lkml.org 
[lkml]   [2011]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel almost hangs when CONFIG_DRM_RADEON=y
    On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
    > On Mon, 29 Aug 2011, Borislav Petkov wrote:
    > > So, hypothetically speaking, hpa suggested then that we could pass
    > > firmware blobs over the linked list setup_data thing in the real-mode
    > > kernel header and parse_setup_data() can look at them and map them
    > > somewhere later for the driver to find. This should be doable because
    > > you're only gonna need a handful of blobs for CPU ucode, network and GPU
    > > if the last is compiled in.
    > >
    > > I wanted to take a serious look at that for the ucode loading, maybe I
    > > should try to shuffle some time for it...
    >
    > It would be very useful, yes.
    >
    > Alternatively, you could extend the initrd format to have a firmware
    > directory appended after the filesystem image. ACPI is going to abuse
    > the initrd in just that way to override ACPI tables very soon (patches
    > have been already submitted to linux-acpi),

    .. lemme guess: they didn't put the correct tables in the BIOS in the
    first place and now it is too late for a BIOS fix and want to shuffle in
    all those "fixes" through initrd ontop of ACPI. Oh boy, do I love all
    the ACPI crap stories :).

    > so if a more structured and extensible way to piggy-back early-init
    > data in the initrd is needed, it would be good to bring that to the
    > table NOW.

    Yeah, that's not more than an idea right now, I haven't even started
    playing with it. If it turns out to be more superior, it could be reused
    for other things too but right now it's too early to tell.

    --
    Regards/Gruss,
    Boris.


    \
     
     \ /
      Last update: 2011-08-30 09:21    [W:4.776 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site