Commit | Line | Data |
---|---|---|
ab42b818 | 1 | =========== |
60b59bea | 2 | Deferred IO |
ab42b818 | 3 | =========== |
60b59bea JK |
4 | |
5 | Deferred IO is a way to delay and repurpose IO. It uses host memory as a | |
6 | buffer and the MMU pagefault as a pretrigger for when to perform the device | |
01dd2fbf | 7 | IO. The following example may be a useful explanation of how one such setup |
60b59bea JK |
8 | works: |
9 | ||
10 | - userspace app like Xfbdev mmaps framebuffer | |
529e55b6 | 11 | - deferred IO and driver sets up fault and page_mkwrite handlers |
60b59bea | 12 | - userspace app tries to write to mmaped vaddress |
529e55b6 NP |
13 | - we get pagefault and reach fault handler |
14 | - fault handler finds and returns physical page | |
60b59bea JK |
15 | - we get page_mkwrite where we add this page to a list |
16 | - schedule a workqueue task to be run after a delay | |
17 | - app continues writing to that page with no additional cost. this is | |
18 | the key benefit. | |
19 | - the workqueue task comes in and mkcleans the pages on the list, then | |
ab42b818 | 20 | completes the work associated with updating the framebuffer. this is |
60b59bea JK |
21 | the real work talking to the device. |
22 | - app tries to write to the address (that has now been mkcleaned) | |
23 | - get pagefault and the above sequence occurs again | |
24 | ||
25 | As can be seen from above, one benefit is roughly to allow bursty framebuffer | |
26 | writes to occur at minimum cost. Then after some time when hopefully things | |
27 | have gone quiet, we go and really update the framebuffer which would be | |
28 | a relatively more expensive operation. | |
29 | ||
30 | For some types of nonvolatile high latency displays, the desired image is | |
31 | the final image rather than the intermediate stages which is why it's okay | |
01dd2fbf | 32 | to not update for each write that is occurring. |
60b59bea JK |
33 | |
34 | It may be the case that this is useful in other scenarios as well. Paul Mundt | |
35 | has mentioned a case where it is beneficial to use the page count to decide | |
36 | whether to coalesce and issue SG DMA or to do memory bursts. | |
37 | ||
38 | Another one may be if one has a device framebuffer that is in an usual format, | |
39 | say diagonally shifting RGB, this may then be a mechanism for you to allow | |
40 | apps to pretend to have a normal framebuffer but reswizzle for the device | |
41 | framebuffer at vsync time based on the touched pagelist. | |
42 | ||
43 | How to use it: (for applications) | |
44 | --------------------------------- | |
45 | No changes needed. mmap the framebuffer like normal and just use it. | |
46 | ||
47 | How to use it: (for fbdev drivers) | |
48 | ---------------------------------- | |
49 | The following example may be helpful. | |
50 | ||
ab42b818 | 51 | 1. Setup your structure. Eg:: |
60b59bea | 52 | |
ab42b818 MCC |
53 | static struct fb_deferred_io hecubafb_defio = { |
54 | .delay = HZ, | |
55 | .deferred_io = hecubafb_dpy_deferred_io, | |
56 | }; | |
60b59bea JK |
57 | |
58 | The delay is the minimum delay between when the page_mkwrite trigger occurs | |
59 | and when the deferred_io callback is called. The deferred_io callback is | |
60 | explained below. | |
61 | ||
ab42b818 MCC |
62 | 2. Setup your deferred IO callback. Eg:: |
63 | ||
64 | static void hecubafb_dpy_deferred_io(struct fb_info *info, | |
65 | struct list_head *pagelist) | |
60b59bea JK |
66 | |
67 | The deferred_io callback is where you would perform all your IO to the display | |
68 | device. You receive the pagelist which is the list of pages that were written | |
69 | to during the delay. You must not modify this list. This callback is called | |
70 | from a workqueue. | |
71 | ||
ab42b818 MCC |
72 | 3. Call init:: |
73 | ||
60b59bea JK |
74 | info->fbdefio = &hecubafb_defio; |
75 | fb_deferred_io_init(info); | |
76 | ||
ab42b818 MCC |
77 | 4. Call cleanup:: |
78 | ||
60b59bea | 79 | fb_deferred_io_cleanup(info); |