lkml.org 
[lkml]   [2012]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner <jkridner@beagleboard.org> wrote:
>> Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of
>> a platform which parses tables and attaches devices to the right physical
>> bus in a manner they can be reliably probed even when the device has no
>> sane autodetect.
>
> I know I *am* the slow person in the room, but doesn't this approach
> require the code to be compiled into the kernel to support the devices
> ahead of time? While I think it might be reasonable to have hardware
> developers provide DT fragments in their EEPROMs, there's no way to
> get them to submit code patches in order to get their hardware to
> work. They need to ship hardware that works with pre-existing
> software, since there will be hundreds of boards created by people
> with little to no previous Linux experience (akin to Arduino). I seem
> to be missing how that approach would get us there.

If it is truly new hardware, then there really is no way around them
either a) submitting new kernel drivers or b) driving them from
userspace.

If it is devices with existing drivers populated onto new custom cape
boards, then the DT fragment approach should be sufficient for
populating them into the Linux driver model. (assuming of course those
drivers are already compiled into the kernel)

g.


\
 
 \ /
  Last update: 2012-11-05 02:41    [W:0.098 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site