Hi, On Wed, 2022-04-13 at 14:30 -0400, Nicolas Dufresne wrote: > Le mercredi 13 avril 2022 à 09:57 +0200, AngeloGioacchino Del Regno a > écrit : > > 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://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek__;!!CTRNKA9wMg0ARbw!0m0Cb9U6Xgnofw4ggJUaMzkm2gsZ6thjlvWu0pVGeeckYXcnIh7sz7C_NqNu96GAUaR1WA$ > > > > > > > > > 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! > > Looks good to me! (don't forget to keep a fallback to > /lib/firmware/scp.img to > maintain backward compatibility). > No problem. I have sent an upstream PATCH for scp firmware path. patchwork.kernel.org/project/linux-mediatek/list/?series=632268 thanks for your comments, Allen > > > > Cheers, > > Angelo > > > >
