* [PATCH v5] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs From: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
From: Kevin Hilman @ 2011-01-03 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294059807-2723-1-git-send-email-michael.williamson@criticallink.com>
Michael Williamson <michael.williamson@criticallink.com> writes:
I'm assuming the 'From:' line currently in the subject was supposed to
go here?
Kevin
> The JTAG variant code for Rev-2.0 silicon of the OMAP-L138 has changed.
> In addition, the variant code for the AM-1808 SoC appears to match
> the Rev-2.0 code for the OMAP-L138. Add an additional entry to support
> these chips.
>
> This patch is originally from a patch on the arago project, here:
> http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=6157618435e313a444cdf059702bd34036a6e2b7
>
> Further information related to the need for this patch can be located at
> http://e2e.ti.com/support/embedded/f/354/p/67290/248486.aspx
> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021224.html
>
> This patch was tested using an AM-1808 SoC on a MityARM-1808 SoM card. It
> was also tested using a Rev 1.0 silicon OMAP-L138 on a MityDSP-L138F card.
>
> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
> Reported-by: Nicolas Luna <luna.id@gmail.com>
> ---
> Built against linux-davinci tree.
>
> Changes since v4.
>
> - removed am18x code from 0 variant per Sekhar's request.
>
> arch/arm/mach-davinci/da850.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 78b5ae2..1550ac3 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -764,6 +764,13 @@ static struct davinci_id da850_ids[] = {
> .cpu_id = DAVINCI_CPU_ID_DA850,
> .name = "da850/omap-l138",
> },
> + {
> + .variant = 0x1,
> + .part_no = 0xb7d1,
> + .manufacturer = 0x017, /* 0x02f >> 1 */
> + .cpu_id = DAVINCI_CPU_ID_DA850,
> + .name = "da850/omap-l138/am18x",
> + },
> };
>
> static struct davinci_timer_instance da850_timer_instance[4] = {
^ permalink raw reply
* [PATCH 09/48] ARM: PL08x: add comment explaining the flow control methods
From: Russell King - ARM Linux @ 2011-01-03 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
Explain the two flow control methods which the PL08x implements, along
with the problem which peripheral flow control presents. This helps
people understand why we are unable to use these DMA controllers with
(eg) the MMCI.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 74fa5a0..4b63fc3 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -53,7 +53,23 @@
*
* ASSUMES default (little) endianness for DMA transfers
*
- * Only DMAC flow control is implemented
+ * The PL08x has two flow control settings:
+ * - DMAC flow control: the transfer size defines the number of transfers
+ * which occur for the current LLI entry, and the DMAC raises TC at the
+ * end of every LLI entry. Observed behaviour shows the DMAC listening
+ * to both the BREQ and SREQ signals (contrary to documented),
+ * transferring data if either is active. The LBREQ and LSREQ signals
+ * are ignored.
+ *
+ * - Peripheral flow control: the transfer size is ignored (and should be
+ * zero). The data is transferred from the current LLI entry, until
+ * after the final transfer signalled by LBREQ or LSREQ. The DMAC
+ * will then move to the next LLI entry.
+ *
+ * Only the former works sanely with scatter lists, so we only implement
+ * the DMAC flow control method. However, peripherals which use the LBREQ
+ * and LSREQ signals (eg, MMCI) are unable to use this mode, which through
+ * these hardware restrictions prevents them from using scatter DMA.
*
* Global TODO:
* - Break out common code from arch/arm/mach-s3c64xx and share
--
1.6.2.5
^ permalink raw reply related
* [PATCH 08/48] ARM: PL08x: fix sparse warnings
From: Russell King - ARM Linux @ 2011-01-03 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
drivers/dma/amba-pl08x.c:1895:40: warning: Unknown escape '%'
drivers/dma/amba-pl08x.c:1903:40: warning: Unknown escape '%'
drivers/dma/amba-pl08x.c:513:6: warning: symbol 'pl08x_choose_master_bus' was not declared. Should it be static?
drivers/dma/amba-pl08x.c:604:5: warning: symbol 'pl08x_fill_llis_for_desc' was not declared. Should it be static?
drivers/dma/amba-pl08x.c:1442:32: warning: symbol 'pl08x_prep_slave_sg' was not declared. Should it be static?
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 4ca1eb1..74fa5a0 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -510,7 +510,7 @@ static inline u32 pl08x_cctl_bits(u32 cctl, u8 srcwidth, u8 dstwidth,
* this prefers the destination bus if both available
* if fixed address on one bus the other will be chosen
*/
-void pl08x_choose_master_bus(struct pl08x_bus_data *src_bus,
+static void pl08x_choose_master_bus(struct pl08x_bus_data *src_bus,
struct pl08x_bus_data *dst_bus, struct pl08x_bus_data **mbus,
struct pl08x_bus_data **sbus, u32 cctl)
{
@@ -545,7 +545,7 @@ void pl08x_choose_master_bus(struct pl08x_bus_data *src_bus,
* Fills in one LLI for a certain transfer descriptor
* and advance the counter
*/
-int pl08x_fill_lli_for_desc(struct pl08x_driver_data *pl08x,
+static int pl08x_fill_lli_for_desc(struct pl08x_driver_data *pl08x,
struct pl08x_txd *txd, int num_llis, int len,
u32 cctl, u32 *remainder)
{
@@ -1439,7 +1439,7 @@ static struct dma_async_tx_descriptor *pl08x_prep_dma_memcpy(
return &txd->tx;
}
-struct dma_async_tx_descriptor *pl08x_prep_slave_sg(
+static struct dma_async_tx_descriptor *pl08x_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_data_direction direction,
unsigned long flags)
@@ -1890,7 +1890,7 @@ static int pl08x_debugfs_show(struct seq_file *s, void *data)
seq_printf(s, "CHANNEL:\tSTATE:\n");
seq_printf(s, "--------\t------\n");
list_for_each_entry(chan, &pl08x->memcpy.channels, chan.device_node) {
- seq_printf(s, "%s\t\t\%s\n", chan->name,
+ seq_printf(s, "%s\t\t%s\n", chan->name,
pl08x_state_str(chan->state));
}
@@ -1898,7 +1898,7 @@ static int pl08x_debugfs_show(struct seq_file *s, void *data)
seq_printf(s, "CHANNEL:\tSTATE:\n");
seq_printf(s, "--------\t------\n");
list_for_each_entry(chan, &pl08x->slave.channels, chan.device_node) {
- seq_printf(s, "%s\t\t\%s\n", chan->name,
+ seq_printf(s, "%s\t\t%s\n", chan->name,
pl08x_state_str(chan->state));
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH 07/48] ARM: PL08x: fix deadlock in terminate_all
From: Russell King - ARM Linux @ 2011-01-03 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
Trying to disable a tasklet while holding a spinlock which the tasklet
will take is a recipe for deadlock - tasklet_disable() will wait for the
tasklet to finish running, which it will never do. In any case, there
is not a corresponding tasklet_enable(), so once the tasklet is disabled,
it will never run again until reboot.
It's safe to just remove the tasklet_disable() as we remove all current
and pending descriptors before releasing this spinlock. This means that
the tasklet will find no remaining work if it subsequently runs.
The only remaining issue is that the callback for an already submitted
txd may be in progress, or even called after terminate_all() returns.
There's not much that can be done about that as waiting for the callback
to complete before returning will also lead to deadlocks.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 9a8d445..4ca1eb1 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1560,8 +1560,6 @@ static int pl08x_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
pl08x_put_phy_channel(pl08x, plchan->phychan);
plchan->phychan = NULL;
}
- /* Stop any pending tasklet */
- tasklet_disable(&plchan->tasklet);
/* Dequeue jobs and free LLIs */
if (plchan->at) {
pl08x_free_txd(pl08x, plchan->at);
--
1.6.2.5
^ permalink raw reply related
* [PATCH 06/48] ARM: PL08x: fix missed spin-unlock in pl08x_issue_pending()
From: Russell King - ARM Linux @ 2011-01-03 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
pl08x_issue_pending() returns with the spinlock locked and interrupts
disabled if the channel is waiting for a physical DMA to become free.
This is wrong - especially as pl08x_issue_pending() is an API function
as it leads to deadlocks. Fix it to always return with the spinlock
unlocked.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index b3b3180..9a8d445 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1294,15 +1294,11 @@ static void pl08x_issue_pending(struct dma_chan *chan)
unsigned long flags;
spin_lock_irqsave(&plchan->lock, flags);
- /* Something is already active */
- if (plchan->at) {
- spin_unlock_irqrestore(&plchan->lock, flags);
- return;
- }
-
- /* Didn't get a physical channel so waiting for it ... */
- if (plchan->state == PL08X_CHAN_WAITING)
+ /* Something is already active, or we're waiting for a channel... */
+ if (plchan->at || plchan->state == PL08X_CHAN_WAITING) {
+ spin_unlock_irqrestore(&plchan->lock, flags);
return;
+ }
/* Take the first element in the queue and execute it */
if (!list_empty(&plchan->desc_list)) {
--
1.6.2.5
^ permalink raw reply related
* [PATCH 05/48] ARM: PL08x: fix a leak when preparing TXDs
From: Russell King - ARM Linux @ 2011-01-03 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
If we fail to allocate the LLI, the prep_* function will return NULL.
However, the TXD we allocated will not be placed on any list, nor
will it be freed - we'll just drop all references to it. Make sure
we free it rather than leaking TXDs.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 69cfb05..b3b3180 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1332,9 +1332,10 @@ static int pl08x_prep_channel_resources(struct pl08x_dma_chan *plchan,
int ret;
num_llis = pl08x_fill_llis_for_desc(pl08x, txd);
-
- if (!num_llis)
+ if (!num_llis) {
+ kfree(txd);
return -EINVAL;
+ }
spin_lock_irqsave(&plchan->lock, plchan->lockflags);
--
1.6.2.5
^ permalink raw reply related
* [PATCH 04/48] ARM: PL08x: fix locking in tasklet
From: Russell King - ARM Linux @ 2011-01-03 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
Tasklets are run from an interruptible context. The slave DMA functions
can be called from within IRQ handlers. Taking the spinlock without
disabling interrupts allows an interrupt handler to run, which may try
to take the spinlock again, resulting in deadlock. Fix this by using
the irqsave spinlocks.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 5d9a156..69cfb05 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1627,11 +1627,12 @@ static void pl08x_tasklet(unsigned long data)
struct pl08x_dma_chan *plchan = (struct pl08x_dma_chan *) data;
struct pl08x_phy_chan *phychan = plchan->phychan;
struct pl08x_driver_data *pl08x = plchan->host;
+ unsigned long flags;
if (!plchan)
BUG();
- spin_lock(&plchan->lock);
+ spin_lock_irqsave(&plchan->lock, flags);
if (plchan->at) {
dma_async_tx_callback callback =
@@ -1728,7 +1729,7 @@ static void pl08x_tasklet(unsigned long data)
}
}
- spin_unlock(&plchan->lock);
+ spin_unlock_irqrestore(&plchan->lock, flags);
}
static irqreturn_t pl08x_irq(int irq, void *dev)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 03/48] ARM: PL08x: fix atomic_t usage and tx_submit() return value range
From: Russell King - ARM Linux @ 2011-01-03 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
The last_issued variable uses an atomic type, which is only
incremented inside a protected region, and then read. Everywhere else
only reads the value, so it isn't using atomic_t correctly, and it
doesn't even need to. Moreover, the DMA engine code provides us with
a variable for this already - chan.cookie. Use chan.cookie instead.
Also, avoid negative dma_cookie_t values - negative returns from
tx_submit() mean failure, yet in reality we always succeed. Restart
from cookie 1, just like other DMA engine drivers do.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 18 +++++++++---------
include/linux/amba/pl08x.h | 1 -
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 0809810..5d9a156 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -74,7 +74,6 @@
#include <asm/hardware/pl080.h>
#include <asm/dma.h>
#include <asm/mach/dma.h>
-#include <asm/atomic.h>
#include <asm/processor.h>
#include <asm/cacheflush.h>
@@ -1082,8 +1081,10 @@ static dma_cookie_t pl08x_tx_submit(struct dma_async_tx_descriptor *tx)
{
struct pl08x_dma_chan *plchan = to_pl08x_chan(tx->chan);
- atomic_inc(&plchan->last_issued);
- tx->cookie = atomic_read(&plchan->last_issued);
+ plchan->chan.cookie += 1;
+ if (plchan->chan.cookie < 0)
+ plchan->chan.cookie = 1;
+ tx->cookie = plchan->chan.cookie;
/* This unlock follows the lock in the prep() function */
spin_unlock_irqrestore(&plchan->lock, plchan->lockflags);
@@ -1115,7 +1116,7 @@ pl08x_dma_tx_status(struct dma_chan *chan,
enum dma_status ret;
u32 bytesleft = 0;
- last_used = atomic_read(&plchan->last_issued);
+ last_used = plchan->chan.cookie;
last_complete = plchan->lc;
ret = dma_async_is_complete(cookie, last_complete, last_used);
@@ -1131,7 +1132,7 @@ pl08x_dma_tx_status(struct dma_chan *chan,
/*
* This cookie not complete yet
*/
- last_used = atomic_read(&plchan->last_issued);
+ last_used = plchan->chan.cookie;
last_complete = plchan->lc;
/* Get number of bytes left in the active transactions and queue */
@@ -1641,8 +1642,7 @@ static void pl08x_tasklet(unsigned long data)
/*
* Update last completed
*/
- plchan->lc =
- (plchan->at->tx.cookie);
+ plchan->lc = plchan->at->tx.cookie;
/*
* Callback to signal completion
@@ -1820,8 +1820,8 @@ static int pl08x_dma_init_virtual_channels(struct pl08x_driver_data *pl08x,
chan->name);
chan->chan.device = dmadev;
- atomic_set(&chan->last_issued, 0);
- chan->lc = atomic_read(&chan->last_issued);
+ chan->chan.cookie = 0;
+ chan->lc = 0;
spin_lock_init(&chan->lock);
INIT_LIST_HEAD(&chan->desc_list);
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 521a0f8..4ae62b4 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -174,7 +174,6 @@ struct pl08x_dma_chan {
struct pl08x_channel_data *cd;
dma_addr_t runtime_addr;
enum dma_data_direction runtime_direction;
- atomic_t last_issued;
dma_cookie_t lc;
struct list_head desc_list;
struct pl08x_txd *at;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 02/48] ARM: PL08x: fix array overflow in dma_set_runtime_config()
From: Russell King - ARM Linux @ 2011-01-03 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
If maxburst was passed in as zero, we would overflow the burst_sizes[]
array. Fix this by checking for this condition, and defaulting to
single transfer 'bursts'.
Improve the readability of the loop using a for() loop rather than
a while() loop with the iterator initialized far from the loop.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 3da49ed..0809810 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1207,7 +1207,7 @@ static void dma_set_runtime_config(struct dma_chan *chan,
u32 cctl = 0;
/* Mask out all except src and dst channel */
u32 ccfg = cd->ccfg & 0x000003DEU;
- int i = 0;
+ int i;
/* Transfer direction */
plchan->runtime_direction = config->direction;
@@ -1250,18 +1250,17 @@ static void dma_set_runtime_config(struct dma_chan *chan,
/*
* Now decide on a maxburst:
- * If this channel will only request single transfers, set
- * this down to ONE element.
+ * If this channel will only request single transfers, set this
+ * down to ONE element. Also select one element if no maxburst
+ * is specified.
*/
- if (plchan->cd->single) {
+ if (plchan->cd->single || maxburst == 0) {
cctl |= (PL080_BSIZE_1 << PL080_CONTROL_SB_SIZE_SHIFT) |
(PL080_BSIZE_1 << PL080_CONTROL_DB_SIZE_SHIFT);
} else {
- while (i < ARRAY_SIZE(burst_sizes)) {
+ for (i = 0; i < ARRAY_SIZE(burst_sizes); i++)
if (burst_sizes[i].burstwords <= maxburst)
break;
- i++;
- }
cctl |= burst_sizes[i].reg;
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH 01/48] ARM: PL08x: fix spelling errors
From: Russell King - ARM Linux @ 2011-01-03 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103222943.GB4572@n2100.arm.linux.org.uk>
Correct mis-spellings in comments and printk strings.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/amba-pl08x.c | 37 +++++++++++++++++--------------------
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index b605cc9..3da49ed 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -19,7 +19,7 @@
* this program; if not, write to the Free Software Foundation, Inc., 59
* Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
- * The full GNU General Public License is iin this distribution in the
+ * The full GNU General Public License is in this distribution in the
* file called COPYING.
*
* Documentation: ARM DDI 0196G == PL080
@@ -82,7 +82,7 @@
/**
* struct vendor_data - vendor-specific config parameters
- * for PL08x derivates
+ * for PL08x derivatives
* @name: the name of this specific variant
* @channels: the number of channels available in this variant
* @dualmaster: whether this version supports dual AHB masters
@@ -96,10 +96,8 @@ struct vendor_data {
/*
* PL08X private data structures
- * An LLI struct - see pl08x TRM
- * Note that next uses bit[0] as a bus bit,
- * start & end do not - their bus bit info
- * is in cctl
+ * An LLI struct - see PL08x TRM. Note that next uses bit[0] as a bus bit,
+ * start & end do not - their bus bit info is in cctl.
*/
struct lli {
dma_addr_t src;
@@ -152,7 +150,7 @@ struct pl08x_driver_data {
/* Size (bytes) of each LLI buffer allocated for one transfer */
# define PL08X_LLI_TSFR_SIZE 0x2000
-/* Maximimum times we call dma_pool_alloc on this pool without freeing */
+/* Maximum times we call dma_pool_alloc on this pool without freeing */
#define PL08X_MAX_ALLOCS 0x40
#define MAX_NUM_TSFR_LLIS (PL08X_LLI_TSFR_SIZE/sizeof(struct lli))
#define PL08X_ALIGN 8
@@ -177,7 +175,7 @@ static int pl08x_phy_channel_busy(struct pl08x_phy_chan *ch)
/*
* Set the initial DMA register values i.e. those for the first LLI
- * The next lli pointer and the configuration interrupt bit have
+ * The next LLI pointer and the configuration interrupt bit have
* been set when the LLIs were constructed
*/
static void pl08x_set_cregs(struct pl08x_driver_data *pl08x,
@@ -366,8 +364,7 @@ static u32 pl08x_getbytes_chan(struct pl08x_dma_chan *plchan)
while (clli) {
bytes += get_bytes_in_cctl(llis_va[i].cctl);
/*
- * A clli of 0x00000000 will terminate the
- * LLI list
+ * A LLI pointer of 0 terminates the LLI list
*/
clli = llis_va[i].next;
i++;
@@ -469,7 +466,7 @@ static inline u32 pl08x_cctl_bits(u32 cctl, u8 srcwidth, u8 dstwidth,
{
u32 retbits = cctl;
- /* Remove all src, dst and transfersize bits */
+ /* Remove all src, dst and transfer size bits */
retbits &= ~PL080_CONTROL_DWIDTH_MASK;
retbits &= ~PL080_CONTROL_SWIDTH_MASK;
retbits &= ~PL080_CONTROL_TRANSFER_SIZE_MASK;
@@ -701,7 +698,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
* Choose bus to align to
* - prefers destination bus if both available
* - if fixed address on one bus chooses other
- * - modifies cctl to choose an apropriate master
+ * - modifies cctl to choose an appropriate master
*/
pl08x_choose_master_bus(&txd->srcbus, &txd->dstbus,
&mbus, &sbus, cctl);
@@ -775,7 +772,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
target_len = max_bytes_per_lli;
/*
- * Set bus lengths for incrementing busses
+ * Set bus lengths for incrementing buses
* to number of bytes which fill to next memory
* boundary
*/
@@ -826,7 +823,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
/*
* So now we know how many bytes to transfer
* to get to the nearest boundary
- * The next lli will past the boundary
+ * The next LLI will past the boundary
* - however we may be working to a boundary
* on the slave bus
* We need to ensure the master stays aligned
@@ -884,7 +881,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
&& (remainder); j++) {
cctl = pl08x_cctl_bits(cctl, 1, 1, 1);
dev_vdbg(&pl08x->adev->dev,
- "%s align with boundardy, single byte (remain %08x)\n",
+ "%s align with boundary, single byte (remain %08x)\n",
__func__, remainder);
num_llis =
pl08x_fill_lli_for_desc(pl08x,
@@ -907,7 +904,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
while (remainder) {
cctl = pl08x_cctl_bits(cctl, 1, 1, 1);
dev_vdbg(&pl08x->adev->dev,
- "%s align with boundardy, single odd byte (remain %d)\n",
+ "%s align with boundary, single odd byte (remain %d)\n",
__func__, remainder);
num_llis = pl08x_fill_lli_for_desc(pl08x, txd, num_llis,
1, cctl, &remainder);
@@ -1367,8 +1364,8 @@ static int pl08x_prep_channel_resources(struct pl08x_dma_chan *plchan,
* available to handle it whereas slave transfers may
* have been denied due to platform channel muxing restrictions
* and since there is no guarantee that this will ever be
- * resolved, and since the signal must be aquired AFTER
- * aquiring the physical channel, we will let them be NACK:ed
+ * resolved, and since the signal must be acquired AFTER
+ * acquiring the physical channel, we will let them be NACK:ed
* with -EBUSY here. The drivers can alway retry the prep()
* call if they are eager on doing this using DMA.
*/
@@ -1620,7 +1617,7 @@ static void pl08x_ensure_on(struct pl08x_driver_data *pl08x)
val = readl(pl08x->base + PL080_CONFIG);
val &= ~(PL080_CONFIG_M2_BE | PL080_CONFIG_M1_BE | PL080_CONFIG_ENABLE);
- /* We implictly clear bit 1 and that means little-endian mode */
+ /* We implicitly clear bit 1 and that means little-endian mode */
val |= PL080_CONFIG_ENABLE;
writel(val, pl08x->base + PL080_CONFIG);
}
@@ -2160,7 +2157,7 @@ static int __init pl08x_init(void)
retval = amba_driver_register(&pl08x_amba_driver);
if (retval)
printk(KERN_WARNING DRIVER_NAME
- "failed to register as an amba device (%d)\n",
+ "failed to register as an AMBA device (%d)\n",
retval);
return retval;
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH 00/48] PL08x DMA
From: Russell King - ARM Linux @ 2011-01-03 22:29 UTC (permalink / raw)
To: linux-arm-kernel
Here's the current state of play with the PL08x driver - a massive 48
patches. The diffstat doesn't look too impresive:
drivers/dma/amba-pl08x.c | 1040 +++++++++++++++++++++-----------------------
include/linux/amba/pl08x.h | 56 ++--
2 files changed, 520 insertions(+), 576 deletions(-)
except that the two files comprise some 2300 lines, so this covers
about a quarter of the driver.
The obvious fixes come first in the series, followed by the simpler
changes, gradually progressing towards more and more invasive stuff.
One thing I really don't like are APIs where a lock is held across two
calls - especially when it can be easily worked around. Patches 45
and 46 which sort this are intentionally towards the end.
Another thing to point out is that platforms can now control which
buses the PL08x uses for transfers for memory, peripherals, etc.
The logic in pl08x_select_bus() is intentionally non-symetric to
prevent both source and destination transfers ending up on the same
bus when both are available. However, the logic is only well
defined for non-zero values of the source and destination bus masks:
src dst M1 M2
01 01 SRC+DST
01 10 SRC DST
01 11 SRC DST
10 01 DST SRC
10 10 SRC+DST
10 11 DST SRC
11 01 DST SRC
11 10 SRC DST
11 11 SRC DST
(src/dst bit0 = M1 available, bit1 = M2 available)
If they happen to be zero, then the result is:
src dst M1 M2
00 00 SRC+DST
00 01 DST SRC
00 10 SRC+DST
00 11 DST SRC
01 00 SRC DST
10 00 SRC+DST
11 00 SRC+DST
so not quite what would be expected - so don't have zero bus masks.
^ permalink raw reply
* [PATCH v11 0/6] Add Omapl138-Hawkboard support
From: Kevin Hilman @ 2011-01-03 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024806D75D@dbde02.ent.ti.com>
"Nori, Sekhar" <nsekhar@ti.com> writes:
> Hi Victor,
>
> On Tue, Dec 28, 2010 at 04:13:07, vm.rod25 at gmail.com wrote:
>> From: Victor Rodriguez <vm.rod25@gmail.com>
>>
>> This patch adds
>> EMAC, EDMA, MMC/SD and USB OHCI
>> support for the Hawkboard-L138 system
>> It is under the machine name "omapl138_hawkboard".
>> This system is based on the da850 davinci CPU architecture.
>
> These 6 patches look good to me. Thanks for your work on this.
>
> For all the 6 patches:
>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
>
OK, queuing these for the 2.6.39 merge window.
Kevin
^ permalink raw reply
* [PATCH 2/2] arm/pxa: buildfix for pam27x without fb
From: Marek Vasut @ 2011-01-03 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=mtu3VibUR5SC+GmsmJCwo-nN9=eoTmzUE9jS8@mail.gmail.com>
On Monday 03 January 2011 16:57:27 Eric Miao wrote:
> On Thu, Dec 30, 2010 at 4:33 AM, Sebastian Andrzej Siewior
>
> <bigeasy@linutronix.de> wrote:
> > |arch/arm/mach-pxa/palmld.c: In function ?palmld_init?:
> > |arch/arm/mach-pxa/palmld.c:330: error: ?palm_320x480_lcd_mode?
> > |undeclared (first use in this function) arch/arm/mach-pxa/palmld.c:330:
> > |error: (Each undeclared identifier is reported only once
> > |arch/arm/mach-pxa/palmld.c:330: error: for each function it appears
> > |in.)
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> Marek,
>
> I need your ack please.
I don't like it being done with preprocessor macro. Maybe we should rather pull
palm_320x320_new_lcd_mode and others outside the #if defined() ?
>
> > ---
> > arch/arm/mach-pxa/include/mach/palm27x.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h
> > b/arch/arm/mach-pxa/include/mach/palm27x.h index 0a5e5ea..7b7927c 100644
> > --- a/arch/arm/mach-pxa/include/mach/palm27x.h
> > +++ b/arch/arm/mach-pxa/include/mach/palm27x.h
> > @@ -34,7 +34,7 @@ extern struct pxafb_mode_info
> > palm_320x320_new_lcd_mode; extern void __init palm27x_lcd_init(int
> > power,
> > struct pxafb_mode_info *mode);
> > #else
> > -static inline void palm27x_lcd_init(int power, struct pxafb_mode_info
> > *mode) {} +#define palm27x_lcd_init(power, mode) do { } while (0)
> > #endif
> >
> > #if defined(CONFIG_USB_GADGET_PXA27X) || \
> > --
> > 1.7.3.2
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Uwe Kleine-König @ 2011-01-03 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101230191846.GB14221@pengutronix.de>
On Thu, Dec 30, 2010 at 08:18:46PM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Dec 30, 2010 at 12:59:52PM -0500, Trond Myklebust wrote:
> > What filesystem are you exporting on the server? What is the NFS
> > version? Is this nfsroot, autofs or an ordinary nfs mount?
> This is an nfsroot of /home/ukl/nfsroot/tx28 which is a symlink to a
> directory on a different partition. I don't know the filesystem of my
> homedir as it resides on a server I have no access to, but I asked the
> admin, so I can follow up with this info later (I'd suspect ext3, too).
Yes, it is ext3.
> The real root directory is on ext3 (rw,noatime).
>
> The serving nfs-server is Debian's nfs-kernel-server 1:1.2.2-1.
If that matters, kernel is linux-image-2.6.32-5-amd64 (2.6.32-29)
provided by Debian.
> I don't
> know if testing that further would help or just waste of my time, so
> please let me know if I can help you and how.
This still applies
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* dmaengine: fix dma_unmap (was: Re: [PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081 PrimeCells)
From: Dan Williams @ 2011-01-03 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103165227.GC32508@n2100.arm.linux.org.uk>
On Mon, Jan 3, 2011 at 8:52 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 03, 2011 at 08:36:00AM -0800, Dan Williams wrote:
>> For raid this will have implications for architectures that split
>> operation types on to different physical channels. ?Preparing the
>> entire operation chain ahead of time is not possible on such
>> configuration because we need to remap the buffers for each channel
>> transition.
>
> That's not entirely true. ?You will only need to remap buffers if
> old_chan->device != new_chan->device, as the underlying struct device
> will be the different and could possibly have a different IOMMU or
> DMA-able memory parameters.
>
Yes, but currently operation capabilities are organized per dma device
(i.e. all channels on a dma device share the same set of
capabilities). The channel allocator will keep the chain on a single
channel where possible, but if it determines we need to switch to a
channel with a different capability set then we have also switched dma
devices at that point.
iop3xx and ppc4xx have this dma_device-per-dma_chan
organization.currently. They could switch to a model of hiding
multiple hw channels behind a single dma_chan, but then they would
need to handle the operation ordering and channel transitions
internally.
> So, when changing channels, the optimization is not engine specific,
> but can be effected when the chan->device points to the same dma_device
> structure. ?That means it should still be possible to chain several
> operations together, even if it means that they occur on different
> channels on the same device.
>
> One passing idea is the async_* operations need to chain buffers in
> terms of <virtual page+offset, len, dma_addr_t, struct dma_device *>, or
> maybe <struct dma_device *, scatterlist>. ?If the dma_device pointer is
> initialized, the scatterlist is already mapped. ?If this differs from
> the dma_device for the next selected operation, the previous operations
> need to be run, then unmap and remap for the new device.
>
> Does that sound possible?
Yes, but the dma driver still does not have enough information to
determine when it is finally safe to unmap / allow speculative reads.
The raid driver can make a much cleaner guarantee of "this stripe now
belongs to a dma device" and "all dma operations have completed this
stripe can be returned to the cpu / rescheduled on a new channel".
>> > I'd also like to see DMA_COMPL_SKIP_*_UNMAP always set by prep_slave_sg()
>> > in tx->flags so we don't have to end up with "is this a slave operation"
>> > tests in the completion handler.
>>
>> Longer term I do not see these flags surviving, but yes a 2.6.38
>> change along these lines makes sense.
>
> Well, if the idea is to kill those flags, then it would be a good idea
> not to introduce new uses of them as that'll only complicate matters.
>
> I do have an untested patch which adds the unmap to pl08x, but I'm
> wondering if it's worth it, or whether to disable the memcpy support
> for the time being.
We could disable the driver if NET_DMA or ASYNC_TX_DMA are selected.
That still allows the driver to be exercised with dmatest. Although
I notice the driver is already marked experimental, do we need
something stronger for 37-final?
--
Dan
^ permalink raw reply
* Git pull request: ux500-core for the v2.6.38 merge window
From: Linus Walleij @ 2011-01-03 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110102235920.GC17727@n2100.arm.linux.org.uk>
2011/1/3 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Dec 29, 2010 at 01:59:09AM +0100, Linus Walleij wrote:
>>
>> This brings in everything except the 5 patches from Rabin
>> that require the GIC+SMP changes. I've frozen that tree
>> until you pull it.
>
> And this is what I get. ?As you didn't provide me with a diffstat, I
> won't push this out until you've confirmed that the following diffstat
> from the merge is correct in case there's a problem.
This looks correct and corresponds to what's been pending in
the -next tree, thanks Russell.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Felipe Balbi @ 2011-01-03 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103171945.GA3839@n2100.arm.linux.org.uk>
Hi,
On Mon, Jan 03, 2011 at 05:19:45PM +0000, Russell King - ARM Linux wrote:
>> Frankly speaking, I doubt that drivers/dma/ will have place for the
>> purely MUSB specific DMA engines such as the named ones (there's no TUSB
>> DMA BTW -- it uses OMAP DMA).
>
>Long term, we need to kill off all these platform private DMA interfaces.
>There's a growing amount of IP that's being shared not only between ARM
>silicon vendors, but also across architectures, and having to re-implement
>drivers because the underlying DMA engine is different is not feasible.
>
>For example, we're seeing ARMs primecells being used with various
>different DMA controllers in various different ARM SoCs. I've heard
>rumours of them appearing in MIPS or PPC stuff as well. We're seeing
>PXA peripheral IP appearing in x86 stuff too.
>
>We can't have drivers tied to their SoC DMA engines, and we can't continue
>having SoC DMA engines implementing their own unique APIs. We do need to
>get on top of this before it becomes a major problem (if it hasn't
>already).
>
>The DMA engine API is still evolving, and should not be taken as concrete
>- I've recently been bringing up a number of points with Dan on various
>aspects of the API, some of which ultimately will lead to changes to the
>async-tx API, and others which hopefully will mean that the DMA slave
>API is better documented.
I couldn't agree more with you Russell. If the API isn't enough
currently, we can always propose an extension.
Having all sorts of SoC-specific "APIs" has already caused enough
problems and it still does (non-generic IRQ handling on
twl?030, menelaus, cbus - which isn't in mainline yet -, etc,
non-generic McBSP usage, non-generic GPMC usage, etc etc). So, if we can
plan for making use of generic APIs, let's do so.
--
balbi
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Felipe Balbi @ 2011-01-03 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404BD3F2C58@dbde02.ent.ti.com>
Hi,
On Mon, Jan 03, 2011 at 10:45:35PM +0530, Gupta, Ajay Kumar wrote:
>> > Moreover, even Felipe also seems to move other musb
>> > DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.
>>
>> Frankly speaking, I doubt that drivers/dma/ will have place for the
>> purely MUSB specific DMA engines such as the named ones (there's no TUSB
>> DMA BTW it uses OMAP DMA).
>I think we will get more clarity once we start on this activity.
I agree, but I personally don't see that many limiting factors.
dmaengine is just a generic API for doing DMA transfers. If it's not
enough for us currently, we extend it.
--
balbi
^ permalink raw reply
* [PATCH] ARM: imx/mx27_3ds: Add PMIC support
From: Uwe Kleine-König @ 2011-01-03 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294060599-30309-1-git-send-email-fabio.estevam@freescale.com>
Hello,
On Mon, Jan 03, 2011 at 11:16:39AM -0200, Fabio Estevam wrote:
> MX27_3DS board has a MC13783 PMIC connected to the CSPI2 port.
>
> Add support for the PMIC.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm/mach-imx/mach-mx27_3ds.c | 77 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 78 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0449b80..17d2e60 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -242,6 +242,7 @@ config MACH_MX27_3DS
> select IMX_HAVE_PLATFORM_IMX_UART
> select IMX_HAVE_PLATFORM_MXC_EHCI
> select IMX_HAVE_PLATFORM_MXC_MMC
> + select IMX_HAVE_PLATFORM_SPI_IMX
> select MXC_ULPI if USB_ULPI
> help
> Include support for MX27PDK platform. This includes specific
> diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
> index 0ee7a73..6fd0f8f 100644
> --- a/arch/arm/mach-imx/mach-mx27_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx27_3ds.c
> @@ -26,6 +26,9 @@
> #include <linux/usb/otg.h>
> #include <linux/usb/ulpi.h>
> #include <linux/delay.h>
> +#include <linux/mfd/mc13783.h>
> +#include <linux/spi/spi.h>
> +#include <linux/regulator/machine.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> @@ -39,6 +42,7 @@
>
> #define SD1_EN_GPIO (GPIO_PORTB + 25)
> #define OTG_PHY_RESET_GPIO (GPIO_PORTB + 23)
> +#define SPI2_SS0 (GPIO_PORTD + 21)
>
> static const int mx27pdk_pins[] __initconst = {
> /* UART1 */
> @@ -87,6 +91,10 @@ static const int mx27pdk_pins[] __initconst = {
> PE2_PF_USBOTG_DIR,
> PE24_PF_USBOTG_CLK,
> PE25_PF_USBOTG_DATA7,
> + /* CSPI2 */
> + PD22_PF_CSPI2_SCLK,
> + PD23_PF_CSPI2_MISO,
> + PD24_PF_CSPI2_MOSI,
> };
>
> static const struct imxuart_platform_data uart_pdata __initconst = {
> @@ -176,6 +184,72 @@ static int __init mx27_3ds_otg_mode(char *options)
> }
> __setup("otg_mode=", mx27_3ds_otg_mode);
>
> +/* Regulators */
> +static struct regulator_consumer_supply vmmc1_consumers[] = {
> + REGULATOR_SUPPLY("lcd_2v8", NULL),
> +};
> +
> +static struct regulator_init_data vmmc1_init = {
> + .constraints = {
> + .min_uV = 2800000,
> + .max_uV = 2800000,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(vmmc1_consumers),
> + .consumer_supplies = vmmc1_consumers,
> +};
> +
> +static struct regulator_consumer_supply vgen_consumers[] = {
> + REGULATOR_SUPPLY("vdd_lcdio", NULL),
> +};
> +
> +static struct regulator_init_data vgen_init = {
> + .constraints = {
> + .min_uV = 1800000,
> + .max_uV = 1800000,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(vgen_consumers),
> + .consumer_supplies = vgen_consumers,
> +};
> +
> +static struct mc13783_regulator_init_data mx27_3ds_regulators[] = {
> + {
> + .id = MC13783_REGU_VMMC1,
> + .init_data = &vmmc1_init,
> + }, {
> + .id = MC13783_REGU_VGEN,
> + .init_data = &vgen_init,
> + },
> +};
> +
> +/* MC13783 */
> +static struct mc13783_platform_data mc13783_pdata __initdata = {
> + .regulators = mx27_3ds_regulators,
> + .num_regulators = ARRAY_SIZE(mx27_3ds_regulators),
> + .flags = MC13783_USE_REGULATOR,
> +};
> +
> +/* SPI */
> +static int spi2_internal_chipselect[] = {SPI2_SS0};
I didn't check what CodingStyle says here, but I'd say
... = { SPI2_SS0 };
(and maybe add a comma between 0 and }).
> +
> +static const struct spi_imx_master spi2_pdata __initconst = {
> + .chipselect = spi2_internal_chipselect,
> + .num_chipselect = ARRAY_SIZE(spi2_internal_chipselect),
> +};
> +
> +static struct spi_board_info mx27_3ds_spi_devs[] __initdata = {
> + {
> + .modalias = "mc13783",
> + .max_speed_hz = 1000000,
> + .bus_num = 1,
> + .chip_select = 0, /* SS0 */
> + .platform_data = &mc13783_pdata,
> + .irq = IRQ_GPIOC(14),
> + .mode = SPI_CS_HIGH,
> + },
> +};
> +
>
> static void __init mx27pdk_init(void)
> {
> @@ -199,6 +273,9 @@ static void __init mx27pdk_init(void)
> if (!otg_mode_host)
> imx27_add_fsl_usb2_udc(&otg_device_pdata);
>
> + imx27_add_spi_imx1(&spi2_pdata);
> + spi_register_board_info(mx27_3ds_spi_devs,
> + ARRAY_SIZE(mx27_3ds_spi_devs));
> }
>
> static void __init mx27pdk_timer_init(void)
Other than that I looks OK for me.
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: sched_clock: improve mult/shift accuracy with high frequency clocks
From: john stultz @ 2011-01-03 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101022004230.16090@xanadu.home>
On Sun, 2011-01-02 at 20:21 -0500, Nicolas Pitre wrote:
> On Mon, 3 Jan 2011, Russell King - ARM Linux wrote:
>
> > On Wed, Dec 29, 2010 at 08:31:58PM -0500, Nicolas Pitre wrote:
> > > On Tue, 21 Dec 2010, Russell King - ARM Linux wrote:
> > >
> > > > On Mon, Dec 20, 2010 at 08:21:41PM -0500, Nicolas Pitre wrote:
> > > > >
> > > > > The minsec argument to clocks_calc_mult_shift() [ which appears to be
> > > > > misnamed by the way ] is used to clamp the magnitude of the mult factor
> > > > > so that the given range won't overflow a 64 bit result. The mult factor
> > > > > is itself already limited to a maximum of 32 bits. Given that the largest
> > > > > clock tick range we may have is also 32 bits, there is no way our usage of
> > > > > any computed mult factor would ever overflow 64 bits.
> > > > >
> > > > > The choice of 60 seconds here for minsec is rather arbitrary. If the
> > > > > mult factor wasn't already limited to 32 bits, this value of 60 would
> > > > > create overflows for clocks which take more than 60 seconds to wrap.
> > > >
> > > > 60 seconds was arbitary, chosen from the selection of clock rates which
> > > > I had available at the time (the highest of which was 24MHz).
> > >
> > > Fair enough. It is just not universally optimal given the different
> > > clock ranges this code now covers.
> > >
> > > > > And for clocks which take less than 60 seconds to wrap then we do lose
> > > > > precision as the mult factor is made smaller (fewer bits) to be adjusted
> > > > > to a range which is larger than what we actually use. This currently
> > > > > affects clocks faster than 71MHz.
> > > > >
> > > > > We could use minsec = 0 instead of 60 and a good 32-bit mult factor would
> > > > > be computed in all cases. But let's be formal and provide the actual
> > > > > range to clocks_calc_mult_shift(). None of the cyc_to_fixed_sched_clock()
> > > > > users are affected as they all are using clocks < 71MHz.
> > > >
> > > > Maybe __clocksource_updatefreq_scale() needs a similar fix too, instead
> > > > of assuming 5 seconds? It also has access to the mask and rate.
> > >
> > > There is a comment to that effect right above the
> > > clocks_calc_mult_shift() indicating that this is a known issue in that
> > > case already.
> > >
> > > And looking at that code, it appears that there is a balance to be made
> > > between cs->max_idle_ns and cs->mult, the former currently being
> > > determined by the later. But if cs->mult is maximized to 32 bits, that
> > > leaves only 31 bits for cs->max_idle_ns which corresponds to approx 2
> > > seconds only.
> > >
> > > So this is not clear to me what would be the optimal mult/shift values
> > > in the __clocksource_updatefreq_scale() context, while this is rather
> > > obvious in the init_sched_clock() context. Hence this patch.
> >
> > As clocksources are about precision (I believe it has been stated so in
> > the past) it seems that fudging the shift and multiplier to get an
> > extended period out of the clock is not the correct approach.
> >
> > Maybe Thomas or John can shed some light on this?
>
> Sure. My current understanding is that the core might be trying to play
> it safe as the mult and shift factors used to be provided by each clock
> source drivers, and they were often the result of some guessing from the
> authors of those drivers. Now that those factors are programmatically
> determined via the clocksource_register_khz interface (is this the case
> for them all?) then it should be possible to tighten that code a bit and
> make it optimal.
Its not yet the case for all clocksources, I've had some trouble getting
arch maintainers to pick up the conversion patches I've sent out so far
(Russell jumped in and did the arm conversion for me, which lightens my
load dramatically, so thanks again for that!).
And yes, the consolidation was done as I was seeing a lot of mult/shift
copy-pasta in clocksources (which is my fault, as the advice on how to
calculate it was poor), and as idle time lengths are growing I saw a
potential hazard of breaking platforms as idle lengths grow, or users
being frustrated that one platform might seemingly use more power then
another due to the mult/shift pair needlessly limiting it.
So the consolidation is mainly just to get the expectations unified and
make it so changes don't have to be done on a clocksource by clocksource
basis.
thanks
-john
^ permalink raw reply
* ks8695_gettimeoffset
From: avictor.za at gmail.com @ 2011-01-03 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D18B2B5.5000001@visionsystems.de>
hi,
> Is it possible at all to implement clocksource/clockevents for KS8695? As Dick and "Register Description" already said you cannot read the time register, so clocksource->read cannot be implemented to return ticks elapsed. Or do I see it wrong?
I'm pretty sure I tested this when I originally submitted the KS8685
processor support (May 2007), and the timer registers are readable.
I would of tested with a userspace program that sat in a tight loop
calling gettimeofday().
Regards,
Andrew Victor
^ permalink raw reply
* [PATCH] ARM: sched_clock: improve mult/shift accuracy with high frequency clocks
From: john stultz @ 2011-01-03 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103003718.GF17727@n2100.arm.linux.org.uk>
On Mon, 2011-01-03 at 00:37 +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 29, 2010 at 08:31:58PM -0500, Nicolas Pitre wrote:
> > On Tue, 21 Dec 2010, Russell King - ARM Linux wrote:
> >
> > > On Mon, Dec 20, 2010 at 08:21:41PM -0500, Nicolas Pitre wrote:
> > > >
> > > > The minsec argument to clocks_calc_mult_shift() [ which appears to be
> > > > misnamed by the way ] is used to clamp the magnitude of the mult factor
> > > > so that the given range won't overflow a 64 bit result. The mult factor
> > > > is itself already limited to a maximum of 32 bits. Given that the largest
> > > > clock tick range we may have is also 32 bits, there is no way our usage of
> > > > any computed mult factor would ever overflow 64 bits.
> > > >
> > > > The choice of 60 seconds here for minsec is rather arbitrary. If the
> > > > mult factor wasn't already limited to 32 bits, this value of 60 would
> > > > create overflows for clocks which take more than 60 seconds to wrap.
> > >
> > > 60 seconds was arbitary, chosen from the selection of clock rates which
> > > I had available at the time (the highest of which was 24MHz).
> >
> > Fair enough. It is just not universally optimal given the different
> > clock ranges this code now covers.
> >
> > > > And for clocks which take less than 60 seconds to wrap then we do lose
> > > > precision as the mult factor is made smaller (fewer bits) to be adjusted
> > > > to a range which is larger than what we actually use. This currently
> > > > affects clocks faster than 71MHz.
> > > >
> > > > We could use minsec = 0 instead of 60 and a good 32-bit mult factor would
> > > > be computed in all cases. But let's be formal and provide the actual
> > > > range to clocks_calc_mult_shift(). None of the cyc_to_fixed_sched_clock()
> > > > users are affected as they all are using clocks < 71MHz.
> > >
> > > Maybe __clocksource_updatefreq_scale() needs a similar fix too, instead
> > > of assuming 5 seconds? It also has access to the mask and rate.
> >
> > There is a comment to that effect right above the
> > clocks_calc_mult_shift() indicating that this is a known issue in that
> > case already.
> >
> > And looking at that code, it appears that there is a balance to be made
> > between cs->max_idle_ns and cs->mult, the former currently being
> > determined by the later. But if cs->mult is maximized to 32 bits, that
> > leaves only 31 bits for cs->max_idle_ns which corresponds to approx 2
> > seconds only.
> >
> > So this is not clear to me what would be the optimal mult/shift values
> > in the __clocksource_updatefreq_scale() context, while this is rather
> > obvious in the init_sched_clock() context. Hence this patch.
>
> As clocksources are about precision (I believe it has been stated so in
> the past) it seems that fudging the shift and multiplier to get an
> extended period out of the clock is not the correct approach.
>
> Maybe Thomas or John can shed some light on this?
Right, so there's conflicting goals of long idle times and fine-grained
time accuracy that pull the clocksource mult/shift pair calculation in
different directions.
Originally, the advice was pick a mult/shift pair that allows for a few
seconds of time to accrue before we overflow. However this was a little
vague and as the number of clocksources grew, and the desired idle times
were increasing, I started to see that the lack of consistency was
going to give us troubles.
So the clocksource_register_hz/khz interfaces try to consolidate that
decision into one place, utilizing the MAX_UPDATE_LENGTH value
(currently 5 seconds) as the max idle time. Clocksource driver writers
don't have to worry about making the correct decision, the kernel should
do it for you.
Now, at some point I expect folks to get grumpy about the max idle time
being limited to 5 seconds, and we'll have to either push it out for
everyone (at the cost of less accurate NTP steering), or make it a
architecture specific config option.
Now, for sched_clock, there are a different set of expectations with
regards to accuracy and expected idle times, and we'll probably need a
similar consolidation effort to make sure the mult/shift calculations
are correct and the resulting limits are taken into account by the
scheduler when going into NOHZ mode.
thanks
-john
^ permalink raw reply
* [PATCH] OMAP3+: sr_device: include pm header
From: Nishanth Menon @ 2011-01-03 19:35 UTC (permalink / raw)
To: linux-arm-kernel
omap_enable_smartreflex_on_init is meant to be used by boards
which would like to have SR enabled by default on the platform, while
omap_devinit_smartreflex is used by pm code, the protos are defined
in pm.h. This header should be included to ensure that sr_device
function definitions match the prototypes.
including pm.h fixes the sparse warnings (with CONFIG_OMAP_SMARTREFLEX=y):
arch/arm/mach-omap2/sr_device.c:138:13: warning: symbol 'omap_enable_smartreflex_on_init' was not declared. Should it be static?
arch/arm/mach-omap2/sr_device.c:143:12: warning: symbol 'omap_devinit_smartreflex' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
branch: omap-for-linus
arch/arm/mach-omap2/sr_device.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 786d685..b1e0af1 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -27,6 +27,7 @@
#include <plat/voltage.h>
#include "control.h"
+#include "pm.h"
static bool sr_enable_on_init;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] OMAP2+: TWL: include pm header for init protos
From: Nishanth Menon @ 2011-01-03 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294081110-23695-1-git-send-email-nm@ti.com>
twl_init functions are declared in pm.h and used in pm.c
pm.h header defining the protos need to be included to
ensure that omap_twl.c has consistent function definition.
This fixes sparse warning:
arch/arm/mach-omap2/omap_twl.c:237:12: warning: symbol 'omap4_twl_init' was not declared. Should it be static?
arch/arm/mach-omap2/omap_twl.c:256:12: warning: symbol 'omap3_twl_init' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/omap_twl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 65ab4e3..00e1d2b 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -20,6 +20,8 @@
#include <plat/voltage.h>
+#include "pm.h"
+
#define OMAP3_SRI2C_SLAVE_ADDR 0x12
#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
#define OMAP3_VDD_CORE_SR_CONTROL_REG 0x01
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] OMAP2+: TWL: make conversion routines static
From: Nishanth Menon @ 2011-01-03 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294081110-23695-1-git-send-email-nm@ti.com>
The uv_to_vsel, vsel_to_uv functions don't need to be exposed to the
world as they are used as function pointers. make them static.
Fixes sparse warnings:
arch/arm/mach-omap2/omap_twl.c:63:15: warning: symbol 'twl4030_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/omap_twl.c:68:4: warning: symbol 'twl4030_uv_to_vsel' was not declared. Should it be static?
arch/arm/mach-omap2/omap_twl.c:73:15: warning: symbol 'twl6030_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/omap_twl.c:105:4: warning: symbol 'twl6030_uv_to_vsel' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/omap_twl.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 15f8c6c..65ab4e3 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -60,17 +60,17 @@ static u8 smps_offset;
#define REG_SMPS_OFFSET 0xE0
-unsigned long twl4030_vsel_to_uv(const u8 vsel)
+static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
return (((vsel * 125) + 6000)) * 100;
}
-u8 twl4030_uv_to_vsel(unsigned long uv)
+static u8 twl4030_uv_to_vsel(unsigned long uv)
{
return DIV_ROUND_UP(uv - 600000, 12500);
}
-unsigned long twl6030_vsel_to_uv(const u8 vsel)
+static unsigned long twl6030_vsel_to_uv(const u8 vsel)
{
/*
* In TWL6030 depending on the value of SMPS_OFFSET
@@ -102,7 +102,7 @@ unsigned long twl6030_vsel_to_uv(const u8 vsel)
return ((((vsel - 1) * 125) + 6000)) * 100;
}
-u8 twl6030_uv_to_vsel(unsigned long uv)
+static u8 twl6030_uv_to_vsel(unsigned long uv)
{
/*
* In TWL6030 depending on the value of SMPS_OFFSET
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox