On Fri 17 Aug 2007 14:24, David Brownell pondered:
> Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves, or it dies.
> Other platforms completely decouple these issues from the
> IRQ infrastructure ... doing the pinmux and gpio claiming
> separately from the request_irq()/free_irq() paths, mostly
> as part of board setup. Doing all of that "early":
is early:
- early in the kernel?
- early before the kernel? (in the bootloader).
> - keeps those error returns from causing hard-to-track-down
> runtime bugs;
The current Blackfin implementation causes a run time message:
"the pin xxxx driver requested, was already claimed by yyy driver".
I don't think that is too bad?
> - works always, even on platforms where a given IRQ may
> appear on any of several pins/balls;
But requires custom bootloaders or board setup for every hardware platform?
Most of our users would not like that, since they do as you say - use the
same kernel - with different drivers on multiple platforms.
> - makes it easier to cross-check against board schematics,
> by keeping most board-specific setup in one source file;
Yes - but we are not talking about muxing a common peripheral (like a single
UART) out many different pins (A or B or C). The UART pins are fixed. If you
want the UART, you need to use pin A. If you want to use the I2C that also
sits on pin A, you will get the message:
"pin A, requested by I2C, was already claimed by UART driver".
> - shrinks the kernel's runtime footprint;
I agree - making things more flexible/easier to use - is normally more
complex/larger/slower. (I know - easier to use is a matter of opinion). Since
this is normally done once, in _init functions, I'm not sure that makes much
of a difference here.
> - allows the label to be more descriptive ... describeing
> exactly *which* IRQ, so that using the labels for better
> diagnostics actually gives better diagnostics.
I'm not sure what you mean?
> Again, not "wrong"; but probably sub-optimal. You might
> want to move towards earlier binding now, while Linux is
> still young on Blackfin and you don't have legacy code to
> worry about.
Our overall goal is to keep as much code - including bootloader - platform
agnostic, and not require people to write any of code/configuration data to
boot up something, and get things working in a semi-standard manner.
This still has it's limits - which is why we publish all our hardware designs.
If you implement things the similar way (because for the most part it is
fixed by the processor designer) - the bootloader/kernel/driver will just
work.
I would rather force a little extra complexity on me (as a kernel developer)
than have to answer thousands of questions from end users, who are trying to
move the kernel onto their hardware.
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
