* [PATCH 0/2] ARM: OMAP: SmartReflex: pass device dependent data via platform data
From: Jean Pihet @ 2012-10-05 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r4pdst5n.fsf@deeprootsystems.com>
On Fri, Oct 5, 2012 at 1:40 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> jean.pihet at newoldbits.com writes:
>
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> Remove the device dependent code (ex. cpu_is_xxx()) and settings
>> from the driver code and instead pass them via the platform
>> data. This allows a clean separation of the driver code and the platform
>> code, as required by the move of the platform header files to
>> include/linux/platform_data.
>>
>> Note about the smartreflex functional clocks: the smartreflex fclks
>> are derived from sys_clk and have the same name as the main_clk from
>> the hwmod entry, in order for the SmartReflex driver to request the
>> fclk (using clk_get(dev, "fck")).
>>
>> Based on mainline 3.6.0. Boot tested on OMAP3&4 platforms.
>
> Thanks, queuing this version for v3.8 (branch: for_3.8/pm/sr)
Thanks!
Jean
>
> Kevin
>
> P.S. in the future, It helps reviewers and maintainers if there's some
> versioning in the patches (e.g. PATCH v3 0/2]), especially when updated
> versions come in quick succession. Thanks.
>
^ permalink raw reply
* [PATCH 04/12] video: exynos: warnings in exynos_dp_core.c
From: Arnd Bergmann @ 2012-10-05 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002001cda2cf$b0b69c60$1223d520$%han@samsung.com>
On Friday 05 October 2012, Jingoo Han wrote:
> This problem was fixed. So, this patch is not necessary.
>
> As you mentioned, this problem was introduced by d5c0eed01
> "video: exynos_dp: adjust voltage swing and pre-emphasis
> during Link Training".
>
> However, this problem was resolved by e75478b "video: exynos_dp:
> replace link_status with link_align to check channel equalization".
>
> The patch was merged to 'fbdev-next', and will be merged to
> '3.7-rc1', soon. Thank you.
Ok, thanks for letting know. I'll drop my patch then.
Arnd
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-05 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005071216.GD4625@n2100.arm.linux.org.uk>
On 5 October 2012 08:12, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
>> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>> > This struct is the IP header, so a struct ptr is just set to the
>> > beginning of the received data. Since ethernet headers are 14 bytes,
>> > often the IP header is not aligned unless the NIC can place the frame at
>> > a 2 byte offset (which is something I need to investigate). So this
>> > function cannot make any assumptions about the alignment. Does the ABI
>> > define structs have some minimum alignment? Does the struct need to be
>> > declared as packed or something?
>>
>> The ABI defines the alignment of structs as the maximum alignment of its
>> members. Since this struct contains 32-bit members, the alignment for the
>> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
>> might be unaligned (in addition to removing any holes within).
>
> This has come up before in the past.
>
> The Linux network folk will _not_ allow - in any shape or form - for
> this struct to be marked packed (it's the struct which needs to be
> marked packed) because by doing so, it causes GCC to issue byte loads/
> stores on architectures where there isn't a problem, and that decreases
> the performance of the Linux IP stack unnecessarily.
Which architectures? I have never seen anything like that.
--
Mans Rullgard / mru
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6VciuxJ=k+fatzLugcehF54mGNOLHpUwdMX99oCnAVg8Q@mail.gmail.com>
On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> On 5 October 2012 08:12, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >> > This struct is the IP header, so a struct ptr is just set to the
> >> > beginning of the received data. Since ethernet headers are 14 bytes,
> >> > often the IP header is not aligned unless the NIC can place the frame at
> >> > a 2 byte offset (which is something I need to investigate). So this
> >> > function cannot make any assumptions about the alignment. Does the ABI
> >> > define structs have some minimum alignment? Does the struct need to be
> >> > declared as packed or something?
> >>
> >> The ABI defines the alignment of structs as the maximum alignment of its
> >> members. Since this struct contains 32-bit members, the alignment for the
> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> >> might be unaligned (in addition to removing any holes within).
> >
> > This has come up before in the past.
> >
> > The Linux network folk will _not_ allow - in any shape or form - for
> > this struct to be marked packed (it's the struct which needs to be
> > marked packed) because by doing so, it causes GCC to issue byte loads/
> > stores on architectures where there isn't a problem, and that decreases
> > the performance of the Linux IP stack unnecessarily.
>
> Which architectures? I have never seen anything like that.
Does it matter? I'm just relaying the argument against adding __packed
which was used before we were forced (by the networking folk) to implement
the alignment fault handler.
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-05 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005082439.GF4625@n2100.arm.linux.org.uk>
On 5 October 2012 09:24, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
>> On 5 October 2012 08:12, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
>> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>> >> > This struct is the IP header, so a struct ptr is just set to the
>> >> > beginning of the received data. Since ethernet headers are 14 bytes,
>> >> > often the IP header is not aligned unless the NIC can place the frame at
>> >> > a 2 byte offset (which is something I need to investigate). So this
>> >> > function cannot make any assumptions about the alignment. Does the ABI
>> >> > define structs have some minimum alignment? Does the struct need to be
>> >> > declared as packed or something?
>> >>
>> >> The ABI defines the alignment of structs as the maximum alignment of its
>> >> members. Since this struct contains 32-bit members, the alignment for the
>> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
>> >> might be unaligned (in addition to removing any holes within).
>> >
>> > This has come up before in the past.
>> >
>> > The Linux network folk will _not_ allow - in any shape or form - for
>> > this struct to be marked packed (it's the struct which needs to be
>> > marked packed) because by doing so, it causes GCC to issue byte loads/
>> > stores on architectures where there isn't a problem, and that decreases
>> > the performance of the Linux IP stack unnecessarily.
>>
>> Which architectures? I have never seen anything like that.
>
> Does it matter?
It matters if we want to fix it.
--
Mans Rullgard / mru
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6UabdyCbmMWr5vqyKfgHsYEzGLmx0=uBiPjyGUmVCejcQ@mail.gmail.com>
On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> On 5 October 2012 09:24, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >> >> > This struct is the IP header, so a struct ptr is just set to the
> >> >> > beginning of the received data. Since ethernet headers are 14 bytes,
> >> >> > often the IP header is not aligned unless the NIC can place the frame at
> >> >> > a 2 byte offset (which is something I need to investigate). So this
> >> >> > function cannot make any assumptions about the alignment. Does the ABI
> >> >> > define structs have some minimum alignment? Does the struct need to be
> >> >> > declared as packed or something?
> >> >>
> >> >> The ABI defines the alignment of structs as the maximum alignment of its
> >> >> members. Since this struct contains 32-bit members, the alignment for the
> >> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> >> >> might be unaligned (in addition to removing any holes within).
> >> >
> >> > This has come up before in the past.
> >> >
> >> > The Linux network folk will _not_ allow - in any shape or form - for
> >> > this struct to be marked packed (it's the struct which needs to be
> >> > marked packed) because by doing so, it causes GCC to issue byte loads/
> >> > stores on architectures where there isn't a problem, and that decreases
> >> > the performance of the Linux IP stack unnecessarily.
> >>
> >> Which architectures? I have never seen anything like that.
> >
> > Does it matter?
>
> It matters if we want to fix it.
I can't help you there. Ask the networking people.
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-05 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005083359.GH4625@n2100.arm.linux.org.uk>
On 5 October 2012 09:33, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
>> On 5 October 2012 09:24, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
>> >> On 5 October 2012 08:12, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
>> >> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>> >> >> > This struct is the IP header, so a struct ptr is just set to the
>> >> >> > beginning of the received data. Since ethernet headers are 14 bytes,
>> >> >> > often the IP header is not aligned unless the NIC can place the frame at
>> >> >> > a 2 byte offset (which is something I need to investigate). So this
>> >> >> > function cannot make any assumptions about the alignment. Does the ABI
>> >> >> > define structs have some minimum alignment? Does the struct need to be
>> >> >> > declared as packed or something?
>> >> >>
>> >> >> The ABI defines the alignment of structs as the maximum alignment of its
>> >> >> members. Since this struct contains 32-bit members, the alignment for the
>> >> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
>> >> >> might be unaligned (in addition to removing any holes within).
>> >> >
>> >> > This has come up before in the past.
>> >> >
>> >> > The Linux network folk will _not_ allow - in any shape or form - for
>> >> > this struct to be marked packed (it's the struct which needs to be
>> >> > marked packed) because by doing so, it causes GCC to issue byte loads/
>> >> > stores on architectures where there isn't a problem, and that decreases
>> >> > the performance of the Linux IP stack unnecessarily.
>> >>
>> >> Which architectures? I have never seen anything like that.
>> >
>> > Does it matter?
>>
>> It matters if we want to fix it.
>
> I can't help you there. Ask the networking people.
I'm asking anyone who is listening. Since you've (apparently) seen the claim
being made, perhaps you can point to an email or so with more information.
I'd hate to think you're just making up excuses.
--
Mans Rullgard / mru
^ permalink raw reply
* [PATCH v4 2/6] misc: Generic on-chip SRAM allocation driver
From: Philipp Zabel @ 2012-10-05 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004152509.GJ11149@beef>
Am Donnerstag, den 04.10.2012, 11:25 -0400 schrieb Matt Porter:
> On Fri, Sep 07, 2012 at 02:43:44PM +0200, Philipp Zabel wrote:
> > This driver requests and remaps a memory region as configured in the
> > device tree. It serves memory from this region via the genalloc API.
> >
> > Other drivers can retrieve the genalloc pool from a phandle pointing
> > to this drivers' device node in the device tree.
>
> <snip>
>
> > + sram->pool = gen_pool_create(PAGE_SHIFT, -1);
> > + if (!sram->pool)
> > + return -ENOMEM;
>
> As mentioned in the uio_pruss/genalloc discussion, removing the
> hardcoded minimum allocation order will allow this to be used for
> a number of other cases. The most notable is moving mach-davinci/
> off of its own genalloc-based SRAM arch driver. Some of the davinci
> SoCs have very small SRAMs and need the ability to allocate a smaller
> chunk.
>
> Here's a build-tested patch to add this option:
Thank you,
> From 6eced8c31eba2f86e72e854cf404d8f58fbeba85 Mon Sep 17 00:00:00 2001
> From: Matt Porter <mporter@ti.com>
> Date: Thu, 4 Oct 2012 11:08:02 -0400
> Subject: [PATCH] misc: sram: add support for configurable allocation order
>
> Adds support for setting the genalloc pool's minimum allocation
> order via DT or platform data. The allocation order is optional
> for both the DT property and platform data case. If it is not
> present then the order defaults to PAGE_SHIFT to preserve the
> current behavior.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> Documentation/devicetree/bindings/misc/sram.txt | 12 ++++++++++-
> drivers/misc/sram.c | 14 ++++++++++++-
> include/linux/platform_data/sram.h | 25 +++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 2 deletions(-)
> create mode 100644 include/linux/platform_data/sram.h
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index b64136c..b1705ec 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,10 +8,20 @@ Required properties:
>
> - reg : SRAM iomem address range
>
> -Example:
> +Optional properties:
> +
> +- alloc-order : Minimum allocation order for the SRAM pool
> +
> +Examples:
> +
> +sram: sram at 5c000000 {
> + compatible = "sram";
> + reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +};
>
> sram: sram at 5c000000 {
> compatible = "sram";
> reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> + alloc-order = <9>; /* Minimum 512 byte allocation */
> };
>
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index 7a363f2..3bf8ed3 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -26,6 +26,7 @@
> #include <linux/platform_device.h>
> #include <linux/spinlock.h>
> #include <linux/genalloc.h>
> +#include <linux/platform_data/sram.h>
>
> struct sram_dev {
> struct gen_pool *pool;
> @@ -37,6 +38,7 @@ static int __devinit sram_probe(struct platform_device *pdev)
> struct sram_dev *sram;
> struct resource *res;
> unsigned long size;
> + u32 alloc_order = PAGE_SHIFT;
> int ret;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -53,7 +55,17 @@ static int __devinit sram_probe(struct platform_device *pdev)
> if (!sram)
> return -ENOMEM;
>
> - sram->pool = gen_pool_create(PAGE_SHIFT, -1);
> + if (pdev->dev.of_node)
> + of_property_read_u32(pdev->dev.of_node,
> + "alloc-order", &alloc_order);
> + else
> + if (pdev->dev.platform_data) {
> + struct sram_pdata *pdata = pdev->dev.platform_data;
> + if (pdata->alloc_order)
> + alloc_order = pdata->alloc_order;
> + }
> +
> + sram->pool = gen_pool_create(alloc_order, -1);
> if (!sram->pool)
> return -ENOMEM;
>
> diff --git a/include/linux/platform_data/sram.h b/include/linux/platform_data/sram.h
> new file mode 100644
> index 0000000..e17bdaa
> --- /dev/null
> +++ b/include/linux/platform_data/sram.h
> @@ -0,0 +1,25 @@
> +/*
> + * include/linux/platform_data/sram.h
> + *
> + * Platform data for generic sram 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 as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _SRAM_H_
> +#define _SRAM_H_
> +
> +struct sram_pdata {
> + unsigned alloc_order; /* Optional: driver defaults to PAGE_SHIFT */
> +};
> +
> +#endif /* _SRAM_H_ */
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Russell King - ARM Linux @ 2012-10-05 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001160639.GA31620@obsidianresearch.com>
On Mon, Oct 01, 2012 at 10:06:39AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
> > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > > LOAD 0x008000 0xc0008000 0x00008000 0x372244 0x3a4310 RWE 0x8000
> >
> > Not related directly to your patch, but I wonder why we don't we see
> > separate r-x and rw- segments?
>
> I think this is because the sections are not aligned when the
> protections change, and the sections are not sorted by protection
> type.
They aren't sorted by protection type, they're ordered according to what's
required for the kernel - which is to have the init sections together as
one complete block so that it can be freed, and to place all of the kernel
text as close to the beginning of the image as possible.
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6WSRtwPkz9OEg6xS7X5uV6-U4o3GaxbTRW-jCfuMPdb=g@mail.gmail.com>
On Fri, Oct 05, 2012 at 09:37:38AM +0100, Mans Rullgard wrote:
> On 5 October 2012 09:33, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 09:24, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> >> <linux@arm.linux.org.uk> wrote:
> >> >> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> >> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >> >> >> > This struct is the IP header, so a struct ptr is just set to the
> >> >> >> > beginning of the received data. Since ethernet headers are 14 bytes,
> >> >> >> > often the IP header is not aligned unless the NIC can place the frame at
> >> >> >> > a 2 byte offset (which is something I need to investigate). So this
> >> >> >> > function cannot make any assumptions about the alignment. Does the ABI
> >> >> >> > define structs have some minimum alignment? Does the struct need to be
> >> >> >> > declared as packed or something?
> >> >> >>
> >> >> >> The ABI defines the alignment of structs as the maximum alignment of its
> >> >> >> members. Since this struct contains 32-bit members, the alignment for the
> >> >> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> >> >> >> might be unaligned (in addition to removing any holes within).
> >> >> >
> >> >> > This has come up before in the past.
> >> >> >
> >> >> > The Linux network folk will _not_ allow - in any shape or form - for
> >> >> > this struct to be marked packed (it's the struct which needs to be
> >> >> > marked packed) because by doing so, it causes GCC to issue byte loads/
> >> >> > stores on architectures where there isn't a problem, and that decreases
> >> >> > the performance of the Linux IP stack unnecessarily.
> >> >>
> >> >> Which architectures? I have never seen anything like that.
> >> >
> >> > Does it matter?
> >>
> >> It matters if we want to fix it.
> >
> > I can't help you there. Ask the networking people.
>
> I'm asking anyone who is listening. Since you've (apparently) seen the claim
> being made, perhaps you can point to an email or so with more information.
> I'd hate to think you're just making up excuses.
Sorry, I'm just not going to bother - especially given your attitude of
"you're just making up excuses" - you just accused me of being a liar.
Thanks for that.
We have the merge window open at the moment, and I've only just got back
from being on holiday for the first half of that - so I have new tree
conflicts to deal with, and need to finish preparing my tree for Linus.
I'm not going to waste the precious time that the merge window is open
for searching lots of mail archives for this when others can do the same,
or even try sending the Linux networking people a patch adding __packed
to their structures and seeing the response.
^ permalink raw reply
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Philip, Avinash @ 2012-10-05 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003192044.GB27502@parrot.com>
On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
> On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
> > On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> > > ELM module can be used for error correction of BCH 4 & 8 bit. Also
> > > support read & write page in one shot by adding custom read_page &
> > > write_page methods. This helps in optimizing code.
> > >
> > > New structure member "is_elm_used" is added to know the status of
> > > whether the ELM module is used for error correction or not.
> > >
> > > Note:
> > > ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
> > > with RBL ECC layout, even though the requirement was only 13 byte. This
> > > results a common ecc layout across RBL, U-boot & Linux.
> > >
> >
> > See a few comments below,
> >
> > (...)
> > > +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> > > + u_char *read_ecc, u_char *calc_ecc)
> > > +{
> > > + struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > > + mtd);
> > > + int eccsteps = info->nand.ecc.steps;
> > > + int i , j, stat = 0;
> > > + int eccsize, eccflag, size;
> > > + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> > > + u_char *ecc_vec = calc_ecc;
> > > + enum bch_ecc type;
> > > + bool is_error_reported = false;
> > > +
> > > + /* initialize elm error vector to zero */
> > > + memset(err_vec, 0, sizeof(err_vec));
> > > + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> > > + size = BCH8_SIZE;
> > > + eccsize = BCH8_ECC_OOB_BYTES;
> > > + type = BCH8_ECC;
> > > + } else {
> > > + size = BCH4_SIZE;
> > > + eccsize = BCH4_SIZE;
> > > + type = BCH4_ECC;
> > > + }
> > > +
> > > + for (i = 0; i < eccsteps ; i++) {
> > > + eccflag = 0; /* initialize eccflag */
> > > +
> > > + for (j = 0; (j < eccsize); j++) {
> > > + if (read_ecc[j] != 0xFF) {
> > > + eccflag = 1; /* data area is flashed */
> >
> > Just a reminder: this way of checking if a page has been programmed is not robust to bitflips,
> > so you may get into trouble with UBIFS on a fairly recent device.
Sorry I missed this point.
Here we were checking data in spare area (only in ecc layout 14*4 for BCH8) is 0xFF. If all data
in spare area is 0xFF, conclude that the page is erased & no need of error correction. In case
of bit flip present in spare area, page will be reported as uncorrectable.
But I am not understand understand " trouble with UBIFS on a fairly recent device".
Can you little elaborativ
Thanks
Avinash
^ permalink raw reply
* [PATCH 02/16] ARM: OMAP: Split plat-omap/i2c.c into mach-omap1 and mach-omap2
From: Shubhrajyoti @ 2012-10-05 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004220436.26676.33938.stgit@muffinssi.local>
On Friday 05 October 2012 03:34 AM, Tony Lindgren wrote:
> There's no need to keep the device related things in the
> common i2c.c as omap2+ is using hwmod. Split the code to
> mach-omap1 and mach-omap2 parts and only leave common
> code to plat-omap/i2c.c.
>
> Note that as omap1 only has one i2c controller, we can
> now remove the old device related macros.
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap1/common.h | 3 +
> arch/arm/mach-omap1/i2c.c | 59 +++++++++++
> arch/arm/mach-omap2/board-rm680.c | 1
> arch/arm/mach-omap2/common.h | 4 +
> arch/arm/mach-omap2/i2c.c | 72 +++++++++++++
> arch/arm/mach-omap2/i2c.h | 25 +----
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 4 +
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 4 +
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 4 +
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 +
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 -
> arch/arm/mach-omap2/twl-common.c | 1
> arch/arm/plat-omap/i2c.c | 152 +---------------------------
> arch/arm/plat-omap/i2c.h | 46 ++++++++
> arch/arm/plat-omap/include/plat/common.h | 1
> 15 files changed, 202 insertions(+), 181 deletions(-)
> rename arch/arm/{plat-omap/include/plat/i2c.h => mach-omap2/i2c.h} (66%)
> create mode 100644 arch/arm/plat-omap/i2c.h
>
> diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
> index c2552b2..306b7ac 100644
> --- a/arch/arm/mach-omap1/common.h
> +++ b/arch/arm/mach-omap1/common.h
> @@ -28,6 +28,9 @@
>
> #include <plat/common.h>
> #include <linux/mtd/mtd.h>
> +#include <linux/i2c-omap.h>
> +
> +#include "../plat-omap/i2c.h"
>
> #if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> void omap7xx_map_io(void);
> diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
> index a0551a6..a6f465a 100644
> --- a/arch/arm/mach-omap1/i2c.c
> +++ b/arch/arm/mach-omap1/i2c.c
> @@ -19,11 +19,25 @@
> *
> */
>
> -#include <plat/i2c.h>
> +#include <linux/i2c-omap.h>
> #include <mach/mux.h>
> #include <plat/cpu.h>
>
> -void __init omap1_i2c_mux_pins(int bus_id)
> +#include "../plat-omap/i2c.h"
> +
> +#define OMAP_I2C_SIZE 0x3f
> +#define OMAP1_I2C_BASE 0xfffb3800
> +#define OMAP1_INT_I2C (32 + 4)
> +
> +static const char name[] = "omap_i2c";
> +
> +static struct resource i2c_resources[2] = {
> +};
> +
> +static struct platform_device omap_i2c_devices[1] = {
> +};
> +
> +static void __init omap1_i2c_mux_pins(int bus_id)
> {
> if (cpu_is_omap7xx()) {
> omap_cfg_reg(I2C_7XX_SDA);
> @@ -33,3 +47,44 @@ void __init omap1_i2c_mux_pins(int bus_id)
> omap_cfg_reg(I2C_SCL);
> }
> }
> +
> +int __init omap_i2c_add_bus(struct omap_i2c_bus_platform_data *pdata,
> + int bus_id)
> +{
> + struct platform_device *pdev;
> + struct resource *res;
> +
> + omap1_i2c_mux_pins(bus_id);
> +
> + pdev = &omap_i2c_devices[bus_id - 1];
> + pdev->id = bus_id;
> + pdev->name = name;
> + pdev->num_resources = ARRAY_SIZE(i2c_resources);
> + res = i2c_resources;
> + res[0].start = OMAP1_I2C_BASE;
> + res[0].end = res[0].start + OMAP_I2C_SIZE;
> + res[0].flags = IORESOURCE_MEM;
> + res[1].start = OMAP1_INT_I2C;
> + res[1].flags = IORESOURCE_IRQ;
> + pdev->resource = res;
> +
> + /* all OMAP1 have IP version 1 register set */
> + pdata->rev = OMAP_I2C_IP_VERSION_1;
> +
> + /* all OMAP1 I2C are implemented like this */
> + pdata->flags = OMAP_I2C_FLAG_NO_FIFO |
> + OMAP_I2C_FLAG_SIMPLE_CLOCK |
> + OMAP_I2C_FLAG_16BIT_DATA_REG |
> + OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK;
> +
> + /* how the cpu bus is wired up differs for 7xx only */
> +
> + if (cpu_is_omap7xx())
> + pdata->flags |= OMAP_I2C_FLAG_BUS_SHIFT_1;
> + else
> + pdata->flags |= OMAP_I2C_FLAG_BUS_SHIFT_2;
> +
> + pdev->dev.platform_data = pdata;
> +
> + return platform_device_register(pdev);
> +}
> diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
> index 45997bf..a57ed21 100644
> --- a/arch/arm/mach-omap2/board-rm680.c
> +++ b/arch/arm/mach-omap2/board-rm680.c
> @@ -22,7 +22,6 @@
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
>
> -#include <plat/i2c.h>
> #include <plat/mmc.h>
> #include <plat/usb.h>
> #include <plat/gpmc.h>
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 7045e4d..a68b421 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -28,7 +28,9 @@
>
> #include <linux/irq.h>
> #include <linux/delay.h>
> +#include <linux/i2c.h>
> #include <linux/i2c/twl.h>
> +#include <linux/i2c-omap.h>
>
> #include <asm/proc-fns.h>
>
> @@ -36,6 +38,8 @@
> #include <plat/serial.h>
> #include <plat/common.h>
>
> +#include "i2c.h"
> +
> #define OMAP_INTC_START NR_IRQS
>
> #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
> index fc57e67..b15416c 100644
> --- a/arch/arm/mach-omap2/i2c.c
> +++ b/arch/arm/mach-omap2/i2c.c
> @@ -19,11 +19,15 @@
> *
> */
>
> -#include <plat/i2c.h>
> +#include <linux/i2c-omap.h>
> +
> #include "common.h"
> #include <plat/omap_hwmod.h>
> +#include <plat/omap_device.h>
> +#include <plat/omap-pm.h>
>
> #include "mux.h"
> +#include "i2c.h"
>
> /* In register I2C_CON, Bit 15 is the I2C enable bit */
> #define I2C_EN BIT(15)
> @@ -33,7 +37,9 @@
> /* Maximum microseconds to wait for OMAP module to softreset */
> #define MAX_MODULE_SOFTRESET_WAIT 10000
>
> -void __init omap2_i2c_mux_pins(int bus_id)
> +#define MAX_OMAP_I2C_HWMOD_NAME_LEN 16
> +
> +static void __init omap2_i2c_mux_pins(int bus_id)
> {
> char mux_name[sizeof("i2c2_scl.i2c2_scl")];
>
> @@ -104,3 +110,65 @@ int omap_i2c_reset(struct omap_hwmod *oh)
>
> return 0;
> }
> +
> +/*
> + * XXX This function is a temporary compatibility wrapper - only
> + * needed until the I2C driver can be converted to call
> + * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
> + */
> +static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
> +{
> + omap_pm_set_max_mpu_wakeup_lat(dev, t);
> +}
> +
> +static const char name[] = "omap_i2c";
> +
> +int __init omap_i2c_add_bus(struct omap_i2c_bus_platform_data *i2c_pdata,
> + int bus_id)
> +{
> + int l;
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> + char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN];
> + struct omap_i2c_bus_platform_data *pdata;
> + struct omap_i2c_dev_attr *dev_attr;
> +
> + omap2_i2c_mux_pins(bus_id);
> +
> + l = snprintf(oh_name, MAX_OMAP_I2C_HWMOD_NAME_LEN, "i2c%d", bus_id);
> + WARN(l >= MAX_OMAP_I2C_HWMOD_NAME_LEN,
> + "String buffer overflow in I2C%d device setup\n", bus_id);
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + return -EEXIST;
> + }
> +
> + pdata = i2c_pdata;
> + /*
> + * pass the hwmod class's CPU-specific knowledge of I2C IP revision in
> + * use, and functionality implementation flags, up to the OMAP I2C
> + * driver via platform data
> + */
> + pdata->rev = oh->class->rev;
> +
> + dev_attr = (struct omap_i2c_dev_attr *)oh->dev_attr;
> + pdata->flags = dev_attr->flags;
> +
> + /*
> + * When waiting for completion of a i2c transfer, we need to
> + * set a wake up latency constraint for the MPU. This is to
> + * ensure quick enough wakeup from idle, when transfer
> + * completes.
> + * Only omap3 has support for constraints
> + */
> + if (cpu_is_omap34xx())
> + pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
this part is touched by Jean also so maybe one of the patch has to be
rebased.
> + pdev = omap_device_build(name, bus_id, oh, pdata,
>
^ permalink raw reply
* [PATCH 14/15] KVM: ARM: Handle I/O aborts
From: Russell King - ARM Linux @ 2012-10-05 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001125326.GA2100@linaro.org>
On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote:
> A good starting point would be load/store emulation as this seems to be a
> common theme, and we would need a credible deployment for any new
> framework so that we know it's fit for purpose.
Probably not actually, that code is written to be fast, because things
like IP stack throughput depend on it - particularly when your network
card can only DMA packets to 32-bit aligned addresses (resulting in
virtually all network data being misaligned.)
^ permalink raw reply
* [PATCH v3] GPIO: Add support for GPIO on CLPS711X-target platform
From: Russell King - ARM Linux @ 2012-10-05 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349106153-27371-1-git-send-email-shc_work@mail.ru>
On Mon, Oct 01, 2012 at 07:42:33PM +0400, Alexander Shiyan wrote:
> The CLPS711X CPUs provide some GPIOs for use in the system. This
> driver provides support for these via gpiolib. Due to platform
> limitations, driver does not support interrupts, only inputs and
> outputs.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/mach-clps711x/include/mach/gpio.h | 27 +++++
> drivers/gpio/Kconfig | 4 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-clps711x.c | 152 ++++++++++++++++++++++++++++
> 5 files changed, 185 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-clps711x/include/mach/gpio.h
> create mode 100644 drivers/gpio/gpio-clps711x.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..e73bf9d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -384,6 +384,7 @@ config ARCH_CLPS711X
> bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
> select CPU_ARM720T
> select ARCH_USES_GETTIMEOFFSET
> + select ARCH_REQUIRE_GPIOLIB
> select NEED_MACH_MEMORY_H
> help
> Support for Cirrus Logic 711x/721x/731x based boards.
> diff --git a/arch/arm/mach-clps711x/include/mach/gpio.h b/arch/arm/mach-clps711x/include/mach/gpio.h
> new file mode 100644
> index 0000000..cbcc985
> --- /dev/null
> +++ b/arch/arm/mach-clps711x/include/mach/gpio.h
> @@ -0,0 +1,27 @@
> +/*
> + * This file contains the CLPS711X GPIO definitions.
> + *
> + * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +/* Simple helper for convert port & pin to GPIO number */
> +#define CLPS711X_GPIO(port, bit) ((port) * 8 + (bit))
> +
> +/* Temporaty definitions for GPIO-ports */
> +/* Will be removed after remove clps_read(write) macros */
> +#include <mach/hardware.h>
> +#define _PADR (CLPS711X_VIRT_BASE + PADR)
> +#define _PBDR (CLPS711X_VIRT_BASE + PBDR)
> +#define _PCDR (CLPS711X_VIRT_BASE + PCDR)
> +#define _PDDR (CLPS711X_VIRT_BASE + PDDR)
> +#define _PADDR (CLPS711X_VIRT_BASE + PADDR)
> +#define _PBDDR (CLPS711X_VIRT_BASE + PBDDR)
> +#define _PCDDR (CLPS711X_VIRT_BASE + PCDDR)
> +#define _PDDDR (CLPS711X_VIRT_BASE + PDDDR)
> +#define _PEDR (CLPS711X_VIRT_BASE + PEDR)
> +#define _PEDDR (CLPS711X_VIRT_BASE + PEDDR)
Why can't this file (or the bulk of it) live in drivers/gpio ?
^ permalink raw reply
* [RFC] arm/mm: add a protection when flushing anonymous pages
From: Russell King - ARM Linux @ 2012-10-05 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANj_sbADwtPR6cgk05QkmvrSUOOQRYXB9vPB6KATKEmwcN8UrA@mail.gmail.com>
On Tue, Oct 02, 2012 at 03:07:33PM +0800, Andrew Yan-Pai Chen wrote:
> [RFC PATCH] make flush_pfn_alias() nonpreemptible
>
> Since flush_pfn_alias() is preemptible, it is possible to be
> preempted just after set_top_pte() is done. If the process
> which preempts the previous happened to invoke flush_pfn_alias()
> with the same colour vaddr as that of the previous, the same
> top pte will be overwritten. When switching back to the previous,
> it attempts to flush cache lines with incorrect mapping. Then
> no lines (or wrong lines) will be flushed because of the nature
> of vipt caches.
>
> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> index 40ca11e..bd07918 100644
> --- a/arch/arm/mm/flush.c
> +++ b/arch/arm/mm/flush.c
> @@ -27,6 +27,8 @@ static void flush_pfn_alias(unsigned long pfn,
> unsigned long vaddr)
> unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
> PAGE_SHIFT);
> const int zero = 0;
>
> + preempt_disable();
> +
> set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
>
> asm( "mcrr p15, 0, %1, %0, c14\n"
> @@ -34,6 +36,8 @@ static void flush_pfn_alias(unsigned long pfn,
> unsigned long vaddr)
> :
> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> : "cc");
> +
> + preempt_enable();
> }
This looks like it's quite correct, but if you look at the file a little
deeper, you'll notice that flush_icache_alias() potentially suffers the
same issue.
They should probably both also have a comment indicating that they're not
to be called for SMP setups (because there's no locking for that.)
^ permalink raw reply
* [PATCH] arm: include linux/sched.h in syscall.h
From: Will Deacon @ 2012-10-05 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004230957.GC4625@n2100.arm.linux.org.uk>
On Fri, Oct 05, 2012 at 12:09:57AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 02, 2012 at 04:52:55PM +0100, Will Deacon wrote:
> >
> > Yep, thanks. Your patch sounds like the right thing to do, but please
> > include the compiler error in your commit log.
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
>
> From what I can tell, the original commit went in during the 3.4..3.5
> timeframe, so doesn't this patch need to be applied to v3.5-stable
> as well as 3.6-stable and for 3.7 ?
I guess so, although it only seems to be affecting lttng which is still
out-of-tree. Depends how kind you're feeling!
Will
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for arm
From: Russell King - ARM Linux @ 2012-10-05 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17343.1349380261@warthog.procyon.org.uk>
On Thu, Oct 04, 2012 at 08:51:01PM +0100, David Howells wrote:
> Can you merge the following branch into the arm tree please.
>
> This is to complete part of the UAPI disintegration for which the preparatory
> patches were pulled recently.
I'll merge this only after I've sorted through the issues arising in my
current tree post merge window opening, so that I can at least get what
was queued up _before_ the merge window into mainline.
Thanks.
^ permalink raw reply
* [PATCH] arm: include linux/sched.h in syscall.h
From: Russell King - ARM Linux @ 2012-10-05 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005091624.GB16044@mudshark.cambridge.arm.com>
On Fri, Oct 05, 2012 at 10:16:24AM +0100, Will Deacon wrote:
> On Fri, Oct 05, 2012 at 12:09:57AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 02, 2012 at 04:52:55PM +0100, Will Deacon wrote:
> > >
> > > Yep, thanks. Your patch sounds like the right thing to do, but please
> > > include the compiler error in your commit log.
> > >
> > > Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > From what I can tell, the original commit went in during the 3.4..3.5
> > timeframe, so doesn't this patch need to be applied to v3.5-stable
> > as well as 3.6-stable and for 3.7 ?
>
> I guess so, although it only seems to be affecting lttng which is still
> out-of-tree. Depends how kind you're feeling!
Well, it's simple enough. I'll add the Cc, and I'll also fix the commit
log so that the compiler error message isn't wrapped.
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Archit Taneja @ 2012-10-05 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <504075A0.7010708@ti.com>
Hi,
On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
> On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
>> On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
>>> On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
>>>> On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
>>>>
>>>>> The only little problem was that during bootup, when hwmods are setup,
>>>>> only the 'parent' hwmod was able to get reset properly, all the other
>>>>> 'child' hwmods don't have modulemode bits tied to them, and hence
>>>>> weren't able to reset. So we got some error prints.
>>>>>
>>>>> Once DSS driver kicks in, the driver ensures the parent is enabled for
>>>>> any child to be enabled, so we don't face the issue again.
>>>>>
>>>>> So, if DSS driver is not built in, and if the bootloader left DSS in a
>>>>> bad state, the DSS clocks might remain messed up all the time since
>>>>> hwmod fwk wasn't able to reset them.
>>>>>
>>>>> I think this is why we didn't proceed with remove "dss_fck" as a slave
>>>>> clock. If this issue is minor, we could go ahead and remove it.
>>>>
>>>> I wonder if we could handle this with a custom reset function. We
>>>> already have a reset func for dss core. If I remember right, the main
>>>> point for that is the fact that omap4 doesn't have a softreset for dss
>>>> core, so we manually write the default values to registers.
>>>>
>>>> For omap2/3 this would be simple: skip the resets for all other dss
>>>> submodules, and dss core's reset would enable all the clocks and set
>>>> the
>>>> softreset bit. This would reset all the submodules also.
>>>>
>>>> Omap4 is more tricky. I guess we'd need to enable all the clocks, clear
>>>> manually dss core's registers, and then set softreset bits in all the
>>>> submodules. So in this case dss core would need to have information
>>>> about the other submodules.
>>>
>>> The is a good idea. I don't clearly understand your approach though. Are
>>> you saying we have a custom reset function for only dss core? And reset
>>> the submodules in it manually?
>>
>> Yes.
>>
>>> An alternative approach would be to implement custom reset functions for
>>> each submodule(or each hwmod), and in the beginning of every reset
>>> function, add a hack to enable MODULEMODE bits(since we don't want hwmod
>>> fwk to touch MODULEMODE for the DSS submodules), and then set the soft
>>> reset bits.
>>
>> I thought about that also. We'd need reset functions for all of them,
>> and for omap2/3 we'd just reset the submodules again as they have
>> already been reset with the dss core reset.
>>
>> The dss submodule resets are a bit linked. For omap2/3 the connection is
>> obvious as dss core reset resets also the submodules, and for omap4 we
>> have this requirement for the modulemode. That's why I though it'd be
>> perhaps cleaner to handle the reset of the DSS block as a whole, in one
>> place.
>>
>>> Your approach would ensure that we get a clean reset of DSS, but it
>>> would still give the annoying prints when each of the submodule tries to
>>> reset itself.
>>
>> The other submodules would not be reset by the hwmod framework at all,
>> so there wouldn't be prints. I think there's a flag for that.
Sorry for bringing up an old thread. I was working on cleaning up the
OMAP4 DSS related clock/pm issues, hence brought it up.
We were discussing here on how to setting up and reset the OMAP4 DSS
submodules correctly without tying the MODULEMODE bits to the
corresponding hwmods.
Tomi, your suggestion was to do soft resets for the submodules manually
in the dss_core hwmod's custom reset function itself, and use the flag
HWMOD_INIT_NO_RESET to prevent _reset() being called.
However, this won't still resolve the issue of the errors we see a
bootup. The function _setup_reset() looks like this:
static int _setup_reset(struct omap_hwmod *oh)
{
...
r = _enable(oh);
if (r) {
pr_warning("omap_hwmod: %s: cannot be enabled for
reset (%d)\n", oh->name, oh->_state);
return -EINVAL;
}
...
if (!(oh->flags & HWMOD_INIT_NO_RESET))
r = _reset(oh);
...
}
So, even if we have ask hwmod not to reset the DSS submodules, it will
still try to enable them, and we can't enable them since MODULEMODE
isn't tied to them. I don't see how we can get a clean reset done for
the DSS submodules without making some changes in hwmod framework.
Archit
^ permalink raw reply
* [PATCH 0/3] ocp2scp: add non-dt support
From: Kishon Vijay Abraham I @ 2012-10-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
This patch series allows ocp2scp driver to create its child devices
from the platform data.
In omap platforms, usb phy is connected to ocp2scp and usb phy is needed
for MUSB to be functional. When ocp2scp driver was added, it had only dt
support which means it wont create usb phy devices for non-dt boot.
This patch series adds non-dt support to ocp2scp and this series is needed
for getting MUSB functioanl in non-dt boot.
This patch series is rebased on linux-next. Let me know if it had to be
based on some other tree.
Did a quick testing for g_zero enumeration in panda board.
Kishon Vijay Abraham I (3):
drivers: bus: ocp2scp: add pdata support
ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
ARM: OMAP: ocp2scp: create omap device for ocp2scp
arch/arm/mach-omap2/devices.c | 72 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 +++++++++++
drivers/bus/omap-ocp2scp.c | 67 ++++++++++++++++++++++++--
include/linux/platform_data/omap_ocp2scp.h | 31 ++++++++++++
4 files changed, 195 insertions(+), 3 deletions(-)
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/3] drivers: bus: ocp2scp: add pdata support
From: Kishon Vijay Abraham I @ 2012-10-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431628-2819-1-git-send-email-kishon@ti.com>
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/bus/omap-ocp2scp.c | 67 ++++++++++++++++++++++++++--
include/linux/platform_data/omap_ocp2scp.h | 31 +++++++++++++
2 files changed, 95 insertions(+), 3 deletions(-)
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index ff63560..5db8297 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -22,6 +22,26 @@
#include <linux/pm_runtime.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/platform_data/omap_ocp2scp.h>
+
+/**
+ * _count_resources - count for the number of resources
+ * @res: struct resource *
+ *
+ * Count and return the number of resources populated for the device that is
+ * connected to ocp2scp.
+ */
+static unsigned _count_resources(struct resource *res)
+{
+ int cnt = 0;
+
+ while (res->start != res->end) {
+ cnt++;
+ res++;
+ }
+
+ return cnt;
+}
static int ocp2scp_remove_devices(struct device *dev, void *c)
{
@@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
{
- int ret;
- struct device_node *np = pdev->dev.of_node;
+ int ret;
+ unsigned res_cnt, i;
+ struct device_node *np = pdev->dev.of_node;
+ struct platform_device *pdev_child;
+ struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
+ struct omap_ocp2scp_dev *dev;
if (np) {
ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
if (ret) {
- dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n");
+ dev_err(&pdev->dev,
+ "failed to add resources for ocp2scp child\n");
goto err0;
}
+ } else if (pdata) {
+ for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
+ dev++) {
+ res_cnt = _count_resources(dev->res);
+
+ pdev_child = platform_device_alloc(dev->drv_name, -1);
+ if (!pdev_child) {
+ dev_err(&pdev->dev,
+ "failed to allocate mem for ocp2scp child\n");
+ goto err0;
+ }
+
+ ret = platform_device_add_resources(pdev_child,
+ dev->res, res_cnt);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to add resources for ocp2scp child\n");
+ goto err1;
+ }
+
+ pdev_child->dev.parent = &pdev->dev;
+
+ ret = platform_device_add(pdev_child);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to register ocp2scp child device\n");
+ goto err1;
+ }
+ }
+ } else {
+ dev_err(&pdev->dev, "OCP2SCP initialized without plat data\n");
+ return -EINVAL;
}
+
pm_runtime_enable(&pdev->dev);
return 0;
+err1:
+ platform_device_put(pdev_child);
+
err0:
device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
diff --git a/include/linux/platform_data/omap_ocp2scp.h b/include/linux/platform_data/omap_ocp2scp.h
new file mode 100644
index 0000000..5c6c393
--- /dev/null
+++ b/include/linux/platform_data/omap_ocp2scp.h
@@ -0,0 +1,31 @@
+/*
+ * omap_ocp2scp.h -- ocp2scp header file
+ *
+ * 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_OCP2SCP_H
+#define __DRIVERS_OMAP_OCP2SCP_H
+
+struct omap_ocp2scp_dev {
+ const char *drv_name;
+ struct resource *res;
+};
+
+struct omap_ocp2scp_platform_data {
+ int dev_cnt;
+ struct omap_ocp2scp_dev **devices;
+};
+#endif /* __DRIVERS_OMAP_OCP2SCP_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
From: Kishon Vijay Abraham I @ 2012-10-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431628-2819-1-git-send-email-kishon@ti.com>
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..cf579b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/platform_data/gpio-omap.h>
#include <linux/power/smartreflex.h>
+#include <linux/platform_data/omap_ocp2scp.h>
#include <plat/omap_hwmod.h>
#include <plat/i2c.h>
@@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
.sysc = &omap44xx_ocp2scp_sysc,
};
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+ {
+ .name = "usb_phy",
+ .start = 0x4a0ad080,
+ .end = 0x4a0ae000,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .name = "ctrl_dev",
+ .start = 0x4a002300,
+ .end = 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ { }
+};
+
+static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
+ {
+ .drv_name = "omap-usb2",
+ .res = omap44xx_usb_phy_and_pll_addrs,
+ },
+ { }
+};
+
/* ocp2scp_usb_phy */
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = "ocp2scp_usb_phy",
@@ -2694,6 +2721,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.modulemode = MODULEMODE_HWCTRL,
},
},
+ .dev_attr = ocp2scp_dev_attr,
};
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
From: Kishon Vijay Abraham I @ 2012-10-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431628-2819-1-git-send-email-kishon@ti.com>
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/mach-omap2/devices.c | 72 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e2ba505 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,7 @@
#include <linux/of.h>
#include <linux/pinctrl/machine.h>
#include <linux/platform_data/omap4-keypad.h>
+#include <linux/platform_data/omap_ocp2scp.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -613,6 +614,76 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
+#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
+static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
+{
+ int cnt = 0;
+
+ while (ocp2scp_dev->drv_name != NULL) {
+ cnt++;
+ ocp2scp_dev++;
+ }
+
+ return cnt;
+}
+
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char *oh_name, *name;
+ struct omap_ocp2scp_platform_data *pdata;
+
+ oh_name = "ocp2scp_usb_phy";
+ name = "omap-ocp2scp";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("%s: could not find omap_hwmod for %s\n", __func__,
+ oh_name);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err("%s: No memory for ocp2scp pdata\n", __func__);
+ return;
+ }
+
+ ocp2scp_dev = oh->dev_attr;
+ dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+ if (!dev_cnt) {
+ pr_err("%s: No devices connected to ocp2scp\n", __func__);
+ return;
+ }
+
+ pdata->devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+ * dev_cnt, GFP_KERNEL);
+ if (!pdata->devices) {
+ pr_err("%s: No memory for ocp2scp pdata devices\n", __func__);
+ return;
+ }
+
+ for (i = 0; i < dev_cnt; i++, ocp2scp_dev++)
+ pdata->devices[i] = ocp2scp_dev;
+
+ pdata->dev_cnt = dev_cnt;
+
+ pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+ 0, false);
+ if (IS_ERR(pdev)) {
+ pr_err("Could not build omap_device for %s %s\n",
+ name, oh_name);
+ return;
+ }
+}
+#else
+static inline void omap_init_ocp2scp(void) { }
+#endif
+
/*-------------------------------------------------------------------------*/
static int __init omap2_init_devices(void)
@@ -640,6 +711,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_ocp2scp();
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC] arm/mm: add a protection when flushing anonymous pages
From: Andrew Yan-Pai Chen @ 2012-10-05 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005091006.GM4625@n2100.arm.linux.org.uk>
On Fri, Oct 5, 2012 at 5:10 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Oct 02, 2012 at 03:07:33PM +0800, Andrew Yan-Pai Chen wrote:
>> [RFC PATCH] make flush_pfn_alias() nonpreemptible
>>
>> Since flush_pfn_alias() is preemptible, it is possible to be
>> preempted just after set_top_pte() is done. If the process
>> which preempts the previous happened to invoke flush_pfn_alias()
>> with the same colour vaddr as that of the previous, the same
>> top pte will be overwritten. When switching back to the previous,
>> it attempts to flush cache lines with incorrect mapping. Then
>> no lines (or wrong lines) will be flushed because of the nature
>> of vipt caches.
>>
>> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
>> index 40ca11e..bd07918 100644
>> --- a/arch/arm/mm/flush.c
>> +++ b/arch/arm/mm/flush.c
>> @@ -27,6 +27,8 @@ static void flush_pfn_alias(unsigned long pfn,
>> unsigned long vaddr)
>> unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
>> PAGE_SHIFT);
>> const int zero = 0;
>>
>> + preempt_disable();
>> +
>> set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
>>
>> asm( "mcrr p15, 0, %1, %0, c14\n"
>> @@ -34,6 +36,8 @@ static void flush_pfn_alias(unsigned long pfn,
>> unsigned long vaddr)
>> :
>> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
>> : "cc");
>> +
>> + preempt_enable();
>> }
>
> This looks like it's quite correct, but if you look at the file a little
> deeper, you'll notice that flush_icache_alias() potentially suffers the
> same issue.
>
> They should probably both also have a comment indicating that they're not
> to be called for SMP setups (because there's no locking for that.)
OK. I will resend the patch later.
Thanks!
--
Regards,
Andrew
^ permalink raw reply
* [PATCH 0/2] Enable ehci and ohci devices for exynos5250
From: Vivek Gautam @ 2012-10-05 10:10 UTC (permalink / raw)
To: linux-arm-kernel
Based on for-next branch of linux-samsung.
Vivek Gautam (2):
ARM: Exynos5250: Enabling ehci-s5p driver
ARM: Exynos5250: Enabling ohci-exynos driver
.../devicetree/bindings/usb/exynos-usb.txt | 40 ++++++++++++++++++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 12 ++++++
arch/arm/mach-exynos/include/mach/map.h | 2 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 4 ++
5 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
--
1.7.6.5
^ 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