* [RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X
From: Richard Zhao @ 2011-03-03 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302163326.GG22310@pengutronix.de>
Hi Uwe,
On Wed, Mar 02, 2011 at 05:33:26PM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 03, 2011 at 12:06:05AM +0800, Richard Zhao wrote:
> > Hi Uwe,
> >
> > Thanks for your detailed explanation!
> > On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
> > > Hello Richard,
> > >
> > > On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> > > > Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> > > >
> > > > My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> > > > and every board can be selected/unselected, and SOC_XXX be selected
> > > > by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
> > > My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:
> > >
> > > - ARCH_MX.. should be only a helper to group all machines together that
> > > can be built in a single image. In the far future it hopefully dies
> > > because we can compile everything together. These IMHO should not be
> > > used in Makefiles or source files at all as the grouping can change
> > > over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
> > > about a better naming scheme, so if you have suggestions don't
> > > hesitate to tell them.
> > Would it make sense to go straight forward?
> > ARCH_MX.. for SoC series. eg. ARCH_MX1/2/3/5. It groups SoCs.
> This doesn't work. Where do you want to put i.MX25? Conceptually the
> easy groups are { i.MX21, i.MX27 } and { i.MX25, i.MX31, i.MX35 }
> because these share PHYS_OFFSETs. And note that i.MX31 has a different
> iomuxer than i.MX25 and i.MX35. As soon as we have support for runtime
> PHYS_OFFSET the remaining groups are:
>
> ARMv4 + ARMv5 vs. ARMv6 + ARMv7
>
> (I think) which doesn't match the ARCH_MX1/2/3/5 approach anymore.
I see, you goup it by same features.
>
> > SOC_IMX.. for single SoC. eg. SOC_IMX31/35/50/51/53. It groups Machines.
> > MACH_.. for single machine. eg. MACH_MX51_BABBAGE.
> >
> > They can be used in Makefiles to help include source files, but idealy not be
> > used in source files. For multi-soc in single image, it's more easy to select
> > build targets. It can also help transit to single image step by step.
> Here I'd prefer things like:
>
> config SOC_IMX21
> bool
> select IMX_HAVE_IOMUX_V1
>
> obj-$(IMX_HAVE_IOMUX_V1) += tralala.o
>
> > > - MACH_MX.. actually are misnomers becauce they clash with the name
> > > space of the machine db. So they should be substituted by SOC_IMX...
> > > (maybe a few by ARCH_MX..) (affected: MACH_MX21 and MACH_MX27)
> > > - SOC_IMX.. are used to differentiate between SoCs.
> > >
> > > So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
> > > files and try to use the SOC_IMX variables instead.
> > > Here I consider important that SOC_IMX... is really only used with
> > > having multi-SoC-kernels in mind. So you can consider ARCH_MX and
> > > MACH_MX as todo-markers for that (and this is the main difference IMHO).
> > > E.g. the Makefile.boots are such a place that are not multi-soc capable
> > > yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
> > > somehow.
> > The ToDO markers might label itself as markers, Or it cause many people
> > confused.
> I don't know what you mean here.
I mean need more comments at:
if ARCH_MX5
# ARCH_MX51 and ARCH_MX50 are left for compatibility
>
> > And are you sure we won't need ARCH_MX.. in the final single image solution?
> > IMHO, single image needs to select what targetis it builds for too. The ARCH_MX..
> > works as categories and help reduce image size.
> Again, I don't understand you here.
I mean ARCH_MX1/2/3 is easy to group SoCs and boards, and esay to select the set
of SoCs/Boards I want to build the kernel for.
>
> > > I don't know if it's sensible to coordinate this effort, it mainly
> > > depends on how many people are willing to help. I'll start with ARCH_MX2
> > > and MACH_MX2[17] next.
> > >
> > > A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
> > > allow them to be merged into mach-imx. I didn't look at all on mxc91231,
> > > yet.
> > >
> > > Comments and patches are welcome. If you want to help and don't know
> > > where to start, here are a few hints:
> > >
> > > - git grep -E 'M?AR?CH_MX' drivers
> > > - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation
> > >
> > > Richard, having said that, some of your changes look OK, while I'm not
> > > completely happy with the others.
> > It seems only PHYS_OFFSET are not ok?
> and Makefile.boot
ok. so, I will send out patch leaving the two places unchanged.
Thanks
Richard
>
> > Maybe the p2v patch can help?
> Indeed.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* [PATCH 0/3] OMAP2+ hwmod fixes
From: Paul Walmsley @ 2011-03-03 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D2589.3090505@ti.com>
Hi Beno?t,
On Tue, 1 Mar 2011, Cousson, Benoit wrote:
> So to conclude, I will drop the #3 and just push #1 and #2.
>
> #1 is fine with addition of the WARN.
We should probably drop this one now that _setup() is allowed to be called
on hwmods that have already been setup (commit 48d54f3f).
> #2 does return an error but does not print anything, but since each call
> (_init_main_clk, _init_interface_clks, _init_opt_clks) does report
> some pr_warn in case of error, this is fine.
#2 looks fine to me.
- Paul
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-03 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6E218F.2020804@stericsson.com>
On 03/02/2011 02:53 AM, Maxime Coquelin wrote:
> On 03/02/2011 11:36 AM, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for
>>> all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have
>> 32-bit
>> etc.
>
> Yes, here is the difficulty. For example, in our case, the SoC unique ID
> is 160 bits long.
> Maybe it would be a better solution to get rid of this unified file, and
> keep only mach specific entries? I mean :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/mach_name
> /sys/devices/system/soc/foo_id
> /sys/devices/system/soc/bar_id
Sorry for the late reply guys. Got wrapped up is some other stuff.
I'm with Maxime on getting rid of the unique id file. It's not as if
it's unique across all machs and archs. Any user space caring to look at
the id will anyway have to check the mach/family first. So, there is no
point in having this unique id file. It just adds more weirdness and
complexity to deal with the different formats or ways each family wants
to export the id. Actually, in the case of MSM, we don't have any need
to export unique id. We just want to export what type of soc it is
within the MSM family.
As for the path, it's not clear we have settled on the final path. I see
us ping-pong between /sys/devices/system/soc/ and
/sys/devices/system/soc/mach/. Can we drop the "mach" subdir? Seems
pointless.
The mandatory file, I would like to call it "family", since "mach" is
too specific (omap3 and omap4 is my usual example -- they can have one
implementation of socinfo and report the family as "omap"). We don't
want people to misunderstand "mach" to be an accurate representation of
the xxxx in mach-xxxx.
The patch that adds this should probably allow each socinfo
implementation to specify the family name and an array of attributes
(struct attribute *) that can be used to expose whatever else they want
to export.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice
From: Richard Zhao @ 2011-03-03 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299086585-22707-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
> The only use of selecting MX2-based before was to get the choice to select
> between i.MX21 and i.MX27. So better provide this choice directly.
>
> Note that this has an influence on reduced i.MX21 configs because the
> former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
> appear in the reduced config and so the default for "Freescale CPU family:"
> (i.e. ARCH_MX3) is used now. mx21_defconfig is adapted not to be affected
> by this problem.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> arch/arm/configs/mx21_defconfig | 2 +-
> arch/arm/configs/mx27_defconfig | 1 -
> arch/arm/mach-imx/Kconfig | 20 --------------------
> arch/arm/plat-mxc/Kconfig | 19 ++++++++++++++++---
> 4 files changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
> index a5a71c2..761fea6 100644
> --- a/arch/arm/configs/mx21_defconfig
> +++ b/arch/arm/configs/mx21_defconfig
> @@ -12,7 +12,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> # CONFIG_IOSCHED_CFQ is not set
> CONFIG_ARCH_MXC=y
> -CONFIG_ARCH_MX2=y
> +CONFIG_MACH_MX21=y
> CONFIG_MACH_MX21ADS=y
> CONFIG_MXC_PWM=y
> CONFIG_NO_HZ=y
> diff --git a/arch/arm/configs/mx27_defconfig b/arch/arm/configs/mx27_defconfig
> index 3817c60..098d77d 100644
> --- a/arch/arm/configs/mx27_defconfig
> +++ b/arch/arm/configs/mx27_defconfig
> @@ -17,7 +17,6 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> # CONFIG_IOSCHED_CFQ is not set
> CONFIG_ARCH_MXC=y
> -CONFIG_ARCH_MX2=y
> CONFIG_MACH_MX27=y
> CONFIG_MACH_MX27ADS=y
> CONFIG_MACH_PCM038=y
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index c172418..c94cbad 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -53,26 +53,6 @@ config MACH_SCB9328
>
> endif
>
> -if ARCH_MX2
> -
> -choice
> - prompt "CPUs:"
> - default MACH_MX21
> -
> -config MACH_MX21
> - bool "i.MX21 support"
> - help
> - This enables support for Freescale's MX2 based i.MX21 processor.
> -
> -config MACH_MX27
> - bool "i.MX27 support"
> - help
> - This enables support for Freescale's MX2 based i.MX27 processor.
> -
> -endchoice
> -
> -endif
> -
> if MACH_MX21
>
> comment "MX21 platforms:"
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index 389f217..03a9a9e 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -2,6 +2,10 @@ if ARCH_MXC
>
> source "arch/arm/plat-mxc/devices/Kconfig"
>
> +config ARCH_MX2
> + # don't use this in new code
> + bool
> +
> menu "Freescale MXC Implementations"
>
> choice
> @@ -14,16 +18,25 @@ config ARCH_MX1
> help
> This enables support for systems based on the Freescale i.MX1 family
>
> -config ARCH_MX2
> - bool "MX2-based"
> +config MACH_MX21
> + bool "MX21-based"
> + select ARCH_MX2
> help
> - This enables support for systems based on the Freescale i.MX2 family
> + This enables support for systems based on the Freescale i.MX21 family
Is it ToDo marker like ARCH_51? Why is it MACH_xx while others are ARCH_XX?
It might be little strange that mx2x is a excetion while others are grouped.
Thanks
Richard
>
> config ARCH_MX25
> bool "MX25-based"
> + # note that i.MX25 doesn't match the expectations that are currently
> + # called ARCH_MX2
> help
> This enables support for systems based on the Freescale i.MX25 family
>
> +config MACH_MX27
> + bool "MX27-based"
> + select ARCH_MX2
> + help
> + This enables support for Freescale's MX2 based i.MX27 processor.
> +
> config ARCH_MX3
> bool "MX3-based"
> select CPU_V6
> --
> 1.7.2.3
>
>
^ permalink raw reply
* [PATCH] ST SPEAr: PCIe Gadget: Documentation for support of multiple device
From: Pratyush Anand @ 2011-03-03 5:16 UTC (permalink / raw)
To: linux-arm-kernel
Directory naming scheme for multiple PCIe device has been mentioned.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
---
.../ABI/testing/configfs-spear-pcie-gadget | 5 +++--
Documentation/misc-devices/spear-pcie-gadget.txt | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-spear-pcie-gadget b/Documentation/ABI/testing/configfs-spear-pcie-gadget
index 29593d0..7c02b32 100644
--- a/Documentation/ABI/testing/configfs-spear-pcie-gadget
+++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget
@@ -12,8 +12,9 @@ Description:
Nodes are only visible when configfs is mounted. To mount configfs
in /config directory use:
# mount -t configfs none /config/
-
- /config/pcie-gadget/
+
+ For nth PCIe Device Controller
+ /config/pcie-gadget.n/
link ... used to enable ltssm and read its status.
int_type ...used to configure and read type of supported
interrupt
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
index 7b86b80..02c13ef 100644
--- a/Documentation/misc-devices/spear-pcie-gadget.txt
+++ b/Documentation/misc-devices/spear-pcie-gadget.txt
@@ -66,7 +66,8 @@ Node programming example
Program all PCIe registers in such a way that when this device is connected
to the PCIe host, then host sees this device as 1MB RAM.
#mount -t configfs none /Config
-# cd /config/pcie_gadget/
+For nth PCIe Device Controller
+# cd /config/pcie_gadget.n/
Now you have all the nodes in this directory.
program vendor id as 0x104a
# echo 104A >> vendor_id
--
1.6.0.2
^ permalink raw reply related
* [PATCH] ARM: EXYNOS4: enabled lcd and backlight in NURI board
From: Kukjin Kim @ 2011-03-03 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299028671-9062-1-git-send-email-dh09.lee@samsung.com>
Donghwa Lee wrote:
>
> This patch enables lcd and backlight drivers in NURI board.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ------
> arch/arm/configs/exynos4_nuri_defconfig | 9 +++-
> arch/arm/mach-exynos4/Kconfig | 1 +
> arch/arm/mach-exynos4/mach-nuri.c | 62
> +++++++++++++++++++++++++++++++
> 3 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/configs/exynos4_nuri_defconfig
> b/arch/arm/configs/exynos4_nuri_defconfig
> index 5f03027..e2f0bfb 100644
> --- a/arch/arm/configs/exynos4_nuri_defconfig
> +++ b/arch/arm/configs/exynos4_nuri_defconfig
> @@ -786,8 +786,13 @@ CONFIG_REGULATOR=y
> # CONFIG_DRM is not set
> # CONFIG_VGASTATE is not set
> # CONFIG_VIDEO_OUTPUT_CONTROL is not set
> -# CONFIG_FB is not set
> -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> +CONFIG_FB=y
> +CONFIG_FB_S3C=y
> +CONFIG_LCD_CLASS_DEVICE=y
> +CONFIG_LCD_PLATFORM=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_BACKLIGHT_PWM=y
>
Hmm...where is exynos4_nuri_defconfig?
And as I said, don't add machine specific defconfig now...
I'm thinking about handling specific CONFIGs on each machine with one
defconfig.
> #
> # Display device support
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 5bf00b9..1d0d222 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -135,6 +135,7 @@ config MACH_NURI
> select EXYNOS4_SETUP_I2C1
> select EXYNOS4_SETUP_I2C5
> select EXYNOS4_SETUP_SDHCI
> + select HAVE_PWM
Since Banajit's PWM backlight patches will be merged, should be following
your next patch.
+ select SAMSUNG_DEV_PWM
> help
> Machine support for Samsung Mobile NURI Board.
>
> diff --git a/arch/arm/mach-exynos4/mach-nuri.c
b/arch/arm/mach-exynos4/mach-
> nuri.c
> index 28010bd..d06cc91 100644
> --- a/arch/arm/mach-exynos4/mach-nuri.c
> +++ b/arch/arm/mach-exynos4/mach-nuri.c
> @@ -17,6 +17,10 @@
> #include <linux/regulator/machine.h>
> #include <linux/regulator/fixed.h>
> #include <linux/mmc/host.h>
> +#include <linux/fb.h>
> +#include <linux/pwm_backlight.h>
> +
> +#include <video/platform_lcd.h>
>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
> @@ -26,6 +30,8 @@
> #include <plat/cpu.h>
> #include <plat/devs.h>
> #include <plat/sdhci.h>
> +#include <plat/fb.h>
> +#include <plat/regs-fb.h>
>
> #include <mach/map.h>
>
> @@ -181,6 +187,60 @@ static struct platform_device nuri_gpio_keys = {
> },
> };
>
> +static int lcd_power_on(struct lcd_device *ld, int enable)
Should be following..."void" and "struct plat_lcd_data *" ?
static void nuri_lcd_power_on(struct plat_lcd_data *ld, int enable)
> +{
> + int gpio = EXYNOS4_GPE1(5);
> +
> + gpio_request(gpio, "LVDS_nSHDN");
> +
> + if (enable)
> + gpio_direction_output(gpio, 1);
> + else
> + gpio_direction_output(gpio, 0);
how about following?
gpio_direction_output(gpio, enable); ?
> +
> + return 0;
So no need...
> +}
> +
> +static int backlight_init(struct device *dev)
Please don't use common function name even though it is used with 'static'
> +{
Don't we need any gpio configuration for this?
> + return 0;
> +}
> +
> +/* nuri pwm backlight */
> +static struct platform_pwm_backlight_data nuri_backlight_data = {
> + .pwm_id = 0,
> + .pwm_period_ns = 30000,
> + .max_brightness = 100,
> + .dft_brightness = 50,
> + .init = backlight_init,
> +};
> +
> +static struct platform_device nuri_backlight_device = {
> + .name = "pwm-backlight",
> + .id = -1,
> + .dev = {
No need following here?
.parent = &s3c_device_timer[0].dev,
> + .platform_data = &nuri_backlight_data,
> + },
> +};
> +
> +static struct plat_lcd_data nuri_lcd_platform_data = {
> + .set_power = lcd_power_on,
> +};
> +
> +static struct platform_device nuri_lcd_device = {
> + .name = "platform-lcd",
> + .id = -1,
> + .dev = {
> + .platform_data = (void *) &nuri_lcd_platform_data,
.platform_data = &nuri_lcd_platform_data,
> + },
> +};
> +
> +static void __init nuri_fb_init(void)
> +{
> + platform_device_register(&nuri_lcd_device);
> + platform_device_register(&nuri_backlight_device);
How about to add above into nuri_devices[] instead?
> +}
> +
> /* I2C1 */
> static struct i2c_board_info i2c1_devs[] __initdata = {
> /* Gyro, To be updated */
> @@ -201,6 +261,7 @@ static struct platform_device *nuri_devices[]
__initdata
> = {
> &s3c_device_wdt,
> #endif
>
> + &s3c_device_timer[0],
> /* NURI Devices */
> &nuri_gpio_keys,
> };
> @@ -219,6 +280,7 @@ static void __init nuri_machine_init(void)
> i2c_register_board_info(1, i2c1_devs, ARRAY_SIZE(i2c1_devs));
> i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));
>
> + nuri_fb_init();
> /* Last */
> platform_add_devices(nuri_devices, ARRAY_SIZE(nuri_devices));
> }
> --
> 1.6.0.4
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
From: Sricharan R @ 2011-03-03 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=MJigLvbJrRJ4CpyDcGd8sZXB7-1nFYup6EeDm@mail.gmail.com>
Hi,
>-----Original Message-----
>From: Govindraj [mailto:govindraj.ti at gmail.com]
>Sent: Wednesday, March 02, 2011 3:37 PM
>To: Sricharan R
>Cc: Govindraj.R; linux-omap at vger.kernel.org;
linux-serial at vger.kernel.org;
>linux-arm-kernel at lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
>Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
>Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
>configured from board file
>
>On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R <r.sricharan@ti.com> wrote:
>> Hi,
>>>-----Original Message-----
>>>From: Govindraj [mailto:govindraj.ti at gmail.com]
>>>Sent: Wednesday, March 02, 2011 1:11 PM
>>>To: Sricharan R
>>>Cc: Govindraj.R; linux-omap at vger.kernel.org;
>> linux-serial at vger.kernel.org;
>>>linux-arm-kernel at lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
>>>Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
>>>Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
>>>configured from board file
>>>
>>>On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R <r.sricharan@ti.com>
wrote:
>>>> Hi,
>>>>>diff --git a/arch/arm/mach-omap2/serial.c
>> b/arch/arm/mach-omap2/serial.c
>>>>>index 755f4aa..530e9e3 100644
>>>>>--- a/arch/arm/mach-omap2/serial.c
>>>>>+++ b/arch/arm/mach-omap2/serial.c
>>>>>@@ -44,6 +44,15 @@
>>>>>
>>>>> static int omap_uart_con_id __initdata = -1;
>>>>>
>>>>>+static struct omap_uart_port_info omap_serial_default_info[] = {
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.dma_enabled ? ?= 0,
>>>>>+ ? ? ? ? ? ? ?.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
>>>>>+ ? ? ? ? ? ? ?.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
>>>>>+ ? ? ? ? ? ? ?.idle_timeout ? = DEFAULT_IDLE_TIMEOUT,
>>>>>+ ? ? ?},
>>>>>+};
>>>>>+
>>>>> static int uart_idle_hwmod(struct omap_device *od)
>>>>> {
>>>>> ? ? ? omap_hwmod_idle(od->hwmods[0]);
>>>>>@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
>>>> omap_uart_latency[]
>>>>>= {
>>>>> ? ? ? },
>>>>> };
>>>>>
>>>>>+#ifdef CONFIG_OMAP_MUX
>>>>>+static struct omap_device_pad default_serial0_pads[] __initdata = {
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.name ? = "uart1_rx.uart1_rx",
>>>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>>>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>>>>+ ? ? ?},
>>>>>+};
>>>>>+
>>>>>+static struct omap_device_pad default_serial1_pads[] __initdata = {
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.name ? = "uart2_rx.uart2_rx",
>>>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>>>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>>>>+ ? ? ?},
>>>>>+};
>>>>>+
>>>>>+static struct omap_device_pad default_serial2_pads[] __initdata = {
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.name ? = "uart3_rx_irrx.uart3_rx_irrx",
>>>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>>>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>>>>+ ? ? ?},
>>>>>+};
>>>>>+
>>>>>+static struct omap_device_pad default_omap36xx_serial3_pads[]
>> __initdata
>>>> =
>>>>>{
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.name ? = "gpmc_wait3.uart4_rx",
>>>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>>>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE2,
>>>>>+ ? ? ?},
>>>>>+};
>>>>>+
>>>>>+static struct omap_device_pad default_omap4_serial3_pads[]
__initdata
>> =
>>>> {
>>>>>+ ? ? ?{
>>>>>+ ? ? ? ? ? ? ?.name ? = "uart4_rx.uart4_rx",
>>>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
>> OMAP_DEVICE_PAD_WAKEUP,
>>>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
>>>>>+ ? ? ?},
>>>>>+};
>>>> Here only the UART RX pins are muxed, so what about the cts, rts, tx
>>>pins?
>>>
>>>The intention here is to enable wakeup capabilities for uart rx pad.
>>>
>>>AFAIK most of the boards are currently dependent on bootloader for
>>>uart-muxing if any board is not dependent on bootloader then we
>>>can use omap_serial_init_port along with board_mux_info from board.
>>>
>> Yes. The idea is to be independent of the bootloaders for mux settings.
>>
>>>Prior to this change uart wakeup is based on rx_pad and we were
>> populating
>>>offset and using omap_ctrl api's to read/write which is cleaned up now.
>>>Most of boards are dependent on uart-rx wakeup to avoid breaking any
>>>board support we
>>>are using omap_serial_init by filling default values, which provides
>>>us with same
>>>environment but with right approach towards handling mux data with a
>>>handshake with
>>>hwmod framework.
>>>
>> Now, in this change only the RX pin is configured. So if some board
uses
>> omap_serial_init then only the RX is going to be configured.
>> How will they configure the rest of the pins?
>
>
>They should call omap_serial_init_port to configure each individual uart
>with
>mux_info filled and not use omap_serial_init.
>
>If any board is not dependent for mux from u-boot then they use above
said
>init_port func.
>
>
>> They cannot call omap_serial_init_port after this just to configure the
>> rest of the mux pins( cts, rts, tx).
>
>No. You need to use either omap_serial_init_port or omap_serial_init
>you cannot call both apis from board file please refer to both func
>documentation.
>
>Also please note i am not configuring all uart pins for pullups and pull
>downs
>with this patch series and its not related to this patch series.
>I am only enabling wakeup-enable pin for rx as it was done before.
>
>> So data which is passed from omap_serial_init should have the
>> configuration
>> for all the pins, and this default data should be consistent across
>> atleast
>> some boards, so that they can use this. This will reduce the data
>> duplication across board files.
>>
>> If this is not true, then all the pads can be configured from the board
>> files itself using omap_serial_init_port and you can set the required
>> RX wakeup capability there as well.
>>
>
>Yes that be done but currently but that is not in my intention here
>with my patch
>I just want to retain rx wakeup by default to avoid breaking support
>for any board.
>
>Adding pin mux for each individual pin is a separate activity where I
also
>need access to various boards So I am leaving that to developers who
>want to configure
>for the corresponding boards using init_port api.
>
>Removing mux from u-boot level and adding it to board file is beyond
>the scope of this
>patch series and is a separate topic of discussion, as current patch
series
>assumes that uarts are muxed from u-boot level and needs to only enable
>wakeup
>capability for rx-pin.
>
>Hope this clarifies.
>
It is true that this patch is not intending to configure the pads.
But my question is, after this patch say
1) some board file calls omap_serial_port.
2) As a result , all the uarts devices are build and only the Rx pad is
configured for each device.
3) After this there will be no way of configuring the rest of the pads
??
That should not happen. Also relying that the bootloaders are going
to do the configuration is not correct.
So if some board calls omap_serial_port then there should be default
values for all pads which a board can use, otherwise the board calls
omap_serial_init_port for each of the device.
>--
>Thanks,
>Govindraj.R
>
>
>>>So if any board needs specific mux they can go ahead and add required
>>>mux data in
>>>board file and use map_serial_init_port instead of current
>>>omap_serial_init.
>>>
>>>
>>>> Is it consistent that across all socs that only UART3 would have
>>>UART/IRDA
>>>> functions capability so that serial2 pads can always be called
>> "rx_irxx"
>>>> ?.
>>>
>>>Yes from OMAP2420 to OMAP4430 uart3 can used as irda.
>>>
>> Ok.
>>>--
>>>Thanks,
>>>Govindraj.R
>>
^ permalink raw reply
* [PATCH V5 Resend] ST SPEAr: PCIE gadget suppport
From: pratyush @ 2011-03-03 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110223160632.0b21c550.akpm@linux-foundation.org>
On 2/24/2011 5:36 AM, Andrew Morton wrote:
> On Mon, 21 Feb 2011 13:50:55 +0530
> Pratyush Anand <pratyush.anand@st.com> wrote:
>
>> This is a configurable gadget. can be configured by configfs interface. Any
>> IP available at PCIE bus can be programmed to be used by host
>> controller.It supoorts both INTX and MSI.
>> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
>> with size 0x1000
>>
>> Changes since V4:
>> - All documentation related comments incorporated
>>
>> Changes since V3:
>> - support for multiple instances of such device
>
> ^^ This doesn't seem to agree with the documentation.
>
Will add a line in documentation for it.
>> ...
>>
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget
>> @@ -0,0 +1,30 @@
>> +What: /config/pcie-gadget
>> +Date: Feb 2011
>> +KernelVersion: 2.6.37
>> +Contact: Pratyush Anand <pratyush.anand@st.com>
>> +Description:
>> +
>> + Interface is used to configure selected dual mode PCIe controller
>> + as device and then program its various registers to configure it
>> + as a particular device type.
>> + This interfaces can be used to show spear's PCIe device capability.
>> +
>> + Nodes are only visible when configfs is mounted. To mount configfs
>> + in /config directory use:
>> + # mount -t configfs none /config/
>> +
>> + /config/pcie-gadget/
>> + link ... used to enable ltssm and read its status.
>> + int_type ...used to configure and read type of supported
>> + interrupt
>> + no_of_msi ... used to configure number of MSI vector needed and
>> + to read no of MSI granted.
>> + inta ... write 1 to assert INTA and 0 to de-assert.
>> + send_msi ... write MSI vector to be sent.
>> + vendor_id ... used to write and read vendor id (hex)
>> + device_id ... used to write and read device id (hex)
>> + bar0_size ... used to write and read bar0_size
>> + bar0_address ... used to write and read bar0 mapped area in hex.
>> + bar0_rw_offset ... used to write and read offset of bar0 where
>> + bar0_data will be written or read.
>> + bar0_data ... used to write and read data at bar0_rw_offset.
>
> What's the configfs naming scheme for the second and later devices?
>
there would be pcie-gadget.n directory under /config for
nth PCIe Device Controller.
Regards
Pratyush
>
> .
>
^ permalink raw reply
* [PATCH/RFC 0/3] ARM: S5P: Add common DPHY control code for MIPI-CSIS/MIPI-DSIM devices
From: Kukjin Kim @ 2011-03-03 4:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299087289-29926-1-git-send-email-s.nawrocki@samsung.com>
Sylwester Nawrocki wrote:
>
> Hello,
>
> the following patch series adds a common platform code to enable control
> of MIPI-CSI receiver's DPHY from within it's V4L2 subdev driver. The
driver
> is supposed to support possibly all S5P SoCs variants and the PHY handling
> details need to be hidden in the platform code. The functionality behind
> "dphy_csis" clocks is not exact a functionality of the clock, but they
have
> common features. If the clock API rules are to strict to accept this kind
> of usage then I'm willing to create some intermediate layer that will
finally
> solve PHY handling for MIPI-CSI, MIPI-DSIM, USB, SATA.. devices, without
> issues
> on a common kernel binary for multiple boards.
>
>
> The patch series contains:
> [PATCH 1/3] ARM: S5P: Rename MIPI-CSIS header and update Copyright
> [PATCH 2/3] ARM: S5PV210: Add clock entries for MIPI DPHY control
> [PATCH 3/3] ARM: EXYNOS4: Add clock entries for MIPI DPHY control
>
> Rebased onto kgene-for-next branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
Maybe we discussed about this ago.
I remember, we agree that to control phy cannot be handled in clock part.
And didn't say to make some kind of common s5p phy setup/control function?
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/038038.ht
ml
I thought it is possible to make it even though some registers is in
different place.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [Qualcomm PM8921 MFD 5/6] MAINTAINERS: Add pmic8921, pmic8xxx subdevices maintainers
From: Abhijeet Dharmapurikar @ 2011-03-03 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299106213.4208.112.camel@Joe-Laptop>
Joe Perches wrote:
> On Wed, 2011-03-02 at 14:13 -0800, adharmap at codeaurora.org wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>
> The patch subject is not quite correct.
> You're adding patterns, not maintainers.
Ok will fix it in the next patch series.
> Another option is a wildcard pattern match like:
>
> F: drivers/*/pm8???-*
>
> instead of:
>
> F: drivers/gpio/pm8xxx-gpio.c
> F: drivers/mfd/pm8921-core.c
> F: drivers/mfd/pm8xxx-irq.c
> F: drivers/mfd/pm8xxx-mpp.c
Will do, thanks for this wildcard pattern
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support
From: Abhijeet Dharmapurikar @ 2011-03-03 4:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302224616.GB32325@opensource.wolfsonmicro.com>
Mark Brown wrote:
> On Wed, Mar 02, 2011 at 02:13:17PM -0800, adharmap at codeaurora.org wrote:
>> Change-Id: Ibb23878cd382af9a750d62ab49482f5dc72e3714
>> Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
>
> Remove the change IDs from upstream submissions. The kernel doesn't use
> gerritt.
>
>> struct pm8921 {
>> - struct device *dev;
>> + struct device *dev;
>> + struct device *irq_dev;
>
> Is it really useful to register a struct device purely for the interrupt
> controller? I'd have expected this to be core functionality of the
> device. The fact that you need to store the device at all is a bit odd
> too as you're using the MFD API.
This design is slightly different from other MFD drivers.
I separated the interrupt from the core because the interrupt
implementation for different Qualcomm pmics remains the same. On 8660
FFA boards for example, we have two pmic chips that have the same
interrupt subdevice implementation (the number of interrupts managed by
each is different). I didn't want to duplicate the exact code in the
core driver - hence a separate interrupt driver.
To answer why we need to keep a reference to irq_dev. This is so because
the gpio code needs to make calls on the irq driver to read the input
values. The gpio code calls pm8xxx_read_irq_stat() on the core and
expects it to read the value. The core then calls an api in the irq
driver (pm8xxx_get_irq_stat)passing it irq_dev to get the required values.
I could have made the gpio code call the irq code directly, but then
that would mean the irq driver has to go over all its devices and find
which device handles this irq number and then read it. That is too much
code execution as compared to remember the irq_dev for each core and let
the gpio code call read apis on it.
>
>> static struct pm8xxx_drvdata pm8921_drvdata = {
>> - .pmic_readb = pm8921_readb,
>> - .pmic_writeb = pm8921_writeb,
>> - .pmic_read_buf = pm8921_read_buf,
>> - .pmic_write_buf = pm8921_write_buf,
>> + .pmic_readb = pm8921_readb,
>> + .pmic_writeb = pm8921_writeb,
>> + .pmic_read_buf = pm8921_read_buf,
>> + .pmic_write_buf = pm8921_write_buf,
>> + .pmic_read_irq_stat = pm8921_read_irq_stat,
>> +};
>
> It'd seem better to indent things as per the final driver in the first
> patch - this reindentation creates a lot of noise in the diff.
>
>> goto err_read_rev;
>> }
>> - pr_info("PMIC revision: %02X\n", val);
>> + pr_info("PMIC revision 1: %02X\n", val);
>> + rev = val;
Yes will fix them
>>
>
> Again, do this in the first patch.
>
>> +static int
>> +pm8xxx_read_block(const struct pm_irq_chip *chip, u8 bp, u8 *ip)
>> +{
>> + int rc;
>> +
>> + rc = pm8xxx_writeb(chip->dev->parent,
>> + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
>> + if (rc) {
>> + pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
>> + goto bail_out;
>> + }
>> +
>> + rc = pm8xxx_readb(chip->dev->parent,
>> + SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
>> + if (rc)
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>> +bail_out:
>> + return rc;
>> +}
>
> The namespacing here is odd, this looks like it should be a generic API
> not a block specific one.
It indicates that the code intends to read a block of interrupt
statuses. The irq h/w is implemented as follows, there are 256
interrupts. One block manages 8 interrupts, so there are 32 blocks.
One master manages 8 blocks so there are 4 masters. And finally there
is one root that manages all the 4 masters.
When an interrupt triggers, the corresponding bit in the block, master
and root is set. The handler reads the root and figures out which master
is set. It then reads the master and figures out which block in that
master is set. It then reads the block to figure out which interrupt in
that block is set. This hardware design makes the handler find the
interrupt super quick as opposed to checking 256 bits when an interrupt
fires.
With that in mind, the driver has following functions
pm8xxxx_read_root
pm8xxxx_read_master
pm8xxxx_read_block
Do you still think I should change the name?
>
>> + /* Check IRQ bits */
>> + for (k = 0; k < 8; k++) {
>> + if (bits & (1 << k)) {
>> + pmirq = block * 8 + k;
>> + irq = pmirq + chip->irq_base;
>> + /* Check spurious interrupts */
>> + if (((1 << k) & chip->irqs_allowed[block])) {
>> + /* Found one */
>> + chip->irqs_to_handle[*handled] = irq;
>> + (*handled)++;
>> + } else { /* Clear and mask wrong one */
>> + config = PM_IRQF_W_C_M |
>> + (k << PM_IRQF_BITS_SHIFT);
>> +
>> + pm8xxx_config_irq(chip,
>> + block, config);
>> +
>> + if (pm8xxx_can_print())
>> + pr_err("Spurious IRQ: %d "
>> + "[block, bit]="
>> + "[%d, %d]\n",
>> + irq, block, k);
>> + }
>
> The generic IRQ code should be able to take care of spurious interrupts
> for you? It's a bit surprising that there's all this logic - I'd expect
> an IRQ chip to just defer logic about which interrupts are valid and so
> on to the generic IRQ code.
That is correct, the genirq does handle spurious interrupts gracefully.
Will fix this in the next patch series.
>> +
>> +#define NR_PM8921_IRQS 256
>
> Traditionally this'd be namespaced like this:
>
> +#define PM8921_NR_IRQS 256
ok good to know will change that.
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 1/3] ARM: S5P: Rename MIPI-CSIS header and update Copyright
From: Kukjin Kim @ 2011-03-03 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299087289-29926-2-git-send-email-s.nawrocki@samsung.com>
Sylwester Nawrocki wrote:
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/plat-s5p/dev-csis0.c | 2 +-
> arch/arm/plat-s5p/dev-csis1.c | 2 +-
> arch/arm/plat-s5p/include/plat/csis.h | 28
--------------------------
> --
> arch/arm/plat-s5p/include/plat/mipi_csis.h | 28
> ++++++++++++++++++++++++++++
> 4 files changed, 30 insertions(+), 30 deletions(-)
> delete mode 100644 arch/arm/plat-s5p/include/plat/csis.h
> create mode 100644 arch/arm/plat-s5p/include/plat/mipi_csis.h
>
Oops, why didn't use '-M'?
It can show me this like following.
.../plat-s5p/include/plat/{csis.h => mipi_csis.h} | 10 +++++-----
3 files changed, 7 insertions(+), 7 deletions(-)
rename arch/arm/plat-s5p/include/plat/{csis.h => mipi_csis.h} (68%)
Secondly, I remember this...
Following is your response at that time.
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/038037.ht
ml
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/8 resend] dw_dmac: Remove compilation dependency from AVR32
From: Shiraz Hashim @ 2011-03-03 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6F0E32.6050505@st.com>
On Thu, Mar 03, 2011 at 11:42:42AM +0800, Viresh KUMAR wrote:
> On 03/02/2011 10:16 PM, Koul, Vinod wrote:
> > On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
[...]
> >> drivers/dma/Kconfig | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >> index 1c28816..95c7db7 100644
> >> --- a/drivers/dma/Kconfig
> >> +++ b/drivers/dma/Kconfig
> >> @@ -82,7 +82,6 @@ config INTEL_IOP_ADMA
> >>
> >> config DW_DMAC
> >> tristate "Synopsys DesignWare AHB DMA support"
> >> - depends on AVR32
> > Shouldn't you be adding a corresponding depends on new arch? And since
> > this supports old arch as well, it should say depends on both...
>
> Why should this driver be dependent on ARM or AVR32? It can be present
> on any other arch too.. So i thought removing this dependency all together
> is better.
There could be a dependency on HAVE_CLK as it uses clock APIs.
--
regards
Shiraz
^ permalink raw reply
* [PATCH 8/8 resend] dw_dmac.c: Pass Channel Priority from platform_data
From: viresh kumar @ 2011-03-03 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299091561.6974.103.camel@vkoul-udesk3>
On 03/03/2011 12:16 AM, Koul, Vinod wrote:
> On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
>> In Synopsys designware, channel priority is programmable. This patch adds
>> support for passing channel priority through platform data. By default Ascending
>> channel priority will be followed, i.e. channel 0 will get highest priority and
>> channel 7 will get lowest.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> drivers/dma/dw_dmac.c | 11 ++++++++++-
>> drivers/dma/dw_dmac_regs.h | 3 +++
>> include/linux/dw_dmac.h | 4 +++-
>> 3 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> index 37ffd2c..edb3d3b 100644
>> --- a/drivers/dma/dw_dmac.c
>> +++ b/drivers/dma/dw_dmac.c
>> @@ -896,8 +896,11 @@ static int dwc_alloc_chan_resources(struct dma_chan *chan)
>> BUG_ON(!dws->dma_dev || dws->dma_dev != dw->dma.dev);
>>
>> cfghi = dws->cfg_hi;
>> - cfglo = dws->cfg_lo;
>> + cfglo = dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
>> }
>> +
>> + cfglo |= DWC_CFGL_CH_PRIOR(dwc->priority);
>> +
>> channel_writel(dwc, CFG_LO, cfglo);
>> channel_writel(dwc, CFG_HI, cfghi);
>>
>> @@ -1320,6 +1323,12 @@ static int __init dw_probe(struct platform_device *pdev)
>> else
>> list_add(&dwc->chan.device_node, &dw->dma.channels);
>>
>> + /* 7 is highest priority & 0 is lowest. */
>> + if (pdata->chan_priority == CHAN_PRIORITY_ASCENDING)
>> + dwc->priority = 7 - i;
>> + else
>> + dwc->priority = i;
>> +
>> dwc->ch_regs = &__dw_regs(dw)->CHAN[i];
>> spin_lock_init(&dwc->lock);
>> dwc->mask = 1 << i;
>> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
>> index d9a939f..6a8e6d3 100644
>> --- a/drivers/dma/dw_dmac_regs.h
>> +++ b/drivers/dma/dw_dmac_regs.h
>> @@ -101,6 +101,8 @@ struct dw_dma_regs {
>> #define DWC_CTLH_BLOCK_TS_MASK 0x00000fff
>>
>> /* Bitfields in CFG_LO. Platform-configurable bits are in <linux/dw_dmac.h> */
>> +#define DWC_CFGL_CH_PRIOR_MASK (0x7 << 5) /* priority mask */
>> +#define DWC_CFGL_CH_PRIOR(x) ((x) << 5) /* priority */
>> #define DWC_CFGL_CH_SUSP (1 << 8) /* pause xfer */
>> #define DWC_CFGL_FIFO_EMPTY (1 << 9) /* pause xfer */
>> #define DWC_CFGL_HS_DST (1 << 10) /* handshake w/dst */
>> @@ -134,6 +136,7 @@ struct dw_dma_chan {
>> struct dma_chan chan;
>> void __iomem *ch_regs;
>> u8 mask;
>> + u8 priority;
>>
>> spinlock_t lock;
>>
>> diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
>> index 057e883..53072c8 100644
>> --- a/include/linux/dw_dmac.h
>> +++ b/include/linux/dw_dmac.h
>> @@ -22,6 +22,9 @@ struct dw_dma_platform_data {
>> #define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
>> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
>> unsigned int chan_allocation_order;
>> +#define CHAN_PRIORITY_ASCENDING 0 /* chan0 highest */
>> +#define CHAN_PRIORITY_DESCENDING 1 /* chan7 highest */
> How about generic CHAN_ORDER_ASCENDING which you can use in both?
By both, you probably mean, both for allocation and priority??
Actually i thought of this, but realized thought, people might want
to control them separately. They may want priority ascending (0 to 7),
but may need allocation in reverse order (7 to 0). So kept them separate.
What do you say??
--
viresh
^ permalink raw reply
* [PATCH 7/8 resend] dw_dmac.c: Pass Channel Allocation Order from platform_data
From: viresh kumar @ 2011-03-03 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299091074.6974.96.camel@vkoul-udesk3>
On 03/03/2011 12:07 AM, Koul, Vinod wrote:
> On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
>> In SPEAr Platform channels 4-7 have more Fifo depth. So we must get better
>> channel first. This patch introduces concept of channel allocation order in
>> dw_dmac. If user doesn't paas anything or 0, than normal (ascending) channel
> pass?
Oops!!
>> allocation will follow, else channels will be allocated in descending order.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> drivers/dma/dw_dmac.c | 6 +++++-
>> include/linux/dw_dmac.h | 3 +++
>> 2 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> index 01f783d..37ffd2c 100644
>> --- a/drivers/dma/dw_dmac.c
>> +++ b/drivers/dma/dw_dmac.c
>> @@ -1314,7 +1314,11 @@ static int __init dw_probe(struct platform_device *pdev)
>> dwc->chan.device = &dw->dma;
>> dwc->chan.cookie = dwc->completed = 1;
>> dwc->chan.chan_id = i;
>> - list_add_tail(&dwc->chan.device_node, &dw->dma.channels);
>> + if (pdata->chan_allocation_order == CHAN_ALLOCATION_ASCENDING)
>> + list_add_tail(&dwc->chan.device_node,
>> + &dw->dma.channels);
>> + else
>> + list_add(&dwc->chan.device_node, &dw->dma.channels);
>>
>> dwc->ch_regs = &__dw_regs(dw)->CHAN[i];
>> spin_lock_init(&dwc->lock);
>> diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
>> index c8aad71..057e883 100644
>> --- a/include/linux/dw_dmac.h
>> +++ b/include/linux/dw_dmac.h
>> @@ -19,6 +19,9 @@
>> */
>> struct dw_dma_platform_data {
>> unsigned int nr_channels;
>> +#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
>> +#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
> Can you add these defines outside of this struct?
I did this deliberately. I feel this is probably the better way as it
tells us _clearly_ the place where this macro is going to be used.
So i would insist on keeping it as it is, if you agree??
>> + unsigned int chan_allocation_order;
--
viresh
^ permalink raw reply
* [PATCH 6/8 resend] dw_dmac: Mark all tx_descriptors with DMA_CRTL_ACK after xfer finish
From: viresh kumar @ 2011-03-03 3:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299090855.6974.94.camel@vkoul-udesk3>
On 03/03/2011 12:04 AM, Koul, Vinod wrote:
> On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
>> dwc_desc_get checks all descriptors for DMA_CTRL_ACK before allocating them for
>> transfers. And descriptors are not marked with DMA_CRTL_ACK after transfer
>> finishes. Thus descriptor once used is not usable again. This patch marks
>> descriptors with DMA_CRTL_ACK after dma xfer finishes
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> drivers/dma/dw_dmac.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> index c40b89f..01f783d 100644
>> --- a/drivers/dma/dw_dmac.c
>> +++ b/drivers/dma/dw_dmac.c
>> @@ -196,6 +196,7 @@ dwc_descriptor_complete(struct dw_dma_chan *dwc, struct dw_desc *desc)
>> dma_async_tx_callback callback;
>> void *param;
>> struct dma_async_tx_descriptor *txd = &desc->txd;
>> + struct dw_desc *child;
> Please align this with previous ones....
>
Will be done
--
viresh
^ permalink raw reply
* [PATCH 4/8 resend] dw_dmac: calling dwc_scan_descriptors from dwc_tx_status() after taking lock
From: viresh kumar @ 2011-03-03 3:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299089633.6974.93.camel@vkoul-udesk3>
On 03/02/2011 11:43 PM, Koul, Vinod wrote:
> On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> drivers/dma/dw_dmac.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> index 3bf4772..5cc5abf 100644
>> --- a/drivers/dma/dw_dmac.c
>> +++ b/drivers/dma/dw_dmac.c
>> @@ -830,7 +830,9 @@ dwc_tx_status(struct dma_chan *chan,
>>
>> ret = dma_async_is_complete(cookie, last_complete, last_used);
>> if (ret != DMA_SUCCESS) {
>> + spin_lock_bh(&dwc->lock);
>> dwc_scan_descriptors(to_dw_dma(chan->device), dwc);
>> + spin_unlock_bh(&dwc->lock);
>>
>> last_complete = dwc->completed;
>> last_used = chan->cookie;
>
> Please always add a short description in the patch, helps in long run
>
Sure.
> Shouldnt you be doing this for dwc_handle_error() as well? I see thats
> called without taking the lock....
>
dwc_handle_error is called from dw_dma_tasklet with lock held. So its not
required there.
--
viresh
^ permalink raw reply
* [PATCH 1/8 resend] dw_dmac: Remove compilation dependency from AVR32
From: viresh kumar @ 2011-03-03 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299084372.6974.91.camel@vkoul-udesk3>
On 03/02/2011 10:16 PM, Koul, Vinod wrote:
> On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
>> This will be used in SPEAr, ARM family.
> Does this mean it can be used on AVR32 now? Did you implay it will
> *also* be....
Yes, also be used in spear.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> drivers/dma/Kconfig | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index 1c28816..95c7db7 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -82,7 +82,6 @@ config INTEL_IOP_ADMA
>>
>> config DW_DMAC
>> tristate "Synopsys DesignWare AHB DMA support"
>> - depends on AVR32
> Shouldn't you be adding a corresponding depends on new arch? And since
> this supports old arch as well, it should say depends on both...
Why should this driver be dependent on ARM or AVR32? It can be present
on any other arch too.. So i thought removing this dependency all together
is better.
^ permalink raw reply
* [PATCH 0/8 resend] dw_dmac: Extending support & minor fixes
From: viresh kumar @ 2011-03-03 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299083974.6974.85.camel@vkoul-udesk3>
On 03/02/2011 10:09 PM, Koul, Vinod wrote:
>> >
> Please remember to copy the MAINTAINERS, (in this case Dan and me) thats
> why didn't get review last time.
Sorry for missing that!!
--
viresh
^ permalink raw reply
* [Qualcomm PM8921 MFD 1/6] mfd: pm8921: Add PMIC 8921 core driver
From: Abhijeet Dharmapurikar @ 2011-03-03 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302222850.GA32325@opensource.wolfsonmicro.com>
Mark Brown wrote:
> On Wed, Mar 02, 2011 at 02:13:16PM -0800, adharmap at codeaurora.org wrote:
>
>> +config MFD_PM8XXX
>> + tristate "Support for Qualcomm PM8xxx subdevices"
>> + help
>> + This option enables the usage of various Qualcomm PMIC 8xxx subdevice
>> + drivers. This is required in order to use generic PM8xxx subdevice
>> + drivers. Selecting with option will result in PM8xxx subdevice
>> + drivers being compiled by default.
>
> As this is selected by the driver it shouldn't have any help text -
> there's no point in users seeing the option since it's useless by
> itself. If we get enough to make an option useful either a menu or
> dependencies from the individual MFDs would be a better option.
Agree will fix this.
>
>> +static int __devinit pm8921_add_subdevices(const struct pm8921_platform_data
>> + *pdata,
>> + struct pm8921 *pmic)
>> +{
>> + return 0;
>> +}
>
> This looks suspicious.
True, the next patch fills in this function. Will remove it from here.
>
>> +static int __init pm8921_init(void)
>> +{
>> + return platform_driver_register(&pm8921_driver);
>> +}
>> +postcore_initcall(pm8921_init);
>
> Typically subsys_initcall() has been used.
Yes will change this and others to subsys_initcall()
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH V5 6/6] pxa3xx_nand: clean the keep configure code
From: Lei Wen @ 2011-03-03 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298901463.2809.27.camel@localhost>
Use nand_scan_ident to unify the need of mtd member initilization
for both normal detection and keep configuration method.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
Change log:
V5.1: Add comment for this patch
arch/arm/plat-pxa/include/plat/pxa3xx_nand.h | 2 +-
drivers/mtd/nand/pxa3xx_nand.c | 103 +++++++++-----------------
2 files changed, 36 insertions(+), 69 deletions(-)
diff --git a/arch/arm/plat-pxa/include/plat/pxa3xx_nand.h b/arch/arm/plat-pxa/include/plat/pxa3xx_nand.h
index 01a8448..442301f 100644
--- a/arch/arm/plat-pxa/include/plat/pxa3xx_nand.h
+++ b/arch/arm/plat-pxa/include/plat/pxa3xx_nand.h
@@ -30,6 +30,7 @@ struct pxa3xx_nand_cmdset {
};
struct pxa3xx_nand_flash {
+ char *name;
uint32_t chip_id;
unsigned int page_per_block; /* Pages per block (PG_PER_BLK) */
unsigned int page_size; /* Page size in bytes (PAGE_SZ) */
@@ -37,7 +38,6 @@ struct pxa3xx_nand_flash {
unsigned int dfc_width; /* Width of flash controller(DWIDTH_C) */
unsigned int num_blocks; /* Number of physical blocks in Flash */
- struct pxa3xx_nand_cmdset *cmdset; /* NAND command set */
struct pxa3xx_nand_timing *timing; /* NAND Flash timing */
};
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index bb50cf2..ab7f4c3 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -211,15 +211,15 @@ static struct pxa3xx_nand_timing timing[] = {
};
static struct pxa3xx_nand_flash builtin_flash_types[] = {
- { 0, 0, 2048, 8, 8, 0, &default_cmdset, &timing[0] },
- { 0x46ec, 32, 512, 16, 16, 4096, &default_cmdset, &timing[1] },
- { 0xdaec, 64, 2048, 8, 8, 2048, &default_cmdset, &timing[1] },
- { 0xd7ec, 128, 4096, 8, 8, 8192, &default_cmdset, &timing[1] },
- { 0xa12c, 64, 2048, 8, 8, 1024, &default_cmdset, &timing[2] },
- { 0xb12c, 64, 2048, 16, 16, 1024, &default_cmdset, &timing[2] },
- { 0xdc2c, 64, 2048, 8, 8, 4096, &default_cmdset, &timing[2] },
- { 0xcc2c, 64, 2048, 16, 16, 4096, &default_cmdset, &timing[2] },
- { 0xba20, 64, 2048, 16, 16, 2048, &default_cmdset, &timing[3] },
+{ "DEFAULT FLASH", 0, 0, 2048, 8, 8, 0, &timing[0] },
+{ "64MiB 16-bit", 0x46ec, 32, 512, 16, 16, 4096, &timing[1] },
+{ "256MiB 8-bit", 0xdaec, 64, 2048, 8, 8, 2048, &timing[1] },
+{ "4GiB 8-bit", 0xd7ec, 128, 4096, 8, 8, 8192, &timing[1] },
+{ "128MiB 8-bit", 0xa12c, 64, 2048, 8, 8, 1024, &timing[2] },
+{ "128MiB 16-bit", 0xb12c, 64, 2048, 16, 16, 1024, &timing[2] },
+{ "512MiB 8-bit", 0xdc2c, 64, 2048, 8, 8, 4096, &timing[2] },
+{ "512MiB 16-bit", 0xcc2c, 64, 2048, 16, 16, 4096, &timing[2] },
+{ "256MiB 16-bit", 0xba20, 64, 2048, 16, 16, 2048, &timing[3] },
};
/* Define a default flash type setting serve as flash detecting only */
@@ -779,9 +779,8 @@ static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
return -EINVAL;
/* calculate flash information */
- info->cmdset = f->cmdset;
+ info->cmdset = &default_cmdset;
info->page_size = f->page_size;
- info->oob_buff = info->data_buff + f->page_size;
info->read_id_bytes = (f->page_size == 2048) ? 4 : 2;
/* calculate addressing information */
@@ -811,45 +810,12 @@ static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
{
uint32_t ndcr = nand_readl(info, NDCR);
- struct nand_flash_dev *type = NULL;
- uint32_t id = -1, page_per_block, num_blocks;
- int i;
-
- page_per_block = ndcr & NDCR_PG_PER_BLK ? 64 : 32;
info->page_size = ndcr & NDCR_PAGE_SZ ? 2048 : 512;
/* set info fields needed to read id */
info->read_id_bytes = (info->page_size == 2048) ? 4 : 2;
info->reg_ndcr = ndcr;
info->cmdset = &default_cmdset;
- pxa3xx_nand_cmdfunc(info->mtd, NAND_CMD_READID, 0, 0);
- id = *((uint16_t *)(info->data_buff));
- if (id == 0)
- return -ENODEV;
-
- /* Lookup the flash id */
- for (i = 0; nand_flash_ids[i].name != NULL; i++) {
- if (id == nand_flash_ids[i].id) {
- type = &nand_flash_ids[i];
- break;
- }
- }
-
- if (!type)
- return -ENODEV;
-
- /* fill the missing flash information */
- i = __ffs(page_per_block * info->page_size);
- num_blocks = type->chipsize << (20 - i);
-
- /* calculate addressing information */
- info->col_addr_cycles = (info->page_size == 2048) ? 2 : 1;
-
- if (num_blocks * page_per_block > 65536)
- info->row_addr_cycles = 3;
- else
- info->row_addr_cycles = 2;
-
info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
@@ -916,13 +882,15 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
struct pxa3xx_nand_info *info = mtd->priv;
struct platform_device *pdev = info->pdev;
struct pxa3xx_nand_platform_data *pdata = pdev->dev.platform_data;
+ struct nand_flash_dev pxa3xx_flash_ids[2] = { {NULL,}, {NULL,} };
const struct pxa3xx_nand_flash *f = NULL;
struct nand_chip *chip = mtd->priv;
uint32_t id = -1;
+ uint64_t chipsize;
int i, ret, num;
if (pdata->keep_config && !pxa3xx_nand_detect_config(info))
- return 0;
+ goto KEEP_CONFIG;
ret = pxa3xx_nand_sensing(info);
if (!ret) {
@@ -953,22 +921,11 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
f = &builtin_flash_types[i - pdata->num_flash + 1];
/* find the chip in default list */
- if (f->chip_id == id) {
- pxa3xx_nand_config_flash(info, f);
- mtd->writesize = f->page_size;
- mtd->writesize_shift = ffs(mtd->writesize) - 1;
- mtd->writesize_mask = (1 << mtd->writesize_shift) - 1;
- mtd->oobsize = mtd->writesize / 32;
- mtd->erasesize = f->page_size * f->page_per_block;
- mtd->erasesize_shift = ffs(mtd->erasesize) - 1;
- mtd->erasesize_mask = (1 << mtd->erasesize_shift) - 1;
-
- mtd->name = mtd_names[0];
+ if (f->chip_id == id)
break;
- }
}
- if (i >= (ARRAY_SIZE(builtin_flash_types) + pdata->num_flash)) {
+ if (i >= (ARRAY_SIZE(builtin_flash_types) + pdata->num_flash - 1)) {
kfree(mtd);
info->mtd = NULL;
printk(KERN_ERR "ERROR!! flash not defined!!!\n");
@@ -976,18 +933,28 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
return -EINVAL;
}
+ pxa3xx_nand_config_flash(info, f);
+ pxa3xx_flash_ids[0].name = f->name;
+ pxa3xx_flash_ids[0].id = (f->chip_id >> 8) & 0xffff;
+ pxa3xx_flash_ids[0].pagesize = f->page_size;
+ chipsize = (uint64_t)f->num_blocks * f->page_per_block * f->page_size;
+ pxa3xx_flash_ids[0].chipsize = chipsize >> 20;
+ pxa3xx_flash_ids[0].erasesize = f->page_size * f->page_per_block;
+ if (f->flash_width == 16)
+ pxa3xx_flash_ids[0].options = NAND_BUSWIDTH_16;
+KEEP_CONFIG:
+ if (nand_scan_ident(mtd, 1, pxa3xx_flash_ids))
+ return -ENODEV;
+ /* calculate addressing information */
+ info->col_addr_cycles = (mtd->writesize >= 2048) ? 2 : 1;
+ info->oob_buff = info->data_buff + mtd->writesize;
+ if ((mtd->size >> chip->page_shift) > 65536)
+ info->row_addr_cycles = 3;
+ else
+ info->row_addr_cycles = 2;
+ mtd->name = mtd_names[0];
chip->ecc.mode = NAND_ECC_HW;
chip->ecc.size = f->page_size;
- chip->chipsize = (uint64_t)f->num_blocks * f->page_per_block
- * f->page_size;
- mtd->size = chip->chipsize;
-
- /* Calculate the address shift from the page size */
- chip->page_shift = ffs(mtd->writesize) - 1;
- chip->pagemask = mtd_div_by_ws(chip->chipsize, mtd) - 1;
- chip->numchips = 1;
- chip->phys_erase_shift = ffs(mtd->erasesize) - 1;
- chip->bbt_erase_shift = chip->phys_erase_shift;
chip->options = (f->flash_width == 16) ? NAND_BUSWIDTH_16 : 0;
chip->options |= NAND_NO_AUTOINCR;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V5 1/6] pxa3xx_nand: make scan procedure more clear
From: Lei Wen @ 2011-03-03 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinb7oZDzvD94RWLZqnLnaX5kY97CxJ+34eVJNmU@mail.gmail.com>
The previous probe function is some kind of big part.
This patch seperate the resource allocation to keep the probe process
more clear than before.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
Change Log:
V5.1:
Add comments for this patch.
drivers/mtd/nand/pxa3xx_nand.c | 99 ++++++++++++++++++++++------------------
1 files changed, 55 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index ea2c288..f440443 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -126,6 +126,7 @@ struct pxa3xx_nand_info {
unsigned int buf_start;
unsigned int buf_count;
+ struct mtd_info *mtd;
/* DMA information */
int drcmr_dat;
int drcmr_cmd;
@@ -1044,34 +1045,27 @@ static void pxa3xx_nand_init_mtd(struct mtd_info *mtd,
this->chip_delay = 25;
}
-static int pxa3xx_nand_probe(struct platform_device *pdev)
+static
+struct pxa3xx_nand_info *alloc_nand_resource(struct platform_device *pdev)
{
- struct pxa3xx_nand_platform_data *pdata;
+ struct pxa3xx_nand_platform_data *pdata = pdev->dev.platform_data;
struct pxa3xx_nand_info *info;
- struct nand_chip *this;
struct mtd_info *mtd;
struct resource *r;
- int ret = 0, irq;
-
- pdata = pdev->dev.platform_data;
-
- if (!pdata) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -ENODEV;
- }
+ int ret, irq;
mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct pxa3xx_nand_info),
GFP_KERNEL);
if (!mtd) {
dev_err(&pdev->dev, "failed to allocate memory\n");
- return -ENOMEM;
+ return NULL;
}
info = (struct pxa3xx_nand_info *)(&mtd[1]);
info->pdev = pdev;
- this = &info->nand_chip;
mtd->priv = info;
+ info->mtd = mtd;
mtd->owner = THIS_MODULE;
info->clk = clk_get(&pdev->dev, NULL);
@@ -1149,31 +1143,9 @@ static int pxa3xx_nand_probe(struct platform_device *pdev)
}
pxa3xx_nand_init_mtd(mtd, info);
+ platform_set_drvdata(pdev, info);
- platform_set_drvdata(pdev, mtd);
-
- if (nand_scan(mtd, 1)) {
- dev_err(&pdev->dev, "failed to scan nand\n");
- ret = -ENXIO;
- goto fail_free_irq;
- }
-
-#ifdef CONFIG_MTD_PARTITIONS
- if (mtd_has_cmdlinepart()) {
- static const char *probes[] = { "cmdlinepart", NULL };
- struct mtd_partition *parts;
- int nr_parts;
-
- nr_parts = parse_mtd_partitions(mtd, probes, &parts, 0);
-
- if (nr_parts)
- return add_mtd_partitions(mtd, parts, nr_parts);
- }
-
- return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
-#else
- return 0;
-#endif
+ return info;
fail_free_irq:
free_irq(irq, info);
@@ -1193,13 +1165,13 @@ fail_put_clk:
clk_put(info->clk);
fail_free_mtd:
kfree(mtd);
- return ret;
+ return NULL;
}
static int pxa3xx_nand_remove(struct platform_device *pdev)
{
- struct mtd_info *mtd = platform_get_drvdata(pdev);
- struct pxa3xx_nand_info *info = mtd->priv;
+ struct pxa3xx_nand_info *info = platform_get_drvdata(pdev);
+ struct mtd_info *mtd = info->mtd;
struct resource *r;
int irq;
@@ -1230,11 +1202,50 @@ static int pxa3xx_nand_remove(struct platform_device *pdev)
return 0;
}
+static int pxa3xx_nand_probe(struct platform_device *pdev)
+{
+ struct pxa3xx_nand_platform_data *pdata;
+ struct pxa3xx_nand_info *info;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data defined\n");
+ return -ENODEV;
+ }
+
+ info = alloc_nand_resource(pdev);
+ if (info == NULL)
+ return -ENOMEM;
+
+ if (nand_scan(info->mtd, 1)) {
+ dev_err(&pdev->dev, "failed to scan nand\n");
+ pxa3xx_nand_remove(pdev);
+ return -ENODEV;
+ }
+
+#ifdef CONFIG_MTD_PARTITIONS
+ if (mtd_has_cmdlinepart()) {
+ const char *probes[] = { "cmdlinepart", NULL };
+ struct mtd_partition *parts;
+ int nr_parts;
+
+ nr_parts = parse_mtd_partitions(info->mtd, probes, &parts, 0);
+
+ if (nr_parts)
+ return add_mtd_partitions(mtd, parts, nr_parts);
+ }
+
+ return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
+#else
+ return 0;
+#endif
+}
+
#ifdef CONFIG_PM
static int pxa3xx_nand_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
- struct pxa3xx_nand_info *info = mtd->priv;
+ struct pxa3xx_nand_info *info = platform_get_drvdata(pdev);
+ struct mtd_info *mtd = info->mtd;
if (info->state != STATE_READY) {
dev_err(&pdev->dev, "driver busy, state = %d\n", info->state);
@@ -1246,8 +1257,8 @@ static int pxa3xx_nand_suspend(struct platform_device *pdev, pm_message_t state)
static int pxa3xx_nand_resume(struct platform_device *pdev)
{
- struct mtd_info *mtd = (struct mtd_info *)platform_get_drvdata(pdev);
- struct pxa3xx_nand_info *info = mtd->priv;
+ struct pxa3xx_nand_info *info = platform_get_drvdata(pdev);
+ struct mtd_info *mtd = info->mtd;
nand_writel(info, NDTR0CS0, info->ndtr0cs0);
nand_writel(info, NDTR1CS0, info->ndtr1cs0);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V5 1/6] pxa3xx_nand: make scan procedure more clear
From: Lei Wen @ 2011-03-03 3:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298901359.2809.25.camel@localhost>
Hi Artem,
On Mon, Feb 28, 2011 at 9:55 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Mon, 2011-02-28 at 10:32 +0800, Lei Wen wrote:
>> Signed-off-by: Lei Wen <leiwen@marvell.com>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
>> Cc: Eric Miao <eric.y.miao@gmail.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
>
> Could you please improve the commit message and make it explain why your
> code makes "scan" more clear, what exactly you do to improve it?
>
The previous probe function is some kind of big part. I seperate the resource
allocation in this patch to keep the probe process more clear than before.
It indeed, the original patch has little comments on it. I would post
a fixed version for that. :)
Thanks,
Lei
^ permalink raw reply
* [PATCHv2] omap:mailbox: resolve hang issue
From: Guzman Lugo, Fernando @ 2011-03-03 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110303014416.GL20560@atomide.com>
On Wed, Mar 2, 2011 at 7:44 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Armando Uribe <x0095078@ti.com> [110302 13:54]:
>> From: Hari Kanigeri <h-kanigeri2@ti.com>
>>
>> omap4 interrupt disable bits is different. On rx kfifo full, the mbox rx
>> interrupts wasn't getting disabled, and this is causing the rcm stress tests
>> to hang.
>>
>> Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
>> Signed-off-by: Armando Uribe <x0095078@ti.com>
>> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
>
> Should we merge this as a fix for the 2.6.38 still?
yeah, if it can still be merged in 2.6.38 because it is a fix it would be great.
Regards,
Fernando.
>
> Tony
>
>> ---
>> ?arch/arm/mach-omap2/mailbox.c | ? 10 ++++++----
>> ?1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
>> index 394413d..011ca50 100644
>> --- a/arch/arm/mach-omap2/mailbox.c
>> +++ b/arch/arm/mach-omap2/mailbox.c
>> @@ -193,10 +193,12 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
>> ? ? ? ? ? ? ? omap_mbox_type_t irq)
>> ?{
>> ? ? ? struct omap_mbox2_priv *p = mbox->priv;
>> - ? ? u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> - ? ? l = mbox_read_reg(p->irqdisable);
>> - ? ? l &= ~bit;
>> - ? ? mbox_write_reg(l, p->irqdisable);
>> + ? ? u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
>> +
>> + ? ? if (!cpu_is_omap44xx())
>> + ? ? ? ? ? ? bit = mbox_read_reg(p->irqdisable) & ~bit;
>> +
>> + ? ? mbox_write_reg(bit, p->irqdisable);
>> ?}
>>
>> ?static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
>> --
>> 1.7.0.4
>>
>
^ permalink raw reply
* [PATCH] ARM: S5PC210: add support for i2c PMICs on Universal_C210 board
From: Kyungmin Park @ 2011-03-03 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215113504.GF4152@n2100.arm.linux.org.uk>
On Tue, Feb 15, 2011 at 8:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 15, 2011 at 11:59:15AM +0100, Marek Szyprowski wrote:
>> ?#include <mach/map.h>
>> +#include <mach/gpio.h>
>
> Need I say anything about this?
Hi Russell,
How about to prevent it as compiler error? It's frequent mistake.
At each mach/gpio.h
#ifndef __LINUX_GPIO_H
#error "You should include <linux/gpio.h> instead of <mach/gpio.h>."
#endif
Thank you,
Kyungmin Park
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
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