lkml.org 
[lkml]   [2018]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ivtv: use arch_phys_wc_add() and require PAT disabled
    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@ou.edu> 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.

    - Nick

    \
     
     \ /
      Last update: 2018-03-12 05:05    [W:2.694 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site