From: "Mike Frysinger" <vapier.adi@gmail.com>
To: Bill Gatliff <bgat@billgatliff.com>
Cc: linux-embedded@vger.kernel.org
Subject: Re: [RFC 0/6] Proposal for a Generic PWM Device API
Date: Thu, 9 Oct 2008 00:05:39 -0400 [thread overview]
Message-ID: <8bd0f97a0810082105mabededn54ffcc937674af3@mail.gmail.com> (raw)
In-Reply-To: <48ED7E8E.3010504@billgatliff.com>
On Wed, Oct 8, 2008 at 23:46, Bill Gatliff wrote:
> Mike Frysinger wrote:
>>> Are you proposing that the API accommodate both input and output devices?
>>
>> i dont think we should preclude it from the outset.
>
> I don't think have a problem with that. At some point, I would need someone
> with input/output hardware to test the input-specific parts, however. Hint,
> hint. ;)
if you'd seriously play with a Blackfin board, i think we can arrange that
>> not really, but i see the existing code you've posted could already
>> utilize some of the "get" functions ...
>
> Which parts? I don't really like keeping the period_ticks and duty_ticks values
> around, but in my case I have no choice--- unless I were to read the CPRE, CPRD
> and CDTY values from the hardware directly. Which could be what your proposed
> "get" methods would do.
sorry, i misread the led driver. too many structures! :)
> But that still isn't PWM "input" the way you are describing, because my hardware
> wouldn't be _reading_ an incoming PWM: it would be just reporting back the
> values that it was using to produce its output signal. Huge difference.
>
> I dunno, I'm still not sure that measuring the characteristics of an incoming
> PWM signal isn't a different kind of device from one that produces PWM signals,
> at least conceptually. Which, in a way, makes it out of scope for the proposed
> API. Not saying I can't go along with the idea, I'm just not sure what a user
> would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC
> device. They certainly aren't going to get a measured value in return!
while true, hardware that can support PWM as both input/output would
suffer from two frameworks. if there's ambiguity in behavior (using
"get" in an output mode), then we can just stick it in the
documentation and move on. the GPIO framework already has this
behavior (set a pin to output and then try and read the data) and i
dont recall it ever being an issue there.
-mike
next prev parent reply other threads:[~2008-10-09 4:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 1/6] [PWM] Generic PWM API implementation Bill Gatliff
[not found] ` <4b5c3aa2b1bc2b7efad834da49c2dec8c0a8726b.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 2/6] [PWM] Changes to existing include/linux/pwm.h to adapt to generic PWM API Bill Gatliff
[not found] ` <88de40673cc33e014928c2ee3a86bdac566021c8.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 3/6] [PWM] Documentation Bill Gatliff
[not found] ` <7b16004ca5f8030184c2de96cbcee38657d56252.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 4/6] [PWM] Driver for Atmel PWMC peripheral Bill Gatliff
[not found] ` <5640f37b779f953c83e79c16b2a0466c0f5da702.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one Bill Gatliff
[not found] ` <475b4a5985463015fdfa943b9835ab8136dbc06a.1223482372.git.bgat@billgatliff.com>
2008-10-08 16:43 ` [RFC 6/6] [PWM] New LED driver and trigger that use PWM API Bill Gatliff
2008-10-09 5:21 ` [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one Hans-Christian Egtvedt
2008-10-09 12:16 ` Haavard Skinnemoen
2008-10-09 12:17 ` Hans-Christian Egtvedt
2008-10-09 14:04 ` Bill Gatliff
2008-10-09 13:40 ` Bill Gatliff
2008-10-09 13:44 ` Hans-Christian Egtvedt
2008-10-09 8:17 ` [RFC 1/6] [PWM] Generic PWM API implementation Marc Pignat
2008-10-08 19:27 ` [RFC 0/6] Proposal for a Generic PWM Device API Mike Frysinger
2008-10-09 2:23 ` Bill Gatliff
2008-10-09 2:29 ` Bill Gatliff
2008-10-09 2:32 ` Mike Frysinger
2008-10-09 3:46 ` Bill Gatliff
2008-10-09 4:05 ` Mike Frysinger [this message]
2008-10-09 4:18 ` Bill Gatliff
2008-10-09 4:33 ` Mike Frysinger
[not found] ` <1223608819.8157.127.camel@pasglop>
[not found] ` <48EED4D1.2040506@billgatliff.com>
2008-10-10 9:00 ` Geert Uytterhoeven
2008-10-10 9:36 ` Paul Mundt
2008-10-10 9:46 ` David Woodhouse
2008-10-10 13:59 ` Bill Gatliff
2008-10-10 14:03 ` Bill Gatliff
2008-10-10 14:32 ` Haavard Skinnemoen
2008-10-10 17:28 ` Paul Mundt
2008-10-10 19:15 ` Bill Gatliff
2008-10-10 13:59 ` Bill Gatliff
2008-10-10 17:40 ` Paul Mundt
2008-10-10 19:42 ` Bill Gatliff
2008-10-13 7:40 ` Geert Uytterhoeven
2008-10-08 16:43 Bill Gatliff
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=8bd0f97a0810082105mabededn54ffcc937674af3@mail.gmail.com \
--to=vapier.adi@gmail.com \
--cc=bgat@billgatliff.com \
--cc=linux-embedded@vger.kernel.org \
/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).