lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 16 May 2014 09:53:50 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Bart Tanghe <bart.tanghe@...masmore.be>, thierry.reding@...il.com,
	michal.simek@...inx.com, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, rob@...dley.net, grant.likely@...aro.org,
	linux-pwm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [rfc]pwm: add xilinx pwm driver

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



Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ