* [PATCH] mxcmmc: use dmaengine API
From: Shawn Guo @ 2011-01-12 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294826996-13764-2-git-send-email-s.hauer@pengutronix.de>
It seems all the tabs were turned into spaces.
On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> This switches the mxcmmc driver to use the dmaengine API. Unlike
> the old one this one is always present in the tree, even if no DMA
> is implement, hence we can remove all the #ifdefs in from the driver.
> The driver automatically switches to PIO mode if no DMA support or no
> suitable channel is available.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/mmc/host/mxcmmc.c | 172 +++++++++++++++++++++++++--------------------
> 1 files changed, 97 insertions(+), 75 deletions(-)
>
[...]
--
Regards,
Shawn
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Uwe Kleine-König @ 2011-01-12 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101121153370.12146@localhost6.localdomain6>
On Wed, Jan 12, 2011 at 11:57:50AM +0100, Thomas Gleixner wrote:
> On Wed, 12 Jan 2011, Uwe Kleine-K?nig wrote:
> > > [ 75.280000] r5:be961ee4 r4:00063015
> > >
> > > I started to bisect, but already the first test case showed a different
> > > error (my getty dying every few seconds).
> > I bisected this one now, the first bad commit is
> >
> > 9c0729d (x86: Eliminate bp argument from the stack tracing routines)
> >
> > . It made a x86 specific change to include/linux/stacktrace.h.
>
> As I said on IRC already, that's complete nonsense. The commit changes
> a function prototype which is only relevant for x86. So how should
> that affect ARM ?
hmm, the conversion that you probably mean is:
22:26 < ukleinek> hmm, 9c0729dc8062bed96189bd14ac6d4920f3958743 is the first bad commit
22:26 < tglx> lol
22:26 * ukleinek goes to bed
22:27 < ukleinek> then it can only be about include/linux/stacktrace.h
22:27 * ukleinek goes to bed anyhow
22:28 < rostedt> ukleinek: btw, you could do the bisect automated with ktest.pl :-)
22:30 < tglx> ukleinek: right, a change to include/linux/stacktrace.h which is x86 specific
22:33 < tglx> makes arm explode
22:33 < tglx> rotfl
I admit I didn't look what was changed there and I understood your
statement as "the change to include/linux/stacktrace.h was x86 specific
and so broke ARM".
I will look into it again after lunch.
> > According to tglx the lockup above "is related to nicks scalability
> > stuff". I havn't researched yet the offending commit. Is that
> > necessary?
>
> Only if you are interested that the problem gets fixed.
OK, will do.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH/RFC 0/3] ARM: S5P: Add a common platform setup code for MIPI CSIS/DSIM
From: Sylwester Nawrocki @ 2011-01-12 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294153764-25006-1-git-send-email-s.nawrocki@samsung.com>
On 01/04/2011 04:09 PM, Sylwester Nawrocki wrote:
> Hello,
>
> the following patch series adds the common platform code for configuration
> of the MIPI CSIS and MIPI DSIM PHYs on S5PV210 and S5PV310 SoCs.
> The spinlock is used to avoid races while the common PHY control register
> is accessed from within MIPI DSIM and MIPI CSIS drivers.
> The common PHY enable bit is cleared only when both CSIS and DSIM devices
> are not in use.
>
>
> The patch series contains:
>
> [PATCH/RFC 1/3] ARM: S5P: Add a platform callback for MIPI CSIS PHY control
> [PATCH/RFC 2/3] ARM: S5PV310: Add a platform helper for MIPI DSIM/CSIS setup
> [PATCH/RFC 3/3] ARM: S5PV210: Add a platform helper for MIPI DSIM/CSIS setup
>
Any comments on this one?
Regards,
Sylwester
^ permalink raw reply
* [PATCH] watchdog: add support for the Synopsys DesignWare WDT
From: viresh kumar @ 2011-01-12 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112113054.GA2658@pulham.picochip.com>
On Wed, Jan 12, 2011 at 5:00 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> On Wed, Jan 12, 2011 at 02:27:47PM +0530, viresh kumar wrote:
>> On Wed, Jan 12, 2011 at 1:54 PM, Jamie Iles <jamie@jamieiles.com> wrote:
>> >> I don't know why, but checkpatch used to give few errors which it is
>> >> not giving now.
>> >> Like:
>> >> - Mixing spaces and tabs
>> >> - Line over 80 columns.
>> >>
> I do need to fix up the register locations (40-45) but the others are ok
> - they are tab indented to get to a multiple of 8 then spaces to align
> to the '(' brackets etc.
That's what i said. Checkpatch used to give warning for them earlier.
I don't know if it is correct or not. Anyway, others will comment if it is
still a issue. You can keep that as it is.
>> Problem will occur if rate is dynamically changed and we are still believing
>> on platform code's clk_rate.
>> Would be better if we switch order. i.e. give priority to clk_get_rate over
>> pdata->rate.
>
> If the platform can change the rate then I don't see why it would define
> the rate in the platform data though. ?Anyway, I can make the change and
> issue a warning and fail the probe if we're using the rate from
> clk_get_rate() and there is a non-zero rate in the platform data.
that's better.
--
viresh
^ permalink raw reply
* [PATCH] watchdog: add support for the Synopsys DesignWare WDT
From: Jamie Iles @ 2011-01-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim2LJVA+qJNqYd2uPNKjP54kuyvsZ7-T3jSJsta@mail.gmail.com>
On Wed, Jan 12, 2011 at 02:27:47PM +0530, viresh kumar wrote:
> Jamie,
>
> On Wed, Jan 12, 2011 at 1:54 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> >> I don't know why, but checkpatch used to give few errors which it is
> >> not giving now.
> >> Like:
> >> - Mixing spaces and tabs
> >> - Line over 80 columns.
> >>
> >> There are few places in this patch where i have seen these issues, but
> >> checkpatch doesn't
> >> report them at all.
> >
> > Hmm, the only lines over 80 chars are printk lines and I can't see any
> > with mixed spaces and tabs...
>
> There are few in file drivers/watchdog/dw_wdt.c
> line 40-45, 127, 133, 156, 167, 204, 216, 315, 319.
I do need to fix up the register locations (40-45) but the others are ok
- they are tab indented to get to a multiple of 8 then spaces to align
to the '(' brackets etc.
> >> I know it doesn't make sense for a platform to have support for clk framework
> >> and pass rate through plat data. But this code will always take
> >> pdata->rate, if it is passed.
> >> Wouldn't it be better if we reverse the sequence.
> >>
> >> if (clk)
> >> ?rate = clk_get_rate(...);
> >> else {
> >> ?pdata = pdev->dev.platform_data;
> >> ?if (pdata)
> >> ? rate = pdata->rate;
> >> }
> >>
> >> and then following code
> >
> > That's what I did first (without the test that clk is not NULL) but
> > switched it the other way round so that the platform can override the
> > frequency by setting platform_data->clk_rate to nonzero. ?That just
> > seems a little more flexible and easy for testing but I'm happy to
> > switch the order if you feel that's important.
> >
>
> Problem will occur if rate is dynamically changed and we are still believing
> on platform code's clk_rate.
> Would be better if we switch order. i.e. give priority to clk_get_rate over
> pdata->rate.
If the platform can change the rate then I don't see why it would define
the rate in the platform data though. Anyway, I can make the change and
issue a warning and fail the probe if we're using the rate from
clk_get_rate() and there is a non-zero rate in the platform data.
Jamie
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Thomas Gleixner @ 2011-01-12 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112075229.GZ24920@pengutronix.de>
On Wed, 12 Jan 2011, Uwe Kleine-K?nig wrote:
> > [ 75.280000] r5:be961ee4 r4:00063015
> >
> > I started to bisect, but already the first test case showed a different
> > error (my getty dying every few seconds).
> I bisected this one now, the first bad commit is
>
> 9c0729d (x86: Eliminate bp argument from the stack tracing routines)
>
> . It made a x86 specific change to include/linux/stacktrace.h.
As I said on IRC already, that's complete nonsense. The commit changes
a function prototype which is only relevant for x86. So how should
that affect ARM ?
> According to tglx the lockup above "is related to nicks scalability
> stuff". I havn't researched yet the offending commit. Is that
> necessary?
Only if you are interested that the problem gets fixed.
Thanks,
tglx
^ permalink raw reply
* [RFC] ARM: Let GIC to route IRQs to any allowed CPUs
From: Russell King - ARM Linux @ 2011-01-12 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim3BUvnMsH=oW1cxmzT2wmwpxPFLjrP39TGbuhx@mail.gmail.com>
On Wed, Jan 12, 2011 at 05:04:43PM +0800, TAO HU wrote:
> Hi, Russell King
>
> Thanks.
>
> For "The result will be CPUs fighting over servicing such interrupts."
> What's the consequence? The performance downgrade?
It means you'll have the same interrupt trying to be serviced on two
CPUs at the same time. One will succeed and service it. The other
will waste time just finding out that there's nothing for it to do,
competing with resources and wasting time that it could otherwise have
spent executing userspace or whatever.
> Does it imply a design flaw in GIC or in ARM SMP?
No. The hardware is doing what you're asking it to. Some OSes may want
this behaviour so it would be wrong for the hardware to deny it.
There's quite a bit of history behind interrupt balancing across CPU
cores, and it's not a simple issue to get to grips with.
I believe the x86 kernel uses software to balance interrupts across the
cores using an algorithm in the kernel. This tries to distribute the
interrupts between the cores. When this was tried on ARM, although it
moved interrupts around the cores, it was no better than having all
interrupts routed to one core.
On x86 they now do away with their kernel algorithm, and instead run a
boot-time utility (irqbalance) which does a one-time distribution of
interrupts across the cores. The idea is that it is more important to
keep an interrupt handler running on the same core than it is to
constantly switch it between the cores.
If a handler keeps switching between the cores, you have to migrate cache
lines between the cores, which adds to the cache coherency traffic, and
on x86 results in a reduction in performance.
So, with all that in mind, when I was sorting out the initial SMP merging,
I tried out various algorithms for automatic interrupt distribution, and
never got any of them to work satisfactorily. In light of discussions with
x86 folk, particularly Arjan van de Ven, I decided not to merge any of them
and leave it as a matter for userspace policy to control how interrupts are
distributed to the cores - just like the majority of x86 platforms now do.
AFAIK, there's nothing stopping anyone running 'irqbalance' (the x86
utility) on ARM - it should just be accessing procfs files. See
http://irqbalance.org/ for more information on the program, and on the
issues surrounding IRQ distribution in SMP systems.
^ permalink raw reply
* [PATCH v3 2/4] ARM: i.MX53 EVK: add spi device
From: Uwe Kleine-König @ 2011-01-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimFGB1BysGiQhgpc9Dq=6t8JYdeKDY_iR1=HzO7@mail.gmail.com>
On Wed, Jan 12, 2011 at 06:10:26PM +0800, Yong Shen wrote:
> Hi Uwe,
>
> >> + ? ? MX53_PAD_EIM_D16__CSPI1_SCLK,
> >> + ? ? MX53_PAD_EIM_D17__CSPI1_MISO,
> >> + ? ? MX53_PAD_EIM_D18__CSPI1_MOSI,
> > did the v2 patch work at all?
>
> Yes, it did work. Only the pad names were wrong, the configurations
> were right, so v3 changed the names to match the configuration.
you didn't just rename the defines but really changed them. (Which
might or might not mean something.):
> -#define MX53_PAD_EIM_D16__GPIO_3_16 IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> -#define MX53_PAD_EIM_D17__GPIO_3_17 IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> -#define MX53_PAD_EIM_D18__GPIO_3_18 IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D16__CSPI1_SCLK IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT4, 0x79c, 3, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D17__CSPI1_MISO IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT4, 0x7a0, 3, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D18__CSPI1_MOSI IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT4, 0x7a4, 3, NO_PAD_CTRL)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 1/4] ARM: i.MX53: enable spi support
From: Yong Shen @ 2011-01-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112101651.GF24920@pengutronix.de>
>> > Why do you remove the GPIO definitions?
>> >
>> Why not? Anyway they are always used as cspi signals.
> always as in "on the machines currently supported by mainline"? ?This
> can change.
>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? IMO, we don't
>> need keep that many configures, and it's better to add them when
>> needed.
> This proved to not work nicely. ?Better generate the complete header
> using your excel sheet.
I don't know if this head file was generated by tool or not, since it
was there before I started submit code. Anyway, follow your comments.
yong
^ permalink raw reply
* [PATCH] Fix dmaengine_submit() return type
From: Russell King - ARM Linux @ 2011-01-12 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110101230023.GE25924@n2100.arm.linux.org.uk>
Ping?
On Sat, Jan 01, 2011 at 11:00:23PM +0000, Russell King - ARM Linux wrote:
> desc->tx_submit's return type is dma_cookie_t, not int. Therefore,
> dmaengine_submit() should match this return type as it's just
> wrapping this detail.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> include/linux/dmaengine.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 9d8688b..830935b 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -532,7 +532,7 @@ static inline int dmaengine_resume(struct dma_chan *chan)
> return dmaengine_device_control(chan, DMA_RESUME, 0);
> }
>
> -static inline int dmaengine_submit(struct dma_async_tx_descriptor *desc)
> +static inline dma_cookie_t dmaengine_submit(struct dma_async_tx_descriptor *desc)
> {
> return desc->tx_submit(desc);
> }
>
> _______________________________________________
> 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] mxcmmc: use dmaengine API
From: Russell King - ARM Linux @ 2011-01-12 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294826996-13764-2-git-send-email-s.hauer@pengutronix.de>
On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> + host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
> + data->sg_len, host->dma_dir);
As recently discussed, you don't need to save dma_nents - the value to
be passed to dma_unmap_sg() is data->sg_len, not host->dma_nents.
You should also do the map/unmap against the DMA engine device (which
is the device actually doing DMA) rather than the peripheral (which is
only the recipient of DMA). The reason is - while the peripheral can
see the DMA controller, the peripheral may be able to see all RAM but
the DMA controller may have an IOMMU or limited view of RAM.
> +static int mxcmci_setup_dma(struct mmc_host *mmc)
> +{
> + struct mxcmci_host *host = mmc_priv(mmc);
> + struct dma_slave_config *config = &host->dma_slave_config;
> +
> + config->direction = DMA_FROM_DEVICE;
I would like to get some concensus on removing config->direction from
the slave configuration entirely - and make all the fields below
refer purely to the peripheral device parameters. At the moment,
the API allows them to be used ambiguously.
> +static bool filter(struct dma_chan *chan, void *param)
> +{
> + struct mxcmci_host *host = param;
> +
> + if (!imx_dma_is_general_purpose(chan)) {
> + printk("no general\n");
> + return false;
> + }
> +
> + chan->private = &host->dma_data;
> +
> + return true;
Looks like something went wrong with the tabbing here?
> @@ -794,7 +823,7 @@ static int mxcmci_probe(struct platform_device *pdev)
> mmc->max_blk_size = 2048;
> mmc->max_blk_count = 65535;
> mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
> - mmc->max_seg_size = mmc->max_req_size;
> + mmc->max_seg_size = 65535;
You can get this from the DMA parameters for the DMA engine device:
mmc->max_seg_size = dma_get_max_seg_size(dev);
where 'dev' is the DMA engine struct device - chan->dma_device->dev.
Also just spotted this left in your patch:
> + if (!mxcmci_use_dma(host))
> + return 0;
> +
> for_each_sg(data->sg, sg, data->sg_len, i) {
> if (sg->offset & 3 || sg->length & 3) {
> host->do_dma = 0;
Shouldn't this be a decision made by the DMA engine rather than the
driver? Having looked at the MMCI code also doing this, I think this
should cause prep_slave_sg() to return NULL if it can't handle the
scatterlist. On MMCI, we fall back to PIO if prep_slave_sg() returns
NULL.
^ permalink raw reply
* [PATCH] ux500: platform data for LP5521 leds driver
From: Philippe Langlais @ 2011-01-12 10:26 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Philippe Langlais <philippe.langlais@stericsson.com>
---
arch/arm/mach-ux500/board-mop500.c | 70 ++++++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 472f9a2..ce3257d 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -21,6 +21,7 @@
#include <linux/spi/spi.h>
#include <linux/mfd/ab8500.h>
#include <linux/mfd/tc3589x.h>
+#include <linux/leds-lp5521.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
@@ -128,6 +129,58 @@ static struct tc3589x_platform_data mop500_tc35892_data = {
.irq_base = MOP500_EGPIO_IRQ_BASE,
};
+#if defined(CONFIG_LEDS_LP5521) || defined(CONFIG_LEDS_LP5521_MODULE)
+static struct lp5521_led_config lp5521_pri_led[] = {
+ [0] = {
+ .chan_nr = 0,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+ [1] = {
+ .chan_nr = 1,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+ [2] = {
+ .chan_nr = 2,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+};
+
+static struct lp5521_platform_data __initdata lp5521_pri_data = {
+ .label = "lp5521_pri",
+ .led_config = &lp5521_pri_led[0],
+ .num_channels = 3,
+ .clock_mode = LP5521_CLOCK_EXT,
+};
+
+static struct lp5521_led_config lp5521_sec_led[] = {
+ [0] = {
+ .chan_nr = 0,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+ [1] = {
+ .chan_nr = 1,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+ [2] = {
+ .chan_nr = 2,
+ .led_current = 0x2f,
+ .max_current = 0x5f,
+ },
+};
+
+static struct lp5521_platform_data __initdata lp5521_sec_data = {
+ .label = "lp5521_sec",
+ .led_config = &lp5521_sec_led[0],
+ .num_channels = 3,
+ .clock_mode = LP5521_CLOCK_EXT,
+};
+#endif /* CONFIG_LEDS_LP5521 */
+
static struct i2c_board_info mop500_i2c0_devices[] = {
{
I2C_BOARD_INFO("tc3589x", 0x42),
@@ -136,6 +189,21 @@ static struct i2c_board_info mop500_i2c0_devices[] = {
},
};
+static struct i2c_board_info __initdata mop500_i2c2_devices[] = {
+#if defined(CONFIG_LEDS_LP5521) || defined(CONFIG_LEDS_LP5521_MODULE)
+ {
+ /* lp5521 LED driver, 1st device */
+ I2C_BOARD_INFO("lp5521", 0x33),
+ .platform_data = &lp5521_pri_data,
+ },
+ {
+ /* lp5521 LED driver, 2st device */
+ I2C_BOARD_INFO("lp5521", 0x34),
+ .platform_data = &lp5521_sec_data,
+ },
+#endif
+};
+
#define U8500_I2C_CONTROLLER(id, _slsu, _tft, _rft, clk, _sm) \
static struct nmk_i2c_controller u8500_i2c##id##_data = { \
/* \
@@ -382,6 +450,8 @@ static void __init u8500_init_machine(void)
i2c_register_board_info(0, mop500_i2c0_devices,
ARRAY_SIZE(mop500_i2c0_devices));
+ i2c_register_board_info(2, mop500_i2c2_devices,
+ ARRAY_SIZE(mop500_i2c2_devices));
platform_add_devices(u8500_platform_devices,
ARRAY_SIZE(u8500_platform_devices));
--
1.7.3.1
^ permalink raw reply related
* [PATCH] ux500: platform data for SFH7741 proximity sensor driver (standard Keyboard GPIO driver)
From: Philippe Langlais @ 2011-01-12 10:21 UTC (permalink / raw)
To: linux-arm-kernel
Proximity sensor is managed as an input event (SW_PROXIMITY).
Signed-off-by: Philippe Langlais <philippe.langlais@stericsson.com>
---
arch/arm/mach-ux500/board-mop500-regulators.c | 11 ++++
arch/arm/mach-ux500/board-mop500.c | 63 +++++++++++++++++++++++++
2 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-regulators.c b/arch/arm/mach-ux500/board-mop500-regulators.c
index 7584a16..6625f4a 100644
--- a/arch/arm/mach-ux500/board-mop500-regulators.c
+++ b/arch/arm/mach-ux500/board-mop500-regulators.c
@@ -9,15 +9,26 @@
* MOP500 board specific initialization for regulators
*/
#include <linux/kernel.h>
+#include <linux/platform_device.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/ab8500.h>
#include "board-mop500-regulators.h"
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+extern struct platform_device mop500_gpio_keys_device;
+#endif
+
static struct regulator_consumer_supply ab8500_vaux1_consumers[] = {
{
.dev = NULL,
.supply = "v-display",
},
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+ {
+ .dev = &mop500_gpio_keys_device.dev,
+ .supply = "v-proximity",
+ },
+#endif
#ifdef CONFIG_SENSORS_BH1780
{
.dev_name = "bh1780",
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 2635bb7..472f9a2 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -21,6 +21,8 @@
#include <linux/spi/spi.h>
#include <linux/mfd/ab8500.h>
#include <linux/mfd/tc3589x.h>
+#include <linux/input.h>
+#include <linux/gpio_keys.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -171,10 +173,68 @@ static void __init mop500_i2c_init(void)
db8500_add_i2c3(&u8500_i2c3_data);
}
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+static struct gpio_keys_button mop500_gpio_keys[] = {
+ {
+ .desc = "Proximity Sensor",
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = MOP500_EGPIO(7),
+ .active_low = 0,
+ .can_disable = 1,
+ }
+};
+
+static struct regulator *prox_regulator;
+static int mop500_prox_activate(struct device *dev);
+static void mop500_prox_deactivate(struct device *dev);
+
+static struct gpio_keys_platform_data mop500_gpio_keys_data = {
+ .buttons = mop500_gpio_keys,
+ .nbuttons = ARRAY_SIZE(mop500_gpio_keys),
+ .enable = mop500_prox_activate,
+ .disable = mop500_prox_deactivate,
+};
+
+struct platform_device mop500_gpio_keys_device = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &mop500_gpio_keys_data,
+ },
+};
+
+static int mop500_prox_activate(struct device *dev)
+{
+ prox_regulator = regulator_get(&mop500_gpio_keys_device.dev,
+ "v-proximity");
+ if (IS_ERR(prox_regulator)) {
+ dev_err(&mop500_gpio_keys_device.dev,
+ "regulator_get(\"v-proximity\") failed\n");
+ return PTR_ERR(prox_regulator);
+ }
+ regulator_enable(prox_regulator);
+ return 0;
+}
+
+static void mop500_prox_deactivate(struct device *dev)
+{
+ regulator_disable(prox_regulator);
+ regulator_put(prox_regulator);
+}
+#endif
+
/* add any platform devices here - TODO */
static struct platform_device *platform_devs[] __initdata = {
};
+static struct platform_device *u8500_platform_devices[] __initdata = {
+ /*TODO - add platform devices here */
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+ &mop500_gpio_keys_device,
+#endif
+};
+
#ifdef CONFIG_STE_DMA40
static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
@@ -322,6 +382,9 @@ static void __init u8500_init_machine(void)
i2c_register_board_info(0, mop500_i2c0_devices,
ARRAY_SIZE(mop500_i2c0_devices));
+
+ platform_add_devices(u8500_platform_devices,
+ ARRAY_SIZE(u8500_platform_devices));
}
MACHINE_START(U8500, "ST-Ericsson MOP500 platform")
--
1.7.3.1
^ permalink raw reply related
* [PATCH] dmaengine i.MX SDMA: Fix firmware loading
From: Sascha Hauer @ 2011-01-12 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294827494-15092-1-git-send-email-s.hauer@pengutronix.de>
When loading the microcode to the SDMA engine we have to use
the ram_code_start_addr found in the firmware image. The copy
in the sdma engine is not initialized correctly. This is broken
since:
5b28aa3 dmaengine i.MX SDMA: Allow to run without firmware
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d5a5d4d..75df8b9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1135,7 +1135,7 @@ static int __init sdma_get_firmware(struct sdma_engine *sdma,
/* download the RAM image for SDMA */
sdma_load_script(sdma, ram_code,
header->ram_code_size,
- sdma->script_addrs->ram_code_start_addr);
+ addr->ram_code_start_addr);
clk_disable(sdma->clk);
sdma_add_scripts(sdma, addr);
--
1.7.2.3
^ permalink raw reply related
* dmaengine: Fix i.MX sdma firmware loading
From: Sascha Hauer @ 2011-01-12 10:18 UTC (permalink / raw)
To: linux-arm-kernel
The firmware loading in the i.MX sdma engine is currently broken. The
following patch fixes this. Dan, please forward this patch for current
-rc.
Sascha Hauer (1):
dmaengine i.MX SDMA: Fix firmware loading
drivers/dma/imx-sdma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH v3 1/4] ARM: i.MX53: enable spi support
From: Uwe Kleine-König @ 2011-01-12 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikS=cWfj1g0q8aj-d=5X8LvDduRn1xL4zJncJVs@mail.gmail.com>
On Wed, Jan 12, 2011 at 06:03:27PM +0800, Yong Shen wrote:
> hi Uwe,
>
> >> -#define MX53_PAD_EIM_D16__GPIO_3_16 IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> >> -#define MX53_PAD_EIM_D17__GPIO_3_17 IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> >> -#define MX53_PAD_EIM_D18__GPIO_3_18 IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> >> +#define MX53_PAD_EIM_D16__CSPI1_SCLK IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT4, 0x79c, 3, NO_PAD_CTRL)
> >> +#define MX53_PAD_EIM_D17__CSPI1_MISO IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT4, 0x7a0, 3, NO_PAD_CTRL)
> >> +#define MX53_PAD_EIM_D18__CSPI1_MOSI IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT4, 0x7a4, 3, NO_PAD_CTRL)
> >> ?#define MX53_PAD_EIM_D20__GPIO_3_20 ? ? ? ? ?IOMUX_PAD(0x470, 0x128,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> >> ?#define MX53_PAD_EIM_D21__GPIO_3_21 ? ? ? ? ?IOMUX_PAD(0x474, 0x12C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> > Why do you remove the GPIO definitions?
> >
> Why not? Anyway they are always used as cspi signals.
always as in "on the machines currently supported by mainline"? This
can change.
> IMO, we don't
> need keep that many configures, and it's better to add them when
> needed.
This proved to not work nicely. Better generate the complete header
using your excel sheet.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 2/4] ARM: i.MX53 EVK: add spi device
From: Yong Shen @ 2011-01-12 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112094033.GE24920@pengutronix.de>
Hi Uwe,
>> + ? ? MX53_PAD_EIM_D16__CSPI1_SCLK,
>> + ? ? MX53_PAD_EIM_D17__CSPI1_MISO,
>> + ? ? MX53_PAD_EIM_D18__CSPI1_MOSI,
> did the v2 patch work at all?
Yes, it did work. Only the pad names were wrong, the configurations
were right, so v3 changed the names to match the configuration.
cheers
Yong
^ permalink raw reply
* [PATCH] mxcmmc: use dmaengine API
From: Sascha Hauer @ 2011-01-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294826996-13764-1-git-send-email-s.hauer@pengutronix.de>
This switches the mxcmmc driver to use the dmaengine API. Unlike
the old one this one is always present in the tree, even if no DMA
is implement, hence we can remove all the #ifdefs in from the driver.
The driver automatically switches to PIO mode if no DMA support or no
suitable channel is available.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/mmc/host/mxcmmc.c | 172 +++++++++++++++++++++++++--------------------
1 files changed, 97 insertions(+), 75 deletions(-)
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index bdd2cbb..5de4bf8 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -31,16 +31,14 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/dmaengine.h>
#include <asm/dma.h>
#include <asm/irq.h>
#include <asm/sizes.h>
#include <mach/mmc.h>
-#ifdef CONFIG_ARCH_MX2
-#include <mach/dma-mx1-mx2.h>
-#define HAS_DMA
-#endif
+#include <mach/dma.h>
#define DRIVER_NAME "mxc-mmc"
@@ -117,7 +115,8 @@ struct mxcmci_host {
void __iomem *base;
int irq;
int detect_irq;
- int dma;
+ struct dma_chan *dma;
+ struct dma_async_tx_descriptor *desc;
int do_dma;
int default_irq_mask;
int use_sdio;
@@ -141,6 +140,11 @@ struct mxcmci_host {
struct work_struct datawork;
spinlock_t lock;
+
+ int burstlen;
+ int dmareq;
+ struct dma_slave_config dma_slave_config;
+ struct imx_dma_data dma_data;
};
static void mxcmci_set_clk_rate(struct mxcmci_host *host, unsigned int clk_ios);
@@ -166,17 +170,16 @@ static void mxcmci_softreset(struct mxcmci_host *host)
writew(0xff, host->base + MMC_REG_RES_TO);
}
+static int mxcmci_setup_dma(struct mmc_host *mmc);
static int mxcmci_setup_data(struct mxcmci_host *host, struct mmc_data *data)
{
unsigned int nob = data->blocks;
unsigned int blksz = data->blksz;
unsigned int datasize = nob * blksz;
-#ifdef HAS_DMA
struct scatterlist *sg;
int i;
- int ret;
-#endif
+
if (data->flags & MMC_DATA_STREAM)
nob = 0xffff;
@@ -187,7 +190,9 @@ static int mxcmci_setup_data(struct mxcmci_host *host, struct mmc_data *data)
writew(blksz, host->base + MMC_REG_BLK_LEN);
host->datasize = datasize;
-#ifdef HAS_DMA
+ if (!mxcmci_use_dma(host))
+ return 0;
+
for_each_sg(data->sg, sg, data->sg_len, i) {
if (sg->offset & 3 || sg->length & 3) {
host->do_dma = 0;
@@ -195,34 +200,25 @@ static int mxcmci_setup_data(struct mxcmci_host *host, struct mmc_data *data)
}
}
- if (data->flags & MMC_DATA_READ) {
+ if (data->flags & MMC_DATA_READ)
host->dma_dir = DMA_FROM_DEVICE;
- host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
- data->sg_len, host->dma_dir);
-
- ret = imx_dma_setup_sg(host->dma, data->sg, host->dma_nents,
- datasize,
- host->res->start + MMC_REG_BUFFER_ACCESS,
- DMA_MODE_READ);
- } else {
+ else
host->dma_dir = DMA_TO_DEVICE;
- host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
- data->sg_len, host->dma_dir);
- ret = imx_dma_setup_sg(host->dma, data->sg, host->dma_nents,
- datasize,
- host->res->start + MMC_REG_BUFFER_ACCESS,
- DMA_MODE_WRITE);
- }
+ host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
+ data->sg_len, host->dma_dir);
+ host->desc = host->dma->device->device_prep_slave_sg(host->dma,
+ data->sg, data->sg_len, host->dma_dir,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (ret) {
- dev_err(mmc_dev(host->mmc), "failed to setup DMA : %d\n", ret);
- return ret;
+ if (!host->desc) {
+ dev_err(mmc_dev(host->mmc), "failed to setup DMA\n");
+ return -EINVAL;
}
wmb();
- imx_dma_enable(host->dma);
-#endif /* HAS_DMA */
+ dmaengine_submit(host->desc);
+
return 0;
}
@@ -297,13 +293,11 @@ static int mxcmci_finish_data(struct mxcmci_host *host, unsigned int stat)
struct mmc_data *data = host->data;
int data_error;
-#ifdef HAS_DMA
if (mxcmci_use_dma(host)) {
- imx_dma_disable(host->dma);
+ dmaengine_terminate_all(host->dma);
dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->dma_nents,
host->dma_dir);
}
-#endif
if (stat & STATUS_ERR_MASK) {
dev_dbg(mmc_dev(host->mmc), "request failed. status: 0x%08x\n",
@@ -505,7 +499,6 @@ static void mxcmci_datawork(struct work_struct *work)
}
}
-#ifdef HAS_DMA
static void mxcmci_data_done(struct mxcmci_host *host, unsigned int stat)
{
struct mmc_data *data = host->data;
@@ -528,7 +521,6 @@ static void mxcmci_data_done(struct mxcmci_host *host, unsigned int stat)
mxcmci_finish_request(host, host->req);
}
}
-#endif /* HAS_DMA */
static void mxcmci_cmd_done(struct mxcmci_host *host, unsigned int stat)
{
@@ -566,12 +558,10 @@ static irqreturn_t mxcmci_irq(int irq, void *devid)
sdio_irq = (stat & STATUS_SDIO_INT_ACTIVE) && host->use_sdio;
spin_unlock_irqrestore(&host->lock, flags);
-#ifdef HAS_DMA
if (mxcmci_use_dma(host) &&
(stat & (STATUS_READ_OP_DONE | STATUS_WRITE_OP_DONE)))
writel(STATUS_READ_OP_DONE | STATUS_WRITE_OP_DONE,
host->base + MMC_REG_STATUS);
-#endif
if (sdio_irq) {
writel(STATUS_SDIO_INT_ACTIVE, host->base + MMC_REG_STATUS);
@@ -581,14 +571,14 @@ static irqreturn_t mxcmci_irq(int irq, void *devid)
if (stat & STATUS_END_CMD_RESP)
mxcmci_cmd_done(host, stat);
-#ifdef HAS_DMA
if (mxcmci_use_dma(host) &&
(stat & (STATUS_DATA_TRANS_DONE | STATUS_WRITE_OP_DONE)))
mxcmci_data_done(host, stat);
-#endif
+
if (host->default_irq_mask &&
(stat & (STATUS_CARD_INSERTION | STATUS_CARD_REMOVAL)))
mmc_detect_change(host->mmc, msecs_to_jiffies(200));
+
return IRQ_HANDLED;
}
@@ -602,9 +592,7 @@ static void mxcmci_request(struct mmc_host *mmc, struct mmc_request *req)
host->req = req;
host->cmdat &= ~CMD_DAT_CONT_INIT;
-#ifdef HAS_DMA
- host->do_dma = 1;
-#endif
+
if (req->data) {
error = mxcmci_setup_data(host, req->data);
if (error) {
@@ -620,6 +608,7 @@ static void mxcmci_request(struct mmc_host *mmc, struct mmc_request *req)
}
error = mxcmci_start_cmd(host, req->cmd, cmdat);
+
out:
if (error)
mxcmci_finish_request(host, req);
@@ -658,22 +647,47 @@ static void mxcmci_set_clk_rate(struct mxcmci_host *host, unsigned int clk_ios)
prescaler, divider, clk_in, clk_ios);
}
+static int mxcmci_setup_dma(struct mmc_host *mmc)
+{
+ struct mxcmci_host *host = mmc_priv(mmc);
+ struct dma_slave_config *config = &host->dma_slave_config;
+
+ config->direction = DMA_FROM_DEVICE;
+ config->dst_addr = host->res->start + MMC_REG_BUFFER_ACCESS;
+ config->src_addr = host->res->start + MMC_REG_BUFFER_ACCESS;
+ config->dst_addr_width = 4;
+ config->src_addr_width = 4;
+ config->dst_maxburst = host->burstlen;
+ config->src_maxburst = host->burstlen;
+
+ return dmaengine_slave_config(host->dma, config);
+}
+
static void mxcmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mxcmci_host *host = mmc_priv(mmc);
-#ifdef HAS_DMA
- unsigned int blen;
+ int burstlen, ret;
+
/*
* use burstlen of 64 in 4 bit mode (--> reg value 0)
* use burstlen of 16 in 1 bit mode (--> reg value 16)
*/
if (ios->bus_width == MMC_BUS_WIDTH_4)
- blen = 0;
+ burstlen = 64;
else
- blen = 16;
+ burstlen = 16;
+
+ if (mxcmci_use_dma(host) && burstlen != host->burstlen) {
+ host->burstlen = burstlen;
+ ret = mxcmci_setup_dma(mmc);
+ if (ret) {
+ dev_err(mmc_dev(host->mmc),
+ "failed to config DMA channel. Falling back to PIO\n");
+ dma_release_channel(host->dma);
+ host->do_dma = 0;
+ }
+ }
- imx_dma_config_burstlen(host->dma, blen);
-#endif
if (ios->bus_width == MMC_BUS_WIDTH_4)
host->cmdat |= CMD_DAT_CONT_BUS_WIDTH_4;
else
@@ -754,6 +768,20 @@ static void mxcmci_init_card(struct mmc_host *host, struct mmc_card *card)
host->caps |= MMC_CAP_4_BIT_DATA;
}
+static bool filter(struct dma_chan *chan, void *param)
+{
+ struct mxcmci_host *host = param;
+
+ if (!imx_dma_is_general_purpose(chan)) {
+ printk("no general\n");
+ return false;
+ }
+
+ chan->private = &host->dma_data;
+
+ return true;
+}
+
static const struct mmc_host_ops mxcmci_ops = {
.request = mxcmci_request,
.set_ios = mxcmci_set_ios,
@@ -768,6 +796,7 @@ static int mxcmci_probe(struct platform_device *pdev)
struct mxcmci_host *host = NULL;
struct resource *iores, *r;
int ret = 0, irq;
+ dma_cap_mask_t mask;
printk(KERN_INFO "i.MX SDHC driver\n");
@@ -794,7 +823,7 @@ static int mxcmci_probe(struct platform_device *pdev)
mmc->max_blk_size = 2048;
mmc->max_blk_count = 65535;
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
- mmc->max_seg_size = mmc->max_req_size;
+ mmc->max_seg_size = 65535;
host = mmc_priv(mmc);
host->base = ioremap(r->start, resource_size(r));
@@ -846,29 +875,22 @@ static int mxcmci_probe(struct platform_device *pdev)
writel(host->default_irq_mask, host->base + MMC_REG_INT_CNTR);
-#ifdef HAS_DMA
- host->dma = imx_dma_request_by_prio(DRIVER_NAME, DMA_PRIO_LOW);
- if (host->dma < 0) {
- dev_err(mmc_dev(host->mmc), "imx_dma_request_by_prio failed\n");
- ret = -EBUSY;
- goto out_clk_put;
- }
-
r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!r) {
- ret = -EINVAL;
- goto out_free_dma;
+ if (r) {
+ host->dmareq = r->start;
+ host->dma_data.peripheral_type = IMX_DMATYPE_SDHC;
+ host->dma_data.priority = DMA_PRIO_LOW;
+ host->dma_data.dma_request = host->dmareq;
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+ host->dma = dma_request_channel(mask, filter, host);
+ if (host->dma)
+ host->do_dma = 1;
}
- ret = imx_dma_config_channel(host->dma,
- IMX_DMA_MEMSIZE_32 | IMX_DMA_TYPE_FIFO,
- IMX_DMA_MEMSIZE_32 | IMX_DMA_TYPE_LINEAR,
- r->start, 0);
- if (ret) {
- dev_err(mmc_dev(host->mmc), "failed to config DMA channel\n");
- goto out_free_dma;
- }
-#endif
+ if (!host->do_dma)
+ dev_info(mmc_dev(host->mmc), "dma not available. Using PIO\n");
+
INIT_WORK(&host->datawork, mxcmci_datawork);
ret = request_irq(host->irq, mxcmci_irq, 0, DRIVER_NAME, host);
@@ -891,9 +913,8 @@ static int mxcmci_probe(struct platform_device *pdev)
out_free_irq:
free_irq(host->irq, host);
out_free_dma:
-#ifdef HAS_DMA
- imx_dma_free(host->dma);
-#endif
+ if (host->dma)
+ dma_release_channel(host->dma);
out_clk_put:
clk_disable(host->clk);
clk_put(host->clk);
@@ -920,9 +941,10 @@ static int mxcmci_remove(struct platform_device *pdev)
free_irq(host->irq, host);
iounmap(host->base);
-#ifdef HAS_DMA
- imx_dma_free(host->dma);
-#endif
+
+ if (host->dma)
+ dma_release_channel(host->dma);
+
clk_disable(host->clk);
clk_put(host->clk);
--
1.7.2.3
^ permalink raw reply related
* let the mxcmmc driver use the dmaengine API
From: Sascha Hauer @ 2011-01-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
This saves us several ifdefs and also adds mxcmmc DMA support for the
i.MX31 processor.
Sascha
Sascha Hauer (1):
mxcmmc: use dmaengine API
drivers/mmc/host/mxcmmc.c | 172 +++++++++++++++++++++++++--------------------
1 files changed, 97 insertions(+), 75 deletions(-)
^ permalink raw reply
* [PATCH] s3c2410_udc: Add handling for S3C244X dual-packet mode
From: Vasily Khoruzhick @ 2011-01-12 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201012131237.12359.anarsoul@gmail.com>
On Monday 13 December 2010 12:37:11 Vasily Khoruzhick wrote:
> On Wednesday 08 December 2010 02:52:41 Ben Dooks wrote:
> > On 06/12/10 19:39, Vasily Khoruzhick wrote:
> > > On Monday 30 August 2010 17:34:22 Vasily Khoruzhick wrote:
> > >> From: Fabian Godehardt <fg@emlix.com>
> > >>
> > >> This is a patch that seems to make the USB hangs on the S3C244X go
> > >> away.
> >
> > Hmm who's job is it to apply it?
> > I'd certainly ack it
> >
> > Acked-by: Ben Dooks <ben-linux@fluff.org>
>
> Hi, David
>
> could you please merge this patch? If not, should I try to merge it through
> mm tree?
>
> Regards
> Vasily
Ping once again
^ permalink raw reply
* [PATCH v3 1/4] ARM: i.MX53: enable spi support
From: Yong Shen @ 2011-01-12 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112093710.GD24920@pengutronix.de>
hi Uwe,
>> ?#define MX53_PAD_EIM_D20__GPIO_3_20 ? ? ? ? ?IOMUX_PAD(0x470, 0x128,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
>> ?#define MX53_PAD_EIM_D21__GPIO_3_21 ? ? ? ? ?IOMUX_PAD(0x474, 0x12C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> Why do you remove the GPIO definitions?
>
Why not? Anyway they are always used as cspi signals. IMO, we don't
need keep that many configures, and it's better to add them when
needed.
thanks
Yong
^ permalink raw reply
* [RFC] ARM: Let GIC to route IRQs to any allowed CPUs
From: Santosh Shilimkar @ 2011-01-12 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim3BUvnMsH=oW1cxmzT2wmwpxPFLjrP39TGbuhx@mail.gmail.com>
Hu Tao,
(Please avoid top posting)
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of TAO HU
> Sent: Wednesday, January 12, 2011 2:35 PM
> To: Russell King - ARM Linux
> Cc: TAO HU; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC] ARM: Let GIC to route IRQs to any allowed CPUs
>
> Hi, Russell King
>
> Thanks.
>
> For "The result will be CPUs fighting over servicing such
> interrupts."
> What's the consequence? The performance downgrade?
>
Few problems I can see here.
1. Spurious interrupts will be seen by CPU who looses the IRQ race
2. When interrupts are targeted on two CPU's, and if one of the CPU is
in low power mode, the ON CPU will not see the interrupt till the OFF
CPU becomes ON again.
3. Unnecessary wakeups on both CPUs which can screw up power savings.
4. prone to aggravate race conditions in the existing drivers.
Regards,
Santosh
^ permalink raw reply
* [PATCH V3 16/63 resend] rtc: Adding support for spear rtc
From: viresh kumar @ 2011-01-12 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cffdbf80fd07e204c2b41b546b6ec6259e400373.1292833228.git.viresh.kumar@st.com>
On 12/20/2010 01:58 PM, Viresh KUMAR wrote:
> From: Rajeev Kumar <rajeev-dlh.kumar@st.com>
>
> Signed-off-by: Rajeev Kumar <rajeev-dlh.kumar@st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> drivers/rtc/Kconfig | 8 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-spear.c | 534 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 543 insertions(+), 0 deletions(-)
> create mode 100644 drivers/rtc/rtc-spear.c
Alessandro,
Any review comments on this patch??
--
viresh
^ permalink raw reply
* [PATCH v3 2/4] ARM: i.MX53 EVK: add spi device
From: Uwe Kleine-König @ 2011-01-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294821324-5688-3-git-send-email-yong.shen@freescale.com>
On Wed, Jan 12, 2011 at 04:35:22PM +0800, yong.shen at freescale.com wrote:
> From: Yong Shen <yong.shen@freescale.com>
>
> 1. add platform data for spi device
> 2. Kconfig change
>
> Signed-off-by: Yong Shen <yong.shen@freescale.com>
> ---
> arch/arm/mach-mx5/Kconfig | 1 +
> arch/arm/mach-mx5/board-mx53_evk.c | 21 +++++++++++++++++++++
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 23b0e3f..777740b 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -126,6 +126,7 @@ config MACH_MX53_EVK
> select IMX_HAVE_PLATFORM_IMX_UART
> select IMX_HAVE_PLATFORM_IMX_I2C
> select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
> + select IMX_HAVE_PLATFORM_SPI_IMX
> help
> Include support for MX53 EVK platform. This includes specific
> configurations for the board and its peripherals.
> diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
> index 4043451..157fe12 100644
> --- a/arch/arm/mach-mx5/board-mx53_evk.c
> +++ b/arch/arm/mach-mx5/board-mx53_evk.c
> @@ -33,6 +33,8 @@
> #include <mach/iomux-mx53.h>
>
> #define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
> +#define EVK_ECSPI1_CS0 IMX_GPIO_NR(2, 30)
> +#define EVK_ECSPI1_CS1 IMX_GPIO_NR(3, 19)
>
> #include "crm_regs.h"
> #include "devices-imx53.h"
> @@ -52,6 +54,13 @@ static iomux_v3_cfg_t mx53_evk_pads[] = {
> MX53_PAD_ATA_CS_1__UART3_RXD,
> MX53_PAD_ATA_DA_1__UART3_CTS,
> MX53_PAD_ATA_DA_2__UART3_RTS,
> +
> + MX53_PAD_EIM_D16__CSPI1_SCLK,
> + MX53_PAD_EIM_D17__CSPI1_MISO,
> + MX53_PAD_EIM_D18__CSPI1_MOSI,
did the v2 patch work at all?
> +
> + MX53_PAD_EIM_EB2__GPIO_2_30,
> + MX53_PAD_EIM_D19__GPIO_3_19,
IMO there's a comment missing what is the purpose of these. I suggest
to remove the empty line above and write something like /* ecspi.0 with
chip select lines */ over MX53_PAD_EIM_D16__CSPI1_SCLK.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 1/4] ARM: i.MX53: enable spi support
From: Uwe Kleine-König @ 2011-01-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294821324-5688-2-git-send-email-yong.shen@freescale.com>
Hello Yong,
On Wed, Jan 12, 2011 at 04:35:21PM +0800, yong.shen at freescale.com wrote:
> --- a/arch/arm/plat-mxc/include/mach/iomux-mx53.h
> +++ b/arch/arm/plat-mxc/include/mach/iomux-mx53.h
> @@ -131,9 +131,9 @@ typedef enum iomux_config {
> #define MX53_PAD_JTAG_TDO__JTAG_TDO IOMUX_PAD(0x454, NON_MUX_I, IOMUX_CONFIG_ALT0, 0x0, 0, NO_PAD_CTRL)
> #define MX53_PAD_EIM_A25__GPIO_5_2 IOMUX_PAD(0x458, 0x110,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> #define MX53_PAD_EIM_EB2__GPIO_2_30 IOMUX_PAD(0x45C, 0x114,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> -#define MX53_PAD_EIM_D16__GPIO_3_16 IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> -#define MX53_PAD_EIM_D17__GPIO_3_17 IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> -#define MX53_PAD_EIM_D18__GPIO_3_18 IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D16__CSPI1_SCLK IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT4, 0x79c, 3, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D17__CSPI1_MISO IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT4, 0x7a0, 3, NO_PAD_CTRL)
> +#define MX53_PAD_EIM_D18__CSPI1_MOSI IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT4, 0x7a4, 3, NO_PAD_CTRL)
> #define MX53_PAD_EIM_D19__GPIO_3_19 IOMUX_PAD(0x46C, 0x124,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> #define MX53_PAD_EIM_D20__GPIO_3_20 IOMUX_PAD(0x470, 0x128,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
> #define MX53_PAD_EIM_D21__GPIO_3_21 IOMUX_PAD(0x474, 0x12C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
Why do you remove the GPIO definitions?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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