Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1444666 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Brian Norris <briannorris@chromium.org> - 2016-07-16 01:40 +0200
    [PATCH v4 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper Brian Norris <briannorris@chromium.org> - 2016-07-16 01:40 +0200
    Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Lee Jones <lee.jones@linaro.org> - 2016-07-18 10:50 +0200
      Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Thierry Reding <thierry.reding@gmail.com> - 2016-07-18 11:20 +0200
        Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Lee Jones <lee.jones@linaro.org> - 2016-07-18 15:30 +0200
          Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Thierry Reding <thierry.reding@gmail.com> - 2016-07-18 16:10 +0200
            Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Lee Jones <lee.jones@linaro.org> - 2016-07-19 09:40 +0200
              Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Thierry Reding <thierry.reding@gmail.com> - 2016-07-25 16:30 +0200
      Re: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM Brian Norris <briannorris@chromium.org> - 2016-07-18 20:50 +0200

#1444666 — [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM

Hi,

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?

Please review.

Regards,
Brian

Change log (also documented in each patch):

v4:
 * return -EPROTO in cros_ec_cmd_xfer_status(), instead of (-EECRESULT - FOO)
 * log EC error results with dev_dbg()

v3:
 * fix some int->hex
 * fix a small bug in the handling of 'disabled' vs. 'duty_cycle == 0'
 * collect acks, tested-by

v2:
 * drop the "google,max-pwms" property
 * separate the cros_ec vs. PWM abstractions a little more clearly in the driver
 * remove dynamic kzalloc()'s and rely on on-stack memory instead



Brian Norris (3):
  mfd: cros_ec: add EC_PWM function definitions
  doc: dt: pwm: add binding for ChromeOS EC PWM
  pwm: add ChromeOS EC PWM driver

Tomeu Vizoso (1):
  mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

 .../devicetree/bindings/pwm/google,cros-ec-pwm.txt |  23 ++
 drivers/platform/chrome/cros_ec_proto.c            |  17 ++
 drivers/pwm/Kconfig                                |   7 +
 drivers/pwm/Makefile                               |   1 +
 drivers/pwm/pwm-cros-ec.c                          | 260 +++++++++++++++++++++
 include/linux/mfd/cros_ec.h                        |  15 ++
 include/linux/mfd/cros_ec_commands.h               |  31 +++
 7 files changed, 354 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
 create mode 100644 drivers/pwm/pwm-cros-ec.c

-- 
2.8.0.rc3.226.g39d4020

[toc] | [next] | [standalone]

#1444667 — [PATCH v4 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

From: Tomeu Vizoso <tomeu.vizoso@collabora.com>

So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate
code when checking for errors from the EC side.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
v4:
 * return -EPROTO instead of custom (-EECRESULT - foo)
 * log msg->result in dev_dbg() (TBD!)

v3:
 * successfully spell success

v2:
 * no change
---
 drivers/platform/chrome/cros_ec_proto.c | 17 +++++++++++++++++
 include/linux/mfd/cros_ec.h             | 15 +++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
index b6e161f71b26..6c084b266651 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -380,3 +380,20 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
 	return ret;
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+			    struct cros_ec_command *msg)
+{
+	int ret;
+
+	ret = cros_ec_cmd_xfer(ec_dev, msg);
+	if (ret < 0) {
+		dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
+	} else if (msg->result != EC_RES_SUCCESS) {
+		dev_dbg(ec_dev->dev, "Command result (err: %d)\n", msg->result);
+		return -EPROTO;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 64184d27e3cd..d641a18abacb 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -226,6 +226,21 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
 		     struct cros_ec_command *msg);
 
 /**
+ * cros_ec_cmd_xfer_status - Send a command to the ChromeOS EC
+ *
+ * This function is identical to cros_ec_cmd_xfer, except it returns success
+ * status only if both the command was transmitted successfully and the EC
+ * replied with success status. It's not necessary to check msg->result when
+ * using this function.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ * @return: Num. of bytes transferred on success, <0 on failure
+ */
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+			    struct cros_ec_command *msg);
+
+/**
  * cros_ec_remove - Remove a ChromeOS EC
  *
  * Call this to deregister a ChromeOS EC, then clean up any private data.
-- 
2.8.0.rc3.226.g39d4020

[toc] | [prev] | [next] | [standalone]

#1445307

On Fri, 15 Jul 2016, Brian Norris wrote:
> 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?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [next] | [standalone]

#1445332

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> On Fri, 15 Jul 2016, Brian Norris wrote:
> > 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.

Thierry

[toc] | [prev] | [next] | [standalone]

#1445481

On Mon, 18 Jul 2016, Thierry Reding wrote:

> On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> > On Fri, 15 Jul 2016, Brian Norris wrote:
> > > 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?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [next] | [standalone]

#1445502

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 18, 2016 at 02:24:26PM +0100, Lee Jones wrote:
> On Mon, 18 Jul 2016, Thierry Reding wrote:
> 
> > On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> > > On Fri, 15 Jul 2016, Brian Norris wrote:
> > > > 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.

Thierry

[toc] | [prev] | [next] | [standalone]

#1446183

On Mon, 18 Jul 2016, Thierry Reding wrote:

> On Mon, Jul 18, 2016 at 02:24:26PM +0100, Lee Jones wrote:
> > On Mon, 18 Jul 2016, Thierry Reding wrote:
> > 
> > > On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> > > > On Fri, 15 Jul 2016, Brian Norris wrote:
> > > > > 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

[toc] | [prev] | [next] | [standalone]

#1449541

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 19, 2016 at 08:37:17AM +0100, Lee Jones wrote:
> On Mon, 18 Jul 2016, Thierry Reding wrote:
> 
> > On Mon, Jul 18, 2016 at 02:24:26PM +0100, Lee Jones wrote:
> > > On Mon, 18 Jul 2016, Thierry Reding wrote:
> > > 
> > > > On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> > > > > On Fri, 15 Jul 2016, Brian Norris wrote:
> > > > > > 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.

It merges cleanly into your mfd-for-next branch, so I've gone and
applied patches 1 and 2 to a for-4.8/mfd branch, which I can provide a
stable tag from if you still need it, and patches 3 and 4 to the
for-4.8/drivers branch.

Thanks,
Thierry

[toc] | [prev] | [next] | [standalone]

#1445723

On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> On Fri, 15 Jul 2016, Brian Norris wrote:
> > 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 think I was only missing Thierry's. If he's planning to take it
through his tree, then that's fine. It's also fine if it waits for 4.9,
if that helps, although I agree it has practically zero chances of
regressions.

But most importantly, I think various parties would like patch 1, so if
it doesn't make 4.8-rc1, then it's probably important it makes it into a
branch others can pull from if necessary.

Regards,
Brian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web