lv1_gpu_device_map (212)

Map a device into logical address space. Address needs to be ioremapped before use.

result = lv1_gpu_device_map( /*IN*/ dev_id, /*OUT*/ &lpar_addr, &lpar_size );

Notes:

Info taken from kboot-10\dl\linux-2.6.16\sound\powerpc\snd_ps3pf.c (kboot-20061208) where the audio front-end registers are mapped into memory. Two calls to lv1_gpu_device_map are performed, the first when dev_id = 1, to obtain the audio interrupt (Audio IRQ Outlet) and a second time when dev_id = 2 to obtain a mapping of the register block (Audio Registers).

lpar_addr is a virtual address, created by the Hypervisor. Multiple calls to lv1_gpu_device_map with the same dev_id return successfully, but the lpar_address returned for each is different (if there have been no intermediary lv1_gpu_device_unmap calls). These various virtual lpar_addr values all alias the same physical location in memory.

It is interesting that when dev_id = 4, LV1_ILLEGAL_PARAMETER_VALUE is returned with lpar_addr and lpar_size set to the values returned from the previous call - for the first call when dev_id = 0, values also appear to be set (though these could be garbage values)

dev_id 1 gives a location used to process IRQ’s from the audio and dev_id 2 gives the base address of the Audio Hardware registers. From published Sony documents (http://www.watch.impress.co.jp/game/docs/20060329/3dps303.htm), Audio is believed to be on the RSX, this call seems to confirm that. Access to the audio after this mapping call (it would appear) bypasses the Hypervisor and occurs directly on the RSX hardware. 3,5,6,7,8 are currently unknown. Presumably 0 and 4 are otherwise valid parameters blocked by the Hypervisor for OtherOS (ie, they may function for Games) otherwise I would have expected a return result of -20 for them. So rather than just being a bridge for audio into HDMI, it is for all audio.

Also interesting is that the GPU version number returned by lv1_gpu_context_allocate appears at address 0×10 in the device 1 dump, though this of course may be complete coincidence.

dev_id 7 appears to be a video device. It is not possible to map the entire reported memory space (0×10000), only areas 0×0000 to 0x0fff and 0×2000 to 0x2fff (discovered via laborious trial and error testing, mapping other areas causes the PS3 to hang without warning). In both mappable areas, the current screen resolution can be seen at locations 0×200 and 0×210. Changes to the ps3 video mode (e.g. using the ps3videomode utility) can be observed in the mapped areas, but modifying the values directly does not affect the screen resolution. Although both areas contain different values, there appear to be parts in common, as changing the values at 0×200 and 0×210 directly in one area also causes the same values in the other area to change.

Given the screen resolution connection, it could be possible that this device is a mapping of the GPU display heads:

• Out of 16Kb, only two areas are mappable (= number of accessible display heads)
• Mappable areas are 2Kb apart → 8 total display heads (= size of display heads array returned by lv1_gpu_context_allocate)

dev_id 8 appears to be a mapping of video RAM at offset 0x0ff10000. This region of video memory is referenced by RSX DMA objects but its purpose is unknown.