Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Em 10-06-2011 06:27, Sakari Ailus escreveu: > Hi Mauro, > > This pull request adds the bitmask controls, flash API and the adp1653 > driver. What has changed since the patches is: > > - Adp1653 flash faults control is volatile. Fix this. > - Flash interface marked as experimental. > - Moved the DocBook documentation to a new location. > - The target version is 3.1, not 2.6.41. > > The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: > > [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 > -0300) > > are available in the git repository at: > ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 > > Hans Verkuil (3): > v4l2-ctrls: add new bitmask control type. > vivi: add bitmask test control. > DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. > > Sakari Ailus (3): > v4l: Add a class and a set of controls for flash devices. > v4l: Add flash control documentation > adp1653: Add driver for LED flash controller > > Documentation/DocBook/media/v4l/compat.xml | 11 + > Documentation/DocBook/media/v4l/controls.xml | 283 > Documentation/DocBook/media/v4l/v4l2.xml |9 +- > .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + > .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- > drivers/media/video/Kconfig|9 + > drivers/media/video/Makefile |1 + > drivers/media/video/adp1653.c | 485 > > drivers/media/video/v4l2-common.c |3 + > drivers/media/video/v4l2-ctrls.c | 62 +++- > drivers/media/video/vivi.c | 18 +- > include/linux/videodev2.h | 37 ++ > include/media/adp1653.h| 126 + > 13 files changed, 1058 insertions(+), 5 deletions(-) > create mode 100644 drivers/media/video/adp1653.c > create mode 100644 include/media/adp1653.h > -- 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/RFC v4] V4L: add media bus configuration subdev operations
On Thu, 30 Jun 2011, Sylwester Nawrocki wrote: > Hi Guennadi, > > On 06/29/2011 06:27 PM, Guennadi Liakhovetski wrote: > > Add media bus configuration types and two subdev operations to get > > supported mediabus configurations and to set a specific configuration. > > Subdevs can support several configurations, e.g., they can send video data > > on 1 or several lanes, can be configured to use a specific CSI-2 channel, > > in such cases subdevice drivers return bitmasks with all respective bits > > set. When a set-configuration operation is called, a non-ambiguous > > configuration has to be specified. > > > > Signed-off-by: Stanimir Varbanov > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > v4: more comments by Hans: > > > > 1. one more variable type to unsigned int > > > > 2. master mode clarified > > > > 3. switch-case fall-through commented > > > > 4. more BT.656, BT.1120 commenting > > > > 5. .s_mbus_config() marked as soc-camera compatibility > > > > v3: addressed comments by Hans - thanks! > > > > 1. moved too big inline function into a new .c file > > > > 2. changed flags types to int, local variables to bool, added "const" > > > > 3. accepting BT.656 now too > > > > v2: > > > > 1. Removed parallel bus width flags. As Laurent correctly pointed out, bus > > width can be configured based on the mediabus format. > > > > 2. Removed the clock parameter for now. Passing timing information between > > the subdevices and the host / bridge driver is indeed necessary, but it is > > not yet quite clear, what is the best way to do this. This requires more > > thinking and can be added as an extra field to struct v4l2_mbus_config > > later. The argument, that "struct clk" is still platform specific is > > correct, but I am too tempted by the possibilities, the clkdev offers us > > to give up this idea immediatrely. Maybe drivers, that need such a clock, > > could use a platform callback to create a clock instance for them, or get > > a clock object from the platform with platform data. However, there are > > Doesn't sound like a good idea to me to be passing clock pointers in platform > data (if that's what you mean) or adding additional callbacks there. > Would such callback be implemented in a board setup file, which are > being phased out in favour of the device tree? As you see, the clock pointer has been removed in v2. We'll see if and when we need it. > > also opinions, that the clkdev API is completely unsuitable for this > > purpose. I'd commit this without any timing first, and consider > > possibilities as a second step. > > > > drivers/media/video/Makefile |2 +- > > include/media/v4l2-mediabus.h | 66 > > + > > include/media/v4l2-subdev.h | 10 ++ > > 3 files changed, 77 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > > index 459db02..e0223ce 100644 > > --- a/drivers/media/video/Makefile > > +++ b/drivers/media/video/Makefile > > @@ -11,7 +11,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o > > omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o > > > > videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o > > \ > > - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o > > + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-mediabus.o > > > > # V4L2 core modules > > > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > > index 971c7fa..e0fb39a 100644 > > --- a/include/media/v4l2-mediabus.h > > +++ b/include/media/v4l2-mediabus.h > > @@ -13,6 +13,72 @@ > > > > #include > > > > +/* Parallel flags */ > > +/* > > + * Can the client run in master or in slave mode. By "Master mode" an > > operation > > + * mode is meant, when the client (e.g., a camera sensor) is producing > > + * horizontal and vertical synchronisation. In "Slave mode" the host is > > + * providing these signals to the slave. > > + */ > > +#define V4L2_MBUS_MASTER (1<< 0) > > +#define V4L2_MBUS_SLAVE(1<< 1) > > +/* Which signal polarities it supports */ > > +/* Note: in BT.656 mode HSYNC and VSYNC are unused */ > > +#define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1<< 2) > > +#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1<< 3) > > +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1<< 4) > > +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1<< 5) > > +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1<< 6) > > +#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1<< 7) > > +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1<< 8) > > +#define V4L2_MBUS_DATA_ACTIVE_LOW (1<< 9) > > + > > +/* Serial flags */ > > +/* How many lanes the client can use */ > > +#define V4L2_MBUS_CSI2_1_LANE (1<< 0) > > +#define V4L2_MBUS_CSI2_2_LANE (1<< 1) > > +#define V4L2_MBUS_CSI2_3_LANE
[PATCH] STV0288 Fast Channel Acquisition
On Wed, 2011-06-29 at 15:16 +0200, Sébastien RAILLARD (COEXSI) wrote:
> On some other transponders, like ASTRA 19.2E 11567-V-22000, the card nearly
> never manage to get the lock: it's looking like the signal isn't good
> enough.
> I turned on the debugging of the stb6000 and stv0288 modules, but I can't
> see anything wrong.
I have had similar problems with the stv0288 on astra 19.2 and 28.2 with
various frequencies.
I have been using this patch for some time which seems to improve
things.
The STV0288 has a fast channel function which eliminates
the need for software carrier search.
The patch removes the slow carrier search and replaces
it with this faster and more reliable built-in chip function.
If carrier is lost while channel is running, fast channel
attempts to recover it.
The patch also reguires registers 50-57 to be set correctly
with inittab. All current combinations in the kernel media
tree have been checked and tested.
Signed-off-by: Malcolm Priestley
---
drivers/media/dvb/frontends/stv0288.c | 75 +---
1 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 8e0cfad..fa5cba5 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -142,6 +142,12 @@ static int stv0288_set_symbolrate(struct dvb_frontend *fe,
u32 srate)
stv0288_writeregI(state, 0x28, b[0]);
stv0288_writeregI(state, 0x29, b[1]);
stv0288_writeregI(state, 0x2a, b[2]);
+
+ stv0288_writeregI(state, 0x22, 0x0);
+ stv0288_writeregI(state, 0x23, 0x0);
+ stv0288_writeregI(state, 0x2b, 0x0);
+ stv0288_writeregI(state, 0x2c, 0x0);
+
dprintk("stv0288: stv0288_set_symbolrate\n");
return 0;
@@ -309,12 +315,13 @@ static u8 stv0288_inittab[] = {
0xf1, 0x0,
0xf2, 0xc0,
0x51, 0x36,
- 0x52, 0x09,
- 0x53, 0x94,
- 0x54, 0x62,
- 0x55, 0x29,
- 0x56, 0x64,
- 0x57, 0x2b,
+ 0x52, 0x21,
+ /* Fast Channel MIN/MAX Freqency Bounds MSB bit 7 sets stop */
+ 0x53, 0x94, /*Min MSB (0-6)*/
+ 0x54, 0x62, /*Min LSB*/
+ 0x55, 0x29, /*Max MSB (0-6)*/
+ 0x56, 0x64, /*Max LSB*/
+ 0x57, 0x2b, /* Increment (signed) */
0xff, 0xff,
};
@@ -356,6 +363,35 @@ static int stv0288_init(struct dvb_frontend *fe)
return 0;
}
+/* STV0288 Fast channel accquisition and blind search */
+static int stv0288_get_fast(struct dvb_frontend *fe)
+{
+ struct stv0288_state *state = fe->demodulator_priv;
+ int timeout = 0;
+
+ /* Coarse Tune */
+ stv0288_writeregI(state, 0x50, 0x35);
+ /* Wait 15ms */
+ msleep(15);
+ /* Fine Tune Control & Center Carrier */
+ stv0288_writeregI(state, 0x50, 0x16);
+ /* Check for Timing lock */
+ while (!(stv0288_readreg(state, 0x1e) & 0x80)) {
+ if (timeout++ > 5)
+ return -EINVAL;
+ msleep(15);
+ }
+
+ /* Center Carrier for further length of time */
+ stv0288_writeregI(state, 0x50, 0x14);
+ udelay(500);
+ /* Fast Search End*/
+ stv0288_writeregI(state, 0x50, 0x10);
+
+ return 0;
+}
+
+
static int stv0288_read_status(struct dvb_frontend *fe, fe_status_t *status)
{
struct stv0288_state *state = fe->demodulator_priv;
@@ -369,6 +405,9 @@ static int stv0288_read_status(struct dvb_frontend *fe,
fe_status_t *status)
*status = 0;
if (sync & 0x80)
*status |= FE_HAS_CARRIER | FE_HAS_SIGNAL;
+ else
+ stv0288_get_fast(fe); /*try to recover*/
+
if (sync & 0x10)
*status |= FE_HAS_VITERBI;
if (sync & 0x08) {
@@ -458,9 +497,7 @@ static int stv0288_set_frontend(struct dvb_frontend *fe,
{
struct stv0288_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
-
- char tm;
- unsigned char tda[3];
+ int ret = 0;
dprintk("%s : FE_SET_FRONTEND\n", __func__);
@@ -487,28 +524,14 @@ static int stv0288_set_frontend(struct dvb_frontend *fe,
stv0288_set_symbolrate(fe, c->symbol_rate);
/* Carrier lock control register */
stv0288_writeregI(state, 0x15, 0xc5);
-
- tda[0] = 0x2b; /* CFRM */
- tda[2] = 0x0; /* CFRL */
- for (tm = -6; tm < 7;) {
- /* Viterbi status */
- if (stv0288_readreg(state, 0x24) & 0x8)
- break;
-
- tda[2] += 40;
- if (tda[2] < 40)
- tm++;
- tda[1] = (unsigned char)tm;
- stv0288_writeregI(state, 0x2b, tda[1]);
- stv0288_writeregI(state, 0x2c, tda[2]);
- udelay(30);
- }
+ /* Search for carrier */
+ ret = stv
Re: [PATCH/RFC] media: vb2: change queue initialization order
On Wed, 29 Jun 2011 16:10:45 +0200 Marek Szyprowski wrote: > > I do still wonder why this is an issue - why not pass the buffers through > > to the driver at VIDIOC_QBUF time? I assume there must be a reason for > > doing things this way, I'd like to understand what it is. > > I want to delay giving the ownership of the buffers to the driver until it > is certain that start_streaming method will be called. This way I achieve > a well defined states of the queued buffers: > > 1. successful start_streaming() -> the driver is processing the queue buffers > 2. unsuccessful start_streaming() -> the driver is responsible to discard all >queued buffers > 3. stop_streaming() called -> the driver has finished or discarded all queued >buffers So it's a buffer ownership thing. I wonder if there would be value in adding a buf_give_them_all_back_now() callback? You have an implicit change of buffer ownership now that seems easy for drivers to mess up. It might be better to send an explicit signal at such times and, perhaps, even require the driver to explicitly hand each buffer back to vb2? That would make the rules clear and give some flexibility - stopping and starting streaming without needing to start over with buffers, for example. Dunno, I'm just sort of babbling as I think; what's there now clearly works. Thanks, jon -- 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/RFC v4] V4L: add media bus configuration subdev operations
Hi Guennadi, On 06/29/2011 06:27 PM, Guennadi Liakhovetski wrote: > Add media bus configuration types and two subdev operations to get > supported mediabus configurations and to set a specific configuration. > Subdevs can support several configurations, e.g., they can send video data > on 1 or several lanes, can be configured to use a specific CSI-2 channel, > in such cases subdevice drivers return bitmasks with all respective bits > set. When a set-configuration operation is called, a non-ambiguous > configuration has to be specified. > > Signed-off-by: Stanimir Varbanov > Signed-off-by: Guennadi Liakhovetski > --- > > v4: more comments by Hans: > > 1. one more variable type to unsigned int > > 2. master mode clarified > > 3. switch-case fall-through commented > > 4. more BT.656, BT.1120 commenting > > 5. .s_mbus_config() marked as soc-camera compatibility > > v3: addressed comments by Hans - thanks! > > 1. moved too big inline function into a new .c file > > 2. changed flags types to int, local variables to bool, added "const" > > 3. accepting BT.656 now too > > v2: > > 1. Removed parallel bus width flags. As Laurent correctly pointed out, bus > width can be configured based on the mediabus format. > > 2. Removed the clock parameter for now. Passing timing information between > the subdevices and the host / bridge driver is indeed necessary, but it is > not yet quite clear, what is the best way to do this. This requires more > thinking and can be added as an extra field to struct v4l2_mbus_config > later. The argument, that "struct clk" is still platform specific is > correct, but I am too tempted by the possibilities, the clkdev offers us > to give up this idea immediatrely. Maybe drivers, that need such a clock, > could use a platform callback to create a clock instance for them, or get > a clock object from the platform with platform data. However, there are Doesn't sound like a good idea to me to be passing clock pointers in platform data (if that's what you mean) or adding additional callbacks there. Would such callback be implemented in a board setup file, which are being phased out in favour of the device tree? > also opinions, that the clkdev API is completely unsuitable for this > purpose. I'd commit this without any timing first, and consider > possibilities as a second step. > > drivers/media/video/Makefile |2 +- > include/media/v4l2-mediabus.h | 66 > + > include/media/v4l2-subdev.h | 10 ++ > 3 files changed, 77 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 459db02..e0223ce 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -11,7 +11,7 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o > omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o > > videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o > \ > - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o > + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-mediabus.o > > # V4L2 core modules > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > index 971c7fa..e0fb39a 100644 > --- a/include/media/v4l2-mediabus.h > +++ b/include/media/v4l2-mediabus.h > @@ -13,6 +13,72 @@ > > #include > > +/* Parallel flags */ > +/* > + * Can the client run in master or in slave mode. By "Master mode" an > operation > + * mode is meant, when the client (e.g., a camera sensor) is producing > + * horizontal and vertical synchronisation. In "Slave mode" the host is > + * providing these signals to the slave. > + */ > +#define V4L2_MBUS_MASTER (1<< 0) > +#define V4L2_MBUS_SLAVE (1<< 1) > +/* Which signal polarities it supports */ > +/* Note: in BT.656 mode HSYNC and VSYNC are unused */ > +#define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1<< 2) > +#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1<< 3) > +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1<< 4) > +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1<< 5) > +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1<< 6) > +#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1<< 7) > +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1<< 8) > +#define V4L2_MBUS_DATA_ACTIVE_LOW(1<< 9) > + > +/* Serial flags */ > +/* How many lanes the client can use */ > +#define V4L2_MBUS_CSI2_1_LANE(1<< 0) > +#define V4L2_MBUS_CSI2_2_LANE(1<< 1) > +#define V4L2_MBUS_CSI2_3_LANE(1<< 2) > +#define V4L2_MBUS_CSI2_4_LANE(1<< 3) > +/* On which channels it can send video data */ > +#define V4L2_MBUS_CSI2_CHANNEL_0 (1<< 4) > +#define V4L2_MBUS_CSI2_CHANNEL_1 (1<< 5) > +#define V4L2_MBUS_CSI2_CHANNEL_2 (1<< 6) > +#define V4L2_MBUS_CSI2_CHANNEL_3 (1<<
Re: RFC: poll behavior
Em 30-06-2011 10:46, Hans Verkuil escreveu:
> On Wednesday, June 29, 2011 16:35:04 Hans de Goede wrote:
>> Hi,
>>
>> On 06/29/2011 03:43 PM, Hans Verkuil wrote:
>>> On Wednesday, June 29, 2011 15:07:14 Hans de Goede wrote:
>>
>>
>>
>>> if (q->num_buffers == 0&& q->fileio == NULL) {
>>> - if (!V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_READ)) {
>>> - ret = __vb2_init_fileio(q, 1);
>>> - if (ret)
>>> - return POLLERR;
>>> - }
>>> - if (V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_WRITE)) {
>>> - ret = __vb2_init_fileio(q, 0);
>>> - if (ret)
>>> - return POLLERR;
>>> - /*
>>> -* Write to OUTPUT queue can be done immediately.
>>> -*/
>>> - return POLLOUT | POLLWRNORM;
>>> - }
>>> + if (!V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_READ))
>>> + return res | POLLIN | POLLRDNORM;
>>> + if (V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_WRITE))
>>> + return res | POLLOUT | POLLWRNORM;
It is wrong to return POLLIN/POLLOUT if the stream hasn't started yet. You
should
return it only when data is ready. Otherwise you should return 0.
>>> }
>>>
>>> /*
>>> * There is nothing to wait for if no buffers have already been
> queued.
>>> */
>>> if (list_empty(&q->queued_list))
>>> - return POLLERR;
>>> + return have_events ? res : POLLERR;
>>>
>>
>> This seems more accurate to me, given that in case of select the 2 influence
>> different fd sets:
>>
>> return res | POLLERR;
>
> Hmm. The problem is that the poll(2) API will always return if POLLERR is
> set,
> even if you only want to wait on POLLPRI.
Yes, but this is the right thing to do: an error condition has happened. If
you're
in doubt, think that poll() is being used for a text file or a socket: if the
connection
has dropped, or there's a problem to access the file, poll() needs to return,
as there is
a condition error that needs to be handled.
> That's a perfectly valid thing to
> do. An alternative is to just not use POLLERR and return res|POLLIN or res|
> POLLOUT depending on V4L2_TYPE_IS_OUTPUT().
You should only rise POLLERR if a problem happened at the events delivery or at
the device streaming.
> Another option is to just return res (which is your suggestion below as well).
> I think this is also a reasonable approach. It would in fact allow one thread
> to call poll(2) and another thread to call REQBUFS/QBUF/STREAMON on the same
> filehandle. And the other thread would return from poll(2) as soon as the
> first frame becomes available.
>
> This also leads to another ambiguity with poll(): what should poll do if
> another filehandle started streaming? So fh1 called STREAMON (and so becomes
> the 'owner' of the stream), and you poll on fh2. If a frame becomes
> available,
> should fh2 wake up? Is fh2 allowed to call DQBUF?
IMO, both fh's should get the same results. This is what happens if you're
writing into a file and two or more processes are selecting at the EOF.
Anyway, changing from the current behavior may break applications.
> To be honest, I think vb2 should keep track of the filehandle that started
> streaming rather than leaving that to drivers, but that's a separate issue.
>
> I really wonder whether we should ever use POLLERR at all: it is extremely
> vague how it should be interpreted, and it doesn't actually tell you what is
> wrong. And is it really an error if you poll on a non-streaming node?
See above. You need to rise it if, for example, an error occurred, and no data
will be ready for read(), write() or DQEVENT. That's the reason why POLLERR
exists.
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: RFC: poll behavior
Em 29-06-2011 09:10, Hans de Goede escreveu: > Hi, > > On 06/29/2011 01:26 PM, Hans Verkuil wrote: >> Hi all, >> >> This RFC is based on recent discussions with regards to how the poll function >> in a V4L2 driver should behave. >> >> Some relevant documents: >> >> POSIX: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/select.html >> http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html >> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >> >> V4L2 Spec: >> >> http://linuxtv.org/downloads/v4l-dvb-apis/func-poll.html >> >> I've copied some descriptions from the POSIX poll document below: >> >> POLLIN >> Data other than high-priority data may be read without blocking. >> >> POLLERR >> An error has occurred on the device or stream. This flag is only valid in the >> revents bitmask; it shall be ignored in the events member. >> >> POLLHUP >> The device has been disconnected. This event and POLLOUT are mutually- >> exclusive; a stream can never be writable if a hangup has occurred. However, >> this event and POLLIN, POLLRDNORM, POLLRDBAND, or POLLPRI are not mutually- >> exclusive. This flag is only valid in the revents bitmask; it shall be >> ignored >> in the events member. >> >> >> >> 1) How *should* it work? >> >> Suppose we could redesign the way V4L2 handles poll(), how should it work? >> >> There are three cases: >> >> a) poll() called when streaming is in progress. >> >> This is easy: if a buffer is available, then return POLLIN (or POLLOUT for >> output). If an event has arrived, then OR with POLLPRI. >> >> b) poll() called when no streaming has started and the driver does not >> support >> the read/write API. >> >> In this case poll() should return POLLERR, since calling poll() when no >> streaming is in progress makes no sense. POLLHUP seems an interesting >> alternative, but other than for end-of-file or end-of-stream conditions it's >> meaning is very fuzzy. Linux also has a POLLRDHUP to make things even more >> confusing. So I would just stick with POLLERR. >> >> c) poll() called when no streaming has started and the driver supports the >> read/write API. >> >> I see no reason why we would do anything different from b). Calling poll() >> when there is no streaming in progress clearly means that there is no data >> available and that there won't be any data either until streaming starts >> somehow. This is where we have different a different understanding. On all cases outside V4L that I know, calling poll (or select) before a read is a valid operation and doesn't return POLLERR, except when there's really an error. Userspace applications assume that, as they generally open a device and calls poll/select to check if they can read or write into it. The V4L2 API seems to understand it at the same way, as it says that calling poll() will start DMA, if the mmap mode is not selected. It should be noticed that there's no splicit command to start DMA via poll/select/read method. So, things like: cat /dev/video0 tail -f /var/video0 mplayer /dev/video0 ... needs to keep working. Requiring a read() to start streaming may break some applications. >> >> >> 2) How does it work today? >> >> a) poll() called when streaming is in progress. >> >> We follow the procedure outlined above. So this is fine. >> >> b) poll() called when no streaming has started and the driver does not >> support >> the read/write API. >> >> In this case POLLERR is returned. So this is also fine. >> >> c) poll() called when no streaming has started and the driver supports the >> read/write API. >> >> Here things are different. poll() will in this case start streaming >> automatically and either return POLLERR if there was an error when starting >> streaming, or return 0 so it will wait until the first buffer arrives. > > Right, to clarify, in this case the drivers assume the app wants r/w mode and > streaming is started for r/w mode, not in mmap mode even if the drivers > support > both. Yes. There is one API violation in this case: poll() is waiting for the stream to start on non-block mode. The right thing would be to defer a working thread to start streaming and return 0 while there's no buffer available, in non-block mode. >> The main problem is that it will also do this if the application only wants >> to >> poll for exceptions (POLLPRI). Unfortunately there is no reliable way in the >> kernel to discover whether the application wanted to poll for POLLIN or just >> for POLLPRI. This behavior simply kills applications that want to wait for >> e.g. changes in controls without actually starting streaming. An example is >> qv4l2. This is the exception usecase. On most cases, the same application controls streaming, events, etc. So, such type of conflicts don't exist, in practice. It might make some sense to have an ioctl that would restrict a "spy only" type of application to actually change anything. One alternative would be to open the
[PATCH 1/2] marvell-cam: Working s/g DMA
The core Marvell camera driver can now do scatter/gather DMA on controllers
which support that functionality.
Signed-off-by: Jonathan Corbet
---
drivers/media/video/marvell-ccic/Kconfig |3 +
drivers/media/video/marvell-ccic/mcam-core.c | 289 ++
drivers/media/video/marvell-ccic/mcam-core.h | 16 ++-
3 files changed, 266 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index 22314a0..5be66e2 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -3,6 +3,8 @@ config VIDEO_CAFE_CCIC
depends on PCI && I2C && VIDEO_V4L2
select VIDEO_OV7670
select VIDEOBUF2_VMALLOC
+ select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_DMA_SG
---help---
This is a video4linux2 driver for the Marvell 88ALP01 integrated
CMOS camera controller. This is the controller found on first-
@@ -15,6 +17,7 @@ config VIDEO_MMP_CAMERA
select I2C_GPIO
select VIDEOBUF2_VMALLOC
select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_DMA_SG
---help---
This is a Video4Linux2 driver for the integrated camera
controller found on Marvell Armada 610 application
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 419b4e5..af5faa6 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "mcam-core.h"
@@ -106,6 +107,7 @@ MODULE_PARM_DESC(buffer_mode,
#define CF_DMA_ACTIVE 3 /* A frame is incoming */
#define CF_CONFIG_NEEDED 4 /* Must configure hardware */
#define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
+#define CF_SG_RESTART 6 /* SG restart needed */
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam->sensor, o, f, ##args)
@@ -180,6 +182,17 @@ static void mcam_set_config_needed(struct mcam_camera
*cam, int needed)
}
/*
+ * The two-word DMA descriptor format used by the Armada 610 and like. There
+ * Is a three-word format as well (set C1_DESC_3WORD) where the third
+ * word is a pointer to the next descriptor, but we don't use it. Two-word
+ * descriptors have to be contiguous in memory.
+ */
+struct mcam_dma_desc {
+ u32 dma_addr;
+ u32 segment_len;
+};
+
+/*
* Our buffer type for working with videobuf2. Note that the vb2
* developers have decreed that struct vb2_buffer must be at the
* beginning of this structure.
@@ -187,6 +200,9 @@ static void mcam_set_config_needed(struct mcam_camera *cam,
int needed)
struct mcam_vb_buffer {
struct vb2_buffer vb_buf;
struct list_head queue;
+ struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
+ dma_addr_t dma_desc_pa; /* Descriptor physical address */
+ int dma_desc_nent; /* Number of mapped descriptors */
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
@@ -268,6 +284,9 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
clear_bit(CF_SINGLE_BUFFER, &cam->flags);
}
+/*
+ * Initial B_DMA_contig setup.
+ */
static void mcam_ctlr_dma_contig(struct mcam_camera *cam)
{
mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
@@ -277,14 +296,38 @@ static void mcam_ctlr_dma_contig(struct mcam_camera *cam)
}
-static void mcam_ctlr_dma(struct mcam_camera *cam)
+/*
+ * Set up the next buffer for S/G I/O; caller should be sure that
+ * the controller is stopped and a buffer is available.
+ */
+static void mcam_sg_next_buffer(struct mcam_camera *cam)
{
- if (cam->buffer_mode == B_DMA_contig)
- mcam_ctlr_dma_contig(cam);
- else
- mcam_ctlr_dma_vmalloc(cam);
+ struct mcam_vb_buffer *buf;
+
+ buf = list_first_entry(&cam->buffers, struct mcam_vb_buffer, queue);
+ list_del_init(&buf->queue);
+ mcam_reg_write(cam, REG_DMA_DESC_Y, buf->dma_desc_pa);
+ mcam_reg_write(cam, REG_DESC_LEN_Y,
+ buf->dma_desc_nent*sizeof(struct mcam_dma_desc));
+ mcam_reg_write(cam, REG_DESC_LEN_U, 0);
+ mcam_reg_write(cam, REG_DESC_LEN_V, 0);
+ cam->vb_bufs[0] = buf;
}
+/*
+ * Initial B_DMA_sg setup
+ */
+static void mcam_ctlr_dma_sg(struct mcam_camera *cam)
+{
+ mcam_reg_clear_bit(cam, REG_CTRL1, C1_DESC_3WORD);
+ mcam_sg_next_buffer(cam);
+ mcam_reg_set_bit(cam, REG_CTRL1, C1_DESC_ENA);
+ cam->nbufs = 3;
+}
+
+/*
+ * Image format setup, independent of DMA scheme.
+ */
static void mcam_ctlr_image(struct mcam_camera *cam)
{
int imgsz;
@@ -341,9 +384,20 @@ static int mcam_ctlr_configure(struct mcam_camera *cam)
unsigned long flags;
spin_lock_irqsave(&cam->dev_lock, flags);
- mcam_ctlr_dma(cam);
+ switch (cam
[PATCH 2/2] marvell-cam: use S/G DMA by default
Scatter/gather DMA mode works nicely on this platform and is clearly the best way of doing things. Signed-off-by: Jonathan Corbet --- drivers/media/video/marvell-ccic/mmp-driver.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mmp-driver.c b/drivers/media/video/marvell-ccic/mmp-driver.c index 7b9c48c..8415915 100644 --- a/drivers/media/video/marvell-ccic/mmp-driver.c +++ b/drivers/media/video/marvell-ccic/mmp-driver.c @@ -180,7 +180,7 @@ static int mmpcam_probe(struct platform_device *pdev) mcam->dev = &pdev->dev; mcam->use_smbus = 0; mcam->chip_id = V4L2_IDENT_ARMADA610; - mcam->buffer_mode = B_vmalloc; /* Switch to dma */ + mcam->buffer_mode = B_DMA_sg; spin_lock_init(&mcam->dev_lock); /* * Get our I/O memory. -- 1.7.5.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] Third marvell-cam patch series
Another week, another series of Marvell cam patches. It's a short series this time: Jonathan Corbet (2): marvell-cam: Working s/g DMA marvell-cam: use S/G DMA by default Kconfig |3 mcam-core.c | 289 ++- mcam-core.h | 16 ++- mmp-driver.c |2 4 files changed, 267 insertions(+), 43 deletions(-) This adds scatter/gather I/O capability to the driver. It was a bit tricky to get going, but it works nicely now; it's the preferred mode of operation for the mmp platform. It can be pulled from: git://git.lwn.net/linux-2.6.git for-mauro I'd meant to resend the other videobuf2-related patches, but Mauro already pulled them. About the only comments I got on the previous set came from Marek; all of those have been addressed after the fact in this series. That mostly completes the hardware enablement push; now there's just all the other details to deal with. My todo list includes: - Being able to operate in all three buffer modes is cool, but the current code requires that support for all three be pulled in (including all three videobuf2-* modules) despite the fact that only one will actually be used. Some sort of config-time selection is clearly needed; I just need to figure out a way that doesn't turn the driver into an #ifdef mess. - Eliminate ov7670 assumptions. I've been thinking on it - will get there, honest. - Planar formats. That's one of those "nobody asked so I never got around to it" items since the first Cafe driver. There's nothing that should be too hard about supporting those formats, though. Comments? Thanks, jon -- 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] Revert "V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI)"
В сообщении от 30 июня 2011 00:49:33 автор Jarod Wilson написал:
> This reverts commit e38030f3ff02684eb9e25e983a03ad318a10a2ea.
>
> MSI flat-out doesn't work right on cx2388x devices yet. There are now
> multiple reports of cards that hard-lock systems when MSI is enabled,
> including my own HVR-1250 when trying to use its built-in IR receiver.
> Disable MSI and it works just fine. Similar for another user's HVR-1270.
> Issues have also been reported with the HVR-1850 when MSI is enabled,
> and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
> seen with an 1800.
>
> References:
>
> http://www.spinics.net/lists/linux-media/msg25956.html
> http://www.spinics.net/lists/linux-media/msg33676.html
> http://www.spinics.net/lists/linux-media/msg34734.html
It's chronic problem now ...
http://www.spinics.net/lists/linux-media/msg22494.html
And how I cure it for particular card.
http://www.spinics.net/lists/linux-media/msg28334.html
Now I see, to revert commit e38030f3ff02684eb9e25e983a03ad318a10a2ea is a
necessity.
>
> CC: Andy Walls
> CC: Kusanagi Kouichi
> Signed-off-by: Jarod Wilson
> ---
> drivers/media/video/cx23885/cx23885-core.c |9 ++---
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/video/cx23885/cx23885-core.c
> b/drivers/media/video/cx23885/cx23885-core.c index 64d9b21..419777a 100644
> --- a/drivers/media/video/cx23885/cx23885-core.c
> +++ b/drivers/media/video/cx23885/cx23885-core.c
> @@ -2060,12 +2060,8 @@ static int __devinit cx23885_initdev(struct pci_dev
> *pci_dev, goto fail_irq;
> }
>
> - if (!pci_enable_msi(pci_dev))
> - err = request_irq(pci_dev->irq, cx23885_irq,
> - IRQF_DISABLED, dev->name, dev);
> - else
> - err = request_irq(pci_dev->irq, cx23885_irq,
> - IRQF_SHARED | IRQF_DISABLED, dev->name, dev);
> + err = request_irq(pci_dev->irq, cx23885_irq,
> + IRQF_SHARED | IRQF_DISABLED, dev->name, dev);
> if (err < 0) {
> printk(KERN_ERR "%s: can't get IRQ %d\n",
> dev->name, pci_dev->irq);
> @@ -2114,7 +2110,6 @@ static void __devexit cx23885_finidev(struct pci_dev
> *pci_dev)
>
> /* unregister stuff */
> free_irq(pci_dev->irq, dev);
> - pci_disable_msi(pci_dev);
>
> cx23885_dev_unregister(dev);
> v4l2_device_unregister(v4l2_dev);
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Jun 30 19:00:43 CEST 2011 git hash:66ef90675ad5e45717ff84e4a106c0d22e690803 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [PATCH] media: fix radio-sf16fmr2 build when SND is not enabled
On Thursday 30 June 2011 19:31:04 Randy Dunlap wrote: > From: Randy Dunlap > > When CONFIG_SND is not enabled, radio-sf16fmr2 build fails with: > > ERROR: "snd_tea575x_init" [drivers/media/radio/radio-sf16fmr2.ko] undefined! > ERROR: "snd_tea575x_exit" [drivers/media/radio/radio-sf16fmr2.ko] undefined! > > so make this driver depend on SND. I broke this when converting the driver to use common TEA575x code. Thanks for finding and fixing it. > Signed-off-by: Randy Dunlap > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab > Cc: linux-media@vger.kernel.org > --- > drivers/media/radio/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-next-20110630.orig/drivers/media/radio/Kconfig > +++ linux-next-20110630/drivers/media/radio/Kconfig > @@ -201,7 +201,7 @@ config RADIO_SF16FMI > > config RADIO_SF16FMR2 > tristate "SF16FMR2 Radio" > - depends on ISA && VIDEO_V4L2 > + depends on ISA && VIDEO_V4L2 && SND > ---help--- > Choose Y here if you have one of these FM radio cards. -- Ondrej Zary -- 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 0/2] USB: EHCI: Allow users to override 80% max periodic bandwidth
On Fri, Jun 24, 2011 at 08:48:06PM +0400, Kirill Smelkov wrote: > > Changes since v1: > > > - dropped RFC status as "this seems like the sort of feature somebody might >reasonably want to use -- if they know exactly what they're doing"; > > - new preparatory patch (1/2) which moves already-in-there sysfs code into >ehci-sysfs.c; > > - moved uframe_periodic_max parameter from module option to sysfs attribute, >so that it can be set per controller and at runtime, added validity checks; > > - clarified a bit bandwith analysis for 96% max periodic setup as noticed by >Alan Stern; > > - clarified patch description saying that set in stone 80% max periodic is >specified by USB 2.0; Have you tested this patch by maxing out this bandwidth on various types of host controllers? It's entirely possible that you'll run into vendor-specific bugs if you try to pack the schedule with isochronous transfers. I don't think any hardware designer would seriously test or validate their hardware with a schedule that is basically a violation of the USB bus spec (more than 80% for periodic transfers). But if Alan is fine with giving users a way to shoot themselves in the foot, and it's disabled by default, then I don't particularly mind this patch. Sarah Sharp -- 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: fix radio-sf16fmr2 build when SND is not enabled
From: Randy Dunlap When CONFIG_SND is not enabled, radio-sf16fmr2 build fails with: ERROR: "snd_tea575x_init" [drivers/media/radio/radio-sf16fmr2.ko] undefined! ERROR: "snd_tea575x_exit" [drivers/media/radio/radio-sf16fmr2.ko] undefined! so make this driver depend on SND. Signed-off-by: Randy Dunlap Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/radio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20110630.orig/drivers/media/radio/Kconfig +++ linux-next-20110630/drivers/media/radio/Kconfig @@ -201,7 +201,7 @@ config RADIO_SF16FMI config RADIO_SF16FMR2 tristate "SF16FMR2 Radio" - depends on ISA && VIDEO_V4L2 + depends on ISA && VIDEO_V4L2 && SND ---help--- Choose Y here if you have one of these FM radio cards. -- 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] V4L: add media bus configuration subdev operations
On Wed, Jun 29, 2011 at 09:28:06PM +0200, Guennadi Liakhovetski wrote: > On Wed, 29 Jun 2011, Sakari Ailus wrote: > > > Guennadi Liakhovetski wrote: > > > On Mon, 27 Jun 2011, Guennadi Liakhovetski wrote: > > > > > > [snip] > > > > > >>> If the structures are expected to be generic I somehow feel that a > > >>> field of > > >>> flags isn't the best way to describe the configuration of CSI-2 or other > > >>> busses. Why not to just use a structure with bus type and an union for > > >>> bus-specific configuration parameters? It'd be easier to access and > > >>> also to > > >>> change as needed than flags in an unsigned long field. > > >> > > >> Well, yes, a union can be a good idea, thanks. > > > > > > ...on a second thought, we currently only have one field: flags, and it > > > is > > > common for all 3 bus types: parallel, reduced parallel (bt.656, etc.), > > > and > > > CSI-2. In the future, when we need more parameters for any of these > > > busses > > > we'll just add such a union, shouldn't be a problem. > > > > What I meant above was that I would prefer to describe the capabilities > > in a structure which would contain appropriate data type for the field, > > not as flags or sets of flags in a bit field. > > > > This would allow e.g. just testing for > > v4l2_mbus_config.u.parallel.hsync_active_low instead of > > v4l2_mbus_config.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW. This way the flags > > used for the bus also express the bus explicitly rather than implicitly. > > I don't think, using flags is any less explicit, than using struct > members. As I already explained, I'd like to use the same interface for > querying capabilities, the present configuration, and setting a > configuration. This is easily achieved with flags. See the > v4l2_mbus_config_compatible() function and try to rewrite all the bitwise > operations in it, using your struct. I still don't like the use of flags this way. I do admit that v4l2_mbus_config_compatible() might be more difficult to write. It's still a tiny piece of code. Speaking of which, should it be part of the latest patch? As far as I understand, v4l2_mbus_config_compatible() is meant for SoC camera compatibility only. I would like that the interface which is not SoC camera dependent would not get compatibility burden right from the beginning. That said, it's a nice property that e.g. sensor drivers written for SoC camera would work without it as well --- is this what the patch would achieve, or a part of it? Regards, -- Sakari Ailus sakari.ai...@iki.fi -- 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: em28xx / ADS Tech USB Instant TV (USBAV-704)
Em 01-05-2011 15:13, Roman Byshko escreveu:
> Hi,
>
> unfortunately nobody replied to me, so I contacted Mauro (thank you!)
> and got some guidance.
>
> According to http://www.linuxtv.org/wiki/index.php/Bus_snooping/sniffing
> I sniffed my device
>
> http://www.linuxtv.org/wiki/index.php/ADS_Tech_Instant_TV_(USBAV-704)
>
> two times. Just in case. The outputs are not identical. Is it ok?
>
> Please find both files attached. I could have adjusted em28xx_cards.c
> by myself, but I know too little. So
> can you please do it or give me hints if this takes too much time.
This device is not touching at the GPIO bits, according with your logs
with is something unusual, but a few devices don't need GPIO's.
The logs shows that the I2C device addresses are:
0x4a - saa7113h
0x60 - not sure... it may be an IR chip. Maybe the Sonix is used as an
IR decoder?
0x86 - tda9887 (part of the tuner)
0xc6 - Probably, this is the tuner
It seems close to EM2820_BOARD_GADMEI_TVR200 (card=62):
[EM2820_BOARD_GADMEI_TVR200] = {
.name = "Gadmei TVR200",
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_SAA711X,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE2,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
},
But, eventually, the audio/video interfaces are on different places.
You'll basically need to write an entry similar to the above, replacing the
tuner type
by the one that represents the tuner FQ1216ME, and replace the .vmux/.amux
entries to
match the entries used on your device. It shouldn't be hard to get the vmux
entry by
taking a look at the "i2c_master_send(0x4a>>1," logs. All you need is to check
at the
saa7113 datasheet (publicly available), and see what registers represent the
video ports
(or look at the saa7115 driver). You'll also need to get the commands from your
log that
are programming the audio mux register.
As there are not that much options, you might also use a trial and error
approach, as
using the wrong values for vmux/amux won't damage your card.
It doesn't seem hard to add support for it, but you'll need to carefully check
each
entry.
As this board doesn't have an eeprom, autodetecting it is tricky. For your
tests, you'll
need to explicitly tell the driver to use your new entry, with card= modprobe
option.
After having it done, please send us the patches, and the logs. It may be
possible to
add an autodetection for it, based on the I2C addresses in usage (0xc6 is not a
common
address, so this will probably work).
After having the video/audio working, we may try to figure out how IR works on
it. From
your logs, it seems that it reads from 0x60 device only:
$ grep 0x60 /tmp/cmds2.txt
i2c_master_recv(0x60>>1, &buf, 0x01); /* 12 */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
i2c_master_recv(0x60>>1, &buf, 0x01); /* ff */
Probably, a value different than 0xff means that a keystroke happened on your
IR.
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: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Hi Manjunath, Thanks for the patches. On Thu, Jun 30, 2011 at 06:43:09PM +0530, Manjunath Hadli wrote: > Thease are the RFC patches for the DM365 video capture, of which > the current set includes only CCDC and the VPFE framework. Once > the present set is reviewed, I will send out the other parts > like H3A, sensor additions etc. > > Introduction > > This is the proposal of the initial version of design and implementation of > the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers > using Media Controloler , the initial version which supports > the following: > 1) dm365 vpfe > 2) ccdc,previewer,resizer,h3a,af blocks > 3) supports both continuous and single-shot modes > 4) supports user pointer exchange and memory mapped modes for buffer > allocation > > This driver bases its design on Laurent Pinchart's Media Controller Design > whose patches for Media Controller and subdev enhancements form the base. > The driver also takes copious elements taken from Laurent Pinchart and > others' OMAP ISP driver based on Media Controller. So thank you all the > people who are responsible for the Media Controller and the OMAP ISP driver. This may be a stupid question, but how much changes are there between this driver and the OMAP 3 ISP driver? I understand that not all the blocks are there. Are there any major functional differences between those in Davinci and those in OMAP 3? Could the OMAP 3 ISP driver made support Davinci ISP as well? There are number of possible improvements that still should be made to the OMAP 3 ISP driver so this way both of the driver would easily get them. To mention some: - Multiple output pipeline - Switch to videobuf2 - Switch to GENIRQ Cc Laurent. Regards, -- Sakari Ailus sakari.ai...@iki.fi -- 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: RFC: poll behavior
On Wednesday, June 29, 2011 16:35:04 Hans de Goede wrote:
> Hi,
>
> On 06/29/2011 03:43 PM, Hans Verkuil wrote:
> > On Wednesday, June 29, 2011 15:07:14 Hans de Goede wrote:
>
>
>
> > if (q->num_buffers == 0&& q->fileio == NULL) {
> > - if (!V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_READ)) {
> > - ret = __vb2_init_fileio(q, 1);
> > - if (ret)
> > - return POLLERR;
> > - }
> > - if (V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_WRITE)) {
> > - ret = __vb2_init_fileio(q, 0);
> > - if (ret)
> > - return POLLERR;
> > - /*
> > -* Write to OUTPUT queue can be done immediately.
> > -*/
> > - return POLLOUT | POLLWRNORM;
> > - }
> > + if (!V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_READ))
> > + return res | POLLIN | POLLRDNORM;
> > + if (V4L2_TYPE_IS_OUTPUT(q->type)&& (q->io_modes& VB2_WRITE))
> > + return res | POLLOUT | POLLWRNORM;
> > }
> >
> > /*
> > * There is nothing to wait for if no buffers have already been
queued.
> > */
> > if (list_empty(&q->queued_list))
> > - return POLLERR;
> > + return have_events ? res : POLLERR;
> >
>
> This seems more accurate to me, given that in case of select the 2 influence
> different fd sets:
>
> return res | POLLERR;
Hmm. The problem is that the poll(2) API will always return if POLLERR is set,
even if you only want to wait on POLLPRI. That's a perfectly valid thing to
do. An alternative is to just not use POLLERR and return res|POLLIN or res|
POLLOUT depending on V4L2_TYPE_IS_OUTPUT().
Another option is to just return res (which is your suggestion below as well).
I think this is also a reasonable approach. It would in fact allow one thread
to call poll(2) and another thread to call REQBUFS/QBUF/STREAMON on the same
filehandle. And the other thread would return from poll(2) as soon as the
first frame becomes available.
This also leads to another ambiguity with poll(): what should poll do if
another filehandle started streaming? So fh1 called STREAMON (and so becomes
the 'owner' of the stream), and you poll on fh2. If a frame becomes available,
should fh2 wake up? Is fh2 allowed to call DQBUF?
To be honest, I think vb2 should keep track of the filehandle that started
streaming rather than leaving that to drivers, but that's a separate issue.
I really wonder whether we should ever use POLLERR at all: it is extremely
vague how it should be interpreted, and it doesn't actually tell you what is
wrong. And is it really an error if you poll on a non-streaming node?
As shown by the use-case above, I don't think it is an error at all.
The default poll mask that is returned when the device doesn't support poll
is #define DEFAULT_POLLMASK (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM).
So if they don't return POLLERR for such devices, perhaps we shouldn't either.
Regards,
Hans
>
> > poll_wait(file,&q->done_wq, wait);
> >
> > @@ -1414,10 +1416,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
> >
> > if (vb&& (vb->state == VB2_BUF_STATE_DONE
> > || vb->state == VB2_BUF_STATE_ERROR)) {
> > - return (V4L2_TYPE_IS_OUTPUT(q->type)) ? POLLOUT | POLLWRNORM :
> > + return res | (V4L2_TYPE_IS_OUTPUT(q->type)) ? POLLOUT |
POLLWRNORM :
> > POLLIN | POLLRDNORM;
>
> I would prefer to see this as:
> res |= (V4L2_TYPE_IS_OUTPUT(q->type)) ? POLLOUT | POLLWRNORM :
> POLLIN | POLLRDNORM;
>
>
> > }
> > - return 0;
> > + return res;
> > }
> > EXPORT_SYMBOL_GPL(vb2_poll);
> >
> >
> > One note: the only time POLLERR is now returned is if no buffers have been
queued
> > and no events have been subscribed to. I think that qualifies as an error
condition.
> > I am not 100% certain, though.
>
> I think it would be better to simply wait (iow return 0) then. I know that
> gstreamer for example uses separate consumer and producer threads, so it is
> possible for the producer thread to wait in select while all buffers have
been
> handed to the (lagging) consumer thread, once the consumer thread has
consumed
> a buffer it will queue it, and once filled the select will return it to
> the producer thread, who shoves it into the pipeline again, etc.
>
> Regards,
>
> Hans
>
>
--
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: [git:xawtv3/master] xawtv: reenable its usage with webcam's
Em 30-06-2011 10:20, Mauro Carvalho Chehab escreveu: > Em 30-06-2011 09:35, Mauro Carvalho Chehab escreveu: >> Em 30-06-2011 07:55, Hans de Goede escreveu: > >>> 1) This bit should be #ifdef __linux__ since we only support >>> auto* on linux because of the sysfs dep: >> >> True, but instead of adding it on every place, the better would be to >> replace auto/auto_tv >> at the library, instead of adding the test at each place we change to auto >> mode. > > I fixed it using this approach. > >>> 2) The added return NULL in case no device can be found lacks >>> printing an error message: > >>> I propose changing the return NULL, with a goto to the error print further >>> down. >> >> Yes, that sounds better to me. > > The error message didn't look good, so I added an specific message for it. > > Yet, IMO, we're being too verbose: > > $ scantv > vid-open-auto: failed to open an analog TV device at /dev/video0 > vid-open: could not find a suitable videodev > no analog TV device available Ah, calling it without any media driver is also verbose and wrong: $ xawtv This is xawtv-, running on Linux/x86_64 (2.6.32-131.0.15.el6.x86_64) vid-open-auto: failed to open a capture device at vid-open: could not find a suitable videodev no video grabber device available $ scantv vid-open-auto: failed to open an analog TV device at �7 vid-open: could not find a suitable videodev no analog TV device available 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: [git:xawtv3/master] xawtv: reenable its usage with webcam's
Em 30-06-2011 09:35, Mauro Carvalho Chehab escreveu: > Em 30-06-2011 07:55, Hans de Goede escreveu: >> 1) This bit should be #ifdef __linux__ since we only support >> auto* on linux because of the sysfs dep: > > True, but instead of adding it on every place, the better would be to replace > auto/auto_tv > at the library, instead of adding the test at each place we change to auto > mode. I fixed it using this approach. >> 2) The added return NULL in case no device can be found lacks >> printing an error message: >> I propose changing the return NULL, with a goto to the error print further >> down. > > Yes, that sounds better to me. The error message didn't look good, so I added an specific message for it. Yet, IMO, we're being too verbose: $ scantv vid-open-auto: failed to open an analog TV device at /dev/video0 vid-open: could not find a suitable videodev no analog TV device available 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
[RFC PATCH 2/8] davinci: vpfe: add IPIPE hardware layer support
From: Nagabhushana Netagunte
add dm365 IPIPE hardware support. IPIPE is the hardware IP which
implements the functionality required for resizer, previewer and
the associated feature support. This is built along with the vpfe
driver, and implements hardware setup including coeffcient
programming for various hardware filters, gamma, cfa and clock
enable.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/dm365_ipipe_hw.c | 1012 ++
drivers/media/video/davinci/dm365_ipipe_hw.h | 539 ++
2 files changed, 1551 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h
diff --git a/drivers/media/video/davinci/dm365_ipipe_hw.c
b/drivers/media/video/davinci/dm365_ipipe_hw.c
new file mode 100644
index 000..b88e8e8
--- /dev/null
+++ b/drivers/media/video/davinci/dm365_ipipe_hw.c
@@ -0,0 +1,1012 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dm365_ipipe_hw.h"
+
+static void ipipe_clock_enable(void)
+{
+ /* enable IPIPE MMR for register write access */
+ regw_ip(IPIPE_GCK_MMR_DEFAULT, IPIPE_GCK_MMR);
+ /* enable the clock wb,cfa,dfc,d2f,pre modules */
+ regw_ip(IPIPE_GCK_PIX_DEFAULT, IPIPE_GCK_PIX);
+ /* enable RSZ MMR for register write access */
+}
+
+/* Set input channel format to either 420 Y or C format */
+int rsz_set_in_pix_format(unsigned char y_c)
+{
+ u32 val;
+
+ val = regr_rsz(RSZ_SRC_FMT1);
+ val |= (y_c & 1);
+ regw_rsz(val, RSZ_SRC_FMT1);
+
+ return 0;
+}
+
+static int rsz_set_common_params(struct ipipe_params *params)
+{
+ struct rsz_common_params *rsz_common = ¶ms->rsz_common;
+ u32 val;
+
+ /* Set mode */
+ regw_rsz(params->ipipe_mode, RSZ_SRC_MODE);
+
+ /* data source selection and bypass */
+ val = ((rsz_common->passthrough << RSZ_BYPASS_SHIFT) |
+ (rsz_common->source));
+
+ regw_rsz(val, RSZ_SRC_FMT0);
+ val = regr_rsz(RSZ_SRC_MODE);
+ /* src image selection */
+ val = (rsz_common->raw_flip & 1) |
+ (rsz_common->src_img_fmt << RSZ_SRC_IMG_FMT_SHIFT) |
+ ((rsz_common->y_c & 1) << RSZ_SRC_Y_C_SEL_SHIFT);
+
+ regw_rsz(val, RSZ_SRC_FMT1);
+ regw_rsz(rsz_common->vps & IPIPE_RSZ_VPS_MASK, RSZ_SRC_VPS);
+ regw_rsz(rsz_common->hps & IPIPE_RSZ_HPS_MASK, RSZ_SRC_HPS);
+ regw_rsz(rsz_common->vsz & IPIPE_RSZ_VSZ_MASK, RSZ_SRC_VSZ);
+ regw_rsz(rsz_common->hsz & IPIPE_RSZ_HSZ_MASK, RSZ_SRC_HSZ);
+ regw_rsz(rsz_common->yuv_y_min, RSZ_YUV_Y_MIN);
+ regw_rsz(rsz_common->yuv_y_max, RSZ_YUV_Y_MAX);
+ regw_rsz(rsz_common->yuv_c_min, RSZ_YUV_C_MIN);
+ regw_rsz(rsz_common->yuv_c_max, RSZ_YUV_C_MAX);
+ /* chromatic position */
+ regw_rsz(rsz_common->out_chr_pos, RSZ_YUV_PHS);
+ val = regr_rsz(RSZ_SRC_MODE);
+
+ return 0;
+}
+
+static void rsz_set_rsz_regs(unsigned int rsz_id, struct ipipe_params *params)
+{
+ struct ipipe_rsz_rescale_param *rsc_params;
+ struct ipipe_ext_mem_param *ext_mem;
+ struct ipipe_rsz_resize2rgb *rgb;
+ u32 reg_base;
+ u32 val;
+
+ val = regr_rsz(RSZ_SEQ);
+ if (rsz_id == RSZ_A) {
+ rsc_params = ¶ms->rsz_rsc_param[RSZ_A];
+ rgb = ¶ms->rsz2rgb[RSZ_A];
+ ext_mem = ¶ms->ext_mem_param[RSZ_A];
+ val = rsc_params->h_flip << RSZA_H_FLIP_SHIFT;
+ val |= rsc_params->v_flip << RSZA_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_A;
+ } else {
+ rsc_params = ¶ms->rsz_rsc_param[RSZ_B];
+ rgb = ¶ms->rsz2rgb[RSZ_B];
+ ext_mem = ¶ms->ext_mem_param[RSZ_B];
+ val = rsc_params->h_flip << RSZB_H_FLIP_SHIFT;
+ val |= rsc_params->v_flip << RSZB_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_B;
+ }
+ /* update flip settings */
+ regw_rsz(val, RSZ_SEQ);
+
+ regw_rsz(rsc_params->mode, reg_base + RSZ_MODE);
+ val = (rsc_params->cen << RSZ_CEN_SHIFT) | rsc_params->yen;
+ regw_rsz(val, reg_base + RSZ_420);
+ regw_rsz(rsc_params->i_vps & RSZ_V
[RFC PATCH 6/8] davinci: vpfe: add v4l2 video driver support
From: Nagabhushana Netagunte
add a generic video driver functionality to be used by all the vpfe
drivers for davinci SoCs. The functionality includes all the
standard v4l2 interfaces including streaming.
The video node interface can be used both as an input and output
node for both continuous and single shot modes.Also supports
dv_presets to include HD modes, wth support for both user pointer
IO and mmap.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/vpfe_video.c | 1712 ++
include/media/davinci/vpfe_types.h | 50 +-
include/media/davinci/vpfe_video.h | 142 +++
3 files changed, 1871 insertions(+), 33 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_video.c
create mode 100644 include/media/davinci/vpfe_video.h
diff --git a/drivers/media/video/davinci/vpfe_video.c
b/drivers/media/video/davinci/vpfe_video.c
new file mode 100644
index 000..00587d7
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_video.c
@@ -0,0 +1,1712 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contributors:-
+ * Manjunath Hadli
+ * Nagabhushana Netagunte
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ccdc_hw_device.h"
+
+/* number of buffers supported in single-shot mode */
+#define SS_NUM_BUFFERS 1
+/* minimum number of buffers needed in cont-mode */
+#define CONT_MIN_NUM_BUFFERS 3
+
+static int debug;
+
+/* get v4l2 subdev pointer to external subdev which is active */
+static struct v4l2_subdev *vpfe_get_input_sd(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video->vpfe_dev;
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(&vpfe_dev->vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR "invalid media connection to ccdc\n");
+ return NULL;
+ }
+
+ return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+/* updates external subdev(sensor/decoder) which is active */
+static int vpfe_update_current_ext_subdev(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video->vpfe_dev;
+ struct vpfe_config *vpfe_cfg;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ int i;
+
+ remote = media_entity_remote_source(&vpfe_dev->vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR "invalid media connection to ccdc\n");
+ return -1;
+ }
+
+ subdev = media_entity_to_v4l2_subdev(remote->entity);
+
+ vpfe_cfg = vpfe_dev->pdev->platform_data;
+
+ for (i = 0; i < vpfe_cfg->num_subdevs; i++) {
+ if (!strcmp(vpfe_cfg->sub_devs[i].module_name, subdev->name)) {
+ video->current_ext_subdev = &vpfe_cfg->sub_devs[i];
+ break;
+ }
+ }
+
+ /* if user not linked decoder/sensor to ccdc */
+ if (i == vpfe_cfg->num_subdevs) {
+ printk(KERN_ERR "invalid media chain connection to ccdc\n");
+ return -1;
+ }
+
+ /* find the v4l2 subdev pointer */
+ for (i = 0; i < vpfe_dev->num_ext_subdevs; i++) {
+ if (!strcmp(video->current_ext_subdev->module_name,
+ vpfe_dev->sd[i]->name))
+ video->current_ext_subdev->subdev = vpfe_dev->sd[i];
+ }
+
+ return 0;
+}
+
+/* get the subdev which is connected to the output video node */
+static struct v4l2_subdev *
+vpfe_video_remote_subdev(struct vpfe_video_device *video, u32 *pad)
+{
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(&video->pad);
+
+ if (remote == NULL ||
+ remote->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
+ return NULL;
+
+ if (pad)
+ *pad = remote->index;
+
+ return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+/* get the format set at ouput pad of the adjacent subdev */
+static int
+__vpfe_video_get_format(struct vpfe_video_device *video,
+ struct v4l2_format *format)
+{
+ struct v4l2_subdev_format fmt;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ u32 pad;
+
[RFC PATCH 5/8] davinci: vpfe: add ccdc driver with media controller interface
From: Nagabhushana Netagunte
Add the CCDC driver for davinci Dm3XX SoCs. The driver supports
CCDC as a media entity with 2 pads - 1 input and 1 output. The
driver implements streaming support and subdev interface. The
ccdc supports bayer and YUV formats.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/ccdc_hw_device.h |6 +-
drivers/media/video/davinci/vpfe_ccdc.c | 813 ++
include/media/davinci/vpfe_ccdc.h| 89 +++
3 files changed, 903 insertions(+), 5 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c
create mode 100644 include/media/davinci/vpfe_ccdc.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
index 86b9b35..7d56ec9 100644
--- a/drivers/media/video/davinci/ccdc_hw_device.h
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -57,7 +57,7 @@ struct ccdc_hw_ops {
*/
int (*get_params) (void *params);
/* Pointer to function to configure ccdc */
- int (*configure) (void);
+ int (*configure) (int mode);
/* Pointer to function to set buffer type */
int (*set_buftype) (enum ccdc_buftype buf_type);
@@ -102,9 +102,5 @@ struct ccdc_hw_device {
struct ccdc_hw_ops hw_ops;
};
-/* Used by CCDC module to register & unregister with vpfe capture driver */
-int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
-void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
-
#endif
#endif
diff --git a/drivers/media/video/davinci/vpfe_ccdc.c
b/drivers/media/video/davinci/vpfe_ccdc.c
new file mode 100644
index 000..e2453a5
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_ccdc.c
@@ -0,0 +1,813 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contributors:
+ * Manjunath Hadli
+ * Nagabhushana Netagunte
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ccdc_hw_device.h"
+
+#define MAX_WIDTH 4096
+#define MAX_HEIGHT 4096
+
+static const unsigned int ccdc_fmts[] = {
+ V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_YUYV10_1X20,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+};
+
+/*
+ * CCDC helper functions
+ */
+/* get field id in ccdc hardware */
+enum v4l2_field ccdc_get_fid(struct vpfe_device *vpfe_dev)
+{
+ struct vpfe_ccdc_device *ccdc = &vpfe_dev->vpfe_ccdc;
+ struct ccdc_hw_device *ccdc_dev = ccdc->ccdc_dev;
+
+ return ccdc_dev->hw_ops.getfid();
+}
+
+/* Retrieve active or try pad format based on query */
+static struct v4l2_mbus_framefmt *
+__ccdc_get_format(struct vpfe_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+ if (which == V4L2_SUBDEV_FORMAT_TRY) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad;
+ fmt.which = which;
+
+ return v4l2_subdev_get_try_format(fh, pad);
+ } else
+ return &ccdc->formats[pad];
+}
+
+/* configure format in ccdc hardware */
+static int vpfe_config_ccdc_format(struct vpfe_device *vpfe_dev,
+ unsigned int pad)
+{
+ struct ccdc_hw_device *ccdc_dev = vpfe_dev->vpfe_ccdc.ccdc_dev;
+ struct vpfe_ccdc_device *vpfe_ccdc = &vpfe_dev->vpfe_ccdc;
+ enum ccdc_frmfmt frm_fmt = CCDC_FRMFMT_INTERLACED;
+ struct v4l2_pix_format format;
+ int ret = 0;
+
+ v4l2_fill_pix_format(&format, &vpfe_dev->vpfe_ccdc.formats[pad]);
+ mbus_to_pix(&vpfe_dev->vpfe_ccdc.formats[pad], &format);
+
+ if (ccdc_dev->hw_ops.set_pixel_format(
+ format.pixelformat) < 0) {
+ v4l2_err(&vpfe_dev->v4l2_dev,
+ "couldn't set pix format in ccdc\n");
+ return -EINVAL;
+ }
+
+ /* call for s_crop will override these values */
+ vpfe_ccdc->crop.left = 0;
+ vpfe_ccdc->crop.top = 0;
+ vpfe_ccdc->crop.width = format.width;
+ vpfe_ccdc->crop.height = format.height;
+
+ /* configure the image window */
+ ccdc_dev->hw_ops.set_image_window(&vpfe_ccdc->crop);
+
+ switch (vpfe_dev->vpfe_ccdc.formats[pad].field) {
+ case
[RFC PATCH 7/8] davinci: vpfe: v4l2 capture driver with media interface
From: Nagabhushana Netagunte Add the vpfe capture driver which implements media controller interface. The driver suports all the setup functionality for all all units nnamely- ccdc, previewer, resizer, h3a, aew. The driver supports both dm365 and Dm355. The driver does isr registration, v4l2 device registration, media registration and platform driver registrations. It calls the appropriate subdevs from here to cerate the appropriate subdevices and media entities. Signed-off-by: Manjunath Hadli Signed-off-by: Nagabhushana Netagunte --- drivers/media/video/davinci/vpfe_capture.c | 793 include/media/davinci/vpfe_capture.h | 158 ++ 2 files changed, 951 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/vpfe_capture.c create mode 100644 include/media/davinci/vpfe_capture.h diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c new file mode 100644 index 000..6c57c19 --- /dev/null +++ b/drivers/media/video/davinci/vpfe_capture.c @@ -0,0 +1,793 @@ +/* + * Copyright (C) 2011 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Contributors:- + * Manjunath Hadli + * Nagabhushana Netagunte + * + * Driver name : VPFE Capture driver + *VPFE Capture driver allows applications to capture and stream video + *frames on DaVinci SoCs (DM6446, DM355 etc) from a YUV source such as + *TVP5146 or Raw Bayer RGB image data from an image sensor + *such as Microns' MT9T001, MT9T031 etc. + * + *These SoCs have, in common, a Video Processing Subsystem (VPSS) that + *consists of a Video Processing Front End (VPFE) for capturing + *video/raw image data and Video Processing Back End (VPBE) for displaying + *YUV data through an in-built analog encoder or Digital LCD port. This + *driver is for capture through VPFE. A typical EVM using these SoCs have + *following high level configuration. + * + *decoder(TVP5146/ YUV/ + * MT9T001) --> Raw Bayer RGB ---> MUX -> VPFE (CCDC/ISIF) + * data input | | + * V | + * SDRAM| + *V + *Image Processor + *| + *V + * SDRAM + *The data flow happens from a decoder connected to the VPFE over a + *YUV embedded (BT.656/BT.1120) or separate sync or raw bayer rgb interface + *and to the input of VPFE through an optional MUX (if more inputs are + *to be interfaced on the EVM). The input data is first passed through + *CCDC (CCD Controller, a.k.a Image Sensor Interface, ISIF). The CCDC + *does very little or no processing on YUV data and does pre-process Raw + *Bayer RGB data through modules such as Defect Pixel Correction (DFC) + *Color Space Conversion (CSC), data gain/offset etc. After this, data + *can be written to SDRAM or can be connected to the image processing + *block such as IPIPE (on DM355/DM365 only). + * + *Features supported + * - MMAP IO + * - USERPTR IO + * - Capture using TVP5146 over BT.656 + * - Support for interfacing decoders using sub device model + * - Work with DM365 or DM355 or DM6446 CCDC to do Raw Bayer + * RGB/YUV data capture to SDRAM. + * - Chaining of Image Processor + * - SINGLE-SHOT mode + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int debug; +static int interface; +static u32 cont_bufoffset; +static u32 cont_bufsize; +static u32 en_serializer; + +module_param(interface, bool, S_IRUGO); +module_param(debug, bool, 0644); +module_param(cont_bufoffset, uint, S_IRUGO); +module_param(cont_bufsize, uint, S_IRUGO); +module_param(en_serializer, uint, S_IRUGO); + +/** + * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002 + * and for capture raw bayer data from camera sensors
[RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
add support for dm3xx IPIPEIF hardware setup. This is the
lowest software layer for the dm3x vpfe driver which directly
accesses hardware. Add support for features like default
pixel correction, dark frame substraction and hardware setup.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 368 +++
include/media/davinci/dm3xx_ipipeif.h | 292 +
2 files changed, 660 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 include/media/davinci/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..36cb61b
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,368 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*
+* ipipe module to hold common functionality across DM355 and DM365
+*/
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DM355 0
+#define DM365 1
+
+static void *__iomem ipipeif_base_addr;
+static int device_type;
+
+static inline u32 regr_if(u32 offset)
+{
+ return readl(ipipeif_base_addr + offset);
+}
+
+static inline void regw_if(u32 val, u32 offset)
+{
+ writel(val, ipipeif_base_addr + offset);
+}
+
+void ipipeif_set_enable(char en, unsigned int mode)
+{
+ regw_if(1, IPIPEIF_ENABLE);
+}
+
+u32 ipipeif_get_enable(void)
+{
+ return regr_if(IPIPEIF_ENABLE);
+}
+
+int ipipeif_set_address(struct ipipeif *params, unsigned int address)
+{
+ unsigned int val1;
+ unsigned int val;
+
+ if (params->source != 0) {
+ val = ((params->adofs >> 5) & IPIPEIF_ADOFS_LSB_MASK);
+ regw_if(val, IPIPEIF_ADOFS);
+
+ /* lower sixteen bit */
+ val = ((address >> IPIPEIF_ADDRL_SHIFT) & IPIPEIF_ADDRL_MASK);
+ regw_if(val, IPIPEIF_ADDRL);
+
+ /* upper next seven bit */
+ val1 =
+ ((address >> IPIPEIF_ADDRU_SHIFT) & IPIPEIF_ADDRU_MASK);
+ regw_if(val1, IPIPEIF_ADDRU);
+ } else
+ return -1;
+
+ return 0;
+}
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc)
+{
+ u32 val;
+
+ if (dpc->en) {
+ val = ((dpc->en & 1) << IPIPEIF_DPC2_EN_SHIFT);
+ val |= (dpc->thr & IPIPEIF_DPC2_THR_MASK);
+ } else
+ val = 0;
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
+/* This function sets up IPIPEIF and is called from
+ * ipipe_hw_setup()
+ */
+int ipipeif_hw_setup(struct ipipeif *params)
+{
+ enum v4l2_mbus_pixelcode isif_port_if;
+ unsigned int val1 = 0x7;
+ unsigned int val;
+
+ if (NULL == params)
+ return -1;
+
+ /* Enable clock to IPIPEIF and IPIPE */
+ if (device_type == DM365)
+ vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
+
+ /* Combine all the fields to make CFG1 register of IPIPEIF */
+ val = params->mode << ONESHOT_SHIFT;
+ val |= params->source << INPSRC_SHIFT;
+ val |= params->clock_select << CLKSEL_SHIFT;
+ val |= params->avg_filter << AVGFILT_SHIFT;
+ val |= params->decimation << DECIM_SHIFT;
+
+ if (device_type == DM355) {
+ val |= params->var.if_base.ialaw << IALAW_SHIFT;
+ val |= params->var.if_base.pack_mode << PACK8IN_SHIFT;
+ val |= params->var.if_base.clk_div << CLKDIV_SHIFT;
+ val |= params->var.if_base.data_shift << DATASFT_SHIFT;
+ } else {
+ /* DM365 IPIPE 5.1 */
+ val |= params->var.if_5_1.pack_mode << PACK8IN_SHIFT;
+ val |= params->var.if_5_1.source1 << INPSRC1_SHIFT;
+ if (params->source != SDRAM_YUV)
+ val |= params->var.if_5_1.data_shift << DATASFT_SHIFT;
+ else
+ val &= (~(val1 << DATASFT_SHIFT));
+ }
+ regw_if(val, IPIPEIF_GFG1);
+
+ switch (params->source) {
+ case CCDC:
+ {
+ regw_if(params->gain, IPIPEIF_GAIN);
+ break;
+ }
+ case SDRAM_RAW:
+ case CCDC_DARKFM:
+ {
+
[RFC PATCH 8/8] davinci: vpfe: build infrastructure for dm365
add build infrastructure for dm365 specific modules such as IPIPE, AEW, AF. Signed-off-by: Manjunath Hadli Signed-off-by: Nagabhushana Netagunte --- drivers/media/video/davinci/Kconfig | 46 - drivers/media/video/davinci/Makefile | 17 +++- 2 files changed, 59 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..6f6da53 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -11,6 +11,48 @@ config DISPLAY_DAVINCI_DM646X_EVM To compile this driver as a module, choose M here: the module will be called vpif_display. +config VIDEO_DM365_3A_HW + tristate "DM365 Auto Focus, Auto Exposure/ White Balance HW module" + depends on ARCH_DAVINCI_DM365 + help + DM365 Auto Focus, Auto Exposure and Auto White Balancing HW module + + This module has functions which configure AEW/AF hardware, high level + AF module and AEW module use these functionalities. It collects metrics + about the image or video data + +config VIDEO_DM365_AF + tristate "DM365 Auto Focus Driver" + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Focus hardware module. + + Auto Focus driver is used to support control loop for Auto Focus. + It collects metrics about the image or video data. This provides + hooks to AF subdevice driver. + +config VIDEO_DM365_AEW + tristate "DM365 Auto exposure /White Balance Driver" + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Exposure and Auto White Balance hardware module. + + This is used to support the control loops for Auto Exposure + and Auto White Balance. It collects metrics about the image + or video data + +config DM365_IPIPE + depends on ARCH_DAVINCI && ARCH_DAVINCI_DM365 + tristate "DM365 IPIPE" + help + dm365 IPIPE hardware module. + + This is the hardware module that implements imp_hw_interface + for DM365. This hardware module provides previewer and resizer + functionality for image processing. + config CAPTURE_DAVINCI_DM646X_EVM tristate "DM646x EVM Video Capture" depends on VIDEO_DEV && MACH_DAVINCI_DM6467_EVM @@ -51,7 +93,7 @@ config VIDEO_VPFE_CAPTURE config VIDEO_DM6446_CCDC tristate "DM6446 CCDC HW module" - depends on VIDEO_VPFE_CAPTURE + depends on VIDEO_VPFE_CAPTURE && ARCH_DAVINCI_DM644x select VIDEO_VPSS_SYSTEM default y help @@ -80,7 +122,7 @@ config VIDEO_DM355_CCDC module will be called vpfe. config VIDEO_ISIF - tristate "ISIF HW module" + tristate "DM365 ISIF HW module" depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM default y diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..8544040 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -12,7 +12,20 @@ obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o -obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o vpfe_ccdc.o \ + vpfe_resizer.o vpfe_previewer.o \ + vpfe_aew.o vpfe_af.o vpfe_video.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o -obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_ISIF) += dm365_ccdc.o + +dm365_a3_hw_driver-objs := dm365_a3_hw.o +obj-$(CONFIG_VIDEO_DM365_3A_HW) += dm365_a3_hw_driver.o +dm365_af_driver-objs := dm365_af.o +obj-$(CONFIG_VIDEO_DM365_AF)+= dm365_af_driver.o +dm365_aew_driver-objs := dm365_aew.o +obj-$(CONFIG_VIDEO_DM365_AEW) += dm365_aew_driver.o + +dm365_imp-objs := dm365_ipipe.o dm365_def_para.o \ +dm365_ipipe_hw.o dm3xx_ipipeif.o +obj-$(CONFIG_DM365_IPIPE) += dm365_imp.o -- 1.6.2.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
[ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Thease are the RFC patches for the DM365 video capture, of which the current set includes only CCDC and the VPFE framework. Once the present set is reviewed, I will send out the other parts like H3A, sensor additions etc. Introduction This is the proposal of the initial version of design and implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports both continuous and single-shot modes 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, and Resizer. The current driver caters to dm6446,dm355 and dm365 of which the current implementation works for dm365. The three VPFE IPs have some common elements in terms of some highe level functionality but there are differences in terms of register definitions and some core blocks. The individual specifications for each of these can be found here: dm6446 vpfe: http://www.ti.com/litv/pdf/sprue38h dm355 vpfe: http://www.ti.com/litv/pdf/spruf71a dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c The initial version of the driver implementation can be found here: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/mc_release Driver Design: Main entities The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. These hardware modules are generically exposed to the user level in the for of dm6446 style modules. Mainly - ccdc, previewer, resizer in addition to the other histogram and auto color/white balance correction and auto focus modules. 1)MT9P031 sensor module for RAW capture 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV conversion 6)Resizer Module for scaling Connection for on-the-fly capture - Mt9P031 -->CCDC--->Previewer(optional)--->Resizer(optional)--->Video | TVP7002 --- | TV514x --- Manjunath Hadli (3): davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add support for CCDC hardware for dm365 davinci: vpfe: build infrastructure for dm365 Nagabhushana Netagunte (5): davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver davinci: vpfe: add ccdc driver with media controller interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: v4l2 capture driver with media interface drivers/media/video/davinci/Kconfig | 46 +- drivers/media/video/davinci/Makefile | 17 +- drivers/media/video/davinci/ccdc_hw_device.h |6 +- drivers/media/video/davinci/dm365_ccdc.c | 1517 + drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ drivers/media/video/davinci/dm365_def_para.c | 485 +++ drivers/media/video/davinci/dm365_def_para.h | 39 + drivers/media/video/davinci/dm365_ipipe.c | 4086 + drivers/media/video/davinci/dm365_ipipe_hw.c | 1012 ++ drivers/media/video/davinci/dm365_ipipe_hw.h | 539 drivers/media/video/davinci/dm3xx_ipipeif.c | 368 +++ drivers/media/video/davinci/vpfe_capture.c| 793 + drivers/media/video/davinci/vpfe_ccdc.c | 813 + drivers/media/video/davinci/vpfe_video.c | 1712 +++ include/media/davinci/dm365_ccdc.h| 722 + include/media/davinci/dm365_ipipe.h | 1353 include/media/davinci/dm3xx_ipipeif.h | 292 ++ include/media/davinci/imp_common.h| 231 ++ include/media/davinci/imp_hw_if.h | 177 ++ include/media/davinci/vpfe_capture.h | 158 + include/media/davinci/vpfe_ccdc.h | 89 + include/media/davinci/vpfe_types.h| 50 +- include/media/davinci/vpfe_video.h| 142 + 23 files changed, 14914 insertions(+), 42 deletions(-) create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 drivers/media/video/davinci/dm365_def_para.c create mode 100644 drivers/media/video/davinci/dm365_def_para.h create mode 100644 drivers/media/video/davinci/dm365_ipipe.c create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c create mode 100644 drivers/media/video/davinci/dm365_i
Re: [git:xawtv3/master] xawtv: reenable its usage with webcam's
Em 30-06-2011 07:55, Hans de Goede escreveu:
> Hi,
>
> On 06/29/2011 09:27 PM, Mauro Carvalho Chehab wrote:
>
>
>
>>
>> Anyway, it is fixed. I also made scantv to force for a TV device at auto
>> mode, as it
>> doesn't sense to scan for TV channels on devices without tuner.
>
> Thanks for fixing this, 2 remarks wrt the auto patch for
> scantv:
>
> 1) This bit should be #ifdef __linux__ since we only support
> auto* on linux because of the sysfs dep:
>
> @@ -149,6 +149,9 @@ main(int argc, char **argv)
>
> /* parse options */
> ng_init();
> +/* Autodetect devices */
> +ng_dev.video = "auto_tv";
> +
> for (;;) {
> if (-1 == (c = getopt(argc, argv, "hsadi:n:f:o:c:C:D:")))
> break;
>
True, but instead of adding it on every place, the better would be to replace
auto/auto_tv
at the library, instead of adding the test at each place we change to auto mode.
BTW, does the bsd driver actually work? I remember they asked us to release the
videodev2.h
file as dual licensing, in order to allow BSD to use V4L2 API also, a few years
ago. If they
actually changed, all those bsd compat stuff is wrong.
> 2) The added return NULL in case no device can be found lacks
> printing an error message:
>
> @@ -568,6 +569,8 @@ static void *ng_vid_open_auto(struct ng_vid_driver *drv,
> char *devpath)
>
> /* Step 2: try grabber devices and webcams */
> if (!handle) {
> +if (!allow_grabber)
> +return NULL;
> device = NULL;
> while (1) {
> device = get_associated_device(md, device, MEDIA_V4L_VIDEO, NULL,
> NONE);
>
> I propose changing the return NULL, with a goto to the error print further
> down.
Yes, that sounds better to me.
>
>> From my side, I don't intend to touch on xawtv any time soon. So, maybe we
>> can wait
>> for a couple days and release version 1.101.
>
> Assuming the 2 things mentioned above get fixed that sounds like a good plan
> to me.
>
> Regards,
>
> Hans
--
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: v4l2 api for flash drivers
Hi Andy and Laurent, On Thu, Jun 30, 2011 at 01:06:08PM +0200, Laurent Pinchart wrote: > Hi Andy, > > On Thursday 30 June 2011 12:55:10 Andy Shevchenko wrote: > > Hello. > > > > I didn't see the patchset [1] in any public tree on git.kernel.org. Is > > this patch going to be pushed? > > > > [1] http://www.spinics.net/lists/linux-media/msg32527.html > > Sakari Ailus sent a pull request for Linux 3.1, so the patches should get > there soon. Yeah, that's my expectation as well unless there are further issues found with them. Mauro? :-) Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- 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: v4l2 api for flash drivers
Hi Andy, On Thursday 30 June 2011 12:55:10 Andy Shevchenko wrote: > Hello. > > I didn't see the patchset [1] in any public tree on git.kernel.org. Is > this patch going to be pushed? > > [1] http://www.spinics.net/lists/linux-media/msg32527.html Sakari Ailus sent a pull request for Linux 3.1, so the patches should get there soon. -- 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
v4l2 api for flash drivers
Hello. I didn't see the patchset [1] in any public tree on git.kernel.org. Is this patch going to be pushed? [1] http://www.spinics.net/lists/linux-media/msg32527.html -- Andy Shevchenko Intel Finland Oy -- 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: [git:xawtv3/master] xawtv: reenable its usage with webcam's
Hi,
On 06/29/2011 09:27 PM, Mauro Carvalho Chehab wrote:
Anyway, it is fixed. I also made scantv to force for a TV device at auto mode,
as it
doesn't sense to scan for TV channels on devices without tuner.
Thanks for fixing this, 2 remarks wrt the auto patch for
scantv:
1) This bit should be #ifdef __linux__ since we only support
auto* on linux because of the sysfs dep:
@@ -149,6 +149,9 @@ main(int argc, char **argv)
/* parse options */
ng_init();
+/* Autodetect devices */
+ng_dev.video = "auto_tv";
+
for (;;) {
if (-1 == (c = getopt(argc, argv, "hsadi:n:f:o:c:C:D:")))
break;
2) The added return NULL in case no device can be found lacks
printing an error message:
@@ -568,6 +569,8 @@ static void *ng_vid_open_auto(struct ng_vid_driver *drv,
char *devpath)
/* Step 2: try grabber devices and webcams */
if (!handle) {
+ if (!allow_grabber)
+ return NULL;
device = NULL;
while (1) {
device = get_associated_device(md, device, MEDIA_V4L_VIDEO, NULL,
NONE);
I propose changing the return NULL, with a goto to the error print further down.
From my side, I don't intend to touch on xawtv any time soon. So, maybe we can
wait
for a couple days and release version 1.101.
Assuming the 2 things mentioned above get fixed that sounds like a good plan to
me.
Regards,
Hans
--
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
tm6000 hangs after starting playback
Hi, I have a piece of software that uses libvlc to playback analog video using V4L2. When stress-testing the software by repeatedly starting and stopping playback, the device I use (TerraTec Cinergy Hybrid Stick [0ccd:00a5]) goes into a very strange state, where it hangs when dequeuing a buffer. This is to where I traced the problem: videobuf_dqbuf() -> stream_next_buffer() -> videobuf_waiton() -> wait_event_interruptible() When the device enters this particular state, the vb->done wait queue is never woken. I was able to trace the cause of that further down to a problem with ISOC transfers from the device no longer working properly: tm6000_irq_callback() -> tm6000_isoc_copy() In this particular state, *all* ISO packet descriptors report an actual transfer length of 0. This in turn seems to be the reason why the wait queue is never woken (buffer_filled() is never called). I've tried to unload and reload the tm6000 module when this issue occurs, but that doesn't help. The problem persists the next time playback is started. The only thing that seems to help is disconnecting and reconnecting the device or, alternatively, reset the USB device using the USBDEVFS_RESET ioctl. I'm wondering whether this is a known problem, or if there is anything I can do to help track this down further. Cheers, Thierry pgpl0ZN4VPR2r.pgp Description: PGP signature
prompt ISP CCDC freeze-up on STREAMON
---
yavta.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/yavta.c b/yavta.c
index 2a166c6..95976b4 100644
--- a/yavta.c
+++ b/yavta.c
@@ -485,7 +485,9 @@ static int video_enable(struct device *dev, int enable)
int type = dev->type;
int ret;
+ printf("+%s\n", enable ? "STREAMON" : "STREAMOFF");
ret = ioctl(dev->fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF,
&type);
+ printf("-%s\n", enable ? "STREAMON" : "STREAMOFF");
if (ret < 0) {
printf("Unable to %s streaming: %d.\n", enable ? "start" :
"stop",
errno);
@@ -1063,6 +1065,7 @@ int main(int argc, char *argv[])
{
struct device dev;
int ret;
+ int i;
/* Options parsings */
int do_file = 0, do_capture = 0, do_pause = 0;
@@ -1259,6 +1262,9 @@ int main(int argc, char *argv[])
video_enum_inputs(&dev);
}
+ for (i=0; i<100; i++) {
+ printf(" %d \n", i);
+
if (do_set_input) {
video_set_input(&dev, input);
ret = video_get_input(&dev);
@@ -1313,6 +1319,8 @@ int main(int argc, char *argv[])
return 1;
}
+ }
+
video_close(&dev);
return 0;
}
--
1.7.5.4
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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
ISP CCDC freeze-up on STREAMON
Hi Laurent, I'm observing a system freeze-up with the ISP when writing data to memory directly from the ccdc. Here's the sequence I'm using: 0. apply the patch I'm sending separate in this thread. 1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY directly from the sensor to memory. 2. yavta -c10 /dev/video2 The patch is pretty self-explanatory. It introduces a loop (with ugly indenting to keep the patch simple) with 100 iterations leaving the device open between them. My system usually hangs up within the first 30 iterations. I've never made it to 100 successfully. I see the same behavior with user pointers and with mmap, but I don't see it when using data from the previewer. Can you please try this out with your setup? Even if you can't get 8-bit gray data from your sensor, hopefully you could observe it with any other format directly from the CCDC. I'll postpone further discussion until you confirm that you can reproduce the behavior. As the patch illustrates, it looks like it is hanging up in STREAMON. -Michael Michael Jones (1): prompt ISP CCDC freeze-up on STREAMON yavta.c |8 1 files changed, 8 insertions(+), 0 deletions(-) -- 1.7.5.4 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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
