RE: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
Kyungmin Park wrote: > > >> > > >> > Hi Kamil, > >> > > >> > I think, should be added my e-mail in Cc... > >> > >> No need to cc all, only machine specific only. > >> and I hope minimal modification at machine specific and move to media > >> if possible. > >> > > Should be reviewed proper maintainer even though it is small changes. > > Really, I don't want to argue to you about my maintaining ship... > > Each preference is different and you and me are different unfortunately. > Hmm...What's different? If you want to submit something, should be sent to proper maintainer. If two maintainers, you need both maintainers' agreement or at least ack to merge it. > > > > And I have a wondering about your sign. > > Did you really check this patch before Kamil's submitting? > > Unfortunately, I don't think so... > > I don't care minor issues I'm more focus on the logic. > Maybe you didn't check/review Kamil's patch before submitting. So your sign has a problem. Please see "Documentation/SubmittingPatches". I don't think that something like missing GPL license is minor issue. I mean if you want to add your sign, you had to check it before posting. And it doesn't matter it's small or big. > What's the matter mfc or mfc5 and so on? some time later these names > are changed if new mfc are introduced. > Currently we're use the mfc version 5. > How about fimc0 or fimc1...it is used as hardware version? No...it means channel. Why do you use mixed rule? As I said, if separate hardware version required, we can do it later. > Do you have any rules on samsung soc variable, module naming? I think > it depends on each case by case. > Already mentioned. ... I'd like to stop this here, we already talked about similar issues many times. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
On Fri, Dec 10, 2010 at 12:40 PM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> On Fri, Dec 10, 2010 at 11:32 AM, Kukjin Kim > wrote: >> > Kamil Debski wrote: >> >> >> >> Hello, >> >> >> >> Last week v3 of this driver has been posted. Since then the driver was >> >> changed >> >> to use the newest videobuf2 version - v6. Two very long functions have >> > been >> >> split to make the code more readible. Minor changes include tidying the >> >> comments and replacing remaining magic numbers with defines. >> >> >> >> I would be grateful for your comments. Original cover letter ant > detailed >> >> change >> >> log has been attached below. >> >> >> >> Best regards, >> >> Kamil Debski >> >> >> >> * Changelog: >> >> >> >> == >> >> Changes since v3 >> >> == >> >> >> >> 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) >> >> - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions >> >> have been merged >> >> - queue initialization has been adapted to the new API >> >> - use of the allocator memops has been changed, now there are single >> >> memops for all the allocator contexts >> >> >> >> 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions >> >> - parts of the s5p_mfc_try_run function have been moved to separate >> >> functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, >> >> s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst >> >> s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) >> >> - s5p_mfc_handle_frame_int has been split to the following functions: >> >> s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new >> >> and s5p_mfc_handle_frame to handle different cases >> >> >> >> 3) Remove remaining magic numbers and tidy up comments >> >> >> >> == >> >> Changes since v2 >> >> == >> >> >> >> 1) Update to newest videobuf2 API >> >> This is the major change from v2. The videobuf2 API will hopefully have > no >> >> more >> >> major API changes. Buffer initialization has been moved from > buf_prepare >> >> callback to buf_init to simplify the process. Locking mechanism has > been >> >> modified to the requirements of new videobuf2 version. >> >> 2) Code cleanup >> >> Removed more magic contants and replaced them with appropriate defines. >> >> Changed >> >> code to use unlocked_ioctl instead of ioctl in v4l2 file ops. >> >> 3) Allocators >> >> All internal buffer allocations are done using the selected vb2 > allocator, >> >> instead of using CMA functions directly. >> >> >> >> == >> >> Changes since v1 >> >> == >> >> >> >> 1) Cleanup accoridng to Peter Oh suggestions on the mailing list > (Thanks). >> >> >> >> * Original cover letter: >> >> >> >> == >> >> Introduction >> >> == >> >> >> >> The purpose of this RFC is to discuss the driver for a hw video codec >> >> embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to >> >> handle video decoding of in a range of formats. >> >> >> >> So far no hardware codec was supported in V4L2 and this would be the >> >> first one. I guess there are more similar device that would benefit > from >> >> a V4L2 unified interface. I suggest a separate control class for codec >> >> devices - V4L2_CTRL_CLASS_CODEC. >> >> >> >> Internally the driver uses videobuf2 framework and CMA memory > allocator. >> >> I am aware that those have not yet been merged, but I wanted to start >> >> discussion about the driver earlier so it could be merged sooner. The >> >> driver posted here is the initial version, so I suppose it will require >> >> more work. >> >> >> >> == >> >> Device interface >> >> == >> >> >> >> The driver principle is based on the idea of memory-to-memory devices: >> >> it provides a single video node and each opened file handle gets its > own >> >> private context with separate buffer queues. Each context consist of 2 >> >> buffer queues: OUTPUT (for source buffers, i.e. encoded video frames) >> >> and CAPTURE (for destination buffers, i.e. decoded raw video frames). >> >> The process of decoding video data from stream is a bit more > complicated >> >> than typical memory-to-memory processing, that's why the m2m framework >> >> is not directly used (it is too limited for this case). The main reason >> >> for this is the fact that the CAPTURE buffers can be dequeued in a >> >> different order than they queued. The hw block decides which buffer has >> >> been completely processed. This is due to the structure of most >> >> compressed video streams - use of B frames causes that decoding and >> >> display order may be different. >> >> >> >> == >> >> Decoding initialization path >> >> == >> >> >> >> First the OUTPUT queue is initialized. With S_FMT the application >> >> chooses which video format to decode and what size should be the input >> >> buffer. Fourcc values have been
RE: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
Kyungmin Park wrote: > > On Fri, Dec 10, 2010 at 11:32 AM, Kukjin Kim wrote: > > Kamil Debski wrote: > >> > >> Hello, > >> > >> Last week v3 of this driver has been posted. Since then the driver was > >> changed > >> to use the newest videobuf2 version - v6. Two very long functions have > > been > >> split to make the code more readible. Minor changes include tidying the > >> comments and replacing remaining magic numbers with defines. > >> > >> I would be grateful for your comments. Original cover letter ant detailed > >> change > >> log has been attached below. > >> > >> Best regards, > >> Kamil Debski > >> > >> * Changelog: > >> > >> == > >> Changes since v3 > >> == > >> > >> 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) > >> - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions > >> have been merged > >> - queue initialization has been adapted to the new API > >> - use of the allocator memops has been changed, now there are single > >> memops for all the allocator contexts > >> > >> 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions > >> - parts of the s5p_mfc_try_run function have been moved to separate > >> functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, > >> s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst > >> s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) > >> - s5p_mfc_handle_frame_int has been split to the following functions: > >> s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new > >> and s5p_mfc_handle_frame to handle different cases > >> > >> 3) Remove remaining magic numbers and tidy up comments > >> > >> == > >> Changes since v2 > >> == > >> > >> 1) Update to newest videobuf2 API > >> This is the major change from v2. The videobuf2 API will hopefully have no > >> more > >> major API changes. Buffer initialization has been moved from buf_prepare > >> callback to buf_init to simplify the process. Locking mechanism has been > >> modified to the requirements of new videobuf2 version. > >> 2) Code cleanup > >> Removed more magic contants and replaced them with appropriate defines. > >> Changed > >> code to use unlocked_ioctl instead of ioctl in v4l2 file ops. > >> 3) Allocators > >> All internal buffer allocations are done using the selected vb2 allocator, > >> instead of using CMA functions directly. > >> > >> == > >> Changes since v1 > >> == > >> > >> 1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks). > >> > >> * Original cover letter: > >> > >> == > >> Introduction > >> == > >> > >> The purpose of this RFC is to discuss the driver for a hw video codec > >> embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to > >> handle video decoding of in a range of formats. > >> > >> So far no hardware codec was supported in V4L2 and this would be the > >> first one. I guess there are more similar device that would benefit from > >> a V4L2 unified interface. I suggest a separate control class for codec > >> devices - V4L2_CTRL_CLASS_CODEC. > >> > >> Internally the driver uses videobuf2 framework and CMA memory allocator. > >> I am aware that those have not yet been merged, but I wanted to start > >> discussion about the driver earlier so it could be merged sooner. The > >> driver posted here is the initial version, so I suppose it will require > >> more work. > >> > >> == > >> Device interface > >> == > >> > >> The driver principle is based on the idea of memory-to-memory devices: > >> it provides a single video node and each opened file handle gets its own > >> private context with separate buffer queues. Each context consist of 2 > >> buffer queues: OUTPUT (for source buffers, i.e. encoded video frames) > >> and CAPTURE (for destination buffers, i.e. decoded raw video frames). > >> The process of decoding video data from stream is a bit more complicated > >> than typical memory-to-memory processing, that's why the m2m framework > >> is not directly used (it is too limited for this case). The main reason > >> for this is the fact that the CAPTURE buffers can be dequeued in a > >> different order than they queued. The hw block decides which buffer has > >> been completely processed. This is due to the structure of most > >> compressed video streams - use of B frames causes that decoding and > >> display order may be different. > >> > >> == > >> Decoding initialization path > >> == > >> > >> First the OUTPUT queue is initialized. With S_FMT the application > >> chooses which video format to decode and what size should be the input > >> buffer. Fourcc values have been defined for different codecs e.g. > >> V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and > >> mmaped. The stream header frame is loaded into the first buffer, queued > >
Re: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
On Fri, Dec 10, 2010 at 11:32 AM, Kukjin Kim wrote: > Kamil Debski wrote: >> >> Hello, >> >> Last week v3 of this driver has been posted. Since then the driver was >> changed >> to use the newest videobuf2 version - v6. Two very long functions have > been >> split to make the code more readible. Minor changes include tidying the >> comments and replacing remaining magic numbers with defines. >> >> I would be grateful for your comments. Original cover letter ant detailed >> change >> log has been attached below. >> >> Best regards, >> Kamil Debski >> >> * Changelog: >> >> == >> Changes since v3 >> == >> >> 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) >> - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions >> have been merged >> - queue initialization has been adapted to the new API >> - use of the allocator memops has been changed, now there are single >> memops for all the allocator contexts >> >> 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions >> - parts of the s5p_mfc_try_run function have been moved to separate >> functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, >> s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst >> s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) >> - s5p_mfc_handle_frame_int has been split to the following functions: >> s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new >> and s5p_mfc_handle_frame to handle different cases >> >> 3) Remove remaining magic numbers and tidy up comments >> >> == >> Changes since v2 >> == >> >> 1) Update to newest videobuf2 API >> This is the major change from v2. The videobuf2 API will hopefully have no >> more >> major API changes. Buffer initialization has been moved from buf_prepare >> callback to buf_init to simplify the process. Locking mechanism has been >> modified to the requirements of new videobuf2 version. >> 2) Code cleanup >> Removed more magic contants and replaced them with appropriate defines. >> Changed >> code to use unlocked_ioctl instead of ioctl in v4l2 file ops. >> 3) Allocators >> All internal buffer allocations are done using the selected vb2 allocator, >> instead of using CMA functions directly. >> >> == >> Changes since v1 >> == >> >> 1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks). >> >> * Original cover letter: >> >> == >> Introduction >> == >> >> The purpose of this RFC is to discuss the driver for a hw video codec >> embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to >> handle video decoding of in a range of formats. >> >> So far no hardware codec was supported in V4L2 and this would be the >> first one. I guess there are more similar device that would benefit from >> a V4L2 unified interface. I suggest a separate control class for codec >> devices - V4L2_CTRL_CLASS_CODEC. >> >> Internally the driver uses videobuf2 framework and CMA memory allocator. >> I am aware that those have not yet been merged, but I wanted to start >> discussion about the driver earlier so it could be merged sooner. The >> driver posted here is the initial version, so I suppose it will require >> more work. >> >> == >> Device interface >> == >> >> The driver principle is based on the idea of memory-to-memory devices: >> it provides a single video node and each opened file handle gets its own >> private context with separate buffer queues. Each context consist of 2 >> buffer queues: OUTPUT (for source buffers, i.e. encoded video frames) >> and CAPTURE (for destination buffers, i.e. decoded raw video frames). >> The process of decoding video data from stream is a bit more complicated >> than typical memory-to-memory processing, that's why the m2m framework >> is not directly used (it is too limited for this case). The main reason >> for this is the fact that the CAPTURE buffers can be dequeued in a >> different order than they queued. The hw block decides which buffer has >> been completely processed. This is due to the structure of most >> compressed video streams - use of B frames causes that decoding and >> display order may be different. >> >> == >> Decoding initialization path >> == >> >> First the OUTPUT queue is initialized. With S_FMT the application >> chooses which video format to decode and what size should be the input >> buffer. Fourcc values have been defined for different codecs e.g. >> V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and >> mmaped. The stream header frame is loaded into the first buffer, queued >> and streaming is enabled. At this point the hardware is able to start >> processing the stream header and afterwards it will have information >> about the video dimensions and the size of the buffers with raw video >> data. >> >> The next step is setting
RE: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
Kamil Debski wrote: > > Hello, > > Last week v3 of this driver has been posted. Since then the driver was > changed > to use the newest videobuf2 version - v6. Two very long functions have been > split to make the code more readible. Minor changes include tidying the > comments and replacing remaining magic numbers with defines. > > I would be grateful for your comments. Original cover letter ant detailed > change > log has been attached below. > > Best regards, > Kamil Debski > > * Changelog: > > == > Changes since v3 > == > > 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) > - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions > have been merged > - queue initialization has been adapted to the new API > - use of the allocator memops has been changed, now there are single > memops for all the allocator contexts > > 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions > - parts of the s5p_mfc_try_run function have been moved to separate > functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, > s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst > s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) > - s5p_mfc_handle_frame_int has been split to the following functions: > s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new > and s5p_mfc_handle_frame to handle different cases > > 3) Remove remaining magic numbers and tidy up comments > > == > Changes since v2 > == > > 1) Update to newest videobuf2 API > This is the major change from v2. The videobuf2 API will hopefully have no > more > major API changes. Buffer initialization has been moved from buf_prepare > callback to buf_init to simplify the process. Locking mechanism has been > modified to the requirements of new videobuf2 version. > 2) Code cleanup > Removed more magic contants and replaced them with appropriate defines. > Changed > code to use unlocked_ioctl instead of ioctl in v4l2 file ops. > 3) Allocators > All internal buffer allocations are done using the selected vb2 allocator, > instead of using CMA functions directly. > > == > Changes since v1 > == > > 1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks). > > * Original cover letter: > > == > Introduction > == > > The purpose of this RFC is to discuss the driver for a hw video codec > embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to > handle video decoding of in a range of formats. > > So far no hardware codec was supported in V4L2 and this would be the > first one. I guess there are more similar device that would benefit from > a V4L2 unified interface. I suggest a separate control class for codec > devices - V4L2_CTRL_CLASS_CODEC. > > Internally the driver uses videobuf2 framework and CMA memory allocator. > I am aware that those have not yet been merged, but I wanted to start > discussion about the driver earlier so it could be merged sooner. The > driver posted here is the initial version, so I suppose it will require > more work. > > == > Device interface > == > > The driver principle is based on the idea of memory-to-memory devices: > it provides a single video node and each opened file handle gets its own > private context with separate buffer queues. Each context consist of 2 > buffer queues: OUTPUT (for source buffers, i.e. encoded video frames) > and CAPTURE (for destination buffers, i.e. decoded raw video frames). > The process of decoding video data from stream is a bit more complicated > than typical memory-to-memory processing, that's why the m2m framework > is not directly used (it is too limited for this case). The main reason > for this is the fact that the CAPTURE buffers can be dequeued in a > different order than they queued. The hw block decides which buffer has > been completely processed. This is due to the structure of most > compressed video streams - use of B frames causes that decoding and > display order may be different. > > == > Decoding initialization path > == > > First the OUTPUT queue is initialized. With S_FMT the application > chooses which video format to decode and what size should be the input > buffer. Fourcc values have been defined for different codecs e.g. > V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and > mmaped. The stream header frame is loaded into the first buffer, queued > and streaming is enabled. At this point the hardware is able to start > processing the stream header and afterwards it will have information > about the video dimensions and the size of the buffers with raw video > data. > > The next step is setting up the CAPTURE queue and buffers. The width, > height, buffer size and minimum number of buffers can be read with G_FMT > call. The application can req
[RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
Hello, Last week v3 of this driver has been posted. Since then the driver was changed to use the newest videobuf2 version - v6. Two very long functions have been split to make the code more readible. Minor changes include tidying the comments and replacing remaining magic numbers with defines. I would be grateful for your comments. Original cover letter ant detailed change log has been attached below. Best regards, Kamil Debski * Changelog: == Changes since v3 == 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions have been merged - queue initialization has been adapted to the new API - use of the allocator memops has been changed, now there are single memops for all the allocator contexts 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions - parts of the s5p_mfc_try_run function have been moved to separate functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) - s5p_mfc_handle_frame_int has been split to the following functions: s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new and s5p_mfc_handle_frame to handle different cases 3) Remove remaining magic numbers and tidy up comments == Changes since v2 == 1) Update to newest videobuf2 API This is the major change from v2. The videobuf2 API will hopefully have no more major API changes. Buffer initialization has been moved from buf_prepare callback to buf_init to simplify the process. Locking mechanism has been modified to the requirements of new videobuf2 version. 2) Code cleanup Removed more magic contants and replaced them with appropriate defines. Changed code to use unlocked_ioctl instead of ioctl in v4l2 file ops. 3) Allocators All internal buffer allocations are done using the selected vb2 allocator, instead of using CMA functions directly. == Changes since v1 == 1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks). * Original cover letter: == Introduction == The purpose of this RFC is to discuss the driver for a hw video codec embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to handle video decoding of in a range of formats. So far no hardware codec was supported in V4L2 and this would be the first one. I guess there are more similar device that would benefit from a V4L2 unified interface. I suggest a separate control class for codec devices - V4L2_CTRL_CLASS_CODEC. Internally the driver uses videobuf2 framework and CMA memory allocator. I am aware that those have not yet been merged, but I wanted to start discussion about the driver earlier so it could be merged sooner. The driver posted here is the initial version, so I suppose it will require more work. == Device interface == The driver principle is based on the idea of memory-to-memory devices: it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. encoded video frames) and CAPTURE (for destination buffers, i.e. decoded raw video frames). The process of decoding video data from stream is a bit more complicated than typical memory-to-memory processing, that's why the m2m framework is not directly used (it is too limited for this case). The main reason for this is the fact that the CAPTURE buffers can be dequeued in a different order than they queued. The hw block decides which buffer has been completely processed. This is due to the structure of most compressed video streams - use of B frames causes that decoding and display order may be different. == Decoding initialization path == First the OUTPUT queue is initialized. With S_FMT the application chooses which video format to decode and what size should be the input buffer. Fourcc values have been defined for different codecs e.g. V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and mmaped. The stream header frame is loaded into the first buffer, queued and streaming is enabled. At this point the hardware is able to start processing the stream header and afterwards it will have information about the video dimensions and the size of the buffers with raw video data. The next step is setting up the CAPTURE queue and buffers. The width, height, buffer size and minimum number of buffers can be read with G_FMT call. The application can request more output buffer if necessary. After requesting and mmaping buffers the device is ready to decode video stream. The stream frames (ES frames) are written to the OUTPUT buffers, and decoded video frames can be read from the CAPTURE buffers. When no more
