Hello Uwe,
On 07/02/2011 10:09 PM, Uwe Kleine-König wrote:
> Hello Sylwester,
>
> thanks for your feedback. A few comments below. For the statements I
> don't reply to, you can consider a "OK, will be fixed in v2".
>
> On Fri, Jul 01, 2011 at 11:20:32PM +0200, Sylwester Nawrocki wrote:
>> On 06/29/2011 09:58 PM, Uwe Kleine-König wrote:
>>> + if (handled& heoimr)
>>> + return IRQ_HANDLED;
>>> + else
>>
>> else could be omitted
> I like the else, but don't care much.
sure, it was purely a personal preference.
>>> + if (rect->left< 0)
>>> + hwxpos = 0;
>>> + else
>>> + hwxpos = rect->left;
>>
>> Could be rewritten as:
>>
>> hwxpos = rect->left< 0 ? 0 : rect->left;
> could even be rewritten as
>
> hwxpos = max(rect->left, 0);
ok, I give up, couldn't make it any simpler;)
>
>>> +static void at91sam9x5_video_vb_wait_prepare(struct vb2_queue *q)
>>> +{
>>> + struct at91sam9x5_video_priv *priv =
>>> + container_of(q, struct at91sam9x5_video_priv, queue);
>>> + unsigned long flags;
>>> +
>>> + debug("cfgupdate=%d hwstate=%d cfgstate=%d\n",
>>> + priv->cfgupdate, priv->hwstate, priv->cfgstate);
>>> + debug("bufs=%p,%p\n", priv->cur.vb, priv->next.vb);
>>> + spin_lock_irqsave(&priv->lock, flags);
>>> +
>>> + at91sam9x5_video_handle_irqstat(priv);
>>> +
>>> + at91sam9x5_video_write32(priv, REG_HEOIER,
>>> + REG_HEOIxR_ADD | REG_HEOIxR_DMA |
>>> + REG_HEOIxR_UADD | REG_HEOIxR_UDMA |
>>> + REG_HEOIxR_VADD | REG_HEOIxR_VDMA);
>>
>> What the above two calls are intended to be doing ?
>
> handle_irqstat handles the eventual pending irqs. The second call
> enables irqs for "frame done" (..._DMA) and "new descriptor loaded"
> (..._ADD).
OK, so it looks to me like irqs are unmasked in wait_prepare and masked
back in wait_finish. I would try to move this logic to start_streaming and
the interrupt handler.
It seems this way too much dependant on when wait_prepare/wait_finish are
called by videobuf2. AFAIK those callbacks are not called in non-blocking
mode.
>
>>> +const struct vb2_ops at91sam9x5_video_vb_ops = {
>>> + .queue_setup = at91sam9x5_video_vb_queue_setup,
>>> +
>>> + .wait_prepare = at91sam9x5_video_vb_wait_prepare,
>>> + .wait_finish = at91sam9x5_video_vb_wait_finish,
>>
>> These 2 functions are intended to unlock and lock respectively the mutex
>> that is used to serialize ioctl handlers, in particular DQBUF.
>> I'm not sure if you're doing the right thing in
>> at91sam9x5_video_vb_wait_prepare/at91sam9x5_video_vb_wait_finish.
> I'm not taking a mutex for sure.
All right, so this needs to be changed. If you decide to add a file
operations mutex and protect each file operation individually in the driver,
rather than assigning a pointer to such mutex to struct video_device::lock
and let the core serialize file ops, then wait_prepare/wait_finish
could be omitted.
>
>>> +
>>> + .buf_prepare = at91sam9x5_video_vb_buf_prepare,
>>> + .buf_queue = at91sam9x5_video_vb_buf_queue,
>>> +};
Also if your driver is supposed to support write() method,
vidioc_streamon/vidioc_streamoff should be just a pass-through for
vb2_streamon/vb2_streamoff and the hardware control should happen in
start_streaming, stop_streaming callbacks.
I can't see a stop_streaming callback in your vb2 operations set.
It's been made mandatory recently, thus it would be good to add it.
>>> +
>>> +static int at91sam9x5_video_vidioc_querycap(struct file *filp,
>>> + void *fh, struct v4l2_capability *cap)
>>> +{
>>> + strcpy(cap->driver, DRIVER_NAME);
I would go for a strlcpy here, better to be safe than sorry. ;-)
>>> + cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING |
>>> + V4L2_CAP_VIDEO_OVERLAY;
>>> +
>>> + /* XXX */
>>> + cap->version = 0;
>>
>> There is no need to set this field any more. It will be overwritten
>> with kernel versions in __video_do_ioctl(). See this for more details:
>> http://git.linuxtv.org/media_tree.git?a=commit;h=33436a81b0d4d1036ffcf0edb7e3bfa65d18ad08
> I saw the discussion on the ML, but missed that it was already
> committed.
>
>>> + cap->card[0] = '\0';
>>> + cap->bus_info[0] = '\0';
> I assume I need to fill these with more sensible values?
I think bus_info is not very useful for this driver and can be left as is.
As for cap->card, I'm not sure. Some drivers just just fill it in with
a video node name (/dev/video*), some are more creative.
Here is what the V4L2 specifications says:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
