blob: 0b3ec75ff6274f4ecd70e0b0a9de4b4fe3f4b75f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
1) Import drivers using VCHI.
VCHI is just a tool to let drivers talk to the firmware. Here are
some of the ones we want:
- vc_mem (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/vc_mem.c)
This driver is what the vcdbg userspace program uses to set up its
requests to the firmware, which are transmitted across VCHIQ. vcdbg
is really useful for debugging firmware interactions.
- VCSM (https://github.com/raspberrypi/linux/tree/rpi-4.4.y/drivers/char/broadcom/vc_sm)
This driver is used for talking about regions of VC memory across
firmware protocols including VCHI. We'll want to extend this driver
to manage these buffers as dmabufs so that we can zero-copy import
camera images into vc4 for rendering/display.
2) Garbage-collect unused code
One of the reasons this driver wasn't upstreamed previously was that
there's a lot code that got built that's probably unnecessary these
days. Once we have the set of VCHI-using drivers we want in tree, we
should be able to do a sweep of the code to see what's left that's
unused.
3) Make driver more portable
Building this driver with arm/multi_v7_defconfig or arm64/defconfig
leads to data corruption during the following command:
vchiq_test -f 1
This should be fixed.
4) Fix kernel module support
Even the VPU firmware doesn't support a VCHI re-connect, the driver
should properly handle a module unload. This also includes that all
resouces must be freed (kthreads, debugfs entries, ...) and global
variables avoided.
5) Cleanup logging mechanism
The driver should probably be using the standard kernel logging mechanisms
such as dev_info, dev_dbg, and friends.
6) Documentation
A short top-down description of this driver's architecture (function of
kthreads, userspace, limitations) could be very helpful for reviewers.
|
