| Message ID | 20190131031333.11905-1-ayaka@soulik.info (mailing list archive) |
|---|---|
| Headers | show |
| Series | WIP: rockchip mpp for v4l2 video decoder | expand |
Hey Ayaka! On Thu, 2019-01-31 at 11:13 +0800, ayaka wrote: > From: Randy 'ayaka' Li <ayaka@soulik.info> > > Hello > Those patches are based on the previous vendor driver I post before, > but it can apply without the previous one. > I really want to make it work before FOSDEM and I didn't. And upcoming > the lunar new year holiday would last two week. > > I have verified the v4l2 part but I meet a problem with power or > clock, it would be a complex problem, I would handle to solve it after I > am back. But I just tell my design on this kind dirver. > This the branch I'm about to submit: http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/vpu-mpeg-2-almost-ready-for-upstream And it has no power issues. Perhaps you can take a look inside, you might be just missing a few pm_ statements? Perhaps a devicetree thing? > A few questions I think you may ask I would like to answer it here. > I have another question: is this patchset meant to support for mpeg-2 decoding only? I can't find any other codec code. Thanks, Ezequiel > 1. Why it is based on the previous vendor driver ? > The vendor driver I post to mail list is a clean version which having a > efficient work flow and those platform dependency controls having been > merged into it. > > For the stateless device, V4L2 is just another interface for userspace > to translate it into registers. > > 2. Why use a structure to store register infomation not marco ? > I really don't want to define many marcos for a device having more than > a hundred of registers. And there are many fields in a registers. > > For the VDPU1/VDPU2 which would support more than 10 video codecs, these > two devices would re-use many registers for many codecs, It would be > hard to show the conflict relations between them in marco but more easy > with C union and structure. > > BTW, I would prefer to write a number of registers into the device > though AHB bus not just generate one then write one, you can save some > times here. > > > Besides the two previous answers. I really have a big problem with v4l2 > design. Which would driver wait the work of the previous picture is > done, leading a large gap time more idle of the device. > > I am ok the current face that v4l2 stateless driver is not stateless. > But it would limit the ability of stateless decoder. It is more flexible > to those videos having different resolution or orientation sequences. > > But I don't like the method to reconstruct the bitstream in driver, it > is a bad idea to limit what data the device want. Those problem is > mainly talking in the HEVC slice thread. And it was ironic for the VPx > serial codec, which mixed compressed data and umcompress header together > and twisted. Even for the ITU H serial codec, it would become a problem > in SVC or Google Android CTS test. > > And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their > code. > > Randy Li (1): > staging: video: rockchip: add video codec > > ayaka (3): > [WIP]: staging: video: rockchip: add v4l2 common > [WIP] staging: video: rockchip: vdpu2 > [TEST]: rockchip: mpp: support qtable > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/rockchip-mpp/Kconfig | 54 + > drivers/staging/rockchip-mpp/Makefile | 8 + > drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ > drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +++++++++++++++++ > drivers/staging/rockchip-mpp/mpp_dev_common.h | 215 +++ > drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 878 +++++++++++ > drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 755 +++++++++ > drivers/staging/rockchip-mpp/mpp_service.c | 197 +++ > drivers/staging/rockchip-mpp/mpp_service.h | 38 + > drivers/staging/rockchip-mpp/rkvdec/hal.h | 53 + > drivers/staging/rockchip-mpp/rkvdec/regs.h | 395 +++++ > drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + > drivers/staging/rockchip-mpp/vdpu2/mpeg2.c | 253 +++ > drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 +++++++++ > 16 files changed, 5052 insertions(+) > create mode 100644 drivers/staging/rockchip-mpp/Kconfig > create mode 100644 drivers/staging/rockchip-mpp/Makefile > create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c > create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h > create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h > create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c > create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h >
Sent from my iPad > On Jan 31, 2019, at 10:03 PM, Ezequiel Garcia <ezequiel@collabora.com> wrote: > > Hey Ayaka! > >> On Thu, 2019-01-31 at 11:13 +0800, ayaka wrote: >> From: Randy 'ayaka' Li <ayaka@soulik.info> >> >> Hello >> Those patches are based on the previous vendor driver I post before, >> but it can apply without the previous one. >> I really want to make it work before FOSDEM and I didn't. And upcoming >> the lunar new year holiday would last two week. >> >> I have verified the v4l2 part but I meet a problem with power or >> clock, it would be a complex problem, I would handle to solve it after I >> am back. But I just tell my design on this kind dirver. >> > > This the branch I'm about to submit: > > http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/vpu-mpeg-2-almost-ready-for-upstream > > And it has no power issues. Perhaps you can take a look inside, > you might be just missing a few pm_ statements? Perhaps a devicetree thing? > I don’t think it is a complex problem, just I waste too time on v4l2 part All the current clock frequency at rk3328 is too low for H.264 decoding you may find my previous mail. >> A few questions I think you may ask I would like to answer it here. >> > > I have another question: is this patchset meant to support for mpeg-2 > decoding only? I can't find any other codec code. > I have not. I would like to move my work on userspace interface later, as I said in IRC. MPEG-2 is just a simple codec I choose for demo(userspace and some not normal picture coded like fileds) and if there is a codec parser there, I can solve it easily. Adding support to new codec is not complex in this driver once the interface problem is solved. I just copy the public rockchip mpp userspace library into it. It is the other advantage use the register structure. But I do like people to merge the final version I submit, I would prove it why later. > Thanks, > Ezequiel > >> 1. Why it is based on the previous vendor driver ? >> The vendor driver I post to mail list is a clean version which having a >> efficient work flow and those platform dependency controls having been >> merged into it. >> >> For the stateless device, V4L2 is just another interface for userspace >> to translate it into registers. >> >> 2. Why use a structure to store register infomation not marco ? >> I really don't want to define many marcos for a device having more than >> a hundred of registers. And there are many fields in a registers. >> >> For the VDPU1/VDPU2 which would support more than 10 video codecs, these >> two devices would re-use many registers for many codecs, It would be >> hard to show the conflict relations between them in marco but more easy >> with C union and structure. >> >> BTW, I would prefer to write a number of registers into the device >> though AHB bus not just generate one then write one, you can save some >> times here. >> >> >> Besides the two previous answers. I really have a big problem with v4l2 >> design. Which would driver wait the work of the previous picture is >> done, leading a large gap time more idle of the device. >> >> I am ok the current face that v4l2 stateless driver is not stateless. >> But it would limit the ability of stateless decoder. It is more flexible >> to those videos having different resolution or orientation sequences. >> >> But I don't like the method to reconstruct the bitstream in driver, it >> is a bad idea to limit what data the device want. Those problem is >> mainly talking in the HEVC slice thread. And it was ironic for the VPx >> serial codec, which mixed compressed data and umcompress header together >> and twisted. Even for the ITU H serial codec, it would become a problem >> in SVC or Google Android CTS test. >> >> And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their >> code. >> >> Randy Li (1): >> staging: video: rockchip: add video codec >> >> ayaka (3): >> [WIP]: staging: video: rockchip: add v4l2 common >> [WIP] staging: video: rockchip: vdpu2 >> [TEST]: rockchip: mpp: support qtable >> >> drivers/staging/Kconfig | 2 + >> drivers/staging/Makefile | 1 + >> drivers/staging/rockchip-mpp/Kconfig | 54 + >> drivers/staging/rockchip-mpp/Makefile | 8 + >> drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ >> drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +++++++++++++++++ >> drivers/staging/rockchip-mpp/mpp_dev_common.h | 215 +++ >> drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 878 +++++++++++ >> drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 755 +++++++++ >> drivers/staging/rockchip-mpp/mpp_service.c | 197 +++ >> drivers/staging/rockchip-mpp/mpp_service.h | 38 + >> drivers/staging/rockchip-mpp/rkvdec/hal.h | 53 + >> drivers/staging/rockchip-mpp/rkvdec/regs.h | 395 +++++ >> drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + >> drivers/staging/rockchip-mpp/vdpu2/mpeg2.c | 253 +++ >> drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 +++++++++ >> 16 files changed, 5052 insertions(+) >> create mode 100644 drivers/staging/rockchip-mpp/Kconfig >> create mode 100644 drivers/staging/rockchip-mpp/Makefile >> create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h >> create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c >> create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h >> create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c >> create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c >> create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c >> create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h >> create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h >> create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h >> create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h >> create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c >> create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h >> > >
From: Randy 'ayaka' Li <ayaka@soulik.info> Hello Those patches are based on the previous vendor driver I post before, but it can apply without the previous one. I really want to make it work before FOSDEM and I didn't. And upcoming the lunar new year holiday would last two week. I have verified the v4l2 part but I meet a problem with power or clock, it would be a complex problem, I would handle to solve it after I am back. But I just tell my design on this kind dirver. A few questions I think you may ask I would like to answer it here. 1. Why it is based on the previous vendor driver ? The vendor driver I post to mail list is a clean version which having a efficient work flow and those platform dependency controls having been merged into it. For the stateless device, V4L2 is just another interface for userspace to translate it into registers. 2. Why use a structure to store register infomation not marco ? I really don't want to define many marcos for a device having more than a hundred of registers. And there are many fields in a registers. For the VDPU1/VDPU2 which would support more than 10 video codecs, these two devices would re-use many registers for many codecs, It would be hard to show the conflict relations between them in marco but more easy with C union and structure. BTW, I would prefer to write a number of registers into the device though AHB bus not just generate one then write one, you can save some times here. Besides the two previous answers. I really have a big problem with v4l2 design. Which would driver wait the work of the previous picture is done, leading a large gap time more idle of the device. I am ok the current face that v4l2 stateless driver is not stateless. But it would limit the ability of stateless decoder. It is more flexible to those videos having different resolution or orientation sequences. But I don't like the method to reconstruct the bitstream in driver, it is a bad idea to limit what data the device want. Those problem is mainly talking in the HEVC slice thread. And it was ironic for the VPx serial codec, which mixed compressed data and umcompress header together and twisted. Even for the ITU H serial codec, it would become a problem in SVC or Google Android CTS test. And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their code. Randy Li (1): staging: video: rockchip: add video codec ayaka (3): [WIP]: staging: video: rockchip: add v4l2 common [WIP] staging: video: rockchip: vdpu2 [TEST]: rockchip: mpp: support qtable drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/rockchip-mpp/Kconfig | 54 + drivers/staging/rockchip-mpp/Makefile | 8 + drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +++++++++++++++++ drivers/staging/rockchip-mpp/mpp_dev_common.h | 215 +++ drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 878 +++++++++++ drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 755 +++++++++ drivers/staging/rockchip-mpp/mpp_service.c | 197 +++ drivers/staging/rockchip-mpp/mpp_service.h | 38 + drivers/staging/rockchip-mpp/rkvdec/hal.h | 53 + drivers/staging/rockchip-mpp/rkvdec/regs.h | 395 +++++ drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + drivers/staging/rockchip-mpp/vdpu2/mpeg2.c | 253 +++ drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 +++++++++ 16 files changed, 5052 insertions(+) create mode 100644 drivers/staging/rockchip-mpp/Kconfig create mode 100644 drivers/staging/rockchip-mpp/Makefile create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h