GSP service "gsp::Gpu"
The GSP module starts a thread for handling commands for each service session, a maximum of 4 processes can use this service at once. Official applications have an optional code-path which writes to registers during initialization, this is normally not used however.
GSP service "gsp::Lcd"
| Command Header
|
Available since system version
|
Description
|
| 0x0001....
|
|
?
|
| 0x0002....
|
|
?
|
| 0x0003....
|
|
?
|
| 0x0004....
|
|
?
|
| 0x0005....
|
|
?
|
| 0x0006....
|
|
?
|
| 0x0007....
|
|
?
|
| 0x0008....
|
|
?
|
| 0x0009....
|
|
?
|
| 0x000A....
|
|
?
|
| 0x000B....
|
|
?
|
| 0x000C....
|
|
?
|
| 0x000D....
|
|
?
|
| 0x000E....
|
|
?
|
| 0x000F....
|
|
?
|
| 0x0010....
|
|
?
|
| 0x0011....
|
|
?
|
| 0x0012....
|
|
?
|
| 0x0013....
|
|
?
|
| 0x0014....
|
8.0.0-18
|
This only returns an error. Uninitialized data(not set by this command itself) is also written to u8 cmdreply_word[2].
|
| 0x0015....
|
8.0.0-18
|
This only returns an error. Uninitialized data(not set by this command itself) is also written to u32 cmdreply_word[2].
|
Unlike gsp::Gpu, GSP module does not start a separate thread for handling these service commands.
Version history
| Version
|
Changes
|
| v8196
|
Support for the new LINEAR memory region was implemented(for cache commands and vaddr->physaddr conversion). Support for the new process-mem 0x1E800000 region(however the GPU can't actually access this memory) was added for vaddr->physaddr conversion. Originally GSP module ignored vaddr->physaddr conversion errors(like with vaddrs outside of the handled ranges) and just wrote physaddr value0 to the GPU registers, however now GSP module returns an error for that instead(bitmask 0x80 gets set in GSP shared memory somewhere for that now). New services commands were added too, see above.
|