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....
|
|
?
|
0x000F0000
|
|
Turns on top and bottom lcd
|
0x00100000
|
|
Turns off top and bottom lcd
|
0x00110040
|
|
PowerOnBacklight
|
0x00120040
|
|
PowerOffBacklight
|
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(see here regarding errors being written to GSP shared-mem). New services commands were added too, see above.
|