gibsson
commented
2 years ago Hi, Thank you for your contribution, it is highly appreciated! Now, since it's your first contribution, here are some guidelines you need to comply to: 1- always sign-off your commits: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff 2- have a proper commit title + log, your current title is too long and doesn't even include the name of the driver you are fixing. https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#describe-your-changes 3- make sure to also use the proper indentation for your commit: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#style-check-your-changes 4- when you use the patch from someone else well use that patch, don't copy it, just cherry-pick it instead so that it keeps the ownership of its author So please cherry-pick the original patch you rely on, then have a follow-up patch with your own changes, explaining why (your text should be in the commit log, not in the pull request text). Regards, Gary
ThbaMG
Hello there,
since this is my first pull request please be gentle in pointing me into the right direction :)
During a project with a custom board i have attached a tc358743 to an imx8mm board via mipi csi. It took me quit some time to get the driver working for numerours lane and resolution configurations from 640x480 to 1920x1080.
I encountered some issues in the driver which i am using from your 5.10 repo which in my opinion should be corrected for this driver to work with RGB888 and higher lane numbers.
I had to fix the lane calculation since the prior one ignores hsync and vsync, however these bits have to be transmitted as well. This breaks the correct lane calculation if the frequency comes close to the maximum lane frequency. This leads to corrupted data which will be with correct crc.
The incoming FIFO size has been set to 16. In the header file it is stated that toshiba recommends using 300 as default. Without increasing this value the stream may skip some bytes from time to time if the input signal is not stable enough and has some jitter on it. This may even be caused by the tx35873 itself not being able to detect the pixel clk properly which seems to happen from time to time.
To be able to drive 1920x1080@60 in RGB888 with 3 bytes per pixel i had to increase the link-frequency since the prior one seems to work for YUV422 which transmits two pixels every four bytes. Therefore i integrated the patch from https://www.spinics.net/lists/linux-media/msg122228.html to support the higher frequencies.
I hope this patch is useful and may spare some time for the next poor soul who has to figure that out.
Best Regards,
Thomas