linux-kernel - Re: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM

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, 23 Aug 2013 13:29:11 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Xiubo Li-B47053 <B47053@...escale.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Guo Shawn-R65073 <r65073@...escale.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"rob@...dley.net" <rob@...dley.net>,
	"ian.campbell@...rix.com" <ian.campbell@...rix.com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>
Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for Freescale
 FTM PWM

On 08/23/2013 01:36 AM, Thierry Reding wrote:
> On Thu, Aug 22, 2013 at 08:26:10AM +0200, Sascha Hauer wrote:
>> On Thu, Aug 22, 2013 at 02:55:42AM +0000, Xiubo Li-B47053 wrote:
>>> Hi Tomasz,
>>> 
>>> Thanks for your comments.
>>> 
>>> 
>>>> Could you explain meaning of this property more precisely?
>>>> I'm interested especially how is this related to the PWM IP
>>>> block and boards.
>>>> 
>>> 
>>> Yes. There are 8 channels most. While the pinctrls of 4th and
>>> 5th channels could be used by uart's Rx and Tx, then these 2
>>> channels won't be used for pwm output, so there will be 6
>>> channels available by the pwm. Thus, the pwm chip will register
>>> only 6 pwms(6 channels) most("fsl,pwm-channel-orders = {0 1 2 3
>>> 6 7}").And also the "fsl,pwm-channel-number" will be 6.
>> 
>> If the chip has eight PWMs I would register all of them. If some
>> of them are not routed out by the pinmux then just nothing
>> happens if you use them. In a sane devicetree they won't be
>> referenced anyway when they are not routed out of the SoC.
> 
> In that case, shouldn't this be hooked up to the pinctrl subsystem
> as well? As I understand the above, the logical thing would be for
> each PWM channel's .request() operation to configure the pinmuxing
> appropriately. And if it can't be configured as necessary then
> .request() should return an error (or propagate the error from the
> pinctrl subsystem).

I think the pin-muxing should be static, i.e. set up when the PWM
device as a whole probe()s, rather than being twiddled at request/free
time. Certainly the pinmux support in the device core is now set up to
acquire the default state right before probe(). I don't see a need to
do anything custom here.
--
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/