[RESEND][PATCH 2/2] media: v4l2-mem2mem: return for polling if a buffer is available
The v4l2_m2m_poll() does not need to wait if there is already a buffer in done_list of source and destination queues, but current v4l2_m2m_poll() always waits. So done_list of each queue is checked before calling poll_wait(). Signed-off-by: Seung-Woo Kim Acked-by: Marek Szyprowski --- drivers/media/v4l2-core/v4l2-mem2mem.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 66f599f..9ac39b5 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -486,8 +486,10 @@ unsigned int v4l2_m2m_poll(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, if (m2m_ctx->m2m_dev->m2m_ops->unlock) m2m_ctx->m2m_dev->m2m_ops->unlock(m2m_ctx->priv); - poll_wait(file, &src_q->done_wq, wait); - poll_wait(file, &dst_q->done_wq, wait); + if (list_empty(&src_q->done_list)) + poll_wait(file, &src_q->done_wq, wait); + if (list_empty(&dst_q->done_list)) + poll_wait(file, &dst_q->done_wq, wait); if (m2m_ctx->m2m_dev->m2m_ops->lock) m2m_ctx->m2m_dev->m2m_ops->lock(m2m_ctx->priv); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 1/2] media: vb2: return for polling if a buffer is available
The vb2_poll() does not need to wait next vb_buffer_done() if there is already a buffer in done_list of queue, but current vb2_poll() always waits. So done_list is checked before calling poll_wait(). Signed-off-by: Seung-Woo Kim Acked-by: Marek Szyprowski --- drivers/media/v4l2-core/videobuf2-core.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 7d833ee..e3bdc3b 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2014,7 +2014,8 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) if (list_empty(&q->queued_list)) return res | POLLERR; - poll_wait(file, &q->done_wq, wait); + if (list_empty(&q->done_list)) + poll_wait(file, &q->done_wq, wait); /* * Take first buffer available for dequeuing. -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 0/2] media: fix polling not to wait if a buffer is available
As poll behavior described in following link, polling needs to just return if already some buffer is in done list. Link: http://www.spinics.net/lists/linux-media/msg34759.html But in current vb2 and v4l2_m2m, poll function always calls poll_wait(), so it needs to wait until next vb2_buffer_done() or queue is cancelled. So I add check routine for done_list before calling poll_wait(). But I'm not sure that locking for done_lock of queue is also needed in this case or not because done_list of queue is checked without locking in some other parts of vb2. Seung-Woo Kim (2): media: vb2: return for polling if a buffer is available media: v4l2-mem2mem: return for polling if a buffer is available drivers/media/v4l2-core/v4l2-mem2mem.c |6 -- drivers/media/v4l2-core/videobuf2-core.c |3 ++- 2 files changed, 6 insertions(+), 3 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] libv4l2rds: added support to decode RDS-TMC tuning information
Hi Hans,
Thank you for your comments, they're very appreciated as always :)
I will integrate the proposals and submit an updated version towards
the end of this week.
To my best knowledge I would say that the functionality of RDS/TMC as
defined by the standards is completely implemented now.
And I agree that human readable output for the TMC messages would be
nice to have, but I'm quite busy with my thesis atm and will not make
any promises ;)
Cheers,
Konke
On Fri, May 10, 2013 at 12:46 PM, Hans Verkuil wrote:
> On Tue May 7 2013 18:24:22 Konke Radlow wrote:
>> Signed-off-by: Konke Radlow
>> ---
>> lib/include/libv4l2rds.h| 39 +++
>> lib/libv4l2rds/libv4l2rds.c | 159
>> +--
>> 2 files changed, 194 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
>> index 62b28bc..45dc2d1 100644
>> --- a/lib/include/libv4l2rds.h
>> +++ b/lib/include/libv4l2rds.h
>> @@ -50,6 +50,10 @@ extern "C" {
>> * Additional data is limited to 112 bit, and the
>> smallest
>> * optional tuple has a size of 4 bit (4 bit identifier
>> +
>> * 0 bits of data) */
>> +#define MAX_TMC_ALT_STATIONS 32 /* defined by ISO 14819-1:2003, 7.5.3.3 */
>> +#define MAX_TMC_AF_CNT 4 /* limit for the numbers of AFs stored per
>> alternative TMC
>> + * station. This value is not defined by the standard,
>> but based on observation
>> + * of real-world RDS-TMC streams */
>
> Could you clarify this a bit more? E.g. what is the maximum number of AFs you
> have seen in practice?
>
>> #define MAX_EON_CNT 20 /* Maximal number of entries in the EON table
>> (for storing
>> * information about other radio stations, broadcasted
>> * by the current station) */
>> @@ -75,6 +79,7 @@ extern "C" {
>> #define V4L2_RDS_TMC_SYS 0x1 /* RDS-TMC system information */
>> #define V4L2_RDS_EON 0x2 /* Enhanced Other Network Info */
>> #define V4L2_RDS_LSF 0x4 /* Linkage information */
>> +#define V4L2_RDS_TMC_TUNING 0x8 /* RDS-TMC tuning information */
>>
>> /* Define Constants for the state of the RDS decoding process
>> * used to address the relevant bit in the decode_information bitmask */
>> @@ -175,6 +180,37 @@ struct v4l2_rds_eon_set {
>>* radio channels */
>> };
>>
>> +/* struct to encapsulate alternative frequencies (AFs) for RDS-TMC stations.
>> + * AFs listed in af[] can be used unconditionally.
>> + * AFs listed in mapped_af[n] should only be used if the current
>> + * tuner frequency matches the value in mapped_af_tuning[n] */
>> +struct v4l2_tmc_alt_freq {
>> + uint8_t af_size;/* number of known AFs */
>> + uint8_t af_index;
>> + uint8_t mapped_af_size; /* number of mapped AFs */
>> + uint8_t mapped_af_index;
>> + uint32_t af[MAX_TMC_AF_CNT];/* AFs defined in Hz */
>> + uint32_t mapped_af[MAX_TMC_AF_CNT]; /* mapped AFs defined
>> in Hz */
>> + uint32_t mapped_af_tuning[MAX_TMC_AF_CNT]; /* mapped AFs defined
>> in Hz */
>> +};
>> +
>> +/* struct to encapsulate information about stations carrying RDS-TMC
>> services */
>> +struct v4l2_tmc_station {
>> + uint16_t pi;
>> + uint8_t ltn;/* database-ID of ON */
>> + uint8_t msg;/* msg parameters of ON */
>> + uint8_t sid;/* service-ID of ON */
>> + struct v4l2_tmc_alt_freq afi;
>> +};
>> +
>> +/* struct to encapsulate tuning information for TMC */
>> +struct v4l2_tmc_tuning {
>> + uint8_t station_cnt;/* number of announced alternative stations */
>> + uint8_t index;
>> + struct v4l2_tmc_station station[MAX_TMC_ALT_STATIONS]; /* information
>> + * about other stations
>> carrying the same RDS-TMC service */
>> +};
>> +
>> /* struct to encapsulate an additional data field in a TMC message */
>> struct v4l2_tmc_additional {
>> uint8_t label;
>> @@ -225,6 +261,9 @@ struct v4l2_rds_tmc {
>> uint8_t t_d;/* delay time (only if mode = enhanced */
>> uint8_t spn[9]; /* service provider name */
>> struct v4l2_rds_tmc_msg tmc_msg;
>> +
>> + /* tuning information for alternative service providers */
>> + struct v4l2_tmc_tuning tuning;
>> };
>>
>> /* struct to encapsulate state and RDS information for current decoding
>> process */
>> diff --git a/lib/libv4l2rds/libv4l2rds.c b/lib/libv4l2rds/libv4l2rds.c
>> index 3a90a3b..3995c3d 100644
>> --- a/lib/libv4l2rds/libv4l2rds.c
>> +++ b/lib/libv4l2rds/libv4l2rds.c
>> @@ -93,7 +93,9 @@ enum rds_state {
>> };
>>
>> /* function declarations to prevent the need to move large code blocks */
>> +static int rds_add_tmc_station(struct rds_private_state *priv_state,
>> uint16_t pi);
>> stat
Re: Kernel freezing with RTL2832U+R820T
On 20.05.2013 13:52, Karsten Malcher wrote: > Does this mean that it should work with Kernel 3.8.5 ? Honestly I don't know. Regarding 3.8.y kernel series[1]. poma [1] http://www.spinics.net/lists/kernel/msg1531126.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: Introduce a new helper framework for buffer synchronization
On Mon, May 20, 2013 at 11:13:04PM +0200, Daniel Vetter wrote: > On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote: > > 2013/5/15 Rob Clark > > > > > On Wed, May 15, 2013 at 1:19 AM, Inki Dae wrote: > > > > > > > > > > > >> -Original Message- > > > >> From: Rob Clark [mailto:robdcl...@gmail.com] > > > >> Sent: Tuesday, May 14, 2013 10:39 PM > > > >> To: Inki Dae > > > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; > > > >> YoungJun > > > >> Cho; linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org > > > >> Subject: Re: Introduce a new helper framework for buffer > > > >> synchronization > > > >> > > > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae > > > wrote: > > > >> >> well, for cache management, I think it is a better idea.. I didn't > > > >> >> really catch that this was the motivation from the initial patch, > > > >> >> but > > > >> >> maybe I read it too quickly. But cache can be decoupled from > > > >> >> synchronization, because CPU access is not asynchronous. For > > > >> >> userspace/CPU access to buffer, you should: > > > >> >> > > > >> >> 1) wait for buffer > > > >> >> 2) prepare-access > > > >> >> 3) ... do whatever cpu access to buffer ... > > > >> >> 4) finish-access > > > >> >> 5) submit buffer for new dma-operation > > > >> >> > > > >> > > > > >> > > > > >> > For data flow from CPU to DMA device, > > > >> > 1) wait for buffer > > > >> > 2) prepare-access (dma_buf_begin_cpu_access) > > > >> > 3) cpu access to buffer > > > >> > > > > >> > > > > >> > For data flow from DMA device to CPU > > > >> > 1) wait for buffer > > > >> > > > >> Right, but CPU access isn't asynchronous (from the point of view of > > > >> the CPU), so there isn't really any wait step at this point. And if > > > >> you do want the CPU to be able to signal a fence from userspace for > > > >> some reason, you probably what something file/fd based so the > > > >> refcnting/cleanup when process dies doesn't leave some pending DMA > > > >> action wedged. But I don't really see the point of that complexity > > > >> when the CPU access isn't asynchronous in the first place. > > > >> > > > > > > > > There was my missing comments, please see the below sequence. > > > > > > > > For data flow from CPU to DMA device and then from DMA device to CPU, > > > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...) > > > > - including prepare-access (dma_buf_begin_cpu_access) > > > > 2) cpu access to buffer > > > > 3) wait for buffer <- at device driver > > > > - but CPU is already accessing the buffer so blocked. > > > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...) > > > > 5) the thread, blocked at 3), is waked up by 4). > > > > - and then finish-access (dma_buf_end_cpu_access) > > > > > > right, I understand you can have background threads, etc, in > > > userspace. But there are already plenty of synchronization primitives > > > that can be used for cpu->cpu synchronization, either within the same > > > process or between multiple processes. For cpu access, even if it is > > > handled by background threads/processes, I think it is better to use > > > the traditional pthreads or unix synchronization primitives. They > > > have existed forever, they are well tested, and they work. > > > > > > So while it seems nice and orthogonal/clean to couple cache and > > > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the > > > same generic way, but I think in practice we have to make things more > > > complex than they otherwise need to be to do this. Otherwise I think > > > we'll be having problems with badly behaved or crashing userspace. > > > > > > > > Right, this is very important. I think it's not esay to solve this > > issue. Aand at least for ARM based embedded system, such feature is useful > > to us; coupling cache operation and buffer synchronization. I'd like to > > collect other opinions and advices to solve this issue. > > Maybe we have a bit a misunderstanding here. The kernel really should take > care of sync and cache coherency, and I agree that with the current > dma_buf code (and the proposed fences) that part is still a bit hazy. But > the kernel should not allow userspace to block access to a buffer until > userspace is done. It should only sync with any oustanding fences and > flush buffers before that userspace access happens. > > Then the kernel would again flush caches on the next dma access (which > hopefully is only started once userspace completed access). Atm this isn't > possible in an efficient way since the dma_buf api only exposes map/unmap > attachment and not a function to just sync an existing mapping like > dma_sync_single_for_device. I guess we should add a > dma_buf_sync_attachment interface for that - we already have range-based > cpu sync support with the begin/end_cpu_access interfaces. I think my mail here was a bit unclear, so let me try to rephrase. Re-rea
Re: Can you take a look at these dvb-apps warnings/errors?
Hi Hans, Em Fri, 17 May 2013 10:30:57 +0200 Hans Verkuil escreveu: > Hi Mauro, > > Can you take a look at these? The daily build is failing because of this. > > Thanks! > > Hans > > test_video.c:322:2: warning: format ‘%d’ expects argument of type ‘int’, but > argument 2 has type ‘ssize_t’ [-Wformat] > dvbscan.c:128:6: warning: variable ‘output_type’ set but not used > [-Wunused-but-set-variable] > dvbscan.c:126:6: warning: variable ‘uk_ordering’ set but not used > [-Wunused-but-set-variable] > dvbscan.c:124:32: warning: variable ‘inversion’ set but not used > [-Wunused-but-set-variable] > dvbscan_dvb.c:27:44: warning: unused parameter ‘fe’ [-Wunused-parameter] > dvbscan_atsc.c:27:45: warning: unused parameter ‘fe’ [-Wunused-parameter] > util.c:193:7: error: ‘SYS_DVBC_ANNEX_A’ undeclared (first use in this > function) > util.c:194:7: error: ‘SYS_DVBC_ANNEX_C’ undeclared (first use in this > function) > util.c:262:26: error: ‘DTV_ENUM_DELSYS’ undeclared (first use in this > function) > util.c:263:1: warning: control reaches end of non-void function > [-Wreturn-type] > make[2]: *** [util.o] Error 1 > make[1]: *** [all] Error 2 > make: *** [all] Error 2 I'm not touching on dvb-apps for a long time. From my side, all I need in terms of userspace apps for DVB is there at dvbv5/libdvbv5 on v4l-utils. That's said, from the above errors, it seems that it got added (partial) support for DVB v5 but, somehow, it is compiling with an older dvb/frontend.h header on your build. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Introduce a new helper framework for buffer synchronization
On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote: > 2013/5/15 Rob Clark > > > On Wed, May 15, 2013 at 1:19 AM, Inki Dae wrote: > > > > > > > > >> -Original Message- > > >> From: Rob Clark [mailto:robdcl...@gmail.com] > > >> Sent: Tuesday, May 14, 2013 10:39 PM > > >> To: Inki Dae > > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun > > >> Cho; linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org > > >> Subject: Re: Introduce a new helper framework for buffer synchronization > > >> > > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae > > wrote: > > >> >> well, for cache management, I think it is a better idea.. I didn't > > >> >> really catch that this was the motivation from the initial patch, but > > >> >> maybe I read it too quickly. But cache can be decoupled from > > >> >> synchronization, because CPU access is not asynchronous. For > > >> >> userspace/CPU access to buffer, you should: > > >> >> > > >> >> 1) wait for buffer > > >> >> 2) prepare-access > > >> >> 3) ... do whatever cpu access to buffer ... > > >> >> 4) finish-access > > >> >> 5) submit buffer for new dma-operation > > >> >> > > >> > > > >> > > > >> > For data flow from CPU to DMA device, > > >> > 1) wait for buffer > > >> > 2) prepare-access (dma_buf_begin_cpu_access) > > >> > 3) cpu access to buffer > > >> > > > >> > > > >> > For data flow from DMA device to CPU > > >> > 1) wait for buffer > > >> > > >> Right, but CPU access isn't asynchronous (from the point of view of > > >> the CPU), so there isn't really any wait step at this point. And if > > >> you do want the CPU to be able to signal a fence from userspace for > > >> some reason, you probably what something file/fd based so the > > >> refcnting/cleanup when process dies doesn't leave some pending DMA > > >> action wedged. But I don't really see the point of that complexity > > >> when the CPU access isn't asynchronous in the first place. > > >> > > > > > > There was my missing comments, please see the below sequence. > > > > > > For data flow from CPU to DMA device and then from DMA device to CPU, > > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...) > > > - including prepare-access (dma_buf_begin_cpu_access) > > > 2) cpu access to buffer > > > 3) wait for buffer <- at device driver > > > - but CPU is already accessing the buffer so blocked. > > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...) > > > 5) the thread, blocked at 3), is waked up by 4). > > > - and then finish-access (dma_buf_end_cpu_access) > > > > right, I understand you can have background threads, etc, in > > userspace. But there are already plenty of synchronization primitives > > that can be used for cpu->cpu synchronization, either within the same > > process or between multiple processes. For cpu access, even if it is > > handled by background threads/processes, I think it is better to use > > the traditional pthreads or unix synchronization primitives. They > > have existed forever, they are well tested, and they work. > > > > So while it seems nice and orthogonal/clean to couple cache and > > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the > > same generic way, but I think in practice we have to make things more > > complex than they otherwise need to be to do this. Otherwise I think > > we'll be having problems with badly behaved or crashing userspace. > > > > > Right, this is very important. I think it's not esay to solve this > issue. Aand at least for ARM based embedded system, such feature is useful > to us; coupling cache operation and buffer synchronization. I'd like to > collect other opinions and advices to solve this issue. Maybe we have a bit a misunderstanding here. The kernel really should take care of sync and cache coherency, and I agree that with the current dma_buf code (and the proposed fences) that part is still a bit hazy. But the kernel should not allow userspace to block access to a buffer until userspace is done. It should only sync with any oustanding fences and flush buffers before that userspace access happens. Then the kernel would again flush caches on the next dma access (which hopefully is only started once userspace completed access). Atm this isn't possible in an efficient way since the dma_buf api only exposes map/unmap attachment and not a function to just sync an existing mapping like dma_sync_single_for_device. I guess we should add a dma_buf_sync_attachment interface for that - we already have range-based cpu sync support with the begin/end_cpu_access interfaces. Yours, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: saa7115/gm7113c - device specific initialization
Em Mon, 20 May 2013 18:20:44 +0200 Jon Arne Jørgensen escreveu: > On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: > > "Jon Arne Jørgensen" wrote: > > > > >Hi, > > >I've recently discovered that the smi2021 device have some pretty > > >specific > > >needs for the setup of the gm7113c chip. > > > > > >Both the smi2021 driver and the stk1160 driver needs registers > > >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c > > >chip to the saa7115 driver in the first place. > > > > > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the > > >initial register settings to be changed for the device to work. > > >He posted a small list of required changes. > > >One of these changes is a change to register 0x12 which sets > > >up what to output on the RTS0 pin on the chip. > > > > > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV > > >to be generated by VREF - whatever that means :). > > >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10. > > >To have the device behave correctly. > > > > > >Both the change for the smi2021 driver and the changes for the Terratec > > >device are pretty hardware specific. > > >They should probably not be part of the generic gm7113c setup. > > > > > >I would also guess that if other devices with the gm7113c chip should > > >surface, these devices might also have different needs for the setup of > > >the chip. > > > > > >I'm not sure what would be the correct way to handle these > > >differences. > > >The only sollution I'we tried is to bypass the saa7115 > > >driver, and push the needed changes directly over usb to the device, > > >after the initial setup is sent by the saa7115 driver. > > >This is a major hack, and the changes should probably go through > > >the saa7115 driver. > > > > > >Should the saa7115 driver be extended with an interface to change > > >random > > >register settings, or does the i2c subsystem already have a way to > > >handle this? > > > > > >Any idea about what might could be a better sollution? > > > > > >Best regards > > >Jon Arne Jørgensen > > > > > >-- > > >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 > > > > For v4l2_subdev's there is a way to pass in platform/bridge device specific > > data so initialization can be different than the default, based on the > > needs of the bridge driver. > > Ok, can you give any pointers to any documentation/source files I can > look at for this? Look, for example, at drivers/media/i2c/mt9v011.c. At mt9v011_probe, it checks if c->dev.platform_data exists. If so, it changes the xtal frequency to the one specified by the driver. -- 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: [PATCH v3] adv7180: add more subdev video ops
Hello.
On 05/13/2013 11:21 PM, Sergei Shtylyov wrote:
From: Vladimir Barinov
Add subdev video ops for ADV7180 video decoder. This makes decoder usable on
the soc-camera drivers.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
Hans, what's your opinion of this version? Mauro said I should ask
you first...
---
This patch is against the 'media_tree.git' repo.
Changes from version 2:
- set the field format depending on video standard in try_mbus_fmt() method;
- removed querystd() method calls from try_mbus_fmt() and cropcap() methods;
- removed g_crop() method.
drivers/media/i2c/adv7180.c | 86
1 file changed, 86 insertions(+)
Index: media_tree/drivers/media/i2c/adv7180.c
===
--- media_tree.orig/drivers/media/i2c/adv7180.c
+++ media_tree/drivers/media/i2c/adv7180.c
@@ -1,6 +1,8 @@
/*
* adv7180.c Analog Devices ADV7180 video decoder driver
* Copyright (c) 2009 Intel Corporation
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Solutions Corp.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -128,6 +130,7 @@ struct adv7180_state {
v4l2_std_id curr_norm;
boolautodetect;
u8 input;
+ struct v4l2_mbus_framefmt fmt;
};
#define to_adv7180_sd(_ctrl) (&container_of(_ctrl->handler,\
struct adv7180_state, \
@@ -397,10 +400,93 @@ static void adv7180_exit_controls(struct
v4l2_ctrl_handler_free(&state->ctrl_hdl);
}
+static int adv7180_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned int index,
+enum v4l2_mbus_pixelcode *code)
+{
+ if (index > 0)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+
+ return 0;
+}
+
+static int adv7180_try_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ struct adv7180_state *state = to_state(sd);
+
+ fmt->code = V4L2_MBUS_FMT_YUYV8_2X8;
+ fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ fmt->field = state->curr_norm & V4L2_STD_525_60 ?
+V4L2_FIELD_INTERLACED_BT : V4L2_FIELD_INTERLACED_TB;
+ fmt->width = 720;
+ fmt->height = state->curr_norm & V4L2_STD_525_60 ? 480 : 576;
+
+ return 0;
+}
+
+static int adv7180_g_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ struct adv7180_state *state = to_state(sd);
+
+ *fmt = state->fmt;
+
+ return 0;
+}
+
+static int adv7180_s_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ struct adv7180_state *state = to_state(sd);
+
+ adv7180_try_mbus_fmt(sd, fmt);
+ state->fmt = *fmt;
+
+ return 0;
+}
+
+static int adv7180_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap *a)
+{
+ struct adv7180_state *state = to_state(sd);
+
+ a->bounds.left = 0;
+ a->bounds.top = 0;
+ a->bounds.width = 720;
+ a->bounds.height = state->curr_norm & V4L2_STD_525_60 ? 480 : 576;
+ a->defrect = a->bounds;
+ a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ a->pixelaspect.numerator = 1;
+ a->pixelaspect.denominator = 1;
+
+ return 0;
+}
+
+static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
+struct v4l2_mbus_config *cfg)
+{
+ /*
+* The ADV7180 sensor supports BT.601/656 output modes.
+* The BT.656 is default and not yet configurable by s/w.
+*/
+ cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
+V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg->type = V4L2_MBUS_BT656;
+
+ return 0;
+}
+
static const struct v4l2_subdev_video_ops adv7180_video_ops = {
.querystd = adv7180_querystd,
.g_input_status = adv7180_g_input_status,
.s_routing = adv7180_s_routing,
+ .enum_mbus_fmt = adv7180_enum_mbus_fmt,
+ .try_mbus_fmt = adv7180_try_mbus_fmt,
+ .g_mbus_fmt = adv7180_g_mbus_fmt,
+ .s_mbus_fmt = adv7180_s_mbus_fmt,
+ .cropcap = adv7180_cropcap,
+ .g_mbus_config = adv7180_g_mbus_config,
};
static const struct v4l2_subdev_core_ops adv7180_core_ops = {
WBR, Sergei
--
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: InstantFM
On 05/20/2013 11:42 AM, Ted To wrote: > Hi, > > On 05/20/2013 02:55 AM, Hans de Goede wrote: >> Hi, >> >> On 05/19/2013 10:18 PM, Ted To wrote: >>> Hi, >>> >>> I purchased this device and while the device driver loads and I can set >>> up gnomeradio to access it, it picks up no radio stations, despite being >>> the model with an external antenna. The log output says "software >>> version 0, hardware version 7". I'm running Debian Wheezy and the >>> output from dmesg is: >>> >>> [66842.724036] usb 2-3: new full-speed USB device number 3 using ohci_hcd >>> [66842.936144] usb 2-3: New USB device found, idVendor=06e1, >>> idProduct=a155 >>> [66842.936150] usb 2-3: New USB device strings: Mfr=1, Product=2, >>> SerialNumber=0 >>> [66842.936154] usb 2-3: Product: ADS InstantFM Music >>> [66842.936156] usb 2-3: Manufacturer: ADS TECH >>> [66843.275730] Linux media interface: v0.10 >>> [66843.296811] Linux video capture interface: v2.00 >>> [66843.321815] USB radio driver for Si470x FM Radio Receivers, Version >>> 1.0.10 >>> [66843.323136] radio-si470x 2-3:1.2: DeviceID=0x ChipID=0x >>> [66843.326127] radio-si470x 2-3:1.2: software version 0, hardware >>> version 7 >>> [66843.326131] radio-si470x 2-3:1.2: This driver is known to work with >>> software version 7, >>> [66843.326135] radio-si470x 2-3:1.2: but the device has software >>> version 0. >>> [66843.326138] radio-si470x 2-3:1.2: If you have some trouble using this >>> driver, >>> [66843.326141] radio-si470x 2-3:1.2: please report to V4L ML at >>> linux-media@vger.kernel.org >>> [66843.338247] usbcore: registered new interface driver radio-si470x >>> [66843.407477] usbcore: registered new interface driver snd-usb-audio >>> >>> Any help on what I need to do to get this working would be much >>> appreciated. >> >> Can you try with the (console-based) radio app from the latest xawtv >> release, >> xawtv-3.103 ? > >> gnomeradio is not being actively maintained, so it could be your just >> hitting >> a gnomeradio issue. >> >> Regards, >> >> Hans > > > I had tried "radio" from the debian repository (version 3.102) but sadly > it did not work. I also tried 3.103 from the sid repository and I get > the following error: > > Invalid freq '13865'. Current freq out of range? > > I can get it to start if I use the "-s" option but still, nothing plays. > Moreover, if I give it a specific frequency, it does not start at that > frequency. > > Could the problem be that my device does not have version 7 of the > firmware? Google has not been helpful regarding how this can be upgraded. > > Thanks, > Ted Actually, playing around with it some more (the version in the stable repository), it appears to be picking something up. "radio -s" produces the following: $ radio -s baseline at 1.00 Station 0: 88.10 MHz - 4.00 Station 1: 88.90 MHz - 3.00 Station 2: 89.70 MHz - 2.00 Station 3: 91.50 MHz - 2.00 Station 4: 92.35 MHz - 3.00 Station 5: 93.10 MHz - 3.00 Station 6: 95.10 MHz - 3.00 Station 7: 95.90 MHz - 2.00 Station 8: 97.80 MHz - 4.00 Station 9: 99.10 MHz - 2.00 Station 10: 100.45 MHz - 2.00 Station 11: 101.90 MHz - 2.00 Station 12: 102.70 MHz - 2.00 Station 13: 104.25 MHz - 4.00 Station 14: 105.75 MHz - 3.00 Station 15: 106.50 MHz - 5.00 tuned 88.10 MHz I assume that the last number is a measure of signal strength? The problem is that no sound is produced. FYI, gnomeradio gives a 'Could not open "/dev/mixer"!' error. There seem to be some bugs reported regarding this problem. https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/613809 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon May 20 19:00:20 CEST 2013 git branch: test git hash: 4237c09a63906b980741725da63f85e454caec02 gcc version:i686-linux-gcc (GCC) 4.8.0 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.10-rc1-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.10-rc1-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API 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: saa7115/gm7113c - device specific initialization
"Jon Arne Jørgensen" wrote: >On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: >> "Jon Arne Jørgensen" wrote: >> >> >Hi, >> >I've recently discovered that the smi2021 device have some pretty >> >specific >> >needs for the setup of the gm7113c chip. >> > >> >Both the smi2021 driver and the stk1160 driver needs registers >> >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c >> >chip to the saa7115 driver in the first place. >> > >> >Then Timo reported that the Terratec Grabby hwrev2 needs some of the >> >initial register settings to be changed for the device to work. >> >He posted a small list of required changes. >> >One of these changes is a change to register 0x12 which sets >> >up what to output on the RTS0 pin on the chip. >> > >> >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV >> >to be generated by VREF - whatever that means :). >> >That is, I need bit 7 to be clear and bit 6 to be set in register >0x10. >> >To have the device behave correctly. >> > >> >Both the change for the smi2021 driver and the changes for the >Terratec >> >device are pretty hardware specific. >> >They should probably not be part of the generic gm7113c setup. >> > >> >I would also guess that if other devices with the gm7113c chip >should >> >surface, these devices might also have different needs for the setup >of >> >the chip. >> > >> >I'm not sure what would be the correct way to handle these >> >differences. >> >The only sollution I'we tried is to bypass the saa7115 >> >driver, and push the needed changes directly over usb to the device, >> >after the initial setup is sent by the saa7115 driver. >> >This is a major hack, and the changes should probably go through >> >the saa7115 driver. >> > >> >Should the saa7115 driver be extended with an interface to change >> >random >> >register settings, or does the i2c subsystem already have a way to >> >handle this? >> > >> >Any idea about what might could be a better sollution? >> > >> >Best regards >> >Jon Arne Jørgensen >> > >> >-- >> >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 >> >> For v4l2_subdev's there is a way to pass in platform/bridge device >specific data so initialization can be different than the default, >based on the needs of the bridge driver. > >Ok, can you give any pointers to any documentation/source files I can >look at for this? > >> >> As for the meaning of the V (Vertical) flag in Start Active Video >(SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard >explains that. Basically they are codes embedded in digitized video >rasters horizontal blanking interval that describe the current video >line and delimit their start and end. >> >> The V flag probably means a line in the vertical blanking interval >(VBI), but I can't recall. >> > >I'm sorry, I was a bit quick with that comment. >I know what the SAV/EAV and V-flag is. I just don't know what it means >that the V-flag is >generated by VREF. > >> Regards, >> Andy >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" >in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html http://lxr.free-electrons.com/source/drivers/media/i2c/wm8775.c#L232 The bttv driver, IIRC, has the wm8775 driver initialize differently for the Nova S card. FWIW, the defaults for the wm8775 driver are generally those needed by the ivtv driver. Regards, Andy -- 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 -next] media: fix hdpvr kconfig/build errors
From: Randy Dunlap Fix hdpvr build errors when CONFIG_I2C=m and VIDEO_V4L2=m and VIDEO_HDPVR=y. drivers/built-in.o: In function `hdpvr_disconnect': hdpvr-core.c:(.text+0xef542): undefined reference to `v4l2_device_disconnect' hdpvr-core.c:(.text+0xef57e): undefined reference to `i2c_del_adapter' hdpvr-core.c:(.text+0xef58a): undefined reference to `video_unregister_device' drivers/built-in.o: In function `hdpvr_delete': (.text+0xef5b9): undefined reference to `video_device_release' drivers/built-in.o: In function `hdpvr_probe': hdpvr-core.c:(.text+0xef63a): undefined reference to `v4l2_device_register' hdpvr-core.c:(.text+0xefd97): undefined reference to `i2c_del_adapter' drivers/built-in.o: In function `hdpvr_s_ctrl': hdpvr-video.c:(.text+0xf03c0): undefined reference to `v4l2_ctrl_activate' drivers/built-in.o: In function `hdpvr_device_release': hdpvr-video.c:(.text+0xf0470): undefined reference to `v4l2_device_unregister' hdpvr-video.c:(.text+0xf0479): undefined reference to `v4l2_ctrl_handler_free' hdpvr-video.c:(.text+0xf048f): undefined reference to `i2c_del_adapter' drivers/built-in.o: In function `hdpvr_open': hdpvr-video.c:(.text+0xf0570): undefined reference to `video_devdata' hdpvr-video.c:(.text+0xf057b): undefined reference to `v4l2_fh_init' hdpvr-video.c:(.text+0xf0583): undefined reference to `v4l2_fh_add' drivers/built-in.o: In function `video_drvdata': hdpvr-video.c:(.text+0xf08a0): undefined reference to `video_devdata' drivers/built-in.o: In function `vidioc_s_dv_timings': hdpvr-video.c:(.text+0xf0d34): undefined reference to `v4l_match_dv_timings' drivers/built-in.o: In function `hdpvr_poll': hdpvr-video.c:(.text+0xf1455): undefined reference to `v4l2_ctrl_poll' drivers/built-in.o: In function `hdpvr_release': hdpvr-video.c:(.text+0xf18f6): undefined reference to `v4l2_fh_release' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1be3): undefined reference to `v4l2_ctrl_handler_init_class' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1c19): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1c42): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1c6b): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1cac): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1cd5): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o:(.text+0xf1cfe): more undefined references to `v4l2_ctrl_new_std' follow drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1d75): undefined reference to `v4l2_ctrl_new_std_menu' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1d9e): undefined reference to `v4l2_ctrl_new_std_menu' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1dc3): undefined reference to `v4l2_ctrl_new_std_menu' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1de5): undefined reference to `v4l2_ctrl_new_std_menu' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1e18): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1e4b): undefined reference to `v4l2_ctrl_new_std' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1e90): undefined reference to `v4l2_ctrl_cluster' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1e98): undefined reference to `v4l2_ctrl_handler_setup' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1ec1): undefined reference to `video_device_alloc' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1f85): undefined reference to `__video_register_device' drivers/built-in.o: In function `hdpvr_register_videodev': (.text+0xf1fac): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `hdpvr_register_ir_tx_i2c': (.text+0xf238f): undefined reference to `i2c_new_device' drivers/built-in.o: In function `hdpvr_register_ir_rx_i2c': (.text+0xf2434): undefined reference to `i2c_new_device' drivers/built-in.o: In function `hdpvr_register_i2c_adapter': (.text+0xf2514): undefined reference to `i2c_add_adapter' drivers/built-in.o:(.rodata+0x1b368): undefined reference to `video_ioctl2' drivers/built-in.o:(.rodata+0x1b690): undefined reference to `v4l2_ctrl_log_status' drivers/built-in.o:(.rodata+0x1b6f8): undefined reference to `v4l2_ctrl_subscribe_event' drivers/built-in.o:(.rodata+
Re: saa7115/gm7113c - device specific initialization
On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: > "Jon Arne Jørgensen" wrote: > > >Hi, > >I've recently discovered that the smi2021 device have some pretty > >specific > >needs for the setup of the gm7113c chip. > > > >Both the smi2021 driver and the stk1160 driver needs registers > >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c > >chip to the saa7115 driver in the first place. > > > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the > >initial register settings to be changed for the device to work. > >He posted a small list of required changes. > >One of these changes is a change to register 0x12 which sets > >up what to output on the RTS0 pin on the chip. > > > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV > >to be generated by VREF - whatever that means :). > >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10. > >To have the device behave correctly. > > > >Both the change for the smi2021 driver and the changes for the Terratec > >device are pretty hardware specific. > >They should probably not be part of the generic gm7113c setup. > > > >I would also guess that if other devices with the gm7113c chip should > >surface, these devices might also have different needs for the setup of > >the chip. > > > >I'm not sure what would be the correct way to handle these > >differences. > >The only sollution I'we tried is to bypass the saa7115 > >driver, and push the needed changes directly over usb to the device, > >after the initial setup is sent by the saa7115 driver. > >This is a major hack, and the changes should probably go through > >the saa7115 driver. > > > >Should the saa7115 driver be extended with an interface to change > >random > >register settings, or does the i2c subsystem already have a way to > >handle this? > > > >Any idea about what might could be a better sollution? > > > >Best regards > >Jon Arne Jørgensen > > > >-- > >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 > > For v4l2_subdev's there is a way to pass in platform/bridge device specific > data so initialization can be different than the default, based on the needs > of the bridge driver. Ok, can you give any pointers to any documentation/source files I can look at for this? > > As for the meaning of the V (Vertical) flag in Start Active Video (SAV) / End > Active Video (EAV) markers, the VESA VIP 1.x standard explains that. > Basically they are codes embedded in digitized video rasters horizontal > blanking interval that describe the current video line and delimit their > start and end. > > The V flag probably means a line in the vertical blanking interval (VBI), but > I can't recall. > I'm sorry, I was a bit quick with that comment. I know what the SAV/EAV and V-flag is. I just don't know what it means that the V-flag is generated by VREF. > Regards, > Andy > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.9.2 kernel - IR / em28xx_rc broken?
- Original Message - > No, just because it didn't change it isn't automatically correct. ;) It's Fedora 18's "haupp" keytable - so it must be correct :-). -- 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: InstantFM
Hi, On 05/20/2013 02:55 AM, Hans de Goede wrote: > Hi, > > On 05/19/2013 10:18 PM, Ted To wrote: >> Hi, >> >> I purchased this device and while the device driver loads and I can set >> up gnomeradio to access it, it picks up no radio stations, despite being >> the model with an external antenna. The log output says "software >> version 0, hardware version 7". I'm running Debian Wheezy and the >> output from dmesg is: >> >> [66842.724036] usb 2-3: new full-speed USB device number 3 using ohci_hcd >> [66842.936144] usb 2-3: New USB device found, idVendor=06e1, >> idProduct=a155 >> [66842.936150] usb 2-3: New USB device strings: Mfr=1, Product=2, >> SerialNumber=0 >> [66842.936154] usb 2-3: Product: ADS InstantFM Music >> [66842.936156] usb 2-3: Manufacturer: ADS TECH >> [66843.275730] Linux media interface: v0.10 >> [66843.296811] Linux video capture interface: v2.00 >> [66843.321815] USB radio driver for Si470x FM Radio Receivers, Version >> 1.0.10 >> [66843.323136] radio-si470x 2-3:1.2: DeviceID=0x ChipID=0x >> [66843.326127] radio-si470x 2-3:1.2: software version 0, hardware >> version 7 >> [66843.326131] radio-si470x 2-3:1.2: This driver is known to work with >> software version 7, >> [66843.326135] radio-si470x 2-3:1.2: but the device has software >> version 0. >> [66843.326138] radio-si470x 2-3:1.2: If you have some trouble using this >> driver, >> [66843.326141] radio-si470x 2-3:1.2: please report to V4L ML at >> linux-media@vger.kernel.org >> [66843.338247] usbcore: registered new interface driver radio-si470x >> [66843.407477] usbcore: registered new interface driver snd-usb-audio >> >> Any help on what I need to do to get this working would be much >> appreciated. > > Can you try with the (console-based) radio app from the latest xawtv > release, > xawtv-3.103 ? > gnomeradio is not being actively maintained, so it could be your just > hitting > a gnomeradio issue. > > Regards, > > Hans I had tried "radio" from the debian repository (version 3.102) but sadly it did not work. I also tried 3.103 from the sid repository and I get the following error: Invalid freq '13865'. Current freq out of range? I can get it to start if I use the "-s" option but still, nothing plays. Moreover, if I give it a specific frequency, it does not start at that frequency. Could the problem be that my device does not have version 7 of the firmware? Google has not been helpful regarding how this can be upgraded. Thanks, Ted -- 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: 3.9.2 kernel - IR / em28xx_rc broken?
Am 20.05.2013 16:51, schrieb Chris Rankin: > - Original Message - > >> If I had to guess, I would say you should check your rc_maps.cfg / keytable. >> ;) > This is unchanged between 3.8.x and 3.9.x, and so is correct by definition. No, just because it didn't change it isn't automatically correct. ;) Which protocol type does you keytable specify/select ? It should be RC5. If it's none or unknown, it's just dump luck that things are working (because the driver fortunately configures the device for RC5 in case of RC_BIT_UNKNOWN). > Kernel Upgrades Do Not Break Userspace. Right. That's why I would say the third (scancode) change is problematic. Let's see what Mauro thinks about this. Regards, Frank > Cheers, > Chris > -- 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: 3.9.2 kernel - IR / em28xx_rc broken?
- Original Message - > If I had to guess, I would say you should check your rc_maps.cfg / keytable. > ;) This is unchanged between 3.8.x and 3.9.x, and so is correct by definition. Kernel Upgrades Do Not Break Userspace. Cheers, Chris -- 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 v3 2/3] media: added managed v4l2 control initialization
Hi Sakari,
Thanks for the review.
On 17.05.2013 00:34, Sakari Ailus wrote:
> Hi Andrzej,
>
> Thanks for the patchset!
>
> On Thu, May 16, 2013 at 10:14:33AM +0200, Andrzej Hajda wrote:
>> This patch adds managed version of initialization
>> function for v4l2 control handler.
>>
>> Signed-off-by: Andrzej Hajda
>> Reviewed-by: Sylwester Nawrocki
>> Signed-off-by: Kyungmin Park
>> ---
>> v3:
>> - removed managed cleanup
>> v2:
>> - added missing struct device forward declaration,
>> - corrected few comments
>> ---
>> drivers/media/v4l2-core/v4l2-ctrls.c | 32
>> include/media/v4l2-ctrls.h | 16
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index ebb8e48..f47ccfa 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1421,6 +1421,38 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler
>> *hdl)
>> }
>> EXPORT_SYMBOL(v4l2_ctrl_handler_free);
>>
>> +static void devm_v4l2_ctrl_handler_release(struct device *dev, void *res)
>> +{
>> +struct v4l2_ctrl_handler **hdl = res;
>> +
>> +v4l2_ctrl_handler_free(*hdl);
> v4l2_ctrl_handler_free() acquires hdl->mutex which is independent of the
> existence of hdl. By default hdl->lock is in the handler, but it may also be
> elsewhere, e.g. in a driver-specific device struct such as struct
> smiapp_sensor defined in drivers/media/i2c/smiapp/smiapp.h. I wonder if
> anything guarantees that hdl->mutex still exists at the time the device is
> removed.
IMO in general if somebody provides custom mutex he becomes responsible
for validity of that mutex during v4l2_ctrl_handler usage.
In the particular case of smiapp if we replace v4l2_ctrl_handler_init with
devm version and remove v4l2_ctrl_handler_free calls it seems to be OK:
- mutex is in devm allocated memory chunk acquired at the beginning of
probe,
- mutex is initialized before devm_v4l2_ctrl_handler_init,
- there is no mutex_destroy call - ie the mutex is valid until the
memory is freed,
- memory free is called after v4l2_ctrl_handler_free - devm
'destructors' are
called in order reverse to devm_* 'constructor' calls.
Anyway in cases when devm_* usage would cause errors
we can still use non devm_* versions.
>
> I have to say I don't think it's neither meaningful to acquire that mutex in
> v4l2_ctrl_handler_free(), though, since the whole going to be freed next
> anyway: reference counting would be needed to prevent bad things from
> happening, in case the drivers wouldn't take care of that.
I do not understand what do you mean exactly. Could you please explain
it more?
What do you want to reference count?
Regards
Andrzej
>
>> +}
>> +
--
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: 3.9.2 kernel - IR / em28xx_rc broken?
Am 20.05.2013 15:01, schrieb Chris Rankin: > - Original Message - > >>> And this is me calling ir-keytable: >>> >>> [ 2183.812407] em28xx #0: Changing protocol: rc_type=1 >> So with 3.8 the same happens as with 3.9. > Yes, that does appear to be part of the RC core ABI. > >> Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get >> RC_BIT_UNKNOWN. ;) >> If you expect the device to be configured for another protocol (RC5 ?), >> you need to find out what's going wrong in the RC core and/or ir-keycode. > Are other RCs affected by this? I have difficulty blaming RC core when its > behaviour hasn't changed. If I had to guess, I would say you should check your rc_maps.cfg / keytable. ;) > >> The point is that 3.8 ignores rc_type=1, whereas 3.9 uses it to update a new >> ir->rc_type field - which in turn controls how em2874_polling_getkey() >> encodes its scancode. >> Indeed, since 3.9 >> 1.) em2874_polling_getkey() cares about the rc_type >> 2.) the new rc_type is saved back to ir->rc_type >> >> AFAICS both changes are correct. > Except that given the current ABI, these changes break my RC. No, the change that actually broke your RC is the third change. > >> But there was a third change: >> 3.) the scancode passed to the RC core with rc_keypress() in case of >> RC_BIT_UNKNOWN changed from a 16 bit value to 32 bit value (e.g.: old: 00 00 >> ab cd => new: ab cd xx xx). >> >> Hmm... isn't this an ABI break !? > em28xx only used to support RC5 in 3.8, by the looks of things. ... and NEC. > The behaviour when configured for "RC_BIT_UNKNOWN" would therefore have been > "undefined"... ;-). With both kernels (3.8 and 3.9), the hardware is configured for RC5 when RC_BIT_UNKNOWN is selected. The only thing that changed in the configuration part (apart from the new ir->rc_type field and RC& support) is, that em28xx_ir_change_protocol() used to return -EINVAL for RC_NIT_UNKNOWN and 3.9 now returns 0. But that seems to be no issue here. Regards, Frank > > Cheers, > Chris -- 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 v5] V4L2: soc_camera: Renesas R-Car VIN driver
Hello. On 20-05-2013 11:31, phil.edwor...@renesas.com wrote: Subject: [PATCH v5] V4L2: soc_camera: Renesas R-Car VIN driver From: Vladimir Barinov Add Renesas R-Car VIN (Video In) V4L2 driver. Based on the patch by Phil Edworthy . I've seen old patches that add VIN to the Marzen board, do you have an updated version? The last version of that patchset is 4, here it is archived: http://marc.info/?l=linux-sh&m=136865481429756 http://marc.info/?l=linux-sh&m=136865499029807 http://marc.info/?l=linux-sh&m=136865509129843 http://marc.info/?l=linux-sh&m=136865520029900 Thanks Phil WBR, Sergei -- 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: 3.9.2 kernel - IR / em28xx_rc broken?
- Original Message - >> And this is me calling ir-keytable: >> >> [ 2183.812407] em28xx #0: Changing protocol: rc_type=1 > So with 3.8 the same happens as with 3.9. Yes, that does appear to be part of the RC core ABI. > Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get > RC_BIT_UNKNOWN. ;) > If you expect the device to be configured for another protocol (RC5 ?), > you need to find out what's going wrong in the RC core and/or ir-keycode. Are other RCs affected by this? I have difficulty blaming RC core when its behaviour hasn't changed. > The point is that 3.8 ignores rc_type=1, whereas 3.9 uses it to update a new > ir->rc_type field - which in turn controls how em2874_polling_getkey() > encodes its scancode. > Indeed, since 3.9 > 1.) em2874_polling_getkey() cares about the rc_type > 2.) the new rc_type is saved back to ir->rc_type > > AFAICS both changes are correct. Except that given the current ABI, these changes break my RC. > But there was a third change: > 3.) the scancode passed to the RC core with rc_keypress() in case of > RC_BIT_UNKNOWN changed from a 16 bit value to 32 bit value (e.g.: old: 00 00 > ab cd => new: ab cd xx xx). > > Hmm... isn't this an ABI break !? em28xx only used to support RC5 in 3.8, by the looks of things. The behaviour when configured for "RC_BIT_UNKNOWN" would therefore have been "undefined"... ;-). Cheers, Chris -- 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: 3.9.2 kernel - IR / em28xx_rc broken?
- Original Message -
> This patch seems to "do the right thing"... I doubt it will apply cleanly
> because of TAB/space issues, but you should get the idea :-).
>
> --- linux-3.9/drivers/media/usb/em28xx/em28xx-input.c.orig 2013-05-19
> 21:18:39.0 +0100
> +++ linux-3.9/drivers/media/usb/em28xx/em28xx-input.c 2013-05-20
> 01:36:51.0 +0100
> @@ -417,6 +417,7 @@
> *rc_type = RC_BIT_RC6_0;
> } else if (*rc_type & RC_BIT_UNKNOWN) {
> *rc_type = RC_BIT_UNKNOWN;
> + return 0;
> } else {
> *rc_type = ir->rc_type;
> return -EINVAL;
>
> This is against 3.9.3.
>
> Signed-off-by: Chris Rankin
> No, this patch is wrong.
> Updating ir->rc_type with the new value of *rc_type is correct.
Well, it restores 3.8 behaviour, i.e. em28xx not clobbering its "RC5"
configuration when RC core subsequently calls ir_change_protocol() with
*rc_type=RC_BIT_UNKNOWN. The ir->rc_type parameter is new to 3.9, by the looks
of things.
Cheers,
Chris
--
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: 3.9.2 kernel - IR / em28xx_rc broken?
Am 20.05.2013 14:38, schrieb Frank Schäfer: > ... > But there was a third change: > 3.) the scancode passed to the RC core with rc_keypress() in case of > RC_BIT_UNKNOWN changed from a 16 bit value to 32 bit value (e.g.: old: > 00 00 ab cd => new: ab cd xx xx). See commit 105e3687ada4ebe6dfbda7abc3b16106f86a787d Author: Mauro Carvalho Chehab Date: Sat Dec 15 08:29:11 2012 -0300 [media] em28xx: add support for NEC proto variants on em2874 and upper default_polling_getkey() (em2860/em2880) still returns the 16 bit scancode. Whatever scancode is correct, it should be the same in both cases... Mauro, can you take a look at this ? Regards, Frank -- 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: 3.9.2 kernel - IR / em28xx_rc broken?
Am 20.05.2013 02:45, schrieb Chris Rankin:
> - Original Message -
>
>> I'm not familar with ir-keytable and the RC core.
>> Mauro ? Can you take over ? ;)
> This patch seems to "do the right thing"... I doubt it will apply cleanly
> because of TAB/space issues, but you should get the idea :-).
>
> --- linux-3.9/drivers/media/usb/em28xx/em28xx-input.c.orig2013-05-19
> 21:18:39.0 +0100
> +++ linux-3.9/drivers/media/usb/em28xx/em28xx-input.c2013-05-20
> 01:36:51.0 +0100
> @@ -417,6 +417,7 @@
> *rc_type = RC_BIT_RC6_0;
> } else if (*rc_type & RC_BIT_UNKNOWN) {
> *rc_type = RC_BIT_UNKNOWN;
> +return 0;
> } else {
> *rc_type = ir->rc_type;
> return -EINVAL;
>
> This is against 3.9.3.
>
> Signed-off-by: Chris Rankin
No, this patch is wrong.
Updating ir->rc_type with the new value of *rc_type is correct.
Regards,
Frank
--
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: 3.9.2 kernel - IR / em28xx_rc broken?
Am 20.05.2013 01:04, schrieb Chris Rankin: > - Original Message - > >> What happens with kernel 3.8 ? Does ir-keytable trigger an >> em28xx_ir_change_protocol() call there, too, but with type=8 ? Or is this >> call missing ? > This is the dmesg output from 3.8, with an extra ex28xx_info() call at the > start of em28xx_ir_change_protocol(): > > [ 2149.668729] Em28xx: Initialized (Em28xx dvb Extension) extension > [ 2149.674447] em28xx #0: Changing protocol: rc_type=1 > [ 2149.700087] Registered IR keymap rc-pinnacle-pctv-hd > [ 2149.700444] input: em28xx IR (em28xx #0) as > /devices/pci:00/:00:1d.7/usb5/5-1/rc/rc0/input15 > [ 2149.700655] rc0: em28xx IR (em28xx #0) as > /devices/pci:00/:00:1d.7/usb5/5-1/rc/rc0 > [ 2149.700660] em28xx #0: Changing protocol: rc_type=8 > [ 2149.702337] Em28xx: Initialized (Em28xx Input Extension) extension > [ 2149.704204] em28xx #0: Changing protocol: rc_type=1 > > And this is me calling ir-keytable: > > [ 2183.812407] em28xx #0: Changing protocol: rc_type=1 So with 3.8 the same happens as with 3.9. Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get RC_BIT_UNKNOWN. ;) If you expect the device to be configured for another protocol (RC5 ?), you need to find out what's going wrong in the RC core and/or ir-keycode. > The point is that 3.8 ignores rc_type=1, whereas 3.9 uses it to update a new > ir->rc_type field - which in turn controls how em2874_polling_getkey() > encodes its scancode. Indeed, since 3.9 1.) em2874_polling_getkey() cares about the rc_type 2.) the new rc_type is saved back to ir->rc_type AFAICS both changes are correct. But there was a third change: 3.) the scancode passed to the RC core with rc_keypress() in case of RC_BIT_UNKNOWN changed from a 16 bit value to 32 bit value (e.g.: old: 00 00 ab cd => new: ab cd xx xx). Hmm... isn't this an ABI break !? Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] soc_camera/sh_mobile_csi2: Remove redundant platform_set_drvdata()
On 20 May 2013 17:30, Guennadi Liakhovetski wrote: > On Mon, 20 May 2013, Sachin Kamat wrote: > >> On 13 May 2013 14:49, Sachin Kamat wrote: >> > Commit 0998d06310 (device-core: Ensure drvdata = NULL when no >> > driver is bound) removes the need to set driver data field to >> > NULL. >> > >> > Signed-off-by: Sachin Kamat > > Thanks, both queued for 3.11. Thanks Guennadi :) -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] soc_camera/sh_mobile_csi2: Remove redundant platform_set_drvdata()
On Mon, 20 May 2013, Sachin Kamat wrote: > On 13 May 2013 14:49, Sachin Kamat wrote: > > Commit 0998d06310 (device-core: Ensure drvdata = NULL when no > > driver is bound) removes the need to set driver data field to > > NULL. > > > > Signed-off-by: Sachin Kamat Thanks, both queued for 3.11. Guennadi > > --- > > drivers/media/platform/soc_camera/sh_mobile_csi2.c |8 +--- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/drivers/media/platform/soc_camera/sh_mobile_csi2.c > > b/drivers/media/platform/soc_camera/sh_mobile_csi2.c > > index 09cb4fc..13a1f8f 100644 > > --- a/drivers/media/platform/soc_camera/sh_mobile_csi2.c > > +++ b/drivers/media/platform/soc_camera/sh_mobile_csi2.c > > @@ -340,18 +340,13 @@ static int sh_csi2_probe(struct platform_device *pdev) > > ret = v4l2_device_register_subdev(pdata->v4l2_dev, &priv->subdev); > > dev_dbg(&pdev->dev, "%s(%p): ret(register_subdev) = %d\n", > > __func__, priv, ret); > > if (ret < 0) > > - goto esdreg; > > + return ret; > > > > pm_runtime_enable(&pdev->dev); > > > > dev_dbg(&pdev->dev, "CSI2 probed.\n"); > > > > return 0; > > - > > -esdreg: > > - platform_set_drvdata(pdev, NULL); > > - > > - return ret; > > } > > > > static int sh_csi2_remove(struct platform_device *pdev) > > @@ -360,7 +355,6 @@ static int sh_csi2_remove(struct platform_device *pdev) > > > > v4l2_device_unregister_subdev(&priv->subdev); > > pm_runtime_disable(&pdev->dev); > > - platform_set_drvdata(pdev, NULL); > > > > return 0; > > } > > -- > > 1.7.9.5 > > > > Ping... > > -- > With warm regards, > Sachin > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel freezing with RTL2832U+R820T
Am 20.05.2013 12:55, schrieb poma: On 18.05.2013 09:36, Karsten Malcher wrote: Hi Gianluca, the crash / freezing occurs before disconnect in normal operation. So the patch will not solve this problem. Although media_build/backports allows you to build certain modules for certain older *kernels*, it doesn't mean that these modules will work tuneful within them. Therefore, I recommend the *recent* ones. Take note of last Mauro's git pull[1]. ;) poma [1] http://www.spinics.net/lists/linux-media/msg63181.html Does this mean that it should work with Kernel 3.8.5 ? Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] soc_camera/sh_mobile_csi2: Remove redundant platform_set_drvdata()
On 13 May 2013 14:49, Sachin Kamat wrote: > Commit 0998d06310 (device-core: Ensure drvdata = NULL when no > driver is bound) removes the need to set driver data field to > NULL. > > Signed-off-by: Sachin Kamat > --- > drivers/media/platform/soc_camera/sh_mobile_csi2.c |8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/media/platform/soc_camera/sh_mobile_csi2.c > b/drivers/media/platform/soc_camera/sh_mobile_csi2.c > index 09cb4fc..13a1f8f 100644 > --- a/drivers/media/platform/soc_camera/sh_mobile_csi2.c > +++ b/drivers/media/platform/soc_camera/sh_mobile_csi2.c > @@ -340,18 +340,13 @@ static int sh_csi2_probe(struct platform_device *pdev) > ret = v4l2_device_register_subdev(pdata->v4l2_dev, &priv->subdev); > dev_dbg(&pdev->dev, "%s(%p): ret(register_subdev) = %d\n", __func__, > priv, ret); > if (ret < 0) > - goto esdreg; > + return ret; > > pm_runtime_enable(&pdev->dev); > > dev_dbg(&pdev->dev, "CSI2 probed.\n"); > > return 0; > - > -esdreg: > - platform_set_drvdata(pdev, NULL); > - > - return ret; > } > > static int sh_csi2_remove(struct platform_device *pdev) > @@ -360,7 +355,6 @@ static int sh_csi2_remove(struct platform_device *pdev) > > v4l2_device_unregister_subdev(&priv->subdev); > pm_runtime_disable(&pdev->dev); > - platform_set_drvdata(pdev, NULL); > > return 0; > } > -- > 1.7.9.5 > Ping... -- With warm regards, Sachin -- 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] videodev2.h: fix typos
Hi Prabhakar,
Thank you for the patch.
On Monday 20 May 2013 15:32:40 Lad Prabhakar wrote:
> From: Lad, Prabhakar
>
> This patch fixes several typos in videodev2.h file
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
> ---
> include/uapi/linux/videodev2.h |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index f40b41c..ee4af53 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -555,7 +555,7 @@ struct v4l2_jpegcompression {
> __u32 jpeg_markers; /* Which markers should go into the JPEG
>* output. Unless you exactly know what
>* you do, leave them untouched.
> - * Inluding less markers will make the
> + * Including less markers will make the
>* resulting code smaller, but there will
>* be fewer applications which can read it.
>* The presence of the APP and COM marker
> @@ -567,7 +567,7 @@ struct v4l2_jpegcompression {
> #define V4L2_JPEG_MARKER_DRI (1<<5)/* Define Restart Interval */
> #define V4L2_JPEG_MARKER_COM (1<<6)/* Comment segment */
> #define V4L2_JPEG_MARKER_APP (1<<7)/* App segment, driver will
> - * allways use APP0 */
> + * always use APP0 */
> };
>
> /*
> @@ -900,7 +900,7 @@ typedef __u64 v4l2_std_id;
> /*
> * "Common" PAL - This macro is there to be compatible with the old
> * V4L1 concept of "PAL": /BGDKHI.
> - * Several PAL standards are mising here: /M, /N and /Nc
> + * Several PAL standards are missing here: /M, /N and /Nc
> */
> #define V4L2_STD_PAL (V4L2_STD_PAL_BG|\
>V4L2_STD_PAL_DK|\
> @@ -1790,7 +1790,7 @@ struct v4l2_event_subscription {
> #define V4L2_CHIP_MATCH_HOST V4L2_CHIP_MATCH_BRIDGE
> #define V4L2_CHIP_MATCH_I2C_DRIVER 1 /* Match against I2C driver name */
> #define V4L2_CHIP_MATCH_I2C_ADDR2 /* Match against I2C 7-bit address
> */ -#define V4L2_CHIP_MATCH_AC973 /* Match against anciliary AC97
> chip */ +#define V4L2_CHIP_MATCH_AC973 /* Match against ancillary
> AC97 chip */ #define V4L2_CHIP_MATCH_SUBDEV 4 /* Match against subdev
> index */
>
> struct v4l2_dbg_match {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel freezing with RTL2832U+R820T
On 18.05.2013 09:36, Karsten Malcher wrote: > Hi Gianluca, > > the crash / freezing occurs before disconnect in normal operation. > So the patch will not solve this problem. Although media_build/backports allows you to build certain modules for certain older *kernels*, it doesn't mean that these modules will work tuneful within them. Therefore, I recommend the *recent* ones. Take note of last Mauro's git pull[1]. ;) poma [1] http://www.spinics.net/lists/linux-media/msg63181.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: saa7115/gm7113c - device specific initialization
"Jon Arne Jørgensen" wrote: >Hi, >I've recently discovered that the smi2021 device have some pretty >specific >needs for the setup of the gm7113c chip. > >Both the smi2021 driver and the stk1160 driver needs registers >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c >chip to the saa7115 driver in the first place. > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the >initial register settings to be changed for the device to work. >He posted a small list of required changes. >One of these changes is a change to register 0x12 which sets >up what to output on the RTS0 pin on the chip. > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV >to be generated by VREF - whatever that means :). >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10. >To have the device behave correctly. > >Both the change for the smi2021 driver and the changes for the Terratec >device are pretty hardware specific. >They should probably not be part of the generic gm7113c setup. > >I would also guess that if other devices with the gm7113c chip should >surface, these devices might also have different needs for the setup of >the chip. > >I'm not sure what would be the correct way to handle these >differences. >The only sollution I'we tried is to bypass the saa7115 >driver, and push the needed changes directly over usb to the device, >after the initial setup is sent by the saa7115 driver. >This is a major hack, and the changes should probably go through >the saa7115 driver. > >Should the saa7115 driver be extended with an interface to change >random >register settings, or does the i2c subsystem already have a way to >handle this? > >Any idea about what might could be a better sollution? > >Best regards >Jon Arne Jørgensen > >-- >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 For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver. As for the meaning of the V (Vertical) flag in Start Active Video (SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard explains that. Basically they are codes embedded in digitized video rasters horizontal blanking interval that describe the current video line and delimit their start and end. The V flag probably means a line in the vertical blanking interval (VBI), but I can't recall. Regards, Andy -- 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
saa7115/gm7113c - device specific initialization
Hi, I've recently discovered that the smi2021 device have some pretty specific needs for the setup of the gm7113c chip. Both the smi2021 driver and the stk1160 driver needs registers 0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c chip to the saa7115 driver in the first place. Then Timo reported that the Terratec Grabby hwrev2 needs some of the initial register settings to be changed for the device to work. He posted a small list of required changes. One of these changes is a change to register 0x12 which sets up what to output on the RTS0 pin on the chip. Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV to be generated by VREF - whatever that means :). That is, I need bit 7 to be clear and bit 6 to be set in register 0x10. To have the device behave correctly. Both the change for the smi2021 driver and the changes for the Terratec device are pretty hardware specific. They should probably not be part of the generic gm7113c setup. I would also guess that if other devices with the gm7113c chip should surface, these devices might also have different needs for the setup of the chip. I'm not sure what would be the correct way to handle these differences. The only sollution I'we tried is to bypass the saa7115 driver, and push the needed changes directly over usb to the device, after the initial setup is sent by the saa7115 driver. This is a major hack, and the changes should probably go through the saa7115 driver. Should the saa7115 driver be extended with an interface to change random register settings, or does the i2c subsystem already have a way to handle this? Any idea about what might could be a better sollution? Best regards Jon Arne Jørgensen -- 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] videodev2.h: fix typos
From: Lad, Prabhakar
This patch fixes several typos in videodev2.h file
Signed-off-by: Lad, Prabhakar
---
include/uapi/linux/videodev2.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index f40b41c..ee4af53 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -555,7 +555,7 @@ struct v4l2_jpegcompression {
__u32 jpeg_markers; /* Which markers should go into the JPEG
* output. Unless you exactly know what
* you do, leave them untouched.
-* Inluding less markers will make the
+* Including less markers will make the
* resulting code smaller, but there will
* be fewer applications which can read it.
* The presence of the APP and COM marker
@@ -567,7 +567,7 @@ struct v4l2_jpegcompression {
#define V4L2_JPEG_MARKER_DRI (1<<5)/* Define Restart Interval */
#define V4L2_JPEG_MARKER_COM (1<<6)/* Comment segment */
#define V4L2_JPEG_MARKER_APP (1<<7)/* App segment, driver will
- * allways use APP0 */
+ * always use APP0 */
};
/*
@@ -900,7 +900,7 @@ typedef __u64 v4l2_std_id;
/*
* "Common" PAL - This macro is there to be compatible with the old
* V4L1 concept of "PAL": /BGDKHI.
- * Several PAL standards are mising here: /M, /N and /Nc
+ * Several PAL standards are missing here: /M, /N and /Nc
*/
#define V4L2_STD_PAL (V4L2_STD_PAL_BG|\
V4L2_STD_PAL_DK|\
@@ -1790,7 +1790,7 @@ struct v4l2_event_subscription {
#define V4L2_CHIP_MATCH_HOST V4L2_CHIP_MATCH_BRIDGE
#define V4L2_CHIP_MATCH_I2C_DRIVER 1 /* Match against I2C driver name */
#define V4L2_CHIP_MATCH_I2C_ADDR2 /* Match against I2C 7-bit address */
-#define V4L2_CHIP_MATCH_AC973 /* Match against anciliary AC97 chip */
+#define V4L2_CHIP_MATCH_AC973 /* Match against ancillary AC97 chip */
#define V4L2_CHIP_MATCH_SUBDEV 4 /* Match against subdev index */
struct v4l2_dbg_match {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Sergei, Vladimir, > Subject: [PATCH v5] V4L2: soc_camera: Renesas R-Car VIN driver > > From: Vladimir Barinov > > Add Renesas R-Car VIN (Video In) V4L2 driver. > > Based on the patch by Phil Edworthy . I've seen old patches that add VIN to the Marzen board, do you have an updated version? Thanks Phil -- 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
