* [PATCH 1/5] ARM: Kirkwood: Allow use of pinctrl
From: Thomas Petazzoni @ 2012-10-25 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-2-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Wed, 24 Oct 2012 16:25:20 +0200, Andrew Lunn wrote:
> index 7bf914d..5682c96 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -188,7 +188,7 @@ config PINCTRL_EXYNOS4
>
> config PINCTRL_MVEBU
> bool
> - depends on ARCH_MVEBU
> + depends on ARCH_MVEBU || ARCH_KIRKWOOD
> select PINMUX
> select PINCONF
Linus Walleij has accepted a patch I have sent yesterday evening that
makes PINCTRL_MVEBU available for all PLAT_ORION platforms, so this
chunk is no longer needed.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/5] ARM: Kirkwood: Allow use of MVEBU GPIO driver.
From: Thomas Petazzoni @ 2012-10-25 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-3-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Wed, 24 Oct 2012 16:25:21 +0200, Andrew Lunn wrote:
> config GPIO_MVEBU
> def_bool y
> - depends on ARCH_MVEBU
> + depends on ARCH_MVEBU || ARCH_KIRKWOOD
> select GPIO_GENERIC
> select GENERIC_IRQ_CHIP
Should we turn the depends on ARCH_MVEBU into a depends on PLAT_ORION,
like I did for the pinctrl driver (patch accepted by Linus Walleij
yesterday) ? I think the dependency on ARCH_MVEBU was making too much
of a shortcut, by assuming that we would very quickly move everybody
into mach-mvebu. As we rather decided to move gradually
mach-{kirkwood,dove,orion5x,mv78xx0} to those infrastructure while
keeping them in their respective directories, I think a dependency on
PLAT_ORION is more appropriate here.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
From: Felipe Balbi @ 2012-10-25 9:00 UTC (permalink / raw)
To: linux-arm-kernel
if we allow compiler reorder our writes, we could
fall into a situation where dev->buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev->buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev->buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev->buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev->buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
This bug has been there forever, but it's quite annoying.
I think it deserves being pushed upstream during this -rc
cycle, but if Wolfram decides to wait until v3.8, I don't
mind.
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..1ec4e6e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
dev->buf = msg->buf;
dev->buf_len = msg->len;
+ wmb();
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev->buf_len);
@@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
*/
timeout = wait_for_completion_timeout(&dev->cmd_complete,
OMAP_I2C_TIMEOUT);
- dev->buf_len = 0;
if (timeout == 0) {
dev_err(dev->dev, "controller timed out\n");
omap_i2c_init(dev);
--
1.8.0
^ permalink raw reply related
* [PATCH 3/5] pinctrl: dove: fix iomem and pdma clock
From: Sebastian Hesselbarth @ 2012-10-25 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYQ+kk1jJ-GfOBd_5pahu-KOTL4GA3_zWP85E6v+h51pA@mail.gmail.com>
On 10/25/2012 09:04 AM, Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 4:25 PM, Andrew Lunn<andrew@lunn.ch> wrote:
>
>> Since 3.7 readl/writel require register addresses to be const void*
>> instead of unsigned int. The register addresses are converted using
>> IOMEM() and offsets are added instead of OR'ed.
>> Also a workaround for the pdma clock is added, that is required as
>> there is still no DT clock provider available on Dove.
>
> So essentially two unrelated patches squashed into one, and I
> would apply the first one right off but now the clock change makes
> me hesitate.
>
>> clk = devm_clk_get(&pdev->dev, NULL);
>> +
>> + /* Currently there is no DT clock provider for pdma clock,
>> + this fallback ensures pdma clock is ticking */
>
> /*
> * I prefer comment style like so because it's easier to read.
> * Maybe it's a bit pedantic but bear with me.
> */
>
>> + if (IS_ERR(clk))
>> + clk = clk_get_sys("dove-pdma", NULL);
>> +
>
> This is a horrible hack. But if the Marvell people agree about
> it I will live with it.
Unfortunately, it is. This is an chicken-egg-problem here, no
DT clk-provider, no clocks properties..
While writing pinctrl-dove I was planing to enable it after
the clock provider but with Andrew pushing forward - for a good
reason - there comes the trouble ;)
I don't like the hack either but the clk-gate is there and
if I don't enable it pinctrl-dove will hang the SoC.
I have a clk-dove DT clk-provider in my pocket somewhere but
didn't find the time to prepare it for posting..
Sebastian
^ permalink raw reply
* [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Huang Shijie @ 2012-10-25 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351145272.7077.8.camel@vkoul-udesk3>
? 2012?10?25? 14:07, Vinod Koul ??:
> On Thu, 2012-10-25 at 13:50 +0800, Huang Shijie wrote:
>> ? 2012?10?25? 12:18, Vinod Koul ??:
>>>> +
>>>> +static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
>>>> +{
>>>> + struct dma_async_tx_descriptor *desc;
>>>> + struct scatterlist *sgl =&s->tx_sgl;
>>>> + struct dma_chan *channel = s->tx_dma_chan;
>>>> + u32 pio;
>>>> +
>>>> + /* [1] : send PIO. Note, the first pio word is CTRL1. */
>>>> + pio = AUART_CTRL1_XFER_COUNT(size);
>>>> + desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)&pio,
>>>> + 1, DMA_TRANS_NONE, 0);
>>> this seems like a hack. API expects a scatterlist as argument.
>>> Same thing about direction, NONE doesnt mean anything for dma transfer.
>> It's not a hack. this DMA descriptor is used to set the registers.
>> Please see the code in drivers/dma/mxs-dma.c:mxs_dam_prep_slave_sg().
> yes it is, and also an abuse of the api.
> prep_slave_sg() expects a scatter list and you are passing something
> else and using DMA_TRANS_NONE to do that, which makes no sense!!!
>
> If you have to setup your registers you need to setup based on what APIs
> passed you and not by abusing.
>
yes. I have to setup the register. Could you told me which API is the
right API?
It seems to the mxs-dma needs a patch again.
>>>> + if (!desc) {
>>>> + dev_err(s->dev, "step 1 error\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + /* [2] : set DMA buffer. */
>>>> + sg_init_one(sgl, s->tx_dma_buf, size);
>>>> + dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
>>>> + desc = dmaengine_prep_slave_sg(channel, sgl,
>>>> + 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>>>> + if (!desc) {
>>>> + dev_err(s->dev, "step 2 error\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + /* [3] : submit the DMA */
>>>> + desc->callback = dma_tx_callback;
>>>> + desc->callback_param = s;
>>>> + dmaengine_submit(desc);
>>>> + dma_async_issue_pending(channel);
>>>> + return 0;
>>>> +}
>>>> +
>>>>
>>>> +static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
>>>> +{
>>>> + struct mxs_auart_port *s = param;
>>>> +
>>>> + if (!mxs_dma_is_apbx(chan))
>>>> + return false;
>>>> +
>>>> + if (s->dma_channel == chan->chan_id) {
>>>> + chan->private =&s->dma_data;
>>> dont use chan->private. You need to dmaengine_slave_config API
>> please see the drivers/dma/mxs-dma.c:mxs_dam_alloc_chan_resoures().
>>
>> The mxs-dma driver uses ->private to store the channel interrupt number.
> And which it should not be doing. private is not supposed to be used for
> passing info. If it is generic add to slave config.
>
Could you give me an example which do not use the private?
The imx-sdma also uses the private to pass some info.
thanks
Huang Shijie
^ permalink raw reply
* [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
From: Shubhrajyoti Datta @ 2012-10-25 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351155648-20429-1-git-send-email-balbi@ti.com>
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi <balbi@ti.com> wrote:
> if we allow compiler reorder our writes, we could
> fall into a situation where dev->buf_len is reset
> for no apparent reason.
>
> This bug was found with a simple script which would
> transfer data to an i2c client from 1 to 1024 bytes
> (a simple for loop), when we got to transfer sizes
> bigger than the fifo size, dev->buf_len was reset
> to zero before we had an oportunity to handle XDR
> Interrupt. Because dev->buf_len was zero, we entered
> omap_i2c_transmit_data() to transfer zero bytes,
> which would mean we would just silently exit
> omap_i2c_transmit_data() without actually writing
> anything to DATA register. That would cause XDR
> IRQ to trigger forever and we would never transfer
> the remaining bytes.
>
> After adding the memory barrier, we also drop resetting
> dev->buf_len to zero in omap_i2c_xfer_msg() because
> both omap_i2c_transmit_data() and omap_i2c_receive_data()
> will act until dev->buf_len reaches zero, rendering the
> other write in omap_i2c_xfer_msg() redundant.
>
> This patch has been tested with pandaboard for a few
> iterations of the script mentioned above.
looks good to me
Acked-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> This bug has been there forever, but it's quite annoying.
> I think it deserves being pushed upstream during this -rc
> cycle, but if Wolfram decides to wait until v3.8, I don't
> mind.
>
> drivers/i2c/busses/i2c-omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..1ec4e6e 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> /* REVISIT: Could the STB bit of I2C_CON be used with probing? */
> dev->buf = msg->buf;
> dev->buf_len = msg->len;
> + wmb();
>
> omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev->buf_len);
>
> @@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> */
> timeout = wait_for_completion_timeout(&dev->cmd_complete,
> OMAP_I2C_TIMEOUT);
> - dev->buf_len = 0;
> if (timeout == 0) {
> dev_err(dev->dev, "controller timed out\n");
> omap_i2c_init(dev);
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv4] Input: keypad: Add smsc ece1099 keypad driver
From: Sourav @ 2012-10-25 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024063559.GA14542@core.coreip.homeip.net>
Hi Dmitry,
On Wednesday 24 October 2012 12:05 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Fri, Oct 05, 2012 at 12:56:26PM +0530, Sourav Poddar wrote:
>> From: G, Manjunath Kondaiah <manjugk@ti.com>
>>
>> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
>> supports a keypad scan matrix of 23*8.This driver uses this
>> device as a keypad driver.
>>
>> Tested on omap5430 evm with 3.6-rc6 custom kernel.
>>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Cc: Felipe Balbi <balbi@ti.com>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>> Acked-by: Felipe Balbi <balbi@ti.com>
>> ---
>> This patch was posted as a series initially
>> http://www.spinics.net/lists/linux-omap/msg78772.html
>>
>> But the parent mfd driver has beeen already picked by mfd maintainer.
>> So this patch can now posted as an standalone patch.
>>
>> v3->v4:
>> Fix Dmitry's comments:
>> - Error patch(input_free_device/input_unregister_device).
>> - Few cleanups.
>> - Included INPUT_MATRIXKMAP
>> drivers/input/keyboard/Kconfig | 12 +
>> drivers/input/keyboard/Makefile | 1 +
>> drivers/input/keyboard/smsc-ece1099-keypad.c | 303 ++++++++++++++++++++++++++
>> 3 files changed, 316 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
>>
>> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
>> index c50fa75..e370b03 100644
>> --- a/drivers/input/keyboard/Kconfig
>> +++ b/drivers/input/keyboard/Kconfig
>> @@ -593,6 +593,18 @@ config KEYBOARD_TWL4030
>> To compile this driver as a module, choose M here: the
>> module will be called twl4030_keypad.
>>
>> +config KEYBOARD_SMSC
>> + tristate "SMSC ECE1099 keypad support"
>> + depends on I2C
>> + select INPUT_MATRIXKMAP
> While I do not see hard dependencies in the driver itself, should we
> also depend on MFD_SMSC?
Ahh, may be yes. This driver will get probed only after parent driver
get probed.
So may be we can follow the same order for building also.
>> + help
>> + Say Y here if your board use the smsc keypad controller
>> + for omap5 defconfig. It's safe to say enable this
>> + even on boards that don't use the keypad controller.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called smsc-ece1099-keypad.
>> +
>> config KEYBOARD_XTKBD
>> tristate "XT keyboard"
>> select SERIO
>> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
>> index 44e7600..0f2aa26 100644
>> --- a/drivers/input/keyboard/Makefile
>> +++ b/drivers/input/keyboard/Makefile
>> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
>> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
>> obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
>> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
>> +obj-$(CONFIG_KEYBOARD_SMSC) += smsc-ece1099-keypad.o
>> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
>> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
>> diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c b/drivers/input/keyboard/smsc-ece1099-keypad.c
>> new file mode 100644
>> index 0000000..a4a0dfe
>> --- /dev/null
>> +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
>> @@ -0,0 +1,303 @@
>> +/*
>> + * SMSC_ECE1099 Keypad driver
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * 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/i2c.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/input.h>
>> +#include <linux/gpio.h>
>> +#include <linux/slab.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/input/matrix_keypad.h>
>> +#include <linux/delay.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/mfd/smsc.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/of.h>
>> +
>> +#define KEYPRESS_TIME 200
>> +
>> +struct smsc_keypad {
>> + struct smsc *smsc;
> I do not see this being actually used.
Yes, will remove.
>> + struct matrix_keymap_data *keymap_data;
> Does not seem to be used.
Yes, will remove.
>> + unsigned int last_key_state[16];
>> + unsigned int last_col;
>> + unsigned int last_key_ms[16];
>> + unsigned short *keymap;
>> + struct i2c_client *client;
>> + struct input_dev *input;
>> + int rows, cols;
>> + int row_shift;
>> + bool no_autorepeat;
>> + unsigned irq;
> I do not think you need to store irq if you are using managed resources.
>
Don't, we need some variable to keep the irq number received after parsing
the dt data.? This variable is basically used as a parameter in
"request_irq" api.
I saw the patch on omap4_keypad switching to managed resource, and there
also we are
keeping the keypad_data->irq intact??
>> + struct device *dev;
>> +};
>> +
>> +static void smsc_kp_scan(struct smsc_keypad *kp)
>> +{
>> + struct input_dev *input = kp->input;
>> + int i, j;
>> + int row, col;
>> + int temp, code;
>> + unsigned int new_state[16];
>> + unsigned int bits_changed;
>> + int this_ms;
>> +
>> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
>> + smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
>> +
>> + /* Scan for row and column */
>> + for (i = 0; i < kp->cols; i++) {
>> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
>> + /* Read Row Status */
>> + smsc_read(kp->dev, SMSC_KP_IN, &temp);
>> + if (temp == 0xFF)
>> + continue;
>> +
>> + col = i;
>> + for (j = 0; j < kp->rows; j++) {
>> + if ((temp & 0x01) != 0x00) {
>> + temp = temp >> 1;
>> + continue;
>> + }
>> +
>> + row = j;
>> + new_state[col] = (1 << row);
>> + bits_changed = kp->last_key_state[col] ^ new_state[col];
>> + this_ms = jiffies_to_msecs(jiffies);
>> + if (bits_changed != 0 || (!bits_changed &&
>> + ((this_ms - kp->last_key_ms[col]) >= KEYPRESS_TIME))) {
>> + code = MATRIX_SCAN_CODE(row, col, kp->row_shift);
>> + input_event(input, EV_MSC, MSC_SCAN, code);
>> + input_report_key(input, kp->keymap[code], 1);
>> + input_report_key(input, kp->keymap[code], 0);
>> + kp->last_key_state[col] = new_state[col];
>> + if (kp->last_col != col)
>> + kp->last_key_state[kp->last_col] = 0;
>> + kp->last_key_ms[col] = this_ms;
>> + }
>> + temp = temp >> 1;
>> + }
>
> Maybe split inner loop into separate function?
Ok.
>> + }
>> + input_sync(input);
>> +
>> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0xFF);
>> +
>> + /* Set up Low Power Mode (Wake-up) (0xFB) */
>> + smsc_write(kp->dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
>> +
>> + /*Enable Keypad Scan (generate interrupt on key press) (0x40)*/
>> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
>> +}
>> +
>> +static irqreturn_t do_kp_irq(int irq, void *_kp)
>> +{
>> + struct smsc_keypad *kp = _kp;
>> + int int_status;
>> +
>> + smsc_read(kp->dev, SMSC_KP_INT_STAT, &int_status);
>> + if (int_status)
>> + smsc_kp_scan(kp);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +#ifdef CONFIG_OF
>> +static int __devinit smsc_keypad_parse_dt(struct device *dev,
>> + struct smsc_keypad *kp)
>> +{
>> + struct device_node *np = dev->of_node;
>> +
>> + if (!np) {
>> + dev_err(dev, "missing DT data");
>> + return -EINVAL;
>> + }
>> +
>> + of_property_read_u32(np, "keypad,num-rows", &kp->rows);
>> + of_property_read_u32(np, "keypad,num-columns", &kp->cols);
>> + if (!kp->rows || !kp->cols) {
>> + dev_err(dev, "number of keypad rows/columns not specified\n");
>> + return -EINVAL;
>> + }
>> +
>> + if (of_property_read_bool(np, "linux,input-no-autorepeat"))
>> + kp->no_autorepeat = true;
>> +
>> + return 0;
>> +}
>> +#else
>> +static inline int smsc_keypad_parse_dt(struct device *dev,
>> + struct smsc_keypad *kp)
>> +{
>> + return -ENOSYS;
>> +}
>> +#endif
>> +
>> +static int __devinit
>> +smsc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct smsc *smsc = dev_get_drvdata(pdev->dev.parent);
>> + struct input_dev *input;
>> + struct smsc_keypad *kp;
>> + int ret = 0;
>> + int i, max_keys, row_shift;
>> + int irq;
>> + int addr;
>> +
>> + kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
>> +
>> + input = input_allocate_device();
>> + if (!kp || !input) {
>> + ret = -ENOMEM;
>> + goto err1;
>> + }
>> +
>> + ret = smsc_keypad_parse_dt(&pdev->dev, kp);
>> + if (ret)
>> + goto err1;
> So this is pure-DT driver. Please add Kconfig dependency on OF, drop
> #ifdef guards and the stub.
Ok.
>> +
>> + /* Get the debug Device */
>> + kp->input = input;
>> + kp->smsc = smsc;
>> + kp->irq = platform_get_irq(pdev, 0);
>> + kp->dev = dev;
>> +
>> + /* setup input device */
>> + __set_bit(EV_KEY, input->evbit);
>> +
>> + /* Enable auto repeat feature of Linux input subsystem */
>> + if (!kp->no_autorepeat)
>> + __set_bit(EV_REP, input->evbit);
>> +
>> + input_set_capability(input, EV_MSC, MSC_SCAN);
>> + input->name = "SMSC Keypad";
>> + input->phys = "smsc_keypad/input0";
>> + input->dev.parent = &pdev->dev;
>> + input->id.bustype = BUS_HOST;
>> + input->id.vendor = 0x0001;
>> + input->id.product = 0x0001;
>> + input->id.version = 0x0003;
>> +
>> + /* Mask all GPIO interrupts (0x37-0x3B) */
>> + for (addr = SMSC_GPIO_INT_MASK_START;
>> + addr < SMSC_GPIO_INT_MASK_START + 4; addr++)
>> + smsc_write(dev, addr, 0);
>> +
>> + /* Set all outputs high (0x05-0x09) */
>> + for (addr = SMSC_GPIO_DATA_OUT_START;
>> + addr < SMSC_GPIO_DATA_OUT_START + 4; addr++)
>> + smsc_write(dev, addr, 0xff);
>> +
>> + /* Clear all GPIO interrupts (0x32-0x36) */
>> + for (addr = SMSC_GPIO_INT_STAT_START;
>> + addr < SMSC_GPIO_INT_STAT_START + 4; addr++)
>> + smsc_write(dev, addr, 0xff);
> You use lowercase hex digits here but also uppercase in other parts of
> the driver. Can we use lowercase throughout please?
Will do.
>> +
>> + /* Configure the smsc pins as Keyboard scan Input */
>> + for (i = 0; i <= kp->rows; i++) {
> You sure you don't want < instead of <= ?
>
Really, "=" should not be there.
>> + addr = 0x12 + i;
>> + smsc_write(dev, addr, SMSC_KP_KSI);
>> + }
>> +
>> + /* Configure the smsc pins as Keyboard scan output */
>> + for (i = 0; i <= kp->cols; i++) {
>> + addr = 0x1A + i;
>> + smsc_write(dev, addr, SMSC_KP_KSO);
>> + }
>> +
>> + smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
>> + smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
>> + smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
>> +
>> + row_shift = get_count_order(kp->cols);
>> + max_keys = kp->rows << row_shift;
>> +
>> + kp->row_shift = row_shift;
>> + kp->keymap = devm_kzalloc(dev, max_keys * sizeof(kp->keymap[0]),
>> + GFP_KERNEL);
>> + if (!kp->keymap) {
>> + dev_err(&pdev->dev, "Not enough memory for keymap\n");
>> + ret = -ENOMEM;
>> + }
>> +
>> + ret = matrix_keypad_build_keymap(NULL, NULL, kp->rows,
>> + kp->cols, kp->keymap, input);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to build keymap\n");
>> + goto err1;
>> + }
>> +
>> + /*
>> + * This ISR will always execute in kernel thread context because of
>> + * the need to access the SMSC over the I2C bus.
>> + */
>> + ret = devm_request_threaded_irq(dev, kp->irq, NULL, do_kp_irq,
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev->name, kp);
>> + if (ret) {
>> + dev_dbg(&pdev->dev, "request_irq failed for irq no=%d\n",
>> + irq);
>> + goto err1;
>> + }
>> +
>> + /* Enable smsc keypad interrupts */
>> + ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
>> + if (ret < 0)
>> + goto err2;
> Consider implementing ->open() and ->close() and putting the above
> there.
Ok.
>> +
>> + ret = input_register_device(input);
>> + if (ret) {
>> + dev_err(kp->dev,
>> + "Unable to register twl4030 keypad device\n");
>> + goto err2;
>> + }
>> +
>> + return 0;
>> +
>> +err2:
>> + free_irq(kp->irq, kp);
> If you allocate IRQ with devm_request_threaded_irq then you should free
> it with devm_free_irq().
Ok. Will change.
>> +err1:
>> + input_free_device(input);
>> + return ret;
>> +}
>> +
>> +static int __devexit smsc_remove(struct platform_device *pdev)
>> +{
>> + struct smsc_keypad *kp = platform_get_drvdata(pdev);
>> + input_unregister_device(kp->input);
> This is wrong: input device is gone but IRQs are still active. You need
> to disable or free IRQ first.
>
> However I just posted a patch adding support for managed input devices:
>
> http://www.spinics.net/lists/linux-input/msg23077.html
>
> so please either switch over, or go with unmanaged resources
> throughout.
Will switch to the managed protocol throughout.
>> +
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_OF
> Since we require DT this ifdef is not needed.
Will remove.
>> +static const struct of_device_id smsc_keypad_dt_match[] = {
>> + { .compatible = "smsc,keypad" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, smsc_keypad_dt_match);
>> +#endif
>> +
>> +static struct platform_driver smsc_driver = {
>> + .driver = {
>> + .name = "smsc-keypad",
>> + .of_match_table = of_match_ptr(smsc_keypad_dt_match),
>> + .owner = THIS_MODULE,
>> + },
>> + .probe = smsc_probe,
>> + .remove = __devexit_p(smsc_remove),
>> +};
>> +
>> +module_platform_driver(smsc_driver);
>> +
>> +MODULE_AUTHOR("G Kondaiah Manjunath <manjugk@ti.com>");
>> +MODULE_DESCRIPTION("SMSC ECE1099 Keypad driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 1.7.1
>>
> Thanks.
>
^ permalink raw reply
* [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver
From: Ulf Hansson @ 2012-10-25 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025082341.GC3348@gmail.com>
On 25 October 2012 10:23, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Oct 2012, Linus Walleij wrote:
>
>> On 10/25/2012 09:31 AM, Lee Jones wrote:
>> >
>> >This certainly doesn't fix the bug we spoke about. I believe Ulf
>> >is still working on that one.
>> >
>> >So do you want me to remove this patch?
>> >
>>
>> Yeah drop it for now.
>
> Actually, a quick question before I do:
>
> If it's better/faster to prepare the clock and keep it prepared
> while you do clk_enable/clk_disable, why don't we do that in all
> drivers? Why do we bother to prepare/unprepare each time if all
> it does is take up cycles?
>
Depending on clock type, a clk_disable is actually not going to "gate"
the clock, that might happen only in unprepare. This depends on if the
clock is a fast or slow clock.
To save as much power as possible, in general, we should do both
disable and unprepare. Although it will be device driver dependent
were it is most convenient to do this things.
Sometimes it is possible to group them sometimes not.
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 2/2] ASoC: ux500_msp_i2s: Fix devm_* and return code merge error
From: Ulf Hansson @ 2012-10-25 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024102707.GC18814@opensource.wolfsonmicro.com>
On 24 October 2012 12:27, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Oct 24, 2012 at 11:34:00AM +0200, Ulf Hansson wrote:
>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> I assume this shall go into 3.7, right?
>>
>> Kind regards
>> Ulf Hansson
>
> You may recall that only yesterday I reminded you not to top post...
Sorry, I have a short memory. :-) I will try to improve.
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Johannes Stezenbach @ 2012-10-25 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959402-24164-1-git-send-email-robherring2@gmail.com>
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
>
> With recent compilers and move to generic unaligned.h in commit d25c881
> (ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
> by the LZO decompressor on v7 cores. So we need to make sure unaligned
> accesses are allowed by clearing the SCTLR A bit.
I just read this in http://gcc.gnu.org/gcc-4.7/changes.html:
On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or
ARMv7-M, the new option -munaligned-access is active by default, which for
some source codes generates code that accesses memory on unaligned addresses.
This will require the kernel of those systems to enable such accesses
(controlled by CP15 register c1, refer to ARM documentation). Alternatively
or for compatibility with kernels where unaligned accesses are not supported,
all code has to be compiled with -mno-unaligned-access. Linux/ARM in official
releases has automatically and unconditionally supported unaligned accesses
as emitted by GCC due to this option being active, since Linux version 2.6.28.
My understanding is that gcc, using the same generic unaligned.h
source code, will generate code for ARMv6 and ARMv7 that uses
unaligned access, while for ARMv5 and older it won't. So it seems
gcc requires Linux to clear SCTLR.A and set SCTLR.U for ARMv6+.
Or add -mno-unaligned-access.
Is my understanding correct?
> While v6 can support unaligned accesses, it is optional and current
> compilers won't emit unaligned accesses. So we don't clear the A bit for
> v6.
not true according to the gcc changes page
Thanks
Johannes
^ permalink raw reply
* [PATCH v2] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti Datta @ 2012-10-25 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025063608.GA5084@arwen.pp.htv.fi>
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi <balbi@ti.com> wrote:
[...]
>> + * Don't write to this register if the IE state is 0 as it can
>> + * cause deadlock.
>> + */
>> + if (dev->iestate)
>> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
>> +}
>> +
>> static int omap_i2c_init(struct omap_i2c_dev *dev)
>> {
>> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
>> + u16 psc = 0, scll = 0, sclh = 0;
>> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
>> unsigned long fclk_rate = 12000000;
>> unsigned long timeout;
>> @@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>> * REVISIT: Some wkup sources might not be needed.
>> */
>> dev->westate = OMAP_I2C_WE_ALL;
>> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
>> - dev->westate);
>
> remove the comment too since now that's done by some other function ?
The comment is applicable to the OMAP_I2C_WE_ALL value.
So I thought it could be kept.
dont feel strongly though.
>
>> }
^ permalink raw reply
* [GIT PULL] ux500 fixes due for v3.7 RCs
From: Lee Jones @ 2012-10-25 9:41 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-rcs-3.7
for you to fetch changes up to 76ff4e434734f7772d1a592cc9fe1d9921a3ec40:
ARM: ux500: Correct SDI5 address and add some format changes (2012-10-25 08:46:20 +0100)
----------------------------------------------------------------
Lee Jones (3):
ARM: ux500: Fix build error relating to IRQCHIP_SKIP_SET_WAKE
ARM: ux500: Specify AMBA Primecell IDs for Nomadik I2C in DT
ARM: ux500: Correct SDI5 address and add some format changes
arch/arm/boot/dts/dbx5x0.dtsi | 17 ++++++++++++++++-
arch/arm/mach-ux500/cpu.c | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-10-25 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50889BB2.3090107@ti.com>
Hi Jon,
On 25.10.2012 03:53, Jon Hunter wrote:
>
> On 10/22/2012 02:55 PM, Daniel Mack wrote:
>> +Example for an AM33xx board:
>> +
>> + gpmc: gpmc at 50000000 {
>> + compatible = "ti,gpmc";
>> + ti,hwmods = "gpmc";
>> + reg = <0x50000000 0x1000000>;
>
> Nit-pick, that size is quite large for a register range. I recommend
> looking at the HWMOD data file
> (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is
> allocated for the registers (see structure am33xx_gpmc_addr_space).
Yeah but reserving the entire memory as per the reference manual also
prvents other from poking around in the same register space. Is there a
scenario in which it would of disadvantage to reserve all that memory?
Daniel
^ permalink raw reply
* [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver
From: Lee Jones @ 2012-10-25 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFromkv_VYgiQsERR=PbrwYqgux=teF_HSZxCtk2BCsk1A@mail.gmail.com>
On Thu, 25 Oct 2012, Ulf Hansson wrote:
> On 25 October 2012 10:23, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Oct 2012, Linus Walleij wrote:
> >
> >> On 10/25/2012 09:31 AM, Lee Jones wrote:
> >> >
> >> >This certainly doesn't fix the bug we spoke about. I believe Ulf
> >> >is still working on that one.
> >> >
> >> >So do you want me to remove this patch?
> >> >
> >>
> >> Yeah drop it for now.
> >
> > Actually, a quick question before I do:
> >
> > If it's better/faster to prepare the clock and keep it prepared
> > while you do clk_enable/clk_disable, why don't we do that in all
> > drivers? Why do we bother to prepare/unprepare each time if all
> > it does is take up cycles?
> >
>
> Depending on clock type, a clk_disable is actually not going to "gate"
> the clock, that might happen only in unprepare. This depends on if the
> clock is a fast or slow clock.
> To save as much power as possible, in general, we should do both
> disable and unprepare. Although it will be device driver dependent
> were it is most convenient to do this things.
> Sometimes it is possible to group them sometimes not.
And in this case, it's better to ... ?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] input: gpio-keys: Add runtime support
From: Lee Jones @ 2012-10-25 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025083046.GA13882@core.coreip.homeip.net>
On Thu, 25 Oct 2012, Dmitry Torokhov wrote:
> On Thu, Oct 25, 2012 at 09:21:45AM +0100, Lee Jones wrote:
> > On Thu, 25 Oct 2012, Linus Walleij wrote:
> >
> > > On Thu, Oct 25, 2012 at 9:57 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > On Fri, 12 Oct 2012, Linus Walleij wrote:
> > >
> > > >> Yours,
> > > >> Linus Walleij
> > > >
> > > > Friendly poke.
> > >
> > > This makes it look like you're poking me as I'm in the To: field but I suspect
> > > the intent must be to poke Dmitry ... I was just providing background
> > > for Shubhrajyoti's question.
> > >
> > > Maybe this helps:
> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > Yes, that was also the intention of the other poke. Sorry about
> > that, I should have moved you into Cc: instead.
> >
> > Yes, the poke was for Dmitry.
>
> Still do not have the right signoffs: person who sends me the patch needs
> to put signed-off-by, not acked-by.
My apologies.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/8] Ux5x0 patches loosely surrounding u9540 enablement
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
Kept together mostly for tracking convenience, this patch-set is
the result of platform tweaking during u9540 enablement.
arch/arm/boot/dts/ccu9540.dts | 72 +++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/dbx5x0.dtsi | 14 ++++++++
arch/arm/boot/dts/hrefprev60.dts | 2 +-
arch/arm/boot/dts/hrefv60plus.dts | 2 +-
arch/arm/boot/dts/snowball.dts | 2 +-
arch/arm/boot/dts/stuib.dtsi | 2 +-
arch/arm/boot/dts/u9540.dts | 47 ------------------------
arch/arm/configs/u8500_defconfig | 1 +
arch/arm/mach-ux500/cpu-db8500.c | 27 +++++---------
9 files changed, 100 insertions(+), 69 deletions(-)
^ permalink raw reply
* [PATCH 1/8] ARM: ux500: Enable all MMC devices on the u9540 when booting with DT
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
The u9540 supports 3 MMC devices. This patch enables two of them
and updates the configuration of the already enabled SDI4 port.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/u9540.dts | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
index 2dade76..95892ec 100644
--- a/arch/arm/boot/dts/u9540.dts
+++ b/arch/arm/boot/dts/u9540.dts
@@ -33,10 +33,35 @@
status = "okay";
};
+ // External Micro SD slot
+ sdi0_per1 at 80126000 {
+ arm,primecell-periphid = <0x10480180>;
+ max-frequency = <100000000>;
+ bus-width = <4>;
+ mmc-cap-sd-highspeed;
+ mmc-cap-mmc-highspeed;
+ vmmc-supply = <&ab8500_ldo_aux3_reg>;
+
+ cd-gpios = <&gpio7 6 0x4>; // 230
+ cd-inverted;
+
+ status = "okay";
+ };
+
+
+ // WLAN SDIO channel
+ sdi1_per2 at 80118000 {
+ arm,primecell-periphid = <0x10480180>;
+ max-frequency = <50000000>;
+ bus-width = <4>;
+
+ status = "okay";
+ };
+
// On-board eMMC
sdi4_per2 at 80114000 {
arm,primecell-periphid = <0x10480180>;
- max-frequency = <50000000>;
+ max-frequency = <100000000>;
bus-width = <8>;
mmc-cap-mmc-highspeed;
vmmc-supply = <&ab8500_ldo_aux2_reg>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/8] ARM: ux500: Rename references to the ccu9540 dev board accordingly
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
When enabling ST-Ericsson's ccu9540 development board the board's
full name has not been used. This patch adapts all references of
the board's short name to how it should be referenced.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/{u9540.dts => ccu9540.dts} | 4 ++--
arch/arm/mach-ux500/cpu-db8500.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
rename arch/arm/boot/dts/{u9540.dts => ccu9540.dts} (93%)
diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/ccu9540.dts
similarity index 93%
rename from arch/arm/boot/dts/u9540.dts
rename to arch/arm/boot/dts/ccu9540.dts
index 95892ec..26dfe83 100644
--- a/arch/arm/boot/dts/u9540.dts
+++ b/arch/arm/boot/dts/ccu9540.dts
@@ -13,8 +13,8 @@
/include/ "dbx5x0.dtsi"
/ {
- model = "ST-Ericsson U9540 platform with Device Tree";
- compatible = "st-ericsson,u9540";
+ model = "ST-Ericsson CCU9540 platform with Device Tree";
+ compatible = "st-ericsson,ccu9540";
memory {
reg = <0x00000000 0x20000000>;
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 0b15591..6e9a06d 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -320,8 +320,8 @@ static void __init u8500_init_machine(void)
snowball_pinmaps_init();
else if (of_machine_is_compatible("st-ericsson,hrefv60+"))
hrefv60_pinmaps_init();
- else if (of_machine_is_compatible("st-ericsson,u9540")) {}
- /* TODO: Add u9540 pinmaps. */
+ else if (of_machine_is_compatible("st-ericsson,ccu9540")) {}
+ /* TODO: Add pinmaps for ccu9540 board. */
/* TODO: Export SoC, USB, cpu-freq and DMA40 */
parent = u8500_of_init_devices();
@@ -334,7 +334,7 @@ static const char * u8500_dt_board_compat[] = {
"calaosystems,snowball-a9500",
"st-ericsson,hrefv60+",
"st-ericsson,mop500",
- "st-ericsson,u9540",
+ "st-ericsson,ccu9540",
NULL,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/8] ARM: ux500: Remove duplicate DT_MACHINE_START - make u8500 for generic
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
The u8500 and u9540 DT_MACHINE_START calls are almost identical
at the moment, referencing exactly the same function pointers.
Until this changes we may as well convert the original one to
be more generic and use that instead.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 6e9a06d..472b49f 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -338,7 +338,7 @@ static const char * u8500_dt_board_compat[] = {
NULL,
};
-DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500 platform (Device Tree Support)")
+DT_MACHINE_START(U8500_DT, "ST-Ericsson Ux5x0 platform (Device Tree Support)")
.map_io = u8500_map_io,
.init_irq = ux500_init_irq,
/* we re-use nomadik timer here */
@@ -349,14 +349,4 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500 platform (Device Tree Support)")
.dt_compat = u8500_dt_board_compat,
MACHINE_END
-DT_MACHINE_START(U9540_DT, "ST-Ericsson 9540 platform (Device Tree Support)")
- .map_io = u8500_map_io,
- .init_irq = ux500_init_irq,
- .timer = &ux500_timer,
- .handle_irq = gic_handle_irq,
- .init_machine = u8500_init_machine,
- .init_late = NULL,
- .dt_compat = u8500_dt_board_compat,
-MACHINE_END
-
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/8] ARM: ux500: List DT compatibility using platform names rather than by board
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
So far, each ST-Ericsson board supported by Device Tree has been similar
enough to run though a single DT_MACHINE_INIT call. On the back of that
it has been suggested that we should reduce the number of compatible
strings in our dt_compat structure. After subsequent discussion with Arnd
Bergmann the conclusion was to list entries by platform as opposed to by
board.
The other suggestion was to use a single string which would cover all
supported platforms, but any wildcard entries would include unsupported
chipsets, such as the u5500 and potential new chips which no not yet have
DT functionality. Hence, the best solution which encompasses all supported
platforms, but no unsupported ones was to list the currently enabled four
chipsets; u8500, u8540, u9500 and u9540 instead.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/ccu9540.dts | 2 +-
arch/arm/boot/dts/hrefprev60.dts | 2 +-
arch/arm/boot/dts/hrefv60plus.dts | 2 +-
arch/arm/boot/dts/snowball.dts | 2 +-
arch/arm/mach-ux500/cpu-db8500.c | 12 ++++++------
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ccu9540.dts
index 26dfe83..0430546 100644
--- a/arch/arm/boot/dts/ccu9540.dts
+++ b/arch/arm/boot/dts/ccu9540.dts
@@ -14,7 +14,7 @@
/ {
model = "ST-Ericsson CCU9540 platform with Device Tree";
- compatible = "st-ericsson,ccu9540";
+ compatible = "st-ericsson,ccu9540", "st-ericsson,u9540";
memory {
reg = <0x00000000 0x20000000>;
diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
index cd9e535..b398946 100644
--- a/arch/arm/boot/dts/hrefprev60.dts
+++ b/arch/arm/boot/dts/hrefprev60.dts
@@ -16,7 +16,7 @@
/ {
model = "ST-Ericsson HREF (pre-v60) platform with Device Tree";
- compatible = "st-ericsson,mop500";
+ compatible = "st-ericsson,mop500", "st-ericsson,u8500";
gpio_keys {
button at 1 {
diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 82103a2..a01ac8f 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -16,7 +16,7 @@
/ {
model = "ST-Ericsson HREF (v60+) platform with Device Tree";
- compatible = "st-ericsson,hrefv60+";
+ compatible = "st-ericsson,hrefv60+", "st-ericsson,u8500";
gpio_keys {
button at 1 {
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 6a2b58b..9e02a91 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -14,7 +14,7 @@
/ {
model = "Calao Systems Snowball platform with device tree";
- compatible = "calaosystems,snowball-a9500";
+ compatible = "calaosystems,snowball-a9500", "st-ericsson,u9500";
memory {
reg = <0x00000000 0x20000000>;
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 472b49f..c65e7e3 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -330,11 +330,11 @@ static void __init u8500_init_machine(void)
of_platform_populate(NULL, u8500_local_bus_nodes, u8500_auxdata_lookup, parent);
}
-static const char * u8500_dt_board_compat[] = {
- "calaosystems,snowball-a9500",
- "st-ericsson,hrefv60+",
- "st-ericsson,mop500",
- "st-ericsson,ccu9540",
+static const char * stericsson_dt_platform_compat[] = {
+ "st-ericsson,u8500",
+ "st-ericsson,u8540",
+ "st-ericsson,u9500",
+ "st-ericsson,u9540",
NULL,
};
@@ -346,7 +346,7 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson Ux5x0 platform (Device Tree Support)")
.handle_irq = gic_handle_irq,
.init_machine = u8500_init_machine,
.init_late = NULL,
- .dt_compat = u8500_dt_board_compat,
+ .dt_compat = stericsson_dt_platform_compat,
MACHINE_END
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/8] ARM: ux500: Add node for the MMC GPIO regulator
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
There is a very simple mechanism to change and SDI's voltage which
consists of toggling some GPIOs. This scenario can be better handled
if we convert it to a GPIO regulator. This patch provides one which
can be read from Device Tree.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 07a085b..536df5d 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -614,5 +614,19 @@
ranges = <0 0x50000000 0x4000000>;
status = "disabled";
};
+
+ vmmci: regulator-gpio {
+ compatible = "regulator-gpio";
+
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2600000>;
+ regulator-name = "mmci-reg";
+ regulator-type = "voltage";
+
+ gpios = <&tc3589x_gpio 18 0x4>;
+ gpio-enable = <&tc3589x_gpio 17 0x4>;
+ states = <1800000 0x1
+ 2900000 0x0>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/8] ARM: ux500: Change the type of interrupt to something compatible
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
On boot the Nomadik GPIO controller complains that an IRQ can't be
configured as active high level-sensitive, so this patch converts
it to be low-to-high edge triggered instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stuib.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stuib.dtsi b/arch/arm/boot/dts/stuib.dtsi
index 6c7e492..39446a2 100644
--- a/arch/arm/boot/dts/stuib.dtsi
+++ b/arch/arm/boot/dts/stuib.dtsi
@@ -15,7 +15,7 @@
stmpe1601: stmpe1601 at 40 {
compatible = "st,stmpe1601";
reg = <0x40>;
- interrupts = <26 0x4>;
+ interrupts = <26 0x1>;
interrupt-parent = <&gpio6>;
interrupt-controller;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/8] ARM: ux500: CONFIG: Enable GPIO Regulators
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
It is the intention to convert the MMC voltage changing from
GPIO flipping to using a proper GPIO regulator interface. A
prerequisite of that is to enable the GPIO regulator
functionality. As this affects all ux5x0 based boards we'll
do it here instead of in the Kconfigs.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/configs/u8500_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 0575d8a..50d3c22 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -76,6 +76,7 @@ CONFIG_AB8500_CORE=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_GPIO=y
# CONFIG_HID_SUPPORT is not set
CONFIG_USB_GADGET=y
CONFIG_AB8500_USB=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/8] ARM: ux500: Convert DT_MACHINE_START to use SMP operations
From: Lee Jones @ 2012-10-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351159031-25391-1-git-send-email-lee.jones@linaro.org>
The Device Tree machine description for the ux5x0 was moved
recently and as a consequence missed the addition of SMP
operations. Without this patch SMP doesn't work and only one
CPU is present after booting.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index c65e7e3..4a0c40a 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -339,6 +339,7 @@ static const char * stericsson_dt_platform_compat[] = {
};
DT_MACHINE_START(U8500_DT, "ST-Ericsson Ux5x0 platform (Device Tree Support)")
+ .smp = smp_ops(ux500_smp_ops),
.map_io = u8500_map_io,
.init_irq = ux500_init_irq,
/* we re-use nomadik timer here */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] i2c: omap: re-factor omap_i2c_init function
From: Felipe Balbi @ 2012-10-25 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=Q2ctcxO2eFFBDdF_Mwt1bm34pj5hvJW4AS6V-GQVTVGz98Q@mail.gmail.com>
Hi,
On Thu, Oct 25, 2012 at 03:04:29PM +0530, Shubhrajyoti Datta wrote:
> On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi <balbi@ti.com> wrote:
>
> [...]
> >> + * Don't write to this register if the IE state is 0 as it can
> >> + * cause deadlock.
> >> + */
> >> + if (dev->iestate)
> >> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> >> +}
> >> +
> >> static int omap_i2c_init(struct omap_i2c_dev *dev)
> >> {
> >> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
> >> + u16 psc = 0, scll = 0, sclh = 0;
> >> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> >> unsigned long fclk_rate = 12000000;
> >> unsigned long timeout;
> >> @@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> >> * REVISIT: Some wkup sources might not be needed.
> >> */
> >> dev->westate = OMAP_I2C_WE_ALL;
> >> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> >> - dev->westate);
> >
> > remove the comment too since now that's done by some other function ?
>
> The comment is applicable to the OMAP_I2C_WE_ALL value.
> So I thought it could be kept.
>
> dont feel strongly though.
I see. that's ok then.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/9ddee6e4/attachment.sig>
^ 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