Re: [PATCH 2/2] m68k/atari - atafb: convert allocation of fb ram to new interface
Hi Michael,
On Thu, Mar 20, 2014 at 9:17 AM, schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
>> kernel_set_cachemode(screen_base, screen_len,
>> IOMAP_WRITETHROUGH);
>>
>> woops, that won't work with the virt_to_phys() above, nor with transparent
>> translation. I guess it writes to a non-existent pointer table,
>> causing the crash?
>
> You mean kernel_set_cachemode wants a physical address?
No, it wants memory mapped using the page tables. Probably it will
work only for System RAM, not for MMIO mapped in head.S.
> Not sure the mapping in head.S is actually per transparent translation for
> 040 or 060. But I'll try with that chunk of code disabled (the early mapping
> is done as NOCACHE_SER so we don't really need all of that if the kernel is
> not in ST-RAM).
it's using mmu_map, not mmu_map_tt, so no transparent translation.
> The last log line I get is:
>
> atafb_init: start
> atafb_init: initializing Falcon hw
> atafb: screen_base ff001000 real_screen_base 00001000 screen_len 69632
> Determined 640x400, depth 1
> virtual 640x870
>
> which is a bit further down.
>
> I guess it dies in register_framebuffer() - the next log entry is missing:
>
> fb_info(&fb_info, "frame buffer device, using %dK of video memory\n",
> screen_len >> 10);
And register_framebuffer() will write to the frame buffer, I think.
So info->screen_base may be incorrect.
Yep:
static void atafb_set_disp(struct fb_info *info)
{
atafb_get_var(&info->var, info);
atafb_get_fix(&info->fix, info);
info->screen_base = (void *)info->fix.smem_start;
}
Missing atari_stram_to_virt().
Any other casts that indicate bugs? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Reply to: