[PATCH v3 5/5] pwm: airoha: Add support for EN7581 SoC
Benjamin Larsson
benjamin.larsson at genexis.eu
Thu Sep 5 11:35:17 PDT 2024
Hi.
On 05/09/2024 17:39, Uwe Kleine-König wrote:
> Hello Benjamin,
>
> On Thu, Sep 05, 2024 at 02:18:41PM +0200, Benjamin Larsson wrote:
>> On 2024-09-05 11:30, Uwe Kleine-König wrote:
>>> 1 second long pulses with a period size of 1 second, so a constant high
>>> signal?
>> Hi, I think I was unclear. The SoC documentation is not that detailed. But I
>> think I understand how it works now.
>>
>> One register contains the minimum duration (d_min). And then there is one 8
>> bit register for the signal low period (lp) and then another 8bit register
>> for the high period (hp). Per my understanding a change of polarity is then
>> just a swap of lp and hp.
> that doesn't sound right.
>
> A "normal" waveform with period = 10 ns and duty_cycle = 2 ns looks as
> follows:
>
> _ _ _
> / \_______/ \_______/ \_______/
> ^ ^ ^ ^
>
> assuming a monospace font that's 1 char per ns, the ^ marking the period
> start.
>
> Ignoring scaling, your hardware needs to have hp = 2 and lp = 8. If you
> switch that (assuming you mean switching in the same way as I do) to hp
> = 8 and lp = 2, you get:
>
> _______ _______ _______
> / \_/ \_/ \_/
> ^ ^ ^ ^
>
> which is still a "normal" polarity output as a period starts with the
> active part.
>
> I admit that's a bit artificial, because the waveform for
>
> period = 10 ns
> duty_cycle = 2 ns
> polarity = inversed
>
> looks as follows:
>
> _______ _______ _______
> \_/ \_/ \_/ \_/
> ^ ^ ^ ^
>
> which isn't any different from the 2nd waveform above if you ignore the
> period start markers (which are not observable apart from the moments
> where you reconfigure the output).
>
> However it matters if you have a chip with >1 output that are not
> independent.
Ok that was a clear explanation, anyway the pwm hardware is then not
capable of a polarity change. It is possible to change the polarity via
other means but there is no way for the pwm block (and driver) to handle
this.
>> This means that when requesting a period and duty cycle you need to search
>> through the configuration space to find the optimal value.
> Or restrict yourself consistently to something simpler than a exhaustive
> search through the complete configuration space.
Is there a recommendation on what is more important? Period duration or
duty cycle percentage?
>> MvH
> (BTW, I had to research the meaning of MvH. In case someone else doesn't
> know it: It's the usual abbreviation for "Med vänliga hälsningar" in
> Sweden or "Med vennlig hilsen" in Norway; both meaning "With friendly
> greetings".)
>
> Best regards
> Uwe
MvH
Benjamin Larsson
More information about the Linux-mediatek
mailing list