Re: [PATCH] qcom: update path for video firmware for vpu-3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 19, 2024 at 12:16:10PM GMT, Vikash Garodia wrote:
> 
> 
> On 7/18/2024 5:07 PM, Dmitry Baryshkov wrote:
> > On Thu, 18 Jul 2024 at 14:10, Dikshita Agarwal
> > <quic_dikshita@xxxxxxxxxxx> wrote:
> >>
> >> - Rename qcom/vpu-3.0/ to qcom/vpu/ to have common sub-folder for
> >>   new firmware files.
> >> - Create symlinks for firmware files for vpu-1.0 and vpu-2.0 in
> >>   the same sub-folder.
> >>
> >> Signed-off-by: Dikshita Agarwal <quic_dikshita@xxxxxxxxxxx>
> >> ---
> >>  WHENCE                    |   2 +-
> >>  qcom/vpu-3.0/vpu30_4v.mbn | Bin 2306664 -> 0 bytes
> >>  qcom/vpu/vpu10_4v.mbn     |   1 +
> >>  qcom/vpu/vpu20_4v.mbn     |   1 +
> >>  qcom/vpu/vpu30_4v.mbn     | Bin 0 -> 2306664 bytes
> > 
> > Ok. You know that a single instance of the file had troubles getting
> > through. Now you are sending it twice when it's not required at all.
> > 
> > Please fix your setup so that git diff / git format-patch shows
> > renames are renames, not as an remove-and-add pair. Git does that
> > _by_default_, so it's something in your setup that changed this.
> > Please revert to the default behaviour.
> > 
> > This is how it looks by default:
> > 
> > diff --git a/qcom/vpu-3.0/vpu30_4v.mbn b/qcom/vpu/vpu30_4v.mbn
> > similarity index 100%
> > rename from qcom/vpu-3.0/vpu30_4v.mbn
> > rename to qcom/vpu/vpu30_4v.mbn
> > 
> > Also please consider using GitLab MRs or pull requests instead of
> > sending huge emails with multi-megabyte binary patches. It's all
> > described in README.md. And I think it should have been added to
> > Qualcomm internal documentation on upstraming.
> I agree MR/PR is the right way to do it for larger binaries, in that case,
> should the README.md be updated to keep the approach limited to MR/PR ? I see
> the approach to send the bins as email is also mentioned as one of the approach.

It's included because it still is a possible approach. For example
Adreno GPU is several KB and doesn't require any special handling. On
the other hand, 2MB binaries are definitely an above the sane boundary.
I'd say, one uses their own discretion to decide of the best way to send
data. In the end, you are not sending 2MB source patches too. Well, I
hope you are not.

> 
> Regards,
> Vikash
> > 
> >>  5 files changed, 3 insertions(+), 1 deletion(-)
> >>  delete mode 100644 qcom/vpu-3.0/vpu30_4v.mbn
> >>  create mode 120000 qcom/vpu/vpu10_4v.mbn
> >>  create mode 120000 qcom/vpu/vpu20_4v.mbn
> > 
> > Please move files to the new location and provide backwards-compatible
> > links rather than doing that backwards and providing
> > forward-compatible links instead.
> > Also please use Link: tag in WHENCE instead of creating symlinks manually.
> > 
> >>  create mode 100644 qcom/vpu/vpu30_4v.mbn
> >>
> >> diff --git a/WHENCE b/WHENCE
> >> index 5e91462..876f562 100644
> >> --- a/WHENCE
> >> +++ b/WHENCE
> >> @@ -5942,7 +5942,7 @@ https://developer.qualcomm.com/hardware/dragonboard-410c/tools
> >>
> >>  Driver: iris - Qualcomm Iris video codec accelerator
> >>
> >> -File: qcom/vpu-3.0/vpu30_4v.mbn
> >> +File: qcom/vpu/vpu30_4v.mbn
> >>
> >>  Version: VIDEO.VPU.3.1-0076
> >>
> > 
> > [skipped two instances of vpu30_4v.mbn]
> > 
> >> diff --git a/qcom/vpu/vpu20_4v.mbn b/qcom/vpu/vpu20_4v.mbn
> >> new file mode 120000
> >> index 0000000..56cdfe6
> >> --- /dev/null
> >> +++ b/qcom/vpu/vpu20_4v.mbn
> >> @@ -0,0 +1 @@
> >> +../vpu-2.0/venus.mbn
> >> \ No newline at end of file
> > 
> > 
> > 
> > --
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux