[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<VE1P189MB1024E9669B8CFCB943D633E7E3102@VE1P189MB1024.EURP189.PROD.OUTLOOK.COM>
Date: Mon, 6 Jan 2025 19:59:23 +0100
From: Maud Spierings <maud_spierings@...mail.com>
To: william.qiu@...rfivetech.com
Cc: hal.feng@...rfivetech.com, linux-kernel@...r.kernel.org,
linux-pwm@...r.kernel.org, p.zabel@...gutronix.de, ukleinek@...nel.org
Subject: Re: [PATCH v17] pwm: opencores: Add PWM driver support
Hello William,
I've once again put the patch to the test, and it seems the oops is
resolved.
I did notice something odd though, when controlling the backlightÂ
bl_power 0 means the backlight is on and controllable, 1 seems like off,
but instead sets the screen to maximum brightness and then stops
listening to any value echoed into brightness.
The brightness is also reversed from what would be logical, so 255 is
off and 0 is maximum.
Now the little text at the top specifies that the hardware only does
inverted polarity, which I guess explains this, but I don't understand
it. I also encountered this when I got an error to start with so I had
to add PWM_POLARITY_INVERTED to my pwm-backlight definition.
But I don't understand why it isn't supported. Wouldn't supporting non
inverted polarity be a very simple calculation? 40% negative duty cycle
is of course equal to 60% positive duty cycle, 20% N == 80% P etc. I
don't see why the hardware would specifically have to support this.
Anyways it does seem to work now so if others approve:
Tested-by: Maud Spierings <maud_spierings@...mail.com>
Kind regards,
Maud
Powered by blists - more mailing lists