On Thu, Feb 28, 2019 at 12:13 AM Ayaka <ay...@soulik.info> wrote: > > Hello all > > I am writing the v4l2 decoder driver for rockchip. Although I hear the > suggest from the Hans before, it is ok for decoder to use single plane buffer > format, but I still decide to the multi planes format. > > There is not a register for vdpau1 and vdpau2 setting the chroma starting > address in both pixel image output(it has one only applied for jpeg) and > reference. And the second plane should follow the first plane. It sounds > pretty fix for the single plane, but the single plane can’t describe offset > of the second plane, which is not the result of bytes per line multiples the > height. > > There are two different memory access steps in those rockchip device, 16bytes > for vdpau1 and vdpau2, 64bytes for rkvdec and 128bytes for rkvdec with a high > resolution. Although those access steps can be adjusted by the memory cache > registers. So it is hard to describe the pixel format with the single plane > formats or userspace would need to do more work.
Why not just adjust the bytes per line to a multiple of 16/64/128 bytes? Most of the platforms allocate buffers this way for performance reasons anyway. > > Currently, I use the dma-contig allocator in my driver, it would allocate the > second plane first, which results that the second plane has a lower address > than first plane, which device would request the second plane follows the > first plane. I increase the sizeimage of the first plane to solve this > problem now and let device can continue to run, but I need a way to solve > this problem. > > Is there a way to control how does dma-contig allocate a buffer? I have not > figured out the internal flow of the videobuf2. I know how to allocate two > planes in different memory region which the s5p-mfc does with two alloc_devs, > but that is not what I want. > > Last time in FOSDEM, kwiboo and I talk some problems of the request API and > stateless decoder, I say the a method to describe a buffer with many offsets > as the buffer meta data would solve the most of problems we talked, but I > have no idea on how to implement it. And I think a buffer meta describing a > buffer with many offsets would solve this problem as well. > > Sent from my iPad P.S. Please fix your email client to properly wrap the lines around the ~75 column line. Best regards, Tomasz
