Thread (12 messages) 12 messages, 3 authors, 2016-07-25

Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM

From: Lee Jones <hidden>
Date: 2016-07-19 07:36:14
Also in: linux-pwm, lkml

On Mon, 18 Jul 2016, Thierry Reding wrote:
On Mon, Jul 18, 2016 at 02:24:26PM +0100, Lee Jones wrote:
quoted
On Mon, 18 Jul 2016, Thierry Reding wrote:
quoted
On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
quoted
On Fri, 15 Jul 2016, Brian Norris wrote:
quoted
This is the 4th (and final?) version of my series to support the new ChromeOS
EC PWM API, so we can control, e.g., a PWM backlight when its PWM is attached
to the EC. It uses Boris's latest "atomic" hooks for the PWM API (i.e., the
->apply() callback), which were recently merged.

Pulled and adapted the cros_ec_cmd_xfer_status() helper from this patch, with
some minor modifications:

https://lkml.org/lkml/2016/4/12/342

Note that after some style bikeshedding, I proposed to put off rewriting the
entire cros_ec_commands.h header at the moment, due to the shared nature of
this file. Follow up here:

https://bugs.chromium.org/p/chromium/issues/detail?id=621123

As this touches MFD (sort of), drivers/platform/chrome/, and drivers/pwm/, I'm
still not sure who it should all go through: Lee, Thierry, or Olof?
I usually take this type of submission through the MFD tree, although
it's too late in the day to make it into v4.8.

Which Acks are you missing?
I'm willing to take this through the PWM tree if you're okay with the
MFD changes. I can put the MFD changes into a separate branch and you
could pull that in if you needed to resolve any dependencies, which I
think would be quite unlikely if you've already closed your tree.
Are you saying that you're willing to take these straight into the
merge-window, with no soak in -next?
There's still a bit of time to let it soak in -next, but I'm not overly
concerned given that this is purely additions of code, so there can't be
any regressions.
No problem my side then.  Apply away.

Before doing so, can you see if there are any clashes with my
mfd-for-next branch?  If conflicts occur, please construct an
immutable tag I can pull from.  That way, I can base my branch on it
and deal with the fallout myself.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help