On Thu, Jun 8, 2017 at 8:11 PM, ayaka <ayaka@xxxxxxxxxxx> wrote: > > > On 06/08/2017 06:56 PM, Hans Verkuil wrote: >> >> Hi Alexandre, >> >> On 08/06/17 11:59, Alexandre Courbot wrote: >>> >>> On Thu, Jun 8, 2017 at 5:56 PM, Pawel Osciak <posciak@xxxxxxxxxxxx> >>> wrote: >>>> >>>> Hi, >>>> >>>> On Fri, May 19, 2017 at 1:08 AM, Hugues FRUCHET <hugues.fruchet@xxxxxx> >>>> wrote: >>>>> >>>>> Before merging this work Hans would like to have feedback from peers, >>>>> in >>>>> order to be sure that this is inline with other SoC vendors drivers >>>>> expectations. >>>>> >>>>> Thomasz, Pawel, could you give your view regarding ChromeOS and >>>>> Rockchip >>>>> driver ? >>>> >>>> The drivers for Rockchip codecs are submitted to the public Chromium OS >>>> kernel >>>> and working on our RK-based platforms. We have also since added a VP9 >>>> API as > > That driver still lacks a number of feature comparing to the rockchip > android driver, since google never requests them. Also the performance is > not as good as the android one. I'm not sure exactly what features or performance problems you're mentioning, but that's not the point. It's a reasonably simple driver without too much complexity, written with good V4L2 codec API compliance in mind and proven in the industry. I see it as a good starting point. > That is why I start to write a new driver myself. I think it would make sense to work on incrementally adding those missing features and performance optimizations, instead of spending time on unnecessary effort of doing the same basic work, which is already done in our driver. > Also the rockchip platform is very complex, that driver won't be work on all > the SoCs without a large of modification(now only two chips are supported) This is another story. The rockchip-vpu driver in ChromeOS 4.4 should be actually refactored into generic V4L2 stateless codec helpers (most of the shared code in current driver) + few separate drivers using those helpers, one for each physical IP block. Current design is there only because we thought there is more similarity between those IP blocks and we didn't have more time to actually clean it up later, after we realized that the assumption was false. Best regards, Tomasz
