On 9/11/19 5:40 PM, Loic Poulain wrote: > On Wed, 11 Sep 2019 at 11:29, Stanimir Varbanov < > stanimir.varbanov@xxxxxxxxxx> 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? -- regards, Stan
