| Message ID | 1567591618-22467-1-git-send-email-loic.poulain@linaro.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | media: venus: core: Fix msm8996 frequency table | expand |
Hi Loic, Thanks for the patch! On 9/4/19 1:06 PM, Loic Poulain wrote: > In downstream driver, there are two frequency tables defined, > one for the encoder and one for the decoder: > > /* Encoders / > <972000 490000000 0x55555555>, / 4k UHD @ 30 / > <489600 320000000 0x55555555>, / 1080p @ 60 / > <244800 150000000 0x55555555>, / 1080p @ 30 / > <108000 75000000 0x55555555>, / 720p @ 30 */ > > /* Decoders / > <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / > < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / > < 489600 150000000 0xffffffff>, / 1080p @ 60 / > < 244800 75000000 0xffffffff>; / 1080p @ 30 */ > > It shows that encoder always needs a higher clock than decoder. > > In current venus driver, the unified frequency table is aligned > with the downstream decoder table which causes performance issues > in decoding scenarios. Fix that by aligning frequency table on s/decoding scenarios/encoding scenarios > worst case (encoding). Did you checked the exact rate from clk_summary? Checking the frequency table for subcore0|1 from mmcc-msm8996.c clock driver shows that the tables are slightly different for higher rates. Otherwise, I'd take the patch but it would be better to align the frequency tables to avoid confusions. On the other side we can split freq table to encode and decode tables, but I'm still not sure is it possible to have: subcore0_freq != subcore1_freq. > > Signed-off-by: Loic Poulain <loic.poulain@linaro.org> > --- > drivers/media/platform/qcom/venus/core.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c > index 0acc757..1e80689 100644 > --- a/drivers/media/platform/qcom/venus/core.c > +++ b/drivers/media/platform/qcom/venus/core.c > @@ -427,10 +427,11 @@ static const struct venus_resources msm8916_res = { > }; > > static const struct freq_tbl msm8996_freq_table[] = { > - { 1944000, 490000000 }, /* 4k UHD @ 60 */ > - { 972000, 320000000 }, /* 4k UHD @ 30 */ > - { 489600, 150000000 }, /* 1080p @ 60 */ > - { 244800, 75000000 }, /* 1080p @ 30 */ > + { 1944000, 490000000 }, /* 4k UHD @ 60 (decode only) */ > + { 972000, 490000000 }, /* 4k UHD @ 30 */ > + { 489600, 320000000 }, /* 1080p @ 60 */ > + { 244800, 150000000 }, /* 1080p @ 30 */ > + { 108000, 75000000 }, /* 720p @ 30 */ > }; > > static const struct reg_val msm8996_reg_preset[] = { >
On 9/11/19 5:40 PM, Loic Poulain wrote: > On Wed, 11 Sep 2019 at 11:29, Stanimir Varbanov < > stanimir.varbanov@linaro.org> wrote: > >> Hi Loic, >> >> Thanks for the patch! >> >> On 9/4/19 1:06 PM, Loic Poulain wrote: >>> In downstream driver, there are two frequency tables defined, >>> one for the encoder and one for the decoder: >>> >>> /* Encoders / >>> <972000 490000000 0x55555555>, / 4k UHD @ 30 / >>> <489600 320000000 0x55555555>, / 1080p @ 60 / >>> <244800 150000000 0x55555555>, / 1080p @ 30 / >>> <108000 75000000 0x55555555>, / 720p @ 30 */ >>> >>> /* Decoders / >>> <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / >>> < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / >>> < 489600 150000000 0xffffffff>, / 1080p @ 60 / >>> < 244800 75000000 0xffffffff>; / 1080p @ 30 */ >>> >>> It shows that encoder always needs a higher clock than decoder. >>> >>> In current venus driver, the unified frequency table is aligned >>> with the downstream decoder table which causes performance issues >>> in decoding scenarios. Fix that by aligning frequency table on >> >> s/decoding scenarios/encoding scenarios >> >>> worst case (encoding). >> >> Did you checked the exact rate from clk_summary? Checking the frequency >> table for subcore0|1 from mmcc-msm8996.c clock driver shows that the >> tables are slightly different for higher rates. >> >> Otherwise, I'd take the patch but it would be better to align the >> frequency tables to avoid confusions. >> > > Thanks, yes I'm going to send a V2 with aligned freqs, note however that > with my setup (DB820C), debugfs reported clk rates seem to be a bit > misaligned. > I get either 75000000, 150000000, 326666666 or 490000000... regardless > frequency table. What kernel version is that?
diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 0acc757..1e80689 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -427,10 +427,11 @@ static const struct venus_resources msm8916_res = { }; static const struct freq_tbl msm8996_freq_table[] = { - { 1944000, 490000000 }, /* 4k UHD @ 60 */ - { 972000, 320000000 }, /* 4k UHD @ 30 */ - { 489600, 150000000 }, /* 1080p @ 60 */ - { 244800, 75000000 }, /* 1080p @ 30 */ + { 1944000, 490000000 }, /* 4k UHD @ 60 (decode only) */ + { 972000, 490000000 }, /* 4k UHD @ 30 */ + { 489600, 320000000 }, /* 1080p @ 60 */ + { 244800, 150000000 }, /* 1080p @ 30 */ + { 108000, 75000000 }, /* 720p @ 30 */ }; static const struct reg_val msm8996_reg_preset[] = {
In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in decoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by: Loic Poulain <loic.poulain@linaro.org> --- drivers/media/platform/qcom/venus/core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)