• Karol Herbst's avatar
    drm/nouveau/pmu/fuc: don't use movw directly anymore · fe9748b7
    Karol Herbst authored
    Fixes failure to compile with recent envyas as a result of the 'movw'
    alias being removed for v5.
    
    A bit of history:
    
    v3 only has a 16-bit sign-extended immediate mov op. In order to set
    the high bits, there's a separate 'sethi' op. envyas validates that
    the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
    to simplify macros that load both the low and high word, a 'movw'
    alias was added which takes an unsigned 16-bit immediate. However the
    actual hardware op still sign extends.
    
    v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op
    is gone (loads 0 into the dst reg). However due to a bug in envyas,
    the movw alias still existed, and selected the no-longer-present v3
    16-bit immediate mov op. As a result usage of movw on v5 is the same
    as mov with a 0x0 argument.
    
    The proper fix throughout is to only ever use the 'movw' alias in
    combination with 'sethi'. Anything else should get the sign-extended
    validation to ensure that the intended value ends up in the
    destination register.
    
    Changes in fuc3 binaries is the result of a different encoding being
    selected for a mov with an 8-bit value.
    
    v2: added commit message written by Ilia, thanks for that!
    v3: messed up rebasing, now it should apply
    Signed-off-by: default avatarKarol Herbst <kherbst@redhat.com>
    Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
    fe9748b7
memx.fuc 8.97 KB