Skip to contentSkip to conversation

dma: support Lynxpoint DMA

PATCH Applied Andy Shevchenko 4 participants 9 messages May 8, 2013 – May 23, 2013

Subsystems (3)
ACPI Common clk dmaengine
lore
Share & tools
lore

Andy Shevchenko

author
#0 lore raw

v3 cover dma: support Lynxpoint DMA

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

I will be on vacation next week. Mika promised to help if anything happens to these patches.

Andy Shevchenko (1):
dma: acpi-dma: parse CSRT to extract additional resources

Rafael J. Wysocki (1):
ACPI / LPSS: register clock device for Lynxpoint DMA properly

 drivers/acpi/Makefile                  |    1 -
 drivers/acpi/acpi_lpss.c               |   26 ++++-
 drivers/acpi/csrt.c                    |  159 -----------------------------
 drivers/acpi/internal.h                |    1 -
 drivers/acpi/scan.c                    |    1 -
 drivers/clk/x86/clk-lpt.c              |   15 ++-
 drivers/dma/acpi-dma.c                 |  172 +++++++++++++++++++++++++++++++-
 include/linux/acpi_dma.h               |    4 +
 include/linux/platform_data/clk-lpss.h |    5 +
 9 files changed, 211 insertions(+), 173 deletions(-)
 delete mode 100644 drivers/acpi/csrt.c
Signature · 1 line
1.7.10.4
author
#1 lore raw

PATCH v3 1/2 dma: acpi-dma: parse CSRT to extract additional resources

Since we have CSRT only to get additional DMA controller resources, let's get rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code.

Signed-off-by Andy Shevchenko <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>
Acked-by Rafael J. Wysocki <[email protected]>
---
 drivers/acpi/Makefile    |    1 -
 drivers/acpi/csrt.c      |  159 ------------------------------------------
 drivers/acpi/internal.h  |    1 -
 drivers/acpi/scan.c      |    1 -
 drivers/dma/acpi-dma.c   |  172 +++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/acpi_dma.h |    4 ++
 6 files changed, 173 insertions(+), 165 deletions(-)
 delete mode 100644 drivers/acpi/csrt.c
drivers/acpi/Makefile +0 -1
index ecb743b..6050c80 100644
@@ -38,7 +38,6 @@ acpi-y				+= processor_core.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
-acpi-y				+= csrt.o
 acpi-$(CONFIG_X86_INTEL_LPSS)	+= acpi_lpss.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= power.o
drivers/acpi/csrt.c deleted +0 -159

159 lines not on this page · raw message

drivers/acpi/internal.h +0 -1
index 6f1afd9..297cbf4 100644
@@ -35,7 +35,6 @@ void acpi_pci_link_init(void);
 void acpi_pci_root_hp_init(void);
 void acpi_platform_init(void);
 int acpi_sysfs_init(void);
-void acpi_csrt_init(void);
 #ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
 #else
drivers/acpi/scan.c +0 -1
index fe158fd..aacc08f 100644
@@ -2042,7 +2042,6 @@ int __init acpi_scan_init(void)
 	acpi_pci_link_init();
 	acpi_platform_init();
 	acpi_lpss_init();
-	acpi_csrt_init();
 	acpi_container_init();
 	acpi_memory_hotplug_init();
drivers/dma/acpi-dma.c +169 -3

215 lines not on this page · raw message

include/linux/acpi_dma.h +4 -0
index d09deab..fb02980 100644
@@ -37,6 +37,8 @@ struct acpi_dma_spec {
  * @dev:		struct device of this controller
  * @acpi_dma_xlate:	callback function to find a suitable channel
  * @data:		private data used by a callback function
+ * @base_request_line:	first supported request line (CSRT)
+ * @end_request_line:	last supported request line (CSRT)
  */
 struct acpi_dma {
 	struct list_head	dma_controllers;

@@ -44,6 +46,8 @@ struct acpi_dma {
 	struct dma_chan		*(*acpi_dma_xlate)
 				(struct acpi_dma_spec *, struct acpi_dma *);
 	void			*data;
+	unsigned short		base_request_line;
+	unsigned short		end_request_line;
 };
 
 /* Used with acpi_dma_simple_xlate() */
Signature · 1 line
1.7.10.4
author
#2 lore raw

PATCH v3 2/2 ACPI / LPSS: register clock device for Lynxpoint DMA properly

In reply to Andy Shevchenko

From: "Rafael J. Wysocki" <[email protected]>

The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job.

This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c.

Signed-off-by Rafael J. Wysocki <[email protected]>
Signed-off-by Andy Shevchenko <[email protected]>
---
 drivers/acpi/acpi_lpss.c               |   26 ++++++++++++++++++++++----
 drivers/clk/x86/clk-lpt.c              |   15 +++++++++++----
 include/linux/platform_data/clk-lpss.h |    5 +++++
 3 files changed, 38 insertions(+), 8 deletions(-)
drivers/acpi/acpi_lpss.c +22 -4
index b1c9542..652fd5c 100644
@@ -35,11 +35,16 @@ ACPI_MODULE_NAME("acpi_lpss");
 
 struct lpss_device_desc {
 	bool clk_required;
-	const char *clk_parent;
+	const char *clkdev_name;
 	bool ltr_required;
 	unsigned int prv_offset;
 };
 
+static struct lpss_device_desc lpss_dma_desc = {
+	.clk_required = true,
+	.clkdev_name = "hclk",
+};
+
 struct lpss_private_data {
 	void __iomem *mmio_base;
 	resource_size_t mmio_size;

@@ -49,7 +54,6 @@ struct lpss_private_data {
 
 static struct lpss_device_desc lpt_dev_desc = {
 	.clk_required = true,
-	.clk_parent = "lpss_clk",
 	.prv_offset = 0x800,
 	.ltr_required = true,
 };

@@ -60,6 +64,9 @@ static struct lpss_device_desc lpt_sdio_dev_desc = {
 };
 
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
+	/* Generic LPSS devices */
+	{ "INTL9C60", (unsigned long)&lpss_dma_desc },
+
 	/* Lynxpoint LPSS devices */
 	{ "INT33C0", (unsigned long)&lpt_dev_desc },
 	{ "INT33C1", (unsigned long)&lpt_dev_desc },

@@ -91,16 +98,27 @@ static int register_device_clock(struct acpi_device *adev,
 				 struct lpss_private_data *pdata)
 {
 	const struct lpss_device_desc *dev_desc = pdata->dev_desc;
+	struct lpss_clk_data *clk_data;
 
 	if (!lpss_clk_dev)
 		lpt_register_clock_device();
 
-	if (!dev_desc->clk_parent || !pdata->mmio_base
+	clk_data = platform_get_drvdata(lpss_clk_dev);
+	if (!clk_data)
+		return -ENODEV;
+
+	if (dev_desc->clkdev_name) {
+		clk_register_clkdev(clk_data->clk, dev_desc->clkdev_name,
+				    dev_name(&adev->dev));
+		return 0;
+	}
+
+	if (!pdata->mmio_base
 	    || pdata->mmio_size < dev_desc->prv_offset + LPSS_CLK_SIZE)
 		return -ENODATA;
 
 	pdata->clk = clk_register_gate(NULL, dev_name(&adev->dev),
-				       dev_desc->clk_parent, 0,
+				       clk_data->name, 0,
 				       pdata->mmio_base + dev_desc->prv_offset,
 				       0, 0, NULL);
 	if (IS_ERR(pdata->clk))
drivers/clk/x86/clk-lpt.c +11 -4
index 5cf4f46..4f45eee 100644
@@ -15,22 +15,29 @@
 #include <linux/clk-provider.h>
 #include <linux/err.h>
 #include <linux/module.h>
+#include <linux/platform_data/clk-lpss.h>
 #include <linux/platform_device.h>
 
 #define PRV_CLOCK_PARAMS 0x800
 
 static int lpt_clk_probe(struct platform_device *pdev)
 {
+	struct lpss_clk_data *drvdata;
 	struct clk *clk;
 
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
 	/* LPSS free running clock */
-	clk = clk_register_fixed_rate(&pdev->dev, "lpss_clk", NULL, CLK_IS_ROOT,
-				      100000000);
+	drvdata->name = "lpss_clk";
+	clk = clk_register_fixed_rate(&pdev->dev, drvdata->name, NULL,
+				      CLK_IS_ROOT, 100000000);
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-	/* Shared DMA clock */
-	clk_register_clkdev(clk, "hclk", "INTL9C60.0.auto");
+	drvdata->clk = clk;
+	platform_set_drvdata(pdev, drvdata);
 	return 0;
 }
include/linux/platform_data/clk-lpss.h +5 -0
index 528e73c..2390199 100644
@@ -13,6 +13,11 @@
 #ifndef __CLK_LPSS_H
 #define __CLK_LPSS_H
 
+struct lpss_clk_data {
+	const char *name;
+	struct clk *clk;
+};
+
 extern int lpt_clk_init(void);
 
 #endif /* __CLK_LPSS_H */
Signature · 1 line
1.7.10.4
Applied
#3 lore raw
In reply to Andy Shevchenko
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Applied both, Thanks

--
~Vinod

Quoted 25 lines

I will be on vacation next week. Mika promised to help if anything happens to these patches.

Andy Shevchenko (1):
dma: acpi-dma: parse CSRT to extract additional resources

Rafael J. Wysocki (1):
ACPI / LPSS: register clock device for Lynxpoint DMA properly

 drivers/acpi/Makefile                  |    1 -
 drivers/acpi/acpi_lpss.c               |   26 ++++-
 drivers/acpi/csrt.c                    |  159 -----------------------------
 drivers/acpi/internal.h                |    1 -
 drivers/acpi/scan.c                    |    1 -
 drivers/clk/x86/clk-lpt.c              |   15 ++-
 drivers/dma/acpi-dma.c                 |  172 +++++++++++++++++++++++++++++++-
 include/linux/acpi_dma.h               |    4 +
 include/linux/platform_data/clk-lpss.h |    5 +
 9 files changed, 211 insertions(+), 173 deletions(-)
 delete mode 100644 drivers/acpi/csrt.c
Signature · 1 line
1.7.10.4
author
#4 lore raw
Quoted 9 lines · Vinod Koul
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Applied both, Thanks

Thank you for applying them to next.

I'm just wondering if you are going to send pull request soon to get them in the v3.10-rcX.

Besides those two are really needed to support Haswell properly, there are people who are waiting for those patches, because patches touch ACPI subsystem.

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#5 lore raw
Quoted 9 lines · Andy Shevchenko
Quoted 8 lines · Vinod Koul
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Quoted 6 lines
Quoted 1 line

Applied both, Thanks

Thank you for applying them to next.

I'm just wondering if you are going to send pull request soon to get them in the v3.10-rcX.

Nope these are in next & would show up in Linus's tree in next merge window. Something which is not a bug fix doesnt get merged in rc's. You should know the process

Quoted 4 lines

Besides those two are really needed to support Haswell properly, there are people who are waiting for those patches, because patches touch ACPI subsystem.

well distro's should cherry-pick the patch, this is fairly common way to do so

--
~Vinod

#6 lore raw
Quoted 12 lines · Vinod Koul
Quoted 11 lines · Andy Shevchenko
Quoted 9 lines · Vinod Koul
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Applied both, Thanks

Quoted 7 lines
Quoted 4 lines

Thank you for applying them to next.

I'm just wondering if you are going to send pull request soon to get them in the v3.10-rcX.

Nope these are in next & would show up in Linus's tree in next merge window. Something which is not a bug fix doesnt get merged in rc's. You should know the process

Hmm... Now we have a situation when v3.9.x has support of Lynxpoint DMA, v3.10-rc2 has it broken.
As far as I remember our discussion [1] we agreed to wait for v3.10-rc1 due to merge of linux-pm patches.

For us it sounds like a regression.

[1] https://lkml.org/lkml/2013/4/22/34

--
With Best Regards,
Andy Shevchenko

#7 lore raw
Quoted 17 lines · Andy Shevchenko
Quoted 16 lines · Vinod Koul
Quoted 15 lines · Andy Shevchenko
Quoted 9 lines · Vinod Koul
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Applied both, Thanks

Thank you for applying them to next.

I'm just wondering if you are going to send pull request soon to get them in the v3.10-rcX.

Quoted 8 lines
Quoted 3 lines

Nope these are in next & would show up in Linus's tree in next merge window. Something which is not a bug fix doesnt get merged in rc's. You should know the process

Hmm... Now we have a situation when v3.9.x has support of Lynxpoint DMA, v3.10-rc2 has it broken.
As far as I remember our discussion [1] we agreed to wait for v3.10-rc1 due to merge of linux-pm patches.

Yes, and we need that stuff for BayTrail support as well. Currently Rafael is waiting these patches so that he can then merge [1].

[1] https://lkml.org/lkml/2013/5/13/542

#8 lore raw
Quoted 16 lines · Mika Westerberg
Quoted 15 lines · Andy Shevchenko
Quoted 14 lines · Vinod Koul
Quoted 13 lines · Andy Shevchenko
Quoted 9 lines · Vinod Koul
Quoted 7 lines · Andy Shevchenko

This is the rest of patch series related to ACPI DMA helpers and Lynxpoint DMAC. Patches are rebased against current Linus' tree and Vinod's branch for-linus.

Since v2:
- remove patches that are already in the Vinod's tree
- rebase on top of today's origin/master and Vinod's for-linus branch
- fix description in patch 2/2

Applied both, Thanks

Thank you for applying them to next.

Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

I'm just wondering if you are going to send pull request soon to get them in the v3.10-rcX.

Nope these are in next & would show up in Linus's tree in next merge window. Something which is not a bug fix doesnt get merged in rc's. You should know the process

Hmm... Now we have a situation when v3.9.x has support of Lynxpoint DMA, v3.10-rc2 has it broken.

How does it work in 3.9 and not in 3.10?

Quoted 2 lines
Quoted 2 lines

As far as I remember our discussion [1] we agreed to wait for v3.10-rc1 due to merge of linux-pm patches.

Yes I applied these. BUT that does not mean they will get merged to Linus as this is not a fix. Which part is not obvious here. This is _the_ process.

Quoted 2 lines

Yes, and we need that stuff for BayTrail support as well. Currently Rafael is waiting these patches so that he can then merge [1].

I can keep these in a topic/branch which wont eb rebased. So Rafael can merge the other dependecies. Let me know if you would like that.

--
~Vinod