From: Pantelis Antoniou <panto@intracom.gr>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
Date: Thu, 05 May 2005 16:27:48 +0300 [thread overview]
Message-ID: <427A1F54.5020108@intracom.gr> (raw)
In-Reply-To: <fb6d7d007dc9f75553f1390b86c5f72b@embeddededge.com>
Dan Malek wrote:
>
> On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote:
>
>> In my experience it's much easier to configure these things once.
>> Hunting down where the driver modifies pins & clocks is a nightmare, if
>> you ever use a non standard configuration.
>
>
> That doesn't quite work, as we have discussed before. The problem with
> setting them in the board set up is you can have loadable modules and
> select among several different IO pin configurations depending upon
> what you load. So, the plan is to have the drivers make a generic
> call out request using feature_call() to the supporting functions in the
> board specific directory. This is for more than just IO pin
> configurations,
> since boards may have power management or other external logic that
> has to be routed to the physical interface. For example, the SCC Ethernet
> driver will perform a feature_call() during set up requesting any necessary
> configuration for SCC2. The board specific function can chose to ignore
> this and get the "default" configuration, or to do whatever is necessary
> unique to the board to enable the external data path. All that drivers
> know
> is there are a couple of specific places where they need configuration
> assistance, they don't care what the specific board has to do.
>
Sounds nice. I'm a much simpler guy it seems :)
> It's in the works and nearly done for a few example 85xx and 82xx
> boards and CPM2 drivers. I'll be checking it in shortly. I just haven't
> decided if I want a varargs list or a data structure for passing the
> information and results.
>
Mind sharing?
> Thanks.
>
> -- Dan
>
>
>
Regards
Pantelis
prev parent reply other threads:[~2005-05-05 13:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-04 14:35 [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx Vitaly Bordug
2005-05-04 22:43 ` Dan Malek
2005-05-05 11:21 ` Pantelis Antoniou
2005-05-05 12:40 ` Vitaly Bordug
2005-05-05 12:36 ` Pantelis Antoniou
2005-05-05 13:19 ` Dan Malek
2005-05-05 13:27 ` Pantelis Antoniou [this message]
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=427A1F54.5020108@intracom.gr \
--to=panto@intracom.gr \
--cc=dan@embeddededge.com \
--cc=linuxppc-embedded@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.