Hi Hans,
I mistake to send msg on the wrong threads, and also there is mis-
understanding cause of a lack of my explanation about this. so I wanna
fix up the agenda about this on this thread, again.
> Yes, there is. You missed the important part about how the media framework
> models
> sub-devices. In your block diagram the media API would not only list the
> v4l
> device nodes, but also the sensor and HW Block A and B as sub-devices.
>
> The media API allows you to reconfigure the links between the subdevices
> and
> the device nodes, so you can decide how the video flows through the
system.
>
> In addition, the sub-devices will get their own device node so you can
> control
> them from userspace. This gives you much more precise control over your
> system.
The H/W Blocks is connected with AMBA bus with the core(ARM926EJS).
And it is already made by platform device now. We base the kernel
version 2.6.34. Sorry for not informing this before.
But, if using media framework or any other ideas is right for V4L2
frameworks, I intend to change this code.
> So in preview mode the video goes from the sensor to block A, then to
> block B
> (using the internal FIFO), then then it goes to an LCD or something like
> that?
Yes, you're right.
>
> And in capture mode it goes from the sensor to Block A and then to the DMA
> engine? Or does it also go through block B first? It's not clear from your
> description.
The first thing is right. It is decided in the Block A, whether FIFO
in preview mode or DMA in capture mode. After Block A take the stream
from sensor to DMA-ed memory, The Block B can get the streams from
Block A's DMA-ed memory in the capture mode.
so I one more try the diagram,
a) In preview mode
+-----------------+
| FIFO Link |
+---| using |---+
| | Internal SRAM | |
+---+ | +-----------------+ |
| C | | |
| C | +--------------------+--+ +-------------+
| D | | H/W Block A |------------------| H/W Block B |
| | +-----------+-----------+ Vsync issued +-------------+
| S +------+ Sensor | Pre - | using interrupt | Post - |
| E | | Interface | Processor | recognized at | Processor |
| N | +----+--------------+---+ H/W Block B +-+-----------+
| S | | | |
| O | +--------------+ |
| R | Vsync issued | DMA
+---+ using interrupt | Link
recognized |
in H/W Block A |
|
+-----------------------------------------------+-----------+
| DMA Bus |
+-----------------------------------------------------------+
b) In capture mode
+-----------------+
| FIFO Link |
| using |
| Internal SRAM |
+---+ +-----------------+
| C |
| C | +--------------------+--+ +-------------+
| D | | H/W Block A |------------------| H/W Block B |
| | +-----------+-----------+ Vsync issued +-------------+
| S +------+ Sensor | Pre - | using interrupt | Post - |
| E | | Interface | Processor | recognized at | Processor |
| N | +----+--------------+---+ H/W Block B +-+-----------+
| S | | | |
| O | +--------------+ |
| R | Vsync issued +--------------------+
+---+ using interrupt | DMA
recognized | Link
in H/W Block A |
|
+-----------------------------------------------+-----------+
| DMA Bus |
+-----------------------------------------------------------+
As you see, in the preview mode the SoC use path like (Sensor)-(Block A)
-(FIFO)-(Block B)-(DMA), and in the capture mode it use (Sensor)-
(Block A)-(DMA). So, Taken together, the conclusion is under here.
1) the Blocks A and B are SoC-integrated using AMBA bus.
2) in the preview mode, it's no way to define buf_type using V4L2 classic
method. (cause of no buffers)
3) in the preview mode, there is another option is using media framework.
(must be changed Block A code from platform device type to subdev type)
4) base kernel version 2.6.34, and already is working using a little hacks.
(not using v4l2 type, only use S_FMT and STREAMON ioctl calls.)
My question is this.
Q) what's the best choice to keep the V4L2 description & framework, between
changing buf_type and using media framework, in this case??
I'm not sure, but we have also a plan to upload ths SoC patches to the
mainline,
probably. So, it's very significant to keep the V4L2 specification, also
just using V4L2.
Thanks to advise and read.
Regards,
HeungJun, Kim
>
> Regards,
>
> Hans
>
> >
> > I would show this SoC's media H/W Blocks flowchart briefly.
> >
> >
> >
> > +------------------+
> > | FIFO Link |
> > +---| using |---+
> > | | Internal SRAM | |
> > +---+ | +------------------+ |
> > | C | | |
> > | C | +--------------------+---+
> > +---------------+
> > | D | | H/W Block A |--------------------| H/W
Block B
> > |
> > | | +-----------+------------+ Vsync issued
> > +---------------+
> > | S +-------+ Sensor | Pre - | using Interrupt | Post -
> > |
> > | E | | Interface | Processor | recognized at |
Processor
> > |
> > | N | +----+--------------+----+ H/W Block B
> > +-+-------------+
> > | S | | | |
> > | O | +--------------+ |
> > | R | Vsync issued | DMA
Link
> > +---+ using Interrupt |
> > recognized in H/W Block A |
> > |
> >
> > +---------------------------------------------------+-----------------+
> > | DMA Bus
> > |
> >
> > +---------------------------------------------------------------------+
> >
> > If the flowchart is crashed, copy and paste in the notepad or something.
> > In the fixed size font, it will looks well.
> >
> > Actualy my opinion, any other buf_type is needed to define in such case,
> > like a V4L2_BUF_FLAG_FIFO, not using media framework.
> >
> > Thanks to reading, and I'll wait any advises and opinions.
> >
> > Regards,
> > HeungJun, Kim
> >
> -----Original Message-----
> From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Kim, HeungJun
> Sent: Wednesday, September 15, 2010 3:39 PM
> To: 'Laurent Pinchart'; hverkuil@xxxxxxxxx
> Cc: linux-media@xxxxxxxxxxxxxxx; inki.dae@xxxxxxxxxxx;
> kyungmin.park@xxxxxxxxxxx
> Subject: RE: how can deal with the stream in only on-the-fly-output
> available HW block??
>
> Sorry, I miss sending msg into any other thread.
> Send with the right thread, Again.
>
> Thanks,
> HeungJun Kim
>
> --------------------------------------------------------------------------
> --
> --------------
>
> Hi Laurent, and Hans,
>
> I checked media frameworks, it was helpful for me, but It's not usable on
> my
> case. Because, before defining the device for using media frameworks, the
> device must be defined by some other device like FB, ALSA, DVB, etc. But,
> this H/W Block is no way to define using any other method in current V4L2
> frameworks.
>
> So, I wanna listen to your advices about this cases.
>
> It has 2 modes, the Preview mode to have Capturing & FIFOing capability,
> and
> the Capture mode to DMAing capabilitiy. Exactly, in Preview mode, it
> dosen't
> need any other V4L2 IOCTL calls related with buffer, like VIDIOC_REQBUFS,
> VIDIOC_QUERYBUFS, and mmap() operation. Using just VIDIOC_S_FMT IOCTL
> calls,
> is able to define this block. Because, it has no buffers. The QBUF and
> DQBUF
> looping, also is same any other V4L2 driver working process. On the other
> hand, In Capture mode, the same stream of Preview mode, is able to get
> using
> WDMA. So, at this mode, it need V4L2 IOCTL calls related with buffers.
>
> I would show this SoC's media H/W Blocks flowchart briefly.
>
>
>
> +------------------+
> | FIFO Link |
> +---| using |---+
> | | Internal SRAM | |
> +---+ | +------------------+ |
> | C | | |
> | C | +--------------------+---+
> +---------------+
> | D | | H/W Block A |--------------------| H/W Block
B
> |
> | | +-----------+------------+ Vsync issued
> +---------------+
> | S +-------+ Sensor | Pre - | using Interrupt | Post -
> |
> | E | | Interface | Processor | recognized at | Processor
> |
> | N | +----+--------------+----+ H/W Block B
> +-+-------------+
> | S | | | |
> | O | +--------------+ |
> | R | Vsync issued | DMA Link
> +---+ using Interrupt |
> recognized in H/W Block A |
> |
>
> +---------------------------------------------------+-----------------+
> | DMA Bus
> |
>
> +---------------------------------------------------------------------+
>
> If the flowchart is crashed, copy and paste in the notepad or something.
> In the fixed size font, it will looks well.
>
> Actualy my opinion, any other buf_type is needed to define in such case,
> like a V4L2_BUF_FLAG_FIFO, not using media framework.
>
> Thanks to reading, and I'll wait any advises and opinions.
>
> Regards,
> HeungJun, Kim
>
>
> > -----Original Message-----
> > From: Kim, HeungJun [mailto:riverful.kim@xxxxxxxxxxx]
> > Sent: Tuesday, September 14, 2010 2:11 PM
> > To: 'linux-media@xxxxxxxxxxxxxxx'; 'laurent.pinchart@xxxxxxxxxxxxxxxx';
> > 'hverkuil@xxxxxxxxx'
> > Cc: 'inki.dae@xxxxxxxxxxx'; 'kyungmin.park@xxxxxxxxxxx'
> > Subject: how can deal with the stream in only on-the-fly-output
> available
> > HW block??
> >
> >
> >
> > -----Original Message-----
> > From: Kim, HeungJun [mailto:riverful.kim@xxxxxxxxxxx]
> > Sent: Tuesday, September 14, 2010 2:02 PM
> > To: 'laurent.pinchart@xxxxxxxxxxxxxxxx'; 'hverkuil@xxxxxxxxx'
> > Subject: RE: how can deal with the stream in only on-the-fly-output
> > available HW block??
> >
> > > On Monday, September 13, 2010 14:10:55 Kim, HeungJun wrote:
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > What if some SoC's specific HW block supports only on-the-fly mode
> for
> > > > stream output??
> > >
> > > What do you mean with 'on-the-fly mode'? Does that mean that two HW
> > blocks
> > > are linked together so that the video stream goes directly from one to
> > the
> > > other without ever being DMA-ed to memory?
> >
> > You're right. It's linked with internal SRAM FIFO. So, syncing streams
> > with both blocks is kept with VSync Interrupt. It's not using DMA-ed to
> > memory in this mode.
> >
> > >
> > > >
> > > > In this case, what is the suitable buf_type??
> > >
> > > Suitable buf_type for doing what?
> >
> > I wanna define this blocks topology with V4L2 APIs. But, I don't find
> > suitable buf_type or any definitions in the V4L2 APIs with current SoC's
> > block media topology.
> >
> > >
> > > You probably need the upcoming media API to be able to correctly deal
> > with
> > > these issues. Check the mailing list for the patches done by Laurent
> > > Pinchart.
> > >
> > > The current V4L2 API is really not able to handle changes in the
> > internal
> > > video stream topology.
> >
> > Thanks to Hans. It's very helpful.
> > I'll check Laurent's media topology patches.
> >
> >
> > Hello, Laurent,
> >
> > I'm googling and find your patches, so I'm checking with. But, where can
> I
> > get your patches?? Probably, I would find in this page :
> > http://git.linuxtv.org/, so what's your repository?
> >
> > Regards,
> > HeungJun, Kim
> >
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > >
> > > > I'm faced with such problem.
> > > >
> > > >
> > > >
> > > > As explanation for my situation briefly, the processor I deal with
> now
> > > has 3
> > > > Multimedia H/W blocks, and the problem-one in the 3 blocks do the
> work
> > > for
> > > > sensor-interfacing and pre-processing.
> > > >
> > > > It supports CCD or CMOS for input, and DMA or On-The-Fly for output.
> > > > Exactly, it has two cases - DMA mode using memory bus & On-The-Fly
> > mode
> > > > connected with any other multimedia blocks.
> > > >
> > > > Also, it use only one format "Bayer RGB" in case of mode the DMA and
> > > > On-The-Fly mode both.
> > > >
> > > >
> > > >
> > > > So, when the device operates in the On-The-Fly mode, is it alright
> the
> > > > driver's current type is V4L2_BUF_TYPE_VIDEO_CAPTURE? or something
> > else?
> > > >
> > > > or if setting buf_type is wrong itself, what v4l2 API flow is right
> > for
> > > > driver or userspace??
> > > >
> > > >
> > > >
> > > > the v4l2 buf_type enumeratinos is defined here, but I have no idea
> > about
> > > > suitable enum value in this case, also except for any other under
> > enums
> > > too.
> > > >
> > > >
> > > >
> > > > V4L2_BUF_TYPE_VIDEO_CAPTURE = 1,
> > > >
> > > > V4L2_BUF_TYPE_VIDEO_OUTPUT = 2,
> > > >
> > > > V4L2_BUF_TYPE_VIDEO_OVERLAY = 3,
> > > >
> > > > V4L2_BUF_TYPE_VBI_CAPTURE = 4,
> > > >
> > > > V4L2_BUF_TYPE_VBI_OUTPUT = 5,
> > > >
> > > > V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
> > > >
> > > > V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
> > > >
> > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
> > > >
> > > > V4L2_BUF_TYPE_PRIVATE = 0x80,
> > > >
> > > >
> > > >
> > > > I'll thanks for any idea or answer.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > HeungJun, Kim
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of
> > > Cisco
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
