Actually it assembles, because addr is only <=0xffff and envyas is fine with that, but I could dig into that a bit more and see what is exactly wrong with that
> Martin Peres <[email protected]> hat am 1. März 2016 um 22:46 geschrieben: > > > On 01/03/16 23:38, Ilia Mirkin wrote: > > On Tue, Mar 1, 2016 at 4:36 PM, Martin Peres <[email protected]> wrote: > >> On 26/02/16 17:19, Karol Herbst wrote: > >>> currently there is no change, because nobody uses those macros yet, but > >>> they > >>> shouldn't stay broken > >>> > >>> Signed-off-by: Karol Herbst <[email protected]> > >>> --- > >>> drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc > >>> b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc > >>> index 0d5cbeb..bb59eb4 100644 > >>> --- a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc > >>> +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc > >>> @@ -252,12 +252,12 @@ > >>> #endif > >>> #define st(size, addr, reg) /* > >>> -*/ movw $r0 addr /* > >>> +*/ mov $r0 addr /* > >> > >> First of all, I know it is annoying, but we *need* to understand exactly > >> what movw is now doing. > >> > >> Secondly, I seem to remember that a 32 bit mov was not added until fuc3 or > > fuc5 > > Ah, right, fuc3 was on the GT2xx. Thanks! > > > >> something. Have you tried assembling this code on older fuc versions? > >> Pretty > >> sure it will fail. > > That's what the imm32() macro is for. > > Right, with the mov replace with the imm32 macro, this patch will have > my R-b! _______________________________________________ Nouveau mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/nouveau
