From: Dafna Hirschfeld <dafna.hirschfeld@xxxxxxxxxxxxx> Add a TODO file listing all that is need for destaging. Signed-off-by: Robert Beckett <bob.beckett@xxxxxxxxxxxxx> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@xxxxxxxxxxxxx> --- drivers/staging/media/wave5/TODO | 64 ++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 drivers/staging/media/wave5/TODO diff --git a/drivers/staging/media/wave5/TODO b/drivers/staging/media/wave5/TODO new file mode 100644 index 000000000000..425ed42a234c --- /dev/null +++ b/drivers/staging/media/wave5/TODO @@ -0,0 +1,64 @@ +* Test on real silicon once available + + This driver has so far been tested on pre-silicon FPGA and on the beta BeagleV + board which uses the StarFive JH7100 beta SoC. + + Testing on FPGA shows it working fine, though the FPGA uses polled interrupts + and copied buffers between the host and it's on board RAM. + + Testing on BeagleV shows buffer corruption that is currently attributed to a + known silicon issue in the SoC that makes the cache coherent interconnect not + so coherent. + This can likely be solved when the riscv non-coherent dma support lands and + provide optional v4l2 non-contiguous allocator, though it remains to be seen + whether support non-coherent use cases will be useful in real world hw. + + Until we can test and resolve any issues on final silicon (due 2H 2021) + this driver should remain in staging. + +* Handle interrupts better + + Currently the interrupt handling uses an unusual design employing a kfifo to + transfer irq status to irq thread. This was done as a work around for dropped + interrupts seen with IRQF_ONESHOT based handling. + + This needs further investigation and fixing properly, with the aid of + C&M and StarFive engineers. + +* Fix early end of stream handling + + When using a gstreamer pipeline like this: + gst-launch-1.0 filesrc location=<file> ! parsebin ! h264parse ! v4l2h264dec ! jpegenc ! identity eos-after=3 ! multifilesink location=%05d.jpeg + i.e. forced eos after 3 buffers + the pipeline stalls on exit waiting for end of job. + We need to add some form of early exit detection, instead of the current + behaviour of only considering a job finish on PIC_END. + +* Support more formats + + The current frontend v4l2 layer only supports V4L2_PIX_FMT_HEVC and + V4L2_PIX_FMT_H264. + The backend logic supports other formats, so we should wire up the support + for further bitsream formats. + +* appropreate error handling: +allocation failure, mutex acquire failure etc. + +* remove all unused struct fields + +* change struct fields to 'bool' type or bitfield when appropreate +Likely good candidates are fields named '*_enable' , '*_on' + +* handle vdi_allocate_dma_memory failure , each function has to clean after itself + +* make sure that 'u32', 's32' etc. are only used when reading/writing hw +and change s32 to u32 when s32 is not required + +* power management handling - add (runtime_)suspen/resume cb where the clock is enabled + +* fix checkpatch issues (mostly fixes , only left to fix MACRO_ARG_REUSE, LONG_LINE) + +* revise logic of wave5_vpu_(dec/enc)_register_framebuffer + +* check if the normal kernel endianness/__swab32 routines are sufficient. (instead of the ones + implemented in the driver -- 2.30.2 [C&M] IMPORTANT NOTICE The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in some unexpected situation, please immediately notify the sender by replying email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, distribution, copying, or storage of this message or its attachments is strictly prohibited.
