On Sun, 11 Mar 2018 23:04:02 -0500 Nick French <naf@xxxxxx> wrote: > On Sun, Mar 11, 2018 at 11:24:38PM +0000, Ian Armstrong wrote: > > On Sat, 10 Mar 2018 16:57:41 +0000 > > "French, Nicholas A." <naf@xxxxxx> wrote: > > > > > > > No what if the framebuffer driver is just requested as a > > > > > secondary step after firmware loading? > > > > > > > > Its a possibility. The decoder firmware gets loaded at the > > > > beginning of the decoder memory range and we know its length, so > > > > its possible to ioremap_nocache enough room for the firmware > > > > only on init and then ioremap the remaining non-firmware > > > > decoder memory areas appropriately after the firmware load > > > > succeeds... > > > > > > I looked in more detail, and this would be "hard" due to the way > > > the rest of the decoder offsets are determined by either making > > > firmware calls or scanning the decoder memory range for magic > > > bytes and other mess. > > > > The buffers used for yuv output are fixed. They are located both > > before and after the framebuffer. Their offset is fixed at > > 'base_addr + IVTV_DECODER_OFFSET + yuv_offset[]'. The yuv offsets > > can be found in 'ivtv-yuv.c'. The buffers are 622080 bytes in > > length. > > > > The range would be from 'base_addr + 0x01000000 + 0x00029000' to > > 'base_addr + 0x01000000 + 0x00748200 + 0x97dff'. This is larger than > > required, but will catch the framebuffer and should not cause any > > problems. If you wanted to render direct to the yuv buffers, you > > would probably want this region included anyway (not that the > > current driver supports that). > > Am I correct that you are talking about the possibility of > re-ioremap()-ing the 'yuv-fb-yuv' area *after* loading the firmware, > not of mapping ranges correctly on the first go-around? > > Because unless my math is letting me down, the decoder firmware is > already loaded from 'base_addr + 0x01000000 + 0x0' to 'base_addr + > 0x01000000 + 0x3ffff' which overlaps the beginning of the yuv range. Good catch. I'd forgotten that the firmware moves after being loaded. Although ivtvfb.c requests the offset to the framebuffer via the firmware, I don't believe it ever actually moves. The firmware allows more memory to be allocated for video buffers, but will then reduce the length of the framebuffer. At present the ivtv driver requests two more video buffers, so the framebuffer is shortened (the start address doesn't move). Those two buffers are located at base_addr + 0x16B0400 and 0x1748200. The now shortened framebuffer is of size 1704960 bytes (0x1A0400). These two offsets, plus those of the other video buffers are hardcoded in ivtv-yuv.c. It was written on the assumption that the location of the video buffers on the card are fixed. To the best of my knowledge, this has never caused a problem. >From ivtvfb.c : /* The osd buffer size depends on the number of video buffers allocated on the PVR350 itself. For now we'll hardcode the smallest osd buffer size to prevent any overlap. */ oi->video_buffer_size = 1704960; We know that one of the additional video buffers is at 0x16B0400, and that this is located at the end of the now shortened 1704960 byte framebuffer. 0x16B0400 - 0x1A0400 = 0x1510000. This gives us a 0x1A0400 byte framebuffer at base_addr + 0x1510000. Assuming the hardware is a PVR350 and is running stock firmware, I thinks its safe to say this won't change. -- Ian
