[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B98BC40.1030306@st.com>
Date: Thu, 11 Mar 2010 15:17:44 +0530
From: Shiraz HASHIM <shiraz.hashim@...com>
To: Linus Walleij <linus.ml.walleij@...il.com>
Cc: Viresh KUMAR <viresh.kumar@...com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
armando.visconti@...com, amit.goel@...com, vipin.kumar@...com,
rajeev-dlh.kumar@...com, deepak.sikri@...com,
ashish.priyadarshi@...com
Subject: Re: [PATCH 04/11] ST SPEAr: Added basic header files for SPEAr platform
Hello Linus,
On 3/11/2010 12:13 PM, Linus Walleij wrote:
> 2010/3/10 Viresh KUMAR <viresh.kumar@...com>:
>
>> One timer (or two channels) are used by clock event and clock source, but rest of
>> the timers are still available. So we need some way to export this functionality
>> of our hardware. It can be considered simply as a driver for GPT.
>
> The timer people have already explained well enough I think, we have some 16
> timers on U8500, one we use as clocksource, one for clock events and 14 are
> currently unused. I plan to add them as clock events as soon as there is some
> practical use for them.
> I think there is nothing stopping you from modelling some extra clock events
> for the remaining timers if you absolutely want to, the kernel will
> just disregard
> them currently, which is just as good/bad as the way you're exposing the custom
> API in these patches.
Can we use clockevents directly? I though they are abstracted by the kernel
framework and using them directly is not advisable/feasible.
regards
Shiraz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists