From: Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>
To: Paul Sokolovsky <pmiscml@gmail.com>
Cc: ian <spyro@f2s.com>,
kernel-discuss@handhelds.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Date: Wed, 02 May 2007 01:17:33 +0400 [thread overview]
Message-ID: <4637AE6D.4090408@gmail.com> (raw)
In-Reply-To: <281618366.20070501230902@gmail.com>
Hello Paul,
Paul Sokolovsky wrote:
>> ASIC-related code (I mean core) forms additional platform layer, so I
>> suggest
>> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
>> ASIC drivers to drivers/asic/ directory.
>
> There problem here is the same - our target chips are not
> just ASICs.
You say they are chips so they are integrated circuits (ICs), they
are designed to solve some specific needs, so they are
application-specific ICs, i.e. ASICs, what's the problem?
> It just happens that the one we start with called such,
> but we have different ones too.
Interesting what are they?
Power management ICs? Power management + audio
+ touchscreen + ADC + USB transceiver + UART + whatever
all such chips may be considered as ASICs.
> It's still important that they contain
> blocks with different functionality, and drivers we propose deal with
> basic, common functionality of chips.
That different functionality blocks will be handled by appropriate
device drivers, and in general the drivers should not depend on
a particular ASIC but use common ASIC API.
But "common functionality" drivers are ASIC-specific.
> Now that it was pointed out that
> there's place in the tree for such drivers, it would be not wise to
> try to create another one.
>
>
>
Perhaps, so. Actually, MFD (multi functional device) doesn't
imply a platform-level device but ASIC seems does.
Thanks,
Dmitry
next prev parent reply other threads:[~2007-05-01 21:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 5:08 [RFC, PATCH 0/4] SoC base drivers Paul Sokolovsky
2007-05-01 8:39 ` Ben Dooks
2007-05-01 10:11 ` Paul Sokolovsky
2007-05-01 10:33 ` ian
2007-05-01 13:53 ` Dmitry Krivoschekov
2007-05-01 14:36 ` Paul Sokolovsky
2007-05-01 15:01 ` Richard Purdie
2007-05-01 17:18 ` Paul Sokolovsky
2007-05-01 18:58 ` Richard Purdie
2007-05-01 19:27 ` Russell King
2007-05-01 16:29 ` Dmitry Krivoschekov
2007-05-01 18:08 ` [Kernel-discuss] " ian
2007-05-01 19:08 ` Dmitry Krivoschekov
2007-05-01 20:09 ` Paul Sokolovsky
2007-05-01 21:17 ` Dmitry Krivoschekov [this message]
2007-05-02 13:39 ` Paul Sokolovsky
2007-05-01 15:55 ` ian
2007-05-01 16:38 ` Dmitry Krivoschekov
2007-05-01 17:12 ` Paul Sokolovsky
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=4637AE6D.4090408@gmail.com \
--to=dmitry.krivoschekov@gmail.com \
--cc=kernel-discuss@handhelds.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=pmiscml@gmail.com \
--cc=spyro@f2s.com \
/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.