* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Robin Murphy @ 2016-11-04 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> + struct pci_dev *dev)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + struct iommu_reserved_region *region;
> + struct resource_entry *window;
> + phys_addr_t start;
> + size_t length;
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
> + continue;
> +
> + start = window->res->start - window->offset;
> + length = window->res->end - window->res->start + 1;
> +
> + iommu_reserved_region_for_each(region, domain) {
> + if (region->start == start && region->length == length)
> + continue;
> + }
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = start;
> + region->length = length;
> +
> + list_add_tail(®ion->list, &domain->reserved_regions);
> + }
> + return 0;
> +}
Per the previous observation, let's just convert
iova_reserve_pci_windows() into a public iommu_dma_get_dm_regions()
callback...
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> + struct device *device)
> +{
> + struct iommu_reserved_region *region;
> + int ret = 0;
> +
> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> + if (!domain->iova_cookie) {
> +
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = MSI_IOVA_BASE;
> + region->length = MSI_IOVA_LENGTH;
> + list_add_tail(®ion->list, &domain->reserved_regions);
> +
> + ret = iommu_get_dma_msi_region_cookie(domain,
> + region->start, region->length);
> + if (ret)
> + return ret;
...and stick this bit in there as well. Then we only need to add code to
individual IOMMU drivers if there are also regions which bypass
translation at the IOMMU itself (if someone does ever integrate an SMMU
with an upstream/parallel ITS, x86-style, I think we'd need to describe
that with a DT property on the SMMU, so it would have to be the SMMU
driver's responsibility).
Robin.
> + }
> +
> + if (dev_is_pci(device))
> + ret = add_pci_window_reserved_regions(domain,
> + to_pci_dev(device));
> + return ret;
> +}
> +
> static struct iommu_ops arm_smmu_ops = {
> .capable = arm_smmu_capable,
> .domain_alloc = arm_smmu_domain_alloc,
> @@ -1548,6 +1613,7 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> .domain_get_attr = arm_smmu_domain_get_attr,
> .domain_set_attr = arm_smmu_domain_set_attr,
> .of_xlate = arm_smmu_of_xlate,
> + .add_reserved_regions = arm_smmu_add_reserved_regions,
> .pgsize_bitmap = -1UL, /* Restricted during device attach */
> };
>
>
^ permalink raw reply
* [PATCH v3] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Robin Murphy @ 2016-11-04 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478253323-9231-1-git-send-email-nipun.gupta@nxp.com>
On 04/11/16 09:55, Nipun Gupta wrote:
> The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
> option to enable the updation of TLB in case of bypass transactions due to
> no stream match in the stream match table. This reduces the latencies of
> the subsequent transactions with the same stream-id which bypasses the SMMU.
> This provides a significant performance benefit for certain networking
> workloads.
>
> With this change substantial performance improvement of ~9% is observed with
> DPDK l3fwd application (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
> on NXP's LS2088a platform.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> Changes for v2:
> - Incorporated Robin's comments on v1 related to
> Setting SMTNMB_TLBEN in ACR only for MMU-500 as ACR is implementation dependent
> Code comments and Naming convention
> Changes for v3:
> - Added correct patch version
>
> drivers/iommu/arm-smmu.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index ce2a9d4..05901be 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -247,6 +247,7 @@ enum arm_smmu_s2cr_privcfg {
> #define ARM_MMU500_ACTLR_CPRE (1 << 1)
>
> #define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
> +#define ARM_MMU500_ACR_SMTNMB_TLBEN (1 << 8)
>
> #define CB_PAR_F (1 << 0)
>
> @@ -1569,16 +1570,22 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> for (i = 0; i < smmu->num_mapping_groups; ++i)
> arm_smmu_write_sme(smmu, i);
>
> - /*
> - * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> - * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> - * bit is only present in MMU-500r2 onwards.
> - */
> - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> - major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> - if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> + if (smmu->model == ARM_MMU500) {
> + /*
> + * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> + * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> + * bit is only present in MMU-500r2 onwards.
> + */
> + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> + major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> - reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> + if (major >= 2)
> + reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> + /*
> + * Allow unmatched Stream IDs to allocate bypass
> + * TLB entries for reduced latency.
> + */
> + reg |= ARM_MMU500_ACR_SMTNMB_TLBEN;
> writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> }
>
>
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.10 #1
From: Alexandre Torgue @ 2016-11-04 14:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this first round of STM32 DT updates for v4.10:
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
tags/stm32-dt-for-v4.10-1
for you to fetch changes up to f6dbbff4f0af1a5c0d6eaf414572b5eff7a73a8b:
ARM: dts: stm32f429: add LSI and LSE clocks (2016-11-04 15:08:08 +0100)
----------------------------------------------------------------
STM32 DT updates for v4.10, round 1.
Highlights:
----------
- Add LSI and LSE clocks support for STM32F429
- Add GPIO IRQ support for STM32F429
- Declare push button as GPIO keys on STM32F429 boards
- Add DMA supports on USART1 & USART3 on STM32F429
- Add Ethernet fixes
----------------------------------------------------------------
Alexandre TORGUE (5):
ARM: DT: STM32: add dma for usart3 on F429
ARM: DT: stm32: move dma translation to board files
ARM: dts: stm32f429: Align Ethernet node with new bindings properties
ARM: dts: stm32f429: Fix Ethernet node on Eval Board
ARM: dts: stm32f429: remove Ethernet wake on Lan support
Gabriel Fernandez (1):
ARM: dts: stm32f429: add LSI and LSE clocks
Gerald Baeza (1):
ARM: DT: STM32: add dma for usart1 on F429
Maxime Coquelin (2):
ARM: dts: Add GPIO irq support to STM32F429
ARM: dts: Declare push button as GPIO key on stm32f429 boards
arch/arm/boot/dts/stm32429i-eval.dts | 29 ++++++++++++++++++++++---
arch/arm/boot/dts/stm32f429-disco.dts | 13 ++++++++++++
arch/arm/boot/dts/stm32f429.dtsi | 40
+++++++++++++++++++++++++++--------
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
4 files changed, 74 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-11-04 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk2cvrtxt.fsf@baylibre.com>
On Wed, Oct 26, 2016 at 5:50 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Yes they are all wrong. They should all be using irq_find_mapping().
>
> So, dumb question from someone trying (but having a hard time) to follow
> and understand the rationale...
>
> If it's wrong enough to completely reject, why are changes still being
> merged that are doing it so wrong? (e.g. like this one[1], just merged
> for v4.9)
It's a bug.
It's that problem that Wolfram brought up in a recent lecture
about maintainer scaling: if noone but the subsystem maintainer
reviews the code, things like this will happen.
I need more review...
> [1] 0eb9f683336d pinctrl: Add IRQ support to STM32 gpios
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/stm32/pinctrl-stm32.c?id=0eb9f683336d7eb99a3b75987620417c574ffb57
Alexandre, Maxime: can you please make a patch for the STM32
driver that remove the semantic dependence for .to_irq() to be called
before an interrupt can be used? It should be possible to use
the irqs directly from the irqchip.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: sun8i: sina33: Enable USB gadget
From: Maxime Ripard @ 2016-11-04 14:44 UTC (permalink / raw)
To: linux-arm-kernel
The micro-USB on the SinA33 has a somewhat interesting design in the sense
that it has a micro USB connector, but the VBUS is (supposed to be)
controlled through an (unpopulated) jumper.
Obviously, that doesn't work really well, and only the peripheral mode
really works. Still enable it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fa8024072025..1c0d98cbd334 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -247,6 +247,11 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
usb1_vbus-supply = <®_vcc5v0>; /* USB1 VBUS is always on */
--
2.10.1
^ permalink raw reply related
* [PATCH] simplefb: Separate clk / regulator get and enable steps
From: Hans de Goede @ 2016-11-04 14:45 UTC (permalink / raw)
To: linux-arm-kernel
Currently when a simplefb needs both clocks and regulators and one
of the regulators returns -EPROBE_DEFER when we try to get it, we end
up disabling the clocks. This causes the screen to go blank; and in some
cases my cause hardware state to be lost resulting in the framebuffer not
working at all.
This commit splits the get and enable steps and only enables
clocks and regulators after successfully getting all of them,
fixing the disabling of the clocks which were left enabled by
the firmware setting up the simplefb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 56 ++++++++++++++++++++++++++++++------------
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 61f799a..a3c44ec 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -180,10 +180,12 @@ static int simplefb_parse_pd(struct platform_device *pdev,
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ bool clks_enabled;
unsigned int clk_count;
struct clk **clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ bool regulators_enabled;
u32 regulator_count;
struct regulator **regulators;
#endif
@@ -208,12 +210,12 @@ struct simplefb_par {
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_clocks_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_clocks_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct clk *clock;
- int i, ret;
+ int i;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -244,6 +246,14 @@ static int simplefb_clocks_init(struct simplefb_par *par,
par->clks[i] = clock;
}
+ return 0;
+}
+
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
ret = clk_prepare_enable(par->clks[i]);
@@ -256,8 +266,7 @@ static int simplefb_clocks_init(struct simplefb_par *par,
}
}
}
-
- return 0;
+ par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
@@ -269,7 +278,8 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
- clk_disable_unprepare(par->clks[i]);
+ if (par->clks_enabled)
+ clk_disable_unprepare(par->clks[i]);
clk_put(par->clks[i]);
}
}
@@ -277,8 +287,10 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
kfree(par->clks);
}
#else
-static int simplefb_clocks_init(struct simplefb_par *par,
+static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
@@ -305,14 +317,14 @@ static void simplefb_clocks_destroy(struct simplefb_par *par) { }
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_regulators_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_regulators_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
struct regulator *regulator;
const char *p;
- int count = 0, i = 0, ret;
+ int count = 0, i = 0;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -354,6 +366,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
}
par->regulator_count = i;
+ return 0;
+}
+
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
/* Enable all the regulators */
for (i = 0; i < par->regulator_count; i++) {
ret = regulator_enable(par->regulators[i]);
@@ -365,15 +385,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
par->regulators[i] = NULL;
}
}
-
- return 0;
+ par->regulators_enabled = true;
}
static void simplefb_regulators_destroy(struct simplefb_par *par)
{
int i;
- if (!par->regulators)
+ if (!par->regulators || !par->regulators_enabled)
return;
for (i = 0; i < par->regulator_count; i++)
@@ -381,8 +400,10 @@ static void simplefb_regulators_destroy(struct simplefb_par *par)
regulator_disable(par->regulators[i]);
}
#else
-static int simplefb_regulators_init(struct simplefb_par *par,
+static int simplefb_regulators_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_regulators_destroy(struct simplefb_par *par) { }
#endif
@@ -453,14 +474,17 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = par->palette;
- ret = simplefb_clocks_init(par, pdev);
+ ret = simplefb_clocks_get(par, pdev);
if (ret < 0)
goto error_unmap;
- ret = simplefb_regulators_init(par, pdev);
+ ret = simplefb_regulators_get(par, pdev);
if (ret < 0)
goto error_clocks;
+ simplefb_clocks_enable(par, pdev);
+ simplefb_regulators_enable(par, pdev);
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
--
2.9.3
^ permalink raw reply related
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Tony Lindgren @ 2016-11-04 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104074533.GB3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:45]:
> Hi!
>
> > > > I have to admit I mostly use an N9.
> > >
> > > Well, if you compare that to development on PC, I prefer PC.
> > >
> > > Even arm development boards are usually easier, as they don't need too
> > > complex userspace, and do have working serial ports.
> > >
> > > But I do have a serial adapter for N900 now (thanks, sre), so my main
> > > problem now is that N900 takes a lot of time to boot into usable
> > > state.
> >
> > Yeah... I just upgraded my Debian installation (armel over NFS) a few major
> > numbers and I find it a lot slower than it used to do. I presume that's
> > mostly because of systemd...
>
> I'm not sure if systemd is to blame. (I'm booting into full GUI...)
>
> And yes, I noticed the slowdown in Debian 7 -> 8 transition, so I'm
> basically staying at Debian 7 as far as I can.
Maybe it's the armel vs armhf causing the slowdown?
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Tony Lindgren @ 2016-11-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104070955.GA3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> Do you actually have hardware with more than one bq27xxx?
I can at least see the twl4030 battery/charger features
being used together with some bq device to monitor the
battery state. Not sure if that counts as multiple
instances here though :)
Regards,
Tony
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-11-04 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477564941.2482.240.camel@baylibre.com>
On Thu, Oct 27, 2016 at 12:42 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Ressource issue : When you create an irq mapping, in case of hierarchic
> domain, it calls the "alloc" function of the domain, which will
> eventually call the "alloc" function of the parent domain ... until you
> reach the "root" domain (here the gic).
(...)
> We are looking to create mapping "on-demand" to make the best use of
> the little number of interrupts we have. To catch request of drivers,
> like gpio-keys, which use gpio_to_irq, it looks the only viable place
> is the to_irq callback (at the moment).
>
> Drivers using gpio_to_irq in their probe function expect that this will
> give them the corresponding virq, so create the mapping if need be.
OK what I need to know is the following:
If this was not a gpio chip, just some random hierarchical irqchip
or mux from drivers/irqchip, where would you make the translation?
The answer to that question applies equally to any GPIO controller
that also provides an irqchip. .to_irq() is not the place to do the
translation.
I looked around and for example irq-s3c24xx.c seems to do this
in the irqdomain xlate() callback, which should only be called
when the interrupt is resolved for a consumer.
If that is the code that you partitioned over to drivers/irqchip,
then maybe this is a sign that this code should not be there
at all, but instead inside this gpiochip driver, or atleast accessible
by it so that your gpiochip driver has direct access to the
irqdomain it is using.
> However, I now get why you don't want that, it seems we have 2 types of
> platforms in the kernel right now:
>
> 1. The one creating the mapping in the to_irq callback. It might be
> because they just copy/paste from another driver doing it, or they may
> have a good reason for it (like I think we do)
>
> 2. the one which call gpio_to_irq in interrupt handlers. Honestly I did
> not know that one could that, but they are in the mainline too, and
> probably have a good reason for doing it.
They are probably all bad or legacy. None of this works with a
irqchip from DT like this:
foo: gpio at 0 {
#gpio-cells = <2>;
gpio-controller;
interrupt-cells = <2>;
interrupt-controller;
}
bar: bar at 1 {
interrupt-parent = <&foo>;
interrupt = <4>;
};
Here notice that bar is NOT doing gpios = <&foo 4>;
which is what you would do to get a GPIO and then call
.to_irq() on it. It just uses it as an interrupt controller.
This MUST work, or you cannot put interrupt-controller;
as a keyword on the gpiochip.
> irq_find_mapping looks safe in interrupt handler, I does not seem to
> sleep (please correct me if I'm wrong).
> irq_create_mapping definitely isn't, because of the irq_domain mutex.
Yep.
> We probably got into this situation because it wasn't clear enough
> whether to_irq was fast or slow (at least it took me a few mails to
> understand this ...)
I don't know either. It's just supposed to be a quick helper
to find the corresponding interrupt for a GPIO, it is not supposed
to have semantic side-effects.
> The two platform groups are most likely exclusive so nobody is sleeping
> in irq, everybody is happy. As a maintainer, I understand that you
> can't allow a dangerous situation like this to continue.
It's a mess allright. I need everyone's help to fix the mess.
> To fix the situation we could add a few things in the gpio subsys:
> - Make it clear that to_irq is fast (like you just did)
Sure patches accepted.
> - add a new callback (to_irq_slow ? provide_irq ? something else) which
> would be allowed to sleep and create mappings.
> - in gpio_to_irq function keeps calling to_irq like it does but also
> call to_irq_slow only if we are not in an interrupt context and a
> mapping could not be found. We could maybe use "in_interrupt()" for
> this ?
None of them should be allowed to create mappings because of the
explanation above: gpiochips and irqchips need to be
orthogonal.
> This way, we could keep the existing drivers working as they are (even
> if they are wrong) and slowly fix things up.
It doesn't seem to help with anything.
Instead go back to what I described above: if it was just
two irqchips: forget the fact that one of them is a GPIO chip
for a while, just two irqchips.
How does one irqchip map to another one?
That is what needs to happen, solely using the irqchip
infrastructure, NOT using .to_irq().
> Sorry, it was kind of long explanation but I hope things are more clear
> now.
I think I understand... famous last words.
>> I just misunderstand it as the global GPIO number, that is
>> not OK.
>
> Ok. Just to be clear, you are ok with the function
> "meson_gpio_to_hwirq" which just does this translation, right ?
That seems all right, the problem is relying on gpio_to_irq()
being called for the interrupts to work.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-04 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4066252.a1W9ejEKHX@phil>
On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
> Hi Jaehoon,
>
> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> > On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> > >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> > >> It should be same behavior. So Use the "max-frequency" instead of
> > >> "clock-freq-min-max".
> > >>
> > >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > >> ---
> > >>
> > >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> > >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> > >> 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > This looks totally independent to rest of patches so it can be applied
> > > separately without any functional impact (except lack of minimum
> > > frequency). Is that correct?
> >
> > You're right. I will split the patches. And will resend.
> > Thanks!
>
> I think what Krzysztof was asking was just if he can simply pick up this patch
> alone, as it does not require any of the previous changes.
>
> Same is true for the Rockchip patches I guess, so we could just take them
> individually into samsung/rockchip dts branches.
Yes, I wanted to get exactly this information. I couldn't find it in
cover letter.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <421e2b14-0231-d376-02a0-097423120b3d@arm.com>
Hi Robin,
>>>Yikes, on second look, that definitely shouldn't be happening.
>>>Everything below is probably the resulting fallout.
>>
>>[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>
>>I think the above print which says "failed to setup iommu_ops"
>>because the call ops->add_device failed in of_pci_iommu_configure
>>is the reason for the failure, in my case i simply do not get this even with
>>your scripts. ops->add_device succeeds in the rebind as well. So still
>>checking what could be happening in your case.
>
>I was looking at your code base from [1].The ops->add_device
>callback from of_pci_iommu_configure on the rebind is the
>one which is causing the failure. But not able to spot out
>from code which point is causing the failure. It would be very helpful
>if i can know which is the return value from the add_device callback
>or point inside add_device callback which fails in your setup.
>
>
>[1] git://linux-arm.org/linux-rm iommu/misc
With little more try, i saw an issue where i had an failure
similar to what you reported. The issue happens when multiple
devices fall in to same group due to matching sids. I ended up
doing a fix like below and it would be nice to verify if it is the same
that we are seeing in your setup and if the fix makes a difference ?
From: Sricharan R <sricharan@codeaurora.org>
Date: Fri, 4 Nov 2016 20:28:49 +0530
Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
iommu_group_get_for_dev which gets called in the add_device
callback, increases the reference count of the iommu_group,
so we do an iommu_group_put after that. iommu_group_get_for_dev
inturn calls device_group callback and in the case of arm-smmu
we call generic_device_group/pci_device_group which takes
care of increasing the group's reference. But when we return
an already existing group(when multiple devices have same group)
the reference is not incremented, resulting in issues when the
remove_device callback for the devices is invoked.
Fixing the same here.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 71ce4b6..a1d0b3c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
group = smmu->s2crs[idx].group;
}
- if (group)
+ if (group) {
+ iommu_group_get_by_id(iommu_group_id(group));
return group;
+ }
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
1.8.2.1
^ permalink raw reply related
* [PATCH 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig()
From: Catalin Marinas @ 2016-11-04 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104025216.GA19810@sha-win-210.asiapac.arm.com>
On Fri, Nov 04, 2016 at 10:52:17AM +0800, Huang Shijie wrote:
> On Thu, Nov 03, 2016 at 06:16:16PM -0600, Catalin Marinas wrote:
> > On Thu, Nov 03, 2016 at 10:27:38AM +0800, Huang Shijie wrote:
> > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > > index 2e49bd2..4811ef1 100644
> > > --- a/arch/arm64/mm/hugetlbpage.c
> > > +++ b/arch/arm64/mm/hugetlbpage.c
> > > @@ -61,10 +61,6 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
> > > return 1;
> > > }
> > > pmd = pmd_offset(pud, addr);
> > > - if (!pmd_present(*pmd)) {
> > > - VM_BUG_ON(!pmd_present(*pmd));
> > > - return 1;
> > > - }
> > > if ((pte_t *)pmd == ptep) {
> > > *pgsize = PMD_SIZE;
> > > return CONT_PMDS;
> >
> > BTW, for the !pud_present() and !pgd_present() cases, shouldn't
> > find_num_contig() actually return 0? These are more likely real bugs, so
> > no point in setting the huge pte.
>
> The kernel will not call the find_num_contig() if the PGD/PUD are empty.
> Please see the code in the hugetlb_fault().
>
> ------------------------------------------------------
> ptep = huge_pte_offset(mm, address);
> if (ptep) {
> ...............................
> } else {
> ptep = huge_pte_alloc(mm, address, huge_page_size(h));
> if (!ptep)
> return VM_FAULT_OOM;
> }
> ------------------------------------------------------
Exactly. So what is the reason for returning 1 if !pgd_present()? Would
removing the checks entirely or adding BUG() be a better option?
--
Catalin
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Catalin Marinas @ 2016-11-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027163058.12156-9-kevin.brodsky@arm.com>
On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
> * The vDSO page replaces the vector page. The vDSO provides its own
> sigreturn trampolines, replacing those in the vector page, but the
> kuser helpers are gone. As a result enabling the compat vDSO will
> break userspace programs relying on the kuser helpers.
I think vDSO and vectors page should not exclude each other. If you want
to disable the vectors page, let's make it an independent config option
like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
like to be able to have both the vDSO and the vectors page at the same
time.
--
Catalin
^ permalink raw reply
* [PATCH net-next 0/2] ARM64: Add Internal PHY support for Meson GXL
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
external RGMII pins.
In order to support switching between the two PHYs links, extended registers
size for mdio-mux-mmioreg must be added.
The DT related patches submitted as RFC in [3] will be sent in a separate
patchset due to multiple patchsets and DTSI migrations.
Changes since v2 RFC patchset at : [3]
- Change phy Kconfig/Makefile alphabetic order
- GXL dtsi cleanup
Changes since original RFC patchset at : [2]
- Remove meson8b experimental phy switching
- Switch to mdio-mux-mmioreg with extennded size support
- Add internal phy support for S905x and p231
- Add external PHY support for p230
[1] http://lkml.kernel.org/r/1477932286-27482-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1477932987-27871-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (2):
net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
net: phy: Add Meson GXL Internal PHY driver
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-mmioreg.c | 60 ++++++++++++----
drivers/net/phy/meson-gxl.c | 81 ++++++++++++++++++++++
5 files changed, 136 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/phy/meson-gxl.c
--
1.9.1
^ permalink raw reply
* [PATCH net-next 1/2] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
In order to support PHY switching on Amlogic GXL SoCs, add support for
16bit and 32bit registers sizes.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
index 8516929..065e8bd 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
+++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
@@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
-supports devices with eight-bit registers.
+supports devices with 8, 16 or 32-bit registers.
Required properties in addition to the generic multiplexer properties:
@@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
- register, and must therefore be 1.
+ register, and must therefore be 1, 2, or 4.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c b/drivers/net/phy/mdio-mux-mmioreg.c
index d0bed52..6a33646 100644
--- a/drivers/net/phy/mdio-mux-mmioreg.c
+++ b/drivers/net/phy/mdio-mux-mmioreg.c
@@ -21,7 +21,8 @@
struct mdio_mux_mmioreg_state {
void *mux_handle;
phys_addr_t phys;
- uint8_t mask;
+ unsigned int iosize;
+ unsigned int mask;
};
/*
@@ -47,17 +48,47 @@ static int mdio_mux_mmioreg_switch_fn(int current_child, int desired_child,
struct mdio_mux_mmioreg_state *s = data;
if (current_child ^ desired_child) {
- void __iomem *p = ioremap(s->phys, 1);
- uint8_t x, y;
-
+ void __iomem *p = ioremap(s->phys, s->iosize);
if (!p)
return -ENOMEM;
- x = ioread8(p);
- y = (x & ~s->mask) | desired_child;
- if (x != y) {
- iowrite8((x & ~s->mask) | desired_child, p);
- pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ switch (s->iosize) {
+ case sizeof(uint8_t): {
+ uint8_t x, y;
+
+ x = ioread8(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite8((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint16_t): {
+ uint16_t x, y;
+
+ x = ioread16(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite16((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %04x -> %04x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint32_t): {
+ uint32_t x, y;
+
+ x = ioread32(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite32((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %08x -> %08x\n", __func__, x, y);
+ }
+
+ break;
+ }
}
iounmap(p);
@@ -88,8 +119,11 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
}
s->phys = res.start;
- if (resource_size(&res) != sizeof(uint8_t)) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ s->iosize = resource_size(&res);
+ if (s->iosize != sizeof(uint8_t) &&
+ s->iosize != sizeof(uint16_t) &&
+ s->iosize != sizeof(uint32_t)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
@@ -98,8 +132,8 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing or invalid mux-mask property\n");
return -ENODEV;
}
- if (be32_to_cpup(iprop) > 255) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ if (be32_to_cpup(iprop) >= BIT(s->iosize * 8)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
s->mask = be32_to_cpup(iprop);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
This PHY seems to only implement some standard registers and need some
workarounds to provide autoneg values from vendor registers.
Some magic values are currently used to configure the PHY, and this a
temporary setup until clarification about these registers names and
registers fields are provided by Amlogic.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+)
create mode 100644 drivers/net/phy/meson-gxl.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2651c8d..b48943a 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -264,6 +264,11 @@ config MARVELL_PHY
---help---
Currently has a driver for the 88E1011S
+config MESON_GXL_PHY
+ tristate "Amlogic Meson GXL Internal PHY"
+ ---help---
+ Currently has a driver for the Amlogic Meson GXL Internal PHY
+
config MICREL_PHY
tristate "Micrel PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..3cd5af7 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
+obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
new file mode 100644
index 0000000..1ea69b7
--- /dev/null
+++ b/drivers/net/phy/meson-gxl.c
@@ -0,0 +1,81 @@
+/*
+ * Amlogic Meson GXL Internal PHY Driver
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ * Copyright (C) 2016 BayLibre, SAS. All rights reserved.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+static int meson_gxl_config_init(struct phy_device *phydev)
+{
+ /* Enable Analog and DSP register Bank access by */
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+
+ /* Write Analog register 23 */
+ phy_write(phydev, 0x17, 0x8E0D);
+ phy_write(phydev, 0x14, 0x4417);
+
+ /* Enable fractional PLL */
+ phy_write(phydev, 0x17, 0x0005);
+ phy_write(phydev, 0x14, 0x5C1B);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0x029A);
+ phy_write(phydev, 0x14, 0x5C1D);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0xAAAA);
+ phy_write(phydev, 0x14, 0x5C1C);
+
+ return 0;
+}
+
+static struct phy_driver meson_gxl_phy[] = {
+ {
+ .phy_id = 0x01814400,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Meson GXL Internal PHY",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_IS_INTERNAL,
+ .config_init = meson_gxl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .aneg_done = genphy_aneg_done,
+ .read_status = genphy_read_status,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ },
+};
+
+static struct mdio_device_id __maybe_unused meson_gxl_tbl[] = {
+ { 0x01814400, 0xfffffff0 },
+ { }
+};
+
+module_phy_driver(meson_gxl_phy);
+
+MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
+
+MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
+MODULE_AUTHOR("Baoqi wang");
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smdk6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smd6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 1/7] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch add support for the new channel request API
introduced in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel"
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 3 +++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..d5c75c8 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2307,6 +2307,9 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch adds DMA slave map tables to the pl080 devices's
platform_data in order to support the new channel request API.
A few devices for which there was no DMA support with current
code are omitted from the tables.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
index 89c5a62..8c88680 100644
--- a/arch/arm/mach-s3c64xx/pl080.c
+++ b/arch/arm/mach-s3c64xx/pl080.c
@@ -117,6 +117,25 @@ static void pl08x_put_xfer_signal(const struct pl08x_channel_data *cd, int ch)
}
};
+static const struct dma_slave_map s3c64xx_dma0_slave_map[] = {
+ { "s3c6400-uart.0", "tx", (void *)"uart0_tx" },
+ { "s3c6400-uart.0", "rx", (void *)"uart0_rx" },
+ { "s3c6400-uart.1", "tx", (void *)"uart1_tx" },
+ { "s3c6400-uart.1", "rx", (void *)"uart1_rx" },
+ { "s3c6400-uart.2", "tx", (void *)"uart2_tx" },
+ { "s3c6400-uart.2", "rx", (void *)"uart2_rx" },
+ { "s3c6400-uart.3", "tx", (void *)"uart3_tx" },
+ { "s3c6400-uart.3", "rx", (void *)"uart3_rx" },
+ { "samsung-pcm.0", "tx", (void *)"pcm0_tx" },
+ { "samsung-pcm.0", "rx", (void *)"pcm0_rx" },
+ { "samsung-i2s.0", "tx", (void *)"i2s0_tx" },
+ { "samsung-i2s.0", "rx", (void *)"i2s0_rx" },
+ { "s3c6410-spi.0", "tx", (void *)"spi0_tx" },
+ { "s3c6410-spi.0", "rx", (void *)"spi0_rx" },
+ { "samsung-i2s.2", "tx", (void *)"i2s2_tx" },
+ { "samsung-i2s.2", "rx", (void *)"i2s2_rx" },
+};
+
struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma0_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
+ .slave_map = s3c64xx_dma0_slave_map,
+ .slavecnt = ARRAY_SIZE(s3c64xx_dma0_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
@@ -207,6 +228,15 @@ static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
},
};
+static const struct dma_slave_map s3c64xx_dma1_slave_map[] = {
+ { "samsung-pcm.1", "tx", (void *)"pcm1_tx" },
+ { "samsung-pcm.1", "rx", (void *)"pcm1_rx" },
+ { "samsung-i2s.1", "tx", (void *)"i2s1_tx" },
+ { "samsung-i2s.1", "rx", (void *)"i2s1_rx" },
+ { "s3c6410-spi.1", "tx", (void *)"spi1_tx" },
+ { "s3c6410-spi.1", "rx", (void *)"spi1_rx" },
+};
+
struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -224,6 +254,8 @@ struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma1_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma1_info),
+ .slave_map = s3c64xx_dma1_slave_map,
+ .slavecnt = ARRAY_SIZE(s3c64xx_dma1_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma1, "dma-pl080s.1", 0,
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 3/7] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to DMA slaves so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/spi/spi-s3c64xx.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 3c09e94..28dfdce 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -341,27 +341,20 @@ static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)
static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
- dma_filter_fn filter = sdd->cntrlr_info->filter;
struct device *dev = &sdd->pdev->dev;
- dma_cap_mask_t mask;
if (is_polling(sdd))
return 0;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
/* Acquire DMA channels */
- sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_rx, dev, "rx");
+ sdd->rx_dma.ch = dma_request_slave_channel(dev, "rx");
if (!sdd->rx_dma.ch) {
dev_err(dev, "Failed to get RX DMA channel\n");
return -EBUSY;
}
spi->dma_rx = sdd->rx_dma.ch;
- sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_tx, dev, "tx");
+ sdd->tx_dma.ch = dma_request_slave_channel(dev, "tx");
if (!sdd->tx_dma.ch) {
dev_err(dev, "Failed to get TX DMA channel\n");
dma_release_channel(sdd->rx_dma.ch);
@@ -1091,11 +1084,6 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
sdd->cur_bpw = 8;
- if (!sdd->pdev->dev.of_node && (!sci->dma_tx || !sci->dma_rx)) {
- dev_warn(&pdev->dev, "Unable to get SPI tx/rx DMA data. Switching to poll mode\n");
- sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
- }
-
sdd->tx_dma.direction = DMA_MEM_TO_DEV;
sdd->rx_dma.direction = DMA_DEV_TO_MEM;
@@ -1205,9 +1193,8 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d with %d Slaves attached\n",
sdd->port_id, master->num_chipselect);
- dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%p, Tx-%p]\n",
- mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1,
- sci->dma_rx, sci->dma_tx);
+ dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\n",
+ mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1);
pm_runtime_mark_last_busy(&pdev->dev);
pm_runtime_put_autosuspend(&pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 4/7] ASoC: samsung: i2s: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
sound/soc/samsung/i2s.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 7e32cf4..95a9a3f 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -90,7 +90,6 @@ struct i2s_dai {
struct snd_dmaengine_dai_dma_data dma_playback;
struct snd_dmaengine_dai_dma_data dma_capture;
struct snd_dmaengine_dai_dma_data idma_playback;
- dma_filter_fn filter;
u32 quirks;
u32 suspend_i2smod;
u32 suspend_i2scon;
@@ -1244,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return ret;
return samsung_asoc_dma_platform_register(&pdev->dev,
- sec_dai->filter, "tx-sec", NULL);
+ NULL, "tx-sec", NULL);
}
pri_dai = i2s_alloc_dai(pdev, false);
@@ -1262,10 +1261,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -EINVAL;
}
- pri_dai->dma_playback.filter_data = i2s_pdata->dma_playback;
- pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
- pri_dai->filter = i2s_pdata->dma_filter;
-
if (&i2s_pdata->type)
i2s_cfg = &i2s_pdata->type.i2s;
@@ -1327,11 +1322,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai->dma_playback.addr = regs_base + I2STXDS;
sec_dai->dma_playback.chan_name = "tx-sec";
- if (!np) {
- sec_dai->dma_playback.filter_data = i2s_pdata->dma_play_sec;
- sec_dai->filter = i2s_pdata->dma_filter;
- }
-
sec_dai->dma_playback.addr_width = 4;
sec_dai->addr = pri_dai->addr;
sec_dai->clk = pri_dai->clk;
@@ -1353,7 +1343,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
if (ret < 0)
goto err_free_dai;
- ret = samsung_asoc_dma_platform_register(&pdev->dev, pri_dai->filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret < 0)
goto err_free_dai;
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 5/7] ASoC: samsung: pcm: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
sound/soc/samsung/pcm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c
index 43e367a..ccedab2 100644
--- a/sound/soc/samsung/pcm.c
+++ b/sound/soc/samsung/pcm.c
@@ -134,18 +134,22 @@ struct s3c_pcm_info {
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_out[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "tx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "tx",
},
};
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_in[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "rx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "rx",
},
};
@@ -488,7 +492,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
struct s3c_pcm_info *pcm;
struct resource *mem_res;
struct s3c_audio_pdata *pcm_pdata;
- dma_filter_fn filter;
int ret;
/* Check for valid device index */
@@ -555,13 +558,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
s3c_pcm_stereo_in[pdev->id].addr = mem_res->start + S3C_PCM_RXFIFO;
s3c_pcm_stereo_out[pdev->id].addr = mem_res->start + S3C_PCM_TXFIFO;
- filter = NULL;
- if (pcm_pdata) {
- s3c_pcm_stereo_in[pdev->id].filter_data = pcm_pdata->dma_capture;
- s3c_pcm_stereo_out[pdev->id].filter_data = pcm_pdata->dma_playback;
- filter = pcm_pdata->dma_filter;
- }
-
pcm->dma_capture = &s3c_pcm_stereo_in[pdev->id];
pcm->dma_playback = &s3c_pcm_stereo_out[pdev->id];
@@ -574,7 +570,7 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
goto err5;
}
- ret = samsung_asoc_dma_platform_register(&pdev->dev, filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret) {
dev_err(&pdev->dev, "failed to get register DMA: %d\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 6/7] ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using those fields so remove them and
remaining initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/plat-samsung/devs.c | 9 ---------
include/linux/platform_data/spi-s3c64xx.h | 3 ---
2 files changed, 12 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e93aa67..4e14bf6 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1124,15 +1124,6 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI0_TX;
- pd.dma_rx = (void *)DMACH_SPI0_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#elif defined(CONFIG_S3C24XX_DMAC)
- pd.filter = s3c24xx_dma_filter;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index 5c1e21c..da79774 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -40,9 +40,6 @@ struct s3c64xx_spi_info {
int num_cs;
bool no_cs;
int (*cfg_gpio)(void);
- dma_filter_fn filter;
- void *dma_tx;
- void *dma_rx;
};
/**
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 7/7] ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata fields
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using these fields so remove them and remaining
initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
include/linux/platform_data/asoc-s3c.h | 5 -----
2 files changed, 24 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b577833..a3f39dd 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,9 +58,6 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S0_OUT,
- .dma_capture = DMACH_I2S0_IN,
};
struct platform_device s3c64xx_device_iis0 = {
@@ -80,9 +77,6 @@ struct platform_device s3c64xx_device_iis0 = {
static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S1_OUT,
- .dma_capture = DMACH_I2S1_IN,
};
struct platform_device s3c64xx_device_iis1 = {
@@ -102,9 +96,6 @@ struct platform_device s3c64xx_device_iis1 = {
static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_HSI_I2SV40_TX,
- .dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
.i2s = {
.quirks = QUIRK_PRI_6CHAN,
@@ -153,9 +144,6 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_PCM0_RX,
- .dma_playback = DMACH_PCM0_TX,
};
struct platform_device s3c64xx_device_pcm0 = {
@@ -175,9 +163,6 @@ struct platform_device s3c64xx_device_pcm0 = {
static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_PCM1_TX,
- .dma_capture = DMACH_PCM1_RX,
};
struct platform_device s3c64xx_device_pcm1 = {
@@ -209,10 +194,6 @@ static int s3c64xx_ac97_cfg_gpe(struct platform_device *pdev)
};
static struct s3c_audio_pdata s3c_ac97_pdata = {
- .dma_playback = DMACH_AC97_PCMOUT,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_AC97_PCMIN,
- .dma_capture_mic = DMACH_AC97_MICIN,
};
static u64 s3c64xx_ac97_dmamask = DMA_BIT_MASK(32);
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 15bf56e..2d415f6 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -42,11 +42,6 @@ struct samsung_i2s {
*/
struct s3c_audio_pdata {
int (*cfg_gpio)(struct platform_device *);
- dma_filter_fn dma_filter;
- void *dma_playback;
- void *dma_capture;
- void *dma_play_sec;
- void *dma_capture_mic;
union {
struct samsung_i2s i2s;
} type;
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox