* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-12 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=vMchmiz70evBB5bPqt4O4DWUocd5M1o9gc8fsY_Fkiw@mail.gmail.com>
On 20:22 Fri 12 Oct , Viresh Kumar wrote:
> On 12 October 2012 20:18, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> >> static struct of_dev_auxdata spear1310_auxdata_lookup[] __initdata = {
> >> - OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, &cf_dma_priv),
> >> - OF_DEV_AUXDATA("snps,dma-spear1340", DMAC0_BASE, NULL, &dmac_plat_data),
> >> - OF_DEV_AUXDATA("snps,dma-spear1340", DMAC1_BASE, NULL, &dmac_plat_data),
> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, "cf"),
> > ?/
>
> Sorry. can't get it :(
what is the "cf" as paltfrom data
Best Regards,
J.
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-12 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpomvCkzSuP1GLBXmDTRCHeKXDgGwwXQ+TzU=Jekmozzo=A@mail.gmail.com>
On 20:25 Fri 12 Oct , Viresh Kumar wrote:
> On 12 October 2012 20:20, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 20:01 Fri 12 Oct , Viresh Kumar wrote:
> >> dw_dmac driver already supports device tree but it used to have its platform
> >> data passed the non-DT way.
> >>
> >> This patch does following changes:
> >> - pass platform data via DT, non-DT way still takes precedence if both are used.
> > why keep it all platform are DT
>
> I would love to remove that, but not sure if somebody want's the non-DT
> way too.
>
> I didn't wanted to get into fixing user SoCs of this driver.
no drop it at the mailine if do not need it
Best Regads,
J.
^ permalink raw reply
* alignment faults in 3.6
From: Ben Hutchings @ 2012-10-12 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7041@saturn3.aculab.com>
On Fri, 2012-10-12 at 16:47 +0100, David Laight wrote:
> > AC was so useless that it has now been reallocated to use by SMAP
> > <https://lwn.net/Articles/517251/>.
>
> That is a long time coming!
> Wonder when it will appear in any cpus.
>
> How am I going to get root access when I can't get the kernel
> to execute code at address 0 any more :-)
Moving further off the topic: that is supposed to be prevented by a
separate feature, SMEP, which I think is available in current Intel CPUs
(Ivy Bridge). Also, unprivileged users are generally not permitted to
mmap() at address 0.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Jason Cooper @ 2012-10-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012165919.0dd085dd@skate>
On Fri, Oct 12, 2012 at 04:59:19PM +0200, Thomas Petazzoni wrote:
> Jason,
>
> On Fri, 12 Oct 2012 10:31:31 -0400, Jason Cooper wrote:
>
> > I agree with Francois on most of these. I prefer readability over
> > hard 80 column limits.
>
> Sure, but checkpatch.pl is warning on every line exceeding the 80
> columns. Not that I think that all checkpatch.pl warnings should
> necessarily be religiously respected, but if you have gazillions of
> warnings regarding line exceeding 80 columns, it is very likely that
> you will miss more important warnings.
./scripts/checkpatch.pl --ignore LONG_LINE ...
Will yield the 'more important' warnings/errors. After those are
cleared, you can run without --ignore to check for over-indentation,
etc.
> > Although, 80 columns is still sound
> > guidance. For example, a majority of the broken lines are due to
> > long macro and constant names. I did a 'git grep NETA' and didn't
> > see anything alarming. So, above could become
> >
> > val |= rx_filled << NETA_RXQ_ADD_NONOCC_SHIFT;
>
> I don't mind, but then I would like to keep things consistent:
>
> * The driver file would be neta.c
>
> * All functions and data structure would be prefixed neta_ and not
> mvneta_
>
> * The Kconfig option would become CONFIG_NETA. Do we really want such
> a "simple" Kconfig option name for a driver?
Well, you could do mv_neta.c and CONFIG_MV_NETA, but at the end of the
day, we were both trying to put lipstick on a pig. Your last paragraph
is the most important.
> Maybe the fact that those long macros are making long lines is also due
> to the code having sometimes a too deep indentation, and I need to fix
> that by using more auxiliary functions or something like that?
This is the intent of the 80 column warning. Please review the patch
for over-indentation, and consider shortening the macros, eg
MVNETA_RXQ_ADD_NONOCC_SHFT.
thx,
Jason.
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VdNVyWxvnHDFjg_5vC95M_LwJYUDLQb+NmBA6GRVsea9g@mail.gmail.com>
On 12 October 2012 21:23, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> 1. This is an equivalent of
> if (last_dw && (last_bus_id == ... ) && (last_dw == dw))
> return false;
> 2. In case dw is always non-NULL the last_dw == dw is false if last_dw is NULL.
>
> Where am I wrong?
Nowhere, I am drunk ;)
--
viresh
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Andy Shevchenko @ 2012-10-12 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohponS+mkj6rN6hzJC1FrbpSS+jWZBii4xQgN+4z2h=zFTWA@mail.gmail.com>
On Fri, Oct 12, 2012 at 6:18 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 12 October 2012 20:28, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> On Fri, 2012-10-12 at 20:01 +0530, Viresh Kumar wrote:
>
>>> + if (last_dw) {
>>> + if ((last_bus_id == param) && (last_dw == dw))
>>> + return false;
>>> + }
1. This is an equivalent of
if (last_dw && (last_bus_id == ... ) && (last_dw == dw))
return false;
2. In case dw is always non-NULL the last_dw == dw is false if last_dw is NULL.
Where am I wrong?
> You are already drunk.
Not yet, but tired.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* alignment faults in 3.6
From: David Laight @ 2012-10-12 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350054254.2819.3.camel@bwh-desktop.uk.solarflarecom.com>
> AC was so useless that it has now been reallocated to use by SMAP
> <https://lwn.net/Articles/517251/>.
That is a long time coming!
Wonder when it will appear in any cpus.
How am I going to get root access when I can't get the kernel
to execute code at address 0 any more :-)
^ permalink raw reply
* [PATCH] mmc: mmci: Fixup and cleanup code for DMA handling
From: Ulf Hansson @ 2012-10-12 15:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
The cookie is now used to indicate if dma_unmap_sg shall be
done in post_request. At DMA errors, the DMA job is immediately
not only terminated but also unmapped. To indicate that this
has been done the cookie is reset to zero. post_request will
thus only do dma_umap_sg for requests which has a cookie not set
to zero.
Some corresponding duplicated code could then be removed and
moreover some corrections at DMA errors for terminating the same
DMA job twice has also been fixed.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
---
I realize that this patch is quite extensive to review, but I could not
manage to simplify it further than this. Sorry for that.
Moreover you require the below patch, recently sent to the mmc-list as well,
be able to apply it.
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
---
drivers/mmc/host/mmci.c | 167 ++++++++++++++++++++++++-----------------------
1 file changed, 85 insertions(+), 82 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index ca6d128..3165808 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -383,10 +383,33 @@ static inline void mmci_dma_release(struct mmci_host *host)
host->dma_rx_channel = host->dma_tx_channel = NULL;
}
+static void mmci_dma_data_error(struct mmci_host *host)
+{
+ dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
+ dmaengine_terminate_all(host->dma_current);
+ host->dma_current = NULL;
+ host->dma_desc_current = NULL;
+ host->data->host_cookie = 0;
+}
+
static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
- struct dma_chan *chan = host->dma_current;
+ struct dma_chan *chan;
enum dma_data_direction dir;
+
+ if (data->flags & MMC_DATA_READ) {
+ dir = DMA_FROM_DEVICE;
+ chan = host->dma_rx_channel;
+ } else {
+ dir = DMA_TO_DEVICE;
+ chan = host->dma_tx_channel;
+ }
+
+ dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+}
+
+static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
+{
u32 status;
int i;
@@ -405,19 +428,12 @@ static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
* contiguous buffers. On TX, we'll get a FIFO underrun error.
*/
if (status & MCI_RXDATAAVLBLMASK) {
- dmaengine_terminate_all(chan);
- if (!data->error)
- data->error = -EIO;
- }
-
- if (data->flags & MMC_DATA_WRITE) {
- dir = DMA_TO_DEVICE;
- } else {
- dir = DMA_FROM_DEVICE;
+ data->error = -EIO;
+ mmci_dma_data_error(host);
}
if (!data->host_cookie)
- dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+ mmci_dma_unmap(host, data);
/*
* Use of DMA with scatter-gather is impossible.
@@ -427,16 +443,15 @@ static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
dev_err(mmc_dev(host->mmc), "buggy DMA detected. Taking evasive action.\n");
mmci_dma_release(host);
}
-}
-static void mmci_dma_data_error(struct mmci_host *host)
-{
- dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
- dmaengine_terminate_all(host->dma_current);
+ host->dma_current = NULL;
+ host->dma_desc_current = NULL;
}
-static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
- struct mmci_host_next *next)
+/* prepares DMA channel and DMA descriptor, returns non-zero on failure */
+static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
+ struct dma_chan **dma_chan,
+ struct dma_async_tx_descriptor **dma_desc)
{
struct variant_data *variant = host->variant;
struct dma_slave_config conf = {
@@ -454,16 +469,6 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
enum dma_data_direction buffer_dirn;
int nr_sg;
- /* Check if next job is already prepared */
- if (data->host_cookie && !next &&
- host->dma_current && host->dma_desc_current)
- return 0;
-
- if (!next) {
- host->dma_current = NULL;
- host->dma_desc_current = NULL;
- }
-
if (data->flags & MMC_DATA_READ) {
conf.direction = DMA_DEV_TO_MEM;
buffer_dirn = DMA_FROM_DEVICE;
@@ -497,30 +502,42 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
if (!desc)
goto unmap_exit;
- if (next) {
- next->dma_chan = chan;
- next->dma_desc = desc;
- } else {
- host->dma_current = chan;
- host->dma_desc_current = desc;
- }
+ *dma_chan = chan;
+ *dma_desc = desc;
return 0;
unmap_exit:
- if (!next)
- dmaengine_terminate_all(chan);
dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
return -ENOMEM;
}
+static inline int mmci_dma_prep_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ /* Check if next job is already prepared. */
+ if (host->dma_current && host->dma_desc_current)
+ return 0;
+
+ /* No job were prepared thus do it now. */
+ return __mmci_dma_prep_data(host, data, &host->dma_current,
+ &host->dma_desc_current);
+}
+
+static inline int mmci_dma_prep_next(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ struct mmci_host_next *nd = &host->next_data;
+ return __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc);
+}
+
static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
{
int ret;
struct mmc_data *data = host->data;
struct variant_data *variant = host->variant;
- ret = mmci_dma_prep_data(host, host->data, NULL);
+ ret = mmci_dma_prep_data(host, host->data);
if (ret)
return ret;
@@ -555,19 +572,11 @@ static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
{
struct mmci_host_next *next = &host->next_data;
- if (data->host_cookie && data->host_cookie != next->cookie) {
- pr_warning("[%s] invalid cookie: data->host_cookie %d"
- " host->next_data.cookie %d\n",
- __func__, data->host_cookie, host->next_data.cookie);
- data->host_cookie = 0;
- }
-
- if (!data->host_cookie)
- return;
+ WARN_ON(data->host_cookie && data->host_cookie != next->cookie);
+ WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
host->dma_desc_current = next->dma_desc;
host->dma_current = next->dma_chan;
-
next->dma_desc = NULL;
next->dma_chan = NULL;
}
@@ -582,22 +591,13 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
if (!data)
return;
- if (mmci_validate_data(host, mrq->data))
- return;
+ BUG_ON(data->host_cookie);
- if (data->host_cookie) {
- data->host_cookie = 0;
+ if (mmci_validate_data(host, data))
return;
- }
- /* if config for dma */
- if (((data->flags & MMC_DATA_WRITE) && host->dma_tx_channel) ||
- ((data->flags & MMC_DATA_READ) && host->dma_rx_channel)) {
- if (mmci_dma_prep_data(host, data, nd))
- data->host_cookie = 0;
- else
- data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
- }
+ if (!mmci_dma_prep_next(host, data))
+ data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
}
static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -605,29 +605,23 @@ static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
{
struct mmci_host *host = mmc_priv(mmc);
struct mmc_data *data = mrq->data;
- struct dma_chan *chan;
- enum dma_data_direction dir;
- if (!data)
+ if (!data || !data->host_cookie)
return;
- if (data->flags & MMC_DATA_READ) {
- dir = DMA_FROM_DEVICE;
- chan = host->dma_rx_channel;
- } else {
- dir = DMA_TO_DEVICE;
- chan = host->dma_tx_channel;
- }
+ mmci_dma_unmap(host, data);
+ if (err) {
+ struct mmci_host_next *next = &host->next_data;
+ struct dma_chan *chan;
+ if (data->flags & MMC_DATA_READ)
+ chan = host->dma_rx_channel;
+ else
+ chan = host->dma_tx_channel;
+ dmaengine_terminate_all(chan);
- /* if config for dma */
- if (chan) {
- if (err)
- dmaengine_terminate_all(chan);
- if (data->host_cookie)
- dma_unmap_sg(mmc_dev(host->mmc), data->sg,
- data->sg_len, dir);
- mrq->data->host_cookie = 0;
+ next->dma_desc = NULL;
+ next->dma_chan = NULL;
}
}
@@ -648,6 +642,11 @@ static inline void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
{
}
+static inline void mmci_dma_finalize(struct mmci_host *host,
+ struct mmc_data *data)
+{
+}
+
static inline void mmci_dma_data_error(struct mmci_host *host)
{
}
@@ -772,8 +771,10 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
u32 remain, success;
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
+ if (dma_inprogress(host)) {
mmci_dma_data_error(host);
+ mmci_dma_unmap(host, data);
+ }
/*
* Calculate how far we are into the transfer. Note that
@@ -812,7 +813,7 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
if (status & MCI_DATAEND || data->error) {
if (dma_inprogress(host))
- mmci_dma_unmap(host, data);
+ mmci_dma_finalize(host, data);
mmci_stop_data(host);
if (!data->error)
@@ -849,8 +850,10 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
if (!cmd->data || cmd->error) {
if (host->data) {
/* Terminate the DMA transfer */
- if (dma_inprogress(host))
+ if (dma_inprogress(host)) {
mmci_dma_data_error(host);
+ mmci_dma_unmap(host, host->data);
+ }
mmci_stop_data(host);
}
mmci_request_end(host, cmd->mrq);
--
1.7.10
^ permalink raw reply related
* [PATCH 4/6] ARM: bcm476x: Add stub clock driver
From: Domenico Andreoli @ 2012-10-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012145221.2941.35101@nucleus>
On Fri, Oct 12, 2012 at 07:52:21AM -0700, Mike Turquette wrote:
> Quoting Domenico Andreoli (2012-10-06 18:53:04)
> > Index: b/drivers/clk/clk-bcm476x.c
> > ===================================================================
> > --- /dev/null
> > +++ b/drivers/clk/clk-bcm476x.c
> > @@ -0,0 +1,52 @@
> > +/*
> > + * Broadcom BCM476x SoCs clocks
> > + *
> > + * Copyright (C) 2011-2012 Domenico Andreoli <domenico.andreoli@linux.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clk-private.h>
>
> Why clk-private.h? That is deprecated and should not be used unless
> absolutely necessary. It will be removed once Tegra and OMAP stop using
> it.
>
> > +#include <linux/clk-provider.h>
> > +#include <linux/clkdev.h>
> > +#include <linux/clk/bcm476x.h>
> > +
> > +/*
> > + * These are fixed clocks (and device tree doesn't support clk!).
> > + *
> > + * They're probably not all root clocks and it may be possible to
> > + * turn them on and off but until this is mapped out better it's
> > + * the only way they can be used.
> > + */
> > +DEFINE_CLK_FIXED_RATE(sys_pclk, CLK_IS_ROOT, 312000000, 0);
> > +DEFINE_CLK_FIXED_RATE(apb_pclk, CLK_IS_ROOT, 156000000, 0);
> > +DEFINE_CLK_FIXED_RATE(uart0_pclk, CLK_IS_ROOT, 78000000, 0);
> > +DEFINE_CLK_FIXED_RATE(uart1_pclk, CLK_IS_ROOT, 78000000, 0);
> > +DEFINE_CLK_FIXED_RATE(uart2_pclk, CLK_IS_ROOT, 78000000, 0);
> > +
>
> Can you use clk_register_fixed_rate instead?
Stephen already warned me, it'll be fixed in the next post. Thanks.
Regards,
Domenico
^ permalink raw reply
* [PATCH 3/4] ARM: AT91: Add AT91RM9200 support to DT board
From: ludovic.desroches @ 2012-10-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012142251.GC12801@game.jcrosoft.org>
Le 10/12/2012 04:22 PM, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
> On 00:05 Fri 12 Oct , Joachim Eastwood wrote:
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>>
>> Hi,
>>
>> This patch has some potential issues.
>> Before this patch board-dt would fail building when only AT91RM9200 was enabled because at91sam926x_timer symbol would be missing. This patch uses the at91rm9200_timer which
>> will fail if AT91RM9200 is not enabled.
> this need work with ot wtihout rm9200
>>
>> Any thoughts on solving this? As mention above this bug exists in mainline now.
> duplicate the board-dt with one for rm9200 only
> as rm9200 ans sam9 are 2 distict familly
Why not adding a new machine descriptor for rm9200 in order to prevent
file duplication?
Regards
Ludovic
>>
>> I had to create a new at91rm9200_dt_initialize since at91_dt_initialize will panic when it tries to add rstc and shdwc.
>> Is it okay to add at91rm9200_dt_initialize or should we fix at91_dt_rstc and at91_dt_shdwc to not panic when DT nodes are not found?
> it's ok
>>
>
> can you add a board too rm9200ek will be good
>
> Best Regards,
> J.
>> regards
>> Joachim Eastwood
>>
>> arch/arm/mach-at91/board-dt.c | 15 +++++++++++++++
>> arch/arm/mach-at91/generic.h | 1 +
>> arch/arm/mach-at91/setup.c | 14 ++++++++++++++
>> 3 files changed, 30 insertions(+)
>>
>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>> index e8f45c4..0e73317 100644
>> --- a/arch/arm/mach-at91/board-dt.c
>> +++ b/arch/arm/mach-at91/board-dt.c
>> @@ -45,11 +45,26 @@ static void __init at91_dt_device_init(void)
>> of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> }
>>
>> +static const char *at91rm9200_dt_board_compat[] __initdata = {
>> + "atmel,at91rm9200",
>> + NULL
>> +};
>> +
>> static const char *at91_dt_board_compat[] __initdata = {
>> "atmel,at91sam9",
>> NULL
>> };
>>
>> +DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
>> + .timer = &at91rm9200_timer,
>> + .map_io = at91_map_io,
>> + .handle_irq = at91_aic_handle_irq,
>> + .init_early = at91rm9200_dt_initialize,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91rm9200_dt_board_compat,
>> +MACHINE_END
>> +
>> DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
>> /* Maintainer: Atmel */
>> .timer = &at91sam926x_timer,
>> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
>> index f496506..9bb5ce5 100644
>> --- a/arch/arm/mach-at91/generic.h
>> +++ b/arch/arm/mach-at91/generic.h
>> @@ -20,6 +20,7 @@ extern void __init at91_init_sram(int bank, unsigned long base,
>> extern void __init at91rm9200_set_type(int type);
>> extern void __init at91_initialize(unsigned long main_clock);
>> extern void __init at91x40_initialize(unsigned long main_clock);
>> +extern void __init at91rm9200_dt_initialize(void);
>> extern void __init at91_dt_initialize(void);
>>
>> /* Interrupts */
>> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
>> index da9881b..2c1fdd4 100644
>> --- a/arch/arm/mach-at91/setup.c
>> +++ b/arch/arm/mach-at91/setup.c
>> @@ -338,6 +338,7 @@ static void at91_dt_rstc(void)
>> }
>>
>> static struct of_device_id ramc_ids[] = {
>> + { .compatible = "atmel,at91rm9200-sdramc" },
>> { .compatible = "atmel,at91sam9260-sdramc" },
>> { .compatible = "atmel,at91sam9g45-ddramc" },
>> { /*sentinel*/ }
>> @@ -436,6 +437,19 @@ end:
>> of_node_put(np);
>> }
>>
>> +void __init at91rm9200_dt_initialize(void)
>> +{
>> + at91_dt_ramc();
>> +
>> + /* Init clock subsystem */
>> + at91_dt_clock_init();
>> +
>> + /* Register the processor-specific clocks */
>> + at91_boot_soc.register_clocks();
>> +
>> + at91_boot_soc.init();
>> +}
>> +
>> void __init at91_dt_initialize(void)
>> {
>> at91_dt_rstc();
>> --
>> 1.7.12.2
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-12 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350053897.10584.172.camel@smile>
On 12 October 2012 20:28, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, 2012-10-12 at 20:01 +0530, Viresh Kumar wrote:
>> + if (last_dw) {
>> + if ((last_bus_id == param) && (last_dw == dw))
>> + return false;
>> + }
> Just came to my mind.
> dw can't be NULL, can't it?
> Then
> if (last_dw) {
> ...
> }
> is unneeded.
dw can't be but last_dw can be, which we are making NULL when
we find a channel :)
You are already drunk.
--
viresh
^ permalink raw reply
* [PATCH 1/2] ARM: config: sort select statements alphanumerically
From: Tony Lindgren @ 2012-10-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012144119.GM28061@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121012 07:44]:
> On Fri, Oct 12, 2012 at 04:04:28PM +0200, Linus Walleij wrote:
> > On Fri, Oct 12, 2012 at 3:26 PM, Russell King
> > <rmk+kernel@arm.linux.org.uk> wrote:
> >
> > > As suggested by Andrew Morton:
> > >
> > > This is a pet peeve of mine. Any time there's a long list of items
> > > (header file inclusions, kconfig entries, array initalisers, etc) and
> > > someone wants to add a new item, they *always* go and stick it at the
> > > end of the list.
> > >
> > > Guys, don't do this. Either put the new item into a randomly-chosen
> > > position or, probably better, alphanumerically sort the list.
> > >
> > > lets sort all our select statements alphanumerically. This commit was
> > > created by the following perl:
> >
> > I applied this and tried to configure the Nomadik defconfig,
> > and I get this, sadly:
>
> Yes, I've just fixed those. Unfortunately, the patch is soo large that
> it trips the mailing list size limit, and has to be manually approved,
> so I'm not sure I can call on the list maintainers again today to do the
> approval thing.
After applying these two patches and manually running:
$ git checkout-index -f arch/arm/mach-pxa/Kconfig
$ git checkout-index -f arch/arm/mach-footbridge/Kconfig
It builds just fine for omaps, so for omaps:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] clk: SPEAr: Vco-pll: Fix compilation warning
From: Mike Turquette @ 2012-10-12 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=npo5A0gvk75Cc5MMzp_qfA4GUeETdCwN-wvA4LCsSVYw@mail.gmail.com>
Quoting viresh kumar (2012-10-11 22:51:05)
> Hi Mike,
>
> Because you are back now, can you please push this patch?
>
Done.
Regards,
Mike
> On Thu, Oct 4, 2012 at 3:19 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Currently we are getting following warning for SPEAr clk-vco-pll.
> >
> > "warning: i is used uninitialized in this function."
> >
> > This is because we are getting value of i by passing its pointer to another
> > routine.
> >
> > The variables here are really not used uninitialized.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> >
> > Andrew,
> >
> > I know this must have gone through Mike Turquette. But he is not around for a
> > week. As, this is a pretty small change, can you take it upstream?
> >
> > drivers/clk/spear/clk-vco-pll.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/spear/clk-vco-pll.c b/drivers/clk/spear/clk-vco-pll.c
> > index 5f1b6ba..1b9b65b 100644
> > --- a/drivers/clk/spear/clk-vco-pll.c
> > +++ b/drivers/clk/spear/clk-vco-pll.c
> > @@ -147,7 +147,7 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned long drate,
> > struct clk_pll *pll = to_clk_pll(hw);
> > struct pll_rate_tbl *rtbl = pll->vco->rtbl;
> > unsigned long flags = 0, val;
> > - int i;
> > + int uninitialized_var(i);
> >
> > clk_pll_round_rate_index(hw, drate, NULL, &i);
> >
> > --
> > 1.7.12.rc2.18.g61b472e
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* alignment faults in 3.6
From: Ben Hutchings @ 2012-10-12 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350053300.21172.12319.camel@edumazet-glaptop>
On Fri, 2012-10-12 at 16:48 +0200, Eric Dumazet wrote:
> On Fri, 2012-10-12 at 10:22 -0400, Benjamin LaHaise wrote:
> > On Fri, Oct 12, 2012 at 02:08:12PM +0200, Eric Dumazet wrote:
> > > So yes, we built network stack with the prereq that IP headers are
> > > aligned, but unfortunately many developers use x86 which doesnt care, so
> > > its possible some bugs are added.
> >
> > x86 does have an alignment check flag that can be set in the flags register.
> > Somehow, I doubt anyone would be willing to walk through all the noise the
> > faults would likely trigger.
>
> If this can be mapped to an event that can be used by perf tool, that
> might be useful ?
AC was so useless that it has now been reallocated to use by SMAP
<https://lwn.net/Articles/517251/>.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 1/4] usb: phy: add a new driver for usb3 phy
From: Tony Lindgren @ 2012-10-12 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5077DE0A.4000301@ti.com>
* kishon <kishon@ti.com> [121012 02:10]:
> Hi Tony,
>
> On Thursday 11 October 2012 06:29 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Kishon Vijay Abraham I <kishon@ti.com> [120919 04:32]:
> >>Added a driver for usb3 phy that handles the interaction between usb phy
> >>device and dwc3 controller.
> >>
> >>This also includes device tree support for usb3 phy driver and
> >>the documentation with device tree binding information is updated.
> >>
> >>Currently writing to control module register is taken care in this
> >>driver which will be removed once the control module driver is in place.
> >
> >You may be able to set up the control module register with one
> >of the following Linux standard frameworks:
> >
> >1. Fixed regulator defined in mach-omap2/control.c
>
> Is it control.c?
Hmm after looking into it more we're missing one piece of the puzzle
to handle SCM regulators, which is omap-scm-regulator.c :)
I'll do a minimal DT only version of that.
> > In this case the PHY driver can pick up the regulator by name.
>
> Do you mean we have to define something like fixed_voltage_config
> defined in board-4430sdp.c?
> From whatever I could make out from regulator/fixed.c,
> enabling/disabling of regulator is done using only gpio. I'm not
> sure how we can use that to write to control module register.
Yes you're right, we're missing omap-scm-regulator.c, then it will
be trivial to select the regulator from DT like we have for the
twl-regulator.c.
> >>+usb3phy at 4a084400 {
> >>+ compatible = "ti,omap-usb3";
> >>+ reg = <0x0x4a084400 0x80>,
> >>+ <0x4a084800 0x64>,
> >>+ <0x4a084c00 0x40>,
> >>+ <0x4a002370 0x4>;
> >>+};
> >
> >And register 0x4a002370 here. Care to post some info what the
> >0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
> >on omap4, or does it have other bits there too?
>
> It's CONTROL_PHY_POWER_USB register and it's structure looks like this.
> 31:22 USB_PWRCTL_CLK_FREQ
> 21:14 USB_PWRCTL_CLK_CMD
> 13:0 RESERVED
>
> CLK_CMD takes values to power up/down the TX and RX in various combinations.
>
> And CLK_FREQ takes values for clock configuration.
Oh, it's a clock. Then it would be best to set it up using the
common clock framework and have the clock registered by the
SCM core driver when those are available.
Maybe please just add a comment for that for later on?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] ARM: config: sort select statements alphanumerically
From: Stephen Warren @ 2012-10-12 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012144832.GN28061@n2100.arm.linux.org.uk>
On 10/12/2012 08:48 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 12, 2012 at 03:41:20PM +0100, Russell King - ARM Linux wrote:
>> On Fri, Oct 12, 2012 at 04:04:28PM +0200, Linus Walleij wrote:
>>> On Fri, Oct 12, 2012 at 3:26 PM, Russell King
>>> <rmk+kernel@arm.linux.org.uk> wrote:
>>>
>>>> As suggested by Andrew Morton:
>>>>
>>>> This is a pet peeve of mine. Any time there's a long list of items
>>>> (header file inclusions, kconfig entries, array initalisers, etc) and
>>>> someone wants to add a new item, they *always* go and stick it at the
>>>> end of the list.
>>>>
>>>> Guys, don't do this. Either put the new item into a randomly-chosen
>>>> position or, probably better, alphanumerically sort the list.
>>>>
>>>> lets sort all our select statements alphanumerically. This commit was
>>>> created by the following perl:
>>>
>>> I applied this and tried to configure the Nomadik defconfig,
>>> and I get this, sadly:
>>
>> Yes, I've just fixed those. Unfortunately, the patch is soo large that
>> it trips the mailing list size limit, and has to be manually approved,
>> so I'm not sure I can call on the list maintainers again today to do the
>> approval thing.
>
> Instead, here's the updated script:
>
> 8<===
> #!/usr/bin/perl
> while (<>) {
> while (/\\\s*$/) {
> $_ .= <>;
> }
> undef %selects if /^\s*config\s+/;
> if (/^\s+select\s+(\w+).*/) {
> if (defined($selects{$1})) {
> if ($selects{$1} eq $_) {
> print STDERR "Warning: removing duplicated $1 entry\n";
> } else {
> print STDERR "Error: $1 differently selected\n".
> "\tOld: $selects{$1}\n".
> "\tNew: $_\n";
> exit 1;
> }
> }
> $selects{$1} = $_;
> next;
> }
> if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
> /^endif/ or /^endchoice/)) {
> foreach $k (sort (keys %selects)) {
> print "$selects{$k}";
> }
> undef %selects;
> }
> print;
> }
> if (%selects) {
> foreach $k (sort (keys %selects)) {
> print "$selects{$k}";
> }
> }
> 8<===
>
> Run it like this (assuming its saved as sort.pl):
>
> for f in $(find arch/arm -name 'Kconfig*'); do perl sort.pl $f > $f.new \
> && mv $f.new $f && git update-index $f; done
>
> Omit the "git update-index" bit if you don't want to commit the result.
> ("git update-index" is safer than "git add" for this as "git add" will
> add new files, "git update-index" won't without an additional option.
> That's not a recommendation to use it though.)
FYI, I Tegra works fine after running this script. I guess you can
consider that an ack for the script output;
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* alignment faults in 3.6
From: Benjamin LaHaise @ 2012-10-12 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350053300.21172.12319.camel@edumazet-glaptop>
On Fri, Oct 12, 2012 at 04:48:20PM +0200, Eric Dumazet wrote:
> > Somehow, I doubt anyone would be willing to walk through all the noise the
> > faults would likely trigger.
>
> If this can be mapped to an event that can be used by perf tool, that
> might be useful ?
There are performance counters for the various different types of alignment
faults supported by perf. Modern x86 makes the vast majority of unaligned
accesses very low overhead -- the only ones that really hurt are those
straddling different vm pages, but even those have little cost compared to
obsolete microarchitectures (*cough* P4 *cough*).
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* [PATCH v2 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Thomas Petazzoni @ 2012-10-12 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012143131.GP12330@titan.lakedaemon.net>
Jason,
On Fri, 12 Oct 2012 10:31:31 -0400, Jason Cooper wrote:
> I agree with Francois on most of these. I prefer readability over
> hard 80 column limits.
Sure, but checkpatch.pl is warning on every line exceeding the 80
columns. Not that I think that all checkpatch.pl warnings should
necessarily be religiously respected, but if you have gazillions of
warnings regarding line exceeding 80 columns, it is very likely that
you will miss more important warnings.
> Although, 80 columns is still sound
> guidance. For example, a majority of the broken lines are due to
> long macro and constant names. I did a 'git grep NETA' and didn't
> see anything alarming. So, above could become
>
> val |= rx_filled << NETA_RXQ_ADD_NONOCC_SHIFT;
I don't mind, but then I would like to keep things consistent:
* The driver file would be neta.c
* All functions and data structure would be prefixed neta_ and not
mvneta_
* The Kconfig option would become CONFIG_NETA. Do we really want such
a "simple" Kconfig option name for a driver?
Also, this is entirely not consistent with the existing mv643xx_eth
driver, which has kept the "mv" part of the prefix.
Maybe the fact that those long macros are making long lines is also due
to the code having sometimes a too deep indentation, and I need to fix
that by using more auxiliary functions or something like that?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] i2c: omap: Do not enable the irq always
From: Shubhrajyoti @ 2012-10-12 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lifb7odc.fsf@deeprootsystems.com>
On Friday 12 October 2012 08:01 PM, Kevin Hilman wrote:
> When using runtime PM with auto-suspend timeouts, why would you disable
> the IRQ before the runtime suspend handlers have run?
>
> If you really want to do this, you probably should have these in the
> runtime PM callbacks. But I'll wait until you add a more descriptive
> changelog before I can really tell why this is being done. Based on the
> discussion in the patch from Kalle, I'm assuming this is to prevent
> interrups when I2C is being used by co-processors. If so, plese
> describe in the changelog.
>
> That being said, doesn't the runtime suspend callback already disable
> IRQs at the device level instead of the INTC level?
I thought of not relying on the intc as the registers may be reconfigured.
> Kevin
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Andy Shevchenko @ 2012-10-12 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9688d98010716880c1bbd966ead312c446282204.1350051925.git.viresh.kumar@linaro.org>
On Fri, 2012-10-12 at 20:01 +0530, Viresh Kumar wrote:
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> @@ -1179,6 +1179,53 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
> dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
> }
>
> +bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> +{
> + struct dw_dma *dw = to_dw_dma(chan->device);
> + static struct dw_dma *last_dw;
> + static char *last_bus_id;
> + int i = -1;
> +
> + /*
> + * dmaengine framework calls this routine for all channels of all dma
> + * controller, until true is returned. If 'param' bus_id is not
> + * registered with a dma controller (dw), then there is no need of
> + * running below function for all channels of dw.
> + *
> + * This block of code does this by saving the parameters of last
> + * failure. If dw and param are same, i.e. trying on same dw with
> + * different channel, return false.
> + */
> + if (last_dw) {
> + if ((last_bus_id == param) && (last_dw == dw))
> + return false;
> + }
Just came to my mind.
dw can't be NULL, can't it?
Then
if (last_dw) {
...
}
is unneeded.
Please, check twice my thought because it's a Friday evening.
> @@ -1462,6 +1509,91 @@ static void dw_dma_off(struct dw_dma *dw)
> dw->chan[i].initialized = false;
> }
>
> +#ifdef CONFIG_OF
> +static struct dw_dma_platform_data *
> +__devinit dw_dma_parse_dt(struct platform_device *pdev)
> +{
> + struct device_node *sn, *cn, *np = pdev->dev.of_node;
> + struct dw_dma_platform_data *pdata;
> + struct dw_dma_slave *sd;
> + u32 val, arr[4];
Let me weekend to think about naming. I really can't offer anything else
right now.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-12 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012145027.GF12801@game.jcrosoft.org>
On 12 October 2012 20:20, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 20:01 Fri 12 Oct , Viresh Kumar wrote:
>> dw_dmac driver already supports device tree but it used to have its platform
>> data passed the non-DT way.
>>
>> This patch does following changes:
>> - pass platform data via DT, non-DT way still takes precedence if both are used.
> why keep it all platform are DT
I would love to remove that, but not sure if somebody want's the non-DT
way too.
I didn't wanted to get into fixing user SoCs of this driver.
--
viresh
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Viresh Kumar @ 2012-10-12 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012144837.GE12801@game.jcrosoft.org>
On 12 October 2012 20:18, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
>> static struct of_dev_auxdata spear1310_auxdata_lookup[] __initdata = {
>> - OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, &cf_dma_priv),
>> - OF_DEV_AUXDATA("snps,dma-spear1340", DMAC0_BASE, NULL, &dmac_plat_data),
>> - OF_DEV_AUXDATA("snps,dma-spear1340", DMAC1_BASE, NULL, &dmac_plat_data),
>> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, "cf"),
> ?/
Sorry. can't get it :(
^ permalink raw reply
* [PATCH 4/6] ARM: bcm476x: Add stub clock driver
From: Mike Turquette @ 2012-10-12 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121007015407.154476821@gmail.com>
Quoting Domenico Andreoli (2012-10-06 18:53:04)
> Index: b/drivers/clk/clk-bcm476x.c
> ===================================================================
> --- /dev/null
> +++ b/drivers/clk/clk-bcm476x.c
> @@ -0,0 +1,52 @@
> +/*
> + * Broadcom BCM476x SoCs clocks
> + *
> + * Copyright (C) 2011-2012 Domenico Andreoli <domenico.andreoli@linux.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-private.h>
Why clk-private.h? That is deprecated and should not be used unless
absolutely necessary. It will be removed once Tegra and OMAP stop using
it.
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk/bcm476x.h>
> +
> +/*
> + * These are fixed clocks (and device tree doesn't support clk!).
> + *
> + * They're probably not all root clocks and it may be possible to
> + * turn them on and off but until this is mapped out better it's
> + * the only way they can be used.
> + */
> +DEFINE_CLK_FIXED_RATE(sys_pclk, CLK_IS_ROOT, 312000000, 0);
> +DEFINE_CLK_FIXED_RATE(apb_pclk, CLK_IS_ROOT, 156000000, 0);
> +DEFINE_CLK_FIXED_RATE(uart0_pclk, CLK_IS_ROOT, 78000000, 0);
> +DEFINE_CLK_FIXED_RATE(uart1_pclk, CLK_IS_ROOT, 78000000, 0);
> +DEFINE_CLK_FIXED_RATE(uart2_pclk, CLK_IS_ROOT, 78000000, 0);
> +
Can you use clk_register_fixed_rate instead?
Regards,
Mike
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Grazvydas Ignotas @ 2012-10-12 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50769D8C.8030401@ti.com>
On Thu, Oct 11, 2012 at 1:21 PM, Sourav <sourav.poddar@ti.com> wrote:
> If you have any pointers on how to test hardware flow control, I will like
> to do that on my beagle board.
If you can find some board with BT chip connected to UART, that would
be a good test as they usually have flow control lines connected and
can run at high bitrates. I think some EVM or Zoom boards have BT
chips.
--
Gra?vydas
^ permalink raw reply
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-12 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9688d98010716880c1bbd966ead312c446282204.1350051925.git.viresh.kumar@linaro.org>
On 20:01 Fri 12 Oct , Viresh Kumar wrote:
> dw_dmac driver already supports device tree but it used to have its platform
> data passed the non-DT way.
>
> This patch does following changes:
> - pass platform data via DT, non-DT way still takes precedence if both are used.
why keep it all platform are DT
Best Regards,
J.
^ 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