On Friday 17 August 2007, Hennerich, Michael wrote:
> Hi Dave,
>
> Right - our patch descriptions needs to be worked on.
Yes, please ... that makes reviewing easier!
> For a well experienced
> systems engineer being the same time the same guy who does the Hardware
> and the Software this is not an issue.
I guess I've rarely come across job descriptions like that.
Lowlevel software folk need to be able to use schematics and
often test equipment, but not design product circuits ... and
circuit designers rarely have responsibility to ship software.
On the other hand, maybe you want your "typical" customer to
be more of a systems integrator than anything else.
> We provide all kind of drivers utilizing almost any peripheral on
> Blackfin.
Chip vendors supporting Linux drivers for all their hardware.
What a pleasant change! :)
> While potentially causing conflicting usage, for someone without
> detailed hardware knowledge. The platform device board file is a good
> thing to track conflicting memory or IO space resources as well as IRQs.
> We also utilize platform device files for exactly these purposes.
>
> The dynamic resource allocation for pinmux and gpio seems to us the best
> way to handle things. The "resource allocation" mechanism will spill an
> error and dump in case conflicting usage is detected. It'll also tell
> you who is causing the conflicting usage.
That's your call, of course. I was pointing out why the "early"
binding of pin resources is the more usual strategy with Linux.
A "late" strategy is a bit surprising, and has its own issues.
> >That said, how you handle pinmux on Blackfin is your business.
> >
> >But you should know that this approach seems idiosyncratic and
> >more complex than needed: when pin config is done early and as
> >part of board setup, drivers don't need to care about it or to
> >handle any pinmux errors. And heck, products can sometimes be
> >shipped with the bootloader having done all pinmux setup, so
> >Linux won't need to worry about it at all. That can help ship
> >multiple board revisions using the same kernel.
>
> This works for fixed function boards.
That is, for typical products embedding Linux...
> But not for development boards
> where we provide lego like add on cards, and allow people to connect
> their homebrewn hardware.
Development boards are usually run differently than product
boards. All that flexibility in the development boards is
not necessarily a feature in the product version; it costs
space and time, which the application may need. Being able
to shift costs *early* and then drop them at runtime is a
useful strategy to apply in most places.
And heck -- most development setups get used only with one
card stack at a time, and it's easy to install new kernels
for new stacks.
- Dave
-
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]
