Functional testing of mainline vchiq driver
Michael Zoran
mzoran at crowfest.net
Mon Oct 31 03:52:17 PDT 2016
On Mon, 2016-10-31 at 11:42 +0100, Stefan Wahren wrote:
> > Phil Elwell <phil at raspberrypi.org> hat am 31. Oktober 2016 um 11:28
> > geschrieben:
> >
> >
> > On 31/10/2016 10:21, Stefan Wahren wrote:
> > >
> > > > Michael Zoran <mzoran at crowfest.net> hat am 30. Oktober 2016 um
> > > > 18:00
> > > > geschrieben:
> > > >
> > > > Going back to the cache line size issue.
> > > >
> > > > I'm wondering if it's important to people to not have an
> > > > override, if
> > > > it would just make sense to use a reasonably large value in the
> > > > DT that
> > > > works on all the platforms. Say 64 or 128. I mean, I think
> > > > the line
> > > > size is sent over to the firmware in the driver init so making
> > > > the
> > > > number too big is just a performance issue and not a
> > > > correctness issue,
> > > > right?
> > > >
> > >
> > > If i change g_cache_line_size to 64 on a Raspberry Pi B then i
> > > get this:
> > >
> > > $ vchiq_test -f 10
> > > Functional test - iters:10
> > > ======== iteration 1 ========
> > > vchiq_test: 1: Data corrupted at 0-0 (datalen 1, align fe0,
> > > server_align 0)
> > > ->
> > > 80
> > > vchiq_test: 891: func_data_test(service, size, PAGE_SIZE - align,
> > > srvr_align
> > > &
> > > 31) != VCHIQ_SUCCESS
> >
> > That's because the firmware doesn't read the cache line size value
> > from
> > the DTB - it knows which chip it is running on, and hence the
> > correct
> > value - so forcing an incorrect value for the ARM causes a
> > discrepancy.
> >
>
> In case VPU and ARM core need the same value i suggest to request the
> firmware
> about that.
> I assume there is no possibility to request the cache line size
> directly.
> So we need to decide based on something like
> RPI_FIRMWARE_GET_BOARD_MODEL?
Sorry, this is my fault. I misread the code. Your correct, the cache
line size is not sent over. The GPU just knows what the correct value
is.
Sorry again.
More information about the linux-rpi-kernel
mailing list