[PATCH v6 4/6] staging: media: wave5: Add TODO file

[PATCH v6 4/6] staging: media: wave5: Add TODO file

[Nas Chung]

From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>

Add a TODO file listing all that is need for destaging.

Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 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.

Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Greg Kroah-Hartman]

On Thu, Mar 31, 2022 at 09:55:10AM +0000, Nas Chung wrote:
> From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> 
> Add a TODO file listing all that is need for destaging.
> 
> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> ---
>  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.

Then why not just wait?  Why merge this now?  What is the benifit of us
taking this code at this point in time for hardware that is no one has
as it is not even created?

thanks,

greg k-h

Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Daniel Palmer]

Hi Greg,

On Thu, 31 Mar 2022 at 20:32, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> > +  Until we can test and resolve any issues on final silicon (due 2H 2021)
> > +  this driver should remain in staging.
>
> Then why not just wait?  Why merge this now?  What is the benifit of us
> taking this code at this point in time for hardware that is no one has
> as it is not even created?

FWIW there is an SoC that is supported (if console from initramfs on
uart counts..) in mainline, Sigmastar ssd202d, that has this IP so it
exists in the wild.
I have tried to get this driver running on it and it did something but
didn't get far enough to actually decode video.

Cheers,

Daniel

Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Greg Kroah-Hartman]

On Thu, Mar 31, 2022 at 08:42:40PM +0900, Daniel Palmer wrote:
> Hi Greg,
> 
> On Thu, 31 Mar 2022 at 20:32, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > > +  Until we can test and resolve any issues on final silicon (due 2H 2021)
> > > +  this driver should remain in staging.
> >
> > Then why not just wait?  Why merge this now?  What is the benifit of us
> > taking this code at this point in time for hardware that is no one has
> > as it is not even created?
> 
> FWIW there is an SoC that is supported (if console from initramfs on
> uart counts..) in mainline, Sigmastar ssd202d, that has this IP so it
> exists in the wild.
> I have tried to get this driver running on it and it did something but
> didn't get far enough to actually decode video.

According to the text in this driver, it will not work on these hardware
as it is broken.  Unless that text is incorrect?

greg k-h

Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Daniel Palmer]

Hi Greg,

On Thu, 31 Mar 2022 at 20:52, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> According to the text in this driver, it will not work on these hardware
> as it is broken.  Unless that text is incorrect?

I think that's for risc-v.
The other chip this is in is ARM Cortex A7. The crusty vendor linux
BSP for this chip manages to play videos using it so it does work in a
real piece of hardware.

Cheers,

Daniel

Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Greg Kroah-Hartman]

On Thu, Mar 31, 2022 at 09:00:28PM +0900, Daniel Palmer wrote:
> Hi Greg,
> 
> On Thu, 31 Mar 2022 at 20:52, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > According to the text in this driver, it will not work on these hardware
> > as it is broken.  Unless that text is incorrect?
> 
> I think that's for risc-v.
> The other chip this is in is ARM Cortex A7. The crusty vendor linux
> BSP for this chip manages to play videos using it so it does work in a
> real piece of hardware.

So are you going to be able to work with this driver to get it out of
staging if you have the hardware?  Otherwise it makes no sense to stick
it here for a year without anyone being able to work on it.

thanks,

greg k-h

RE: [PATCH v6 4/6] staging: media: wave5: Add TODO file

[Nas Chung]

Sorry for insufficient information in TODO file.

The j721s2 board which i've tested v4l2 driver is already existed.
- https://lwn.net/Articles/877594/
- I will update the TODO file to include the test result of J721S2 EVM board.

And, I'm going to work with this driver to get it out of staging.

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: Thursday, March 31, 2022 9:31 PM
> To: Daniel Palmer <daniel@0x0f.com>
> Cc: Nas Chung <nas.chung@chipsnmedia.com>; linux-media@vger.kernel.org;
> Dafna Hirschfeld <dafna.hirschfeld@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; open list:STAGING SUBSYSTEM <linux-
> staging@lists.linux.dev>; open list <linux-kernel@vger.kernel.org>;
> laurent.pinchart@ideasonboard.com; hverkuil@xs4all.nl; kernel@collabora.com;
> dafna3@gmail.com; bob.beckett@collabora.com; kiril.bicevski@collabora.com;
> lafley.kim <lafley.kim@chipsnmedia.com>; Scott Woo
> <scott.woo@chipsnmedia.com>; olivier.crete@collabora.com;
> dan.carpenter@oracle.com; rdunlap@infradead.org
> Subject: Re: [PATCH v6 4/6] staging: media: wave5: Add TODO file
> 
> On Thu, Mar 31, 2022 at 09:00:28PM +0900, Daniel Palmer wrote:
> > Hi Greg,
> >
> > On Thu, 31 Mar 2022 at 20:52, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > According to the text in this driver, it will not work on these
> > > hardware as it is broken.  Unless that text is incorrect?
> >
> > I think that's for risc-v.
> > The other chip this is in is ARM Cortex A7. The crusty vendor linux
> > BSP for this chip manages to play videos using it so it does work in a
> > real piece of hardware.
> 
> So are you going to be able to work with this driver to get it out of
> staging if you have the hardware?  Otherwise it makes no sense to stick it
> here for a year without anyone being able to work on it.
> 
> thanks,
> 
> greg k-h