From: Armin Steinhoff <armin@steinhoff.de>
To: Ben Nizette <bn@niasdigital.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [UIO] SMX UIO interface
Date: Fri, 03 Sep 2010 10:36:08 +0200 [thread overview]
Message-ID: <4C80B378.5060509@steinhoff.de> (raw)
In-Reply-To: <59079FAE-8CF7-4E2F-B5C6-77B6A6D2B8F8@niasdigital.com>
Ben Nizette wrote:
> On 02/09/2010, at 8:13 PM, Armin Steinhoff wrote:
>
>> Ben Nizette wrote:
>>> On 01/09/2010, at 5:22 PM, Armin Steinhoff wrote:
>>>
>>>> Hi Ben,
>>>>
>>>> I have a question about the SMX UIO Interface.
>>>>
>>>> In the SMX module you are reading the data of the platform resourses:
>>>>
>>>> regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>>> if (!regs) {
>>>> dev_err(&dev->dev, "No memory resource specified\n");
>>>> goto out_free;
>>>> }
>>>>
>>>> But who sets these data initially ?
>>> Who ever sets up the platform device that will bind to this driver, usually the board code (eg on avr32 arch/avr32/boards/*/setup.c, ARM is somewhere under arch/arm/mach-*/ I think).
>>>
>>> The board code would create an array of struct resource with the appropriate memory regions and an IRQ entry, create a struct platform_device with the right content to bind to that driver, set the platform_device .resource field to the previously created array then call platform_device_register() to kick things off.
>>>
>> That means there is additionally an individual driver of the board and the UIO interface is just for open up the hardware interfaces ?
> Um, sort of, I guess.. :-)
>
> The board code isn't a driver, it's just code that gets run at startup whose job is to register all the devices on the board. If your board only contains probe-able busses then you might not need any board code at all but if you've got busses which can't be automatically discovered then something else needs to tell the kernel what devices are where.
>
> Maybe a good place to start would be to read up a bit more on the Linux device model and look through some example board code, you'll probably learn more than me just answering small bits like this :-)
Yes, you are right. I'm currently learning a lot about the Linux
driver model ... it's a real jungle :)
Thanks for your small bits and bytes
--Armin
> --Ben.
>
>> Thanks
>>
>> --Armin
>>
>>
>>> --Ben.
>>>
>>>> Cheers
>>>>
>>>> --Armin
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2010-09-03 8:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 7:22 [UIO] SMX UIO interface Armin Steinhoff
2010-09-01 23:33 ` Ben Nizette
2010-09-02 10:13 ` Armin Steinhoff
2010-09-02 11:45 ` Ben Nizette
2010-09-03 8:36 ` Armin Steinhoff [this message]
2010-09-04 14:22 ` [ISA bus] or platform bus ? Armin Steinhoff
2010-09-05 18:39 ` [PC/104 interrupt bug] Fedora 13 problem Armin Steinhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C80B378.5060509@steinhoff.de \
--to=armin@steinhoff.de \
--cc=bn@niasdigital.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox