* [PATCHv6 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.
From: Denis Carikli @ 2014-01-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390398511-8041-1-git-send-email-denis@eukrea.com>
If de-active and/or pixelclk-active properties were set in the
display-timings DT node, they were not used.
Instead the data-enable and the pixel data clock polarity
were hardcoded.
This change is needed for making the eukrea-cpuimx51
QVGA display work.
Cc: David Airlie <airlied@linux.ie>
Cc: Eric B?nard <eric@eukrea.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: dri-devel at lists.freedesktop.org
Cc: driverdev-devel at linuxdriverproject.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Removed wrong coments from the code.
- Corrected the code style of the "if (!!val)"
ChangeLog v3->v4:
- The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some mode".
- Reworked the patch entierly: we now takes the mode flags from the device tree.
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
drivers/staging/imx-drm/imx-drm.h | 3 +++
drivers/staging/imx-drm/ipuv3-crtc.c | 8 ++++++--
drivers/staging/imx-drm/parallel-display.c | 27 +++++++++++++++++++++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm.h b/drivers/staging/imx-drm/imx-drm.h
index ae90c9c..dfdc180 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -5,6 +5,9 @@
#define IPU_PIX_FMT_GBR24 v4l2_fourcc('G', 'B', 'R', '3')
+#define IMXDRM_MODE_FLAG_DE_HIGH (1<<0)
+#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE (1<<1)
+
struct drm_crtc;
struct drm_connector;
struct drm_device;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index ce6ba98..ce8e6e4 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -156,8 +156,12 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = 1;
- sig_cfg.clk_pol = 1;
+ if (mode->private_flags & IMXDRM_MODE_FLAG_DE_HIGH)
+ sig_cfg.enable_pol = 1;
+
+ if (mode->private_flags & IMXDRM_MODE_FLAG_PIXDATA_POSEDGE)
+ sig_cfg.clk_pol = 1;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index bb71d6d..02aa4da 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -74,7 +74,34 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ struct device_node *timings_np;
+ struct device_node *mode_np;
+ u32 val;
+
of_get_drm_display_mode(np, &imxpd->mode, 0);
+
+ timings_np = of_get_child_by_name(np, "display-timings");
+ if (timings_np) {
+ /* get the display mode node */
+ mode_np = of_parse_phandle(timings_np,
+ "native-mode", 0);
+ if (!mode_np)
+ mode_np = of_get_next_child(timings_np, NULL);
+
+ /* set de-active to 1 if not set */
+ of_property_read_u32(mode_np, "de-active", &val);
+ if (val) {
+ imxpd->mode.private_flags |=
+ IMXDRM_MODE_FLAG_DE_HIGH;
+ }
+
+ /* set pixelclk-active to 1 if not set */
+ of_property_read_u32(mode_np, "pixelclk-active", &val);
+ if (val) {
+ imxpd->mode.private_flags |=
+ IMXDRM_MODE_FLAG_PIXDATA_POSEDGE;
+ }
+ }
drm_mode_copy(mode, &imxpd->mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
drm_mode_probed_add(connector, mode);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Will Deacon @ 2014-01-22 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a73ef0128a0141eabf0a3b899f3afdae@DM2PR03MB479.namprd03.prod.outlook.com>
On Wed, Jan 22, 2014 at 01:14:13PM +0000, Varun Sethi wrote:
> > On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > > > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > > > + unsigned long action, void *data) {
> > > > + struct device *dev = data;
> > > > + struct dma_iommu_mapping *mapping;
> > > > + struct arm_smmu_device *smmu;
> > > > + int ret;
> > > > +
> > > > + switch (action) {
> > > > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > > > +
> > > > + smmu = dev->archdata.iommu;
> > > > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > > > + break;
> > > [Sethi Varun-B16395] Should this check be really done here? The
> > > "Isolate devices" property would allow us to set up iommu groups. My
> > > understanding is that if we specify the isolate devices property, then
> > > each device would have a separate iommu group otherwise all devices
> > > connected to the SMMU would share the iommu group.
> >
> > That's not what currently happens (at least, in the patch I have queued
> > for groups). The code queued adds each device to its own group in
> > arm_smmu_add_device, which I think is the right thing to do.
> >
> > > With that logic, we should link the mapping to the iommu group.
> >
> > Ok, so are you suggesting that we perform the isolation mapping in
> > arm_smmu_add_device and drop the notifier altogether?
> I think that should be fine, until we want to delay mapping creation till
> driver bind time.
Is there a hard dependency on that?
> But the "isolate device" property should dictate iommu group creation.
The reason we added automatic group creation (per-device) is for VFIO, which
expects all devices to be in a group regardless of the device isolation
configuration.
Will
^ permalink raw reply
* [PATCH 5/5] ARM: integrator: select AMBA bus and GPIO block
From: Russell King - ARM Linux @ 2014-01-22 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-6-git-send-email-linus.walleij@linaro.org>
On Wed, Jan 22, 2014 at 02:31:11PM +0100, Linus Walleij wrote:
> The Integrator/AP can be used with a logical module called
logic module
> IM-PD1, which contains a few AMBA PrimeCell devices, one of which
> is the PL061 GPIO controller. As the lines from this GPIO
> controller are looped back to devices on the board itself and
> provides resources back to it, we need to always have GPIO
> and the PL061 driver available for other devices to work.
> config INTEGRATOR_IMPD1
> tristate "Include support for Integrator/IM-PD1"
> depends on ARCH_INTEGRATOR_AP
> + select ARCH_REQUIRE_GPIOLIB
> + select ARM_AMBA
Doesn't ARCH_INTEGRATOR already select ARM_AMBA, which this option already
depends on?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 5/5] ARM: integrator: select AMBA bus and GPIO block
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
The Integrator/AP can be used with a logical module called
IM-PD1, which contains a few AMBA PrimeCell devices, one of which
is the PL061 GPIO controller. As the lines from this GPIO
controller are looped back to devices on the board itself and
provides resources back to it, we need to always have GPIO
and the PL061 driver available for other devices to work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 46be99007529..b61e962ef992 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -30,7 +30,10 @@ config ARCH_CINTEGRATOR
config INTEGRATOR_IMPD1
tristate "Include support for Integrator/IM-PD1"
depends on ARCH_INTEGRATOR_AP
+ select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
select ARM_VIC
+ select GPIO_PL061 if GPIOLIB
help
The IM-PD1 is an add-on logic module for the Integrator which
allows ARM(R) Ltd PrimeCells to be developed and evaluated.
--
1.8.4.2
^ permalink raw reply related
* [PATCH 4/5] ARM: integrator: register the IM-PD1 VIC
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
The peripherals on the IM-PD1 has never really been able to
properly fire their IRQs to the main FPGA IRQ controller.
Cascade it properly and register interrupts for all the
devices in the array.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 1 +
arch/arm/mach-integrator/impd1.c | 45 ++++++++++++++++++++++++++++++++--------
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index abeff25532ab..46be99007529 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -30,6 +30,7 @@ config ARCH_CINTEGRATOR
config INTEGRATOR_IMPD1
tristate "Include support for Integrator/IM-PD1"
depends on ARCH_INTEGRATOR_AP
+ select ARM_VIC
help
The IM-PD1 is an add-on logic module for the Integrator which
allows ARM(R) Ltd PrimeCells to be developed and evaluated.
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index aeeae0d79a18..d9b784824808 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -23,6 +23,7 @@
#include <linux/io.h>
#include <linux/platform_data/clk-integrator.h>
#include <linux/slab.h>
+#include <linux/irqchip/arm-vic.h>
#include <mach/lm.h>
#include <mach/impd1.h>
@@ -35,6 +36,7 @@ MODULE_PARM_DESC(lmid, "logic module stack position");
struct impd1_module {
void __iomem *base;
+ void __iomem *vic_base;
};
void impd1_tweak_control(struct device *dev, u32 mask, u32 val)
@@ -262,9 +264,6 @@ struct impd1_device {
static struct impd1_device impd1_devs[] = {
{
- .offset = 0x03000000,
- .id = 0x00041190,
- }, {
.offset = 0x00100000,
.irq = { 1 },
.id = 0x00141011,
@@ -304,9 +303,15 @@ static struct impd1_device impd1_devs[] = {
}
};
-static int impd1_probe(struct lm_device *dev)
+/*
+ * Valid IRQs: 0 thru 9 and 11, 10 unused.
+ */
+#define IMPD1_VALID_IRQS 0x00000bffU
+
+static int __init impd1_probe(struct lm_device *dev)
{
struct impd1_module *impd1;
+ int irq_base;
int i;
if (dev->id != module_id)
@@ -325,23 +330,45 @@ static int impd1_probe(struct lm_device *dev)
if (!impd1->base)
return -ENOMEM;
- lm_set_drvdata(dev, impd1);
+ integrator_impd1_clk_init(impd1->base, dev->id);
+
+ if (!devm_request_mem_region(&dev->dev,
+ dev->resource.start + 0x03000000,
+ SZ_4K, "VIC"))
+ return -EBUSY;
- printk("IM-PD1 found at 0x%08lx\n",
- (unsigned long)dev->resource.start);
+ impd1->vic_base = devm_ioremap(&dev->dev,
+ dev->resource.start + 0x03000000,
+ SZ_4K);
+ if (!impd1->vic_base)
+ return -ENOMEM;
- integrator_impd1_clk_init(impd1->base, dev->id);
+ irq_base = vic_init_cascaded(impd1->vic_base, dev->irq,
+ IMPD1_VALID_IRQS, 0);
+
+ lm_set_drvdata(dev, impd1);
+
+ dev_info(&dev->dev, "IM-PD1 found at 0x%08lx\n",
+ (unsigned long)dev->resource.start);
for (i = 0; i < ARRAY_SIZE(impd1_devs); i++) {
struct impd1_device *idev = impd1_devs + i;
struct amba_device *d;
unsigned long pc_base;
char devname[32];
+ int irq1 = idev->irq[0];
+ int irq2 = idev->irq[1];
+
+ /* Translate IRQs to IM-PD1 local numberspace */
+ if (irq1)
+ irq1 += irq_base;
+ if (irq2)
+ irq2 += irq_base;
pc_base = dev->resource.start + idev->offset;
snprintf(devname, 32, "lm%x:%5.5lx", dev->id, idev->offset >> 12);
d = amba_ahb_device_add_res(&dev->dev, devname, pc_base, SZ_4K,
- dev->irq, dev->irq,
+ irq1, irq2,
idev->platform_data, idev->id,
&dev->resource);
if (IS_ERR(d)) {
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/5] ARM: integrator: use managed resources for the IM-PD1
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
Switch the IM-PD1 driver to use managed resources and cut down
on boilerplate.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/impd1.c | 36 ++++++++++--------------------------
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index 9f82f9dcbb98..aeeae0d79a18 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -307,25 +307,23 @@ static struct impd1_device impd1_devs[] = {
static int impd1_probe(struct lm_device *dev)
{
struct impd1_module *impd1;
- int i, ret;
+ int i;
if (dev->id != module_id)
return -EINVAL;
- if (!request_mem_region(dev->resource.start, SZ_4K, "LM registers"))
+ if (!devm_request_mem_region(&dev->dev, dev->resource.start,
+ SZ_4K, "LM registers"))
return -EBUSY;
- impd1 = kzalloc(sizeof(struct impd1_module), GFP_KERNEL);
- if (!impd1) {
- ret = -ENOMEM;
- goto release_lm;
- }
+ impd1 = devm_kzalloc(&dev->dev, sizeof(struct impd1_module),
+ GFP_KERNEL);
+ if (!impd1)
+ return -ENOMEM;
- impd1->base = ioremap(dev->resource.start, SZ_4K);
- if (!impd1->base) {
- ret = -ENOMEM;
- goto free_impd1;
- }
+ impd1->base = devm_ioremap(&dev->dev, dev->resource.start, SZ_4K);
+ if (!impd1->base)
+ return -ENOMEM;
lm_set_drvdata(dev, impd1);
@@ -353,14 +351,6 @@ static int impd1_probe(struct lm_device *dev)
}
return 0;
-
- free_impd1:
- if (impd1 && impd1->base)
- iounmap(impd1->base);
- kfree(impd1);
- release_lm:
- release_mem_region(dev->resource.start, SZ_4K);
- return ret;
}
static int impd1_remove_one(struct device *dev, void *data)
@@ -371,16 +361,10 @@ static int impd1_remove_one(struct device *dev, void *data)
static void impd1_remove(struct lm_device *dev)
{
- struct impd1_module *impd1 = lm_get_drvdata(dev);
-
device_for_each_child(&dev->dev, NULL, impd1_remove_one);
integrator_impd1_clk_exit(dev->id);
lm_set_drvdata(dev, NULL);
-
- iounmap(impd1->base);
- kfree(impd1);
- release_mem_region(dev->resource.start, SZ_4K);
}
static struct lm_driver impd1_driver = {
--
1.8.4.2
^ permalink raw reply related
* [PATCH 2/5] irqchip: support cascaded VICs
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
This adds support for a VIC to be cascaded off another IRQ.
On the Integrator/AP logical module IM-PD1 there is a VIC
cascaded off the central FPGA IRQ controller so this is
needed for that to work out.
In order for the plug-in board to be able to register all
the devices with their IRQs relative to the offset of the
base obtained for the cascaded VIC, the base IRQ number
is passed back to the caller.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
tglx: if you're happy with this pls ACK it so I can take this
through the ARM SoC tree.
---
arch/arm/mach-versatile/core.c | 2 +-
drivers/irqchip/irq-vic.c | 53 ++++++++++++++++++++++++++++++++++++-----
include/linux/irqchip/arm-vic.h | 6 +++--
3 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 3b0572f30d56..36b97212d554 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -108,7 +108,7 @@ void __init versatile_init_irq(void)
np = of_find_matching_node_by_address(NULL, vic_of_match,
VERSATILE_VIC_BASE);
- __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np);
+ __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 70108c1491bc..6002942a231c 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -57,6 +57,7 @@
/**
* struct vic_device - VIC PM device
+ * @parent_irq: The parent IRQ number of the VIC if cascaded, or 0.
* @irq: The IRQ number for the base of the VIC.
* @base: The register base for the VIC.
* @valid_sources: A bitmask of valid interrupts
@@ -224,6 +225,17 @@ static int handle_one_vic(struct vic_device *vic, struct pt_regs *regs)
return handled;
}
+static void vic_handle_irq_cascaded(unsigned int irq, struct irq_desc *desc)
+{
+ u32 stat, hwirq;
+ struct vic_device *vic = irq_desc_get_handler_data(desc);
+
+ while ((stat = readl_relaxed(vic->base + VIC_IRQ_STATUS))) {
+ hwirq = ffs(stat) - 1;
+ generic_handle_irq(irq_find_mapping(vic->domain, hwirq));
+ }
+}
+
/*
* Keep iterating over all registered VIC's until there are no pending
* interrupts.
@@ -246,6 +258,7 @@ static struct irq_domain_ops vic_irqdomain_ops = {
/**
* vic_register() - Register a VIC.
* @base: The base address of the VIC.
+ * @parent_irq: The parent IRQ if cascaded, else 0.
* @irq: The base IRQ for the VIC.
* @valid_sources: bitmask of valid interrupts
* @resume_sources: bitmask of interrupts allowed for resume sources.
@@ -257,7 +270,8 @@ static struct irq_domain_ops vic_irqdomain_ops = {
*
* This also configures the IRQ domain for the VIC.
*/
-static void __init vic_register(void __iomem *base, unsigned int irq,
+static void __init vic_register(void __iomem *base, unsigned int parent_irq,
+ unsigned int irq,
u32 valid_sources, u32 resume_sources,
struct device_node *node)
{
@@ -275,6 +289,12 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
v->resume_sources = resume_sources;
set_handle_irq(vic_handle_irq);
vic_id++;
+
+ if (parent_irq) {
+ irq_set_handler_data(parent_irq, v);
+ irq_set_chained_handler(parent_irq, vic_handle_irq_cascaded);
+ }
+
v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
&vic_irqdomain_ops, v);
/* create an IRQ mapping for each valid IRQ */
@@ -413,10 +433,10 @@ static void __init vic_init_st(void __iomem *base, unsigned int irq_start,
writel(32, base + VIC_PL190_DEF_VECT_ADDR);
}
- vic_register(base, irq_start, vic_sources, 0, node);
+ vic_register(base, 0, irq_start, vic_sources, 0, node);
}
-void __init __vic_init(void __iomem *base, int irq_start,
+void __init __vic_init(void __iomem *base, int parent_irq, int irq_start,
u32 vic_sources, u32 resume_sources,
struct device_node *node)
{
@@ -453,7 +473,7 @@ void __init __vic_init(void __iomem *base, int irq_start,
vic_init2(base);
- vic_register(base, irq_start, vic_sources, resume_sources, node);
+ vic_register(base, parent_irq, irq_start, vic_sources, resume_sources, node);
}
/**
@@ -466,7 +486,28 @@ void __init __vic_init(void __iomem *base, int irq_start,
void __init vic_init(void __iomem *base, unsigned int irq_start,
u32 vic_sources, u32 resume_sources)
{
- __vic_init(base, irq_start, vic_sources, resume_sources, NULL);
+ __vic_init(base, 0, irq_start, vic_sources, resume_sources, NULL);
+}
+
+/**
+ * vic_init_cascaded() - initialise a cascaded vectored interrupt controller
+ * @base: iomem base address
+ * @parent_irq: the parent IRQ we're cascaded off
+ * @irq_start: starting interrupt number, must be muliple of 32
+ * @vic_sources: bitmask of interrupt sources to allow
+ * @resume_sources: bitmask of interrupt sources to allow for resume
+ *
+ * This returns the base for the new interrupts or negative on error.
+ */
+int __init vic_init_cascaded(void __iomem *base, unsigned int parent_irq,
+ u32 vic_sources, u32 resume_sources)
+{
+ struct vic_device *v;
+
+ v = &vic_devices[vic_id];
+ __vic_init(base, parent_irq, 0, vic_sources, resume_sources, NULL);
+ /* Return out acquired base */
+ return v->irq;
}
#ifdef CONFIG_OF
@@ -489,7 +530,7 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
/*
* Passing 0 as first IRQ makes the simple domain allocate descriptors
*/
- __vic_init(regs, 0, interrupt_mask, wakeup_mask, node);
+ __vic_init(regs, 0, 0, interrupt_mask, wakeup_mask, node);
return 0;
}
diff --git a/include/linux/irqchip/arm-vic.h b/include/linux/irqchip/arm-vic.h
index e3c82dc95756..ba46c794b4e5 100644
--- a/include/linux/irqchip/arm-vic.h
+++ b/include/linux/irqchip/arm-vic.h
@@ -29,8 +29,10 @@
struct device_node;
struct pt_regs;
-void __vic_init(void __iomem *base, int irq_start, u32 vic_sources,
- u32 resume_sources, struct device_node *node);
+void __vic_init(void __iomem *base, int parent_irq, int irq_start,
+ u32 vic_sources, u32 resume_sources, struct device_node *node);
void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);
+int vic_init_cascaded(void __iomem *base, unsigned int parent_irq,
+ u32 vic_sources, u32 resume_sources);
#endif
--
1.8.4.2
^ permalink raw reply related
* [PATCH 1/5] irqchip: vic: update the base IRQ member correctly
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
When passing 0 as the irq base the VIC driver will dynamically
allocate a number of consecutive interrupt descriptors at some
available number range. Make sure this number is recorded in
the state container rather than the passed-in zero argument
in this case.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
tglx: if you're happy with this pls ACK it so I can take this
through the ARM SoC tree.
---
drivers/irqchip/irq-vic.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 8e21ae0bab46..70108c1491bc 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -273,7 +273,6 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
v->base = base;
v->valid_sources = valid_sources;
v->resume_sources = resume_sources;
- v->irq = irq;
set_handle_irq(vic_handle_irq);
vic_id++;
v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
@@ -282,6 +281,11 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
for (i = 0; i < fls(valid_sources); i++)
if (valid_sources & (1 << i))
irq_create_mapping(v->domain, i);
+ /* If no base IRQ was passed, figure out our allocated base */
+ if (irq)
+ v->irq = irq;
+ else
+ v->irq = irq_find_mapping(v->domain, 0);
}
static void vic_ack_irq(struct irq_data *d)
--
1.8.4.2
^ permalink raw reply related
* [PATCH 0/5] ARM: integrator: cascaded IRQs on IM-PD1
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
This series alters the VIC driver to allow for cascaded VICs off other
IRQ parents, such as the VIC found on the IM-PD1 daughterboard on the
Integrator/AP.
After this series I can start a fully working console on the UARTs on
the IM-PD1 that report their IRQs in /proc/interrupts like this:
root at integrator:/ cat /proc/interrupts
CPU0
17: 111 pic 1 uart-pl010
18: 7 pic 2 uart-pl010
22: 5377 pic 6 timer
24: 0 pic 8 rtc-pl030
33: 0 pic 17 PCIv3 error
39: 102 VIC 1 uart-pl011
40: 7 VIC 2 uart-pl011
Err: 0
(Dumped on the IM-PD1 UART.)
Linus Walleij (5):
irqchip: vic: update the base IRQ member correctly
irqchip: support cascaded VICs
ARM: integrator: use managed resources for the IM-PD1
ARM: integrator: register the IM-PD1 VIC
ARM: integrator: select AMBA bus and GPIO block
arch/arm/mach-integrator/Kconfig | 4 ++
arch/arm/mach-integrator/impd1.c | 81 +++++++++++++++++++++++-----------------
arch/arm/mach-versatile/core.c | 2 +-
drivers/irqchip/irq-vic.c | 59 +++++++++++++++++++++++++----
include/linux/irqchip/arm-vic.h | 6 ++-
5 files changed, 107 insertions(+), 45 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Russell King - ARM Linux @ 2014-01-22 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-3-git-send-email-wangnan0@huawei.com>
On Wed, Jan 22, 2014 at 07:25:15PM +0800, Wang Nan wrote:
> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
> cache problem: flush_icache_range can't reliably ensure the copied data
> correctly goes into RAM.
Quite right too. You're mistake here is thinking that flush_icache_range()
should push it to RAM. That's incorrect.
flush_icache_range() is there to deal with such things as loadable modules
and self modifying code, where the MMU is not being turned off. Hence, it
only flushes to the point of coherency between the I and D caches, and
any further levels of cache between that point and memory are not touched.
Why should it touch any more levels - it's not the function's purpose.
> After mmu turned off and jump to the trampoline, kexec always failed due
> to random undef instructions.
We already have code in the kernel which deals with shutting the MMU off.
An instance of how this can be done is illustrated in the soft_restart()
code path, and kexec already uses this.
One of the first things soft_restart() does is turn off the outer cache -
which OMAP4 does have, but this can only be done if there is a single CPU
running. If there's multiple CPUs running, then the outer cache can't be
disabled, and that's the most likely cause of the problem you're seeing.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Varun Sethi @ 2014-01-22 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122122550.GA14108@mudshark.cambridge.arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Wednesday, January 22, 2014 5:56 PM
> To: Sethi Varun-B16395
> Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; Andreas Herrmann
> Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> notifier block
>
> Hi Varun, Andreas,
>
> On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > > + unsigned long action, void *data) {
> > > + struct device *dev = data;
> > > + struct dma_iommu_mapping *mapping;
> > > + struct arm_smmu_device *smmu;
> > > + int ret;
> > > +
> > > + switch (action) {
> > > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > > +
> > > + smmu = dev->archdata.iommu;
> > > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > > + break;
> > [Sethi Varun-B16395] Should this check be really done here? The
> > "Isolate devices" property would allow us to set up iommu groups. My
> > understanding is that if we specify the isolate devices property, then
> > each device would have a separate iommu group otherwise all devices
> > connected to the SMMU would share the iommu group.
>
> That's not what currently happens (at least, in the patch I have queued
> for groups). The code queued adds each device to its own group in
> arm_smmu_add_device, which I think is the right thing to do.
>
> > With that logic, we should link the mapping to the iommu group.
>
> Ok, so are you suggesting that we perform the isolation mapping in
> arm_smmu_add_device and drop the notifier altogether?
I think that should be fine, until we want to delay mapping creation till driver bind time. But the "isolate device" property should dictate iommu group creation.
-Varun
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-22 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANacCWz2DdLvns9htszpwWnASrYGXQt+tHMsw4aBbjoyw-DmeQ@mail.gmail.com>
On 2014/1/22 20:56, Vaibhav Bedia wrote:
> On Wed, Jan 22, 2014 at 6:25 AM, Wang Nan <wangnan0 at huawei.com <mailto:wangnan0@huawei.com>> wrote:
>
> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
> cache problem: flush_icache_range can't reliably ensure the copied data
> correctly goes into RAM. After mmu turned off and jump to the trampoline, kexec
> always failed due to random undef instructions.
>
> This patch use ioremap to make sure the destnation of all memcpy() is
> uncachable memory, including copying of target kernel and trampoline.
>
>
> AFAIK ioremap on RAM in forbidden in ARM and device memory that ioremap()
> ends up creating is not meant for executable code.
>
> Doesn't this trigger the WARN_ON() in _arm_ioremap_pfn_caller)?
This patch is depend on the previous one:
ARM: Premit ioremap() to map reserved pages
However, Russell is opposed to it.
^ permalink raw reply
* [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
From: Sricharan R @ 2014-01-22 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1VyjuU-0005EQ-H5@rmk-PC.arm.linux.org.uk>
Hi Russell,
On Thursday 02 January 2014 08:40 PM, Russell King wrote:
> Consolidate the setup of the channel control register. Prepare the
> basic value in the preparation of the DMA descriptor, and write it into
> the register upon descriptor execution.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/dma/omap-dma.c | 133 ++++++++++++++++-------------------------------
> 1 files changed, 45 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 98928f7209f6..796f882da03c 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -58,8 +58,7 @@ struct omap_desc {
>
> int16_t fi; /* for OMAP_DMA_SYNC_PACKET */
> uint8_t es; /* OMAP_DMA_DATA_TYPE_xxx */
> - uint8_t sync_mode; /* OMAP_DMA_SYNC_xxx */
> - uint8_t sync_type; /* OMAP_DMA_xxx_SYNC* */
> + uint32_t ccr; /* CCR value */
> uint16_t cicr; /* CICR value */
> uint32_t csdp; /* CSDP value */
>
> @@ -228,7 +227,6 @@ static void omap_dma_start_desc(struct omap_chan *c)
> {
> struct virt_dma_desc *vd = vchan_next_desc(&c->vc);
> struct omap_desc *d;
> - uint32_t val;
>
> if (!vd) {
> c->desc = NULL;
> @@ -240,23 +238,15 @@ static void omap_dma_start_desc(struct omap_chan *c)
> c->desc = d = to_omap_dma_desc(&vd->tx);
> c->sgidx = 0;
>
> - if (d->dir == DMA_DEV_TO_MEM) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(0x03 << 14 | 0x03 << 12);
> - val |= OMAP_DMA_AMODE_POST_INC << 14;
> - val |= OMAP_DMA_AMODE_CONSTANT << 12;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> + c->plat->dma_write(d->ccr, CCR, c->dma_ch);
> + if (dma_omap1())
> + c->plat->dma_write(d->ccr >> 16, CCR2, c->dma_ch);
>
> + if (d->dir == DMA_DEV_TO_MEM) {
> c->plat->dma_write(d->dev_addr, CSSA, c->dma_ch);
> c->plat->dma_write(0, CSEI, c->dma_ch);
> c->plat->dma_write(d->fi, CSFI, c->dma_ch);
> } else {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(0x03 << 12 | 0x03 << 14);
> - val |= OMAP_DMA_AMODE_CONSTANT << 14;
> - val |= OMAP_DMA_AMODE_POST_INC << 12;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> -
> c->plat->dma_write(d->dev_addr, CDSA, c->dma_ch);
> c->plat->dma_write(0, CDEI, c->dma_ch);
> c->plat->dma_write(d->fi, CDFI, c->dma_ch);
> @@ -264,47 +254,6 @@ static void omap_dma_start_desc(struct omap_chan *c)
>
> c->plat->dma_write(d->csdp, CSDP, c->dma_ch);
>
> - if (dma_omap1()) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(1 << 5);
> - if (d->sync_mode == OMAP_DMA_SYNC_FRAME)
> - val |= 1 << 5;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> -
> - val = c->plat->dma_read(CCR2, c->dma_ch);
> - val &= ~(1 << 2);
> - if (d->sync_mode == OMAP_DMA_SYNC_BLOCK)
> - val |= 1 << 2;
> - c->plat->dma_write(val, CCR2, c->dma_ch);
> - }
> -
> - if (dma_omap2plus() && c->dma_sig) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> -
> - /* DMA_SYNCHRO_CONTROL_UPPER depends on the channel number */
> - val &= ~(1 << 24 | 1 << 23 | 3 << 19 | 1 << 18 | 1 << 5 | 0x1f);
> - val |= (c->dma_sig & ~0x1f) << 14;
> - val |= c->dma_sig & 0x1f;
> -
> - if (d->sync_mode & OMAP_DMA_SYNC_FRAME)
> - val |= 1 << 5;
> -
> - if (d->sync_mode & OMAP_DMA_SYNC_BLOCK)
> - val |= 1 << 18;
> -
> - switch (d->sync_type) {
> - case OMAP_DMA_DST_SYNC_PREFETCH:/* dest synch */
> - val |= 1 << 23; /* Prefetch */
> - break;
> - case 0:
> - break;
> - default:
> - val |= 1 << 24; /* source synch */
> - break;
> - }
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> -
> omap_dma_start_sg(c, d, 0);
> }
>
> @@ -543,19 +492,17 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> struct scatterlist *sgent;
> struct omap_desc *d;
> dma_addr_t dev_addr;
> - unsigned i, j = 0, es, en, frame_bytes, sync_type;
> + unsigned i, j = 0, es, en, frame_bytes;
> u32 burst;
>
> if (dir == DMA_DEV_TO_MEM) {
> dev_addr = c->cfg.src_addr;
> dev_width = c->cfg.src_addr_width;
> burst = c->cfg.src_maxburst;
> - sync_type = OMAP_DMA_SRC_SYNC;
> } else if (dir == DMA_MEM_TO_DEV) {
> dev_addr = c->cfg.dst_addr;
> dev_width = c->cfg.dst_addr_width;
> burst = c->cfg.dst_maxburst;
> - sync_type = OMAP_DMA_DST_SYNC;
> } else {
> dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> return NULL;
> @@ -584,12 +531,20 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> d->dir = dir;
> d->dev_addr = dev_addr;
> d->es = es;
> - d->sync_mode = OMAP_DMA_SYNC_FRAME;
> - d->sync_type = sync_type;
> +
> + d->ccr = 0;
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= OMAP_DMA_AMODE_POST_INC << 14 |
> + OMAP_DMA_AMODE_CONSTANT << 12;
> + else
> + d->ccr |= OMAP_DMA_AMODE_CONSTANT << 14 |
> + OMAP_DMA_AMODE_POST_INC << 12;
> +
> d->cicr = OMAP_DMA_DROP_IRQ | OMAP_DMA_BLOCK_IRQ;
> d->csdp = es;
>
> if (dma_omap1()) {
> + d->ccr |= 1 << 5; /* frame sync */
> d->cicr |= OMAP1_DMA_TOUT_IRQ;
>
> if (dir == DMA_DEV_TO_MEM)
> @@ -599,6 +554,13 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> d->csdp |= OMAP_DMA_PORT_TIPB << 9 |
> OMAP_DMA_PORT_EMIFF << 2;
> } else if (dma_omap2plus()) {
> + d->ccr |= (c->dma_sig & ~0x1f) << 14;
> + d->ccr |= c->dma_sig & 0x1f;
> + d->ccr |= 1 << 5; /* frame sync */
> +
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= 1 << 24; /* source synch */
> +
> d->cicr |= OMAP2_DMA_MISALIGNED_ERR_IRQ | OMAP2_DMA_TRANS_ERR_IRQ;
> }
>
> @@ -635,19 +597,17 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> enum dma_slave_buswidth dev_width;
> struct omap_desc *d;
> dma_addr_t dev_addr;
> - unsigned es, sync_type;
> + unsigned es;
> u32 burst;
>
> if (dir == DMA_DEV_TO_MEM) {
> dev_addr = c->cfg.src_addr;
> dev_width = c->cfg.src_addr_width;
> burst = c->cfg.src_maxburst;
> - sync_type = OMAP_DMA_SRC_SYNC;
> } else if (dir == DMA_MEM_TO_DEV) {
> dev_addr = c->cfg.dst_addr;
> dev_width = c->cfg.dst_addr_width;
> burst = c->cfg.dst_maxburst;
> - sync_type = OMAP_DMA_DST_SYNC;
> } else {
> dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> return NULL;
> @@ -677,15 +637,21 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> d->dev_addr = dev_addr;
> d->fi = burst;
> d->es = es;
> - if (burst)
> - d->sync_mode = OMAP_DMA_SYNC_PACKET;
> - else
> - d->sync_mode = OMAP_DMA_SYNC_ELEMENT;
> - d->sync_type = sync_type;
> d->sg[0].addr = buf_addr;
> d->sg[0].en = period_len / es_bytes[es];
> d->sg[0].fn = buf_len / period_len;
> d->sglen = 1;
> +
> + d->ccr = 0;
> + if (__dma_omap15xx(od->plat->dma_attr))
> + d->ccr = 3 << 8;
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= OMAP_DMA_AMODE_POST_INC << 14 |
> + OMAP_DMA_AMODE_CONSTANT << 12;
> + else
> + d->ccr |= OMAP_DMA_AMODE_CONSTANT << 14 |
> + OMAP_DMA_AMODE_POST_INC << 12;
> +
> d->cicr = OMAP_DMA_DROP_IRQ;
> if (flags & DMA_PREP_INTERRUPT)
> d->cicr |= OMAP_DMA_FRAME_IRQ;
> @@ -702,23 +668,22 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> d->csdp |= OMAP_DMA_PORT_MPUI << 9 |
> OMAP_DMA_PORT_EMIFF << 2;
> } else if (dma_omap2plus()) {
> + d->ccr |= (c->dma_sig & ~0x1f) << 14;
> + d->ccr |= c->dma_sig & 0x1f;
> +
> + if (burst)
> + d->ccr |= 1 << 18 | 1 << 5; /* packet */
> +
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= 1 << 24; /* source synch */
> +
> d->cicr |= OMAP2_DMA_MISALIGNED_ERR_IRQ | OMAP2_DMA_TRANS_ERR_IRQ;
>
> /* src and dst burst mode 16 */
> d->csdp |= 3 << 14 | 3 << 7;
> }
>
> - if (!c->cyclic) {
> - c->cyclic = true;
> -
> - if (__dma_omap15xx(od->plat->dma_attr)) {
> - uint32_t val;
> -
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val |= 3 << 8;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> - }
> + c->cyclic = true;
>
> return vchan_tx_prep(&c->vc, &d->vd, flags);
> }
> @@ -762,14 +727,6 @@ static int omap_dma_terminate_all(struct omap_chan *c)
> if (c->cyclic) {
> c->cyclic = false;
> c->paused = false;
> -
> - if (__dma_omap15xx(od->plat->dma_attr)) {
> - uint32_t val;
> -
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(3 << 8);
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> }
>
> vchan_get_all_descriptors(&c->vc, &head);
Setting up of DMA_DST_SYNC_PREFETCH is missing after this ?
Regards,
Sricharan
^ permalink raw reply
* [PATCH RFC 03/26] dmaengine: omap-dma: program hardware directly
From: Sricharan R @ 2014-01-22 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1Vyjtf-0005E5-Vw@rmk-PC.arm.linux.org.uk>
On Thursday 02 January 2014 08:39 PM, Russell King wrote:
> Program the transfer parameters directly into the hardware, rather
> than using the functions in arch/arm/plat-omap/dma.c.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/dma/omap-dma.c | 144 ++++++++++++++++++++++++++++++++++++++++-----
> include/linux/omap-dma.h | 6 +-
> 2 files changed, 132 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 3c1bb34aad0a..dd233ca2cf5a 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -99,16 +99,96 @@ static void omap_dma_start_sg(struct omap_chan *c, struct omap_desc *d,
> unsigned idx)
> {
> struct omap_sg *sg = d->sg + idx;
> + uint32_t val;
> +
> + if (d->dir == DMA_DEV_TO_MEM) {
> + if (dma_omap1()) {
> + val = c->plat->dma_read(CSDP, c->dma_ch);
> + val &= ~(0x1f << 9);
> + val |= OMAP_DMA_PORT_EMIFF << 9;
> + c->plat->dma_write(val, CSDP, c->dma_ch);
> + }
>
> - if (d->dir == DMA_DEV_TO_MEM)
> - omap_set_dma_dest_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
> - OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
> - else
> - omap_set_dma_src_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
> - OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
> + val = c->plat->dma_read(CCR, c->dma_ch);
> + val &= ~(0x03 << 14);
> + val |= OMAP_DMA_AMODE_POST_INC << 14;
> + c->plat->dma_write(val, CCR, c->dma_ch);
> +
> + c->plat->dma_write(sg->addr, CDSA, c->dma_ch);
> + c->plat->dma_write(0, CDEI, c->dma_ch);
> + c->plat->dma_write(0, CDFI, c->dma_ch);
> + } else {
> + if (dma_omap1()) {
> + val = c->plat->dma_read(CSDP, c->dma_ch);
> + val &= ~(0x1f << 2);
> + val |= OMAP_DMA_PORT_EMIFF << 2;
> + c->plat->dma_write(val, CSDP, c->dma_ch);
> + }
> +
> + val = c->plat->dma_read(CCR, c->dma_ch);
> + val &= ~(0x03 << 12);
> + val |= OMAP_DMA_AMODE_POST_INC << 12;
> + c->plat->dma_write(val, CCR, c->dma_ch);
> +
> + c->plat->dma_write(sg->addr, CSSA, c->dma_ch);
> + c->plat->dma_write(0, CSEI, c->dma_ch);
> + c->plat->dma_write(0, CSFI, c->dma_ch);
> + }
> +
EI and FI are always set to zero. So interleaved transfers support
have to enabled in omap-dma, as it was supported by the
legacy driver. It was not enabled because of no users of the feature,
right ?
Regards,
Sricharan
^ permalink raw reply
* [PATCH v4 00/36] mtd: st_spi_fsm: Add new driver
From: Lee Jones @ 2014-01-22 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140108143316.GA14575@lee--X1>
Hi Brian,
> Version 4:
> Tended to Brian's previous review comments
> - Checkpatch acceptance
> - MODULE_DEVICE_TABLE() name slip correction
> - Timeout issue(s) resolved
> - Potential infinite loop mitigated
> - Code clarity suggests heeded
> - Duplication with MTD core code removed
> - Upgraded to using ROUND_UP() helper
> - Moved non-shared header code into main driver
> - Relocated dynamic msg sequence stores into main struct
> - Averted adaption of static (table) data
> - Basic whitespace/spelling/data type/dev_err suggestions accepted
>
> Version 3:
> Okay, this thing should be fully functional now. Identify a chip
> based on it's JEDEC ID, Read, Write, Erase (all or by sector).
> Support for various chip quirks added too.
>
> Version 2:
> The first bunch of these patches have been on the MLs before, but
> didn't receive a great deal of attention for the most part. We are
> a little more featureful this time however. We can now successfully
> setup and configure the N25Q256. We still can't read/write/erase
> it though. I'll start work on that next week and will provide it in
> the next instalment.
>
> Version 1:
> First stab at getting this thing Mainlined. It doesn't do a great deal
> yet, but we are able to initialise the device and dynamically set it up
> correctly based on an extracted JEDEC ID.
>
> Documentation/devicetree/bindings/mtd/st-fsm.txt | 26 ++
> arch/arm/boot/dts/stih416-b2105.dts | 14 +
> arch/arm/boot/dts/stih416-pinctrl.dtsi | 12 +
> drivers/mtd/devices/Kconfig | 8 +
> drivers/mtd/devices/Makefile | 1 +
> drivers/mtd/devices/serial_flash_cmds.h | 81 ++++
> drivers/mtd/devices/st_spi_fsm.c | 2124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 7 files changed, 2266 insertions(+)
Can you confirm receipt of this set, or would you like me to resend?
Kind regards,
Lee
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] at91: pinctrl: use gpiolib API to mark a GPIO used as an IRQ
From: Gregory CLEMENT @ 2014-01-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-2-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
On 22/01/2014 13:39, Jean-Jacques Hiblot wrote:
> When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
> the gpiolib so we can keep track of the usage centrally.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> drivers/pinctrl/pinctrl-at91.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index e8c8301..fbedde2 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1299,6 +1299,28 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
> return 0;
> }
>
> +static unsigned int gpio_irq_startup(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> + int ret;
> +
> + ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
> + if (ret) {
> + dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
> + d->hwirq);
> + return ret;
> + }
> + return 0;
> +}
As for the 1st patch, a blank line between the 2 functions should be nice
Thanks,
Gregory
> +static void gpio_irq_shutdown(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> +
> + gpio_unlock_as_irq(&at91_gpio->chip, pin);
> +}
> +
> #ifdef CONFIG_PM
>
> static u32 wakeups[MAX_GPIO_BANKS];
> @@ -1377,6 +1399,8 @@ void at91_pinctrl_gpio_resume(void)
>
> static struct irq_chip gpio_irqchip = {
> .name = "GPIO",
> + .irq_startup = gpio_irq_startup,
> + .irq_shutdown = gpio_irq_shutdown,
> .irq_disable = gpio_irq_mask,
> .irq_mask = gpio_irq_mask,
> .irq_unmask = gpio_irq_unmask,
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] at91: gpio: use gpiolib API to mark a GPIO used as an IRQ
From: Gregory CLEMENT @ 2014-01-22 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-1-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
On 22/01/2014 13:39, Jean-Jacques Hiblot wrote:
> When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
> the gpiolib so we can keep track of the usage centrally.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/mach-at91/gpio.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
> index a5afcf7..6176b4b 100644
> --- a/arch/arm/mach-at91/gpio.c
> +++ b/arch/arm/mach-at91/gpio.c
> @@ -577,8 +577,32 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
> return 0;
> }
>
> +static unsigned int gpio_irq_startup(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> + int ret;
> +
> + ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
> + if (ret) {
> + dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
> + d->hwirq);
> + return ret;
> + }
> + return 0;
> +}
Nitpick: a blank line should be nice here between the 2 functions
> +static void gpio_irq_shutdown(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> +
> + gpio_unlock_as_irq(&at91_gpio->chip, pin);
> +}
> +
> static struct irq_chip gpio_irqchip = {
> .name = "GPIO",
> + .irq_shutdown = gpio_irq_shutdown,
> + .irq_startup = gpio_irq_startup,
> .irq_disable = gpio_irq_mask,
> .irq_mask = gpio_irq_mask,
> .irq_unmask = gpio_irq_unmask,
>
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] watchdog: Add sp805_wdt depends on ARM64
From: naresh.bhat at linaro.org @ 2014-01-22 12:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Naresh Bhat <naresh.bhat@linaro.org>
Add sp805_wdt depends on ARM64.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..2385124 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -109,7 +109,7 @@ config WM8350_WATCHDOG
config ARM_SP805_WATCHDOG
tristate "ARM SP805 Watchdog"
- depends on ARM && ARM_AMBA
+ depends on (ARM || ARM64) && ARM_AMBA
select WATCHDOG_CORE
help
ARM Primecell SP805 Watchdog timer. This will reboot your system when
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] at91: pinctrl: use gpiolib API to mark a GPIO used as an IRQ
From: Jean-Jacques Hiblot @ 2014-01-22 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-1-git-send-email-jjhiblot@traphandler.com>
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
the gpiolib so we can keep track of the usage centrally.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
drivers/pinctrl/pinctrl-at91.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index e8c8301..fbedde2 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1299,6 +1299,28 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
return 0;
}
+static unsigned int gpio_irq_startup(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+ int ret;
+
+ ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
+ if (ret) {
+ dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
+ d->hwirq);
+ return ret;
+ }
+ return 0;
+}
+static void gpio_irq_shutdown(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+
+ gpio_unlock_as_irq(&at91_gpio->chip, pin);
+}
+
#ifdef CONFIG_PM
static u32 wakeups[MAX_GPIO_BANKS];
@@ -1377,6 +1399,8 @@ void at91_pinctrl_gpio_resume(void)
static struct irq_chip gpio_irqchip = {
.name = "GPIO",
+ .irq_startup = gpio_irq_startup,
+ .irq_shutdown = gpio_irq_shutdown,
.irq_disable = gpio_irq_mask,
.irq_mask = gpio_irq_mask,
.irq_unmask = gpio_irq_unmask,
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/2] at91: gpio: use gpiolib API to mark a GPIO used as an IRQ
From: Jean-Jacques Hiblot @ 2014-01-22 12:39 UTC (permalink / raw)
To: linux-arm-kernel
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
the gpiolib so we can keep track of the usage centrally.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
arch/arm/mach-at91/gpio.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index a5afcf7..6176b4b 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -577,8 +577,32 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
return 0;
}
+static unsigned int gpio_irq_startup(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+ int ret;
+
+ ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
+ if (ret) {
+ dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
+ d->hwirq);
+ return ret;
+ }
+ return 0;
+}
+static void gpio_irq_shutdown(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+
+ gpio_unlock_as_irq(&at91_gpio->chip, pin);
+}
+
static struct irq_chip gpio_irqchip = {
.name = "GPIO",
+ .irq_shutdown = gpio_irq_shutdown,
+ .irq_startup = gpio_irq_startup,
.irq_disable = gpio_irq_mask,
.irq_mask = gpio_irq_mask,
.irq_unmask = gpio_irq_unmask,
--
1.8.5.2
^ permalink raw reply related
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Mark Brown @ 2014-01-22 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401211950.07011.arnd@arndb.de>
On Tue, Jan 21, 2014 at 07:50:06PM +0100, Arnd Bergmann wrote:
> I should have another look at the debugfs representation, but isn't
> there a global namespace that gets used for all gpios? Neither the
> con_id nor the name that the driver picks would be globally unique
> and stable across kernel versions, so they don't make a good user
> interface.
Currently the globally unique name is the GPIO number but that's not
stable since it gets dynamically assigned.
> I think what we want here is a system-wide unique identifier for
> each gpio line that may get represented in debugfs, and use a new
> DT mechanism to communicate that.
We've mostly been using things based off dev_name() for stability.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/dfe74bd2/attachment.sig>
^ permalink raw reply
* Kconfig errors
From: Russell King - ARM Linux @ 2014-01-22 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8uy6wM8nS993VeezJGOaoqM5GRsJE7FrKe7=bhD6nZhXw@mail.gmail.com>
On Wed, Jan 22, 2014 at 05:54:29PM +0530, Prabhakar Lad wrote:
> Hi Russell,
>
> On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad
> <prabhakar.csengg@gmail.com> wrote:
> > Hi,
> >
> > On Linux-next branch I see following errors for davinci_all_defconfig
> > & da8xx_omapl_defconfig configs,
> >
> > arch/arm/Kconfig:1966:error: recursive dependency detected!
> > arch/arm/Kconfig:1966: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
> > arch/arm/Kconfig:2154: symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
> > #
> > # configuration written to .config
> > #
> >
> I am seeing this errors on linux-next, with your recent patch,
> "[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM"
> and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM
> but still an error.
>
> Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and
> CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0
I've killed off the "select AUTO_ZRELADDR if !ZBOOT_ROM" in the IMX
Kconfig now, so when linux-next picks up my tree, that should be gone.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Will Deacon @ 2014-01-22 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e92c5fd617fb4068b4ec5de696527ee3@BL2PR03MB468.namprd03.prod.outlook.com>
Hi Varun, Andreas,
On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > + unsigned long action, void *data)
> > +{
> > + struct device *dev = data;
> > + struct dma_iommu_mapping *mapping;
> > + struct arm_smmu_device *smmu;
> > + int ret;
> > +
> > + switch (action) {
> > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > +
> > + smmu = dev->archdata.iommu;
> > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > + break;
> [Sethi Varun-B16395] Should this check be really done here? The "Isolate
> devices" property would allow us to set up iommu groups. My understanding
> is that if we specify the isolate devices property, then each device would
> have a separate iommu group otherwise all devices connected to the SMMU
> would share the iommu group.
That's not what currently happens (at least, in the patch I have queued for
groups). The code queued adds each device to its own group in
arm_smmu_add_device, which I think is the right thing to do.
> With that logic, we should link the mapping to the iommu group.
Ok, so are you suggesting that we perform the isolation mapping in
arm_smmu_add_device and drop the notifier altogether?
Will
^ permalink raw reply
* Kconfig errors
From: Prabhakar Lad @ 2014-01-22 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8vcvTRpP-cE6SKd1KgWgzSbOXvSNW+5Jh8wqOfr1za4SQ@mail.gmail.com>
Hi Russell,
On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad
<prabhakar.csengg@gmail.com> wrote:
> Hi,
>
> On Linux-next branch I see following errors for davinci_all_defconfig
> & da8xx_omapl_defconfig configs,
>
> arch/arm/Kconfig:1966:error: recursive dependency detected!
> arch/arm/Kconfig:1966: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
> arch/arm/Kconfig:2154: symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
> #
> # configuration written to .config
> #
>
I am seeing this errors on linux-next, with your recent patch,
"[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM"
and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM
but still an error.
Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and
CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0
Regards,
--Prabhakar Lad
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-22 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaAe7M3RjOiOrs9-bF5p80mshxbcNwKoDSMAXJ+5D27Ew@mail.gmail.com>
2014/1/22 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Jan 15, 2014 at 6:28 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 13/01/2014 11:35, boris brezillon :
>
>>> You should only request it as a GPIO and then use gpio_to_irq to get the
>>> related IRQ.
>>> Because what is done here, is to solve the case where only the irq
>>> is request, and in this specific case we need to request the pin as a
>>> GPIO.
>>
>> Yes, this is what we do.
>>
>> It seems simple and obvious to me, but some may say that "you shall not
>> do that, it is horrible!". Well... I always tend to choose a solution
>> that works. It is one of my weaknesses, I admit ;-)
>>
>> Linus W. any advice on this, before we hit again one of those infinite
>> threads that leads no progress at all?
>
> So we recently established that it is actually OK for any IRQ
> consumer to request an IRQ from any irq_chip no matter if
> that is a combined GPIO+IRQ driver. This was concluded after
> a long discussion involving several parties.
>
> gpio_to_irq() is just a convenience function and should not be
> relied upon to have been called before the IRQ is used.
>
> The basic premise is that gpio_chip and irq_chip are
> orthogonal, and offering their services independent of each
> other.
>
> Especially in the device tree use case it is very hard to
> dictate that a certain semantic need to be followed to use
> a certain interrupt-controller to have dependencies to a
> certain gpio-controller. So they need to be orthogonal.
>
> First step is: always prepare the hardware and make it
> ready for action in respective callbacks from the gpio_chip API
> and irq_chip API. Do not rely on gpio_to_irq() having been
> called first anymore.
>
> This leads to ambiguities that we need to solve: if there is
> competition inside the subsystem which side is using
> the resource (a certain GPIO line and register for example)
> it needs to deny certain operations and keep track of usage
> inside of the gpiolib subsystem.
>
> We have added a new API to help with this situation:
>
> gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
> gpio_unlock_as_irq(struct gpio_chip *chip,
> unsigned int offset)
>
> These should be called from the irq_chip startup() and
> .shutdown() callbacks to flag that the line is now in use by
> an IRQ. For example the GPIOlib core will deny the line to
> be set as output after this.
>
> If we need more infrastructure to help with this, I'm game.
>
> Clear as mud? ;-)
it's actually crystal clear.
>
> Yours,
> Linus Walleij
^ permalink raw reply
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