Re: [PATCH v8, 00/15] media: mtk-vcodec: support for M8192 decoder

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

 



Il 13/04/22 09:03, allen-kh.cheng ha scritto:
Hi Nicolas,

On Tue, 2022-04-12 at 10:48 -0400, Nicolas Dufresne wrote:
Le lundi 11 avril 2022 à 11:41 +0800, yunfei.dong@xxxxxxxxxxxx a
écrit :
Hi Nicolas,

On Thu, 2022-03-31 at 16:48 -0400, Nicolas Dufresne wrote:
Hi Yunfei,

thanks for the update, I should be testing this really soon.

Le jeudi 31 mars 2022 à 10:47 +0800, Yunfei Dong a écrit :
This series adds support for mt8192 h264/vp8/vp9 decoder
drivers.
Firstly, refactor
power/clock/interrupt interfaces for mt8192 is lat and core
architecture.

Similarly to MT8173 and MT8183, a shared* firmware is needed for
this
CODEC to
work (scp.img). I looked into linux-firmware[1] it has not been
added
for mt8192
yet. As your patches are getting close to be ready, it would be
important to
look into this so the patchset does not get blocked due to that.

best regards,
Nicolas

[1]

https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek__;!!CTRNKA9wMg0ARbw!zy4N6JDroSXtumXXa7MuxAgYAPAink8uyW-978vpWct8S3vOjBqXirFE8uTEHopHCovbSl0FNP9LPgWCEBrZfMIcvQ$
* Shared at least between MDP3 and MTK VCODEC from my knowledge


Thanks for your remind.

I have already sent mt8192 scp.img to github.


https://urldefense.com/v3/__https://github.com/yunfeidongmediatek/linux_fw_scp_8192/commit/3ac2fc85bc7dfcebdb92b5b5808b0268cdfb772d__;!!CTRNKA9wMg0ARbw!zy4N6JDroSXtumXXa7MuxAgYAPAink8uyW-978vpWct8S3vOjBqXirFE8uTEHopHCovbSl0FNP9LPgWCEBpf9F_nWA$
Waiting for to be merged.

On boards I have, the firmware is loaded from /lib/firmware/scp.img,
but with
this submission it will be in lib/firmware/mediatek/mt8192/scp.img .
I haven't
found anything around:

  drivers/remoteproc/mtk_scp.c:812:       char *fw_name = "scp.img";

That would use the platform path. This seems like a problem to me,
the
upstreaming of the firmware isn't being aligned with the were the
firmware is
picked by the upstream driver. Correct me if I got this wrong, but
I'd really
like to clarify this.

Nicolas


I am not sure why it's accepted the fw path of scp is
/lib/firmware/scp.img in mt8173/8183 but we upload scp.ing in
/lib/firmware/mediatek/mt8173(mt8183)/scp.img to

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek

Currently, the scp driver will load firmware in /lib/firmware/scp.img.
that means there is only one firmware for a specific platform.
I think we can send a PATCH to make firmware name of scp being more
flexible.

Maybe get firmware name from dts. e.g.,
&scp {
	status = "okay";
	firmware-name = "mediatek/mt81xx/scp.img";
};

Do you think it feasible?
If you have any concerns, please let us know.

Thanks,
Allen


Hello Allen,

what you proposed is exactly what has been done for other platforms because of
both per-device firmware differences (different signatures) and per-SoC (different
firmware entirely), found on TI K3, iMX DSP, Qualcomm MSS/DSP remoteproc and
others.

Of course this is an accepted way to resolve this situation: please go on!

Cheers,
Angelo




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux