* [PATCH 07/10] input: Enable STMPE keypad driver for Device Tree
From: Dmitry Torokhov @ 2012-10-10 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349451107-8009-8-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Fri, Oct 05, 2012 at 04:31:43PM +0100, Lee Jones wrote:
> This patch allows the STMPE driver to be successfully probed and
> initialised when Device Tree support is enabled. Besides the usual
> platform data changes, we also separate the process of filling in
> the 'in use' pin bitmap, as we have to extract the information from
> Device Tree in the DT boot case.
This generally looks OK although I wonder if we could not unify DT and
non-DT case by doing:
for (row = 0; row < STMPE_KEYPAD_MAX_ROWS; row++) {
if (col = 0; col < STMPE_KEYPAD_MAX_COLS; col++) {
int code = MATRIX_SCAN_CODE(row, col,
STMPE_KEYPAD_ROW_SHIFT);
if (keypad->keymap[code] != KEY_RESERVED) {
keypad->rows |= 1 << row;
keypad->cols |= 1 << col;
}
}
}
BTW, am I supposed to merge it or ack it?
Thanks!
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input at vger.kernel.org
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/input/keyboard/stmpe-keypad.c | 67 ++++++++++++++++++++++++++++-----
> drivers/mfd/stmpe.c | 1 +
> 2 files changed, 59 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/keyboard/stmpe-keypad.c b/drivers/input/keyboard/stmpe-keypad.c
> index 470a877..c722d23 100644
> --- a/drivers/input/keyboard/stmpe-keypad.c
> +++ b/drivers/input/keyboard/stmpe-keypad.c
> @@ -257,19 +257,73 @@ static int __devinit stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
> (plat->debounce_ms << 1));
> }
>
> +static int stmpe_keypad_fill_used_pins(struct platform_device *pdev,
> + struct stmpe_keypad *keypad,
> + struct stmpe_keypad_platform_data *plat)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + unsigned int proplen;
> + const __be32 *prop;
> + int i;
> +
> + if (np) {
> + prop = of_get_property(np, "linux,keymap", &proplen);
> + if (!prop) {
> + dev_err(&pdev->dev,
> + "linux,keymap property not defined\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < proplen / sizeof(u32); i++) {
> + unsigned int key = be32_to_cpup(prop + i);
> +
> + keypad->cols |= 1 << KEY_COL(key);
> + keypad->rows |= 1 << KEY_ROW(key);
> + }
> + } else {
> + for (i = 0; i < plat->keymap_data->keymap_size; i++) {
> + unsigned int key = plat->keymap_data->keymap[i];
> +
> + keypad->cols |= 1 << KEY_COL(key);
> + keypad->rows |= 1 << KEY_ROW(key);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void __devinit stmpe_keypad_of_probe(struct device_node *np,
> + struct stmpe_keypad_platform_data *plat)
> +{
> + of_property_read_u32(np, "debounce-interval", &plat->debounce_ms);
> + of_property_read_u32(np, "stericsson,scan-count", &plat->scan_count);
> +
> + if (of_get_property(np, "stericsson,no-autorepeat", NULL))
> + plat->no_autorepeat = true;
> +}
> +
> static int __devinit stmpe_keypad_probe(struct platform_device *pdev)
> {
> struct stmpe *stmpe = dev_get_drvdata(pdev->dev.parent);
> struct stmpe_keypad_platform_data *plat;
> + struct device_node *np = pdev->dev.of_node;
> struct stmpe_keypad *keypad;
> struct input_dev *input;
> int ret;
> int irq;
> - int i;
>
> plat = stmpe->pdata->keypad;
> - if (!plat)
> - return -ENODEV;
> + if (!plat) {
> + if (np) {
> + plat = devm_kzalloc(&pdev->dev,
> + sizeof(*plat), GFP_KERNEL);
> + if (!plat)
> + return -ENOMEM;
> +
> + stmpe_keypad_of_probe(np, plat);
> + } else
> + return -ENODEV;
> + }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0)
> @@ -300,12 +354,7 @@ static int __devinit stmpe_keypad_probe(struct platform_device *pdev)
> if (!plat->no_autorepeat)
> __set_bit(EV_REP, input->evbit);
>
> - for (i = 0; i < plat->keymap_data->keymap_size; i++) {
> - unsigned int key = plat->keymap_data->keymap[i];
> -
> - keypad->cols |= 1 << KEY_COL(key);
> - keypad->rows |= 1 << KEY_ROW(key);
> - }
> + stmpe_keypad_fill_used_pins(pdev, keypad, plat);
>
> keypad->stmpe = stmpe;
> keypad->plat = plat;
> diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
> index ba157d4..b03cc64 100644
> --- a/drivers/mfd/stmpe.c
> +++ b/drivers/mfd/stmpe.c
> @@ -321,6 +321,7 @@ static struct resource stmpe_keypad_resources[] = {
>
> static struct mfd_cell stmpe_keypad_cell = {
> .name = "stmpe-keypad",
> + .of_compatible = "st,stmpe-keypad",
> .resources = stmpe_keypad_resources,
> .num_resources = ARRAY_SIZE(stmpe_keypad_resources),
> };
> --
> 1.7.9.5
>
--
Dmitry
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Linus Walleij @ 2012-10-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b88c853b3691338fae037f569917fc300cd6032.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> read_buf/write_buf callbacks should be able to accept a user space memory
> address (virtually contiguous memory) as buffer pointer.
>
> This patch allocates a logically contiguous memory area which is use for dma
You mean PHYSICALLY contigous, don't you?
> xfers during read and write accesses.
>
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
If you really want a physically contigous buffer you need to use
CMA, but I don't think that is the real problem here...
We're already using userspace buffers in e.g. the MMCI driver
(drivers/mmc/host/mmci.c).
The real problem is likely the DMA driver. The stuf that get
fed into dma.device_prep_dma_memcpy() needs to be
converted to a scatterlist and then set up in the LLI list
for the controller.
IIRC SPEAr is using drivers/dma/dw_dmac.c so
check this driver's dwc_prep_dma_memcpy().
It does seem like it is checking whether src or
dest is scattered in this for() loop:
for (offset = 0; offset < len; offset += xfer_count << src_width) {}
dma_sync_single_for_device() is translating the virtual
address to physical for every chunk BTW.
So instead of doing this copying, debug the problem, and
see if there is a bug in that for()-loop or similar, if it needs
to be rewritten or so.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Ivan Djelic @ 2012-10-10 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9CA829@DBDE01.ent.ti.com>
On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote:
(...)
> > There are at least 2 potential problems when reading an erased page with bitflips:
> >
> > 1. bitflip in data area and no bitflip in spare area (all 0xff)
> > Your code will not perform any ECC correction.
> > UBIFS does not like finding bitflips in empty pages, see for instance
> > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
>
> In case of error correction using ELM, syndrome vector calculated after reading
> Data area & OOB area. So handling of erased page requires a software workaround.
> I am planning something as follows.
>
> I will first check calculated ecc, which would be zero for non error pages.
> Then I would check 0xFF in OOB area (for erased page) by checking number of
> bit zeros in OOB area. If it is 0xFF (number of bit zero count is zero),
> set entire page as 0xFF if number of bit zeros is less than max bit flips
> (8 or 4) by counting the number of bit zero's in data area.
>
> This logic is implemented in fsmc_nand.c
>
> See commit
> mtd: fsmc: Newly erased page read algorithm implemented
>
> >
> > 2. bitflip in ECC bytes in spare area
> > Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
> > I guess you will lose data.
>
> In case of uncorrectable errors due to bit flips in spare area,
> I can go on checking number of bit zero's in data area + OOB area
> are less than max bit flips (8 or 4), I can go on setting the entire
> page as 0xFF.
>
OK, sounds reasonable.
Another simple strategy could use the fact that you add a 14th zero byte to
the 13 BCH bytes for RBL compatibility:
Upon reading:
- if this 14th byte is zero (*) => page was programmed: perform ECC
correction as usual
- else, page was not programmed: do not perform ECC, read entire data+spare
area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits
were found
(*) for robustness to bitflip in 14th byte, replace condition
"14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1".
What do you think ?
BR,
--
Ivan
^ permalink raw reply
* [PATCH 08/11] fsmc/nand: Use relaxed variants of io accessors
From: Linus Walleij @ 2012-10-10 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88484dbae96f7db42ce615552a4c758844a5e6cc.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> Use relaxed variants of readl/writel accessors. readl/writel io accessors use
> explicit dsb instruction which causes stalls in the processor core resulting
> several cycles of delay for each access
>
> Use relaxed variants where ever possible. This also results in an improved
> read/write performance.
>
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
Good idea for any performance-critical code! Thanks!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 06/11] fsmc/nand: Modify the wait to uninterruptible
From: Linus Walleij @ 2012-10-10 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3dcb002d0ad03dde9a91e8128dbaa320b8a264a9.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> Interruptible wait caused trouble in fsmc hardware state machine if the
> application was killed abruptly. To make fsmc operation safe turn wait in to
> un-interruptible.
>
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
Yes this is wise.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 09/11] fsmc/nand:FIX: replace change_bit routine
From: Linus Walleij @ 2012-10-10 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec169eb041e87e66c06108e85ea4a67e5797cecc.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> change_bit routine accepts only ulong pointers as buffer, so an unaligned char
> pointer passed to change_bit may lead to a crash.
>
> Fix this bug by accessing the buffer as char pointer.
Why not see if we can fix change_bit() instead?
Since I suspect this is on ARM I bet Russell and Nico
want to hear about this if there is a problem.
Can the ARM change_bit() not be fixed, so that
long arguments are the only option?
> if (err_idx[i] < chip->ecc.size * 8) {
> - change_bit(err_idx[i], (unsigned long *)dat);
> + uint8_t *p = dat + err_idx[i] / 8;
> + *p = *p ^ (1 << (err_idx[i] % 8));
I'm one of these people who would write >>3 and
&7 rather than /8 or %8 but I guess we are all
different. Atleast consider it if you stick with this...
Yours,
Linus Walleij
^ permalink raw reply
* [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
From: Linus Walleij @ 2012-10-10 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349885000-22887-1-git-send-email-ulf.hansson@stericsson.com>
On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Looks correct to me:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
I guess this goes into Russell's patch tracker.
Yours,
Linus Walleij
^ permalink raw reply
* [RESEND PATCH 2/2] mmc: mmci: Switching off HWFC for SDIO depends on MCLK
From: Linus Walleij @ 2012-10-10 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349885000-22887-2-git-send-email-ulf.hansson@stericsson.com>
On Wed, Oct 10, 2012 at 6:03 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For writes, HWFC shall be switched off when transfer size <= 8
> bytes and when MCLK rate is above 50 MHz. For 50MHz and below
> it shall be switched off when transfer size < 8 bytes.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Tony Prisk @ 2012-10-10 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210100835.05898.arnd@arndb.de>
On Wed, 2012-10-10 at 08:35 +0000, Arnd Bergmann wrote:
> On Wednesday 10 October 2012, Tony Prisk wrote:
> > This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
> > SPARSE_IRQ. IRQ domain is changed from legacy to linear.
> >
> > Also, remove legacy code in include/mach/entry-macro.S and
> > include/mach/irq.h to prepare for multiplatform.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>
> Excellent!
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> One small style comment for a preexisting issue I had not noticed before:
>
> > static void vt8500_irq_mask(struct irq_data *d)
> > {
> > - struct vt8500_irq_priv *priv =
> > - (struct vt8500_irq_priv *)(d->domain->host_data);
> > + struct vt8500_irq_data *priv =
> > + (struct vt8500_irq_data *)(d->domain->host_data);
>
> host_data is a void pointer, so you don't need the type cast. Writing this
> as
>
> struct vt8500_irq_priv *priv = d->domain->host_data;
>
> is both the common convention and easier to read.
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I seem to have a thing about casting pointers - this must be the 3rd-4th
time you've mentioned different occasions where I've unnecessarily cast
a void pointer.
Must do better! :)
Changes made locally as requested - Should have the rest of the
multiplatform change done shortly.. then roll on -rc1....
Regards
Tony P
^ permalink raw reply
* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Tony Prisk @ 2012-10-10 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349856509-20480-1-git-send-email-linux@prisktech.co.nz>
I did have one bit I wasn't sure about:
On Wed, 2012-10-10 at 21:08 +1300, Tony Prisk wrote:
> This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
> SPARSE_IRQ. IRQ domain is changed from legacy to linear.
>
> Also, remove legacy code in include/mach/entry-macro.S and
> include/mach/irq.h to prepare for multiplatform.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> ...
>
> diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
> index 2b24196..6f2b843 100644
> --- a/arch/arm/mach-vt8500/common.h
> +++ b/arch/arm/mach-vt8500/common.h
> @@ -25,4 +25,7 @@ int __init vt8500_irq_init(struct device_node *node,
> /* defined in drivers/clk/clk-vt8500.c */
> void __init vtwm_clk_init(void __iomem *pmc_base);
>
> +/* defined in irq.c */
> +asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
Should asmlinkage be used here in the header or is it unnecessary?
> +
> #endif
Regards
Tony P
^ permalink raw reply
* [PATCH 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes
From: Tony Lindgren @ 2012-10-10 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075A1EF.60900@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [121010 09:36]:
> On 10/10/2012 01:26 AM, Linus Walleij wrote:
> > On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> >
> >> Seuqential patches from this series introduce SoC-specific data parsing
> >> from device tree.
> >>
> >> This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
> >> replaces them with nodes and properties required for these patches.
> >
> > So to be clear:
> >
> >> + pinctrl-bank-types {
> >> + bank_off: bank-off {
> >> + samsung,reg-names = "func", "dat", "pud",
> >> + "drv", "conpdn", "pudpdn";
> >> + samsung,reg-params = <0x00 4>, <0x04 1>, <0x08 2>,
> >> + <0x0C 2>, <0x10 2>, <0x14 2>;
> >> + };
> >
> > This is starting to look like a firmware language, I have mixed
> > feelings about this. Shall this be read:
> >
> > "Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08" etc?
> >
> > We really need to discuss this, Grant has already NACK:ed
> > such approaches once.
>
> Well, I don't think he NACK'd Tony Lindgren's generic pinctrl driver,
> which is doing this exact same thing. I did raise the same point about
> Tony's driver when he posted it, but nobody seemed inclined to NACK it
> based on that at the time, IIRC...
To summarize, using reg value pairs in DT makes sense if the amount
of data is huge. Otherwise we'll be describing indidual hardware bits
as properties in DT, or have to have huge amounts of static data in
the kernel.
Where it does not make sense is if there's a sequence of reads
and writes with test loops in between.. But that's does not look
to be the case here.
The reg value pairs will be readable when the DT preprocessing is
available, and that allows the values to be orred together while
DT properties don't. The alternative is to describe hardware register
bits as DT properties, which is very bloated.
But considering all this.. Are the samsung,reg-names really needed
by the kernel?
The pinctrl named modes actually are more generic from the pinctrl
client driver point of view as you can set up multiple states for
runtime PM.
> BTW, the idea here is IIRC to create a generic Samsung pinctrl driver
> that works across N different Samsung SoCs, each with different register
> layout, without having to encode the register layout into tables in the
> kernel.
>
> > If you're still going to do this, it is mandatory
> > to NOT use magic hex numbers anymore, because Stephen has
> > merged preprocessor support to the DTC compiler so you
> > can use #defined macros.
> >
> > See commit:
> > cd296721a9645f9f28800a072490fa15458d1fb7
>
> That feature isn't enabled yet. While dtc has been modified to be able
> to accept input that's been generated/processed by cpp, there is still
> ongoing discussion about how/whether to actually enable *.dts to use
> that feature.
Hey finally! That's good news.
Regards,
Tony
^ permalink raw reply
* [PATCH 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes
From: Tomasz Figa @ 2012-10-10 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010181253.GQ12552@atomide.com>
Dnia ?roda, 10 pa?dziernika 2012 11:12:53 Tony Lindgren pisze:
> * Stephen Warren <swarren@wwwdotorg.org> [121010 09:36]:
> > On 10/10/2012 01:26 AM, Linus Walleij wrote:
> > > On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com>
wrote:
> > >> Seuqential patches from this series introduce SoC-specific data
parsing
> > >> from device tree.
> > >>
> > >> This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
> > >> replaces them with nodes and properties required for these patches.
> > >
> > > So to be clear:
> > >> + pinctrl-bank-types {
> > >> + bank_off: bank-off {
> > >> + samsung,reg-names = "func", "dat", "pud",
> > >> + "drv", "conpdn",
> > >> "pudpdn";
> > >> + samsung,reg-params = <0x00 4>, <0x04 1>,
<0x08
> > >> 2>,
> > >> + <0x0C 2>, <0x10 2>,
> > >> <0x14 2>; + };
> > >
> > > This is starting to look like a firmware language, I have mixed
> > > feelings about this. Shall this be read:
> > >
> > > "Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08" etc?
> > >
> > > We really need to discuss this, Grant has already NACK:ed
> > > such approaches once.
> >
> > Well, I don't think he NACK'd Tony Lindgren's generic pinctrl driver,
> > which is doing this exact same thing. I did raise the same point about
> > Tony's driver when he posted it, but nobody seemed inclined to NACK it
> > based on that at the time, IIRC...
>
> To summarize, using reg value pairs in DT makes sense if the amount
> of data is huge. Otherwise we'll be describing indidual hardware bits
> as properties in DT, or have to have huge amounts of static data in
> the kernel.
>
> Where it does not make sense is if there's a sequence of reads
> and writes with test loops in between.. But that's does not look
> to be the case here.
>
> The reg value pairs will be readable when the DT preprocessing is
> available, and that allows the values to be orred together while
> DT properties don't. The alternative is to describe hardware register
> bits as DT properties, which is very bloated.
>
> But considering all this.. Are the samsung,reg-names really needed
> by the kernel?
They are used to specify which registers are defined in reg-params property
and in which order. Most of the registers are not mandatory and this is
needed to be able to specify only those that are present. At least I
couldn't think of a better solution for this. Do you have some suggestions?
Best regards,
Tomasz Figa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121010/8a94d561/attachment-0001.html>
^ permalink raw reply
* [PATCH 5/7] ARM: clps711x: make all virtual addresses definition via one macro
From: Arnd Bergmann @ 2012-10-10 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349883933-8881-5-git-send-email-shc_work@mail.ru>
On Wednesday 10 October 2012, Alexander Shiyan wrote:
> This patch make all virtual addresses definition via one macro.
> This modification allows to avoid warning "BUG: mapping for 0x80000000
> at 0xff000000 out of vmalloc space".
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Two comments on this one:
* I wonder if we could just kill off some of the mappings if no driver
relies on the registers being mapped in advance, especially for those
that don't benefit from section mapping like the ethernet one that is
only a page anyway.
* I would recommend defining the IO_ADDRESS macro in a way that the
result is of type 'void __iomem *', and you add a cast in the
map_desc array. We will probably clean those up eventually and
require that they are pointers at that place anyway, based on
recent discussions.
Arnd
^ permalink raw reply
* [PATCH 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes
From: Tomasz Figa @ 2012-10-10 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010181253.GQ12552@atomide.com>
Dnia ?roda, 10 pa?dziernika 2012 11:12:53 Tony Lindgren pisze:
> * Stephen Warren <swarren@wwwdotorg.org> [121010 09:36]:
> > On 10/10/2012 01:26 AM, Linus Walleij wrote:
> > > On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com>
wrote:
> > >> Seuqential patches from this series introduce SoC-specific data
> > >> parsing
> > >> from device tree.
> > >>
> > >> This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
> > >> replaces them with nodes and properties required for these patches.
> > >
> > > So to be clear:
> > >> + pinctrl-bank-types {
> > >> + bank_off: bank-off {
> > >> + samsung,reg-names = "func", "dat", "pud",
> > >> + "drv", "conpdn",
> > >> "pudpdn"; + samsung,reg-params = <0x00 4>,
> > >> <0x04 1>, <0x08 2>, +
> > >> <0x0C 2>, <0x10 2>, <0x14 2>; + };
> > >
> > > This is starting to look like a firmware language, I have mixed
> > > feelings about this. Shall this be read:
> > >
> > > "Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08" etc?
> > >
> > > We really need to discuss this, Grant has already NACK:ed
> > > such approaches once.
> >
> > Well, I don't think he NACK'd Tony Lindgren's generic pinctrl driver,
> > which is doing this exact same thing. I did raise the same point about
> > Tony's driver when he posted it, but nobody seemed inclined to NACK it
> > based on that at the time, IIRC...
>
> To summarize, using reg value pairs in DT makes sense if the amount
> of data is huge. Otherwise we'll be describing indidual hardware bits
> as properties in DT, or have to have huge amounts of static data in
> the kernel.
>
> Where it does not make sense is if there's a sequence of reads
> and writes with test loops in between.. But that's does not look
> to be the case here.
>
> The reg value pairs will be readable when the DT preprocessing is
> available, and that allows the values to be orred together while
> DT properties don't. The alternative is to describe hardware register
> bits as DT properties, which is very bloated.
>
> But considering all this.. Are the samsung,reg-names really needed
> by the kernel?
They are used to specify which registers are defined in reg-params property
and in which order. Most of the registers are not mandatory and this is
needed to be able to specify only those that are present. At least I
couldn't think of a better solution for this. Do you have some suggestions?
Best regards,
Tomasz Figa
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Kevin Hilman @ 2012-10-10 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507427DA.6020409@ti.com>
Hi Sourav,
Sourav <sourav.poddar@ti.com> writes:
[...]
> Boot Tested this patch series against v3.6 tag(applied cleanly) on
> panda board and
> PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
>
> Note, I also tested the patches against the current master but only
> after rebasing, since the current master includes serial patches from
> Felipe Balbi[1].
> [1] https://lkml.org/lkml/2012/8/24/139
>
> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Did you test flow control after off-mode transitons?
Russell indicated that the context save/restore is not saving important
bits related to HW flow control, so I suspect some more testing,
specifically of flow control after off-mode is needed.
Kevin
^ permalink raw reply
* [PATCH 3.6.0- 0/6] ARM: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Running below Coccinelle lookup pattern like below on the
latest kernel showed about 52 hits. This patch series is a subset
of those 52 patches, so that it will be easy for maintainers to review.
Hopefully these patches will get rid of some code duplication in kernel.
@ @
- initfunc(void)
- { return platform_driver_register(&dr); }
...
- module_init(initfunc);
...
- exitfunc(void)
- { platform_driver_unregister(&dr); }
...
- module_exit(exitfunc);
+ module_platform_driver(dr);
Srinivas Kandagatla (6):
ARM/omap1: use module_platform_driver macro
ARM/omap2: use module_platform_driver macro
ARM/pxa: use module_platform_driver macro
ARM/pxa: use module_platform_driver macro
ARM/omap: use module_platform_driver macro
omap_rng: use module_platform_driver macro
arch/arm/mach-omap1/mailbox.c | 14 +-------------
arch/arm/mach-omap2/mailbox.c | 14 +-------------
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +------------
arch/arm/mach-pxa/tosa-bt.c | 15 +--------------
arch/arm/plat-omap/dmtimer.c | 13 +------------
drivers/char/hw_random/omap-rng.c | 14 +-------------
6 files changed, 6 insertions(+), 77 deletions(-)
^ permalink raw reply
* [PATCH 3.6.0- 1/6] ARM/omap1: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-omap1/mailbox.c | 14 +-------------
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e962926..45c8719 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -179,19 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
.name = "omap-mailbox",
},
};
-
-static int __init omap1_mbox_init(void)
-{
- return platform_driver_register(&omap1_mbox_driver);
-}
-
-static void __exit omap1_mbox_exit(void)
-{
- platform_driver_unregister(&omap1_mbox_driver);
-}
-
-module_init(omap1_mbox_init);
-module_exit(omap1_mbox_exit);
+module_platform_driver(omap1_mbox_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap1 architecture specific functions");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3.6.0- 2/6] ARM/omap2: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-omap2/mailbox.c | 14 +-------------
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..eb64ca9 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -409,19 +409,7 @@ static struct platform_driver omap2_mbox_driver = {
.name = "omap-mailbox",
},
};
-
-static int __init omap2_mbox_init(void)
-{
- return platform_driver_register(&omap2_mbox_driver);
-}
-
-static void __exit omap2_mbox_exit(void)
-{
- platform_driver_unregister(&omap2_mbox_driver);
-}
-
-module_init(omap2_mbox_init);
-module_exit(omap2_mbox_exit);
+module_platform_driver(omap2_mbox_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap2/3/4 architecture specific functions");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3.6.0- 3/6] ARM/pxa: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index 7dbe3cc..e329cce 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -384,18 +384,7 @@ static struct platform_driver pxa3xx_u2d_ulpi_driver = {
.probe = pxa3xx_u2d_probe,
.remove = pxa3xx_u2d_remove,
};
-
-static int pxa3xx_u2d_ulpi_init(void)
-{
- return platform_driver_register(&pxa3xx_u2d_ulpi_driver);
-}
-module_init(pxa3xx_u2d_ulpi_init);
-
-static void __exit pxa3xx_u2d_ulpi_exit(void)
-{
- platform_driver_unregister(&pxa3xx_u2d_ulpi_driver);
-}
-module_exit(pxa3xx_u2d_ulpi_exit);
+module_platform_driver(pxa3xx_u2d_ulpi_driver);
MODULE_DESCRIPTION("PXA3xx U2D ULPI driver");
MODULE_AUTHOR("Igor Grinberg");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/7] ARM: clps711x: convert to clockevents
From: Arnd Bergmann @ 2012-10-10 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349883933-8881-1-git-send-email-shc_work@mail.ru>
On Wednesday 10 October 2012, Alexander Shiyan wrote:
> This patch converts CLPS711X-platform to use modern clockevent API.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> arch/arm/Kconfig | 2 +-
> arch/arm/mach-clps711x/common.c | 38 +++++++++++++++++---------------------
> 2 files changed, 18 insertions(+), 22 deletions(-)
Overall a very nice series, all 7 patches. I just have a few trivial
comments for patch 5.
Arnd
^ permalink raw reply
* [PATCH 3.6.0- 4/6] ARM/pxa: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/mach-pxa/tosa-bt.c | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index b9b1e5c..fe2a9e1 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,17 +132,4 @@ static struct platform_driver tosa_bt_driver = {
.owner = THIS_MODULE,
},
};
-
-
-static int __init tosa_bt_init(void)
-{
- return platform_driver_register(&tosa_bt_driver);
-}
-
-static void __exit tosa_bt_exit(void)
-{
- platform_driver_unregister(&tosa_bt_driver);
-}
-
-module_init(tosa_bt_init);
-module_exit(tosa_bt_exit);
+module_platform_driver(tosa_bt_driver);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3.6.0- 5/6] ARM/omap: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/plat-omap/dmtimer.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..c89fc6a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -786,19 +786,8 @@ static struct platform_driver omap_dm_timer_driver = {
},
};
-static int __init omap_dm_timer_driver_init(void)
-{
- return platform_driver_register(&omap_dm_timer_driver);
-}
-
-static void __exit omap_dm_timer_driver_exit(void)
-{
- platform_driver_unregister(&omap_dm_timer_driver);
-}
-
early_platform_init("earlytimer", &omap_dm_timer_driver);
-module_init(omap_dm_timer_driver_init);
-module_exit(omap_dm_timer_driver_exit);
+module_platform_driver(omap_dm_timer_driver);
MODULE_DESCRIPTION("OMAP Dual-Mode Timer Driver");
MODULE_LICENSE("GPL");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3.6.0- 6/6] omap_rng: use module_platform_driver macro
From: Srinivas KANDAGATLA @ 2012-10-10 18:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
drivers/char/hw_random/omap-rng.c | 14 +-------------
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index a5effd8..29732c6 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -217,19 +217,7 @@ static struct platform_driver omap_rng_driver = {
.probe = omap_rng_probe,
.remove = __exit_p(omap_rng_remove),
};
-
-static int __init omap_rng_init(void)
-{
- return platform_driver_register(&omap_rng_driver);
-}
-
-static void __exit omap_rng_exit(void)
-{
- platform_driver_unregister(&omap_rng_driver);
-}
-
-module_init(omap_rng_init);
-module_exit(omap_rng_exit);
+module_platform_driver(omap_rng_driver);
MODULE_AUTHOR("Deepak Saxena (and others)");
MODULE_LICENSE("GPL");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/6] mfd: Differentiate between u8500 and u9540 TCDM address mapping
From: Arnd Bergmann @ 2012-10-10 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-7-git-send-email-lee.jones@linaro.org>
On Wednesday 10 October 2012, Lee Jones wrote:
> @@ -2688,7 +2688,11 @@ void __init db8500_prcmu_early_init(void)
> iounmap(tcpm_base);
> }
>
> - tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
> + if (cpu_is_u9540())
> + tcdm_base = ioremap_nocache(U8500_PRCMU_TCDM_BASE,
> + SZ_4K + SZ_8K) + SZ_8K;
> + else
> + tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
> } else {
> pr_err("prcmu: Unsupported chip version\n");
> BUG();
Would it be possible to get the base out of the device tree and always
map it from there? Adding another dependency on a fixed constant is
just going to make the conversion to multiplatform harder, since it
was decided that device drivers should not have access to platform
header files in the multiplatform case.
Arnd
^ permalink raw reply
* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Arnd Bergmann @ 2012-10-10 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349891673.22215.2.camel@gitbox>
On Wednesday 10 October 2012, Tony Prisk wrote:
> I did have one bit I wasn't sure about:
>
> On Wed, 2012-10-10 at 21:08 +1300, Tony Prisk wrote:
> > This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
> > SPARSE_IRQ. IRQ domain is changed from legacy to linear.
> >
> > Also, remove legacy code in include/mach/entry-macro.S and
> > include/mach/irq.h to prepare for multiplatform.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> > ---
> > ...
> >
> > diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
> > index 2b24196..6f2b843 100644
> > --- a/arch/arm/mach-vt8500/common.h
> > +++ b/arch/arm/mach-vt8500/common.h
> > @@ -25,4 +25,7 @@ int __init vt8500_irq_init(struct device_node *node,
> > /* defined in drivers/clk/clk-vt8500.c */
> > void __init vtwm_clk_init(void __iomem *pmc_base);
> >
> > +/* defined in irq.c */
> > +asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
>
> Should asmlinkage be used here in the header or is it unnecessary?
I think it's not technically needed because the function is not called
from C code anywhere, but IMHO it's better to have it here out of principle.
Arnd
^ 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