From: Michal Simek <monstr@monstr.eu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bart Tanghe <bart.tanghe@thomasmore.be>,
thierry.reding@gmail.com, michal.simek@xilinx.com,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, grant.likely@linaro.org,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc]pwm: add xilinx pwm driver
Date: Fri, 16 May 2014 09:53:50 +0200 [thread overview]
Message-ID: <5375C40E.2090904@monstr.eu> (raw)
In-Reply-To: <16896948.U7hTsgDub4@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
On 05/15/2014 06:30 PM, Arnd Bergmann wrote:
> On Thursday 15 May 2014 15:56:03 Michal Simek wrote:
>> IP is configurable as is normal for us.
>> You can select IP with just one timer.
>> It means register locations for specific timer are fixed.
>> http://www.xilinx.com/support/documentation/ip_documentation/xps_timer.pdf
>>
>> timer0 - offset 0x0
>> timer1 - offset 0x10 (doesn't need to be synthesized)
>>
>> There is one interrupt for both timers.
>>
>> Timers can be as timers (up/down count/ reload with or without IRQs)
>> But then one options is to use both timers and generate PWM signal.
>> From full ip description in DT you can see xlnx,gen0-assert = <1>;
>> which can suggest that this IP can output PMW signal.
>> (We can also detect if PWM0 signal is connected just to be sure
>> that PWM can be enabled).
>>
>> There is also capture trigger mode where external signal start/stop
>> timer counting.
>>
>> It means there are 3 modes - timer, capture and PWM.
>> Timer (clocksource, clockevent) requires specific handling,
>> PWM has own subsystem and not sure if there is any subsystem for
>> capture mode. Is there any?
>
> I don't think so. Possibly somewhere in IIO.
>
>> Not every timer configuration is suitable for all things
>> but fully configured timer can be used in all 3 modes.
>>
>>
>> I think that make sense to register and map all timers in the system
>> and classify them with flags (like can't be used for capture or PMW
>> if there are not outputs connected) and then use the best
>> timer for clocksource and clockevent. The best candidate is IP
>> with the lowest IRQ number in dual timer mode but in general
>> whatever timer can be used that's why we can't probably avoid
>> timer specification in DT.
>> In spite of this smells because you are saying via DT
>> to Linux which timer should be used for what purpose.
>
> We had discussions about this in the past, but I don't remember the
> outcome of that.
Will be great if someone is able to find out this outcome.
IRC: You can register as many clocksources as you like and core
itself choose the best one - the most accurate one.
But I don't think for our case there is any universal algorithm
which we can use to find out which timer should be used for this
purpose that's why selecting it via DT is probably the best what we
can do.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2014-05-16 7:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 11:26 [rfc]pwm: add xilinx pwm driver Bart Tanghe
2014-05-15 7:23 ` Arnd Bergmann
2014-05-15 8:50 ` Bart Tanghe
2014-05-15 10:33 ` Michal Simek
2014-05-15 11:30 ` Bart Tanghe
2014-05-15 11:54 ` Michal Simek
2014-05-15 9:48 ` Michal Simek
[not found] ` <53748D84.5040005-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2014-05-15 12:20 ` Arnd Bergmann
2014-05-15 13:56 ` Michal Simek
2014-05-15 16:30 ` Arnd Bergmann
2014-05-15 20:49 ` Thierry Reding
2014-05-16 8:44 ` Michal Simek
2014-05-16 7:53 ` Michal Simek [this message]
2014-09-04 10:41 ` Bart Tanghe
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=5375C40E.2090904@monstr.eu \
--to=monstr@monstr.eu \
--cc=arnd@arndb.de \
--cc=bart.tanghe@thomasmore.be \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=michal.simek@xilinx.com \
--cc=pawel.moll@arm.com \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).