Re: [PATCH v3 5/5] pwm: airoha: Add support for EN7581 SoC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux