On Sat, May 23, 2020 at 08:24:23PM -0400, Sven Van Asbroeck wrote:
> Hi Uwe,
>
> On Sat, May 23, 2020 at 4:17 PM Uwe Kleine-König
> wrote:
> >
> > Is this patch still relevant?
>
> A slightly different version of this patch has already landed in
> mainline. Clemens Gruber had
> relevant
Hi Uwe,
On Sat, May 23, 2020 at 4:17 PM Uwe Kleine-König
wrote:
>
> Is this patch still relevant?
A slightly different version of this patch has already landed in
mainline. Clemens Gruber had
relevant hardware available, and was able to test it out.
See Linus's tree here:
On Thu, Jun 06, 2019 at 11:11:11AM -0400, Sven Van Asbroeck wrote:
> I was able to test the patch [1] exclusion mechanism without access to actual
> hardware - by giving it a dummy regmap. See patch below.
>
> Test cases (all via sysfs):
> 1. verify requested pwm cannot be requested as gpio
> 2.
I was able to test the patch [1] exclusion mechanism without access to actual
hardware - by giving it a dummy regmap. See patch below.
Test cases (all via sysfs):
1. verify requested pwm cannot be requested as gpio
2. verify requested gpio cannot be requested as pwm
3. verify pwm "all LEDs"
On Mon, Jun 03, 2019 at 11:08:06AM -0400, Sven Van Asbroeck wrote:
> On Mon, Jun 3, 2019 at 7:40 AM Mika Westerberg
> wrote:
> Unfortunately, I no longer have any test hardware. The project that
> required this chip is long dead.
Anyone in possession of Intel Galileo Gen 2 can test this.
--
On Mon, Jun 03, 2019 at 11:08:06AM -0400, Sven Van Asbroeck wrote:
> On Mon, Jun 3, 2019 at 7:40 AM Mika Westerberg
> wrote:
> >
> > I think you are right. pca9685_pwm_request() should take the mutex as
> > long as it is requesting PWM.
>
> Yes, but things get hairy because pca9685_pwm_request()
On Mon, Jun 3, 2019 at 7:40 AM Mika Westerberg
wrote:
>
> I think you are right. pca9685_pwm_request() should take the mutex as
> long as it is requesting PWM.
Yes, but things get hairy because pca9685_pwm_request() will have to
give up the mutex when it returns. I cannot see a way to keep
On Sun, Jun 02, 2019 at 10:18:15AM -0400, Sven Van Asbroeck wrote:
> On Sat, Jun 1, 2019 at 12:05 PM Uwe Kleine-König
> wrote:
> >
> > I didn't look into the driver to try to understand that, but the
> > definitely needs a comment to explain for the next person to think they
> > can do a cleanup
On Sat, Jun 1, 2019 at 12:05 PM Uwe Kleine-König
wrote:
>
> I didn't look into the driver to try to understand that, but the
> definitely needs a comment to explain for the next person to think they
> can do a cleanup here.
Certainly.
But if we do restore the old behaviour, there may still be
Hello Sven,
On Sat, Jun 01, 2019 at 09:03:09AM -0400, Sven Van Asbroeck wrote:
> Hi YueHaibing,
>
> On Fri, May 31, 2019 at 11:49 PM YueHaibing wrote:
> >
> > mutex_lock(>lock);
> > - pwm = >chip.pwms[offset];
> > mutex_unlock(>lock);
>
> Thanks for noticing this issue.
Hi YueHaibing,
On Fri, May 31, 2019 at 11:49 PM YueHaibing wrote:
>
> mutex_lock(>lock);
> - pwm = >chip.pwms[offset];
> mutex_unlock(>lock);
Thanks for noticing this issue. However it should be fixed differently.
This was introduced by Uwe's clean-up patch:
commit
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/pwm/pwm-pca9685.c: In function 'pca9685_pwm_gpio_free':
drivers/pwm/pwm-pca9685.c:173:21: warning:
variable 'pwm' set but not used [-Wunused-but-set-variable]
It's not used since commit e926b12c611c ("pwm: Clear chip_data in pwm_put()")
12 matches
Mail list logo
