From mboxrd@z Thu Jan 1 00:00:00 1970 From: ivan.khoronzhuk@ti.com (Ivan Khoronzhuk) Date: Thu, 6 Feb 2014 16:09:05 +0200 Subject: [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer In-Reply-To: References: <1391608060-10760-1-git-send-email-ivan.khoronzhuk@ti.com> <1391608060-10760-3-git-send-email-ivan.khoronzhuk@ti.com> <52F26444.5090707@ti.com> <52F28875.9000200@ti.com> Message-ID: <52F39781.3060405@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/06/2014 01:36 AM, Rob Herring wrote: > On Wed, Feb 5, 2014 at 12:52 PM, Ivan Khoronzhuk wrote: >> On 02/05/2014 07:41 PM, Rob Herring wrote: >>> On Wed, Feb 5, 2014 at 10:18 AM, Ivan Khoronzhuk >>> wrote: >>>> On 02/05/2014 04:39 PM, Rob Herring wrote: >>>>> On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk >>>>> wrote: >>>>>> This patch provides bindings for the 64-bit timer in the KeyStone >>>>>> architecture devices. The timer can be configured as a general-purpose >>>>>> 64-bit >>>>>> timer, dual general-purpose 32-bit timers. When configured as dual >>>>>> 32-bit >>>>>> timers, each half can operate in conjunction (chain mode) or >>>>>> independently >>>>>> (unchained mode) of each other. >>>>> This is software configurable or h/w design time configurations? >>>>> >>>>> Rob >>>>> >>>> This is h/w design time configurations >>> Then it seems like the binding should provide for describing those >>> differences either with a property or different compatible strings. >>> >>> Rob >> Oh..sorry, seems I didn't catch, this is configurable by software. >> These configurations are like modes in which timer can work >> and they are not different hardware IPs. It depends on driver in >> which mode it should work. > In that case, > > Acked-by: Rob Herring Thanks -- Regards, Ivan Khoronzhuk