Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] gpio: exynos4: Add device tree support
From: Rob Herring @ 2011-10-11 15:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1318320974-9879-1-git-send-email-thomas.abraham@linaro.org>

Thomas,

On 10/11/2011 03:16 AM, Thomas Abraham wrote:
> As gpio chips get registered, a device tree node which represents the
> gpio chip is searched and attached to it. A translate function is also
> provided to convert the gpio specifier into actual platform settings
> for pin function selection, pull up/down and driver strength settings.
> 
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> This patch is based on the latest consolidated Samsung GPIO driver available
> in the following tree:
>   https://github.com/kgene/linux-samsung.git  branch: for-next
> 
>  .../devicetree/bindings/gpio/gpio-samsung.txt      |   30 +++++++++++
>  drivers/gpio/gpio-samsung.c                        |   53 ++++++++++++++++++++
>  2 files changed, 83 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> new file mode 100644
> index 0000000..883faeb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
> @@ -0,0 +1,30 @@
> +Samsung Exynos4 GPIO Controller
> +
> +Required properties:
> +- compatible: Format of compatible property value should be
> +  "samsung,exynos4-gpio-<controller_name>". Example: For GPA0 controller, the
> +  compatible property value should be "samsung,exynos4-gpio-gpa0".

Isn't gpa0 an instance of the h/w, not a version?

> +
> +- reg: Physical base address of the controller and length of memory mapped region.
> +
> +- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
> +  should be the following with values derived from the SoC user manual.
> +     <[phandle of the gpio controller node] <pin number within the gpio controller]
> +      [mux function] [pull up/down] [drive strength]>

It would be better to list out the values here.

> +
> +- gpio-controller: Specifies that the node is a gpio controller.
> +
> +- #address-cells: should be 1.
> +
> +- #size-cells: should be 1. 
> +
> +Example:
> +
> +	gpa0: gpio-controller at 11400000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "samsung,exynos4-gpio-gpa0";
> +		reg = <0x11400000 0x20>;
> +		#gpio-cells = <4>;
> +		gpio-controller;
> +	};
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index b6be77a..037d3bb 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -24,6 +24,10 @@
>  #include <linux/interrupt.h>
>  #include <linux/sysdev.h>
>  #include <linux/ioport.h>
> +#ifdef CONFIG_OF
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#endif

Don't need the ifdef here.

>  
>  #include <asm/irq.h>
>  
> @@ -2353,6 +2357,52 @@ static struct samsung_gpio_chip exynos4_gpios_3[] = {
>  #endif
>  };
>  
> +#if defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF)
> +int exynos4_gpio_xlate(struct gpio_chip *gc, struct device_node *np,

static

> +			 const void *gpio_spec, u32 *flags)
> +{
> +	const __be32 *gpio = gpio_spec;
> +	const u32 n = be32_to_cpup(gpio);
> +	unsigned int pin = gc->base + be32_to_cpu(gpio[0]);
> +
> +	if (gc->of_gpio_n_cells < 4) {
> +		WARN_ON(1);
> +		return -EINVAL;
> +	}
> +
> +	if (n > gc->ngpio)
> +		return -EINVAL;
> +
> +	s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(be32_to_cpu(gpio[1])));
> +	s3c_gpio_setpull(pin, be32_to_cpu(gpio[2]));
> +	s5p_gpio_set_drvstr(pin, be32_to_cpu(gpio[3]));
> +	return n;
> +}
> +
> +static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *gc)
> +{
> +	const char exynos4_gpio_compat_base[] = "samsung,exynos4-gpio-";
> +	char *exynos4_gpio_compat;
> +
> +	exynos4_gpio_compat = kzalloc(strlen(exynos4_gpio_compat_base) +
> +				strlen(gc->label), GFP_KERNEL);
> +	if (!exynos4_gpio_compat)
> +		return;
> +
> +	strcpy(exynos4_gpio_compat, exynos4_gpio_compat_base);
> +	strcat(exynos4_gpio_compat, gc->label);
> +	gc->of_node = of_find_compatible_node(NULL, NULL, exynos4_gpio_compat);
> +	gc->of_gpio_n_cells = 4;
> +	gc->of_xlate = exynos4_gpio_xlate;
> +	kfree(exynos4_gpio_compat);
> +}
> +#else
> +static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *chip)
> +{
> +	return;
> +}
> +#endif /* defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF) */
> +
>  /* TODO: cleanup soc_is_* */
>  static __init int samsung_gpiolib_init(void)
>  {
> @@ -2434,6 +2484,7 @@ static __init int samsung_gpiolib_init(void)
>  				chip->config = &exynos4_gpio_cfg;
>  				chip->group = group++;
>  			}
> +			exynos4_gpiolib_attach_ofnode(&chip->chip);
>  		}
>  		samsung_gpiolib_add_4bit_chips(exynos4_gpios_1, nr_chips, S5P_VA_GPIO1);
>  
> @@ -2446,6 +2497,7 @@ static __init int samsung_gpiolib_init(void)
>  				chip->config = &exynos4_gpio_cfg;
>  				chip->group = group++;
>  			}
> +			exynos4_gpiolib_attach_ofnode(&chip->chip);
>  		}
>  		samsung_gpiolib_add_4bit_chips(exynos4_gpios_2, nr_chips, S5P_VA_GPIO2);
>  
> @@ -2458,6 +2510,7 @@ static __init int samsung_gpiolib_init(void)
>  				chip->config = &exynos4_gpio_cfg;
>  				chip->group = group++;
>  			}
> +			exynos4_gpiolib_attach_ofnode(&chip->chip);
>  		}
>  		samsung_gpiolib_add_4bit_chips(exynos4_gpios_3, nr_chips, S5P_VA_GPIO3);
>  

This code is really ugly, but I guess you inherited it. Converting to a
platform driver and using id table would be much cleaner.

Rob

^ permalink raw reply

* [PATCH 8/9] ARM: SPMP8000: Add support for the Letcool board
From: Arnd Bergmann @ 2011-10-11 15:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGVye5PNhQpdZ9QP-s1EM_Vm22fWC0sW+jV9=CbFivaTMTvkjQ@mail.gmail.com>

On Tuesday 11 October 2011, Zoltan Devai wrote:
> >
> > Hi Zoltan,
> >
> > We basically stopped doing board files for new platforms. Please get
> > rid of this and make sure that the spmp8000-letcool.dts describes
> > everything you need to get this board running. The DT_MACHINE_START
> > part should just be part of the core.c file and not mention the
> > board name, since its intended to apply to all boards with this
> > SOC.
> Hi,
> 
> The board file only contains platform data for drivers which don't handle DT.
> Should I strip those off ?

Well, ideally you should add support for DT probing to those drivers.
With all the new helpers we recently added, that should not require more
code than what you have in the board file that you lose in the process.

> Does that also mean that no fully working ARM board will be allowed into
> mainline until all required drivers do DT ?

Yes, sorry that this causes more work for you.

The overall strategy is more complex, it depends a lot on the state that
the platform is in:

1. For new platforms (prima2, zynq, picoxcell, highbank, spmp8000, ...),
there is a single machine description and all devices are probed through
the device tree. Board files are no longer allowed.

2a For actively maintained platforms (omap, pxa, msm, samsung, at91, imx,
...), the expectation is that the maintainers work on converting the
drivers to device tree probing, but they can still add the occasional
board file for important boards. Once all on board (not necessarily
on-chip) devices can be probed using device tree, new boards files are
not allowed any more, and existing board files should be removed
(either all at once or gradually as dts files get added).

2b After an existing platform has lost its board files, we also want
to remove the on-soc devices from platform files by moving them into
the device tree. The method is the same: you get to add new socs only
if you work on infrastructure to get rid of the code again and move
it into dts files. Once the infrastructure is there, the existing
soc descriptions should gradually go away.

3. For legacy platforms (rpc, sa1100, h720x, ...), I don't expect
anyone to realistically work on device tree conversion. If someone
sends a new board file, that would likely be accepted. Those platforms
are also simple enough that doing everything using board files is
not a signficant overhead.

	Arnd

^ permalink raw reply

* [PATCH] gpio: exynos4: Add device tree support
From: Thomas Abraham @ 2011-10-11 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4E945C90.1050601@gmail.com>

Hi Rob,

On 11 October 2011 20:41, Rob Herring <robherring2@gmail.com> wrote:
> Thomas,
>
> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
>> As gpio chips get registered, a device tree node which represents the
>> gpio chip is searched and attached to it. A translate function is also
>> provided to convert the gpio specifier into actual platform settings
>> for pin function selection, pull up/down and driver strength settings.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> This patch is based on the latest consolidated Samsung GPIO driver available
>> in the following tree:
>> ? https://github.com/kgene/linux-samsung.git ?branch: for-next
>>
>> ?.../devicetree/bindings/gpio/gpio-samsung.txt ? ? ?| ? 30 +++++++++++
>> ?drivers/gpio/gpio-samsung.c ? ? ? ? ? ? ? ? ? ? ? ?| ? 53 ++++++++++++++++++++
>> ?2 files changed, 83 insertions(+), 0 deletions(-)
>> ?create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>> new file mode 100644
>> index 0000000..883faeb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>> @@ -0,0 +1,30 @@
>> +Samsung Exynos4 GPIO Controller
>> +
>> +Required properties:
>> +- compatible: Format of compatible property value should be
>> + ?"samsung,exynos4-gpio-<controller_name>". Example: For GPA0 controller, the
>> + ?compatible property value should be "samsung,exynos4-gpio-gpa0".
>
> Isn't gpa0 an instance of the h/w, not a version?

GPA0 is a instance of the gpio controller. There are several such
instances and there could be differences in those instances such as
the number of GPIO lines managed by that gpio controller instance.

>
>> +
>> +- reg: Physical base address of the controller and length of memory mapped region.
>> +
>> +- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
>> + ?should be the following with values derived from the SoC user manual.
>> + ? ? <[phandle of the gpio controller node] <pin number within the gpio controller]
>> + ? ? ?[mux function] [pull up/down] [drive strength]>
>
> It would be better to list out the values here.

Ok. I will do that in the next version of the patch.

>
>> +
>> +- gpio-controller: Specifies that the node is a gpio controller.
>> +
>> +- #address-cells: should be 1.
>> +
>> +- #size-cells: should be 1.
>> +
>> +Example:
>> +
>> + ? ? gpa0: gpio-controller at 11400000 {
>> + ? ? ? ? ? ? #address-cells = <1>;
>> + ? ? ? ? ? ? #size-cells = <1>;
>> + ? ? ? ? ? ? compatible = "samsung,exynos4-gpio-gpa0";
>> + ? ? ? ? ? ? reg = <0x11400000 0x20>;
>> + ? ? ? ? ? ? #gpio-cells = <4>;
>> + ? ? ? ? ? ? gpio-controller;
>> + ? ? };
>> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
>> index b6be77a..037d3bb 100644
>> --- a/drivers/gpio/gpio-samsung.c
>> +++ b/drivers/gpio/gpio-samsung.c
>> @@ -24,6 +24,10 @@
>> ?#include <linux/interrupt.h>
>> ?#include <linux/sysdev.h>
>> ?#include <linux/ioport.h>
>> +#ifdef CONFIG_OF
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#endif
>
> Don't need the ifdef here.

Ok. I will remove it.

>
>>
>> ?#include <asm/irq.h>
>>
>> @@ -2353,6 +2357,52 @@ static struct samsung_gpio_chip exynos4_gpios_3[] = {
>> ?#endif
>> ?};
>>
>> +#if defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF)
>> +int exynos4_gpio_xlate(struct gpio_chip *gc, struct device_node *np,
>
> static

Ok. I will add it.

>
>> + ? ? ? ? ? ? ? ? ? ? ?const void *gpio_spec, u32 *flags)
>> +{
>> + ? ? const __be32 *gpio = gpio_spec;
>> + ? ? const u32 n = be32_to_cpup(gpio);
>> + ? ? unsigned int pin = gc->base + be32_to_cpu(gpio[0]);
>> +
>> + ? ? if (gc->of_gpio_n_cells < 4) {
>> + ? ? ? ? ? ? WARN_ON(1);
>> + ? ? ? ? ? ? return -EINVAL;
>> + ? ? }
>> +
>> + ? ? if (n > gc->ngpio)
>> + ? ? ? ? ? ? return -EINVAL;
>> +
>> + ? ? s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(be32_to_cpu(gpio[1])));
>> + ? ? s3c_gpio_setpull(pin, be32_to_cpu(gpio[2]));
>> + ? ? s5p_gpio_set_drvstr(pin, be32_to_cpu(gpio[3]));
>> + ? ? return n;
>> +}
>> +
>> +static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *gc)
>> +{
>> + ? ? const char exynos4_gpio_compat_base[] = "samsung,exynos4-gpio-";
>> + ? ? char *exynos4_gpio_compat;
>> +
>> + ? ? exynos4_gpio_compat = kzalloc(strlen(exynos4_gpio_compat_base) +
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? strlen(gc->label), GFP_KERNEL);
>> + ? ? if (!exynos4_gpio_compat)
>> + ? ? ? ? ? ? return;
>> +
>> + ? ? strcpy(exynos4_gpio_compat, exynos4_gpio_compat_base);
>> + ? ? strcat(exynos4_gpio_compat, gc->label);
>> + ? ? gc->of_node = of_find_compatible_node(NULL, NULL, exynos4_gpio_compat);
>> + ? ? gc->of_gpio_n_cells = 4;
>> + ? ? gc->of_xlate = exynos4_gpio_xlate;
>> + ? ? kfree(exynos4_gpio_compat);
>> +}
>> +#else
>> +static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *chip)
>> +{
>> + ? ? return;
>> +}
>> +#endif /* defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF) */
>> +
>> ?/* TODO: cleanup soc_is_* */
>> ?static __init int samsung_gpiolib_init(void)
>> ?{
>> @@ -2434,6 +2484,7 @@ static __init int samsung_gpiolib_init(void)
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->config = &exynos4_gpio_cfg;
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->group = group++;
>> ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? ? ? ? exynos4_gpiolib_attach_ofnode(&chip->chip);
>> ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? samsung_gpiolib_add_4bit_chips(exynos4_gpios_1, nr_chips, S5P_VA_GPIO1);
>>
>> @@ -2446,6 +2497,7 @@ static __init int samsung_gpiolib_init(void)
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->config = &exynos4_gpio_cfg;
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->group = group++;
>> ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? ? ? ? exynos4_gpiolib_attach_ofnode(&chip->chip);
>> ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? samsung_gpiolib_add_4bit_chips(exynos4_gpios_2, nr_chips, S5P_VA_GPIO2);
>>
>> @@ -2458,6 +2510,7 @@ static __init int samsung_gpiolib_init(void)
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->config = &exynos4_gpio_cfg;
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? chip->group = group++;
>> ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? ? ? ? exynos4_gpiolib_attach_ofnode(&chip->chip);
>> ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? samsung_gpiolib_add_4bit_chips(exynos4_gpios_3, nr_chips, S5P_VA_GPIO3);
>>
>
> This code is really ugly, but I guess you inherited it. Converting to a
> platform driver and using id table would be much cleaner.

Ok. I wanted to get the initial dt support for gpio controller on
Exynos started because dt support for other controllers depend on
this. I will revisit this as per your suggestion during the 3.2 cycle.

Thanks for reviewing this patch.

Regards,
Thomas

>
> Rob
>

^ permalink raw reply

* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Arnd Bergmann @ 2011-10-11 15:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111011144005.GI3471@opensource.wolfsonmicro.com>

On Tuesday 11 October 2011, Mark Brown wrote:
> On Tue, Oct 11, 2011 at 04:17:51PM +0200, Arnd Bergmann wrote:
> > On Monday 10 October 2011, Mark Brown wrote:
> 
> > > At the minute it seems to me that arch/arm is as good a place as any
> > > really - currently this code is getting dumped wherever the main device
> > > is.
> 
> > My feeling is that there is a general class of drivers involving
> > the gpio, pinmux, pwm, led, adc and dac: these are basically all
> > things you do with a single pin. Right now we have subsystems for
> > some of them, adding some others and don't have anything for adc
> > basides iio (which only partially fits here).
> 
> We've been round this loop repeatedly before, trying to push all this
> stuff into pins really doesn't map terribly well.  For example, SoCs
> will frequently have PWM controllers which are isolated IP blocks within
> the device and may each have multiple mappings out of the device onto
> pins.  In the case of DACs, ADCs and PWM you definitely don't have a one
> to one mapping with a single pin - they can be differential inputs and
> outputs, or entirely internal to a device.  Trying to push everything
> into a single namespace just makes things confusing.

I didn't mean to suggest that they should be the same subsystem, but
it would be nice to use similar in-kernel interfaces so that a driver
author doesn't have to learn about six different interfaces for
a new soc. If we add an adc subsystem, I would definitely recommend
looking at how the others work.

> > Since there is no externally visible interface for this kind of
> > adc driver, we can always fix it later, which helps a lot. How
> > about putting it into drivers/adc or drivers/misc/adc for now
> > and waiting for others to join it? We can then later make it a
> > proper subsystem along the lines of gpio and pwm and move
> > interfaces for input, hwmon and iio into the subsystem.
> 
> I'm not sure that IIO isn't the kernel subsystem we're looking for here
> - as I keep saying when this comes up it's just representing bare DACs
> and ADCs pretty directly which looks like a generic subsystem to me.

Possible, yes. Until now, IIO is a subsystem for user-level access
not for kernel access though, so it's not the right place yet.
If we decide to let IIO handle all ADC input, do you think it would
also be the right place to do PWM output, rather than having a
separate subsystem for that?

	Arnd

^ permalink raw reply

* [PATCH 2/2] [ARM] MX1:apf9328: Add i2c support
From: gwenhael.goavec @ 2011-10-11 15:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111008192730.GB28049@pengutronix.de>

Hi,

On Sat, 8 Oct 2011 21:27:30 +0200
Wolfram Sang <w.sang@pengutronix.de> wrote:

> On Sat, Oct 08, 2011 at 05:19:49PM +0200, Gwenhael Goavec-Merou wrote:
> > 
> > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> 
> Out of curiosity, no devices on the bus?
>
Devices present on this modules's I2C bus don't have mailined kernel drivers or
don't need one (in that case /dev/i2c-xx is used). This module can be plugged
on a baseboard adding some stuff on I2C but this will be part of another patch
adding the baseboard description. 

Gwenhael
>
> Other than that, looks OK to me:
> 
> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> 
> > ---
> >  arch/arm/mach-imx/Kconfig        |    1 +
> >  arch/arm/mach-imx/mach-apf9328.c |   10 ++++++++++
> >  2 files changed, 11 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 4792fd5..0e89395 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -99,6 +99,7 @@ config MACH_SCB9328
> >  config MACH_APF9328
> >  	bool "APF9328"
> >  	select SOC_IMX1
> > +	select IMX_HAVE_PLATFORM_IMX_I2C
> >  	select IMX_HAVE_PLATFORM_IMX_UART
> >  	help
> >  	  Say Yes here if you are using the Armadeus APF9328 development board
> > diff --git a/arch/arm/mach-imx/mach-apf9328.c b/arch/arm/mach-imx/mach-apf9328.c
> > index a404c89..f60e2b4 100644
> > --- a/arch/arm/mach-imx/mach-apf9328.c
> > +++ b/arch/arm/mach-imx/mach-apf9328.c
> > @@ -18,6 +18,7 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/mtd/physmap.h>
> >  #include <linux/dm9000.h>
> > +#include <linux/i2c.h>
> >  
> >  #include <asm/mach-types.h>
> >  #include <asm/mach/arch.h>
> > @@ -41,6 +42,9 @@ static const int apf9328_pins[] __initconst = {
> >  	PB29_PF_UART2_RTS,
> >  	PB30_PF_UART2_TXD,
> >  	PB31_PF_UART2_RXD,
> > +	/* I2C */
> > +	PA15_PF_I2C_SDA,
> > +	PA16_PF_I2C_SCL,
> >  };
> >  
> >  /*
> > @@ -103,6 +107,10 @@ static const struct imxuart_platform_data uart1_pdata __initconst = {
> >  	.flags = IMXUART_HAVE_RTSCTS,
> >  };
> >  
> > +static const struct imxi2c_platform_data apf9328_i2c_data __initconst = {
> > +	.bitrate = 100000,
> > +};
> > +
> >  static struct platform_device *devices[] __initdata = {
> >  	&apf9328_flash_device,
> >  	&dm9000x_device,
> > @@ -119,6 +127,8 @@ static void __init apf9328_init(void)
> >  	imx1_add_imx_uart0(NULL);
> >  	imx1_add_imx_uart1(&uart1_pdata);
> >  
> > +	imx1_add_imx_i2c(&apf9328_i2c_data);
> > +
> >  	platform_add_devices(devices, ARRAY_SIZE(devices));
> >  }
> >  
> > -- 
> > 1.7.3.4
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> -- 
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* TX28 drivers - Please help
From: Robert Schwebel @ 2011-10-11 15:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4E9453A5.2000501@prolan.hu>

Hi Peter,

On Tue, Oct 11, 2011 at 04:33:09PM +0200, Peter Rusko wrote:
> We'd like to use the Ka-Ro TX28 module in a device with our company.
> As I could see, not all the features of it's processor are supported.
> I have already added some of them using the Freescale version just to
> see that things are working, but the code became really messy. So I've
> decided to restart, and this time I'd like to commit the changes to
> the mainline kernel.

This is in general a good idea :-)

> We have already designed a company board supporting the TX28 module.
> The first problem I don't know how to do well is to separate the
> module and the baseboard.

Uwe proposed a baseboard abstraction patch some time ago (should be in
the list archives, drop me a note if you do not find it), because we
have the same issue on several TX28 customer boards as well (and with
other module hardware, like the Phytec modules). However, the general
position seems to be that this path will not lead into mainline, becasue
of oftree (which is, for the long term, of course the better solution).

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply

* [PATCH] gpio: exynos4: Add device tree support
From: Rob Herring @ 2011-10-11 15:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJuYYwRwBxkAo2fMfVV9wtQ40XeROAnc-cGJK+cssjuh9px=qQ@mail.gmail.com>

On 10/11/2011 10:19 AM, Thomas Abraham wrote:
> Hi Rob,
> 
> On 11 October 2011 20:41, Rob Herring <robherring2@gmail.com> wrote:
>> Thomas,
>>
>> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
>>> As gpio chips get registered, a device tree node which represents the
>>> gpio chip is searched and attached to it. A translate function is also
>>> provided to convert the gpio specifier into actual platform settings
>>> for pin function selection, pull up/down and driver strength settings.
>>>
>>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>>> ---
>>> This patch is based on the latest consolidated Samsung GPIO driver available
>>> in the following tree:
>>>   https://github.com/kgene/linux-samsung.git  branch: for-next
>>>
>>>  .../devicetree/bindings/gpio/gpio-samsung.txt      |   30 +++++++++++
>>>  drivers/gpio/gpio-samsung.c                        |   53 ++++++++++++++++++++
>>>  2 files changed, 83 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>> new file mode 100644
>>> index 0000000..883faeb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>> @@ -0,0 +1,30 @@
>>> +Samsung Exynos4 GPIO Controller
>>> +
>>> +Required properties:
>>> +- compatible: Format of compatible property value should be
>>> +  "samsung,exynos4-gpio-<controller_name>". Example: For GPA0 controller, the
>>> +  compatible property value should be "samsung,exynos4-gpio-gpa0".
>>
>> Isn't gpa0 an instance of the h/w, not a version?
> 
> GPA0 is a instance of the gpio controller. There are several such
> instances and there could be differences in those instances such as
> the number of GPIO lines managed by that gpio controller instance.
> 

That doesn't seem like a reason to have different compatible strings.
Does that affect the programming model of the controller? Unused lines
whether at the board level or SOC level shouldn't really matter.

Rob

^ permalink raw reply

* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Jonathan Cameron @ 2011-10-11 15:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201110111724.48069.arnd@arndb.de>

On 10/11/11 16:24, Arnd Bergmann wrote:
> On Tuesday 11 October 2011, Mark Brown wrote:
>> On Tue, Oct 11, 2011 at 04:17:51PM +0200, Arnd Bergmann wrote:
>>> On Monday 10 October 2011, Mark Brown wrote:
>>
>>>> At the minute it seems to me that arch/arm is as good a place as any
>>>> really - currently this code is getting dumped wherever the main device
>>>> is.
>>
>>> My feeling is that there is a general class of drivers involving
>>> the gpio, pinmux, pwm, led, adc and dac: these are basically all
>>> things you do with a single pin. Right now we have subsystems for
>>> some of them, adding some others and don't have anything for adc
>>> basides iio (which only partially fits here).
>>
>> We've been round this loop repeatedly before, trying to push all this
>> stuff into pins really doesn't map terribly well.  For example, SoCs
>> will frequently have PWM controllers which are isolated IP blocks within
>> the device and may each have multiple mappings out of the device onto
>> pins.  In the case of DACs, ADCs and PWM you definitely don't have a one
>> to one mapping with a single pin - they can be differential inputs and
>> outputs, or entirely internal to a device.  Trying to push everything
>> into a single namespace just makes things confusing.
> 
> I didn't mean to suggest that they should be the same subsystem, but
> it would be nice to use similar in-kernel interfaces so that a driver
> author doesn't have to learn about six different interfaces for
> a new soc. If we add an adc subsystem, I would definitely recommend
> looking at how the others work.
Yup, I'm reading the clk api stuff right now.
> 
>>> Since there is no externally visible interface for this kind of
>>> adc driver, we can always fix it later, which helps a lot. How
>>> about putting it into drivers/adc or drivers/misc/adc for now
>>> and waiting for others to join it? We can then later make it a
>>> proper subsystem along the lines of gpio and pwm and move
>>> interfaces for input, hwmon and iio into the subsystem.
>>
>> I'm not sure that IIO isn't the kernel subsystem we're looking for here
>> - as I keep saying when this comes up it's just representing bare DACs
>> and ADCs pretty directly which looks like a generic subsystem to me.
> 
> Possible, yes. Until now, IIO is a subsystem for user-level access
> not for kernel access though, so it's not the right place yet.
Technically proof of concept code for kernel access went out this morning
(sorry, didn't cc you as you hadn't entered this thread yet).   It's
all of 10 lines of code right now.  But yeah, its userspace focussed.

https://lkml.org/lkml/2011/10/11/141

Covers basic hwmon type usage (polled single channel read).  I'm not nearly
as sure how to handle complex channel scans.  There's a lot of infrastructure
involved in those.

> If we decide to let IIO handle all ADC input, do you think it would
> also be the right place to do PWM output, rather than having a
> separate subsystem for that?
That's one I've been avoiding talking about.  The fuzzy region is between
DDS (direct digital synthesis - waveform generator) chips which we have
been taking in IIO so far.   We don't actually handle these that well
at the moment.  Our core channel registration code doesn't handle the
weird routing these can do - single underlying generator does several
synchronized waveforms.

Pwm is small compact and nice.  Perhaps a similar shim to that I proposed
to hwmon alongside that patch earlier.  So simple pwm only device sits
in pwm, but we have a general purpose driver sitting on IIO that can
provide pwm from an appropriate channel of a more complex device.
It would need hooks that aren't there at the moment and more of the
DDS control to become part of the IIO core.

We may ultimately want to hive off more of IIO into a layer sitting
at same level as other users. It's tricky to know where to make
such divisions though.

Jonathan

^ permalink raw reply

* sched: ARM: arch_scale_freq_power
From: Vincent Guittot @ 2011-10-11 16:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1318328848.8395.45.camel@twins>

On 11 October 2011 12:27, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2011-10-11 at 11:40 +0200, Vincent Guittot wrote:
>> On 11 October 2011 11:13, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>> > On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
>> >> I have several goals. The 1st one is that I need to put more load on
>> >> some cpus when I have packages with different cpu frequency.
>> >
>> > That should be rather easy.
>> >
>>
>> I agree, I was mainly wondering If I should use a [1-1024] or a
>> [1024-xxxx] range and it seems that both can be used according : SMT
>> uses <1024 and x86 turbo mode uses >1024
>
> Well, turbo mode would typically only boost a cpu 25% or so, and only
> while idling other cores to keep under its thermal limit. So its not
> sufficient to actually affect the capacity calculation much if at all.
>

OK

>> >> Then, I have some use cases which have several running tasks but a low
>> >> cpu load. In this case, the small tasks are spread on several cpu by
>> >> the load_balance whereas they could be easily handled by one cpu
>> >> without significant performance modification.
>> >
>> > That shouldn't be done using cpu_power, we have sched_smt_power_savings
>> > and sched_mc_power_savings for stuff like that.
>> >
>>
>> sched_mc_power_saving works fine when we have more than 2 cpus but
>> can't apply on a dual core because it needs at least 2 sched_groups
>> and the nr_running of these sched_groups must be higher than 0 but
>> smaller than group_capacity which is 1 on a dual core system.
>
> SD_POWERSAVINGS_BALANCE does /=2 to nr_running, effectively doubling the
> capacity iirc. And I know some IBM dudes were toying with the idea of
> playing tricks with the capacity numbers, but that never went anywhere.
>

yes but it's only a special case for 2 tasks on a dual core and the
SD_WAKE_AFFINE flag and cpu_idle_sibling can overwrite this decision.

>> > Although I would really like to kill all those different
>> > sched_*_power_savings knobs and reduce it to one.
>> >
>> >> If the cpu_power is
>> >> higher than 1024, the cpu is no more seen out of capacity by the
>> >> load_balance as soon as a short process is running and teh main result
>> >> is that the small tasks will stay on the same cpu. This configuration
>> >> is mainly usefull for ARM dual core system when we want to power gate
>> >> one cpu. I use cyclictest to simulate such use case.
>> >
>> > Yeah, but that's wrong.
>>
>> That's the only way I have found to gathers small task without any
>> relationship on one cpu. Do you know any better solution ?
>
> How do you know the task is 'small' ?
>

I want to use cpufreq to be notified that we have a large/small cpu
load. If we have several tasks but the cpu uses the lowest frequency,
it "should" mean that we have small tasks that are running (less than
20ms*95% of added duration) and we could gather them on one cpu (by
increasing the cpu_power on a dual core).

> For that you would need to track a time-weighted effective load average
> of the task and we don't have that.
>

yes, that's why I use cpufreq until better option, like a
time-weighted load average, is available

> [ how bad is all this u64 math on ARM btw? and when will ARM finally
> ?agree all this 32bit nonsense is a waste of time and silicon? ]
>
> But yeah, the whole nr_running vs capacity thing was traditionally to
> deal with spreading single tasks around. And traditional power aware
> scheduling was mostly about packing those on sockets (keeps other
> sockets idle) instead of spreading them around sockets (optimizes
> cache).
>
> Now I wouldn't at all mind you ripping out all that
> sched_*_power_savings crap and replacing it, I doubt it actually works
> anyway. I haven't got many patches on the subject, and I know I don't
> have the equipment to measure power usage.
>
> Also, the few patches I got mostly made the sched_*_power_savings mess
> bigger, which I refuse to do (what sysad wants to have a 27-state space
> to configure his power aware scheduling). This has mostly made people go
> away instead of fixing things up :-(
>
> As to what the replacement would have to look like, dunno, its not
> something I've really thought much about, but maybe the time-weighted
> stuff is the only sane approach, that combined with options on how to
> spread tasks (core, socket, node, etc..).
>
> I really think changing the load-balancer is the right way to go about
> solving your power issue (hot-plugging a cpu really is an insane way to
> idle a core) and I'm open to discussing what would work for you.
>

Great. My 1st goal was not to modify the load-balancer and sched_mc
(or as less as possible) and to study how I could tune the scheduler
parameters to have the best power consumption on ARM platform. Now,
changing the load-balancer is probably a better solution.

> All I really ask is to not cobble something together, the load-balancer
> is a horridly complex thing already and the last thing it needs is more
> special cases that don't interact properly.
>
>
>

^ permalink raw reply

* [RFC PATCH] tty/serial: atmel_serial: add device tree support
From: Nicolas Ferre @ 2011-10-11 16:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111004165520.GB10919@ponder.secretlab.ca>

On 10/04/2011 06:55 PM, Grant Likely :
> On Tue, Oct 04, 2011 at 08:08:27AM -0500, Rob Herring wrote:
>> Nicolas,
>>
>> On 10/04/2011 03:18 AM, Nicolas Ferre wrote:
>>> On 10/04/2011 03:58 AM, Rob Herring :
>>>> On 10/03/2011 04:51 AM, Nicolas Ferre wrote:
>>>>> +Optional properties:
>>>>> +- atmel,use-dma-rx: use of PDC or DMA for receiving data
>>>>> +- atmel,use-dma-tx: use of PDC or DMA for transmitting data
>>>>
>>>> Is this an internal DMA or separate DMA controller? If the latter, these
>>>> should be phandles to a DMA channel/request.
>>>
>>> Well, for now it relies on PDC (looks like an internal DMA). There is no
>>> notion of channel/request so I think it is appropriate to keep it like this.
>>>
>>
>> Okay. Although, this is a bit of Linux creeping into DT. DT should
>> describe the h/w. You should really be describing whether the h/w
>> supports DMA or not rather than whether you want to use DMA or not.
>> Since DMA support is really tied to the SOC rather than board, you could
>> just use the compatible string to distinguish platforms that support DMA
>> or not. So what is determining this setting? Is it purely user choice?
> 
> It is okay for a binding to still requires config properties like this
> to state if the DMA can be used, even if compatible is enough to
> distinquish.  However, you're right to bring it up.  It is a design
> choice that should be made thoughtfully.

Grant, Rob,

Thanks for your inputs.

I would like to keep this binding to allow the user to choose the way he
likes to use integrated DMA.

I plan to resend a patch series about this serial driver once I will be
able to propose a rs485 binding.

Cheers,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH] gpio: exynos4: Add device tree support
From: Thomas Abraham @ 2011-10-11 16:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4E946109.2000305@gmail.com>

On 11 October 2011 21:00, Rob Herring <robherring2@gmail.com> wrote:
> On 10/11/2011 10:19 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 11 October 2011 20:41, Rob Herring <robherring2@gmail.com> wrote:
>>> Thomas,
>>>
>>> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
>>>> As gpio chips get registered, a device tree node which represents the
>>>> gpio chip is searched and attached to it. A translate function is also
>>>> provided to convert the gpio specifier into actual platform settings
>>>> for pin function selection, pull up/down and driver strength settings.
>>>>
>>>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>>>> ---
>>>> This patch is based on the latest consolidated Samsung GPIO driver available
>>>> in the following tree:
>>>> ? https://github.com/kgene/linux-samsung.git ?branch: for-next
>>>>
>>>> ?.../devicetree/bindings/gpio/gpio-samsung.txt ? ? ?| ? 30 +++++++++++
>>>> ?drivers/gpio/gpio-samsung.c ? ? ? ? ? ? ? ? ? ? ? ?| ? 53 ++++++++++++++++++++
>>>> ?2 files changed, 83 insertions(+), 0 deletions(-)
>>>> ?create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>>> new file mode 100644
>>>> index 0000000..883faeb
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
>>>> @@ -0,0 +1,30 @@
>>>> +Samsung Exynos4 GPIO Controller
>>>> +
>>>> +Required properties:
>>>> +- compatible: Format of compatible property value should be
>>>> + ?"samsung,exynos4-gpio-<controller_name>". Example: For GPA0 controller, the
>>>> + ?compatible property value should be "samsung,exynos4-gpio-gpa0".
>>>
>>> Isn't gpa0 an instance of the h/w, not a version?
>>
>> GPA0 is a instance of the gpio controller. There are several such
>> instances and there could be differences in those instances such as
>> the number of GPIO lines managed by that gpio controller instance.
>>
>
> That doesn't seem like a reason to have different compatible strings.
> Does that affect the programming model of the controller? Unused lines
> whether at the board level or SOC level shouldn't really matter.


No, that does not affect the programming of the controller. The reason
for the instance name extension in compatible string is to match the
gpio_chip with a gpio controller node. When matched, the of_node
pointer of the gpio_chip is set to point to that controller node.

This might not be the best possible implementation but the device tree
support code in this patch is dictated by the structure of the
existing gpio driver code. As you suggested previously, I will look at
reworking the gpio driver a little later but for now, there was a need
for working gpio dt solution to make progress on dt support for other
controllers.

Thanks,
Thomas.

>
> Rob
>
>

^ permalink raw reply

* sched: ARM: arch_scale_freq_power
From: Peter Zijlstra @ 2011-10-11 16:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKfTPtDgKcTucAR-YW27boAeUu1Ur6Txw6hLm3B48jw+sgEUOw@mail.gmail.com>

On Tue, 2011-10-11 at 18:03 +0200, Vincent Guittot wrote:
> > How do you know the task is 'small' ?
> >
> 
> I want to use cpufreq to be notified that we have a large/small cpu
> load. If we have several tasks but the cpu uses the lowest frequency,
> it "should" mean that we have small tasks that are running (less than
> 20ms*95% of added duration) and we could gather them on one cpu (by
> increasing the cpu_power on a dual core).
> 
> > For that you would need to track a time-weighted effective load average
> > of the task and we don't have that.
> >
> 
> yes, that's why I use cpufreq until better option, like a
> time-weighted load average, is available 

Egads... so basically you're (ab)using the ondemand cpufreq stats to get
a guestimate of the time-weighted load of the cpu, and then (ab)use the
scheduler cpufreq hook to pump its capacity numbers.

No cookies for you.

^ permalink raw reply

* [PATCH 2/3] mmc: Add OF bindings support for mmc host controller capabilities
From: Stephen Warren @ 2011-10-11 16:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJuYYwSOZsqKObmt4MeaJa+aPmktwLsFocfmpjbJbOYyvmuwLQ@mail.gmail.com>

Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:
> On 5 October 2011 21:25, Stephen Warren <swarren@nvidia.com> wrote:
> > Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:
> >> On 5 October 2011 18:59, Rob Herring <robherring2@gmail.com> wrote:
> >> > On 10/05/2011 05:13 AM, Thomas Abraham wrote:
> >> >> Device nodes representing sd/mmc controllers in a device tree would include
> >> >> mmc host controller capabilities. Add support for parsing of mmc host
> >> >> controller capabilities included in device nodes.
> > ...
> >> >> +- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
> >> >> +- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
> >> >> +- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
> >> >> +- linux,mmc_cap_needs_poll - host needs polling for card detection
> >> >> +- linux,mmc_cap_8_bit_data - host can do 8 bit transfer
> >> >
> >> > "sdhci,1-bit-only" already exists as a binding. Perhaps add
> >> > "sdhci,4-bit-only". No property then means can do 8-bit.
> >>
> >> Ok. But that would remain just as sdhci host controller capability and
> >> will not be applicable to other types of host controllers.
> >
> > Just as an FYI, NVIDIA's SDHCI controller bindings use property
> > "support-8bit" to indicate 8-bit support. A similar property could be
> > used for 4-bit support too.
> 
> In this case, the binding would be applicable only to nVidia's SDHCI
> controller.

Sure, this is the case right now. And I thought I'd copied this property
name from some other driver, but it looks like I'm mistaken.

> And this binding would select MMC_CAP_8_BIT_DATA in the
> sdhci-tegra driver. There are sdhci drivers that can accept host
> capabilities via platform data.
> 
> The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across
> host controllers and some of them are supplied as platform data for
> non-device tree platforms.
> 
> So, bindings for MMC_CAP_XXX macros can be defined which any host
> controller supporting device tree could use. Host controllers could
> use the mmc_of_parse_host_caps() helper function (listed in this
> patch) to parse all the bindings for MMC_CAP_XXX  available in the
> device node.
> 
> I would like to retain this patch in this series but if there is a
> definite no, then I will drop it. Please let me know your opinion.

I was simply pointing out that there are already some properties in this
area. It'd be nice if we could unify everything on a single style; either
expanding the existing "sdhci,1-bit-only" style that Rob mentioned, or
expanding the "support-8bit" style that Tegra currently uses, rather than
adding a third way of indicating this. Still, given the early state of
DT on Tegra, I'd be happy migrating Tegra to whatever single unified
approach is chosen, so don't take my comments as nak'ing your patch or
anything like that.

-- 
nvpublic

^ permalink raw reply

* [PATCH v8 3/3] arm/tegra: device tree support for ventana board
From: Stephen Warren @ 2011-10-11 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1318329909-32601-4-git-send-email-pdeschrijver@nvidia.com>

Peter De Schrijver wrote at Tuesday, October 11, 2011 4:45 AM:
> Change-Id: I5ed18750e6a8aa3242dae4bcd7165cfd819356d2

You probably want to remove that.

...
> diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
...
> +	if (i == ARRAY_SIZE(pinmux_configs))
> +		WARN(1, "Unknown platform! Pinmuxing not initialized\n");

Sorry to keep picking on this, but shouldn't that be simply:

		WARN(i == ARRAY_SIZE(pinmux_configs),
			"Unknown platform! Pinmuxing not initialized\n");

-- 
nvpublic

^ permalink raw reply

* [PATCH v6 00/10] Add device tree support for PL330 dma controller driver
From: Vinod Koul @ 2011-10-11 16:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <057401cc880e$41e30b20$c5a92160$%kim@samsung.com>

On Tue, 2011-10-11 at 21:06 +0900, Kukjin Kim wrote:
> Thomas Abraham wrote:
> 
> Hi,
> 
> Looks ok to me and if required,
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> 
> And I hope since this includes many changes of arch/arm/Samsung stuff, this
> would be sent to upstream via Samsung tree after ack from Vinod for dma
> stuff.
Sure, looks fine to me
Acked-by: Vinod Koul <vinod.koul@intel.com>

-- 
~Vinod

^ permalink raw reply

* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-11 17:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4E93EBC2.1060103@ti.com>

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> On Monday 10 October 2011 11:31 PM, Kevin Hilman wrote:
>> Hi Santosh,
>> 
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> 
>>> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
>>> suspend (S2R), CPU hotplug and CPUidle.
>> 
>> There are a few more compile errors when doing OMAP1-only builds.
>> You'll need a way to eliminate the secure calls for OMAP1.
>> 
>> This series causes a couple build errors when doing OMAP1-only builds
>> (I used omap1_defconfig):
>> 
> OK. Thanks for catching it.
>
>> First:
>> 
>> /work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory
>> 
>> And trying creating a dummy header to see if it would continue to build gives:
>> 
>> /work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve':
>> /work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock'
>> make[2]: *** [arch/arm/plat-omap/common.o] Error 1
>> make[1]: *** [arch/arm/plat-omap] Error 2
>> 
> For OMAP1 build, omap_secure_ram_reserve_memblock() definition is
> needed since common.c is built for OMAP1 as well.
> The trivial change in the end of this email fixes the omap1 build.

Looks good.

> Have folded that change in original patch and updated the OMAP4
> PM branch - for_3_2/omap4-mpuss-pm_2

Thanks.

> Regards
> Santosh
> P.S : Even with this fix, omap1_defconfig build breaks because of USB.
> I removed USB from build to check rest of the build and it was
> fine then.

OK.

Kevin

^ permalink raw reply

* [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-11 17:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111011103820.GF2138@amd.com>

On Tue, Oct 11, 2011 at 12:38 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> You need to make sure that you don;t pass larger regions then requested
> to the low-level driver. Some logic like in the iommu_map function
> should do it.

You're right. But the solution IMHO should be getting rid of that size
-> order -> size conversion which we do back and forth, as it's kinda
pointless.

> Please use PAGE_SIZE instead of 0x1000UL.

This one would go away too if we remove the size -> order -> size
conversions. In fact, iommu_unmap() just becomes so much simpler when
we do that.

I'm attaching two patches: first one that removes the
size->order->size conversions we have, and then the usual pgsize patch
rebased to it.

Please take a look,

Thanks,
Ohad.

^ permalink raw reply

* [PATCH] arm/tegra: Harmony: Configure PMC for low-level interrupts
From: Stephen Warren @ 2011-10-11 17:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1316643040-7998-1-git-send-email-swarren@nvidia.com>

Stephen Warren wrote at Wednesday, September 21, 2011 4:11 PM:
> Without this, the PMC continually detects an interrupt when the PMU_IRQ
> line is high, causing the tps6686x IRQ handler thread to hog an entire
> CPU.
> 
> This change was originally written by Wei Ni <wni@nvidia.com> for Seaboard
> in the ChromeOS kernel.
> 
> Long-term, this should probably be moved into some kind of PMU driver,
> or perhaps integrated into the GPIO/IRQ/pinmux system?

Olof, is this change OK for inclusion? Or, should we create some kind
of PMU driver and interrupt controller to solve this?

Thanks.

>  int __init harmony_regulator_init(void)
>  {
> +	void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
> +	u32 pmc_ctrl;
> +
> +	/*
> +	 * Configure the power management controller to trigger PMU
> +	 * interrupts when low
> +	 */
> +	pmc_ctrl = readl(pmc + PMC_CTRL);
> +	writel(pmc_ctrl | PMC_CTRL_INTR_LOW, pmc + PMC_CTRL);
> +
>  	i2c_register_board_info(3, harmony_regulators, 1);
> 
>  	return 0;

-- 
nvpublic

^ permalink raw reply

* [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-11 17:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAHQjnOPcetkp-XX0x4HQsR+iYN1SaCAhuBEE2nVTdhssFpUmJQ@mail.gmail.com>

Hi KyongHo,

On Tue, Oct 11, 2011 at 4:59 PM, KyongHo Cho <pullip.cho@samsung.com> wrote:
> I think the type of size should be size_t.
..
> Thus, it should be
> iommu_unmap(domain, orig_iova, orig_size - size)

Agree with both suggestions, thanks !

P.S - please only keep the parts of my email which you are replying
to, otherwise it's a bit hard to find your comments.

Thanks,
Ohad.

^ permalink raw reply

* [RFC PATCH] tty/serial: RS485 bindings for device tree
From: Nicolas Ferre @ 2011-10-11 17:13 UTC (permalink / raw)
  To: linux-arm-kernel

Generic bindings for RS485 feature included in some UARTs.
Those bindings have to be used withing an UART device tree node.
Documentation updated to link to the bindings definition.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Hi all,

1/ I have used the "linux" vendor definition: tell me if it makes sense...
2/ I have the feeling that the SER_RS485_RTS_ON_SEND flag can easily deduced
   from a zero value on both "before" and "after" data delays.

Tell me what you think about this...

Bye,

 Documentation/devicetree/bindings/serial/rs485.txt |   28 ++++++++++++++++++++
 Documentation/serial/serial-rs485.txt              |    5 +++
 2 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/rs485.txt

diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
new file mode 100644
index 0000000..6514be8
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/rs485.txt
@@ -0,0 +1,28 @@
+* RS485 serial communications
+
+The RTS signal is capable of automatically controlling line direction for
+the built-in half-duplex mode.
+The properties described hereafter shall be given to a half-duplex capable
+UART node.
+
+Optional properties:
+- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
+  feature at boot time. It can be disabled later with proper ioctl.
+- linux,rs485-rts-delay: prop-encoded-array <a b> where:
+  * a is the delay beteween rts signal and beginning of data sent in milliseconds.
+      it corresponds to the delay before sending data.
+  * b is the delay between end of data sent and rts signal in milliseconds
+      it corresponds to the delay after sending data and actual release of the
+      line.
+
+RS485 example for Atmel USART:
+	usart0: serial at fff8c000 {
+		compatible = "atmel,at91sam9260-usart";
+		reg = <0xfff8c000 0x4000>;
+		interrupts = <7>;
+		atmel,use-dma-rx;
+		atmel,use-dma-tx;
+		linux,rs485-enabled-at-boot-time;
+		linux,rs485-rts-delay = <0 200>;	// in milliseconds
+	};
+
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.txt
index a493238..d11e5eb 100644
--- a/Documentation/serial/serial-rs485.txt
+++ b/Documentation/serial/serial-rs485.txt
@@ -28,6 +28,10 @@
    RS485 communications. This data structure is used to set and configure RS485
    parameters in the platform data and in ioctls.
 
+   The device tree can also provide RS485 boot time parameters (see [2]
+   for bindings). The driver is in charge of filling this data structure from
+   the values given by the device tree.
+
    Any driver for devices capable of working both as RS232 and RS485 should
    provide at least the following ioctls:
 
@@ -118,3 +122,4 @@
 5. REFERENCES
 
  [1]	include/linux/serial.h
+ [2]	Documentation/devicetree/bindings/serial/rs485.txt
-- 
1.7.5.4

^ permalink raw reply related

* [RFC PATCH] tty/serial: RS485 bindings for device tree
From: Nicolas Ferre @ 2011-10-11 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1318353208-24422-1-git-send-email-nicolas.ferre@atmel.com>

I can also add this new property (support for it already in linux-next):

On 10/11/2011 07:13 PM, Nicolas Ferre :
> Generic bindings for RS485 feature included in some UARTs.
> Those bindings have to be used withing an UART device tree node.
> Documentation updated to link to the bindings definition.

[..]

> +Optional properties:
> +- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
> +  feature at boot time. It can be disabled later with proper ioctl.

+- linux,rs485-rx-during-tx: empty property that enable the receiving of data
+  even whilst sending data.

> +- linux,rs485-rts-delay: prop-encoded-array <a b> where:

[..]

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
From: Kevin Hilman @ 2011-10-11 17:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087037AF843F8@dbde02.ent.ti.com>

"Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes:

> hi Kevin,
> Apologies for the delayed response, I was on vacation.
>
> On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
>>
>> Abhilash,
>>
>> Kevin Hilman <khilman@ti.com> writes:
>>
>>> Abhilash K V <abhilash.kv@ti.com> writes:
>>>
>>>> From: Abhilash K V <abhilash.kv@ti.com>
>>>>
>>>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>>>> we must not enable it. So omap3_twl_init() is now not called
>>>> when the processor does not support SR.
>>>
>>> This still isn't right.
>>>
>>> The reason to skip the TWL PMIC init is not because SR is not available
>>> (TWL PMICs are quite usable without SR).  The reason to skip TWL PMIC
>>> init is because the PMIC is not present.
> [Abhilash K V] yes, I understand now.
>>>
>>> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
>>> only registered if a TWL driver is registered.
>>>
>>
>> Below is a test patch that is a first pass at implementing what I
>> suggested above.  I tested this (along with your patch 3/3) on a
>> 3430/n900 after removing the omap_pmic_init() call frome the board file.
> [Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already
> pulled it into your branch).

I haven't posted/merged this yet, but I will now that you've tested it.

Thanks.

>>
>> Can you let me know if this solves the problem you're seeing on
>> platforms that don't have TWL PMICs?
> [Abhilash K V] It should, I have validated on  am3517_evm

Thanks, will add a Tested-by from you.

>> After digging into this more, I'm increasingly aware that the way we're
>> managing the init of PMIC stuff is a mess.  Guess I need another round
>> of voltage layer cleanups to fix that up.
> [Abhilash K V] True, and to add to this, the changes required to support only 
> ONE voltage-domain for am35xx would be too many, I believe.

I don't see that part to be an obstacle.

Let's just be sure to use the clock, clockdomain, powerdomain &
voltagedomain data files to describe the hardware.  That is the only
scalable and maintainable way to support these devices.

Any core code changes to fix assumption's we've made that are now wrong
need to be raised and addressed.

Stated differently, we know we have assumptions in the PM core code that
may now be mistaken in light of these new AM3xxx devices.  Rather than
try to trick the core PM code into thinking these devices are "normal"
OMAP3/4 devices, let's fix those assumptions so we can properly support
the new devices.

Kevin

^ permalink raw reply

* Message could not be delivered
From: linux-arm-kernel at lists.infradead.org @ 2011-10-11 17:52 UTC (permalink / raw)
  To: linux-arm-kernel

A non-text attachment was scrubbed...
Name: not available
Type: multipart/mixed
Size: 1 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111011/d3650cc6/attachment.bin>

^ permalink raw reply

* Your email requires verification verify#BnPqIJe51L0EH_wVSi4DF-1318355582)
From: bhook at pyrogon.com @ 2011-10-11 17:53 UTC (permalink / raw)
  To: linux-arm-kernel

The message you sent requires that you verify that you 
are a real live human being and not a spam source.

To complete this verification, simply reply to this message and leave
the subject line intact.

The headers of the message sent from your address are shown below:

^ permalink raw reply

* [PATCH 2/3] mmc: Add OF bindings support for mmc host controller capabilities
From: Thomas Abraham @ 2011-10-11 18:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE19AAE@HQMAIL01.nvidia.com>

On 11 October 2011 21:59, Stephen Warren <swarren@nvidia.com> wrote:
> Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:
>> On 5 October 2011 21:25, Stephen Warren <swarren@nvidia.com> wrote:
>> > Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:
>> >> On 5 October 2011 18:59, Rob Herring <robherring2@gmail.com> wrote:
>> >> > On 10/05/2011 05:13 AM, Thomas Abraham wrote:
>> >> >> Device nodes representing sd/mmc controllers in a device tree would include
>> >> >> mmc host controller capabilities. Add support for parsing of mmc host
>> >> >> controller capabilities included in device nodes.
>> > ...
>> >> >> +- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
>> >> >> +- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
>> >> >> +- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
>> >> >> +- linux,mmc_cap_needs_poll - host needs polling for card detection
>> >> >> +- linux,mmc_cap_8_bit_data - host can do 8 bit transfer
>> >> >
>> >> > "sdhci,1-bit-only" already exists as a binding. Perhaps add
>> >> > "sdhci,4-bit-only". No property then means can do 8-bit.
>> >>
>> >> Ok. But that would remain just as sdhci host controller capability and
>> >> will not be applicable to other types of host controllers.
>> >
>> > Just as an FYI, NVIDIA's SDHCI controller bindings use property
>> > "support-8bit" to indicate 8-bit support. A similar property could be
>> > used for 4-bit support too.
>>
>> In this case, the binding would be applicable only to nVidia's SDHCI
>> controller.
>
> Sure, this is the case right now. And I thought I'd copied this property
> name from some other driver, but it looks like I'm mistaken.
>
>> And this binding would select MMC_CAP_8_BIT_DATA in the
>> sdhci-tegra driver. There are sdhci drivers that can accept host
>> capabilities via platform data.
>>
>> The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across
>> host controllers and some of them are supplied as platform data for
>> non-device tree platforms.
>>
>> So, bindings for MMC_CAP_XXX macros can be defined which any host
>> controller supporting device tree could use. Host controllers could
>> use the mmc_of_parse_host_caps() helper function (listed in this
>> patch) to parse all the bindings for MMC_CAP_XXX ?available in the
>> device node.
>>
>> I would like to retain this patch in this series but if there is a
>> definite no, then I will drop it. Please let me know your opinion.
>
> I was simply pointing out that there are already some properties in this
> area. It'd be nice if we could unify everything on a single style; either
> expanding the existing "sdhci,1-bit-only" style that Rob mentioned, or
> expanding the "support-8bit" style that Tegra currently uses, rather than
> adding a third way of indicating this. Still, given the early state of
> DT on Tegra, I'd be happy migrating Tegra to whatever single unified
> approach is chosen, so don't take my comments as nak'ing your patch or
> anything like that.

Ok.

The sdhci bus width binding is an example that can be extended as you
have suggested. If done this way, the sdhci bus width bindings would
be converted by the driver to either of MMC_CAP_[4/8]_BIT_DATA
capability.

But there are other MMC_CAP_XXX values as well which the host
controller driver needs to report to the upper mmc core layer. Some of
these capabilities are determined by reading caps register of the host
controller and converting them to equivalent MMC_CAP_XXX flags. But
some of them are board dependent such as

MMC_CAP_NEEDS_POLL,
MMC_CAP_DISABLE,
MMC_CAP_NONREMOVABLE,
MMC_CAP_POWER_OFF_CARD and others.

These flags which are tied to the characteristics of the board is
usually supplied using platform data. The driver picks up these from
platform data, adds its own set of CAP's and reports to the upper
layer.

When we do not have platform data (as in the case of dt), there could
be two options to bind these CAP's. Either define custom bindings for
these and then translate them in each host controller driver using
them or provide direct bindings for MMC_CAP_xxx with a common function
to parse them. I tend towards direct bindings for MMC_CAP_XXX because
it can be used by any type of mmc/sd host controller and not just
sdhci controller and provides common binding for all host controllers.

Thanks for your comments.

Regards,
Thomas.

>
> --
> nvpublic
>
>

^ 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