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

Groups > linux.kernel > #1193235 > unrolled thread

[PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT

Back to article view | Back to linux.kernel

Contents

  [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-07-27 17:10 +0200
    Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Lee Jones <lee.jones@linaro.org> - 2015-07-27 23:30 +0200
      Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-07-27 23:40 +0200
        Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Lee Jones <lee.jones@linaro.org> - 2015-07-28 09:50 +0200
    Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Lee Jones <lee.jones@linaro.org> - 2015-07-27 23:30 +0200
    Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-07-27 23:30 +0200
    Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Lee Jones <lee.jones@linaro.org> - 2015-07-28 11:00 +0200
      Re: [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT Mika Westerberg <mika.westerberg@linux.intel.com> - 2015-07-28 11:10 +0200
      [GIT PULL] mfd: Immutable branch between MFD, Base, ACPI and DMA Lee Jones <lee.jones@linaro.org> - 2015-07-28 11:10 +0200

#1193235 — [PATCH v6 0/8] mfd: introduce a driver for LPSS devices on SPT

The new coming Intel platforms such as Skylake will contain Sunrisepoint PCH.

The driver is based on MFD framework since the main device, i.e. serial bus
controller, contains register space for itself, DMA part, and an additional
address space (convergence layer). 

The public specification of the register map is avaiable in [1].

This is sixth generation of the patch series to bring support LPSS devices
found on Intel Sunrisepoint (Intel Skylake PCH). Previous one can be found here
[2].

The series has few logical parts:
- patches 1-3 prepares PM core, ACPI, and driver core (PM) to handle our case
- patches 4-6 introduce unregistering platform devices in MFD in reversed
  order
- patch 7 implements iDMA 64-bit driver
- patch 8 introduces an MFD driver for LPSS devices

The driver has been tested with SPI and UART on Intel Skylake PCH.

Stephen, can you, please, have a look into patch 8 regarding to clock name
matching and other stuff Lee asked?

[1] https://download.01.org/future-platform-configuration-hub/skylake/register-definitions/332219-002.pdf
[2] http://www.spinics.net/lists/linux-acpi/msg59267.html

Changelog v6:
  - rebase on top of v4.2-rc4
  - address Vinod's comments regarding to idma64 driver
  - fix a bug in idma64 driver found by our Q/A team (use after free)

Changelog v5:
  - rebase on top of v4.2-rc1
  - patch 3 is modified accordingly to new changes in drivers/base/dd.c
  - correct Rafael's email in patch 3

Changelog v4:
  - replace patch 3 by Rafael's suggession
  - append ACKs from Rafael
  - rebase on top of v4.1-rc8

Changelog v3:
  - rework patch 3 to be used for all kind of devices (address Alan comment)
  - iDMA 64-bit driver improvements:
    - fix burst-to-register conversion
    - remove excessive locking
  - do not expose core part to the user (Kconfig)
  - address most of Lee's comments
  - append ACKs
  - rebase on top of v4.1-rc6

Changelog v2:
  - new DMA driver to fully support iDMA 64-bit IP
  - patch 3 is added to wake up parent devices when ->probe(), ->remove(), or
    ->shutdown()
  - MFD core is unregistering devices in reversed order
  - address few Lee's comments on v1
  - address Russel's comment, therefore use clkdev_create() helper
  - intel-lpss{,-acpi,-pci} are modified regarding to above changes

Andy Shevchenko (5):
  klist: implement klist_prev()
  driver core: implement device_for_each_child_reverse()
  mfd: make mfd_remove_devices() iterate in reverse order
  dmaengine: add a driver for Intel integrated DMA 64-bit
  mfd: Add support for Intel Sunrisepoint LPSS devices

Mika Westerberg (2):
  PM / QoS: Make it possible to expose device latency tolerance to
    userspace
  ACPI / PM: Attach ACPI power domain only once

Rafael J. Wysocki (1):
  Driver core: wakeup the parent device before trying probe

 drivers/acpi/device_pm.c      |   8 +
 drivers/acpi/internal.h       |   2 +
 drivers/acpi/scan.c           |  46 ++-
 drivers/base/core.c           |  43 +++
 drivers/base/dd.c             |  20 ++
 drivers/base/power/power.h    |   2 +
 drivers/base/power/qos.c      |  37 +++
 drivers/base/power/sysfs.c    |  11 +
 drivers/dma/Kconfig           |   8 +
 drivers/dma/Makefile          |   1 +
 drivers/dma/idma64.c          | 710 ++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/idma64.h          | 233 ++++++++++++++
 drivers/mfd/Kconfig           |  23 ++
 drivers/mfd/Makefile          |   3 +
 drivers/mfd/intel-lpss-acpi.c |  84 +++++
 drivers/mfd/intel-lpss-pci.c  | 113 +++++++
 drivers/mfd/intel-lpss.c      | 524 +++++++++++++++++++++++++++++++
 drivers/mfd/intel-lpss.h      |  62 ++++
 drivers/mfd/mfd-core.c        |   2 +-
 include/linux/device.h        |   2 +
 include/linux/klist.h         |   1 +
 include/linux/pm_qos.h        |   5 +
 lib/klist.c                   |  41 +++
 23 files changed, 1964 insertions(+), 17 deletions(-)
 create mode 100644 drivers/dma/idma64.c
 create mode 100644 drivers/dma/idma64.h
 create mode 100644 drivers/mfd/intel-lpss-acpi.c
 create mode 100644 drivers/mfd/intel-lpss-pci.c
 create mode 100644 drivers/mfd/intel-lpss.c
 create mode 100644 drivers/mfd/intel-lpss.h

-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1193501

On Mon, 27 Jul 2015, Lee Jones wrote:

> On Mon, 27 Jul 2015, Rafael J. Wysocki wrote:
> 
> > On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> > > On Mon, 27 Jul 2015, Mika Westerberg wrote:
> > > 
> > > > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote:
> > > > > FAO Stephen Boyd,
> > > > > 
> > > > > > Stephen, can you, please, have a look into patch 8 regarding to clock name
> > > > > > matching and other stuff Lee asked?
> > > > > 
> > > > > Patch 8:
> > > > > 
> > > > >       "Can you review the clock implementation please?  It looks
> > > > >       fragile to me as it relies heavily on device names constructed
> > > > >       of MFD cell names and IDA numbers cat'ed together!"
> > > > 
> > > > Lee, can you suggest an alternative then?
> > > > 
> > > > Why we are doing it like this is that number of different LPSS devices
> > > > changes from SoC to SoC. In addition to that the device (called "slice")
> > > > might have iDMA block or not.
> > > > 
> > > > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw)
> > > > use standard clk framework to request their clocks the Linux device must
> > > > have clock registered which matches the device in advance.
> > > > 
> > > > Because we add the host controller device dynamically (from the MFD
> > > > driver) based on how many devices are actually present, we need somehow
> > > > predict what would be the correct name and instance number for that
> > > > device to get the clock for it. That's the reason we use IDA here along
> > > > with the cell name (or driver name).
> > > 
> > > I'm sure there are perfectly viable reasons for you doing this.  And I
> > > don't know the CCF well enough to know whether it's the best idea or
> > > not, or else I would have made a suggestion rather than waiting all
> > > this time.
> > > 
> > > It's for this reason that I needed Mike (now Stephen) to take a look
> > > and give me either an Ack, to say it's the best solution, or to
> > > provide a better alternative.
> > > 
> > > Until that happens, I'm stuck!
> > 
> > Well, what if we had no one at hand to review that code?  Would that mean it
> > would not be applicable forever?
> 
> No, but that's not the case is it?
> 
> I don't understand why Mike and Stephen aren't helping!

I'll wait until tomorrow and if we haven't heard anything I'll make a
decision.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193512

On Monday, July 27, 2015 10:29:34 PM Lee Jones wrote:
> On Mon, 27 Jul 2015, Lee Jones wrote:
> 
> > On Mon, 27 Jul 2015, Rafael J. Wysocki wrote:
> > 
> > > On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> > > > On Mon, 27 Jul 2015, Mika Westerberg wrote:
> > > > 
> > > > > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote:
> > > > > > FAO Stephen Boyd,
> > > > > > 
> > > > > > > Stephen, can you, please, have a look into patch 8 regarding to clock name
> > > > > > > matching and other stuff Lee asked?
> > > > > > 
> > > > > > Patch 8:
> > > > > > 
> > > > > >       "Can you review the clock implementation please?  It looks
> > > > > >       fragile to me as it relies heavily on device names constructed
> > > > > >       of MFD cell names and IDA numbers cat'ed together!"
> > > > > 
> > > > > Lee, can you suggest an alternative then?
> > > > > 
> > > > > Why we are doing it like this is that number of different LPSS devices
> > > > > changes from SoC to SoC. In addition to that the device (called "slice")
> > > > > might have iDMA block or not.
> > > > > 
> > > > > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw)
> > > > > use standard clk framework to request their clocks the Linux device must
> > > > > have clock registered which matches the device in advance.
> > > > > 
> > > > > Because we add the host controller device dynamically (from the MFD
> > > > > driver) based on how many devices are actually present, we need somehow
> > > > > predict what would be the correct name and instance number for that
> > > > > device to get the clock for it. That's the reason we use IDA here along
> > > > > with the cell name (or driver name).
> > > > 
> > > > I'm sure there are perfectly viable reasons for you doing this.  And I
> > > > don't know the CCF well enough to know whether it's the best idea or
> > > > not, or else I would have made a suggestion rather than waiting all
> > > > this time.
> > > > 
> > > > It's for this reason that I needed Mike (now Stephen) to take a look
> > > > and give me either an Ack, to say it's the best solution, or to
> > > > provide a better alternative.
> > > > 
> > > > Until that happens, I'm stuck!
> > > 
> > > Well, what if we had no one at hand to review that code?  Would that mean it
> > > would not be applicable forever?
> > 
> > No, but that's not the case is it?
> > 
> > I don't understand why Mike and Stephen aren't helping!
> 
> I'll wait until tomorrow and if we haven't heard anything I'll make a
> decision.

OK, thanks!

BTW, I don't have the time to review every single patch using ACPI
or one of the PM frameworks.  If people who use them make mistakes,
it is their burden to fix those mistakes when they show up in testing.

What's happening here is that Andy and Mika are taking the responsibility
for fixing the new code if it turns out to be buggy and so it's their
problem if it happens to be broken.

And you can still revert commits that introduce bugs as a last resort.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193840

On Tue, 28 Jul 2015, Rafael J. Wysocki wrote:

> On Monday, July 27, 2015 10:29:34 PM Lee Jones wrote:
> > On Mon, 27 Jul 2015, Lee Jones wrote:
> > 
> > > On Mon, 27 Jul 2015, Rafael J. Wysocki wrote:
> > > 
> > > > On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> > > > > On Mon, 27 Jul 2015, Mika Westerberg wrote:
> > > > > 
> > > > > > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote:
> > > > > > > FAO Stephen Boyd,
> > > > > > > 
> > > > > > > > Stephen, can you, please, have a look into patch 8 regarding to clock name
> > > > > > > > matching and other stuff Lee asked?
> > > > > > > 
> > > > > > > Patch 8:
> > > > > > > 
> > > > > > >       "Can you review the clock implementation please?  It looks
> > > > > > >       fragile to me as it relies heavily on device names constructed
> > > > > > >       of MFD cell names and IDA numbers cat'ed together!"
> > > > > > 
> > > > > > Lee, can you suggest an alternative then?
> > > > > > 
> > > > > > Why we are doing it like this is that number of different LPSS devices
> > > > > > changes from SoC to SoC. In addition to that the device (called "slice")
> > > > > > might have iDMA block or not.
> > > > > > 
> > > > > > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw)
> > > > > > use standard clk framework to request their clocks the Linux device must
> > > > > > have clock registered which matches the device in advance.
> > > > > > 
> > > > > > Because we add the host controller device dynamically (from the MFD
> > > > > > driver) based on how many devices are actually present, we need somehow
> > > > > > predict what would be the correct name and instance number for that
> > > > > > device to get the clock for it. That's the reason we use IDA here along
> > > > > > with the cell name (or driver name).
> > > > > 
> > > > > I'm sure there are perfectly viable reasons for you doing this.  And I
> > > > > don't know the CCF well enough to know whether it's the best idea or
> > > > > not, or else I would have made a suggestion rather than waiting all
> > > > > this time.
> > > > > 
> > > > > It's for this reason that I needed Mike (now Stephen) to take a look
> > > > > and give me either an Ack, to say it's the best solution, or to
> > > > > provide a better alternative.
> > > > > 
> > > > > Until that happens, I'm stuck!
> > > > 
> > > > Well, what if we had no one at hand to review that code?  Would that mean it
> > > > would not be applicable forever?
> > > 
> > > No, but that's not the case is it?
> > > 
> > > I don't understand why Mike and Stephen aren't helping!
> > 
> > I'll wait until tomorrow and if we haven't heard anything I'll make a
> > decision.
> 
> OK, thanks!
> 
> BTW, I don't have the time to review every single patch using ACPI
> or one of the PM frameworks.  If people who use them make mistakes,
> it is their burden to fix those mistakes when they show up in testing.
> 
> What's happening here is that Andy and Mika are taking the responsibility
> for fixing the new code if it turns out to be buggy and so it's their
> problem if it happens to be broken.
> 
> And you can still revert commits that introduce bugs as a last resort.

I'm fine with that in principle.  My issue here was that it looks
wrong to me.  I just don't know enough about the inner workings of the
CCF to be able to say that for sure, or to provide a suitable
alternative.  I think, probably the correct thing to do is to have an
accompanying clock driver, but who knows (I guess Stephen and Mike to,
but are seemingly unwilling to help).

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193505

On Mon, 27 Jul 2015, Rafael J. Wysocki wrote:

> On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> > On Mon, 27 Jul 2015, Mika Westerberg wrote:
> > 
> > > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote:
> > > > FAO Stephen Boyd,
> > > > 
> > > > > Stephen, can you, please, have a look into patch 8 regarding to clock name
> > > > > matching and other stuff Lee asked?
> > > > 
> > > > Patch 8:
> > > > 
> > > >       "Can you review the clock implementation please?  It looks
> > > >       fragile to me as it relies heavily on device names constructed
> > > >       of MFD cell names and IDA numbers cat'ed together!"
> > > 
> > > Lee, can you suggest an alternative then?
> > > 
> > > Why we are doing it like this is that number of different LPSS devices
> > > changes from SoC to SoC. In addition to that the device (called "slice")
> > > might have iDMA block or not.
> > > 
> > > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw)
> > > use standard clk framework to request their clocks the Linux device must
> > > have clock registered which matches the device in advance.
> > > 
> > > Because we add the host controller device dynamically (from the MFD
> > > driver) based on how many devices are actually present, we need somehow
> > > predict what would be the correct name and instance number for that
> > > device to get the clock for it. That's the reason we use IDA here along
> > > with the cell name (or driver name).
> > 
> > I'm sure there are perfectly viable reasons for you doing this.  And I
> > don't know the CCF well enough to know whether it's the best idea or
> > not, or else I would have made a suggestion rather than waiting all
> > this time.
> > 
> > It's for this reason that I needed Mike (now Stephen) to take a look
> > and give me either an Ack, to say it's the best solution, or to
> > provide a better alternative.
> > 
> > Until that happens, I'm stuck!
> 
> Well, what if we had no one at hand to review that code?  Would that mean it
> would not be applicable forever?

No, but that's not the case is it?

I don't understand why Mike and Stephen aren't helping!

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193507

On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> On Mon, 27 Jul 2015, Mika Westerberg wrote:
> 
> > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote:
> > > FAO Stephen Boyd,
> > > 
> > > > Stephen, can you, please, have a look into patch 8 regarding to clock name
> > > > matching and other stuff Lee asked?
> > > 
> > > Patch 8:
> > > 
> > >       "Can you review the clock implementation please?  It looks
> > >       fragile to me as it relies heavily on device names constructed
> > >       of MFD cell names and IDA numbers cat'ed together!"
> > 
> > Lee, can you suggest an alternative then?
> > 
> > Why we are doing it like this is that number of different LPSS devices
> > changes from SoC to SoC. In addition to that the device (called "slice")
> > might have iDMA block or not.
> > 
> > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw)
> > use standard clk framework to request their clocks the Linux device must
> > have clock registered which matches the device in advance.
> > 
> > Because we add the host controller device dynamically (from the MFD
> > driver) based on how many devices are actually present, we need somehow
> > predict what would be the correct name and instance number for that
> > device to get the clock for it. That's the reason we use IDA here along
> > with the cell name (or driver name).
> 
> I'm sure there are perfectly viable reasons for you doing this.  And I
> don't know the CCF well enough to know whether it's the best idea or
> not, or else I would have made a suggestion rather than waiting all
> this time.
> 
> It's for this reason that I needed Mike (now Stephen) to take a look
> and give me either an Ack, to say it's the best solution, or to
> provide a better alternative.
> 
> Until that happens, I'm stuck!

Well, what if we had no one at hand to review that code?  Would that mean it
would not be applicable forever?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193908

Enjoy,

The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:

  Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-base-acpi-dma-v4.3

for you to fetch changes up to 4b45efe8526359a11ca60a299bef3aebf413fd77:

  mfd: Add support for Intel Sunrisepoint LPSS devices (2015-07-28 09:56:47 +0100)

----------------------------------------------------------------
Immutable branch between MFD, Base, ACPI and DMA due for v4.3

----------------------------------------------------------------
Andy Shevchenko (5):
      klist: implement klist_prev()
      driver core: implement device_for_each_child_reverse()
      mfd: make mfd_remove_devices() iterate in reverse order
      dmaengine: add a driver for Intel integrated DMA 64-bit
      mfd: Add support for Intel Sunrisepoint LPSS devices

Mika Westerberg (2):
      PM / QoS: Make it possible to expose device latency tolerance to userspace
      ACPI / PM: Attach ACPI power domain only once

Rafael J. Wysocki (1):
      Driver core: wakeup the parent device before trying probe

 drivers/acpi/device_pm.c      |   8 +
 drivers/acpi/internal.h       |   2 +
 drivers/acpi/scan.c           |  46 ++-
 drivers/base/core.c           |  43 +++
 drivers/base/dd.c             |  20 ++
 drivers/base/power/power.h    |   2 +
 drivers/base/power/qos.c      |  37 +++
 drivers/base/power/sysfs.c    |  11 +
 drivers/dma/Kconfig           |   8 +
 drivers/dma/Makefile          |   1 +
 drivers/dma/idma64.c          | 710 ++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/idma64.h          | 233 ++++++++++++++
 drivers/mfd/Kconfig           |  23 ++
 drivers/mfd/Makefile          |   3 +
 drivers/mfd/intel-lpss-acpi.c |  84 +++++
 drivers/mfd/intel-lpss-pci.c  | 113 +++++++
 drivers/mfd/intel-lpss.c      | 524 +++++++++++++++++++++++++++++++
 drivers/mfd/intel-lpss.h      |  62 ++++
 drivers/mfd/mfd-core.c        |   2 +-
 include/linux/device.h        |   2 +
 include/linux/klist.h         |   1 +
 include/linux/pm_qos.h        |   5 +
 lib/klist.c                   |  41 +++
 23 files changed, 1964 insertions(+), 17 deletions(-)
 create mode 100644 drivers/dma/idma64.c
 create mode 100644 drivers/dma/idma64.h
 create mode 100644 drivers/mfd/intel-lpss-acpi.c
 create mode 100644 drivers/mfd/intel-lpss-pci.c
 create mode 100644 drivers/mfd/intel-lpss.c
 create mode 100644 drivers/mfd/intel-lpss.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193914

On Tue, Jul 28, 2015 at 09:59:30AM +0100, Lee Jones wrote:
> Enjoy,
> 
> The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
> 
>   Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-base-acpi-dma-v4.3
> 
> for you to fetch changes up to 4b45efe8526359a11ca60a299bef3aebf413fd77:
> 
>   mfd: Add support for Intel Sunrisepoint LPSS devices (2015-07-28 09:56:47 +0100)
> 
> ----------------------------------------------------------------
> Immutable branch between MFD, Base, ACPI and DMA due for v4.3
> 
> ----------------------------------------------------------------
> Andy Shevchenko (5):
>       klist: implement klist_prev()
>       driver core: implement device_for_each_child_reverse()
>       mfd: make mfd_remove_devices() iterate in reverse order
>       dmaengine: add a driver for Intel integrated DMA 64-bit
>       mfd: Add support for Intel Sunrisepoint LPSS devices
> 
> Mika Westerberg (2):
>       PM / QoS: Make it possible to expose device latency tolerance to userspace
>       ACPI / PM: Attach ACPI power domain only once
> 
> Rafael J. Wysocki (1):
>       Driver core: wakeup the parent device before trying probe

Thank you :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1193917 — [GIT PULL] mfd: Immutable branch between MFD, Base, ACPI and DMA

With more explicit $SUBJECT line this time.

Sorry for the noise.

> Enjoy,
> 
> The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
> 
>   Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-base-acpi-dma-v4.3
> 
> for you to fetch changes up to 4b45efe8526359a11ca60a299bef3aebf413fd77:
> 
>   mfd: Add support for Intel Sunrisepoint LPSS devices (2015-07-28 09:56:47 +0100)
> 
> ----------------------------------------------------------------
> Immutable branch between MFD, Base, ACPI and DMA due for v4.3
> 
> ----------------------------------------------------------------
> Andy Shevchenko (5):
>       klist: implement klist_prev()
>       driver core: implement device_for_each_child_reverse()
>       mfd: make mfd_remove_devices() iterate in reverse order
>       dmaengine: add a driver for Intel integrated DMA 64-bit
>       mfd: Add support for Intel Sunrisepoint LPSS devices
> 
> Mika Westerberg (2):
>       PM / QoS: Make it possible to expose device latency tolerance to userspace
>       ACPI / PM: Attach ACPI power domain only once
> 
> Rafael J. Wysocki (1):
>       Driver core: wakeup the parent device before trying probe
> 
>  drivers/acpi/device_pm.c      |   8 +
>  drivers/acpi/internal.h       |   2 +
>  drivers/acpi/scan.c           |  46 ++-
>  drivers/base/core.c           |  43 +++
>  drivers/base/dd.c             |  20 ++
>  drivers/base/power/power.h    |   2 +
>  drivers/base/power/qos.c      |  37 +++
>  drivers/base/power/sysfs.c    |  11 +
>  drivers/dma/Kconfig           |   8 +
>  drivers/dma/Makefile          |   1 +
>  drivers/dma/idma64.c          | 710 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/dma/idma64.h          | 233 ++++++++++++++
>  drivers/mfd/Kconfig           |  23 ++
>  drivers/mfd/Makefile          |   3 +
>  drivers/mfd/intel-lpss-acpi.c |  84 +++++
>  drivers/mfd/intel-lpss-pci.c  | 113 +++++++
>  drivers/mfd/intel-lpss.c      | 524 +++++++++++++++++++++++++++++++
>  drivers/mfd/intel-lpss.h      |  62 ++++
>  drivers/mfd/mfd-core.c        |   2 +-
>  include/linux/device.h        |   2 +
>  include/linux/klist.h         |   1 +
>  include/linux/pm_qos.h        |   5 +
>  lib/klist.c                   |  41 +++
>  23 files changed, 1964 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/dma/idma64.c
>  create mode 100644 drivers/dma/idma64.h
>  create mode 100644 drivers/mfd/intel-lpss-acpi.c
>  create mode 100644 drivers/mfd/intel-lpss-pci.c
>  create mode 100644 drivers/mfd/intel-lpss.c
>  create mode 100644 drivers/mfd/intel-lpss.h
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web