[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
    Date said:
    > A lot of serial.c is actually completely hardware-independent, and
    > serial.c in many ways is already "two drivers", in that it both knows
    > how to handle the low-level hardware AND it knows how to handle the
    > higher-level issues. And I don't think it would be bad to split it up
    > some more.

    The problem is that if you start to decouple the chipset driver from the
    code which knows how to access the chip, you end up with lots of horrible
    indirect function calls in the inner loops. This isn't really going to help
    improve performance - and the serial driver has one of the biggest problems
    w.r.t latency already.

    I figure I can get away with it for the MTD code (see the interaction
    between the CFI chipset code and the 'map' modules) because flash is
    generally slow as hell anyway, but for serial it's just not that feasible.

    We have the same problem when readb() becomes something other than a
    #define or inline function.

    One possibility for serial might be to reuse the generic chipset code in
    source form rather than object form - i.e. define serial_readb() et al.
    functions for your particular board/bus/mapping and then
    #include <generic_16550.c>. That's quite ugly though.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:37    [W:0.022 / U:37.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site