* [PATCH 5/5] OMAP3EVM: Set TSC wakeup option in pad config
From: Hiremath, Vaibhav @ 2011-02-22 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217221933.GC20795@atomide.com>
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Friday, February 18, 2011 3:50 AM
> To: Hilman, Kevin
> Cc: Hiremath, Vaibhav; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 5/5] OMAP3EVM: Set TSC wakeup option in pad config
>
> * Kevin Hilman <khilman@ti.com> [110127 10:41]:
> > Vaibhav Hiremath <hvaibhav@ti.com> writes:
> >
> > > Set OMAP_PIN_OFF_WAKEUPENABLE to enable the wake-up
> > > functionality from touchscreen controller.
> > >
> > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > ---
> > > arch/arm/mach-omap2/board-omap3evm.c | 6 ++++--
> > > 1 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> > > index 2a2efa9..5eddf93 100644
> > > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > > @@ -716,7 +716,8 @@ static struct omap_board_mux omap35x_board_mux[]
> __initdata = {
> > > OMAP_PIN_OFF_INPUT_PULLUP |
> OMAP_PIN_OFF_OUTPUT_LOW |
> > > OMAP_PIN_OFF_WAKEUPENABLE),
> > > OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
> > > - OMAP_PIN_OFF_INPUT_PULLUP |
> OMAP_PIN_OFF_OUTPUT_LOW),
> > > + OMAP_PIN_OFF_INPUT_PULLUP |
> OMAP_PIN_OFF_OUTPUT_LOW |
> > > + OMAP_PIN_OFF_WAKEUPENABLE),
> >
> > This hunk doesn't apply because the code below (SYS_BOOT5, etc.) doesn't
> > exist in upstream code.
>
> Looks like this applies on top of current omap-for-linus with the mcspi
> changes
> in. So I've applied all the omap3evm related patches.
>
> I had to resolve few changes manually with wl12xx changes, can you guys
> please
> check that everything is working? Pushing them into the devel-board branch.
>
[Hiremath, Vaibhav] Thanks Tony for merging all these patches.
I have tested it here at my end on RevG version of EVM. Also I have verified NFS mount on both <RevD & RevG EVM's without any issues.
Thanks,
Vaibhav
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH v2 3/6] davinci: da8xx: add spi resources and registration routine
From: Nori, Sekhar @ 2011-02-22 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297257114-764-4-git-send-email-michael.williamson@criticallink.com>
Hi Mike,
On Wed, Feb 09, 2011 at 18:41:51, Michael Williamson wrote:
> Add IO resource structures, platform data, and a registration
> routine in order to support spi device on DA850/OMAP-L138/AM18x
> and DA830/OMAP-L137/AM17x platforms.
>
> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
[...]
> +static struct resource da8xx_spi1_resources[] = {
> + [0] = {
> + .start = DA8XX_SPI1_BASE,
> + .end = DA8XX_SPI1_BASE + SZ_4K -1,
checkpatch reports a warning here. Need to have spaces
on either side of binary '-'
I tested this series and the two patches it depends on
using SPI flash present on DA850 and DA830 EVMs (tested
in DMA mode) and found no issues.
So, with this minor issue fixed, can you please repost
with my Ack? You can include the two dependent patches
in the same series so it is easy to pick-up the whole
bunch.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 11/13] da850: pruss SUART board specific additions.
From: Subhasish Ghosh @ 2011-02-22 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5584EC.4070506@mvista.com>
Hello,
Have modified this as shown below:
Please let me know if this looks ok.
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
+static struct da850_evm_pruss_can_data can_data = {
.version = 1,
};
+static struct resource da850_evm_suart_resource[] =
------------------------->>> Added a separate resource structure for
suart.
+ {
+ .name = "da8xx_mcasp0_iomem",
+ .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
+ .end = DAVINCI_DA8XX_MCASP0_REG_BASE +
+ (SZ_1K * 12) - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
static struct da8xx_pruss_devices pruss_devices[] = {
{
.dev_name = "da8xx_pruss_can",
.pdata = &can_data,
.pdata_size = sizeof(can_data),
.setup = da850_evm_setup_pruss_can,
+ .num_resources = 0,
+ .resources = NULL,
},
{
.dev_name = "da8xx_pruss_uart",
.pdata = &suart_data,
.pdata_size = sizeof(suart_data),
.setup = da850_evm_setup_pruss_suart,
+ .num_resources = ARRAY_SIZE(da850_evm_suart_resource),
+ .resources =
a850_evm_suart_resource, ---------------------------- >>>>> Initialized it
here
},
{
.dev_name = NULL,
diff --git a/drivers/mfd/da8xx_pru.c b/drivers/mfd/da8xx_pru.c
index f7868a4..140bf14 100644
--- a/drivers/mfd/da8xx_pru.c
+++ b/drivers/mfd/da8xx_pru.c
@@ -332,6 +332,8 @@ static int pruss_mfd_add_devices(struct platform_device
*pdev)
cell.name = (dev_data + count)->dev_name;
cell.platform_data = (dev_data + count)->pdata;
cell.data_size = (dev_data + count)->pdata_size;
+ cell.resources = (dev_data +
ount)->resources; ---------------------->>>Modified the MFD driver to add
the resources.
+ cell.num_resources = (dev_data + count)->num_resources;
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart.c
b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
+ res = platform_get_resource(pdev, IORESOURCE_MEM,
0); ------------------>> Used platform infrastructure to get the data.
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get resource");
+ return -ENOMEM;
+ }
+
+ if (!request_mem_region(res->start,
+ resource_size(res),
--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov@mvista.com>
Sent: Saturday, February 12, 2011 12:20 AM
To: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
Cc: <davinci-linux-open-source@linux.davincidsp.com>;
<sachi@mistralsolutions.com>; "Russell King" <linux@arm.linux.org.uk>;
"Kevin Hilman" <khilman@deeprootsystems.com>; <nsekhar@ti.com>; "open list"
<linux-kernel@vger.kernel.org>; <m-watkins@ti.com>;
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 11/13] da850: pruss SUART board specific additions.
> Subhasish Ghosh wrote:
>
>> This patch adds the pruss SUART pin mux and registers the device
>> with the pruss mfd driver.
>
>> Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
>> ---
>> arch/arm/mach-davinci/board-da850-evm.c | 36
>> +++++++++++++++++++++++++++++++
>> 1 files changed, 36 insertions(+), 0 deletions(-)
>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index f9c38f8..3858516 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> [...]
>> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
>> return ret;
>> }
>> +static struct da850_evm_pruss_suart_data suart_data = {
>> + .version = 1,
>> + .resource = {
>> + .name = "da8xx_mcasp0_iomem",
>> + .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
>> + .end = DAVINCI_DA8XX_MCASP0_REG_BASE +
>> + (SZ_1K * 12) - 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +
>
> I don't think passing a resource thru platform data is good idea...
> Resources should be bound to the platform device.
>
> WBR, Sergei
^ permalink raw reply related
* [PATCH v2 5/6] davinci: add spi devices support for da850/omap-l138/am18x evm
From: Nori, Sekhar @ 2011-02-22 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297257114-764-6-git-send-email-michael.williamson@criticallink.com>
On Wed, Feb 09, 2011 at 18:41:53, Michael Williamson wrote:
> From: Sekhar Nori <nsekhar@ti.com>
>
> This patch adds the on-board SPI flash device to the
> DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
> device to the MTD subsystem.
>
> Based on SPI flash device support for MityDSP-L138F platform.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> [michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
> +static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
> +{
> + int ret;
> +
> + ret = spi_register_board_info(info, len);
> + if (ret)
> + pr_warning("failed to register board info : %d\n", ret);
> +
> + da8xx_spi_pdata[1].num_chipselect = len;
> +
> + ret = da8xx_register_spi(1);
> + if (ret)
> + pr_warning("failed to register spi 1 device : %d\n", ret);
> +}
When reposting can you also modify this to print function name
with the error message (so it is easy to find what exactly failed).
The same thing needs to be done with DA830 EVM.
Rest of the stuff looks good to me.
Thanks,
Sekhar
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-22 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102201603.41856.arnd@arndb.de>
On Sun, Feb 20, 2011 at 9:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> From your flashbench -a run, I would guess that it uses
> 8 MB allocation units, although the data is not 100% conclusive
> there.
>
Because the 8MB aligned write time is significantly faster, right?
>
> My interpretation is that it uses 16 KB pages, but can do two page-sized
> writes in a single access (multi-plane write). Anything smaller than
> a page goes to a temporary buffer first (like the Toshiba chip), but
> gets flushed when the next one is not contiguous. If you manage to fill
> the entire 16 KB page using small contiguous writes, it can do a single
> efficient write access instead.
>
> To confirm that 16 KB is the page size, you can try
>
> flashbench -s --scatter-span=1 --scatter-order=10 -o plot.data \
> ? ? ? ?/dev/mmcblk1 -c 32 --blocksize=16384
> gnuplot -p -e 'plot "plot.data" '
>
> On most MLC flashes, this will show a pattern alternating between slow
> and fast pages like the one from https://lwn.net/Articles/428836/
Cool.
I am attaching some graphs. The 16k sandisk shows the slow and fast
page parallel lines, as does the 8k toshiba (but we knew it for the
toshiba case), but the boundaries are strange for the sandisk case,
and there an interesting 2mb variation in the toshiba 8k graph. What
is the correct way to interpret graphs with other block sizes?
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_8k_read_ts.png
Type: image/png
Size: 11238 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_8k_sandisk.png
Type: image/png
Size: 8964 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_16k_sandisk.png
Type: image/png
Size: 6853 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_32k_read_ts.png
Type: image/png
Size: 9471 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_32k_sandisk.png
Type: image/png
Size: 6790 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatter_16k_read_ts.png
Type: image/png
Size: 9040 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/220679a1/attachment-0011.png>
^ permalink raw reply
* [PATCH 4/6] ARM: tegra: harmony: register sdhci devices
From: Mike Rapoport @ 2011-02-22 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298354117-19097-5-git-send-email-olof@lixom.net>
Hi Olof,
Sorry for jumping late, haven't thought about the proposal below yesterday.
I'm not objecting to applying the patch as is, we can refactor the code
afterwards as well.
On 02/22/11 07:55, Olof Johansson wrote:
> Add the 3 sdhci devices that are available on Harmony as
> platform devices. Two go to slots (one 4-lane, one 8-lane),
> and one goes to onboard wifi.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> arch/arm/mach-tegra/board-harmony.c | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
> index f6ad58b..7010774 100644
> --- a/arch/arm/mach-tegra/board-harmony.c
> +++ b/arch/arm/mach-tegra/board-harmony.c
> @@ -30,10 +30,13 @@
>
> #include <mach/iomap.h>
> #include <mach/irqs.h>
> +#include <mach/sdhci.h>
>
> #include "board.h"
> #include "board-harmony.h"
> #include "clock.h"
> +#include "devices.h"
> +#include "gpio-names.h"
>
> static struct plat_serial8250_port debug_uart_platform_data[] = {
> {
> @@ -59,6 +62,9 @@ static struct platform_device debug_uart = {
>
> static struct platform_device *harmony_devices[] __initdata = {
> &debug_uart,
> + &tegra_sdhci_device1,
> + &tegra_sdhci_device2,
> + &tegra_sdhci_device4,
> };
>
> static void __init tegra_harmony_fixup(struct machine_desc *desc,
> @@ -77,6 +83,26 @@ static __initdata struct tegra_clk_init_table harmony_clk_init_table[] = {
> { NULL, NULL, 0, 0},
> };
>
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata1 = {
> + .cd_gpio = -1,
> + .wp_gpio = -1,
> + .power_gpio = -1,
> +};
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata2 = {
> + .cd_gpio = TEGRA_GPIO_PI5,
> + .wp_gpio = TEGRA_GPIO_PH1,
> + .power_gpio = TEGRA_GPIO_PT3,
> +};
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata4 = {
> + .cd_gpio = TEGRA_GPIO_PH2,
> + .wp_gpio = TEGRA_GPIO_PH3,
> + .power_gpio = TEGRA_GPIO_PI6,
> + .is_8bit = 1,
> +};
> +
> static void __init tegra_harmony_init(void)
> {
> tegra_common_init();
> @@ -85,6 +111,10 @@ static void __init tegra_harmony_init(void)
>
> harmony_pinmux_init();
>
> + tegra_sdhci_device1.dev.platform_data = &sdhci_pdata1;
> + tegra_sdhci_device2.dev.platform_data = &sdhci_pdata2;
> + tegra_sdhci_device4.dev.platform_data = &sdhci_pdata4;
> +
I think that instead of copying explicit initialization of the platform_data
member from board to board we can do something similar to what PXA does. The
board file would have to call something like
tegra_set_device_X_info(struct tegra_device_X_platform_data *data);
and then static registration of platform devices in the board files can be dropped.
For instance, the devices.c would have
void __init tegra_register_device(struct platform_device *dev, void *data)
{
int ret;
dev->dev.platform_data = data;
ret = platform_device_register(dev);
if (ret)
dev_err(&dev->dev, "unable to register device: %d\n", ret);
}
void __init tegra_set_sdhci1_info(struct tegra_sdhci_platform_data *info)
{
tegra_register_device(&tegra_sdhci_device1, info);
}
and the board files would just call tegra_set_sdhci1_info to pass the platform
data for the tegra_sdhci_device1 and register the device.
This way we could reduce amount of copy/paste between the board files. Besides,
if/when tegra will be using device trees, handling of the device registration in
common place would make the transition easier.
> platform_add_devices(harmony_devices, ARRAY_SIZE(harmony_devices));
> }
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-22 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102201623.03596.arnd@arndb.de>
On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The description of the test case is probably suboptimal. What this does
> is 32 KB accesses, with 32 KB alignment in the pre and post case, but 16 KB
> alignment in the "on" case. The idea here is that it should never do
> any access with less than "--blocksize" aligment.
>
Now I feel slightly confused :(.
-b 16384 implies blocksize = 16384, maxalign is 8mb due to count 32,
ret = time_rw_interval(dev, count, pre, blocksize,
align - blocksize, maxalign,
do_write); //
<----------------- read 16k at align - 16k with 8mb intervals?
returnif(ret);
ret = time_rw_interval(dev, count, on, blocksize,
align - blocksize / 2, maxalign,
do_write); //
<----------------- read 16k at align - 8k with 8mb intervals?
returnif(ret);
ret = time_rw_interval(dev, count, post, blocksize,
align, maxalign, do_write); //
<-------- read 16k@align with 8mb intervals?
returnif(ret);
I hope I'm not missing something obvious...
> This is what I think happens:
> Since the partition is over 64 MB size and it can have 7 4 MB allocation units open,
> writing to 8 locations on the drive separated 8 MB causes it to do garbage collection
> all the time for 32KB accesses and larger. However, the "on" measurement is only
> 16 KB aligned, so it goes into T's buffer A for small writes, and does not hit
> the garbage collection all the time, so it ends up being a lot faster.
>
Can't go to A. A is 8KB big. Strange...
A
^ permalink raw reply
* [PATCH 6/6] ARM: tegra: add seaboard, wario and kaen boards
From: Colin Cross @ 2011-02-22 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298354117-19097-7-git-send-email-olof@lixom.net>
On Mon, Feb 21, 2011 at 9:55 PM, Olof Johansson <olof@lixom.net> wrote:
> This adds board support for the Seaboard eval platform and some of the
> derivatives that are very similar. Since they only differ in some very
> minor ways, most of the code is shared.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
<snip>
> +config MACH_SEABOARD
> + ? ? ? bool "Seaboard board family"
Nit: is the Seaboard a family or a board or both? If both, maybe
"Seaboard and family of related boards" or something similar?
<snip>
> +#include <mach/io.h>
linux/io.h?
Other than that, Acked-by: Colin Cross <ccross@android.com>
^ permalink raw reply
* [PATCH 2/2] arm: mxs: add i2c-devices
From: Shawn Guo @ 2011-02-22 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218211618.GI22310@pengutronix.de>
On Fri, Feb 18, 2011 at 10:16:18PM +0100, Uwe Kleine-K?nig wrote:
>
> > diff --git a/arch/arm/mach-mxs/devices/platform-i2c.c b/arch/arm/mach-mxs/devices/platform-i2c.c
> > new file mode 100644
> > index 0000000..22236b2
> > --- /dev/null
> > +++ b/arch/arm/mach-mxs/devices/platform-i2c.c
> > @@ -0,0 +1,56 @@
> > +/*
> > + * Copyright (C) 2011 Pengutronix
> > + * Wolfram Sang <w.sang@pengutronix.de>
> > + *
> > + * This program is free software; you can redistribute it and/or modify it under
> > + * the terms of the GNU General Public License version 2 as published by the
> > + * Free Software Foundation.
> > + */
> > +#include <asm/sizes.h>
> > +#include <mach/mx28.h>
> > +#include <mach/devices-common.h>
> > +
> > +/* helper defines to fix MX23 naming anomaly */
> > +#define MX23_I2C0_BASE_ADDR MX23_I2C_BASE_ADDR
> > +#define MX23_INT_I2C0_ERROR MX23_INT_I2C_ERROR
> > +#define MX23_INT_I2C0_DMA MX23_INT_I2C_DMA
> not needed yet, but OK
>
It makes less sense to me to have these without including mx23.h.
--
Regards,
Shawn
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-22 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102201539.08496.arnd@arndb.de>
On Sun, Feb 20, 2011 at 8:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> [adding linux-fsdevel to Cc, see http://lwn.net/Articles/428941/ and
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/105607 for more
> on this discussion.]
>
>
> I think it's good to discuss all the options, but my feeling is that
> we should not add so much complexity at the interface level, because
> we will never be able to change all that again. In general, sysfs
> files should contain simple values that are self-descriptive (a simple
> number or one word), and should have no side-effects (unlike the delete
> or the policies attributes you describe).
>
> The behavior of the Toshiba chip is peculiar enough to justify having
> some workarounds for it, including run-time selected ones, but I'm
> looking for something much simpler. I'd certainly be interested in
> the patch you come up with and any performance results, but I don't
> think it can be merged like that.
>
Sure. The page_align patch is just going to be a single sysfs
attribute. All I need to prove to myself now is the effect for large
unaligned accesses (and show everyone else the data :-)).
> In the end, Chris will have to make the decision on mmc patches of
> course -- I'm just trying to contribute experience from other subsystems.
>
> What I see as a more promising approach is to add the tunables
> to attributes of the CFQ I/O scheduler once we know what we want.
> This will allow doing the same optimizations to non-MMC devices such
> as USB sticks or CF/IDE cards without reimplementing it in other
> subsystems, and give more control over the individual requests than
> the MMC layer has.
>
> E.g. the I/O scheduler can also make sure that we always submit all
> blocks from the start of one erase unit (e.g. 4 MB) to the end, but
> not try to merge requests across erase unit boundaries. It can
> also try to group the requests in aligned power-of-two sized chunks
> rather than merging as many sectors as possible up to the maximum
> request size, ignoring the alignment.
I agree. These are common things that affect any kind of flash
storage, and it belongs in the I/O scheduler as simple tuneables. I'll
see if I can figure my way around that...
What belongs in mmc card driver are tunable workarounds for MMC/SD
brokeness. For example - needing to use 8K-spitted reliable writes to
ensure that a 64KB access doesn't wind up in the 4MB buffer B (as to
improve lifespan of the card.) But you want a waterline above which
you don't do this anymore, otherwise the overall performance will go
to 0 - i.e. there is a need to balance between performance and
reliability, so the range of access size for which the workaround
works needs to be runtime controlled, as it's potentially different.
Another example (this one is apparently affecting Sandisk) - do
special stuff for block erase, since the card violates spec in that
regard (touch ext_csd instead of argument, I believe). A different
example might be turning on reliable writes for WRITE_META (or all)
blocks for a certain partition (but I just made that up... ).
So there are things that just should be on (spec brokeness
workarounds), and things that apply only to a subset of accesses (and
thus they are selective at issue_*_rq time), whether it's because of
accessed offset or access size.
I agree that the sysfs method is particularly nasty, and I guess I
didn't have to make a prototype to figure that out :-) (but needed
something similar for selective testing anyway). Nothing else exists
right now that acts in the same way, and nothing really should, as
there is no feedback for manipulating the policies (echo POLICY_ENUM >
policy, if it doesn't stick, then the arguments were wrong, etc).
You could put the entire MMC block policy interface through an API
usable by system integrators - i.e. you would really only care for
tuning the MMC parameters if you're creating a device around an emmc.
Idea (1). One idea is to keep the "policies" from my previous mail.
Policies are registered through platform-specific code. The policies
could be then matched for enabling against a specific block device by
manfid/date/etc at the time of mmc_block_alloc... For removable media
no one would fiddle with the tunable parameters anyway, unless there
was some global database of cards and workarounds and a daemon or some
such to take care of that... Probably don't want to add such baggage
to the kernel.
Idea (2). There is probably no need to overcomplicate. Just add a
platform callback (something like int
(*mmc_platform_block_workaround)(struct request *, struct
mmc_blk_request *)). This will be usable as-is for R/W accesses, and
the discard code will need to be slightly modified.
Do you think there is any need for runtime tuning of the MMC
workarounds (disregarding ones that really belong in the I/O
scheduler)? Should the workarounds be simply platform callbacks, or
should they be something heftier ("policies")?
A
^ permalink raw reply
* [PATCH v2 1/1] ARM: imx53: correct Silicon Revision definition following fuse map
From: Jason Chen @ 2011-02-22 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298031990-4521-1-git-send-email-richard.zhao@freescale.com>
2011/2/18 Richard Zhao <richard.zhao@freescale.com>:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Jason Chen <jason.chen@freescale.com>
>
> diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c
> index d40671d..df46b5e 100644
> --- a/arch/arm/mach-mx5/cpu.c
> +++ b/arch/arm/mach-mx5/cpu.c
> @@ -78,11 +78,16 @@ static int get_mx53_srev(void)
> ? ? ? ?void __iomem *iim_base = MX51_IO_ADDRESS(MX53_IIM_BASE_ADDR);
> ? ? ? ?u32 rev = readl(iim_base + IIM_SREV) & 0xff;
>
> - ? ? ? if (rev == 0x0)
> + ? ? ? switch (rev) {
> + ? ? ? case 0x0:
> ? ? ? ? ? ? ? ?return IMX_CHIP_REVISION_1_0;
> - ? ? ? else if (rev == 0x10)
> + ? ? ? case 0x2:
> ? ? ? ? ? ? ? ?return IMX_CHIP_REVISION_2_0;
> - ? ? ? return 0;
> + ? ? ? case 0x3:
> + ? ? ? ? ? ? ? return IMX_CHIP_REVISION_2_1;
> + ? ? ? default:
> + ? ? ? ? ? ? ? return IMX_CHIP_REVISION_UNKNOWN;
> + ? ? ? }
> ?}
>
> ?/*
> --
> 1.7.1
>
>
>
> _______________________________________________
> 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 v3 2/2] ARM: mxs: add dma device
From: Sascha Hauer @ 2011-02-22 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284306-14710-3-git-send-email-shawn.guo@freescale.com>
On Mon, Feb 21, 2011 at 06:31:46PM +0800, Shawn Guo wrote:
> diff --git a/arch/arm/mach-mxs/devices/platform-dma.c b/arch/arm/mach-mxs/devices/platform-dma.c
> new file mode 100644
> index 0000000..ee3220e
> --- /dev/null
> +++ b/arch/arm/mach-mxs/devices/platform-dma.c
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright (C) 2010 Pengutronix
> + * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> + *
> + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +#include <linux/compiler.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +
> +#include <mach/mx23.h>
> +#include <mach/mx28.h>
> +#include <mach/devices-common.h>
> +
> +struct mxs_mxs_dma_data {
> + const char *devid;
> + resource_size_t iobase;
> +};
> +
> +#define mxs_dma_data_entry_single(soc, type, _devid) \
> + { \
> + .devid = _devid, \
> + .iobase = soc ## _ ## type ## _DMA ## _BASE_ADDR, \
> + }
> +
> +#ifdef CONFIG_SOC_IMX23
> +struct mxs_mxs_dma_data mx23_dma_data[] __initconst = {
> + mxs_dma_data_entry_single(MX23, APBH, "mxs-dma-apbh"),
> + mxs_dma_data_entry_single(MX23, APBX, "mxs-dma-apbx"),
> +};
> +#endif
> +
> +#ifdef CONFIG_SOC_IMX28
> +struct mxs_mxs_dma_data mx28_dma_data[] __initconst = {
> + mxs_dma_data_entry_single(MX28, APBH, "mxs-dma-apbh"),
> + mxs_dma_data_entry_single(MX28, APBX, "mxs-dma-apbx"),
> +};
> +#endif
> +
> +struct platform_device *__init mxs_add_dma(
> + const struct mxs_mxs_dma_data *data)
> +{
> + struct resource res[] = {
> + {
> + .start = data->iobase,
> + .end = data->iobase + SZ_8K - 1,
> + .flags = IORESOURCE_MEM,
> + }
> + };
> +
> + return mxs_add_platform_device_dmamask(data->devid, -1,
> + res, ARRAY_SIZE(res), NULL, 0,
> + DMA_BIT_MASK(32));
> +}
> +
> +#define mx23_add_apbh_dma() \
> + mxs_add_dma(&mx23_dma_data[0])
> +#define mx23_add_apbx_dma() \
> + mxs_add_dma(&mx23_dma_data[1])
> +
> +#define mx28_add_apbh_dma() \
> + mxs_add_dma(&mx28_dma_data[0])
> +#define mx28_add_apbx_dma() \
> + mxs_add_dma(&mx28_dma_data[1])
> +
> +static int __init mxs_add_mxs_dma(void)
> +{
> + struct platform_device *ret;
> +
> +#ifdef CONFIG_SOC_IMX23
> + if (cpu_is_mx23()) {
> + ret = mx23_add_apbh_dma();
> + if (IS_ERR(ret))
> + goto out;
> +
> + ret = mx23_add_apbx_dma();
> + } else
> +#endif
> +
> +#ifdef CONFIG_SOC_IMX28
> + if (cpu_is_mx28()) {
> + ret = mx28_add_apbh_dma();
> + if (IS_ERR(ret))
> + goto out;
> +
> + ret = mx28_add_apbx_dma();
> + } else
> +#endif
> + ret = ERR_PTR(-ENODEV);
> +
> +out:
> + if (IS_ERR(ret))
> + return PTR_ERR(ret);
> + else
> + return 0;
> +}
> +arch_initcall(mxs_add_mxs_dma);
Being consistent is one thing, but this should not lead to ifdeffery
where not necessary. Wouldn't it be much simpler to do the following:
static struct platform_device * __init mxs_add_dma(const char *devid,
resource_size_t base)
{
struct resource res_apbh[] = {
{
.start = base,
.end = base + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
};
return mxs_add_platform_device_dmamask(devid, -1,
res, ARRAY_SIZE(res), NULL, 0,
DMA_BIT_MASK(32));
}
static int __init mxs_add_mxs_dma(void)
{
char *apbh = "mxs-dma-apbh";
char *apbx = "mxs-dma-apbx";
if (cpu_is_mx23()) {
mxs_add_dma(apbh, MX23_APBH_DMA_BASE_ADDR);
mxs_add_dma(apbx, MX23_APBX_DMA_BASE_ADDR);
}
if (cpu_is_mx28()) {
mxs_add_dma(apbh, MX28_APBH_DMA_BASE_ADDR);
mxs_add_dma(apbx, MX28_APBX_DMA_BASE_ADDR);
}
return 0;
}
arch_initcall(mxs_add_mxs_dma);
No ifdef, clear to read and only half the size.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 5/7] ARM: tegra: timer: Enable timer and rtc clocks
From: Colin Cross @ 2011-02-22 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim=TZaqZFSJwOAN2gntvu=fiHVPQVn12=WyF9Wi@mail.gmail.com>
On Mon, Feb 21, 2011 at 9:32 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
>
> On Mon, Feb 21, 2011 at 6:39 PM, Colin Cross <ccross@android.com> wrote:
>> Enable the timer and rtc clocks to prevent them being
>> turned off by the bootloader clock disabling code.
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>> ---
>> ?arch/arm/mach-tegra/timer.c | ? 14 ++++++++++++--
>> ?1 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
>> index ffa6a68..31b4f56 100644
>> --- a/arch/arm/mach-tegra/timer.c
>> +++ b/arch/arm/mach-tegra/timer.c
>> @@ -18,6 +18,7 @@
>> ?*/
>>
>> ?#include <linux/init.h>
>> +#include <linux/err.h>
>> ?#include <linux/sched.h>
>> ?#include <linux/time.h>
>> ?#include <linux/interrupt.h>
>> @@ -193,9 +194,20 @@ static struct irqaction tegra_timer_irq = {
>>
>> ?static void __init tegra_init_timer(void)
>> ?{
>> + ? ? ? struct clk *clk;
>> ? ? ? ?unsigned long rate = clk_measure_input_freq();
>> ? ? ? ?int ret;
>>
>> + ? ? ? clk = clk_get_sys("timer", NULL);
>> + ? ? ? BUG_ON(IS_ERR(clk));
>> + ? ? ? clk_enable(clk);
>> + ? ? ? clk_put(clk);
>> +
>> + ? ? ? clk = clk_get_sys("rtc-tegra", NULL);
>> + ? ? ? BUG_ON(IS_ERR(clk));
>> + ? ? ? clk_enable(clk);
>> + ? ? ? clk_put(clk);
>
> Why initialize the rtc clock here? Not all boards use it and instead
> use the rtc on the pmic. Seems wasteful to clock it unless the driver
> for it is probed and configured.
timekeeping_suspend uses read_persistent_clock and not the RTC driver
to track time in suspend. The Tegra implementation of
read_persistent_clock reads from the internal RTC registers. Its a 32
kHz clock, so it's power usage is negligible, and it is required on
all Tegra boards.
^ permalink raw reply
* [PATCH 7/7] ARM: tegra: clock: Disable clocks left on by bootloader
From: Colin Cross @ 2011-02-22 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikNSEyjdL0Lchmm-bFxD00omkGLq6Q6Yyjy51Ov@mail.gmail.com>
On Mon, Feb 21, 2011 at 9:43 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> On Mon, Feb 21, 2011 at 6:39 PM, Colin Cross <ccross@android.com> wrote:
>> Iterates through all clocks, disabling any for which the
>> refcount is 0 but the clock init detected the bootloader
>> left the clock on. ?Can be disabled with command line
>> tegra_clock.disable_boot_clocks=N
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>> ---
>> ?arch/arm/mach-tegra/clock.c | ? 44 +++++++++++++++++++++++++++++++++++++++++++
>> ?1 files changed, 44 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
>> index e028320..6d686ff 100644
>> --- a/arch/arm/mach-tegra/clock.c
>> +++ b/arch/arm/mach-tegra/clock.c
>> @@ -33,6 +33,9 @@
>> ?#include "board.h"
>> ?#include "clock.h"
>>
>> +#undef MODULE_PARAM_PREFIX
>> +#define MODULE_PARAM_PREFIX "tegra_clock."
>> +
>> ?/*
>> ?* Locking:
>> ?*
>> @@ -416,6 +419,47 @@ void tegra_sdmmc_tap_delay(struct clk *c, int delay)
>> ? ? ? ?spin_unlock_irqrestore(&c->spinlock, flags);
>> ?}
>>
>> +static bool tegra_disable_boot_clocks = true;
>> +module_param_named(disable_boot_clocks, tegra_disable_boot_clocks, bool,
>> + ? ? ? S_IRUGO | S_IWUSR | S_IWGRP);
>
> I suggest doing this as an early_param instead. I know it's not truly
> an early param, but it's the easier way to do non-module bootargs,
> i.e. by not requiring a (fake) module prefix. It'd be a little
> cleaner, in my opinion. The variable name itself is unique enough to
> not need a module prefix for namespace reasons.
It doesn't need to be an early_param, I can make it a __setup.
> Also, Documentation/kernel-parameters.txt should be updated with it.
Is it really worth adding every debug flag on every platform to
kernel-parametes.txt? I could add the flag to the warning message
instead.
^ permalink raw reply
* [PATCH v3] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-22 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221174016.GN2616@pengutronix.de>
Hi Wolfram,
On Mon, Feb 21, 2011 at 06:40:16PM +0100, Wolfram Sang wrote:
> Shawn,
>
> On Mon, Feb 21, 2011 at 06:35:28PM +0800, Shawn Guo wrote:
> > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > The driver calls into mxs-dma via generic dmaengine api for both pio
> > and data transfer.
> >
> > Thanks Chris Ball for the indentation patch.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> What throughput rates do you get on a mx28-regulated slot serving a card
> at 50Mhz? This is poor here (55kb/s) while it is OK at 25Mhz. Could be a
To make sure we are on the same page, can you share me the test you
ran? And I can give it a try on my board.
> board issue though (or we can fix it later), rest works fine, thus:
>
> Tested-by: Wolfram Sang <w.sang@pengutronix.de>
>
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v3 2/2] ARM: mxs: add dma device
From: Uwe Kleine-König @ 2011-02-22 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284306-14710-3-git-send-email-shawn.guo@freescale.com>
On Mon, Feb 21, 2011 at 06:31:46PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/clock-mx23.c | 3 +-
> arch/arm/mach-mxs/clock-mx28.c | 4 +-
> arch/arm/mach-mxs/devices/Makefile | 1 +
> arch/arm/mach-mxs/devices/platform-dma.c | 101 ++++++++++++++++++++++++++++++
> 4 files changed, 106 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-mxs/devices/platform-dma.c
>
> diff --git a/arch/arm/mach-mxs/clock-mx23.c b/arch/arm/mach-mxs/clock-mx23.c
> index b1a362e..350b28c 100644
> --- a/arch/arm/mach-mxs/clock-mx23.c
> +++ b/arch/arm/mach-mxs/clock-mx23.c
> @@ -443,7 +443,8 @@ static struct clk_lookup lookups[] = {
> /* for amba-pl011 driver */
> _REGISTER_CLOCK("duart", NULL, uart_clk)
> _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> - _REGISTER_CLOCK(NULL, "hclk", hbus_clk)
> + _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> + _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> _REGISTER_CLOCK(NULL, "usb", usb_clk)
> _REGISTER_CLOCK(NULL, "audio", audio_clk)
> _REGISTER_CLOCK(NULL, "pwm", pwm_clk)
> diff --git a/arch/arm/mach-mxs/clock-mx28.c b/arch/arm/mach-mxs/clock-mx28.c
> index c9d7951..a3b4787 100644
> --- a/arch/arm/mach-mxs/clock-mx28.c
> +++ b/arch/arm/mach-mxs/clock-mx28.c
> @@ -617,8 +617,8 @@ static struct clk_lookup lookups[] = {
> _REGISTER_CLOCK("fec.0", NULL, fec_clk)
> _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> _REGISTER_CLOCK("pll2", NULL, pll2_clk)
> - _REGISTER_CLOCK(NULL, "hclk", hbus_clk)
> - _REGISTER_CLOCK(NULL, "xclk", xbus_clk)
> + _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> + _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> _REGISTER_CLOCK("flexcan.0", NULL, can0_clk)
> _REGISTER_CLOCK("flexcan.1", NULL, can1_clk)
> _REGISTER_CLOCK(NULL, "usb0", usb0_clk)
> diff --git a/arch/arm/mach-mxs/devices/Makefile b/arch/arm/mach-mxs/devices/Makefile
> index a8dc8d5..ca7acc4 100644
> --- a/arch/arm/mach-mxs/devices/Makefile
> +++ b/arch/arm/mach-mxs/devices/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_MXS_HAVE_AMBA_DUART) += amba-duart.o
> obj-$(CONFIG_MXS_HAVE_PLATFORM_AUART) += platform-auart.o
> +obj-y += platform-dma.o
> obj-$(CONFIG_MXS_HAVE_PLATFORM_FEC) += platform-fec.o
> obj-$(CONFIG_MXS_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
> diff --git a/arch/arm/mach-mxs/devices/platform-dma.c b/arch/arm/mach-mxs/devices/platform-dma.c
> new file mode 100644
> index 0000000..ee3220e
> --- /dev/null
> +++ b/arch/arm/mach-mxs/devices/platform-dma.c
I'd prefer to have that called platform-mxs-dma.c to match the driver
name. (At least that's what you use for the data structs.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 2/6] ARM: mxs: make ssp error irq definition consistent
From: Uwe Kleine-König @ 2011-02-22 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284979-14853-3-git-send-email-shawn.guo@freescale.com>
On Mon, Feb 21, 2011 at 06:42:55PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/include/mach/mx23.h | 2 +-
> arch/arm/mach-mxs/include/mach/mx28.h | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/include/mach/mx23.h b/arch/arm/mach-mxs/include/mach/mx23.h
> index 1730c9c..e858692 100644
> --- a/arch/arm/mach-mxs/include/mach/mx23.h
> +++ b/arch/arm/mach-mxs/include/mach/mx23.h
> @@ -93,7 +93,7 @@
> #define MX23_INT_USB_WAKEUP 12
> #define MX23_INT_GPMI_DMA 13
> #define MX23_INT_SSP1_DMA 14
> -#define MX23_INT_SSP_ERROR 15
> +#define MX23_INT_SSP1_ERROR 15
SSP_ERROR matches the reference manual, but using SSP1 looks correct as
there are >1 SSPs.
> #define MX23_INT_GPIO0 16
> #define MX23_INT_GPIO1 17
> #define MX23_INT_GPIO2 18
> diff --git a/arch/arm/mach-mxs/include/mach/mx28.h b/arch/arm/mach-mxs/include/mach/mx28.h
> index 3f3485a..75d8611 100644
> --- a/arch/arm/mach-mxs/include/mach/mx28.h
> +++ b/arch/arm/mach-mxs/include/mach/mx28.h
> @@ -163,10 +163,10 @@
> #define MX28_INT_USB0 93
> #define MX28_INT_USB1_WAKEUP 94
> #define MX28_INT_USB0_WAKEUP 95
> -#define MX28_INT_SSP0 96
> -#define MX28_INT_SSP1 97
> -#define MX28_INT_SSP2 98
> -#define MX28_INT_SSP3 99
> +#define MX28_INT_SSP0_ERROR 96
> +#define MX28_INT_SSP1_ERROR 97
> +#define MX28_INT_SSP2_ERROR 98
> +#define MX28_INT_SSP3_ERROR 99
> #define MX28_INT_ENET_SWI 100
> #define MX28_INT_ENET_MAC0 101
> #define MX28_INT_ENET_MAC1 102
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 3/6] ARM: mxs: dynamically allocate mmc device
From: Uwe Kleine-König @ 2011-02-22 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284979-14853-4-git-send-email-shawn.guo@freescale.com>
On Mon, Feb 21, 2011 at 06:42:56PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/clock-mx23.c | 16 +++++
> arch/arm/mach-mxs/clock-mx28.c | 18 +++++
> arch/arm/mach-mxs/devices-mx23.h | 4 +
> arch/arm/mach-mxs/devices-mx28.h | 4 +
> arch/arm/mach-mxs/devices/Kconfig | 3 +
> arch/arm/mach-mxs/devices/Makefile | 1 +
> arch/arm/mach-mxs/devices/platform-mmc.c | 77 +++++++++++++++++++++++
> arch/arm/mach-mxs/include/mach/devices-common.h | 13 ++++
> 8 files changed, 136 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mxs/devices/platform-mmc.c
>
> diff --git a/arch/arm/mach-mxs/clock-mx23.c b/arch/arm/mach-mxs/clock-mx23.c
> index c19b69a..a1ed5f4 100644
> --- a/arch/arm/mach-mxs/clock-mx23.c
> +++ b/arch/arm/mach-mxs/clock-mx23.c
> @@ -445,6 +445,7 @@ static struct clk_lookup lookups[] = {
> _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> + _REGISTER_CLOCK("mxs-mmc.0", NULL, ssp_clk)
> _REGISTER_CLOCK(NULL, "usb", usb_clk)
> _REGISTER_CLOCK(NULL, "audio", audio_clk)
> _REGISTER_CLOCK(NULL, "pwm", pwm_clk)
> @@ -515,6 +516,15 @@ static int clk_misc_init(void)
> __raw_writel(BM_CLKCTRL_CPU_INTERRUPT_WAIT,
> CLKCTRL_BASE_ADDR + HW_CLKCTRL_CPU_SET);
>
> + /*
> + * 480 MHz seems too high to be ssp clock source directly,
> + * so set frac to get a 288 MHz ref_io.
> + */
> + reg = __raw_readl(CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC);
> + reg &= ~BM_CLKCTRL_FRAC_IOFRAC;
> + reg |= 30 << BP_CLKCTRL_FRAC_IOFRAC;
> + __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC);
> +
> return 0;
> }
>
> @@ -522,6 +532,12 @@ int __init mx23_clocks_init(void)
> {
> clk_misc_init();
>
> + /*
> + * source ssp clock from ref_io than ref_xtal,
> + * as ref_xtal only provides 24 MHz as maximum.
> + */
> + clk_set_parent(&ssp_clk, &ref_io_clk);
> +
> clk_enable(&cpu_clk);
> clk_enable(&hbus_clk);
> clk_enable(&xbus_clk);
> diff --git a/arch/arm/mach-mxs/clock-mx28.c b/arch/arm/mach-mxs/clock-mx28.c
> index 9f4ee36..aeb7b2c 100644
> --- a/arch/arm/mach-mxs/clock-mx28.c
> +++ b/arch/arm/mach-mxs/clock-mx28.c
> @@ -619,6 +619,8 @@ static struct clk_lookup lookups[] = {
> _REGISTER_CLOCK("pll2", NULL, pll2_clk)
> _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> + _REGISTER_CLOCK("mxs-mmc.0", NULL, ssp0_clk)
> + _REGISTER_CLOCK("mxs-mmc.1", NULL, ssp1_clk)
> _REGISTER_CLOCK("flexcan.0", NULL, can0_clk)
> _REGISTER_CLOCK("flexcan.1", NULL, can1_clk)
> _REGISTER_CLOCK(NULL, "usb0", usb0_clk)
> @@ -730,6 +732,15 @@ static int clk_misc_init(void)
> reg |= BM_CLKCTRL_ENET_CLK_OUT_EN;
> __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_ENET);
>
> + /*
> + * 480 MHz seems too high to be ssp clock source directly,
> + * so set frac0 to get a 288 MHz ref_io0.
> + */
> + reg = __raw_readl(CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC0);
> + reg &= ~BM_CLKCTRL_FRAC0_IO0FRAC;
> + reg |= 30 << BP_CLKCTRL_FRAC0_IO0FRAC;
> + __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC0);
> +
> return 0;
> }
>
> @@ -737,6 +748,13 @@ int __init mx28_clocks_init(void)
> {
> clk_misc_init();
>
> + /*
> + * source ssp clock from ref_io0 than ref_xtal,
> + * as ref_xtal only provides 24 MHz as maximum.
> + */
> + clk_set_parent(&ssp0_clk, &ref_io0_clk);
> + clk_set_parent(&ssp1_clk, &ref_io0_clk);
> +
> clk_enable(&cpu_clk);
> clk_enable(&hbus_clk);
> clk_enable(&xbus_clk);
> diff --git a/arch/arm/mach-mxs/devices-mx23.h b/arch/arm/mach-mxs/devices-mx23.h
> index 1256788..4419390 100644
> --- a/arch/arm/mach-mxs/devices-mx23.h
> +++ b/arch/arm/mach-mxs/devices-mx23.h
> @@ -14,3 +14,7 @@
> extern const struct amba_device mx23_duart_device __initconst;
> #define mx23_add_duart() \
> mxs_add_duart(&mx23_duart_device)
> +
> +extern const struct mxs_mmc_data mx23_mmc_data[] __initconst;
> +#define mx23_add_mmc(id, pdata) \
> + mxs_add_mmc(&mx23_mmc_data[id], pdata)
mxs_mmc please (not sure about mxs_mxs_mmc_data, but it would be
consistent). At least mx23_add_mxs_mmc and mxs_add_mxs_mmc.
> diff --git a/arch/arm/mach-mxs/devices-mx28.h b/arch/arm/mach-mxs/devices-mx28.h
> index 3b18304..540639d 100644
> --- a/arch/arm/mach-mxs/devices-mx28.h
> +++ b/arch/arm/mach-mxs/devices-mx28.h
> @@ -32,3 +32,7 @@ extern const struct mxs_flexcan_data mx28_flexcan_data[] __initconst;
> mxs_add_flexcan(&mx28_flexcan_data[id], pdata)
> #define mx28_add_flexcan0(pdata) mx28_add_flexcan(0, pdata)
> #define mx28_add_flexcan1(pdata) mx28_add_flexcan(1, pdata)
> +
> +extern const struct mxs_mmc_data mx28_mmc_data[] __initconst;
> +#define mx28_add_mmc(id, pdata) \
> + mxs_add_mmc(&mx28_mmc_data[id], pdata)
This conflicts with my series, but it's trivial enough to let Sascha
handle that.
> diff --git a/arch/arm/mach-mxs/devices/Kconfig b/arch/arm/mach-mxs/devices/Kconfig
> index 6c65b67..49307f8 100644
> --- a/arch/arm/mach-mxs/devices/Kconfig
> +++ b/arch/arm/mach-mxs/devices/Kconfig
> @@ -11,3 +11,6 @@ config MXS_HAVE_PLATFORM_FEC
> config MXS_HAVE_PLATFORM_FLEXCAN
> select HAVE_CAN_FLEXCAN if CAN
> bool
> +
> +config MXS_HAVE_PLATFORM_MMC
> + bool
ditto MXS_HAVE_PLATFORM_MXS_MMC
> diff --git a/arch/arm/mach-mxs/devices/Makefile b/arch/arm/mach-mxs/devices/Makefile
> index ca7acc4..c0dacfd 100644
> --- a/arch/arm/mach-mxs/devices/Makefile
> +++ b/arch/arm/mach-mxs/devices/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_MXS_HAVE_PLATFORM_AUART) += platform-auart.o
> obj-y += platform-dma.o
> obj-$(CONFIG_MXS_HAVE_PLATFORM_FEC) += platform-fec.o
> obj-$(CONFIG_MXS_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
> +obj-$(CONFIG_MXS_HAVE_PLATFORM_MMC) += platform-mmc.o
> diff --git a/arch/arm/mach-mxs/devices/platform-mmc.c b/arch/arm/mach-mxs/devices/platform-mmc.c
> new file mode 100644
> index 0000000..868def1
> --- /dev/null
> +++ b/arch/arm/mach-mxs/devices/platform-mmc.c
> @@ -0,0 +1,77 @@
> +/*
> + * Copyright (C) 2010 Pengutronix
> + * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> + *
> + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#include <linux/compiler.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +
> +#include <mach/mx23.h>
> +#include <mach/mx28.h>
> +#include <mach/devices-common.h>
> +
> +#define mxs_mmc_data_entry_single(soc, _id, hwid) \
> + { \
> + .id = _id, \
> + .iobase = soc ## _SSP ## hwid ## _BASE_ADDR, \
> + .dma = soc ## _DMA_SSP ## hwid, \
> + .irq_err = soc ## _INT_SSP ## hwid ## _ERROR, \
> + .irq_dma = soc ## _INT_SSP ## hwid ## _DMA, \
> + }
> +
> +#define mxs_mmc_data_entry(soc, _id, hwid) \
> + [_id] = mxs_mmc_data_entry_single(soc, _id, hwid)
> +
> +
> +#ifdef CONFIG_SOC_IMX23
> +const struct mxs_mmc_data mx23_mmc_data[] __initconst = {
> +#define mx23_mmc_data_entry(_id, hwid) \
> + mxs_mmc_data_entry(MX23, _id, hwid)
> + mx23_mmc_data_entry(0, 1),
> + mx23_mmc_data_entry(1, 2),
> +};
hmm, maybe let mxs-mmc.1 use MX23_SSP1_BASE_ADDR?
BTW, Sascha pointed out that
mxs_mmc_data_entry(MX23, 0, 1),
mxs_mmc_data_entry(MX23, 1, 2),
is easier than
#define mx23_mmc_data_entry(_id, hwid) \
mxs_mmc_data_entry(MX23, _id, hwid)
mx23_mmc_data_entry(0, 1),
mx23_mmc_data_entry(1, 2),
though it has to repeat MX23.
> +#endif
> +
> +#ifdef CONFIG_SOC_IMX28
> +const struct mxs_mmc_data mx28_mmc_data[] __initconst = {
> +#define mx28_mmc_data_entry(_id) \
> + mxs_mmc_data_entry(MX28, _id, _id)
> + mx28_mmc_data_entry(0),
> + mx28_mmc_data_entry(1),
> +};
> +#endif
hmm, so i.MX28 starts at 0, i.MX23 at 1. Well, that's how it is.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 5/6] ARM: mxs/mx23evk: add mmc device
From: Uwe Kleine-König @ 2011-02-22 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284979-14853-6-git-send-email-shawn.guo@freescale.com>
On Mon, Feb 21, 2011 at 06:42:58PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/Kconfig | 1 +
> arch/arm/mach-mxs/mach-mx23evk.c | 47 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> index cd2fbdf..f47fae3 100644
> --- a/arch/arm/mach-mxs/Kconfig
> +++ b/arch/arm/mach-mxs/Kconfig
> @@ -19,6 +19,7 @@ config MACH_MX23EVK
> bool "Support MX23EVK Platform"
> select SOC_IMX23
> select MXS_HAVE_AMBA_DUART
> + select MXS_HAVE_PLATFORM_MMC
> default y
> help
> Include support for MX23EVK platform. This includes specific
> diff --git a/arch/arm/mach-mxs/mach-mx23evk.c b/arch/arm/mach-mxs/mach-mx23evk.c
> index aa06400..21519e3 100644
> --- a/arch/arm/mach-mxs/mach-mx23evk.c
> +++ b/arch/arm/mach-mxs/mach-mx23evk.c
> @@ -26,17 +26,64 @@
>
> #include "devices-mx23.h"
>
> +#define MX23EVK_MMC0_WRITE_PROTECT MXS_GPIO_NR(1, 30)
> +#define MX23EVK_MMC0_SLOT_POWER MXS_GPIO_NR(1, 29)
> +
> static const iomux_cfg_t mx23evk_pads[] __initconst = {
> /* duart */
> MX23_PAD_PWM0__DUART_RX | MXS_PAD_4MA,
> MX23_PAD_PWM1__DUART_TX | MXS_PAD_4MA,
> +
> + /* mmc */
> + MX23_PAD_SSP1_DATA0__SSP1_DATA0 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_SSP1_DATA1__SSP1_DATA1 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_SSP1_DATA2__SSP1_DATA2 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_SSP1_DATA3__SSP1_DATA3 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_GPMI_D08__SSP1_DATA4 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_GPMI_D09__SSP1_DATA5 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_GPMI_D10__SSP1_DATA6 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_GPMI_D11__SSP1_DATA7 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_SSP1_CMD__SSP1_CMD |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX23_PAD_SSP1_DETECT__SSP1_DETECT |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> + MX23_PAD_SSP1_SCK__SSP1_SCK |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> + /* write protect */
> + MX23_PAD_PWM4__GPIO_1_30 |
> + (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> + /* slot power enable */
> + MX23_PAD_PWM3__GPIO_1_29 |
> + (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> +};
> +
> +static struct mxs_mmc_platform_data mx23_mmc_pdata __initdata = {
> + .wp_gpio = MX23EVK_MMC0_WRITE_PROTECT,
> + .flags = SLOTF_8_BIT_CAPABLE,
can this be const?
> };
>
> static void __init mx23evk_init(void)
> {
> + int ret;
> +
> mxs_iomux_setup_multiple_pads(mx23evk_pads, ARRAY_SIZE(mx23evk_pads));
>
> mx23_add_duart();
> +
> + /* power on mmc slot by writing 0 to the gpio */
> + ret = gpio_request_one(MX23EVK_MMC0_SLOT_POWER, GPIOF_DIR_OUT,
> + "mmc0-slot-power");
> + if (ret)
> + pr_warn("failed to request gpio mmc0-slot-power: %d\n", ret);
> + mx23_add_mmc(0, &mx23_mmc_pdata);
> }
>
> static void __init mx23evk_timer_init(void)
> --
> 1.7.1
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: pxa: support 806MHz operating points for PXA31x processors A2 stepping
From: Igor Grinberg @ 2011-02-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTino2vLisNgKeyXppuHwDyhLMMAcOOZjA0hgmkj6@mail.gmail.com>
Hi,
On 02/22/11 03:12, Axel Lin wrote:
> Hi Igor,
>
>> Also, there is one thing that is not related to this patch, but
>> if you have the hardware, you need to be concerned with,
>> is that the vcc_core voltage has to be 1.4V, otherwise your
>> hardware will be unstable.
> I don't see any unstable issue on my device.
> But it seems the vcc_core and vcc_sram fields of pxa3xx_freq_info
> are not used now.
Indeed, they are not used, because we don't have any DVFS driver for PXA3xx.
But, the hardware is running regardless of you have the driver or not ;)
There are other means to make sure the vcc_core voltage is set appropriately:
1) could be already set (PMIC default)
2) could be set by "Hardware-Controlled Voltage-Change Sequencer" automatically
(PXA3xx_DM_Vol_I chapter 6.8.3) if your PMIC is 100% compatible with PXA3xx
and PVCR[FVE/PVE] bits set accordingly.
3) If your PMIC is for some reason not 100% compatible, then the voltage can be
set by regulator API or even by the bootloader.
Anyway, to make sure it is set to the appropriate level, you need to measure it.
Usually, this line has some capacitors on it, so it shouldn't be a hard task
Now, regarding hardware instability:
I've seen instabilities related to the vcc_core set improperly, but it has never
showed up that quickly, sometimes it took a week of testing for it to show up.
But when it shows up, you can see strange things happening, like your DRAM
is messed or buses fail or the cpu just freezes.
Another thing (which could be related to the patch) is the package marking.
We have PXA3xx SoCs marked A2 stepping, but C624, which means that the
highest running frequency should not exceed 624MHz.
What is your PXA3xx A2 marking in respect to Cxxx option?
--
Regards,
Igor.
^ permalink raw reply
* dma_declare_coherent_memory() again.
From: Uwe Kleine-König @ 2011-02-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1102211602140.26977@axis700.grange>
On Mon, Feb 21, 2011 at 04:37:00PM +0100, Guennadi Liakhovetski wrote:
> Hi All
>
> AFAIU, dma_declare_coherent_memory() is still present on the following
> platforms:
>
> arch/arm/mach-mx3/mach-pcm037.c
I had a patch for that one[1]. Russell considered it OK if I got him
correctly. (I think it's OK from a platform's POV, maybe there are some
architecture problems?)
There were a few minor review nits, I can respin if there is general
agreement that the patch is fine.
> arch/arm/mach-mx3/mach-mx31moboard.c
> arch/arm/mach-shmobile/board-ap4evb.c
> arch/arm/mach-shmobile/board-mackerel.c (latter 2 via
> drivers/media/video/sh_mobile_ceu_camera.c)
>
> and there are no pending patches to fix them for 2.6.38, is this right? If
> there are no realistic plans for proper memory reservation on ARM in
> 2.6.38, shall I just submit patches to disable those calls on the above
> platforms and hope, that the user manages to get RAM without boot-time
> reservation? Or is a definite failure preferred?
Thanks
Uwe
[1] http://mid.gmane.org/1290505382-16110-1-git-send-email-u.kleine-koenig at pengutronix.de
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 13/13] tty: pruss SUART driver
From: Subhasish Ghosh @ 2011-02-22 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102181951.32631.arnd@arndb.de>
Hello,
I had kept separate files to affirm the modularity and ease of portability
of the system.
There are three different interfaces,
1. The Linux driver interface
2. The PRU control interface
3. The McASP serializer interface.
To maintain modularity, I had classified the files respectively as :
1. pruss_suart.c
2. pruss_suart_api.c
3. pruss_suart_utils.c
This is not a single device which can be expressed as a single file,
but functionally different devices logically cascaded together to work in
unison.
We use the PRU for packet processing, but the actual data is
transmitted/received through the
McASP, which we use as a serializer.
I feel to combine these disparate functionalities into a single file will
not
1. Help better understanding the device. I mean, why should a TTY UART
driver be aware of the McASP or the PRU.
2. In case of a bug in the API layer or McASP, the driver need not be
touched, thus improve maintainability.
3. If we need to port it to another Linux version, just editing the driver
file should suffice, this will reduce bugs while porting.
To me, combining all of these into a single file only creates a mess. This
is the reason I had separated them into different files!!
I don't understand why should it be better to have all of these into a
single file.
--------------------------------------------------
From: "Arnd Bergmann" <arnd@arndb.de>
Sent: Saturday, February 19, 2011 12:21 AM
To: <linux-arm-kernel@lists.infradead.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>; "Alan Cox"
<alan@lxorguk.ukuu.org.uk>; <sachi@mistralsolutions.com>;
<davinci-linux-open-source@linux.davincidsp.com>; "Subhasish Ghosh"
<subhasish@mistralsolutions.com>; "Greg Kroah-Hartman" <gregkh@suse.de>;
<nsekhar@ti.com>; "open list" <linux-kernel@vger.kernel.org>;
<m-watkins@ti.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
> On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
>> On Fri, 18 Feb 2011, Alan Cox wrote:
>>
>> > On Fri, 18 Feb 2011 19:17:38 +0530
>> > "Subhasish Ghosh" <subhasish@mistralsolutions.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > Regarding the semaphore to mutex migration.
>> > > We are using down_trylock in interrupt context,
>> > > mutex_trylock cannot be used in interrupt context, so we cannot use
>> > > mutex in
>> > > our driver.
>> >
>> > Then you probably need to rework your locking. Best bet might be to fix
>> > all the other stuff and report the driver, and people can think about
>> > the
>> > locking problem.
>>
>> That semaphore is utterly useless to begin with. There are more
>> serious locking problems than this one. Non serialized calls to
>> suart_intr_clrmask/suart_intr_setmask are the most obvious ones.
>>
>> Aside of that the code is complete unreadable.
>
> I think it mostly suffers from the same problem as the CAN driver
> I commented on earlier: One of the files (pruss_suart_api.c) was
> clearly not written with Linux as the target, and the other files
> try to work around this by wrapping a Linux driver around it.
>
> The suart_api HAL stuff clearly needs to go away, so that the rest
> can be rewritten into a proper device driver.
>
> Arnd
^ permalink raw reply
* [PATCH v2 13/13] tty: pruss SUART driver
From: Subhasish Ghosh @ 2011-02-22 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102181951.32631.arnd@arndb.de>
I agree with the Codingstyle which needs to be fixed and would appreciate
more feedback on it.
I have also gotten rid of the semaphore completely, please let me know what
you feel of this implementation:
I have tested this without any problem.
What I am basically doing below is that, I am getting the data from the circ
buff and then using the interrupt handler to
pump out the data. As the circ buff empties, I am accepting another request
from the TTY.
Are you noticing any problems with this:
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart.c
b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
index d222e2e..edc3863 100644
--- a/drivers/tty/serial/da8xx_pruss/pruss_suart.c
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
@@ -72,7 +72,7 @@ struct suart_fifo {
struct omapl_pru_suart {
struct uart_port port[NR_SUART];
struct device *dev; /* pdev->dev */
- struct semaphore port_sem[NR_SUART];
+ bool tx_empty[NR_SUART];
struct clk *clk_mcasp;
struct suart_fifo suart_fifo_addr[NR_SUART];
const struct firmware *fw;
@@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct omapl_pru_suart
*soft_uart, u32 uart_no)
if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
return;
- if (down_trylock(&soft_uart->port_sem[uart_no]))
- return;
-
if (uart_circ_empty(xmit) ||
uart_tx_stopped(&soft_uart->port[uart_no])) {
pruss_suart_stop_tx(&soft_uart->port[uart_no]);
- up(&soft_uart->port_sem[uart_no]);
+ soft_uart->tx_empty[uart_no] = true;
return;
}
@@ -259,7 +256,6 @@ static irqreturn_t pruss_suart_interrupt(s32 irq, void
*dev_id)
pru_intr_clr_isrstatus(dev, uart_num, PRU_TX_INTR);
pru_softuart_clr_tx_status(dev,
&soft_uart->suart_hdl
[port->line]);
- up(&soft_uart->port_sem[port->line]);
omapl_pru_tx_chars(soft_uart, port->line);
}
} while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
@@ -294,7 +290,10 @@ static void pruss_suart_start_tx(struct uart_port
*port)
suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
- omapl_pru_tx_chars(soft_uart, port->line);
+ if (soft_uart->tx_empty[port->line] == true) {
+ soft_uart->tx_empty[port->line] = false;
+ omapl_pru_tx_chars(soft_uart, port->line);
+ }
}
--------------------------------------------------
From: "Arnd Bergmann" <arnd@arndb.de>
Sent: Saturday, February 19, 2011 12:21 AM
To: <linux-arm-kernel@lists.infradead.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>; "Alan Cox"
<alan@lxorguk.ukuu.org.uk>; <sachi@mistralsolutions.com>;
<davinci-linux-open-source@linux.davincidsp.com>; "Subhasish Ghosh"
<subhasish@mistralsolutions.com>; "Greg Kroah-Hartman" <gregkh@suse.de>;
<nsekhar@ti.com>; "open list" <linux-kernel@vger.kernel.org>;
<m-watkins@ti.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
> On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
>> On Fri, 18 Feb 2011, Alan Cox wrote:
>>
>> > On Fri, 18 Feb 2011 19:17:38 +0530
>> > "Subhasish Ghosh" <subhasish@mistralsolutions.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > Regarding the semaphore to mutex migration.
>> > > We are using down_trylock in interrupt context,
>> > > mutex_trylock cannot be used in interrupt context, so we cannot use
>> > > mutex in
>> > > our driver.
>> >
>> > Then you probably need to rework your locking. Best bet might be to fix
>> > all the other stuff and report the driver, and people can think about
>> > the
>> > locking problem.
>>
>> That semaphore is utterly useless to begin with. There are more
>> serious locking problems than this one. Non serialized calls to
>> suart_intr_clrmask/suart_intr_setmask are the most obvious ones.
>>
>> Aside of that the code is complete unreadable.
>
> I think it mostly suffers from the same problem as the CAN driver
> I commented on earlier: One of the files (pruss_suart_api.c) was
> clearly not written with Linux as the target, and the other files
> try to work around this by wrapping a Linux driver around it.
>
> The suart_api HAL stuff clearly needs to go away, so that the rest
> can be rewritten into a proper device driver.
>
> Arnd
^ permalink raw reply related
* [PATCH v4] ARM: mxs/mx23evk: add mmc device
From: Shawn Guo @ 2011-02-22 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284979-14853-6-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/Kconfig | 1 +
arch/arm/mach-mxs/mach-mx23evk.c | 47 ++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index cd2fbdf..f47fae3 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -19,6 +19,7 @@ config MACH_MX23EVK
bool "Support MX23EVK Platform"
select SOC_IMX23
select MXS_HAVE_AMBA_DUART
+ select MXS_HAVE_PLATFORM_MMC
default y
help
Include support for MX23EVK platform. This includes specific
diff --git a/arch/arm/mach-mxs/mach-mx23evk.c b/arch/arm/mach-mxs/mach-mx23evk.c
index aa06400..d690fa0 100644
--- a/arch/arm/mach-mxs/mach-mx23evk.c
+++ b/arch/arm/mach-mxs/mach-mx23evk.c
@@ -26,17 +26,64 @@
#include "devices-mx23.h"
+#define MX23EVK_MMC0_WRITE_PROTECT MXS_GPIO_NR(1, 30)
+#define MX23EVK_MMC0_SLOT_POWER MXS_GPIO_NR(1, 29)
+
static const iomux_cfg_t mx23evk_pads[] __initconst = {
/* duart */
MX23_PAD_PWM0__DUART_RX | MXS_PAD_4MA,
MX23_PAD_PWM1__DUART_TX | MXS_PAD_4MA,
+
+ /* mmc */
+ MX23_PAD_SSP1_DATA0__SSP1_DATA0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_SSP1_DATA1__SSP1_DATA1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_SSP1_DATA2__SSP1_DATA2 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_SSP1_DATA3__SSP1_DATA3 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_GPMI_D08__SSP1_DATA4 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_GPMI_D09__SSP1_DATA5 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_GPMI_D10__SSP1_DATA6 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_GPMI_D11__SSP1_DATA7 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_SSP1_CMD__SSP1_CMD |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX23_PAD_SSP1_DETECT__SSP1_DETECT |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ MX23_PAD_SSP1_SCK__SSP1_SCK |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* write protect */
+ MX23_PAD_PWM4__GPIO_1_30 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* slot power enable */
+ MX23_PAD_PWM3__GPIO_1_29 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+};
+
+static struct mxs_mmc_platform_data mx23evk_mmc_pdata __initdata = {
+ .wp_gpio = MX23EVK_MMC0_WRITE_PROTECT,
+ .flags = SLOTF_8_BIT_CAPABLE,
};
static void __init mx23evk_init(void)
{
+ int ret;
+
mxs_iomux_setup_multiple_pads(mx23evk_pads, ARRAY_SIZE(mx23evk_pads));
mx23_add_duart();
+
+ /* power on mmc slot by writing 0 to the gpio */
+ ret = gpio_request_one(MX23EVK_MMC0_SLOT_POWER, GPIOF_DIR_OUT,
+ "mmc0-slot-power");
+ if (ret)
+ pr_warn("failed to request gpio mmc0-slot-power: %d\n", ret);
+ mx23_add_mmc(0, &mx23evk_mmc_pdata);
}
static void __init mx23evk_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [PATCH v4] ARM: mxs/mx28evk: add mmc device
From: Shawn Guo @ 2011-02-22 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298284979-14853-7-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/Kconfig | 1 +
arch/arm/mach-mxs/mach-mx28evk.c | 96 +++++++++++++++++++++++++++++++++++++-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index f47fae3..287e0f8 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -30,6 +30,7 @@ config MACH_MX28EVK
select SOC_IMX28
select MXS_HAVE_AMBA_DUART
select MXS_HAVE_PLATFORM_FEC
+ select MXS_HAVE_PLATFORM_MMC
select MXS_OCOTP
default y
help
diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
index e8db99f..d5fb2f3 100644
--- a/arch/arm/mach-mxs/mach-mx28evk.c
+++ b/arch/arm/mach-mxs/mach-mx28evk.c
@@ -28,8 +28,13 @@
#include "devices-mx28.h"
#include "gpio.h"
-#define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
-#define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
+#define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
+#define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
+
+#define MX28EVK_MMC0_WRITE_PROTECT MXS_GPIO_NR(2, 12)
+#define MX28EVK_MMC1_WRITE_PROTECT MXS_GPIO_NR(0, 28)
+#define MX28EVK_MMC0_SLOT_POWER MXS_GPIO_NR(3, 28)
+#define MX28EVK_MMC1_SLOT_POWER MXS_GPIO_NR(3, 29)
static const iomux_cfg_t mx28evk_pads[] __initconst = {
/* duart */
@@ -76,6 +81,66 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
/* phy reset line */
MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+
+ /* mmc0 */
+ MX28_PAD_SSP0_DATA0__SSP0_D0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA1__SSP0_D1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA2__SSP0_D2 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA3__SSP0_D3 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA4__SSP0_D4 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA5__SSP0_D5 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA6__SSP0_D6 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA7__SSP0_D7 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_CMD__SSP0_CMD |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ MX28_PAD_SSP0_SCK__SSP0_SCK |
+ (MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* write protect */
+ MX28_PAD_SSP1_SCK__GPIO_2_12 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* slot power enable */
+ MX28_PAD_PWM3__GPIO_3_28 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+
+ /* mmc1 */
+ MX28_PAD_GPMI_D00__SSP1_D0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D01__SSP1_D1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D02__SSP1_D2 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D03__SSP1_D3 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D04__SSP1_D4 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D05__SSP1_D5 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D06__SSP1_D6 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_D07__SSP1_D7 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_RDY1__SSP1_CMD |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_GPMI_RDY0__SSP1_CARD_DETECT |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ MX28_PAD_GPMI_WRN__SSP1_SCK |
+ (MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* write protect */
+ MX28_PAD_GPMI_RESETN__GPIO_0_28 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* slot power enable */
+ MX28_PAD_PWM4__GPIO_3_29 |
+ (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
};
/* fec */
@@ -159,12 +224,39 @@ error:
return -ETIMEDOUT;
}
+static struct mxs_mmc_platform_data mx28evk_mmc_pdata[] __initdata = {
+ {
+ /* mmc0 */
+ .wp_gpio = MX28EVK_MMC0_WRITE_PROTECT,
+ .flags = SLOTF_8_BIT_CAPABLE,
+ }, {
+ /* mmc1 */
+ .wp_gpio = MX28EVK_MMC1_WRITE_PROTECT,
+ .flags = SLOTF_8_BIT_CAPABLE,
+ },
+};
+
static void __init mx28evk_init(void)
{
+ int ret;
+
mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
mx28_add_duart();
+ /* power on mmc slot by writing 0 to the gpio */
+ ret = gpio_request_one(MX28EVK_MMC0_SLOT_POWER, GPIOF_DIR_OUT,
+ "mmc0-slot-power");
+ if (ret)
+ pr_warn("failed to request gpio mmc0-slot-power: %d\n", ret);
+ mx28_add_mmc(0, &mx28evk_mmc_pdata[0]);
+
+ ret = gpio_request_one(MX28EVK_MMC1_SLOT_POWER, GPIOF_DIR_OUT,
+ "mmc1-slot-power");
+ if (ret)
+ pr_warn("failed to request gpio mmc1-slot-power: %d\n", ret);
+ mx28_add_mmc(1, &mx28evk_mmc_pdata[1]);
+
if (mx28evk_fec_get_mac())
pr_warn("%s: failed on fec mac setup\n", __func__);
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox