* [PATCH v3 1/4] dmaengine: at_hdmac: platform data move to use .id_table
From: Nicolas Ferre @ 2011-10-12 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318438634-11826-1-git-send-email-nicolas.ferre@atmel.com>
We remove the use of platform data from DMA controller driver.
We now use of .id_table to distinguish between compatible
types. The two implementations allow to determine the
number of channels and the capabilities of the controller.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 48 ++++++++++++++++++++++++++++++++++---------
drivers/dma/at_hdmac_regs.h | 8 +++++++
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index fcfa0a8..d1869c5 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1175,6 +1175,18 @@ static void atc_free_chan_resources(struct dma_chan *chan)
/*-- Module Management -----------------------------------------------*/
+static struct platform_device_id atdma_devtypes[] = {
+ {
+ .name = "at91sam9rl_dma",
+ .driver_data = ATDMA_DEVTYPE_SAM9RL,
+ }, {
+ .name = "at91sam9g45_dma",
+ .driver_data = ATDMA_DEVTYPE_SAM9G45,
+ }, {
+ /* sentinel */
+ }
+};
+
/**
* at_dma_off - disable DMA controller
* @atdma: the Atmel HDAMC device
@@ -1193,18 +1205,32 @@ static void at_dma_off(struct at_dma *atdma)
static int __init at_dma_probe(struct platform_device *pdev)
{
- struct at_dma_platform_data *pdata;
struct resource *io;
struct at_dma *atdma;
size_t size;
int irq;
int err;
int i;
+ u32 nr_channels;
+ dma_cap_mask_t cap_mask = {};
+ enum atdma_devtype atdmatype;
+
+ dma_cap_set(DMA_MEMCPY, cap_mask);
+
+ /* get DMA parameters from controller type */
+ atdmatype = platform_get_device_id(pdev)->driver_data;
- /* get DMA Controller parameters from platform */
- pdata = pdev->dev.platform_data;
- if (!pdata || pdata->nr_channels > AT_DMA_MAX_NR_CHANNELS)
+ switch (atdmatype) {
+ case ATDMA_DEVTYPE_SAM9RL:
+ nr_channels = 2;
+ break;
+ case ATDMA_DEVTYPE_SAM9G45:
+ nr_channels = 8;
+ dma_cap_set(DMA_SLAVE, cap_mask);
+ break;
+ default:
return -EINVAL;
+ }
io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!io)
@@ -1215,14 +1241,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
return irq;
size = sizeof(struct at_dma);
- size += pdata->nr_channels * sizeof(struct at_dma_chan);
+ size += nr_channels * sizeof(struct at_dma_chan);
atdma = kzalloc(size, GFP_KERNEL);
if (!atdma)
return -ENOMEM;
- /* discover transaction capabilites from the platform data */
- atdma->dma_common.cap_mask = pdata->cap_mask;
- atdma->all_chan_mask = (1 << pdata->nr_channels) - 1;
+ /* discover transaction capabilities */
+ atdma->dma_common.cap_mask = cap_mask;
+ atdma->all_chan_mask = (1 << nr_channels) - 1;
+ atdma->devtype = atdmatype;
size = resource_size(io);
if (!request_mem_region(io->start, size, pdev->dev.driver->name)) {
@@ -1268,7 +1295,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
/* initialize channels related values */
INIT_LIST_HEAD(&atdma->dma_common.channels);
- for (i = 0; i < pdata->nr_channels; i++) {
+ for (i = 0; i < nr_channels; i++) {
struct at_dma_chan *atchan = &atdma->chan[i];
atchan->chan_common.device = &atdma->dma_common;
@@ -1313,7 +1340,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel AHB DMA Controller ( %s%s), %d channels\n",
dma_has_cap(DMA_MEMCPY, atdma->dma_common.cap_mask) ? "cpy " : "",
dma_has_cap(DMA_SLAVE, atdma->dma_common.cap_mask) ? "slave " : "",
- pdata->nr_channels);
+ nr_channels);
dma_async_device_register(&atdma->dma_common);
@@ -1495,6 +1522,7 @@ static const struct dev_pm_ops at_dma_dev_pm_ops = {
static struct platform_driver at_dma_driver = {
.remove = __exit_p(at_dma_remove),
.shutdown = at_dma_shutdown,
+ .id_table = atdma_devtypes,
.driver = {
.name = "at_hdmac",
.pm = &at_dma_dev_pm_ops,
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index aa4c9ae..d7d6737 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -248,9 +248,16 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
/*-- Controller ------------------------------------------------------*/
+enum atdma_devtype {
+ ATDMA_DEVTYPE_UNDEFINED = 0,
+ ATDMA_DEVTYPE_SAM9RL, /* compatible with SAM9RL DMA controller */
+ ATDMA_DEVTYPE_SAM9G45, /* compatible with SAM9G45 DMA controller */
+};
+
/**
* struct at_dma - internal representation of an Atmel HDMA Controller
* @chan_common: common dmaengine dma_device object members
+ * @atdma_devtype: identifier of DMA controller compatibility
* @ch_regs: memory mapped register base
* @clk: dma controller clock
* @save_imr: interrupt mask register that is saved on suspend/resume cycle
@@ -260,6 +267,7 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
*/
struct at_dma {
struct dma_device dma_common;
+ enum atdma_devtype devtype;
void __iomem *regs;
struct clk *clk;
u32 save_imr;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 2/4] dmaengine: at_hdmac: add device tree support
From: Nicolas Ferre @ 2011-10-12 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318438634-11826-1-git-send-email-nicolas.ferre@atmel.com>
Add device tree probe support for atmel at_hdmac DMA driver.
Bindings are added to specify DMA controller configuration.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
.../devicetree/bindings/dma/atmel-dma.txt | 14 +++++++++
drivers/dma/at_hdmac.c | 30 +++++++++++++++++++-
2 files changed, 43 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
new file mode 100644
index 0000000..3c046ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -0,0 +1,14 @@
+* Atmel Direct Memory Access Controller (DMA)
+
+Required properties:
+- compatible: Should be "atmel,<chip>-dma"
+- reg: Should contain DMA registers location and length
+- interrupts: Should contain DMA interrupt
+
+Examples:
+
+dma at ffffec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+};
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index d1869c5..42bd64c 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -23,6 +23,8 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include "at_hdmac_regs.h"
@@ -1175,6 +1177,20 @@ static void atc_free_chan_resources(struct dma_chan *chan)
/*-- Module Management -----------------------------------------------*/
+#if defined(CONFIG_OF)
+static const struct of_device_id atmel_dma_dt_ids[] = {
+ {
+ .compatible = "atmel,at91sam9rl-dma",
+ .data = (void *)ATDMA_DEVTYPE_SAM9RL
+ }, {
+ .compatible = "atmel,at91sam9g45-dma",
+ .data = (void *)ATDMA_DEVTYPE_SAM9G45
+ }, { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, atmel_dma_dt_ids);
+#endif
+
static struct platform_device_id atdma_devtypes[] = {
{
.name = "at91sam9rl_dma",
@@ -1187,6 +1203,17 @@ static struct platform_device_id atdma_devtypes[] = {
}
};
+static inline enum atdma_devtype __init at_dma_get_driver_data(
+ struct platform_device *pdev)
+{
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(atmel_dma_dt_ids, pdev->dev.of_node);
+ return (enum atdma_devtype)match->data;
+ }
+ return platform_get_device_id(pdev)->driver_data;
+}
+
/**
* at_dma_off - disable DMA controller
* @atdma: the Atmel HDAMC device
@@ -1218,7 +1245,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_MEMCPY, cap_mask);
/* get DMA parameters from controller type */
- atdmatype = platform_get_device_id(pdev)->driver_data;
+ atdmatype = at_dma_get_driver_data(pdev);
switch (atdmatype) {
case ATDMA_DEVTYPE_SAM9RL:
@@ -1526,6 +1553,7 @@ static struct platform_driver at_dma_driver = {
.driver = {
.name = "at_hdmac",
.pm = &at_dma_dev_pm_ops,
+ .of_match_table = of_match_ptr(atmel_dma_dt_ids),
},
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 3/4] ARM: at91/dma: remove platform data from DMA controller
From: Nicolas Ferre @ 2011-10-12 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318438634-11826-1-git-send-email-nicolas.ferre@atmel.com>
DMA controller can deduce its configuration data from
the platform. Remove the platform data and match device
types with the compatible ones.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9g45_devices.c | 9 +--------
arch/arm/mach-at91/at91sam9rl_devices.c | 8 +-------
arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ----------
3 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..c9b897f 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -38,10 +38,6 @@
#if defined(CONFIG_AT_HDMAC) || defined(CONFIG_AT_HDMAC_MODULE)
static u64 hdmac_dmamask = DMA_BIT_MASK(32);
-static struct at_dma_platform_data atdma_pdata = {
- .nr_channels = 8,
-};
-
static struct resource hdmac_resources[] = {
[0] = {
.start = AT91_BASE_SYS + AT91_DMA,
@@ -56,12 +52,11 @@ static struct resource hdmac_resources[] = {
};
static struct platform_device at_hdmac_device = {
- .name = "at_hdmac",
+ .name = "at91sam9g45_dma",
.id = -1,
.dev = {
.dma_mask = &hdmac_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &atdma_pdata,
},
.resource = hdmac_resources,
.num_resources = ARRAY_SIZE(hdmac_resources),
@@ -69,8 +64,6 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
- dma_cap_set(DMA_SLAVE, atdma_pdata.cap_mask);
platform_device_register(&at_hdmac_device);
}
#else
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index aacb19d..81954f7 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -33,10 +33,6 @@
#if defined(CONFIG_AT_HDMAC) || defined(CONFIG_AT_HDMAC_MODULE)
static u64 hdmac_dmamask = DMA_BIT_MASK(32);
-static struct at_dma_platform_data atdma_pdata = {
- .nr_channels = 2,
-};
-
static struct resource hdmac_resources[] = {
[0] = {
.start = AT91_BASE_SYS + AT91_DMA,
@@ -51,12 +47,11 @@ static struct resource hdmac_resources[] = {
};
static struct platform_device at_hdmac_device = {
- .name = "at_hdmac",
+ .name = "at91sam9rl_dma",
.id = -1,
.dev = {
.dma_mask = &hdmac_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &atdma_pdata,
},
.resource = hdmac_resources,
.num_resources = ARRAY_SIZE(hdmac_resources),
@@ -64,7 +59,6 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
platform_device_register(&at_hdmac_device);
}
#else
diff --git a/arch/arm/mach-at91/include/mach/at_hdmac.h b/arch/arm/mach-at91/include/mach/at_hdmac.h
index 187cb58..652c1a1 100644
--- a/arch/arm/mach-at91/include/mach/at_hdmac.h
+++ b/arch/arm/mach-at91/include/mach/at_hdmac.h
@@ -14,16 +14,6 @@
#include <linux/dmaengine.h>
/**
- * struct at_dma_platform_data - Controller configuration parameters
- * @nr_channels: Number of channels supported by hardware (max 8)
- * @cap_mask: dma_capability flags supported by the platform
- */
-struct at_dma_platform_data {
- unsigned int nr_channels;
- dma_cap_mask_t cap_mask;
-};
-
-/**
* enum at_dma_slave_width - DMA slave register access width.
* @AT_DMA_SLAVE_WIDTH_8BIT: Do 8-bit slave register accesses
* @AT_DMA_SLAVE_WIDTH_16BIT: Do 16-bit slave register accesses
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 4/4] ARM: at91/dma: DMA controller registering with DT support
From: Nicolas Ferre @ 2011-10-12 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318438634-11826-1-git-send-email-nicolas.ferre@atmel.com>
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no dma-controller node is
found in device tree.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9g45_devices.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index c9b897f..b9888c5 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -64,7 +64,13 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- platform_device_register(&at_hdmac_device);
+ struct device_node *of_node =
+ of_find_node_by_name(NULL, "dma-controller");
+
+ if (of_node)
+ of_node_put(of_node);
+ else
+ platform_device_register(&at_hdmac_device);
}
#else
void __init at91_add_device_hdmac(void) {}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/5 v4] ARM Realview PCIX map include file changes
From: Russell King - ARM Linux @ 2011-10-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000001cc872e$d1aaf870$7500e950$@tuckley@arm.com>
On Mon, Oct 10, 2011 at 10:27:08AM +0100, Colin Tuckley wrote:
> Ah, I wasn't aware of that. However when I include asm/io.h and remove the
The general rule is that linux/io.h includes asm/io.h, which in turn
includes mach/io.h includes and nothing should include either asm/io.h
nor mach/io.h directly - if it does, things probably break - which is
desirable behaviour because that indicates that the include is wrong.
> A quick check shows that the piece of code you quote above does not exist in
> my (3.1.0-rc9) source tree.
It's not in -rc9, but will be during the next merge window - and is in
linux-next.
^ permalink raw reply
* [PATCH 4/5 v4] Realview PCIX support - add main support module code
From: Russell King - ARM Linux @ 2011-10-12 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000101cc872f$82425660$86c70320$@tuckley@arm.com>
On Mon, Oct 10, 2011 at 10:32:20AM +0100, Colin Tuckley wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Subject: Re: [PATCH 4/5 v4] Realview PCIX support - add main support
> > module code
>
> Russell said:
>
> > I thought one of my previous review points on this was that it was
> > completely unsafe to match only on dev->device, rather than on both
> > dev->device and dev->vendor. Device IDs are allocated by individual
> > vendors and are meaningless without also checking the vendor ID.
>
> And
>
> > And I thought we'd got to the point where we had a swizzle here.
>
> The patch I sent to the list was indeed an old version. However the reason
> is that despite the testing we did and your suggested changes the swizzle
> based code still does not fully work. So I thought it best to post working
> code.
>
> I'm still waiting for a response from you on the last round of test results
> I sent.
I don't have a response at the moment (and it's going to be a while
as I'm going to be using the next few days to catch up with quite a
backlog of email.) I've also lost all the context from March - which
was an absolute necessity to ensure the survival of the ARM Linux in
the mainline kernel sources.
^ permalink raw reply
* [PATCH] arm: fix handling of nr_cpus
From: Russell King - ARM Linux @ 2011-10-12 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318339864-32396-1-git-send-email-msalter@redhat.com>
On Tue, Oct 11, 2011 at 09:31:04AM -0400, Mark Salter wrote:
> The current code duplicates the setup of the cpu_possible bitmap in the
> platform smp_init_cpus() function. Unfortunately, all of those places
> have the same bug where the nr_cpus kernel parameter is ignored. This patch
> consolidates the duplicated code in one place and fixes it to honor the
> nr_cpus parameter. This is accomplished by having smp_init_cpus() return
> the platform specific number of cores so that the caller (setup_arch) can
> set up the cpu_possible bitmap correctly for all platforms.
Who says every platform we're going to see will always have CPUs 0..N ?
It's entirely possible that someone might want to have CPUs 0, 2, 3 as
possible CPUs but omit CPU1 for platform reasons.
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Russell King - ARM Linux @ 2011-10-12 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2414781.rlNqTThJUN@wuerfel>
On Tue, Oct 11, 2011 at 09:25:19PM +0200, Arnd Bergmann wrote:
> On Tuesday 11 October 2011 19:48:21 Will Deacon wrote:
> > On Tue, Oct 11, 2011 at 04:09:15PM +0100, Will Deacon wrote:
> > > For the cpu-mapping, I depend on:
> > >
> > > ARM: 7011/1: Add ARM cpu topology definition
> > > ARM: 7060/1: smp: populate logical CPU mapping during boot
> > > ARM: 7061/1: gic: convert logical CPU numbers into physical numbers
> > >
> > > which I can only see in Russell's for-next branch.
> > >
> > > For the debug-ll stuff, I depend on:
> > >
> > > ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART
> > >
> > > and conflict with:
> > >
> > > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
> > > ARM: 7096/1: debug: Add UART1 config choices
> > > ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice
> > > ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour
> >
> > I've stuck a debug-ll branch and a cpu-mapping branch here:
> >
> > git://github.com/wdeacon/linux-wd.git
>
> Ok, thanks.
>
> > (I finally gave up with my old broken git server!)
> >
> > These branches are based against -rc9 and I've cherry-picked the
> > dependencies from Russell's for-next branch. I'm not sure that's good for
> > anything, but it at least helps to show what's already in Russell's tree
> > and what's currently outstanding.
>
> I've stuck them into the arm-soc tree for now, so we get linux-next
> coverage, but I won't send them to Linus this way because then we
> would get the same commits twice in the history.
>
> Russell, would be mind putting the 8 patches that Will listed above
> into the devel-stable or some other non-rebasing branch so we can
> rebase Will's patches on top of that?
>
> Alternatively, if you prefer you could also throw them out of your
> tree so I can send them to Linus, or you could pull the two patch
> series from Will into your arm tree so I can drop them completely.
At this point in the game (which I guess is that the merge window is
very likely going to open this evening), I'm minded to just say no, my
tree is now frozen, and that's that - especially as there's a bunch of
_horrible_ merges involved in rebuilding that stuff now.
Especially as its going to take me a few days before I start looking
at touching my git tree as I'll be sorting through the email backlog.
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Will Deacon @ 2011-10-12 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012172925.GD21648@n2100.arm.linux.org.uk>
Hi Russell,
On Wed, Oct 12, 2011 at 06:29:25PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 11, 2011 at 09:25:19PM +0200, Arnd Bergmann wrote:
> > Russell, would be mind putting the 8 patches that Will listed above
> > into the devel-stable or some other non-rebasing branch so we can
> > rebase Will's patches on top of that?
> >
> > Alternatively, if you prefer you could also throw them out of your
> > tree so I can send them to Linus, or you could pull the two patch
> > series from Will into your arm tree so I can drop them completely.
>
> At this point in the game (which I guess is that the merge window is
> very likely going to open this evening), I'm minded to just say no, my
> tree is now frozen, and that's that - especially as there's a bunch of
> _horrible_ merges involved in rebuilding that stuff now.
>
> Especially as its going to take me a few days before I start looking
> at touching my git tree as I'll be sorting through the email backlog.
OK, that's understandable. Does this mean that your for-next branch is what
will be going to Linus when the merge window opens? If so, I can rebase onto
that now that it's frozen and Arnd can pull in the platform bits to arm-soc.
Cheers,
Will
^ permalink raw reply
* Anyone used KDB single-stepping on ARM
From: Tim Bird @ 2011-10-12 17:41 UTC (permalink / raw)
To: linux-arm-kernel
I've tried to use single-stepping ('ss' command) on ARM
from KDB, without success.
Has anyone done this - is it currently supported on ARM?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Russell King - ARM Linux @ 2011-10-12 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012173523.GB12865@mudshark.cambridge.arm.com>
On Wed, Oct 12, 2011 at 06:35:23PM +0100, Will Deacon wrote:
> OK, that's understandable. Does this mean that your for-next branch is what
> will be going to Linus when the merge window opens? If so, I can rebase onto
> that now that it's frozen and Arnd can pull in the platform bits to arm-soc.
Given that I've only been back for less than an hour, I can't say very
much because I don't know what the current state of anything is yet.
That's more the message I wanted to convey at the moment.
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Will Deacon @ 2011-10-12 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012180155.GE21648@n2100.arm.linux.org.uk>
On Wed, Oct 12, 2011 at 07:01:55PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2011 at 06:35:23PM +0100, Will Deacon wrote:
> > OK, that's understandable. Does this mean that your for-next branch is what
> > will be going to Linus when the merge window opens? If so, I can rebase onto
> > that now that it's frozen and Arnd can pull in the platform bits to arm-soc.
>
> Given that I've only been back for less than an hour, I can't say very
> much because I don't know what the current state of anything is yet.
> That's more the message I wanted to convey at the moment.
Right, I'll hold my horses 'til things have settled down then.
Thanks,
Will
^ permalink raw reply
* [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function
From: Kevin Hilman @ 2011-10-12 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAL8m4xTmz+-ureDiGPoKUu634q1Wy=h01kpfRWCk9LFCV0+Dg@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
> On Tue, Oct 11, 2011 at 11:54 PM, Kevin Hilman <khilman@ti.com> wrote:
>> "Govindraj.R" <govindraj.raja@ti.com> writes:
>>
>>> Modify the omap_uart_can_sleep function to check uart is active
>>> or not to be used by pm code to enter low power states.
>>
>> Doesn't the driver now control when the UART clocks are gated (using
>> runtime PM autosuspend)?
>>
>> IMO, this check should be completely removed and the driver should
>> be managing this with the autosuspend timeout.
>>
>>> Removing this check can cause console response little sluggish.
>>
>> Sluggish in what way?
>>
>
> response is slower like when we type something or cat debugfs/pm_count
> see things little slower on console, there is no character loss.
>
> Happens even though we have not set the autosuspend timeout and uart
> clocks are active, which basically means allowing mpu to enter
> retention keeping uart active.
OK, I see now.
> this delay in response or sluggishness is not there on my 3430SDP or
> 3630zoom board but I was able to see this behavior on a beagle
> board(xm rev c).
Here's why:
The difference is the powerdomain that the console UART is on for these
boards. UART1,2 are in CORE, UART2/3 are in PER. SDP uses UART1 (CORE),
Zoom3 doesn't use OMAP UARTs at all, and Beagle uses UART3 (PER).
Due to a HW sleepdep between MPU and CORE, MPU will not transition until
CORE does, which means MPU will not transition until UART 1 & 2 are
idle.
On Beagle, the console is ttyO2 (UART3) which is in PER, and since the
MPU is free to transition independently of PER, that is what is
happening, resulting in slower response time on for any boards that have
PER-UART consoles.
> retaining this uart_can_sleep check in omap3_can_sleep ensures a better
> console user experience. (not allowing mpu to enter retention
> until uart clocks are cut)
Yes, but obviously comes at the expense of power savings. IOW, This is
a hard-coded power vs. performance trade off that we are trying to get
away from.
So, the root of the problem is that the MPU wakeup latency is causing a
"sluggish" console. The solution? request an MPU wakeup latency
constraint.
This is a classic use-case for such a constraint, and the serial driver
should have the option of requesting a constraint to prevent the sluggish
console. The constraint only needs to be held until the auto-suspend
delay expires, so should be relased in the ->runtime_suspend() method of
the driver.
This constraint needs to be configurable, probably from the board file,
so that it is optional, and so users who don't care about sluggish
consoles (or non-console UART users who don't care about response time)
have the option of preferring power savings over UART responsiveness.
As a reference, the i2c driver is currently doing something similar
in that it request an MPU constraint to prevent the MPU from going into
retention/off while waiting for an i2c interrupt to arrive.
Kevin
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Nicolas Pitre @ 2011-10-12 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012083819.GB2418@totoro>
On Wed, 12 Oct 2011, Jamie Iles wrote:
> Hi Nicolas,
>
> On Tue, Oct 11, 2011 at 08:03:38PM -0400, Nicolas Pitre wrote:
> > On Tue, 11 Oct 2011, Arnd Bergmann wrote:
> >
> > > I've stuck them into the arm-soc tree for now, so we get linux-next
> > > coverage, but I won't send them to Linus this way because then we
> > > would get the same commits twice in the history.
> >
> > Could you please do the same with the following:
> >
> > git://git.linaro.org/people/nico/linux.git mach_memory_h
> >
> > Russell pulled it at some point, and dropped it due to concerns about
> > repeated conflict resolutions (or so I presume). I just did a test
> > merge between your for-next branch and the above and that looked trivial
> > enough.
>
> I just had a quick look at this branch as picoxcell has just been merged
> with an empty memory.h. I'll submit a patch to remove that, but I just
> noticed in "ARM: switch from NO_MACH_MEMORY_H to NEED_MACH_MEMORY_H"
> there is this hunk:
>
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index e00fe76..6d49d2f1d 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -14,6 +14,7 @@ config ARCH_OMAP1
> select CLKDEV_LOOKUP
> select CLKSRC_MMIO
> select GENERIC_IRQ_CHIP
> + select HAVE_MACH_MEMORY_H
> help
> "Systems based on omap7xx, omap15xx or omap16xx"
>
> and I think that should be "select NEED_MACH_MEMORY_H" instead.
Indeed, good catch. I've updated my branch with that fix.
Nicolas
^ permalink raw reply
* [PATCH] MAINTAINERS: Update tegra maintainer information
From: Grant Likely @ 2011-10-12 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173B23B3B9@HQMAIL01.nvidia.com>
On Fri, Oct 7, 2011 at 3:28 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Olof Johansson wrote at Friday, October 07, 2011 2:28 PM:
>> A couple of changes to the Tegra maintainership setup:
>>
>> I'm very glad to bring on Stephen Warren on board as a maintainer. The
>> work he has done so far is excellent, and the fact that he works for
>> Nvidia means he has long-term interest in the platform.
>
> Thanks for bringing me on board.
>
> Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
>> Erik Gilling did an astounding amount of work on getting things up and
>> running but has been a silent partner on the maintainership side for a
>> while, and is stepping down. Thanks for your contributions so far, Erik.
>
> I'd like to echo this, and also extend it to everyone else who's brought
> Tegra support to the point where it is today.
>
> --
> nvpublic
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] ARM: zImage: Use $(CROSS_COMPILE)size to get .bss size
From: Tony Lindgren @ 2011-10-12 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110121029470.17040@xanadu.home>
* Nicolas Pitre <nicolas.pitre@linaro.org> [111012 07:03]:
> On Wed, 12 Oct 2011, Thomas Weber wrote:
>
> > Use $(CROSS_COMPILE)size to determine the bss size
> > from vmlinux.
> >
> > The problem is introduced in:
> > commit 8738646c02064d38f6fb056eb039ebf9138c5434
> >
> > ARM: zImage: make sure appended DTB doesn't get
> > overwritten by kernel .bss
> >
> > This fixes following error message:
> >
> > size: arch/arm/boot/compressed/../../../../vmlinux:
> > File format is ambiguous
> >
> > size: Matching formats:
> > elf32-littlearm
> > elf32-littlearm-symbian
> > elf32-littlearm-vxworks
> >
> > Signed-off-by: Thomas Weber <weber@corscience.de>
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [RFC 2/2] dma-buf: Documentation for buffer sharing framework
From: Randy Dunlap @ 2011-10-12 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318325033-32688-3-git-send-email-sumit.semwal@ti.com>
On 10/11/2011 02:23 AM, Sumit Semwal wrote:
> Add documentation for dma buffer sharing framework, explaining the
> various operations, members and API of the dma buffer sharing
> framework.
>
> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
> ---
> Documentation/dma-buf-sharing.txt | 210 +++++++++++++++++++++++++++++++++++++
> 1 files changed, 210 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/dma-buf-sharing.txt
>
> diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
> new file mode 100644
> index 0000000..4da6644
> --- /dev/null
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -0,0 +1,210 @@
> + DMA Buffer Sharing API Guide
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> + Sumit Semwal
> + <sumit dot semwal@linaro dot org>
> + <sumit dot semwal@ti dot com>
> +
> +This document serves as a guide to device-driver writers on what is the dma-buf
> +buffer sharing API, how to use it for exporting and using shared buffers.
> +
> +Any device driver which wishes to be a part of dma buffer sharing, can do so as
Please use DMA instead of dma (except combinations like dma-buf are OK). [multiple]
> +either the 'exporter' of buffers, or the 'user' of buffers.
> +
> +Say a driver A wants to use buffers created by driver B, then we call B as the
> +exporter, and B as buffer-user.
and A
> +
> +The exporter
> +- implements and manages operations[1] for the buffer
> +- allows other users to share the buffer by using dma_buf sharing APIs,
> +- manages the details of buffer allocation,
> +- decides about the actual backing storage where this allocation happens,
> +- takes care of any migration of scatterlist - for all (shared) users of this
> + buffer,
> +- optionally, provides mmap capability for drivers that need it.
> +
> +The buffer-user
> +- is one of (many) sharing users of the buffer.
> +- doesn't need to worry about how the buffer is allocated, or where.
> +- needs a mechanism to get access to the scatterlist that makes up this buffer
> + in memory, mapped into its own address space, so it can access the same area
> + of memory.
> +
> +
> +The dma_buf buffer sharing API usage contains the following steps:
> +
> +1. Exporter announces that it wishes to export a buffer
> +2. Userspace gets the file descriptor associated with the exported buffer, and
> + passes it around to potential buffer-users based on use case
> +3. Each buffer-user 'connects' itself to the buffer
> +4. When needed, buffer-user requests access to the buffer from exporter
> +5. When finished with its use, the buffer-user notifies end-of-dma to exporter
> +6. when buffer-user is done using this buffer completely, it 'disconnects'
> + itself from the buffer.
> +
> +
> +1. Exporter's announcement of buffer export
> +
> + The buffer exporter announces its wish to export a buffer. In this, it
> + connects its own private buffer data, provides implementation for operations
> + that can be performed on the exported dma_buf, and flags for the file
> + associated with this buffer.
> +
> + Interface:
> + struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
> + int flags)
> +
> + If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
> + pointer to the same. It also associates an anon file with this buffer, so it
s/anon/anonymous/ (multiple)
> + can be exported. On failure to allocate the dma_buf object, it returns NULL.
> +
> +2. Userspace gets a handle to pass around to potential buffer-users
> +
> + Userspace entity requests for a file-descriptor (fd) which is a handle to the
> + anon file associated with the buffer. It can then share the fd with other
> + drivers and/or processes.
> +
> + Interface:
> + int dma_buf_fd(struct dma_buf *dmabuf)
> +
> + This API installs an fd for the anon file associated with this buffer;
> + returns either 'fd', or error.
> +
> +3. Each buffer-user 'connects' itself to the buffer
> +
> + Each buffer-user now gets a reference to the buffer, using the fd passed to
> + it.
> +
> + Interface:
> + struct dma_buf *dma_buf_get(int fd)
> +
> + This API will return a reference to the dma_buf, and increment refcount for
> + it.
> +
> + After this, the buffer-user needs to attach its device with the buffer, which
> + helps the exporter to know of device buffer constraints.
> +
> + Interface:
> + struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> + struct device *dev)
> +
> + This API returns reference to an attachment structure, which is then used
> + for scatterlist operations. It will optionally call the 'attach' dma_buf
> + operation, if provided by the exporter.
> +
> + The dma-buf sharing framework does the book-keeping bits related to keeping
bookkeeping
> + the list of all attachments to a buffer.
> +
> +Till this stage, the buffer-exporter has the option to choose not to actually
Until
> +allocate the backing storage for this buffer, but wait for the first buffer-user
> +to request use of buffer for allocation.
> +
> +
> +4. When needed, buffer-user requests access to the buffer
> +
> + Whenever a buffer-user wants to use the buffer for any dma, it asks for
> + access to the buffer using dma_buf->ops->get_scatterlist operation. Atleast
At least
> + one attach to the buffer should have happened before get_scatterlist can be
> + called.
> +
> + Interface: [member of struct dma_buf_ops]
> + struct scatterlist * (*get_scatterlist)(struct dma_buf_attachment *,
> + enum dma_data_direction,
> + int* nents);
> +
> + It is one of the buffer operations that must be implemented by the exporter.
> + It should return the scatterlist for this buffer, mapped into caller's address
> + space.
> +
> + If this is being called for the first time, the exporter can now choose to
> + scan through the list of attachments for this buffer, collate the requirements
> + of the attached devices, and choose an appropriate backing storage for the
> + buffer.
> +
> + Based on enum dma_data_direction, it might be possible to have multiple users
> + accessing at the same time (for reading, maybe), or any other kind of sharing
> + that the exporter might wish to make available to buffer-users.
> +
> +
> +5. When finished, the buffer-user notifies end-of-dma to exporter
> +
> + Once the dma for the current buffer-user is over, it signals 'end-of-dma' to
> + the exporter using the dma_buf->ops->put_scatterlist() operation.
> +
> + Interface:
> + void (*put_scatterlist)(struct dma_buf_attachment *, struct scatterlist *,
> + int nents);
> +
> + put_scatterlist signifies the end-of-dma for the attachment provided.
> +
> +
> +6. when buffer-user is done using this buffer, it 'disconnects' itself from the
> + buffer.
> +
> + After the buffer-user has no more interest in using this buffer, it should
> + disconnect itself from the buffer:
> +
> + - it first detaches itself from the buffer.
> +
> + Interface:
> + void dma_buf_detach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *dmabuf_attach);
> +
> + This API removes the attachment from the list in dmabuf, and optionally calls
> + dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits.
> +
> + - Then, the buffer-user returns the buffer reference to exporter.
> +
> + Interface:
> + void dma_buf_put(struct dma_buf *dmabuf);
> +
> + This API then reduces the refcount for this buffer.
> +
> + If, as a result of this call, the refcount becomes 0, the 'release' file
> + operation related to this fd is called. It calls the dmabuf->ops->release()
> + operation in turn, and frees the memory allocated for dmabuf when exported.
> +
> +NOTES:
> +- Importance of attach-detach and {get,put}_scatterlist operation pairs
> + The attach-detach calls allow the exporter to figure out backing-storage
> + constraints for the currently-interested devices. This allows preferential
> + allocation, and/or migration of pages across different types of storage
> + available, if possible.
> +
> + Bracketing of dma access with {get,put}_scatterlist operations is essential
> + to allow just-in-time backing of storage, and migration mid-way through a
> + use-case.
> +
> +- Migration of backing storage if needed
> + After
> + - atleast one get_scatterlist has happened,
at least
> + - and the backing storage has been allocated for this buffer,
> + If another new buffer-user intends to attach itself to this buffer, it might
> + be allowed, if possible for the exporter.
> +
> + In case it is allowed by the exporter:
> + if the new buffer-user has stricter 'backing-storage constraints', and the
> + exporter can handle these constraints, the exporter can just stall on the
> + get_scatterlist till all outstanding access is completed (as signalled by
until
> + put_scatterlist).
> + Once all ongoing access is completed, the exporter could potentially move
> + the buffer to the stricter backing-storage, and then allow further
> + {get,put}_scatterlist operations from any buffer-user from the migrated
> + backing-storage.
> +
> + If the exporter cannot fulfill the backing-storage constraints of the new
> + buffer-user device as requested, dma_buf_attach() would return an error to
> + denote non-compatibility of the new buffer-sharing request with the current
> + buffer.
> +
> + If the exporter chooses not to allow an attach() operation once a
> + get_scatterlist has been called, it simply returns an error.
> +
> +- mmap file operation
> + An mmap() file operation is provided for the fd associated with the buffer.
> + If the exporter defines an mmap operation, the mmap() fop calls this to allow
> + mmap for devices that might need it; if not, it returns an error.
> +
> +References:
> +[1] struct dma_buf_ops in include/linux/dma-buf.h
> +[2] All interfaces mentioned above defined in include/linux/dma-buf.h
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH v9 0/3] Add support for tegra2 based ventana board
From: Olof Johansson @ 2011-10-12 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE19D81@HQMAIL01.nvidia.com>
On Wed, Oct 12, 2011 at 08:56:47AM -0700, Stephen Warren wrote:
> pdeschrijver at nvidia.com wrote at Wednesday, October 12, 2011 5:53 AM:
> > This patch set adds support for the tegra2 based ventana development board.
> >
> > Boot tested on ventana.
> >
> > Uses a table based approach to select the correct init function.
> >
> > Provoke kernel warning when no suitable pinmux table can be found.
>
> Whole series:
>
> Acked-by: Stephen Warren <swarren@nvidia.com>
>
> Thanks for following up on my picky comments:-)
Yes, thanks Peter.
Applied to for-3.2/features. I had to do some fixups since I applied it
on top of some of Stephen's changes for gpio/pinmux, so please verify
that I did the fixups correctly.
-Olof
^ permalink raw reply
* [PATCH v4 1/4] arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
From: Olof Johansson @ 2011-10-12 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-1-git-send-email-swarren@nvidia.com>
On Tue, Oct 11, 2011 at 04:16:12PM -0600, Stephen Warren wrote:
> The Tegra GPIO driver will be converted from static registration via
> postcore_initcall() to be a platform device later in this patch series.
> A new Tegra pinmux platform device will also be added.
>
> Prepare for this by modifying all boards to register the appropriate
> platform devices before-hand, so that when the drivers are converted,
> those devices will be probed, and git bisectability will be maintained.
>
> v2: Add resource definitions for GPIO and pinmux
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks, applied to for-3.2/features.
-Olof
^ permalink raw reply
* [PATCH v4 2/4] arm/dt: Tegra: Add pinmux node to tegra20.dtsi
From: Olof Johansson @ 2011-10-12 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-2-git-send-email-swarren@nvidia.com>
On Tue, Oct 11, 2011 at 04:16:13PM -0600, Stephen Warren wrote:
> Add a pinmux node to tegra20.dtsi in order to instantiate the future
> pinmux device.
>
> v2: Specify reg property precisely; don't just point at the whole APB_MISC
> register range.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks, applied to for-3.2/features.
-Olof
^ permalink raw reply
* [PATCH v4 4/4] arm/tegra: Convert pinmux driver to a platform device
From: Olof Johansson @ 2011-10-12 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-4-git-send-email-swarren@nvidia.com>
On Tue, Oct 11, 2011 at 04:16:15PM -0600, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks, applied to for-3.2/features.
(In the future, please give at least a one-sentence patch description in the
body).
-Olof
^ permalink raw reply
* [PATCH v4 3/4] gpio/tegra: Convert to a platform device
From: Olof Johansson @ 2011-10-12 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-3-git-send-email-swarren@nvidia.com>
On Tue, Oct 11, 2011 at 04:16:14PM -0600, Stephen Warren wrote:
> v3: Make regs variable static. Remove empty init of tegra_gpio_banks.
>
> v2: Retrieve IRQ and memory addresses from resources instead of hard-
> coding them. Add back initialization of tegra_gpio_chip.of_node.
In the future, please move the revision log to below the ---, and just have
the main patch description above, since that is what goes into the git repo.
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Otherwise, patch looks good. Due to dependencies between this, the rest
of this patch series and the pinmux changes, I'll hold off on it until
the dependencies land (i.e. target it for 3.3). We're cutting it very close
to the merge window as it is, I'll start for-3.3 branches shortly.
-Olof
^ permalink raw reply
* [PATCH v2] arm/tegra: pinmux: ioremap registers
From: Olof Johansson @ 2011-10-12 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318434867-19120-1-git-send-email-swarren@nvidia.com>
On Wed, Oct 12, 2011 at 09:54:27AM -0600, Stephen Warren wrote:
> Use ioremap to obtain access to registers instead of using static
> mappings. This reduces the number of users of the static mappings, which
> will eventually allow them to be removed.
>
> Note that on Tegra30, the number of register "banks" will decrease to 2,
> and the packing of specific bits into registers will change significantly.
> That's why this change adds the "*_bank" fields to the pingroup tables,
> rather than implementing some more hard-coded scheme.
>
> Also, completely remove the implementation of suspend/resume; Tegra doesn't
> yet support suspend/resume, and the implementation is complex for the
> general pinmux driver:
>
> * Not all registers are used within each bank, so we probably shouldn't
> just iterate over every register in the bank, and save/restore it,
> since that would mean touching undefined registers.
>
> * Registers are shared between pingroups, so we can't simply iterate over
> each pingroup, and save/restore the registers it uses.
>
> It'd probably be best have probe() calculate a bitmask of actually-used
> registers for each bank, and have suspend/resume iterate over those
> bitmaps.
>
> Oh, and Real Soon Now, I should be looking into converting this driver to
> the new pinmux/pinctrl subsystem, so I didn't want to put too much work
> into the current incarnation.
>
> v2: s/space/bank/ to match comments on reg_* fields in pinmux.h.
> Re-order bank/reg parameters to pg_readl/pg_writel.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks, applied to for-3.2/features.
-Olof
^ permalink raw reply
* [PATCH v4 3/4] gpio/tegra: Convert to a platform device
From: Stephen Warren @ 2011-10-12 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012224131.GD25128@quad.lixom.net>
Olof Johansson wrote at Wednesday, October 12, 2011 4:42 PM:
> On Tue, Oct 11, 2011 at 04:16:14PM -0600, Stephen Warren wrote:
> > v3: Make regs variable static. Remove empty init of tegra_gpio_banks.
> >
> > v2: Retrieve IRQ and memory addresses from resources instead of hard-
> > coding them. Add back initialization of tegra_gpio_chip.of_node.
>
> In the future, please move the revision log to below the ---, and just have
> the main patch description above, since that is what goes into the git repo.
I don't quite recall when or exactly which Linux-related mailing list I
saw it on, but I saw a discussion on this topic, and people pointed out
that having the revision log in the git commit message actually has some
advantages; it documents some of the things that were though about during
the review, and ends up documenting which version of the patch actually
ended up in git.
Besides, it's a lot easier to maintain the changelog in the git commit
description than in some out-of-band location:-) Although I guess I
could edit the files after git format-patch.
So, I wonder if it might be a good idea to check the changelog in?
--
nvpublic
^ permalink raw reply
* [PATCH] arm/tegra: Harmony: Configure PMC for low-level interrupts
From: Olof Johansson @ 2011-10-12 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316643040-7998-1-git-send-email-swarren@nvidia.com>
On Wed, Sep 21, 2011 at 04:10:40PM -0600, Stephen Warren wrote:
> Without this, the PMC continually detects an interrupt when the PMU_IRQ
> line is high, causing the tps6686x IRQ handler thread to hog an entire
> CPU.
>
> This change was originally written by Wei Ni <wni@nvidia.com> for Seaboard
> in the ChromeOS kernel.
>
> Long-term, this should probably be moved into some kind of PMU driver,
> or perhaps integrated into the GPIO/IRQ/pinmux system?
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks, applied to for-3.2/features.
-Olof
^ 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