lkml.org 
[lkml]   [2008]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] UIO: generic platform driver
Hello Hans,

Hans J. Koch wrote:
> On Wed, Apr 23, 2008 at 10:56:29AM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > Uwe Kleine-König wrote:
> > > Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
> > > ---
> > > Hello,
> > >
> > > This is the former patch 4/4 after some discussion.
> > >
> > > Open issues:
> > > - clock name "uio" isn't considered good by Russell King
> > > I don't have a better suggestion
> > I added another branch[1] on my repo that doesn't have the dummy clk
> > patch and variant of this one that doesn't use the clk API.
> >
> > This way the clk API isn't needed anymore for my patch and the issue
> > about the clock name disappeard, too.
>
> Hi Uwe,
> sorry for the delay, I was away for a few days and had an awful lot of
> work when I came back.
>
> About your generic platform driver: I think we've got two choices, both
> of them are acceptable as far as I'm concerned:
>
> 1.) Use the clk API and make your driver depend on it. AFAICS, only ARM
> and PPC implement it right now. On some platforms, it will probably
> never be implemented. E.g. x86 doesn't have any clocks that could be
> controlled that way. It's probably only useful for SoCs.
> Advantages: People who need it get clk support for free, without having
> to write much code.
> Disadvantages: The generic platform driver is not available for all
> platforms. It might not be easy to implement the dependency in Kconfig
> in a way acceptable to all maintainers ;-)
>
> 2.) Don't use the clk API. I don't think we would lose much. Drivers
> could implement clk stuff in their board support. You could add some
> generic function pointers in struct uio_platdata that are called in
> open/release/probe/remove. That way, any platform specific stuff,
> including clk, could be handled.
> Advantages: The generic platform driver is available for all
> platforms, no need for dependencies in Kconfig.
> Disadvantages: People who need clk_* must write a lot of code within
> their board support file. Not nice and clean...
>
> I'm ready to accept 1.) or 2.), or even both of them (why can't we have
> two generic platform drivers?)
For now I suggest 2). Using the clk API might be implemented by a
generic open/release routine. Maybe I will look into that at a later
time. For now I'm happy without clk support, too.

For now you can find two patches in my uio branch at
git://www.modarm9.com/gitsrc/pub/people/ukleinek/linux-2.6.git uio

I rebased them to current Linus' master; otherwise they are unmodified
since the last posts. For completeness I'll resend them as a reply to
this mail.

For shortlog and diffstat see below.

Best regards
Uwe

Uwe Kleine-König (2):
UIO: don't let UIO_CIF and UIO_SMX depend twice on UIO
UIO: generic platform driver

drivers/uio/Kconfig | 10 +++-
drivers/uio/Makefile | 1 +
drivers/uio/uio_pdrv.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 127 insertions(+), 2 deletions(-)

--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
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/

\
 
 \ /
  Last update: 2008-05-20 11:25    [W:0.130 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site