Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/8] OMAP2+: hwmod/clockevent: allow late-init of individual hwmods
From: Cousson, Benoit @ 2011-02-28 11:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1102271928550.505@utopia.booyaka.com>

Salut Paul,

On 2/28/2011 3:31 AM, Paul Walmsley wrote:
> Salut Beno?t,
>
> On Wed, 23 Feb 2011, Cousson, Benoit wrote:
>
>> On 2/23/2011 8:11 AM, Paul Walmsley wrote:
>>> This series adds the ability to late-initialize individual
>>> hwmods.  The goal here is for clockevent (and eventually
>>> clocksource) hwmods to be late-initialized individually, and
>>> right before they are needed, in the timer init code.  Then
>>> omap_hwmod_late_init(), which late-inits the rest of the hwmods,
>>> is intended to run as an initcall -- much later in the boot
>>> process.
>>>
>>> This series includes the OMAP2/3 hwmod data for the GPTIMERs that
>>> Tarun posted earlier.  This data is necessary for this new code
>>> to avoid warnings during boot.
>>>
>>> Boot-tested on N800, OMAP34xx Beagleboard and OMAP4430ES2 Panda.
>>
>> I'm testing it on 4430sdp, and I have the following warning:
>>
>> [    0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
>> [    0.000000] ------------[ cut here ]------------
>> [    0.000000] WARNING: at arch/arm/mach-omap2/timer-gp.c:157 omap2_gp_timer_init+0x80/0x190()
>> [    0.000000] timer-gp: omap_dm_timer_set_source() failed
>> [    0.000000] Modules linked in:
>> [    0.000000] [<c0062a6c>] (unwind_backtrace+0x0/0xec) from [<c009422c>] (warn_slowpath_common+0x4c/0x64)
>> [    0.000000] [<c009422c>] (warn_slowpath_common+0x4c/0x64) from [<c00942c4>] (warn_slowpath_fmt+0x2c/0x3c)
>> [    0.000000] [<c00942c4>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0010e30>] (omap2_gp_timer_init+0x80/0x190)
>> [    0.000000] [<c0010e30>] (omap2_gp_timer_init+0x80/0x190) from [<c000c0dc>] (time_init+0x20/0x30)
>> [    0.000000] [<c000c0dc>] (time_init+0x20/0x30) from [<c0008cbc>] (start_kernel+0x1a4/0x30c)
>> [    0.000000] [<c0008cbc>] (start_kernel+0x1a4/0x30c) from [<80008038>] (0x80008038)
>> [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
>> [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
>
> This is due to commit 3b03b58dab847883e6b9a431558c7d8e43fa94c6 ("OMAP4:
> hwmod data: Prevent timer1 to be reset and idle during init").  Could you
> please try reverting this and see if the warning disappears?

Thanks, this is indeed fixing this warning. I didn't see these two 
patches were exclusive.

Thanks,
Benoit

>
> Tony, I guess the omap-for-linus branch will probably need to get rebuilt
> to drop that patch, once this series is merged...
>
> - Paul

^ permalink raw reply

* [PATCH v2 09/09] ARM: s3c2440: gta02: Add touchscreen support
From: Lars-Peter Clausen @ 2011-02-28 11:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1297043521-21903-9-git-send-email-lars@metafoo.de>

This patch adds registers the s3c touchscreen and adc devices to add touchscreen
support for the gta02.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
 arch/arm/mach-s3c2440/mach-gta02.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c2440/mach-gta02.c b/arch/arm/mach-s3c2440/mach-gta02.c
index 640ca68..12193ad 100644
--- a/arch/arm/mach-s3c2440/mach-gta02.c
+++ b/arch/arm/mach-s3c2440/mach-gta02.c
@@ -89,6 +89,8 @@
 #include <plat/udc.h>
 #include <plat/gpio-cfg.h>
 #include <plat/iic.h>
+#include <plat/ts.h>
+
 
 static struct pcf50633 *gta02_pcf;
 
@@ -480,6 +482,13 @@ static struct s3c2410_hcd_info gta02_usb_info __initdata = {
 	},
 };
 
+/* Touchscreen */
+static struct s3c2410_ts_mach_info gta02_ts_info = {
+	.delay			= 10000,
+	.presc			= 0xff, /* slow as we can go */
+	.oversampling_shift	= 2,
+};
+
 /* Buttons */
 static struct gpio_keys_button gta02_buttons[] = {
 	{
@@ -533,6 +542,8 @@ static struct platform_device *gta02_devices[] __initdata = {
 	&samsung_asoc_dma,
 	&s3c_device_i2c0,
 	&gta02_buttons_device,
+	&s3c_device_adc,
+	&s3c_device_ts,
 };
 
 /* These guys DO need to be children of PMU. */
@@ -595,6 +606,7 @@ static void __init gta02_machine_init(void)
 #endif
 
 	s3c24xx_udc_set_platdata(&gta02_udc_cfg);
+	s3c24xx_ts_set_platdata(&gta02_ts_info);
 	s3c_ohci_set_platdata(&gta02_usb_info);
 	s3c_nand_set_platdata(&gta02_nand_info);
 	s3c_i2c0_set_platdata(NULL);
-- 
1.7.2.3

^ permalink raw reply related

* [PATCH V4 2/4] ARM: Xilinx: Adding timer support to the platform
From: Jamie Iles @ 2011-02-28 11:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a7f0ed14-296f-450d-af78-6771cd7281d1@VA3EHSMHS022.ehs.local>

On Fri, Feb 18, 2011 at 11:14:39AM -0700, John Linn wrote:
> The timer driver supports the Xilinx PS Timer Counter IP.
> 
> Signed-off-by: Kiran Sutariya <kiran.sutariya@einfochips.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---

Looks nice to me.  It may be worth adding sched_clock() support to get 
better scheduler resolution in the future but that could come as a 
separate patch.

Jamie

^ permalink raw reply

* [PATCH V4 1/4] ARM: Xilinx: Adding Xilinx board support
From: Jamie Iles @ 2011-02-28 11:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <b8e72ca5-de48-41ec-89b9-95bb90e18826@VA3EHSMHS013.ehs.local>

Hi John,

A couple of very pedantic nitpicks below, sorry I didn't spot them 
before!

On Fri, Feb 18, 2011 at 11:14:38AM -0700, John Linn wrote:
> The 1st board support is minimal to get a system up and running
> on the Xilinx platform.
> 
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> 
> V4 Changes
> 	Minor cleanup based on input from Jamie Iles.
> 
> V3 Changes
> 
> Updates based on Russell Kings' comments
> 	Changed headers to update the license info and remove
> 	the address
> 
> 	Changed the name of functions to include "xilinx" in 
> 	common.c and common.h
> 
> Changed the Kconfig and Makefile to use MACH_XILINX which
> matches the machine registered.
> 
> V2 Changes
> 
> Updates based on Russell King's comments	
> 	minor cleanups
> 	cleaned up physical/virtual addresses in early i/o table		
> 
>  arch/arm/mach-xilinx/Kconfig       |   14 +++++
>  arch/arm/mach-xilinx/Makefile      |    7 ++
>  arch/arm/mach-xilinx/Makefile.boot |    3 +
>  arch/arm/mach-xilinx/board_ep107.c |   82 ++++++++++++++++++++++++++
>  arch/arm/mach-xilinx/common.c      |  113 ++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-xilinx/common.h      |   30 ++++++++++
>  6 files changed, 249 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-xilinx/Kconfig
>  create mode 100644 arch/arm/mach-xilinx/Makefile
>  create mode 100644 arch/arm/mach-xilinx/Makefile.boot
>  create mode 100644 arch/arm/mach-xilinx/board_ep107.c
>  create mode 100644 arch/arm/mach-xilinx/common.c
>  create mode 100644 arch/arm/mach-xilinx/common.h
> 
> diff --git a/arch/arm/mach-xilinx/Kconfig b/arch/arm/mach-xilinx/Kconfig
> new file mode 100644
> index 0000000..61532af
> --- /dev/null
> +++ b/arch/arm/mach-xilinx/Kconfig
> @@ -0,0 +1,14 @@
> +if ARCH_XILINX
> +
> +choice
> +        prompt "Board Selection"
> +	default MACH_XILINX
> +
> +config MACH_XILINX
> +	bool "Xilinx EP107 Board"
> +	help
> +	  Select if you are using a Xilinx EP107 board.
> +
> +endchoice
> +
> +endif
> diff --git a/arch/arm/mach-xilinx/Makefile b/arch/arm/mach-xilinx/Makefile
> new file mode 100644
> index 0000000..76e9e55
> --- /dev/null
> +++ b/arch/arm/mach-xilinx/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the linux kernel.
> +#
> +
> +# Common support
> +obj-y 				:= common.o
> +obj-$(CONFIG_MACH_XILINX)	+= board_ep107.o
> diff --git a/arch/arm/mach-xilinx/Makefile.boot b/arch/arm/mach-xilinx/Makefile.boot
> new file mode 100644
> index 0000000..67039c3
> --- /dev/null
> +++ b/arch/arm/mach-xilinx/Makefile.boot
> @@ -0,0 +1,3 @@
> +   zreladdr-y	:= 0x00008000
> +params_phys-y	:= 0x00000100
> +initrd_phys-y	:= 0x00800000
> diff --git a/arch/arm/mach-xilinx/board_ep107.c b/arch/arm/mach-xilinx/board_ep107.c
> new file mode 100644
> index 0000000..a1635b5
> --- /dev/null
> +++ b/arch/arm/mach-xilinx/board_ep107.c
> @@ -0,0 +1,82 @@
> +/* arch/arm/mach-xilinx/board_ep107.c
> + *
> + * This file contains code specific to the Xilinx EP107 board.
> + *
> + *  Copyright (C) 2011 Xilinx
> + *
> + * based on /arch/arm/mach-realview/core.c
> + *
> + *  Copyright (C) 1999 - 2003 ARM Limited
> + *  Copyright (C) 2000 Deep Blue Solutions Ltd
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/xilinx_soc.h>
> +#include <mach/irqs.h>
> +#include <linux/clkdev.h>
> +#include "common.h"

Usual convention is to order these as the linux, then the asm, then the 
mach includes.

> +
> +/*
> + * Fixed clocks for now
> + */
> +
> +static struct clk ref50_clk = {
> +	.rate	= 50000000,
> +};
> +
> +/* Create all the platform devices for the board */
> +
> +static struct resource uart0[] = {
> +	{
> +		.start = UART0_PHYS,
> +		.end = UART0_PHYS + 0xFFF,
> +		.flags = IORESOURCE_MEM,
> +	}, {
> +		.start = IRQ_UART0,
> +		.end = IRQ_UART0,
> +		.flags = IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device uart_device0 = {
> +	.name = "xuartpss",
> +	.id = 0,
> +	.dev = {
> +		.platform_data = &ref50_clk.rate,
> +	},
> +	.resource = uart0,
> +	.num_resources = ARRAY_SIZE(uart0),
> +};
> +
> +static struct platform_device *xilinx_pdevices[] __initdata = {
> +	&uart_device0,
> +};
> +
> +/**
> + * board_ep107_init - Board specific initialization for the Xilinx EP107 board.
> + *
> + **/
> +static void __init board_ep107_init(void)
> +{
> +	xilinx_system_init();
> +	platform_add_devices(&xilinx_pdevices[0], ARRAY_SIZE(xilinx_pdevices));
> +}
> +
> +MACHINE_START(XILINX_EP107, "Xilinx EP107")
> +	.boot_params    = PHYS_OFFSET + 0x00000100,

Should this use PLAT_PHYS_OFFSET?

Jamie

^ permalink raw reply

* [PATCH 08/09] ARM: s3c2440: gta02: Request usb pullup pin before using it
From: Lars-Peter Clausen @ 2011-02-28 10:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <003201cbd734$79d87050$6d8950f0$%kim@samsung.com>

On 02/28/2011 11:44 AM, Kukjin Kim wrote:
> Lars-Peter Clausen wrote:
>>
>> On 02/28/2011 07:16 AM, Kukjin Kim wrote:
>>> Lars-Peter Clausen wrote:
>>>>
>>>> Request the gpio pin used to control the usb pullup before using it to
>>> avoid
>>>> a
>>>> runtime warning about an auto-requested gpio.
>>>>
>>>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>>>> ---
>>>>  arch/arm/mach-s3c2440/mach-gta02.c |   17 +++++++++++++++--
>>>>  1 files changed, 15 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-s3c2440/mach-gta02.c
>>> b/arch/arm/mach-s3c2440/mach-
>>>> gta02.c
>>>> index 1396639..94456fa 100644
>>>> --- a/arch/arm/mach-s3c2440/mach-gta02.c
>>>> +++ b/arch/arm/mach-s3c2440/mach-gta02.c
>>>> @@ -451,11 +451,11 @@ static void gta02_udc_command(enum
> s3c2410_udc_cmd_e
>>>> cmd)
>>>>  	switch (cmd) {
>>>>  	case S3C2410_UDC_P_ENABLE:
>>>>  		pr_debug("%s S3C2410_UDC_P_ENABLE\n", __func__);
>>>> -		gpio_direction_output(GTA02_GPIO_USB_PULLUP, 1);
>>>> +		gpio_set_value(GTA02_GPIO_USB_PULLUP, 1);
>>>
>>> How about following instead?
>>> 	gpio_request(GTA02_GPIO_USB_PULLUP, "USB_PULLUP");
>>> 	gpio_direction_output(GTA02_GPIO_USB_PULLUP, 1);
>>> 	gpio_free(GTA02_GPIO_USB_PULLUP);
>>>
>>
>> I don't think that is a good idea. This gpio should really be reserved for
>> the
>> udc driver. If it is freed again, it could be requested from someone else
>> which
>> could lead to undefined behaviour.
>>
> Yes right, but I mean the board designer already knows the usage of
> regarding GPIOs on his board.
> So why do we really need gpio_request for it?...

Well, for one because it's part of the gpio-api. You should not call any other
gpio functions on a pin unless you've successfully requested that pin.
On the other hand this helps debugging and ensures that the same gpio is not
used by two drivers accident. For example it is also possible to request gpios
from userspace using the gpio sysfs. So by keeping the gpio requested it wont
be possible to request it from userspace by accident. And the gpio will also be
listed in the gpio debugfs file, which can be helpful for debugging as well.

- Lars

^ permalink raw reply

* [PATCH 3/8 resend] dw_dmac: call dwc_scan_descriptor from dwc_issue_pending only if active list is empty
From: viresh kumar @ 2011-02-28 10:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228104635.GB2754@pulham.picochip.com>

On 02/28/2011 04:16 PM, Jamie Iles wrote:
> On Mon, Feb 28, 2011 at 04:11:18PM +0530, Viresh Kumar wrote:
>> > dwc_scan_descriptor was called even when there were descriptors in active list.
>> > Checking if active list is empty or not.
>> > 
>> > Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> Hi Viresh,
> 
> I have a similar patch to this that is already in next that should 
> achieve the same thing (dmaengine/dw_dmac: don't scan descriptors if no 
> xfers in progress).

Jamie,

Sorry for missing that!!
This patch can be dropped.

-- 
viresh

^ permalink raw reply

* [PATCH 06/09] ARM: s3c2440: gta02: Remove state_mem constraints for the pcf50633 regulators
From: Kukjin Kim @ 2011-02-28 10:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6B78CD.5090602@metafoo.de>

Lars-Peter Clausen wrote:
> 
> On 02/28/2011 07:26 AM, Kukjin Kim wrote:
> > Lars-Peter Clausen wrote:
> >>
> >> The pcf50633 regulator driver does not use the state_mem constraints,
so
> >> there
> >> is no use in setting them.
> >>
> >> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> >> ---
> >>  arch/arm/mach-s3c2440/mach-gta02.c |   15 ---------------
> >>  1 files changed, 0 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-s3c2440/mach-gta02.c
> > b/arch/arm/mach-s3c2440/mach-
> >> gta02.c
> >> index e57c4d8..01e0930 100644
> >> --- a/arch/arm/mach-s3c2440/mach-gta02.c
> >> +++ b/arch/arm/mach-s3c2440/mach-gta02.c
> >> @@ -283,9 +283,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
> >>  				.always_on = 1,
> >>  				.apply_uV = 1,
> >> -				.state_mem = {
> >> -					.enabled = 1,
> >> -				},
> >>  			},
> >>  		},
> >>  		[PCF50633_REGULATOR_DOWN1] = {
> >> @@ -304,9 +301,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
> >>  				.apply_uV = 1,
> >>  				.always_on = 1,
> >> -				.state_mem = {
> >> -					.enabled = 1,
> >> -				},
> >>  			},
> >>  		},
> >>  		[PCF50633_REGULATOR_HCLDO] = {
> >> @@ -325,9 +319,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
> >>  				.valid_ops_mask = REGULATOR_CHANGE_STATUS,
> >>  				.apply_uV = 1,
> >> -				.state_mem = {
> >> -					.enabled = 0,
> >> -				},
> >>  			},
> >>  		},
> >>  		[PCF50633_REGULATOR_LDO2] = {
> >> @@ -362,9 +353,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
> >>  				.valid_ops_mask = REGULATOR_CHANGE_STATUS,
> >>  				.apply_uV = 1,
> >> -				.state_mem = {
> >> -					.enabled = 1,
> >> -				},
> >>  			},
> >>  		},
> >>  		[PCF50633_REGULATOR_LDO6] = {
> >> @@ -379,9 +367,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >>  				.min_uV = 1800000,
> >>  				.max_uV = 1800000,
> >>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
> >> -				.state_mem = {
> >> -					.enabled = 1,
> >> -				},
> >>  			},
> >>  		},
> >>
> >> --
> >
> > Don't we need regulator_suspend_mem_state_show() on PCF50633?
> >
> >
> No. The pcf50633 driver has no set_suspend_enable or set_suspend_disable
ops.
> So the 'suspend_mem_state' sysfs file does not get registered and that
> function
> is never called.
> 
Ok, will apply.
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

^ permalink raw reply

* [PATCH 09/09] ARM: s3c2440: gta02: Add touchscreen support
From: Kukjin Kim @ 2011-02-28 10:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6B7CA5.9010708@metafoo.de>

Lars-Peter Clausen wrote:
> 
> On 02/28/2011 07:04 AM, Kukjin Kim wrote:
> > Lars-Peter Clausen wrote:
> >>

(snip)

> >>  /* Buttons */
> >>  static struct gpio_keys_button gta02_buttons[] = {
> >>  	{
> >> @@ -533,6 +542,8 @@ static struct platform_device *gta02_devices[]
> > __initdata
> >> = {
> >>  	&samsung_asoc_dma,
> >>  	&s3c_device_i2c0,
> >>  	&gta02_buttons_device,
> >> +	&s3c_device_adc,
> >
> > No need to build plat-samsung/dev-adc.c for this?
> > If you want to add '&s3c_deivce_adc', should add 'select
SAMSUNG_DEV_ADC'
> > into "config MACH_NEO1973_GTA02".
> 
> There appear to be two different definitions for s3c_deivce_adc one is in
> plat-samsung/dev-adc.c the other is in plat-s3c24xx/devs.c. So if I select
> SAMSUNG_DEV_ADC I'll actually get compile errors.
> The definition in plat-s3c24xx/devs.c should probably be dropped, but
thats
> something for a different patch.
> 
Oops, you're right...ok, please keep your current code.
If required, we can do it later :)

(snip)

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

^ permalink raw reply

* [PATCH 0/6] ARM: SAMSUNG: Add support PWM backlight
From: Kukjin Kim @ 2011-02-28 10:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298694546-16816-1-git-send-email-banajit.g@samsung.com>

Banajit Goswami wrote:
> 
> This patch adds support PWM backlight for S5P SoCs.
> 
> 1. Move PWM timer code from plat-s3c24xx to plat-samsung for common
> useability
> 2. Add PWM backlight support for SMDK6410/6440/6450/C100 and SMDKV210
> 
> Note: The modification of GPIO F for S5P64X0 patch should be merged first
as
> there is a dependency for PWM on S5P64X0.
> 
> [PATCH 1/6] ARM: SAMSUNG: Move PWM device definition from plat-s3c24xx to
> plat-samsung
> [PATCH 2/6] ARM: S3C64XX: Add PWM backlight support on SMDK6410
> [PATCH 3/6] ARM: S5P64X0: Add PWM backlight support on SMDK6440
> [PATCH 4/6] ARM: S5P64X0: Add PWM backlight support on SMDK6450
> [PATCH 5/6] ARM: S5PC100: Add PWM backlight support on SMDKC100
> [PATCH 6/6] ARM: S5PV210: Add PWM backlight support on SMDKV210

Ok, looks ok to me except adding unrelated platform devices.
Could you please re-work?

And please make sure that it works fine on each board before re-submitting
:)

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

^ permalink raw reply

* [PATCH 01/09] ARM: s3c2442: gta02: Fix usage gpio bank j pin definitions
From: Kukjin Kim @ 2011-02-28 10:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6B7D19.1050103@metafoo.de>

Lars-Peter Clausen wrote:
> 
> On 02/28/2011 07:41 AM, Kukjin Kim wrote:
> > Lars-Peter Clausen wrote:

(snip)

> >
> > Yeah, old S3C2440_GPJx has removed.
> > Is the S3C2410_GPJ(1) right instead of S3C2440_GPJ1?
> 
> I think so. At least the the compile errors are gone and the drivers using
> these gpios work as expected.
> 
Ok, you mean test it on board...so will apply into my s5p-fixes-for-linus
for 38-rc.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

^ permalink raw reply

* [PATCH 01/09] ARM: s3c2442: gta02: Fix usage gpio bank j pin definitions
From: Lars-Peter Clausen @ 2011-02-28 10:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <000801cbd712$907019c0$b1504d40$%kim@samsung.com>

On 02/28/2011 07:41 AM, Kukjin Kim wrote:
> Lars-Peter Clausen wrote:
>>
>> The gta02 header file still uses the old S3C2410_GPJx defines instead of
> the
>> S3C2410_GPJ(x) macro. Since the S3C2410_GPJx defines have already been
>> removed
>> this causes the following build failure:
>>
>> 	sound/soc/samsung/neo1973_wm8753.c: In function 'lm4853_set_spk':
>> 	sound/soc/samsung/neo1973_wm8753.c:259: error: 'S3C2440_GPJ2'
>> undeclared (first use in this function)
>> 	sound/soc/samsung/neo1973_wm8753.c:259: error: (Each undeclared
>> identifier is reported only once
>> 	sound/soc/samsung/neo1973_wm8753.c:259: error: for each function it
>> appears in.)
>> 	sound/soc/samsung/neo1973_wm8753.c: In function 'lm4853_get_spk':
>> 	sound/soc/samsung/neo1973_wm8753.c:267: error: 'S3C2440_GPJ2'
>> undeclared (first use in this function)
>> 	sound/soc/samsung/neo1973_wm8753.c: In function 'lm4853_event':
>> 	sound/soc/samsung/neo1973_wm8753.c:276: error: 'S3C2440_GPJ1'
>> undeclared (first use in this function)
>> 	sound/soc/samsung/neo1973_wm8753.c: At top level:
>> 	sound/soc/samsung/neo1973_wm8753.c:439: error: 'S3C2440_GPJ2'
>> undeclared here (not in a function)
>> 	sound/soc/samsung/neo1973_wm8753.c:440: error: 'S3C2440_GPJ1'
>> undeclared here (not in a function)
>>
>> This patches fixes the issue by doing a
>> s,S3C2410_GPJ([\d]+),S3C2410_GPJ(\1),g
> 
> Maybe, "s,S3C2440_GPJ([\d]+),S3C2410_GPJ(\1),g" instead ?
> 
>> on the file.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>> ---
>>  arch/arm/mach-s3c2440/include/mach/gta02.h |   26
> +++++++++++++-------------
>>  1 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c2440/include/mach/gta02.h b/arch/arm/mach-
>> s3c2440/include/mach/gta02.h
>> index 953331d..3a56a22 100644
>> --- a/arch/arm/mach-s3c2440/include/mach/gta02.h
>> +++ b/arch/arm/mach-s3c2440/include/mach/gta02.h
>> @@ -44,19 +44,19 @@
>>  #define GTA02v3_GPIO_nUSB_FLT	S3C2410_GPG(10)	/* v3 + v4 only */
>>  #define GTA02v3_GPIO_nGSM_OC	S3C2410_GPG(11)	/* v3 + v4 only */
>>
>> -#define GTA02_GPIO_AMP_SHUT	S3C2440_GPJ1	/* v2 + v3 + v4 only */
>> -#define GTA02v1_GPIO_WLAN_GPIO10	S3C2440_GPJ2
>> -#define GTA02_GPIO_HP_IN	S3C2440_GPJ2	/* v2 + v3 + v4 only */
>> -#define GTA02_GPIO_INT0		S3C2440_GPJ3	/* v2 + v3 + v4 only
> */
>> -#define GTA02_GPIO_nGSM_EN	S3C2440_GPJ4
>> -#define GTA02_GPIO_3D_RESET	S3C2440_GPJ5
>> -#define GTA02_GPIO_nDL_GSM	S3C2440_GPJ6	/* v4 + v5 only */
>> -#define GTA02_GPIO_WLAN_GPIO0	S3C2440_GPJ7
>> -#define GTA02v1_GPIO_BAT_ID	S3C2440_GPJ8
>> -#define GTA02_GPIO_KEEPACT	S3C2440_GPJ8
>> -#define GTA02v1_GPIO_HP_IN	S3C2440_GPJ10
>> -#define GTA02_CHIP_PWD		S3C2440_GPJ11	/* v2 + v3 + v4 only
> */
>> -#define GTA02_GPIO_nWLAN_RESET	S3C2440_GPJ12	/* v2 + v3 + v4 only
> */
>> +#define GTA02_GPIO_AMP_SHUT	S3C2410_GPJ(1)	/* v2 + v3 + v4 only */
>> +#define GTA02v1_GPIO_WLAN_GPIO10	S3C2410_GPJ(2)
>> +#define GTA02_GPIO_HP_IN	S3C2410_GPJ(2)	/* v2 + v3 + v4 only */
>> +#define GTA02_GPIO_INT0		S3C2410_GPJ(3)	/* v2 + v3 + v4 only
> */
>> +#define GTA02_GPIO_nGSM_EN	S3C2410_GPJ(4)
>> +#define GTA02_GPIO_3D_RESET	S3C2410_GPJ(5)
>> +#define GTA02_GPIO_nDL_GSM	S3C2410_GPJ(6)	/* v4 + v5 only */
>> +#define GTA02_GPIO_WLAN_GPIO0	S3C2410_GPJ(7)
>> +#define GTA02v1_GPIO_BAT_ID	S3C2410_GPJ(8)
>> +#define GTA02_GPIO_KEEPACT	S3C2410_GPJ(8)
>> +#define GTA02v1_GPIO_HP_IN	S3C2410_GPJ(10)
>> +#define GTA02_CHIP_PWD		S3C2410_GPJ(11)	/* v2 + v3 + v4
>> only */
>> +#define GTA02_GPIO_nWLAN_RESET	S3C2410_GPJ(12)	/* v2 + v3 + v4
>> only */
>>
>>  #define GTA02_IRQ_GSENSOR_1	IRQ_EINT0
>>  #define GTA02_IRQ_MODEM		IRQ_EINT1
>> --
>> 1.7.2.3
> 
> Yeah, old S3C2440_GPJx has removed.
> Is the S3C2410_GPJ(1) right instead of S3C2440_GPJ1?

I think so. At least the the compile errors are gone and the drivers using
these gpios work as expected.

- Lars

^ permalink raw reply

* [PATCH 3/8 resend] dw_dmac: call dwc_scan_descriptor from dwc_issue_pending only if active list is empty
From: Jamie Iles @ 2011-02-28 10:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <8003205172278ef36cfca1fd50a54cb143fad958.1298889267.git.viresh.kumar@st.com>

On Mon, Feb 28, 2011 at 04:11:18PM +0530, Viresh Kumar wrote:
> dwc_scan_descriptor was called even when there were descriptors in active list.
> Checking if active list is empty or not.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>

Hi Viresh,

I have a similar patch to this that is already in next that should 
achieve the same thing (dmaengine/dw_dmac: don't scan descriptors if no 
xfers in progress).

Jamie

^ permalink raw reply

* [PATCH 09/09] ARM: s3c2440: gta02: Add touchscreen support
From: Lars-Peter Clausen @ 2011-02-28 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <000201cbd70d$4f67f1f0$ee37d5d0$%kim@samsung.com>

On 02/28/2011 07:04 AM, Kukjin Kim wrote:
> Lars-Peter Clausen wrote:
>>
>> This patch registers the s3c touchscreen and adc devices to add
> touchscreen
>> support for the gta02.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>> ---
>>  arch/arm/mach-s3c2440/mach-gta02.c |   12 ++++++++++++
>>  1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c2440/mach-gta02.c
> b/arch/arm/mach-s3c2440/mach-
>> gta02.c
>> index 94456fa..2300ec5 100644
>> --- a/arch/arm/mach-s3c2440/mach-gta02.c
>> +++ b/arch/arm/mach-s3c2440/mach-gta02.c
>> @@ -79,6 +79,8 @@
>>  #include <mach/regs-mem.h>
>>  #include <mach/hardware.h>
>>
>> +#include <plat/ts.h>
>> +
> 
> Please group same/similar inclusion together like following.
> <linux/...> <asm/...> then <mach/...> or <plat/...>
> 
> In other words, please add your <plat/ts.h> inclusion after other <plat/...>

Ok.
> 
>>  #include <mach/gta02.h>
>>
>>  #include <plat/regs-serial.h>
>> @@ -480,6 +482,13 @@ static struct s3c2410_hcd_info gta02_usb_info
> __initdata
>> = {
>>  	},
>>  };
>>
>> +/* Touchscreen */
>> +static struct s3c2410_ts_mach_info gta02_ts_info = {
>> +	.delay = 10000,
>> +	.presc = 0xff, /* slow as we can go */
>> +	.oversampling_shift = 2,
>> +};
> 
> How about to use tab between member and = like following?
> 
> static struct s3c2410_ts_mach_info gta02_ts_info = {
> 	.delay			= 10000,
> 	.presc			= 0xff, /* slow as we can go */
> 	.oversampling_shift	= 2,
> };

Ok.

> 
>> +
>>  /* Buttons */
>>  static struct gpio_keys_button gta02_buttons[] = {
>>  	{
>> @@ -533,6 +542,8 @@ static struct platform_device *gta02_devices[]
> __initdata
>> = {
>>  	&samsung_asoc_dma,
>>  	&s3c_device_i2c0,
>>  	&gta02_buttons_device,
>> +	&s3c_device_adc,
> 
> No need to build plat-samsung/dev-adc.c for this?
> If you want to add '&s3c_deivce_adc', should add 'select SAMSUNG_DEV_ADC'
> into "config MACH_NEO1973_GTA02".

There appear to be two different definitions for s3c_deivce_adc one is in
plat-samsung/dev-adc.c the other is in plat-s3c24xx/devs.c. So if I select
SAMSUNG_DEV_ADC I'll actually get compile errors.
The definition in plat-s3c24xx/devs.c should probably be dropped, but thats
something for a different patch.


> 
>> +	&s3c_device_ts,
> 
> 'select SAMSUNG_DEV_TS'

Same here.

> 
>>  };
>>
>>  /* These guys DO need to be children of PMU. */
>> @@ -597,6 +608,7 @@ static void __init gta02_machine_init(void)
>>  #endif
>>
>>  	s3c24xx_udc_set_platdata(&gta02_udc_cfg);
>> +	s3c24xx_ts_set_platdata(&gta02_ts_info);
> 
> Same as above. 'select SAMSUNG_DEV_TS' should be added for
> plat-samsung/dev-ts.c.

And here.

> 
>>  	s3c_ohci_set_platdata(&gta02_usb_info);
>>  	s3c_nand_set_platdata(&gta02_nand_info);
>>  	s3c_i2c0_set_platdata(NULL);
>> --
>> 1.7.2.3
> 
> 
> Thanks.
> 
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
> 

^ permalink raw reply

* [PATCH 08/09] ARM: s3c2440: gta02: Request usb pullup pin before using it
From: Kukjin Kim @ 2011-02-28 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6B7826.1030500@metafoo.de>

Lars-Peter Clausen wrote:
> 
> On 02/28/2011 07:16 AM, Kukjin Kim wrote:
> > Lars-Peter Clausen wrote:
> >>
> >> Request the gpio pin used to control the usb pullup before using it to
> > avoid
> >> a
> >> runtime warning about an auto-requested gpio.
> >>
> >> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> >> ---
> >>  arch/arm/mach-s3c2440/mach-gta02.c |   17 +++++++++++++++--
> >>  1 files changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-s3c2440/mach-gta02.c
> > b/arch/arm/mach-s3c2440/mach-
> >> gta02.c
> >> index 1396639..94456fa 100644
> >> --- a/arch/arm/mach-s3c2440/mach-gta02.c
> >> +++ b/arch/arm/mach-s3c2440/mach-gta02.c
> >> @@ -451,11 +451,11 @@ static void gta02_udc_command(enum
s3c2410_udc_cmd_e
> >> cmd)
> >>  	switch (cmd) {
> >>  	case S3C2410_UDC_P_ENABLE:
> >>  		pr_debug("%s S3C2410_UDC_P_ENABLE\n", __func__);
> >> -		gpio_direction_output(GTA02_GPIO_USB_PULLUP, 1);
> >> +		gpio_set_value(GTA02_GPIO_USB_PULLUP, 1);
> >
> > How about following instead?
> > 	gpio_request(GTA02_GPIO_USB_PULLUP, "USB_PULLUP");
> > 	gpio_direction_output(GTA02_GPIO_USB_PULLUP, 1);
> > 	gpio_free(GTA02_GPIO_USB_PULLUP);
> >
> 
> I don't think that is a good idea. This gpio should really be reserved for
> the
> udc driver. If it is freed again, it could be requested from someone else
> which
> could lead to undefined behaviour.
> 
Yes right, but I mean the board designer already knows the usage of
regarding GPIOs on his board.
So why do we really need gpio_request for it?...

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

^ permalink raw reply

* [PATCH 8/8 resend] dw_dmac.c: Pass Channel Priority from platform_data
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

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 */
+	unsigned int	chan_priority;
 };
 
 /**
@@ -65,7 +68,6 @@ struct dw_dma_slave {
 #define DWC_CFGH_DST_PER(x)	((x) << 11)
 
 /* Platform-configurable bits in CFG_LO */
-#define DWC_CFGL_PRIO(x)	((x) << 5)	/* priority */
 #define DWC_CFGL_LOCK_CH_XFER	(0 << 12)	/* scope of LOCK_CH */
 #define DWC_CFGL_LOCK_CH_BLOCK	(1 << 12)
 #define DWC_CFGL_LOCK_CH_XACT	(2 << 12)
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 7/8 resend] dw_dmac.c: Pass Channel Allocation Order from platform_data
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

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
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 */
+	unsigned int	chan_allocation_order;
 };
 
 /**
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 6/8 resend] dw_dmac: Mark all tx_descriptors with DMA_CRTL_ACK after xfer finish
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

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;
 
 	dev_vdbg(chan2dev(&dwc->chan), "descriptor %u complete\n", txd->cookie);
 
@@ -204,6 +205,12 @@ dwc_descriptor_complete(struct dw_dma_chan *dwc, struct dw_desc *desc)
 	param = txd->callback_param;
 
 	dwc_sync_desc_for_cpu(dwc, desc);
+
+	/* async_tx_ack */
+	list_for_each_entry(child, &desc->tx_list, desc_node)
+		async_tx_ack(&child->txd);
+	async_tx_ack(&desc->txd);
+
 	list_splice_init(&desc->tx_list, &dwc->free_list);
 	list_move(&desc->desc_node, &dwc->free_list);
 
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 5/8 resend] dw_dmac: adding support for 64 bit access width for memcpy xfers
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
---
 drivers/dma/dw_dmac.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 5cc5abf..c40b89f 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -577,7 +577,9 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
 	 * We can be a lot more clever here, but this should take care
 	 * of the most common optimization.
 	 */
-	if (!((src | dest  | len) & 3))
+	if (!((src | dest  | len) & 7))
+		src_width = dst_width = 3;
+	else if (!((src | dest  | len) & 3))
 		src_width = dst_width = 2;
 	else if (!((src | dest | len) & 1))
 		src_width = dst_width = 1;
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 4/8 resend] dw_dmac: calling dwc_scan_descriptors from dwc_tx_status() after taking lock
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

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;
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 3/8 resend] dw_dmac: call dwc_scan_descriptor from dwc_issue_pending only if active list is empty
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

dwc_scan_descriptor was called even when there were descriptors in active list.
Checking if active list is empty or not.

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
---
 drivers/dma/dw_dmac.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 6dd03b0..3bf4772 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -848,7 +848,7 @@ static void dwc_issue_pending(struct dma_chan *chan)
 	struct dw_dma_chan	*dwc = to_dw_dma_chan(chan);
 
 	spin_lock_bh(&dwc->lock);
-	if (!list_empty(&dwc->queue))
+	if (!list_empty(&dwc->queue) && list_empty(&dwc->active_list))
 		dwc_scan_descriptors(to_dw_dma(chan->device), dwc);
 	spin_unlock_bh(&dwc->lock);
 }
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 2/8 resend] dw_dmac: Move single descriptor from dwc->queue to dwc->active_list in dwc_complete_all
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

dwc_complete_all and other routines were removing all descriptors from dwc->queue
and pushing them to dwc->active_list. Only one was required to be removed. Also
we are calling dwc_dostart, once list is fixed.

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
---
 drivers/dma/dw_dmac.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index a3991ab..6dd03b0 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -84,11 +84,6 @@ static struct dw_desc *dwc_first_active(struct dw_dma_chan *dwc)
 	return list_entry(dwc->active_list.next, struct dw_desc, desc_node);
 }
 
-static struct dw_desc *dwc_first_queued(struct dw_dma_chan *dwc)
-{
-	return list_entry(dwc->queue.next, struct dw_desc, desc_node);
-}
-
 static struct dw_desc *dwc_desc_get(struct dw_dma_chan *dwc)
 {
 	struct dw_desc *desc, *_desc;
@@ -259,10 +254,11 @@ static void dwc_complete_all(struct dw_dma *dw, struct dw_dma_chan *dwc)
 	 * Submit queued descriptors ASAP, i.e. before we go through
 	 * the completed ones.
 	 */
-	if (!list_empty(&dwc->queue))
-		dwc_dostart(dwc, dwc_first_queued(dwc));
 	list_splice_init(&dwc->active_list, &list);
-	list_splice_init(&dwc->queue, &dwc->active_list);
+	if (!list_empty(&dwc->queue)) {
+		list_move(dwc->queue.next, &dwc->active_list);
+		dwc_dostart(dwc, dwc_first_active(dwc));
+	}
 
 	list_for_each_entry_safe(desc, _desc, &list, desc_node)
 		dwc_descriptor_complete(dwc, desc);
@@ -319,8 +315,8 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
 		cpu_relax();
 
 	if (!list_empty(&dwc->queue)) {
-		dwc_dostart(dwc, dwc_first_queued(dwc));
-		list_splice_init(&dwc->queue, &dwc->active_list);
+		list_move(dwc->queue.next, &dwc->active_list);
+		dwc_dostart(dwc, dwc_first_active(dwc));
 	}
 }
 
@@ -346,7 +342,7 @@ static void dwc_handle_error(struct dw_dma *dw, struct dw_dma_chan *dwc)
 	 */
 	bad_desc = dwc_first_active(dwc);
 	list_del_init(&bad_desc->desc_node);
-	list_splice_init(&dwc->queue, dwc->active_list.prev);
+	list_move(dwc->queue.next, dwc->active_list.prev);
 
 	/* Clear the error flag and try to restart the controller */
 	dma_writel(dw, CLEAR.ERROR, dwc->mask);
@@ -541,8 +537,8 @@ static dma_cookie_t dwc_tx_submit(struct dma_async_tx_descriptor *tx)
 	if (list_empty(&dwc->active_list)) {
 		dev_vdbg(chan2dev(tx->chan), "tx_submit: started %u\n",
 				desc->txd.cookie);
-		dwc_dostart(dwc, desc);
 		list_add_tail(&desc->desc_node, &dwc->active_list);
+		dwc_dostart(dwc, dwc_first_active(dwc));
 	} else {
 		dev_vdbg(chan2dev(tx->chan), "tx_submit: queued %u\n",
 				desc->txd.cookie);
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 1/8 resend] dw_dmac: Remove compilation dependency from AVR32
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1298889267.git.viresh.kumar@st.com>

This will be used in SPEAr, ARM family.

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
 	select DMA_ENGINE
 	default y if CPU_AT32AP7000
 	help
-- 
1.7.2.2

^ permalink raw reply related

* [PATCH 0/8 resend] dw_dmac: Extending support & minor fixes
From: Viresh Kumar @ 2011-02-28 10:41 UTC (permalink / raw)
  To: linux-arm-kernel

Following set of patches extends dw_dmac support and fixes minor bugs.

This patch series has earlier been posted to linux-kernel at vger.kernel.org.
Didn't get any review there, so including linux-arm-kernel at lists.infradead.org.

Viresh Kumar (8):
  dw_dmac: Remove compilation dependency from AVR32
  dw_dmac: Move single descriptor from dwc->queue to dwc->active_list
    in dwc_complete_all
  dw_dmac: call dwc_scan_descriptor from dwc_issue_pending only if
    active list is empty
  dw_dmac: calling dwc_scan_descriptors from dwc_tx_status() after
    taking lock
  dw_dmac: adding support for 64 bit access width for memcpy xfers
  dw_dmac: Mark all tx_descriptors with DMA_CRTL_ACK after xfer finish
  dw_dmac.c: Pass Channel Allocation Order from platform_data
  dw_dmac.c: Pass Channel Priority from platform_data

 drivers/dma/Kconfig        |    1 -
 drivers/dma/dw_dmac.c      |   52 ++++++++++++++++++++++++++++++-------------
 drivers/dma/dw_dmac_regs.h |    3 ++
 include/linux/dw_dmac.h    |    7 +++++-
 4 files changed, 45 insertions(+), 18 deletions(-)

-- 
1.7.2.2

^ permalink raw reply

* [PATCH] davinci: cpufreq: fix section mismatch warning
From: Nori, Sekhar @ 2011-02-28 10:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298345033.3903.7.camel@mola>

Hi Axel,

On Tue, Feb 22, 2011 at 08:53:53, Axel Lin wrote:
> Fix below section mismatch warning:
> WARNING: vmlinux.o(.data+0x673c): Section mismatch in reference from the variable davinci_driver to the function .init.text:davinci_cpu_init()
> The variable davinci_driver references
> the function __init davinci_cpu_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
> 
> Signed-off-by: Axel Lin <axel.lin@gmail.com>

Will queue for Kevin to send upstream.

Thanks,
Sekhar

^ permalink raw reply

* [PATCH 06/09] ARM: s3c2440: gta02: Remove state_mem constraints for the pcf50633 regulators
From: Lars-Peter Clausen @ 2011-02-28 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <000401cbd710$6035fab0$20a1f010$%kim@samsung.com>

On 02/28/2011 07:26 AM, Kukjin Kim wrote:
> Lars-Peter Clausen wrote:
>>
>> The pcf50633 regulator driver does not use the state_mem constraints, so
>> there
>> is no use in setting them.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>> ---
>>  arch/arm/mach-s3c2440/mach-gta02.c |   15 ---------------
>>  1 files changed, 0 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c2440/mach-gta02.c
> b/arch/arm/mach-s3c2440/mach-
>> gta02.c
>> index e57c4d8..01e0930 100644
>> --- a/arch/arm/mach-s3c2440/mach-gta02.c
>> +++ b/arch/arm/mach-s3c2440/mach-gta02.c
>> @@ -283,9 +283,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
>>  				.always_on = 1,
>>  				.apply_uV = 1,
>> -				.state_mem = {
>> -					.enabled = 1,
>> -				},
>>  			},
>>  		},
>>  		[PCF50633_REGULATOR_DOWN1] = {
>> @@ -304,9 +301,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
>>  				.apply_uV = 1,
>>  				.always_on = 1,
>> -				.state_mem = {
>> -					.enabled = 1,
>> -				},
>>  			},
>>  		},
>>  		[PCF50633_REGULATOR_HCLDO] = {
>> @@ -325,9 +319,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
>>  				.valid_ops_mask = REGULATOR_CHANGE_STATUS,
>>  				.apply_uV = 1,
>> -				.state_mem = {
>> -					.enabled = 0,
>> -				},
>>  			},
>>  		},
>>  		[PCF50633_REGULATOR_LDO2] = {
>> @@ -362,9 +353,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
>>  				.valid_ops_mask = REGULATOR_CHANGE_STATUS,
>>  				.apply_uV = 1,
>> -				.state_mem = {
>> -					.enabled = 1,
>> -				},
>>  			},
>>  		},
>>  		[PCF50633_REGULATOR_LDO6] = {
>> @@ -379,9 +367,6 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>>  				.min_uV = 1800000,
>>  				.max_uV = 1800000,
>>  				.valid_modes_mask = REGULATOR_MODE_NORMAL,
>> -				.state_mem = {
>> -					.enabled = 1,
>> -				},
>>  			},
>>  		},
>>
>> --
> 
> Don't we need regulator_suspend_mem_state_show() on PCF50633?
> 
> 
No. The pcf50633 driver has no set_suspend_enable or set_suspend_disable ops.
So the 'suspend_mem_state' sysfs file does not get registered and that function
is never called.

- Lars

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox