Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Tushar Behera]

On 08/16/2012 10:05 PM, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
> 
> Cc: Ben Dooks 
> Cc: Kukjin Kim 
> Cc: Chris Ball 
> Signed-off-by: Thomas Abraham 
> ---
> Changes since v3:
> 
> The patch series that adds device tree support for Samsung sdhci controller
> had six patches in total, of which, the first five patches have been accepted.
> The sixth patch in the series was dropped since it was using custom Samsung
> properties for descrbing the bus-width and card-detect gpio, but had otherwise
> addressed all the comments.
> 
> This patch reworks the sixth patch in v3 of the sdhci device tree support
> patch series. The only change in this patch from the v3 version is the use of
> generic mmc bindings for descrbing the bus-width and card-detect gpio.
> 
>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   51 +++
>  drivers/mmc/host/sdhci-s3c.c   |  146 
> +++-
>  2 files changed, 191 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> 
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> new file mode 100644
> index 000..398540b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -0,0 +1,51 @@
> +* Samsung's SDHCI Controller device tree bindings
> +
> +Samsung's SDHCI controller is used as a connectivity interface with external
> +MMC, SD and eMMC storage mediums. This file documents differences between the
> +core mmc properties described by mmc.txt and the properties used by the
> +Samsung implmentation of the SDHCI controller.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> +  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
> +controller.
> +  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
> +controller.
> +
> +Required Board Specific Properties:
> +- gpios: Should specify the gpios used for clock, command and data lines. The
> +  gpio specifier format depends on the gpio controller.
> +
> +Optional Board Specific Properties:
> +- One of the following properties for card detect type.
> +  - samsung,sdhci-cd-internal: Card detect line from the card slot  is
> +connected to the card detect pad of the sdhci controller. A gpio is
> +used for this connection (with possible pin function settings).
> +  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
> +is used a card detect line. This gpio line is not connected to card 
> detect
> +pad of the sdhci controller.
> +  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
> +detect the presence of the card. (DEFAULT, if no card detect property
> +is specified).
> +  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
> +permanently connected to the sdhci controller.
> +
> +Example:
> + sdhci@1253 {
> + compatible = "samsung,exynos4210-sdhci";
> + reg = <0x1253 0x100>;
> + interrupts = <<0 75 0>;

Typo: interrupts = <0 75 0>;

> + bus-width = <4>;
> + samsung,sdhci-cd-internal;
> + cd-gpios = <&gpk2 2 2 3 3>;
> + gpios = <&gpk2 0 2 0 3>,  /* clock line */
> + <&gpk2 1 2 0 3>,  /* command line */
> + <&gpk2 3 2 3 3>,  /* data line 0 */
> + <&gpk2 4 2 3 3>,  /* data line 1 */
> + <&gpk2 5 2 3 3>,  /* data line 2 */
> + <&gpk2 6 2 3 3>;  /* data line 3 */
> + };
> +
> + Note: This example shows both SoC specific and board specific properties
> + in a single device node. The properties can be actually be seperated
> + into SoC specific node and board specific node.
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a50c205..7fcc642 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -34,6 +34,9 @@
>  
>  #define MAX_BUS_CLK  (4)
>  
> +/* Number of gpio's used is max data bus width + command and clock lines */
> +#define NUM_GPIOS(x) (x + 2)
> +
>  /**
>   * struct sdhci_s3c - S3C SDHCI instance
>   * @host: The SDHCI host created
> @@ -41,6 +44,7 @@
>   * @ioarea: The resource created when we claimed the IO area.
>   * @pdata: The platform data for this controller.
>   * @cur_clk: The index of the current bus clock.
> + * @gpios: List of gpio numbers parsed from device tree.
>   * @clk_io: The clock for the internal bus interface.
>   * @clk_bus: The clocks that are available for the SD/MMC bus clock.
>   */
> @@ -52,6 +56,7 @@ struct sdhci_s3c {
>   unsigned intcur_clk;
>   int ext_cd_irq;
>   int ext_cd_gpio;
> + int *gpios;
>  
>   s

Re: [PATCH 1/2] ARM: dts: Add pinctrl node entries for Samsung Exynos4210 SoC

[Thomas Abraham]

On 17 August 2012 00:26, Matt Sealey  wrote:
> Re: samsung,pin-function samsung,pin-pud samsung,pin-drv - why can't
> these be one property, why take the space to define them individually
> instead of in an array of 3 values under one property name?

Samsung pinctrl driver was written to be usable on all of the Samsung
application processors starting from 24xx series to the latest
Exynos5.

The gpio/pinmux/pinconfig controllers on these SoC have varying
capabilities. Some of the banks in s3c24xx series support mux function
but do not support pull up/down (pud) or driver strength (drv).
s3c64xx soc's have banks that support pin mux and 'pud' but do not
support 'drv'. And there are banks that do not support mux function
but support 'pud' and 'drv'. Further, a given SoC can have multiple
combinations of different bank types.

In addition to this, there are two more properties for mux and pud
values in power down mode in some of the samsung SoC's.

To keep the bindings common across all the possible Samsung SoC's, the
mux, pud and drv properties were split so that the parsing code in the
Samsung pinctrl driver remains generic for all the possible
combinations of pin banks and SoC's.

Thanks,
Thomas.


>
> --
> Matt Sealey 
> Product Development Analyst, Genesi USA, Inc.
>
>
> On Wed, Aug 15, 2012 at 3:10 PM, Thomas Abraham
>  wrote:
>> Add pinctrl driver nodes for the three instances of pin controllers
>> in Samsung Exynos4210 SoC and add the pin group nodes available in the
>> each of those three instances.
>>
>> Cc: Kukjin Kim 
>> Signed-off-by: Thomas Abraham 
>> ---
>>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi |  457 
>> +
>>  arch/arm/boot/dts/exynos4210.dtsi |   37 +++
>>  2 files changed, 494 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
>> b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> new file mode 100644
>> index 000..b12cf27
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> @@ -0,0 +1,457 @@
>> +/*
>> + * Samsung's Exynos4210 SoC pin-mux and pin-config device tree source
>> + *
>> + * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + * Copyright (c) 2011-2012 Linaro Ltd.
>> + * www.linaro.org
>> + *
>> + * Samsung's Exynos4210 SoC pin-mux and pin-config optiosn are listed as 
>> device
>> + * tree nodes are listed in this file.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/ {
>> +   pinctrl@1140 {
>> +   uart0_data: uart0-data {
>> +   samsung,pins = "gpa0-0", "gpa0-1";
>> +   samsung,pin-function = <0x2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart0_fctl: uart0-fctl {
>> +   samsung,pins = "gpa0-2", "gpa0-3";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart1_data: uart1-data {
>> +   samsung,pins = "gpa0-4", "gpa0-5";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart1_fctl: uart1-fctl {
>> +   samsung,pins = "gpa0-6", "gpa0-7";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   i2c2_bus: i2c2-bus {
>> +   samsung,pins = "gpa0-6", "gpa0-7";
>> +   samsung,pin-function = <3>;
>> +   samsung,pin-pud = <3>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart2_data: uart2-data {
>> +   samsung,pins = "gpa1-0", "gpa1-1";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart2_fctl: uart2-fctl {
>> +   samsung,pins = "gpa1-2", "gpa1-3";
>> +   samsung,pin-function = <2>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
>> +   uart_audio_a: uart-audio-a {
>> +   samsung,pins = "gpa1-0", "gpa1-1";
>> +   samsung,pin-function = <4>;
>> +   samsung,pin-pud = <0>;
>> 

Re: [PATCH] ARM: EXYNOS: Add MFC device tree support

[Arun Kumar K]

Hi Thomas,
Thank you for the comments.
Please find my response inline.

--- Original Message ---
Sender : Thomas Abraham 
Date   : Aug 16, 2012 17:12 (GMT+05:30)
Title  : Re: [PATCH] ARM: EXYNOS: Add MFC device tree support

On 16 August 2012 18:01, Arun Kumar K  wrote:
> From: Naveen Krishna Chatradhi 
>
> This patch adds device tree entry for MFC in the Exynos
> machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
> MFC v6.x version. So making the required changes in the clock
> files and adds MFC to the DT device list.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Arun Kumar K 
> ---
>  .../devicetree/bindings/media/s5p-mfc.txt  |   24 
> 
>  arch/arm/boot/dts/exynos4210.dtsi  |   10 
>  arch/arm/boot/dts/exynos5250.dtsi  |   10 
>  arch/arm/mach-exynos/clock-exynos5.c   |2 +-
>  arch/arm/mach-exynos/mach-exynos4-dt.c |   22 ++
>  arch/arm/mach-exynos/mach-exynos5-dt.c |   22 ++
>  6 files changed, 89 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> new file mode 100644
> index 000..b9bd266
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -0,0 +1,24 @@
> +* Samsung Multi Format Codec (MFC)
> +
> +Mult Format Codec (MFC) is the IP present in Samsung SoCs which
> +supports high resolution decoding and encoding functionalities.
>
> In addition to this, specifying that mfc is used for video
> encode/decode would be informative.

Ok. I will make it more descriptive.

> +
> +Required properties:
> +  - compatible : value should be either one among the following
> +   (a) "samsung,s5p-mfc-v5" for MFC v5 present in Exynos4 SoCs
> +   (b) "samsung,s5p-mfc-v6" for MFC v6.x present in Exynos5 SoCs
>
> "s5p" should be dropped from the compatible values. For example, it
> should be "samsung,mfc-v5", which is sufficient to identify the
> version of the mfc controller.

Ok will remove s5p.

> +
> +  - reg : Physical base address of the IP registers and length of memory
> + mapped region.
> +
> +  - interrupts : MFC interupt number to the CPU.
> +
> +  - samsung,mfc-r : Base address of the first memory bank used by MFC
> +   for DMA contiguous memory allocation.
> +
> +  - samsung,mfc-r-size : Size of the first memory bank.
>
> It is not allowed to pass buffer base address and size from device
> tree. Device tree node should describe only the MFC controller
> hardware. Any memory management related information should be handled
> outside of device tree. This helps the bindings to be reusable across
> multiple operating systems.

The mfc-l and mfc-r base address and size is board specific info which has to
be passed to the driver. This is used for DMA contiguous allocation by driver 
and this value
can change on a different board. 
So in that case, i will pass it as platform data to the driver from 
mach-exynos5-dt.c file.
I hope that would be ok.

> +
> +  - samsung,mfc-l : Base address of the second memory bank used by MFC
> +   for DMA contiguous memory allocation.
> +
> +  - samsung,mfc-l-size : Size of the second memory bank.
>
> Same comment as above. And the bindings documentation is usually
> included in the same patch that adds device tree support for the
> driver.

Ok

> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 02891fe..b5ee43d 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -56,6 +56,16 @@
> interrupts = <0 43 0>;
> };
>
> +   mfc {
> +   compatible = "samsung,s5p-mfc";
> +   reg = <0x1340 0x1>;
> +   interrupts = <0 94 0>;
> +   samsung,mfc-r = <0x4300>;
> +   samsung,mfc-r-size = <8388608>;
> +   samsung,mfc-l = <0x5100>;
> +   samsung,mfc-l-size = <8388608>;
> +   };
> +
> rtc@1007 {
> compatible = "samsung,s3c6410-rtc";
> reg = <0x1007 0x100>;
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 004aaa8..3c762a4 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -58,6 +58,16 @@
> interrupts = <0 42 0>;
> };
>
> +   mfc {
> +   compatible = "samsung,s5p-mfc-v6";
> +   reg = <0x1100 0x1>;
> +   interrupts = <0 96 0>;
> +   samsung,mfc-r = <0x4300>;
> +   samsung,mfc-r-size = <8388608>;
> +   samsung,mfc-l = <0x5100>;
> +   samsung,mfc-l-size = <8388608>;
> +   };
> +
>

Re: [PATCH v6 5/6] ARM: exynos: add thermal sensor driver platform data support

[Thomas Abraham]

On 16 August 2012 17:11, Amit Daniel Kachhap  wrote:
> Add necessary default platform data support needed for TMU driver.  The
> supplied dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
> platforms and only compile tested for exynos4412.
>
> Signed-off-by: Amit Daniel Kachhap 
> Acked-by: Guenter Roeck 
> Cc: SangWook Ju 
> Cc: Durgadoss 
> Cc: Len Brown 
> Cc: Jean Delvare 
> Cc: jonghwa lee 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/exynos_thermal.c |  111 
> +-
>  1 files changed, 110 insertions(+), 1 deletions(-)

Reviewed-by: Thomas Abraham 

Few minor comments inline below.

>
> diff --git a/drivers/thermal/exynos_thermal.c 
> b/drivers/thermal/exynos_thermal.c
> index e79cdc9..03a99e4 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -723,14 +723,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>  static struct thermal_sensor_conf exynos_sensor_conf = {
> .name   = "exynos-therm",
> .read_temperature   = (int (*)(void *))exynos_tmu_read,
> +};
> +
> +#if defined(CONFIG_CPU_EXYNOS4210)
> +static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
> +   .threshold = 80,
> +   .trigger_levels[0] = 5,
> +   .trigger_levels[1] = 20,
> +   .trigger_levels[2] = 30,
> +   .trigger_level0_en = 1,
> +   .trigger_level1_en = 1,
> +   .trigger_level2_en = 1,
> +   .trigger_level3_en = 0,
> +   .gain = 15,
> +   .reference_voltage = 7,
> +   .cal_type = TYPE_ONE_POINT_TRIMMING,
> +   .freq_tab[0] = {
> +   .freq_clip_max = 800 * 1000,
> +   .temp_level = 85,
> +   },
> +   .freq_tab[1] = {
> +   .freq_clip_max = 200 * 1000,
> +   .temp_level = 100,
> +   },
> +   .freq_tab_count = 2,
> +   .type = SOC_ARCH_EXYNOS4210,
> +};
> +#define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
> +#else
> +#define EXYNOS4210_TMU_DRV_DATA (NULL)
> +#endif
> +
> +#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
> +static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
> +   .trigger_levels[0] = 85,
> +   .trigger_levels[1] = 103,
> +   .trigger_levels[2] = 110,
> +   .trigger_level0_en = 1,
> +   .trigger_level1_en = 1,
> +   .trigger_level2_en = 1,
> +   .trigger_level3_en = 0,
> +   .gain = 8,
> +   .reference_voltage = 16,
> +   .noise_cancel_mode = 4,
> +   .cal_type = TYPE_ONE_POINT_TRIMMING,
> +   .efuse_value = 55,
> +   .freq_tab[0] = {
> +   .freq_clip_max = 800 * 1000,
> +   .temp_level = 85,
> +   },
> +   .freq_tab[1] = {
> +   .freq_clip_max = 200 * 1000,
> +   .temp_level = 103,
> +   },
> +   .freq_tab_count = 2,
> +   .type = SOC_ARCH_EXYNOS,
> +};
> +#define EXYNOS_TMU_DRV_DATA (&exynos_default_tmu_data)
> +#else
> +#define EXYNOS_TMU_DRV_DATA (NULL)
> +#endif
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_tmu_match[] = {
> +   {
> +   .compatible = "samsung,exynos4210-tmu",
> +   .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> +   },
> +   {

This can be  }, {

> +   .compatible = "samsung,exynos5250-tmu",
> +   .data = (void *)EXYNOS_TMU_DRV_DATA,
> +   },
> +   {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_tmu_match);
> +#else
> +#define  exynos_tmu_match NULL
> +#endif
> +
> +static struct platform_device_id exynos_tmu_driver_ids[] = {
> +   {
> +   .name   = "exynos4210-tmu",
> +   .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
> +   },
> +   {
> +   .name   = "exynos5250-tmu",
> +   .driver_data= (kernel_ulong_t)EXYNOS_TMU_DRV_DATA,
> +   },

Since Exynos5250 platforms are dt based, the above entry could be left out.

> +   { },
> +};
> +MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
> +
> +static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
> +   struct platform_device *pdev)
> +{
> +#ifdef CONFIG_OF
> +   if (pdev->dev.of_node) {
> +   const struct of_device_id *match;
> +   match = of_match_node(exynos_tmu_match, pdev->dev.of_node);
> +   if (!match)
> +   return NULL;
> +   return (struct exynos_tmu_platform_data *) match->data;
> +   }
> +#endif
> +   return (struct exynos_tmu_platform_data *)
> +   platform_get_device_id(pdev)->driver_data;
>  }
> -;
>  static int __devinit exynos_tmu_probe(struct platform_device *pdev)
>  {
> struct exynos_tmu_data *data;
> struct exynos_tmu_platform_data *pdata = pdev->dev.platform_data;
>  

Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

[Amit Kachhap]

On 16 August 2012 20:22, Valentin, Eduardo  wrote:
>
> Amit,
>
> Thanks again for keeping this up.
>
> On Thu, Aug 16, 2012 at 2:41 PM, Amit Daniel Kachhap
>  wrote:
> > This patchset introduces a new generic cooling device based on cpufreq
> > that can be used on non-ACPI platforms.  As a proof of concept, we have
> > drivers for the following platforms using this mechanism now:
> >
> >  * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
> >  * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
> > imx6q_thermal)
>
> FYI, the OMAP code is under drivers/staging/omap-thermal/. The file
> omap-thermal-common.c is the one which is using your generic cooling
> device. But it needs to be updated accordingly to the API change you
> mention.
>
> >
> > There is a small change in cpufreq cooling registration APIs, so a minor
> > change is needed for Freescale platforms.
> >
> > Brief Description:
> >
> > 1) The generic cooling devices code is placed inside driver/thermal/*
> >as placing inside acpi folder will need un-necessary enabling of acpi
> >code.  This code is architecture independent.
> >
> > 2) This patchset adds generic cpu cooling low level implementation
> >through frequency clipping.  In future, other cpu related cooling
> >devices may be added here.  An ACPI version of this already exists
> >(drivers/acpi/processor_thermal.c) .But this will be useful for
> >platforms like ARM using the generic thermal interface along with the
> >generic cpu cooling devices.  The cooling device registration API's
> >return cooling device pointers which can be easily binded with the
> >thermal zone trip points.  The important APIs exposed are,
> >
> >a) struct thermal_cooling_device *cpufreq_cooling_register(
> > struct cpumask *clip_cpus)
> >b) void cpufreq_cooling_unregister(struct thermal_cooling_device
> > *cdev)
> >
> > 3) Samsung exynos platform thermal implementation is done using the
> >generic cpu cooling APIs and the new trip type.  The temperature
> > sensor
> >driver present in the hwmon folder(registered as hwmon driver) is
> > moved
> >to thermal folder and registered as a thermal driver.
> >
> > A simple data/control flow diagrams is shown below,
> >
> > Core Linux thermal <->  Exynos thermal interface <- Temperature
> > Sensor
> >   | |
> >  \|/|
> >   Cpufreq cooling device <---
> >
> > TODO:
> > *Will send the DT enablement patches later after the driver is merged.
> >
> > This patch:
> >
> > Add support for generic cpu thermal cooling low level implementations
> > using frequency scaling up/down based on the registration parameters.
> > Different cpu related cooling devices can be registered by the user and
> > the binding of these cooling devices to the corresponding trip points
> > can
> > be easily done as the registration APIs return the cooling device
> > pointer.
> > The user of these APIs are responsible for passing clipping frequency .
> > The drivers can also register to recieve notification about any cooling
> > action called.
> >
> > [a...@linux-foundation.org: fix comment layout]
> > Signed-off-by: Amit Daniel Kachhap 
> > Cc: Guenter Roeck 
> > Cc: SangWook Ju 
> > Cc: Durgadoss 
> > Cc: Len Brown 
> > Cc: Jean Delvare 
> > Cc: Kyungmin Park 
> > Cc: Kukjin Kim 
> > Signed-off-by: Andrew Morton 
> > Signed-off-by: Amit Daniel Kachhap 
>
>
> Reviewed-by: Eduardo Valentin 

Thanks Eduardo .

>
>
> > ---
> >  Documentation/thermal/cpu-cooling-api.txt |   52 +++
> >  drivers/thermal/Kconfig   |   11 +
> >  drivers/thermal/Makefile  |1 +
> >  drivers/thermal/cpu_cooling.c |  512
> > +
> >  include/linux/cpu_cooling.h   |   79 +
> >  5 files changed, 655 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
> >  create mode 100644 drivers/thermal/cpu_cooling.c
> >  create mode 100644 include/linux/cpu_cooling.h
> >
> > diff --git a/Documentation/thermal/cpu-cooling-api.txt
> > b/Documentation/thermal/cpu-cooling-api.txt
> > new file mode 100644
> > index 000..a1f2a6b
> > --- /dev/null
> > +++ b/Documentation/thermal/cpu-cooling-api.txt
> > @@ -0,0 +1,52 @@
> > +CPU cooling APIs How To
> > +===
> > +
> > +Written by Amit Daniel Kachhap 
> > +
> > +Updated: 12 May 2012
> > +
> > +Copyright (c)  2012 Samsung Electronics Co.,
> > Ltd(http://www.samsung.com)
> > +
> > +0. Introduction
> > +
> > +The generic cpu cooling(freq clipping) provides
> > registration/unregistration APIs
> > +to the caller. The binding of the cooling devices to the trip point is
> > left for
> > +the user. The registration APIs returns the cooling device pointer.
> > +
> > +1. cpu cooling APIs
> > +
> > +1.1 cpufreq registration/unregistration APIs
> > +1.1.1 struct thermal_coo

Re: [PATCH] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions

[Guenter Roeck]

Sigh.

s/remove/resume/ in headline.

Guenter

On Thu, Aug 16, 2012 at 08:14:25PM -0700, Guenter Roeck wrote:
> Suspend and resume functions call spi_master_get() without matching
> spi_master_put(). The extra references are unnecessary and cause subsequent
> module unload attempts to fail. Drop the calls.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/spi/spi-s3c64xx.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 646a765..d7a87df 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1409,7 +1409,7 @@ static int s3c64xx_spi_remove(struct platform_device 
> *pdev)
>  #ifdef CONFIG_PM
>  static int s3c64xx_spi_suspend(struct device *dev)
>  {
> - struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
> + struct spi_master *master = dev_get_drvdata(dev);
>   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
>  
>   spi_master_suspend(master);
> @@ -1428,7 +1428,7 @@ static int s3c64xx_spi_suspend(struct device *dev)
>  
>  static int s3c64xx_spi_resume(struct device *dev)
>  {
> - struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
> + struct spi_master *master = dev_get_drvdata(dev);
>   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
>   struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
>  
> @@ -1452,7 +1452,7 @@ static int s3c64xx_spi_resume(struct device *dev)
>  #ifdef CONFIG_PM_RUNTIME
>  static int s3c64xx_spi_runtime_suspend(struct device *dev)
>  {
> - struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
> + struct spi_master *master = dev_get_drvdata(dev);
>   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
>  
>   clk_disable(sdd->clk);
> @@ -1463,7 +1463,7 @@ static int s3c64xx_spi_runtime_suspend(struct device 
> *dev)
>  
>  static int s3c64xx_spi_runtime_resume(struct device *dev)
>  {
> - struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
> + struct spi_master *master = dev_get_drvdata(dev);
>   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
>  
>   clk_enable(sdd->src_clk);
> -- 
> 1.7.9.7
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions

[Guenter Roeck]

Suspend and resume functions call spi_master_get() without matching
spi_master_put(). The extra references are unnecessary and cause subsequent
module unload attempts to fail. Drop the calls.

Signed-off-by: Guenter Roeck 
---
 drivers/spi/spi-s3c64xx.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 646a765..d7a87df 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1409,7 +1409,7 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 #ifdef CONFIG_PM
 static int s3c64xx_spi_suspend(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
 
spi_master_suspend(master);
@@ -1428,7 +1428,7 @@ static int s3c64xx_spi_suspend(struct device *dev)
 
 static int s3c64xx_spi_resume(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 
@@ -1452,7 +1452,7 @@ static int s3c64xx_spi_resume(struct device *dev)
 #ifdef CONFIG_PM_RUNTIME
 static int s3c64xx_spi_runtime_suspend(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
 
clk_disable(sdd->clk);
@@ -1463,7 +1463,7 @@ static int s3c64xx_spi_runtime_suspend(struct device *dev)
 
 static int s3c64xx_spi_runtime_resume(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct spi_master *master = dev_get_drvdata(dev);
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
 
clk_enable(sdd->src_clk);
-- 
1.7.9.7

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: Add pinctrl node entries for Samsung Exynos4210 SoC

[Matt Sealey]

Re: samsung,pin-function samsung,pin-pud samsung,pin-drv - why can't
these be one property, why take the space to define them individually
instead of in an array of 3 values under one property name?

-- 
Matt Sealey 
Product Development Analyst, Genesi USA, Inc.


On Wed, Aug 15, 2012 at 3:10 PM, Thomas Abraham
 wrote:
> Add pinctrl driver nodes for the three instances of pin controllers
> in Samsung Exynos4210 SoC and add the pin group nodes available in the
> each of those three instances.
>
> Cc: Kukjin Kim 
> Signed-off-by: Thomas Abraham 
> ---
>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi |  457 
> +
>  arch/arm/boot/dts/exynos4210.dtsi |   37 +++
>  2 files changed, 494 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> new file mode 100644
> index 000..b12cf27
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> @@ -0,0 +1,457 @@
> +/*
> + * Samsung's Exynos4210 SoC pin-mux and pin-config device tree source
> + *
> + * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + * Copyright (c) 2011-2012 Linaro Ltd.
> + * www.linaro.org
> + *
> + * Samsung's Exynos4210 SoC pin-mux and pin-config optiosn are listed as 
> device
> + * tree nodes are listed in this file.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +/ {
> +   pinctrl@1140 {
> +   uart0_data: uart0-data {
> +   samsung,pins = "gpa0-0", "gpa0-1";
> +   samsung,pin-function = <0x2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart0_fctl: uart0-fctl {
> +   samsung,pins = "gpa0-2", "gpa0-3";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart1_data: uart1-data {
> +   samsung,pins = "gpa0-4", "gpa0-5";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart1_fctl: uart1-fctl {
> +   samsung,pins = "gpa0-6", "gpa0-7";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   i2c2_bus: i2c2-bus {
> +   samsung,pins = "gpa0-6", "gpa0-7";
> +   samsung,pin-function = <3>;
> +   samsung,pin-pud = <3>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart2_data: uart2-data {
> +   samsung,pins = "gpa1-0", "gpa1-1";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart2_fctl: uart2-fctl {
> +   samsung,pins = "gpa1-2", "gpa1-3";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart_audio_a: uart-audio-a {
> +   samsung,pins = "gpa1-0", "gpa1-1";
> +   samsung,pin-function = <4>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   i2c3_bus: i2c3-bus {
> +   samsung,pins = "gpa1-2", "gpa1-3";
> +   samsung,pin-function = <3>;
> +   samsung,pin-pud = <3>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart3_data: uart3-data {
> +   samsung,pins = "gpa1-4", "gpa1-5";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   uart_audio_b: uart-audio-b {
> +   samsung,pins = "gpa1-4", "gpa1-5";
> +   samsung,pin-function = <4>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +
> +   spi0_bus: spi0-bus {
> +   samsung,pins = "gpb-0", "gpb-2", "gpb-3";
> +   samsung,pin-function = <2>;
> +   samsung,pin-pud = <3>

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

On 16 August 2012 22:22, Chris Ball  wrote:
> Hi Thomas,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> +Optional Board Specific Properties:
>> +- One of the following properties for card detect type.
>> +  - samsung,sdhci-cd-internal: Card detect line from the card slot is
>> +connected to the card detect pad of the sdhci controller. A gpio is
>> +used for this connection (with possible pin function settings).
>> +  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
>> +is used a card detect line. This gpio line is not connected to card 
>> detect
>> +pad of the sdhci controller.
>> +  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
>> +detect the presence of the card. (DEFAULT, if no card detect property
>> +is specified).
>> +  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
>> +permanently connected to the sdhci controller.
>
> sdhci-s3c isn't the only driver that's going to have options for
> different cd configurations -- maybe now is the right time to move
> these options into the core bindings?

Yes, I agree. It will be better to reduce the custom bindings.

>
> At OLPC we've just started using:
>
>  * "broken-cd" to mean "samsung,sdhci-cd-none",

Yes, they are mean the same.

>
>  * the presence of a "cd-gpios" property to imply "samsung,sdhci-cd-gpio".

"samsung,sdhci-cd-gpio" and "sdhci-cd-internal" both use the cd-gpio line.

"samsung,sdhci-cd-gpio" means that the cd-gpio line is not connected
to the card-detect pad of the sdhci controller. Instead, it identifies
cd-gpio as a gpio pin, connected to the card-detect pin of the "card
slot" and it can used as a source of external interrupt. The driver
can register card insert/remove handler for this interrupt and get
notified about the changes in card state.

"sdhci-cd-internal" means that the "cd-gpio" line is used to connect
the card-detect pin of the card slot and the card-detect pad of the
sdhci controller. The controller is then aware of any changes in card
state and the controller generates appropriate interrupts to notify
changes in card-state.

>
>  * "non-removable" to mean "samsung,sdhci-cd-permanent" (this is already
>specified in mmc.txt)

Ok.

>
> Would these work for you?

Yes, the first and the third works, but the second point needs a way
to identify the type of external card-detection mechanism.

>
> We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio,
> and I'm having trouble working out why one is necessary.  Why does the
> driver need to know where the gpio came from, aside from knowing which
> gpio it is and whether it needs to be inverted (with cd-inverted)?

This is as explained above. Maybe other controllers also need
something similar to "samsung,sdhci-cd-gpio" and "sdhci-cd-internal".
And so, we could make a generic binding for these as well.

Thanks,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Chris Ball]

Hi Thomas,

On Thu, Aug 16 2012, Thomas Abraham wrote:
> +Optional Board Specific Properties:
> +- One of the following properties for card detect type.
> +  - samsung,sdhci-cd-internal: Card detect line from the card slot is
> +connected to the card detect pad of the sdhci controller. A gpio is
> +used for this connection (with possible pin function settings).
> +  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
> +is used a card detect line. This gpio line is not connected to card 
> detect
> +pad of the sdhci controller.
> +  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
> +detect the presence of the card. (DEFAULT, if no card detect property
> +is specified).
> +  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
> +permanently connected to the sdhci controller.

sdhci-s3c isn't the only driver that's going to have options for
different cd configurations -- maybe now is the right time to move
these options into the core bindings?

At OLPC we've just started using:

 * "broken-cd" to mean "samsung,sdhci-cd-none",
 
 * the presence of a "cd-gpios" property to imply "samsung,sdhci-cd-gpio".
   
 * "non-removable" to mean "samsung,sdhci-cd-permanent" (this is already
   specified in mmc.txt)

Would these work for you?

We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio,
and I'm having trouble working out why one is necessary.  Why does the
driver need to know where the gpio came from, aside from knowing which
gpio it is and whether it needs to be inverted (with cd-inverted)?

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: use generic mmc properties for Samsung Exynos4210 sdhci nodes

[Thomas Abraham]

The SDHCI controller nodes in platforms which are based on Samsung's Exynos4210
SoC are using the older custom Samsung SDHCI bindings. Remove the old Samsung
specific bindings and use the generic mmc bindings that are defined for mmc
controllers.

Cc: Kukjin Kim 
Cc: Chris Ball 
Signed-off-by: Thomas Abraham 
---
 arch/arm/boot/dts/exynos4210-origen.dts   |   10 --
 arch/arm/boot/dts/exynos4210-smdkv310.dts |5 ++---
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index 0c49caa..5b5f389 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -30,10 +30,9 @@
};
 
sdhci@1253 {
-   samsung,sdhci-bus-width = <4>;
-   linux,mmc_cap_4_bit_data;
+   bus-width = <4>;
samsung,sdhci-cd-internal;
-   gpio-cd = <&gpk2 2 2 3 3>;
+   cd-gpios = <&gpk2 2 2 3 3>;
gpios = <&gpk2 0 2 0 3>,
<&gpk2 1 2 0 3>,
<&gpk2 3 2 3 3>,
@@ -43,10 +42,9 @@
};
 
sdhci@1251 {
-   samsung,sdhci-bus-width = <4>;
-   linux,mmc_cap_4_bit_data;
+   bus-width = <4>;
samsung,sdhci-cd-internal;
-   gpio-cd = <&gpk0 2 2 3 3>;
+   cd-gpios = <&gpk0 2 2 3 3>;
gpios = <&gpk0 0 2 0 3>,
<&gpk0 1 2 0 3>,
<&gpk0 3 2 3 3>,
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 1beccc8..f090095 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -30,10 +30,9 @@
};
 
sdhci@1253 {
-   samsung,sdhci-bus-width = <4>;
-   linux,mmc_cap_4_bit_data;
+   bus-width = <4>;
samsung,sdhci-cd-internal;
-   gpio-cd = <&gpk2 2 2 3 3>;
+   cd-gpios = <&gpk2 2 2 3 3>;
gpios = <&gpk2 0 2 0 3>,
<&gpk2 1 2 0 3>,
<&gpk2 3 2 3 3>,
-- 
1.6.6.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

On 16 August 2012 21:59, Chris Ball  wrote:
> Hi,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks 
>> Cc: Kukjin Kim 
>> Cc: Chris Ball 
>> Signed-off-by: Thomas Abraham 
>> ---
>> Changes since v3:
>>
>> The patch series that adds device tree support for Samsung sdhci controller
>> had six patches in total, of which, the first five patches have been 
>> accepted.
>> The sixth patch in the series was dropped since it was using custom Samsung
>> properties for descrbing the bus-width and card-detect gpio, but had 
>> otherwise
>> addressed all the comments.
>>
>> This patch reworks the sixth patch in v3 of the sdhci device tree support
>> patch series. The only change in this patch from the v3 version is the use of
>> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>>
>>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   51 +++
>>  drivers/mmc/host/sdhci-s3c.c   |  146 
>> +++-
>>  2 files changed, 191 insertions(+), 6 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt 
>> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>> new file mode 100644
>> index 000..398540b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>> @@ -0,0 +1,51 @@
>> +* Samsung's SDHCI Controller device tree bindings
>> +
>> +Samsung's SDHCI controller is used as a connectivity interface with external
>> +MMC, SD and eMMC storage mediums. This file documents differences between 
>> the
>> +core mmc properties described by mmc.txt and the properties used by the
>> +Samsung implmentation of the SDHCI controller.
>> +
>> +Required SoC Specific Properties:
>> +- compatible: should be one of the following
>> +  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
>> +controller.
>> +  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 
>> sdhci
>> +controller.
>> +
>> +Required Board Specific Properties:
>> +- gpios: Should specify the gpios used for clock, command and data lines. 
>> The
>> +  gpio specifier format depends on the gpio controller.
>> +
>> +Optional Board Specific Properties:
>> +- One of the following properties for card detect type.
>> +  - samsung,sdhci-cd-internal: Card detect line from the card slot  is
>> +connected to the card detect pad of the sdhci controller. A gpio is
>> +used for this connection (with possible pin function settings).
>> +  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
>> +is used a card detect line. This gpio line is not connected to card 
>> detect
>> +pad of the sdhci controller.
>> +  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
>> +detect the presence of the card. (DEFAULT, if no card detect property
>> +is specified).
>> +  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
>> +permanently connected to the sdhci controller.
>> +
>> +Example:
>> + sdhci@1253 {
>> + compatible = "samsung,exynos4210-sdhci";
>> + reg = <0x1253 0x100>;
>> + interrupts = <<0 75 0>;
>> + bus-width = <4>;
>> + samsung,sdhci-cd-internal;
>> + cd-gpios = <&gpk2 2 2 3 3>;
>> + gpios = <&gpk2 0 2 0 3>,  /* clock line */
>> + <&gpk2 1 2 0 3>,  /* command line */
>> + <&gpk2 3 2 3 3>,  /* data line 0 */
>> + <&gpk2 4 2 3 3>,  /* data line 1 */
>> + <&gpk2 5 2 3 3>,  /* data line 2 */
>> + <&gpk2 6 2 3 3>;  /* data line 3 */
>> + };
>> +
>> + Note: This example shows both SoC specific and board specific 
>> properties
>> + in a single device node. The properties can be actually be seperated
>> + into SoC specific node and board specific node.
>
> Looks good, except the text file doesn't mention anywhere that it describes
> the bindings used by sdhci-s3c.c -- that could be useful information to
> someone reading the binding and trying to discover which driver uses it.
>
> Maybe we can call the text file "sdhci-s3c.txt"?  Or "samsung,sdhci-s3c.txt"
> if you prefer.

Hi Chris,

The assumption here was that the all the binding documentation have to
be generic enough to be useful for non-linux platforms as well. And
there were previous discussions on actually moving the binding
documentation outside of the linux source and maintained separately.

Hence, the text file states that it describes the bindings used by
Samsung's SDHCI controller. If you prefer, I can resubmit this patch
with samsung,sdhci-s3c.txt as the file name for the bindings
documentation file.

Thanks,
Thomas.

>
> Thanks,
>
> - Chris.
> --
> Chris Ball  
> One Lap

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Chris Ball]

Hi,

On Thu, Aug 16 2012, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks 
> Cc: Kukjin Kim 
> Cc: Chris Ball 
> Signed-off-by: Thomas Abraham 
> ---
> Changes since v3:
>
> The patch series that adds device tree support for Samsung sdhci controller
> had six patches in total, of which, the first five patches have been accepted.
> The sixth patch in the series was dropped since it was using custom Samsung
> properties for descrbing the bus-width and card-detect gpio, but had otherwise
> addressed all the comments.
>
> This patch reworks the sixth patch in v3 of the sdhci device tree support
> patch series. The only change in this patch from the v3 version is the use of
> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>
>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   51 +++
>  drivers/mmc/host/sdhci-s3c.c   |  146 
> +++-
>  2 files changed, 191 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> new file mode 100644
> index 000..398540b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -0,0 +1,51 @@
> +* Samsung's SDHCI Controller device tree bindings
> +
> +Samsung's SDHCI controller is used as a connectivity interface with external
> +MMC, SD and eMMC storage mediums. This file documents differences between the
> +core mmc properties described by mmc.txt and the properties used by the
> +Samsung implmentation of the SDHCI controller.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> +  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
> +controller.
> +  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
> +controller.
> +
> +Required Board Specific Properties:
> +- gpios: Should specify the gpios used for clock, command and data lines. The
> +  gpio specifier format depends on the gpio controller.
> +
> +Optional Board Specific Properties:
> +- One of the following properties for card detect type.
> +  - samsung,sdhci-cd-internal: Card detect line from the card slot  is
> +connected to the card detect pad of the sdhci controller. A gpio is
> +used for this connection (with possible pin function settings).
> +  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
> +is used a card detect line. This gpio line is not connected to card 
> detect
> +pad of the sdhci controller.
> +  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
> +detect the presence of the card. (DEFAULT, if no card detect property
> +is specified).
> +  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
> +permanently connected to the sdhci controller.
> +
> +Example:
> + sdhci@1253 {
> + compatible = "samsung,exynos4210-sdhci";
> + reg = <0x1253 0x100>;
> + interrupts = <<0 75 0>;
> + bus-width = <4>;
> + samsung,sdhci-cd-internal;
> + cd-gpios = <&gpk2 2 2 3 3>;
> + gpios = <&gpk2 0 2 0 3>,  /* clock line */
> + <&gpk2 1 2 0 3>,  /* command line */
> + <&gpk2 3 2 3 3>,  /* data line 0 */
> + <&gpk2 4 2 3 3>,  /* data line 1 */
> + <&gpk2 5 2 3 3>,  /* data line 2 */
> + <&gpk2 6 2 3 3>;  /* data line 3 */
> + };
> +
> + Note: This example shows both SoC specific and board specific properties
> + in a single device node. The properties can be actually be seperated
> + into SoC specific node and board specific node.

Looks good, except the text file doesn't mention anywhere that it describes
the bindings used by sdhci-s3c.c -- that could be useful information to
someone reading the binding and trying to discover which driver uses it.

Maybe we can call the text file "sdhci-s3c.txt"?  Or "samsung,sdhci-s3c.txt"
if you prefer.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

Add device tree based discovery support for Samsung's sdhci controller

Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Chris Ball 
Signed-off-by: Thomas Abraham 
---
Changes since v3:

The patch series that adds device tree support for Samsung sdhci controller
had six patches in total, of which, the first five patches have been accepted.
The sixth patch in the series was dropped since it was using custom Samsung
properties for descrbing the bus-width and card-detect gpio, but had otherwise
addressed all the comments.

This patch reworks the sixth patch in v3 of the sdhci device tree support
patch series. The only change in this patch from the v3 version is the use of
generic mmc bindings for descrbing the bus-width and card-detect gpio.

 .../devicetree/bindings/mmc/samsung-sdhci.txt  |   51 +++
 drivers/mmc/host/sdhci-s3c.c   |  146 +++-
 2 files changed, 191 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt

diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt 
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000..398540b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,51 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums. This file documents differences between the
+core mmc properties described by mmc.txt and the properties used by the
+Samsung implmentation of the SDHCI controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
+controller.
+  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
+controller.
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+  gpio specifier format depends on the gpio controller.
+
+Optional Board Specific Properties:
+- One of the following properties for card detect type.
+  - samsung,sdhci-cd-internal: Card detect line from the card slot  is
+connected to the card detect pad of the sdhci controller. A gpio is
+used for this connection (with possible pin function settings).
+  - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+is used a card detect line. This gpio line is not connected to card detect
+pad of the sdhci controller.
+  - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+detect the presence of the card. (DEFAULT, if no card detect property
+is specified).
+  - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+permanently connected to the sdhci controller.
+
+Example:
+   sdhci@1253 {
+   compatible = "samsung,exynos4210-sdhci";
+   reg = <0x1253 0x100>;
+   interrupts = <<0 75 0>;
+   bus-width = <4>;
+   samsung,sdhci-cd-internal;
+   cd-gpios = <&gpk2 2 2 3 3>;
+   gpios = <&gpk2 0 2 0 3>,  /* clock line */
+   <&gpk2 1 2 0 3>,  /* command line */
+   <&gpk2 3 2 3 3>,  /* data line 0 */
+   <&gpk2 4 2 3 3>,  /* data line 1 */
+   <&gpk2 5 2 3 3>,  /* data line 2 */
+   <&gpk2 6 2 3 3>;  /* data line 3 */
+   };
+
+   Note: This example shows both SoC specific and board specific properties
+   in a single device node. The properties can be actually be seperated
+   into SoC specific node and board specific node.
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a50c205..7fcc642 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -34,6 +34,9 @@
 
 #define MAX_BUS_CLK(4)
 
+/* Number of gpio's used is max data bus width + command and clock lines */
+#define NUM_GPIOS(x)   (x + 2)
+
 /**
  * struct sdhci_s3c - S3C SDHCI instance
  * @host: The SDHCI host created
@@ -41,6 +44,7 @@
  * @ioarea: The resource created when we claimed the IO area.
  * @pdata: The platform data for this controller.
  * @cur_clk: The index of the current bus clock.
+ * @gpios: List of gpio numbers parsed from device tree.
  * @clk_io: The clock for the internal bus interface.
  * @clk_bus: The clocks that are available for the SD/MMC bus clock.
  */
@@ -52,6 +56,7 @@ struct sdhci_s3c {
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
+   int *gpios;
 
struct clk  *clk_io;
struct clk  *clk_bus[MAX_BUS_CLK];
@@ -419,9 +424,109 @@ static void sdhci_s3c_setup_card_detect_gpio(struct 
sdhci_s3c *sc)
}
 }
 
+#ifdef CONFIG_OF
+static int __devinit sdhci_s3c_parse_dt(struct

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

Hi Chris,

Thanks for your review.

On 16 August 2012 21:17, Chris Ball  wrote:
> Hi Thomas,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks 
>> Cc: Kukjin Kim 
>> Cc: Chris Ball 
>> Signed-off-by: Thomas Abraham 
>> ---
>>  drivers/mmc/host/sdhci-s3c.c |  146 
>> --
>>  1 files changed, 140 insertions(+), 6 deletions(-)
>
> I know your initial version was submitted before we adopted a set of
> standard MMC DT bindings, but now that those bindings exist this code
> should be using them -- there should be a new file:
>Documentation/devicetree/bindings/mmc/sdhci-s3c.txt
> describing differences between the mmc.txt bindings and this driver's.

Sorry, I missed that. I will resend this patch with the documentation.

>
> Also, you didn't include a patch changelog, so I can't tell whether this
> contains changes against your v3 of this patch; please do that.

Yes, I missed the changelog as well. I will add it in the next version
of this patch.

Thanks,
Thomas.

>
> Thanks!
>
> - Chris.
> --
> Chris Ball  
> One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci-s3c: Add device tree support

[Chris Ball]

Hi Thomas,

On Thu, Aug 16 2012, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks 
> Cc: Kukjin Kim 
> Cc: Chris Ball 
> Signed-off-by: Thomas Abraham 
> ---
>  drivers/mmc/host/sdhci-s3c.c |  146 
> --
>  1 files changed, 140 insertions(+), 6 deletions(-)

I know your initial version was submitted before we adopted a set of
standard MMC DT bindings, but now that those bindings exist this code
should be using them -- there should be a new file:
   Documentation/devicetree/bindings/mmc/sdhci-s3c.txt
describing differences between the mmc.txt bindings and this driver's.

Also, you didn't include a patch changelog, so I can't tell whether this
contains changes against your v3 of this patch; please do that.

Thanks!

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

Add device tree based discovery support for Samsung's sdhci controller

Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Chris Ball 
Signed-off-by: Thomas Abraham 
---
 drivers/mmc/host/sdhci-s3c.c |  146 --
 1 files changed, 140 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a50c205..7fcc642 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -34,6 +34,9 @@
 
 #define MAX_BUS_CLK(4)
 
+/* Number of gpio's used is max data bus width + command and clock lines */
+#define NUM_GPIOS(x)   (x + 2)
+
 /**
  * struct sdhci_s3c - S3C SDHCI instance
  * @host: The SDHCI host created
@@ -41,6 +44,7 @@
  * @ioarea: The resource created when we claimed the IO area.
  * @pdata: The platform data for this controller.
  * @cur_clk: The index of the current bus clock.
+ * @gpios: List of gpio numbers parsed from device tree.
  * @clk_io: The clock for the internal bus interface.
  * @clk_bus: The clocks that are available for the SD/MMC bus clock.
  */
@@ -52,6 +56,7 @@ struct sdhci_s3c {
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
+   int *gpios;
 
struct clk  *clk_io;
struct clk  *clk_bus[MAX_BUS_CLK];
@@ -419,9 +424,109 @@ static void sdhci_s3c_setup_card_detect_gpio(struct 
sdhci_s3c *sc)
}
 }
 
+#ifdef CONFIG_OF
+static int __devinit sdhci_s3c_parse_dt(struct device *dev,
+   struct sdhci_host *host, struct s3c_sdhci_platdata *pdata)
+{
+   struct device_node *node = dev->of_node;
+   struct sdhci_s3c *ourhost = to_s3c(host);
+   u32 max_width;
+   int gpio, cnt, ret;
+
+   /* if the bus-width property is not specified, assume width as 1 */
+   if (of_property_read_u32(node, "bus-width", &max_width))
+   max_width = 1;
+   pdata->max_width = max_width;
+
+   ourhost->gpios = devm_kzalloc(dev, NUM_GPIOS(pdata->max_width) *
+   sizeof(int), GFP_KERNEL);
+   if (!ourhost->gpios)
+   return -ENOMEM;
+
+   /* get the card detection method */
+   if (of_get_property(node, "samsung,sdhci-cd-internal", NULL))
+   pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
+   else if (of_get_property(node, "samsung,sdhci-cd-gpio", NULL))
+   pdata->cd_type = S3C_SDHCI_CD_GPIO;
+   else if (of_get_property(node, "samsung,sdhci-cd-none", NULL))
+   pdata->cd_type = S3C_SDHCI_CD_NONE;
+   else if (of_get_property(node, "samsung,sdhci-cd-permanent", NULL))
+   pdata->cd_type = S3C_SDHCI_CD_PERMANENT;
+   else
+   pdata->cd_type = S3C_SDHCI_CD_NONE;
+
+   /* get the gpio used for card detection */
+   if (pdata->cd_type == S3C_SDHCI_CD_GPIO ||
+   pdata->cd_type == S3C_SDHCI_CD_INTERNAL) {
+   gpio = of_get_named_gpio(node, "cd-gpios", 0);
+   if (!gpio_is_valid(gpio)) {
+   dev_err(dev, "invalid card detect gpio specified\n");
+   return -EINVAL;
+   }
+   }
+
+   if (pdata->cd_type == S3C_SDHCI_CD_GPIO) {
+   pdata->ext_cd_gpio = gpio;
+   ourhost->ext_cd_gpio = -1;
+   if (of_get_property(node, "cd-inverted", NULL))
+   pdata->ext_cd_gpio_invert = 1;
+   } else if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL) {
+   ret = gpio_request(gpio, "sdhci-cd");
+   if (ret) {
+   dev_err(dev, "card detect gpio request failed\n");
+   return -EINVAL;
+   }
+   ourhost->ext_cd_gpio = gpio;
+   }
+
+   /* get the gpios for command, clock and data lines */
+   for (cnt = 0; cnt < NUM_GPIOS(pdata->max_width); cnt++) {
+   gpio = of_get_gpio(node, cnt);
+   if (!gpio_is_valid(gpio)) {
+   dev_err(dev, "invalid gpio[%d]\n", cnt);
+   goto err_free_dt_cd_gpio;
+   }
+   ourhost->gpios[cnt] = gpio;
+   }
+
+   for (cnt = 0; cnt < NUM_GPIOS(pdata->max_width); cnt++) {
+   ret = gpio_request(ourhost->gpios[cnt], "sdhci-gpio");
+   if (ret) {
+   dev_err(dev, "gpio[%d] request failed\n", cnt);
+   goto err_free_dt_gpios;
+   }
+   }
+
+   return 0;
+
+ err_free_dt_gpios:
+   while (--cnt >= 0)
+   gpio_free(ourhost->gpios[cnt]);
+ err_free_dt_cd_gpio:
+   if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL)
+   gpio_free(ourhost->ext_cd_gpio);
+   return -EINVAL;
+}
+#else
+static int __devinit sdhci_s3c_parse_dt(struct device *dev,
+   struct sdhci_host *host, struct s3c_sdhci_platdata *pdata)
+{
+   return -EINVAL;
+}
+#endif
+

Re: [linux-pm] [PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

[Valentin, Eduardo]

Amit,

Thanks again for keeping this up.

On Thu, Aug 16, 2012 at 2:41 PM, Amit Daniel Kachhap
 wrote:
> This patchset introduces a new generic cooling device based on cpufreq
> that can be used on non-ACPI platforms.  As a proof of concept, we have
> drivers for the following platforms using this mechanism now:
>
>  * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
>  * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git 
> imx6q_thermal)

FYI, the OMAP code is under drivers/staging/omap-thermal/. The file
omap-thermal-common.c is the one which is using your generic cooling
device. But it needs to be updated accordingly to the API change you
mention.

>
> There is a small change in cpufreq cooling registration APIs, so a minor
> change is needed for Freescale platforms.
>
> Brief Description:
>
> 1) The generic cooling devices code is placed inside driver/thermal/*
>as placing inside acpi folder will need un-necessary enabling of acpi
>code.  This code is architecture independent.
>
> 2) This patchset adds generic cpu cooling low level implementation
>through frequency clipping.  In future, other cpu related cooling
>devices may be added here.  An ACPI version of this already exists
>(drivers/acpi/processor_thermal.c) .But this will be useful for
>platforms like ARM using the generic thermal interface along with the
>generic cpu cooling devices.  The cooling device registration API's
>return cooling device pointers which can be easily binded with the
>thermal zone trip points.  The important APIs exposed are,
>
>a) struct thermal_cooling_device *cpufreq_cooling_register(
> struct cpumask *clip_cpus)
>b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>
> 3) Samsung exynos platform thermal implementation is done using the
>generic cpu cooling APIs and the new trip type.  The temperature sensor
>driver present in the hwmon folder(registered as hwmon driver) is moved
>to thermal folder and registered as a thermal driver.
>
> A simple data/control flow diagrams is shown below,
>
> Core Linux thermal <->  Exynos thermal interface <- Temperature Sensor
>   | |
>  \|/|
>   Cpufreq cooling device <---
>
> TODO:
> *Will send the DT enablement patches later after the driver is merged.
>
> This patch:
>
> Add support for generic cpu thermal cooling low level implementations
> using frequency scaling up/down based on the registration parameters.
> Different cpu related cooling devices can be registered by the user and
> the binding of these cooling devices to the corresponding trip points can
> be easily done as the registration APIs return the cooling device pointer.
> The user of these APIs are responsible for passing clipping frequency .
> The drivers can also register to recieve notification about any cooling
> action called.
>
> [a...@linux-foundation.org: fix comment layout]
> Signed-off-by: Amit Daniel Kachhap 
> Cc: Guenter Roeck 
> Cc: SangWook Ju 
> Cc: Durgadoss 
> Cc: Len Brown 
> Cc: Jean Delvare 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Amit Daniel Kachhap 


Reviewed-by: Eduardo Valentin 


> ---
>  Documentation/thermal/cpu-cooling-api.txt |   52 +++
>  drivers/thermal/Kconfig   |   11 +
>  drivers/thermal/Makefile  |1 +
>  drivers/thermal/cpu_cooling.c |  512 
> +
>  include/linux/cpu_cooling.h   |   79 +
>  5 files changed, 655 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
>  create mode 100644 drivers/thermal/cpu_cooling.c
>  create mode 100644 include/linux/cpu_cooling.h
>
> diff --git a/Documentation/thermal/cpu-cooling-api.txt 
> b/Documentation/thermal/cpu-cooling-api.txt
> new file mode 100644
> index 000..a1f2a6b
> --- /dev/null
> +++ b/Documentation/thermal/cpu-cooling-api.txt
> @@ -0,0 +1,52 @@
> +CPU cooling APIs How To
> +===
> +
> +Written by Amit Daniel Kachhap 
> +
> +Updated: 12 May 2012
> +
> +Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
> +
> +0. Introduction
> +
> +The generic cpu cooling(freq clipping) provides registration/unregistration 
> APIs
> +to the caller. The binding of the cooling devices to the trip point is left 
> for
> +the user. The registration APIs returns the cooling device pointer.
> +
> +1. cpu cooling APIs
> +
> +1.1 cpufreq registration/unregistration APIs
> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
> +   struct cpumask *clip_cpus)
> +
> +This interface function registers the cpufreq cooling device with the 
> name
> +"thermal-cpufreq-%x". This api can support multiple instances of cpufreq
> +cooling devices.
> +
> +   clip_cpus: cpumask of cpus where the frequency constrain

Re: Unbalanced calls to spi_master_get in coldfire-qspi and s3c64xx SPI master drivers

[Guenter Roeck]

On Thu, Aug 16, 2012 at 02:27:49PM +0530, Thomas Abraham wrote:
> On 14 August 2012 03:14, Guenter Roeck  wrote:
> > Hi all,
> >
> > looking through SPI master drivers, I noticed that the following drivers 
> > call
> > spi_master_get() in their suspend and resume functions. Yet, there is no
> > matching call to spi_master_put(), meaning the reference count will increase
> > with each suspend/resume cycle.
> > spi-coldfire-qspi.c
> > spi-s3c64xx.c
> > Other SPI master drivers also support suspend and resume, but do not call
> > spi_master_get() in the suspend/resume functions. The spi-pl022 driver calls
> > spi_master_suspend() and spi_master_resume() like the above, but does not
> > call spi_master_get() either.
> >
> > This leads me to believe that the above drivers will hang on unload after a
> > suspend/resume cycle due to the extra references.
> >
> > Can someone please have a look and confirm if my understanding is correct ?
> > If so I'll send a set of patches to fix the problems.
> 
> For spi-s3c64xx.c, yes it does seem that the spi_master_get() and
> spi_master_put() calls are not balanced.  The probable change could be
> 
> -  struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
> + struct spi_master *master = dev_get_drvdata(dev);
> 
Yes, that is what I thought.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/6] thermal: exynos5: add exynos5250 thermal sensor driver support

[Amit Daniel Kachhap]

Insert exynos5 TMU sensor changes into the thermal driver.  Some exynos4
changes are made generic for exynos series.

[a...@linux-foundation.org: fix comment layout]
Signed-off-by: SangWook Ju 
Signed-off-by: Amit Daniel Kachhap 
Acked-by: Guenter Roeck 
Cc: Durgadoss 
Cc: Len Brown 
Cc: Jean Delvare 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/Kconfig  |2 +-
 drivers/thermal/exynos_thermal.c |  351 --
 include/linux/platform_data/exynos_thermal.h |   19 ++-
 3 files changed, 240 insertions(+), 132 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8f2b6ea..edfd67d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -49,7 +49,7 @@ config RCAR_THERMAL
 
 config EXYNOS_THERMAL
tristate "Temperature sensor on Samsung EXYNOS"
-   depends on ARCH_EXYNOS4 && THERMAL
+   depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && THERMAL
help
  If you say yes here you get support for TMU (Thermal Managment
  Unit) on SAMSUNG EXYNOS series of SoC.
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 556d15b..c9a33dd 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -33,44 +33,83 @@
 #include 
 #include 
 #include 
-
 #include 
-
-#define EXYNOS4_TMU_REG_TRIMINFO   0x0
-#define EXYNOS4_TMU_REG_CONTROL0x20
-#define EXYNOS4_TMU_REG_STATUS 0x28
-#define EXYNOS4_TMU_REG_CURRENT_TEMP   0x40
-#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
-#define EXYNOS4_TMU_REG_TRIG_LEVEL00x50
-#define EXYNOS4_TMU_REG_TRIG_LEVEL10x54
-#define EXYNOS4_TMU_REG_TRIG_LEVEL20x58
-#define EXYNOS4_TMU_REG_TRIG_LEVEL30x5C
-#define EXYNOS4_TMU_REG_PAST_TEMP0 0x60
-#define EXYNOS4_TMU_REG_PAST_TEMP1 0x64
-#define EXYNOS4_TMU_REG_PAST_TEMP2 0x68
-#define EXYNOS4_TMU_REG_PAST_TEMP3 0x6C
-#define EXYNOS4_TMU_REG_INTEN  0x70
-#define EXYNOS4_TMU_REG_INTSTAT0x74
-#define EXYNOS4_TMU_REG_INTCLEAR   0x78
-
-#define EXYNOS4_TMU_GAIN_SHIFT 8
-#define EXYNOS4_TMU_REF_VOLTAGE_SHIFT  24
-
-#define EXYNOS4_TMU_TRIM_TEMP_MASK 0xff
-#define EXYNOS4_TMU_CORE_ON3
-#define EXYNOS4_TMU_CORE_OFF   2
-#define EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET50
-#define EXYNOS4_TMU_TRIG_LEVEL0_MASK   0x1
-#define EXYNOS4_TMU_TRIG_LEVEL1_MASK   0x10
-#define EXYNOS4_TMU_TRIG_LEVEL2_MASK   0x100
-#define EXYNOS4_TMU_TRIG_LEVEL3_MASK   0x1000
-#define EXYNOS4_TMU_INTCLEAR_VAL   0x
-
-struct exynos4_tmu_data {
-   struct exynos4_tmu_platform_data *pdata;
+#include 
+
+#include 
+
+/* Exynos generic registers */
+#define EXYNOS_TMU_REG_TRIMINFO0x0
+#define EXYNOS_TMU_REG_CONTROL 0x20
+#define EXYNOS_TMU_REG_STATUS  0x28
+#define EXYNOS_TMU_REG_CURRENT_TEMP0x40
+#define EXYNOS_TMU_REG_INTEN   0x70
+#define EXYNOS_TMU_REG_INTSTAT 0x74
+#define EXYNOS_TMU_REG_INTCLEAR0x78
+
+#define EXYNOS_TMU_TRIM_TEMP_MASK  0xff
+#define EXYNOS_TMU_GAIN_SHIFT  8
+#define EXYNOS_TMU_REF_VOLTAGE_SHIFT   24
+#define EXYNOS_TMU_CORE_ON 3
+#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
+
+/* Exynos4210 specific registers */
+#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP  0x44
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C
+#define EXYNOS4210_TMU_REG_PAST_TEMP0  0x60
+#define EXYNOS4210_TMU_REG_PAST_TEMP1  0x64
+#define EXYNOS4210_TMU_REG_PAST_TEMP2  0x68
+#define EXYNOS4210_TMU_REG_PAST_TEMP3  0x6C
+
+#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK0x1
+#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK0x10
+#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK0x100
+#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK0x1000
+#define EXYNOS4210_TMU_INTCLEAR_VAL0x
+
+/* Exynos5250 and Exynos4412 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON0x14
+#define EXYNOS_THD_TEMP_RISE   0x50
+#define EXYNOS_THD_TEMP_FALL   0x54
+#define EXYNOS_EMUL_CON0x80
+
+#define EXYNOS_TRIMINFO_RELOAD 0x1
+#define EXYNOS_TMU_CLEAR_RISE_INT  0x111
+#define EXYNOS_TMU_CLEAR_FALL_INT  (0x111 << 16)
+#define EXYNOS_MUX_ADDR_VALUE  6
+#define EXYNOS_MUX_ADDR_SHIFT  20
+#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+
+#define EFUSE_MIN_VALUE 40
+#define EFUSE_MAX_VALUE 100
+
+/* In-kernel thermal framework related macros & definations */
+#define SENSOR_NAME_LEN16
+#define MAX_TRIP_COUNT 8
+#define MAX_COOLING_DEVICE 4
+
+#define ACTIVE_INTERVAL 500
+#define IDLE_INTERVAL 1
+
+/* CPU Zone information */
+#define PANIC_ZONE  4
+#define WARN_ZONE   3
+#define MONITOR_ZONE2
+#define SAFE_Z

Re: [PATCH] ARM: EXYNOS: Add MFC device tree support

[Thomas Abraham]

On 16 August 2012 18:01, Arun Kumar K  wrote:
> From: Naveen Krishna Chatradhi 
>
> This patch adds device tree entry for MFC in the Exynos
> machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
> MFC v6.x version. So making the required changes in the clock
> files and adds MFC to the DT device list.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Arun Kumar K 
> ---
>  .../devicetree/bindings/media/s5p-mfc.txt  |   24 
> 
>  arch/arm/boot/dts/exynos4210.dtsi  |   10 
>  arch/arm/boot/dts/exynos5250.dtsi  |   10 
>  arch/arm/mach-exynos/clock-exynos5.c   |2 +-
>  arch/arm/mach-exynos/mach-exynos4-dt.c |   22 ++
>  arch/arm/mach-exynos/mach-exynos5-dt.c |   22 ++
>  6 files changed, 89 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> new file mode 100644
> index 000..b9bd266
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -0,0 +1,24 @@
> +* Samsung Multi Format Codec (MFC)
> +
> +Mult Format Codec (MFC) is the IP present in Samsung SoCs which
> +supports high resolution decoding and encoding functionalities.

In addition to this, specifying that mfc is used for video
encode/decode would be informative.

> +
> +Required properties:
> +  - compatible : value should be either one among the following
> +   (a) "samsung,s5p-mfc-v5" for MFC v5 present in Exynos4 SoCs
> +   (b) "samsung,s5p-mfc-v6" for MFC v6.x present in Exynos5 SoCs

"s5p" should be dropped from the compatible values. For example, it
should be "samsung,mfc-v5", which is sufficient to identify the
version of the mfc controller.

> +
> +  - reg : Physical base address of the IP registers and length of memory
> + mapped region.
> +
> +  - interrupts : MFC interupt number to the CPU.
> +
> +  - samsung,mfc-r : Base address of the first memory bank used by MFC
> +   for DMA contiguous memory allocation.
> +
> +  - samsung,mfc-r-size : Size of the first memory bank.

It is not allowed to pass buffer base address and size from device
tree. Device tree node should describe only the MFC controller
hardware. Any memory management related information should be handled
outside of device tree. This helps the bindings to be reusable across
multiple operating systems.

> +
> +  - samsung,mfc-l : Base address of the second memory bank used by MFC
> +   for DMA contiguous memory allocation.
> +
> +  - samsung,mfc-l-size : Size of the second memory bank.

Same comment as above. And the bindings documentation is usually
included in the same patch that adds device tree support for the
driver.

> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 02891fe..b5ee43d 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -56,6 +56,16 @@
> interrupts = <0 43 0>;
> };
>
> +   mfc {
> +   compatible = "samsung,s5p-mfc";
> +   reg = <0x1340 0x1>;
> +   interrupts = <0 94 0>;
> +   samsung,mfc-r = <0x4300>;
> +   samsung,mfc-r-size = <8388608>;
> +   samsung,mfc-l = <0x5100>;
> +   samsung,mfc-l-size = <8388608>;
> +   };
> +
> rtc@1007 {
> compatible = "samsung,s3c6410-rtc";
> reg = <0x1007 0x100>;
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 004aaa8..3c762a4 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -58,6 +58,16 @@
> interrupts = <0 42 0>;
> };
>
> +   mfc {
> +   compatible = "samsung,s5p-mfc-v6";
> +   reg = <0x1100 0x1>;
> +   interrupts = <0 96 0>;
> +   samsung,mfc-r = <0x4300>;
> +   samsung,mfc-r-size = <8388608>;
> +   samsung,mfc-l = <0x5100>;
> +   samsung,mfc-l-size = <8388608>;
> +   };
> +
> rtc {
> compatible = "samsung,s3c6410-rtc";
> reg = <0x101E 0x100>;
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
> b/arch/arm/mach-exynos/clock-exynos5.c
> index 3b00e29..c85e7b2 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -607,7 +607,7 @@ static struct clk exynos5_init_clocks_off[] = {
> .ctrlbit= (1 << 25),
> }, {
> .name   = "mfc",
> -   .devname= "s5p-mfc",
> +   .devname= "s5p-mfc-v6",
> .enable = exynos5_clk_ip_mfc_ctr

[PATCH v6 6/6] thermal: exynos: Use devm_* functions

[Amit Daniel Kachhap]

devm_* functions are used to replace kzalloc, request_mem_region, ioremap
and request_irq functions in probe call. With the usage of devm_* functions
explicit freeing and unmapping is not required.

Signed-off-by: Sachin Kamat 
Signed-off-by: Sachin Kamat 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/exynos_thermal.c |   45 +++--
 1 files changed, 9 insertions(+), 36 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 03a99e4..e84acde 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -842,7 +842,8 @@ static int __devinit exynos_tmu_probe(struct 
platform_device *pdev)
dev_err(&pdev->dev, "No platform init data supplied.\n");
return -ENODEV;
}
-   data = kzalloc(sizeof(struct exynos_tmu_data), GFP_KERNEL);
+   data = devm_kzalloc(&pdev->dev, sizeof(struct exynos_tmu_data),
+   GFP_KERNEL);
if (!data) {
dev_err(&pdev->dev, "Failed to allocate driver structure\n");
return -ENOMEM;
@@ -850,47 +851,35 @@ static int __devinit exynos_tmu_probe(struct 
platform_device *pdev)
 
data->irq = platform_get_irq(pdev, 0);
if (data->irq < 0) {
-   ret = data->irq;
dev_err(&pdev->dev, "Failed to get platform irq\n");
-   goto err_free;
+   return data->irq;
}
 
INIT_WORK(&data->irq_work, exynos_tmu_work);
 
data->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!data->mem) {
-   ret = -ENOENT;
dev_err(&pdev->dev, "Failed to get platform resource\n");
-   goto err_free;
+   return -ENOENT;
}
 
-   data->mem = request_mem_region(data->mem->start,
-   resource_size(data->mem), pdev->name);
-   if (!data->mem) {
-   ret = -ENODEV;
-   dev_err(&pdev->dev, "Failed to request memory region\n");
-   goto err_free;
-   }
-
-   data->base = ioremap(data->mem->start, resource_size(data->mem));
+   data->base = devm_request_and_ioremap(&pdev->dev, data->mem);
if (!data->base) {
-   ret = -ENODEV;
dev_err(&pdev->dev, "Failed to ioremap memory\n");
-   goto err_mem_region;
+   return -ENODEV;
}
 
-   ret = request_irq(data->irq, exynos_tmu_irq,
+   ret = devm_request_irq(&pdev->dev, data->irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING, "exynos-tmu", data);
if (ret) {
dev_err(&pdev->dev, "Failed to request irq: %d\n", data->irq);
-   goto err_io_remap;
+   return ret;
}
 
data->clk = clk_get(NULL, "tmu_apbif");
if (IS_ERR(data->clk)) {
-   ret = PTR_ERR(data->clk);
dev_err(&pdev->dev, "Failed to get clock\n");
-   goto err_irq;
+   return  PTR_ERR(data->clk);
}
 
if (pdata->type == SOC_ARCH_EXYNOS ||
@@ -942,15 +931,6 @@ static int __devinit exynos_tmu_probe(struct 
platform_device *pdev)
 err_clk:
platform_set_drvdata(pdev, NULL);
clk_put(data->clk);
-err_irq:
-   free_irq(data->irq, data);
-err_io_remap:
-   iounmap(data->base);
-err_mem_region:
-   release_mem_region(data->mem->start, resource_size(data->mem));
-err_free:
-   kfree(data);
-
return ret;
 }
 
@@ -964,15 +944,8 @@ static int __devexit exynos_tmu_remove(struct 
platform_device *pdev)
 
clk_put(data->clk);
 
-   free_irq(data->irq, data);
-
-   iounmap(data->base);
-   release_mem_region(data->mem->start, resource_size(data->mem));
-
platform_set_drvdata(pdev, NULL);
 
-   kfree(data);
-
return 0;
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/6] ARM: exynos: add thermal sensor driver platform data support

[Amit Daniel Kachhap]

Add necessary default platform data support needed for TMU driver.  The
supplied dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms and only compile tested for exynos4412.

Signed-off-by: Amit Daniel Kachhap 
Acked-by: Guenter Roeck 
Cc: SangWook Ju 
Cc: Durgadoss 
Cc: Len Brown 
Cc: Jean Delvare 
Cc: jonghwa lee 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/exynos_thermal.c |  111 +-
 1 files changed, 110 insertions(+), 1 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index e79cdc9..03a99e4 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -723,14 +723,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
 static struct thermal_sensor_conf exynos_sensor_conf = {
.name   = "exynos-therm",
.read_temperature   = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
+static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
+   .threshold = 80,
+   .trigger_levels[0] = 5,
+   .trigger_levels[1] = 20,
+   .trigger_levels[2] = 30,
+   .trigger_level0_en = 1,
+   .trigger_level1_en = 1,
+   .trigger_level2_en = 1,
+   .trigger_level3_en = 0,
+   .gain = 15,
+   .reference_voltage = 7,
+   .cal_type = TYPE_ONE_POINT_TRIMMING,
+   .freq_tab[0] = {
+   .freq_clip_max = 800 * 1000,
+   .temp_level = 85,
+   },
+   .freq_tab[1] = {
+   .freq_clip_max = 200 * 1000,
+   .temp_level = 100,
+   },
+   .freq_tab_count = 2,
+   .type = SOC_ARCH_EXYNOS4210,
+};
+#define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
+#else
+#define EXYNOS4210_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
+static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
+   .trigger_levels[0] = 85,
+   .trigger_levels[1] = 103,
+   .trigger_levels[2] = 110,
+   .trigger_level0_en = 1,
+   .trigger_level1_en = 1,
+   .trigger_level2_en = 1,
+   .trigger_level3_en = 0,
+   .gain = 8,
+   .reference_voltage = 16,
+   .noise_cancel_mode = 4,
+   .cal_type = TYPE_ONE_POINT_TRIMMING,
+   .efuse_value = 55,
+   .freq_tab[0] = {
+   .freq_clip_max = 800 * 1000,
+   .temp_level = 85,
+   },
+   .freq_tab[1] = {
+   .freq_clip_max = 200 * 1000,
+   .temp_level = 103,
+   },
+   .freq_tab_count = 2,
+   .type = SOC_ARCH_EXYNOS,
+};
+#define EXYNOS_TMU_DRV_DATA (&exynos_default_tmu_data)
+#else
+#define EXYNOS_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+   {
+   .compatible = "samsung,exynos4210-tmu",
+   .data = (void *)EXYNOS4210_TMU_DRV_DATA,
+   },
+   {
+   .compatible = "samsung,exynos5250-tmu",
+   .data = (void *)EXYNOS_TMU_DRV_DATA,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define  exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+   {
+   .name   = "exynos4210-tmu",
+   .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
+   },
+   {
+   .name   = "exynos5250-tmu",
+   .driver_data= (kernel_ulong_t)EXYNOS_TMU_DRV_DATA,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
+   struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+   if (pdev->dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_node(exynos_tmu_match, pdev->dev.of_node);
+   if (!match)
+   return NULL;
+   return (struct exynos_tmu_platform_data *) match->data;
+   }
+#endif
+   return (struct exynos_tmu_platform_data *)
+   platform_get_device_id(pdev)->driver_data;
 }
-;
 static int __devinit exynos_tmu_probe(struct platform_device *pdev)
 {
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev->dev.platform_data;
int ret, i;
 
+   if (!pdata)
+   pdata = exynos_get_driver_data(pdev);
+
if (!pdata) {
dev_err(&pdev->dev, "No platform init data supplied.\n");
return -ENODEV;
@@ -899,9 +1006,11 @@ static struct platform_driver exynos_tmu_driver = {
.name   = "exynos-tmu",
.owner  = THIS_MODULE,
.pm = EXYNOS_TMU_PM,
+   .of_match_table = exynos_tmu_match,
},
.probe = exy

[PATCH v6 4/6] thermal: exynos: register the tmu sensor with the kernel thermal layer

[Amit Daniel Kachhap]

This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform.  This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.

[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Amit Daniel Kachhap 
Acked-by: Guenter Roeck 
Cc: SangWook Ju 
Cc: Durgadoss 
Cc: Len Brown 
Cc: Jean Delvare 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/exynos_thermal.c |  406 +-
 include/linux/platform_data/exynos_thermal.h |   22 ++
 2 files changed, 426 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index c9a33dd..e79cdc9 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -94,6 +97,7 @@
 
 #define ACTIVE_INTERVAL 500
 #define IDLE_INTERVAL 1
+#define MCELSIUS   1000
 
 /* CPU Zone information */
 #define PANIC_ZONE  4
@@ -104,6 +108,8 @@
 #define GET_ZONE(trip) (trip + 2)
 #define GET_TRIP(zone) (zone - 2)
 
+#define EXYNOS_ZONE_COUNT  3
+
 struct exynos_tmu_data {
struct exynos_tmu_platform_data *pdata;
struct resource *mem;
@@ -116,6 +122,371 @@ struct exynos_tmu_data {
u8 temp_error1, temp_error2;
 };
 
+struct thermal_trip_point_conf {
+   int trip_val[MAX_TRIP_COUNT];
+   int trip_count;
+};
+
+struct thermal_cooling_conf {
+   struct freq_clip_table freq_data[MAX_TRIP_COUNT];
+   int freq_clip_count;
+};
+
+struct thermal_sensor_conf {
+   char name[SENSOR_NAME_LEN];
+   int (*read_temperature)(void *data);
+   struct thermal_trip_point_conf trip_data;
+   struct thermal_cooling_conf cooling_data;
+   void *private_data;
+};
+
+struct exynos_thermal_zone {
+   enum thermal_device_mode mode;
+   struct thermal_zone_device *therm_dev;
+   struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+   unsigned int cool_dev_size;
+   struct platform_device *exynos4_dev;
+   struct thermal_sensor_conf *sensor_conf;
+   bool bind;
+};
+
+static struct exynos_thermal_zone *th_zone;
+static void exynos_unregister_thermal(void);
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
+
+/* Get mode callback functions for thermal zone */
+static int exynos_get_mode(struct thermal_zone_device *thermal,
+   enum thermal_device_mode *mode)
+{
+   if (th_zone)
+   *mode = th_zone->mode;
+   return 0;
+}
+
+/* Set mode callback functions for thermal zone */
+static int exynos_set_mode(struct thermal_zone_device *thermal,
+   enum thermal_device_mode mode)
+{
+   if (!th_zone->therm_dev) {
+   pr_notice("thermal zone not registered\n");
+   return 0;
+   }
+
+   mutex_lock(&th_zone->therm_dev->lock);
+
+   if (mode == THERMAL_DEVICE_ENABLED)
+   th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
+   else
+   th_zone->therm_dev->polling_delay = 0;
+
+   mutex_unlock(&th_zone->therm_dev->lock);
+
+   th_zone->mode = mode;
+   thermal_zone_device_update(th_zone->therm_dev);
+   pr_info("thermal polling set for duration=%d msec\n",
+   th_zone->therm_dev->polling_delay);
+   return 0;
+}
+
+
+/* Get trip type callback functions for thermal zone */
+static int exynos_get_trip_type(struct thermal_zone_device *thermal, int trip,
+enum thermal_trip_type *type)
+{
+   switch (GET_ZONE(trip)) {
+   case MONITOR_ZONE:
+   case WARN_ZONE:
+   *type = THERMAL_TRIP_ACTIVE;
+   break;
+   case PANIC_ZONE:
+   *type = THERMAL_TRIP_CRITICAL;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
+/* Get trip temperature callback functions for thermal zone */
+static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int trip,
+   unsigned long *temp)
+{
+   if (trip < GET_TRIP(MONITOR_ZONE) || trip > GET_TRIP(PANIC_ZONE))
+   return -EINVAL;
+
+   *temp = th_zone->sensor_conf->trip_data.trip_val[trip];
+   /* convert the temperature into millicelsius */
+   *temp = *temp * MCELSIUS;
+
+   return 0;
+}
+
+/* Get critical temperature callback functions for thermal zone */
+static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
+   unsigned long *temp)
+{
+   int ret;
+   /* Panic zone */
+   ret = exynos_get_trip_temp(thermal, GET_TRIP(PANIC_ZONE), temp);
+   return ret;
+}
+
+static int exynos_get_frequency_level(unsigned int cpu, uns

[PATCH v6 2/6] hwmon: exynos4: move thermal sensor driver to driver/thermal directory

[Amit Daniel Kachhap]

This movement is needed because the hwmon entries and corresponding sysfs
interface is a duplicate of utilities already provided by
driver/thermal/thermal_sys.c.  The goal is to place it in thermal folder
and add necessary functions to use the in-kernel thermal interfaces.

Signed-off-by: Amit Daniel Kachhap 
Acked-by: Guenter Roeck 
Cc: SangWook Ju 
Cc: Durgadoss 
Cc: Len Brown 
Cc: Jean Delvare 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Amit Daniel Kachhap 
---
 Documentation/hwmon/exynos4_tmu  |   81 
 Documentation/thermal/exynos_thermal |   52 +++
 drivers/hwmon/Kconfig|   10 -
 drivers/hwmon/Makefile   |1 -
 drivers/hwmon/exynos4_tmu.c  |  518 --
 drivers/thermal/Kconfig  |7 +
 drivers/thermal/Makefile |1 +
 drivers/thermal/exynos_thermal.c |  413 
 include/linux/platform_data/exynos4_tmu.h|   83 
 include/linux/platform_data/exynos_thermal.h |   83 
 10 files changed, 556 insertions(+), 693 deletions(-)
 delete mode 100644 Documentation/hwmon/exynos4_tmu
 create mode 100644 Documentation/thermal/exynos_thermal
 delete mode 100644 drivers/hwmon/exynos4_tmu.c
 create mode 100644 drivers/thermal/exynos_thermal.c
 delete mode 100644 include/linux/platform_data/exynos4_tmu.h
 create mode 100644 include/linux/platform_data/exynos_thermal.h

diff --git a/Documentation/hwmon/exynos4_tmu b/Documentation/hwmon/exynos4_tmu
deleted file mode 100644
index c3c6b41..000
--- a/Documentation/hwmon/exynos4_tmu
+++ /dev/null
@@ -1,81 +0,0 @@
-Kernel driver exynos4_tmu
-=
-
-Supported chips:
-* ARM SAMSUNG EXYNOS4 series of SoC
-  Prefix: 'exynos4-tmu'
-  Datasheet: Not publicly available
-
-Authors: Donggeun Kim 
-
-Description

-
-This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
-
-The chip only exposes the measured 8-bit temperature code value
-through a register.
-Temperature can be taken from the temperature code.
-There are three equations converting from temperature to temperature code.
-
-The three equations are:
-  1. Two point trimming
-   Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1
-
-  2. One point trimming
-   Tc = T + TI1 - 25
-
-  3. No trimming
-   Tc = T + 50
-
-  Tc: Temperature code, T: Temperature,
-  TI1: Trimming info for 25 degree Celsius (stored at TRIMINFO register)
-   Temperature code measured at 25 degree Celsius which is unchanged
-  TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
-   Temperature code measured at 85 degree Celsius which is unchanged
-
-TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
-when temperature exceeds pre-defined levels.
-The maximum number of configurable threshold is four.
-The threshold levels are defined as follows:
-  Level_0: current temperature > trigger_level_0 + threshold
-  Level_1: current temperature > trigger_level_1 + threshold
-  Level_2: current temperature > trigger_level_2 + threshold
-  Level_3: current temperature > trigger_level_3 + threshold
-
-  The threshold and each trigger_level are set
-  through the corresponding registers.
-
-When an interrupt occurs, this driver notify user space of
-one of four threshold levels for the interrupt
-through kobject_uevent_env and sysfs_notify functions.
-Although an interrupt condition for level_0 can be set,
-it is not notified to user space through sysfs_notify function.
-
-Sysfs Interface

-name   name of the temperature sensor
-   RO
-
-temp1_inputtemperature
-   RO
-
-temp1_max  temperature for level_1 interrupt
-   RO
-
-temp1_crit temperature for level_2 interrupt
-   RO
-
-temp1_emergencytemperature for level_3 interrupt
-   RO
-
-temp1_max_alarmalarm for level_1 interrupt
-   RO
-
-temp1_crit_alarm
-   alarm for level_2 interrupt
-   RO
-
-temp1_emergency_alarm
-   alarm for level_3 interrupt
-   RO
diff --git a/Documentation/thermal/exynos_thermal 
b/Documentation/thermal/exynos_thermal
new file mode 100644
index 000..2b46f67
--- /dev/null
+++ b/Documentation/thermal/exynos_thermal
@@ -0,0 +1,52 @@
+Kernel driver exynos4_tmu
+=
+
+Supported chips:
+* ARM SAMSUNG EXYNOS4 series of SoC
+  Prefix: 'exynos4-tmu'
+  Datasheet: Not publicly available
+
+Authors: Donggeun Kim 
+
+Description
+---
+
+This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
+
+The chip only exposes the measured 8-bit temperature code value
+through a register.
+Temperature can be taken from the temperature code.
+There are three equations converting from temperature to temperature code.
+
+The three equations are:
+  1. Two point trimming
+   Tc = (T

[PATCH v6 0/6] thermal: Add kernel thermal support for exynos platform

[Amit Daniel Kachhap]

Hi Andrew/Zhang/Len,

This current patchset is based on 3.6-rc1 and Zhang Rui's core thermal
enhancement patches(http://permalink.gmane.org/gmane.linux.acpi.devel/54564).

Version V5 is present in linux-next tree. Since Zhang Rui's implementation are
already present in linux-next so requesting Andrew to add this V6 series and 
drop
earlier V5 version.

Changes since v5:
This patchset basically simplifies the cpufreq cooling API's to take just
cpumask as an input parameter and also removes the state management logic as 
they
are now taken care in the core thermal layer.

All these patches over Zhang Rui's work can be found in the git link
git://git.linaro.org/people/amitdanielk/linux.git exynos_v6_thermal_tree

Thanks,
Amit Daniel

Amit Daniel Kachhap (6):
  thermal: add generic cpufreq cooling implementation
  hwmon: exynos4: move thermal sensor driver to driver/thermal
directory
  thermal: exynos5: add exynos5250 thermal sensor driver support
  thermal: exynos: register the tmu sensor with the kernel thermal
layer
  ARM: exynos: add thermal sensor driver platform data support
  thermal: exynos: Use devm_* functions

 Documentation/hwmon/exynos4_tmu  |   81 ---
 Documentation/thermal/cpu-cooling-api.txt|   52 ++
 Documentation/thermal/exynos_thermal |   52 ++
 drivers/hwmon/Kconfig|   10 -
 drivers/hwmon/Makefile   |1 -
 drivers/hwmon/exynos4_tmu.c  |  518 --
 drivers/thermal/Kconfig  |   18 +
 drivers/thermal/Makefile |2 +
 drivers/thermal/cpu_cooling.c|  512 +
 drivers/thermal/exynos_thermal.c |  994 ++
 include/linux/cpu_cooling.h  |   79 ++
 include/linux/platform_data/exynos4_tmu.h|   83 ---
 include/linux/platform_data/exynos_thermal.h |  116 +++
 13 files changed, 1825 insertions(+), 693 deletions(-)
 delete mode 100644 Documentation/hwmon/exynos4_tmu
 create mode 100644 Documentation/thermal/cpu-cooling-api.txt
 create mode 100644 Documentation/thermal/exynos_thermal
 delete mode 100644 drivers/hwmon/exynos4_tmu.c
 create mode 100644 drivers/thermal/cpu_cooling.c
 create mode 100644 drivers/thermal/exynos_thermal.c
 create mode 100644 include/linux/cpu_cooling.h
 delete mode 100644 include/linux/platform_data/exynos4_tmu.h
 create mode 100644 include/linux/platform_data/exynos_thermal.h

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/6] thermal: add generic cpufreq cooling implementation

[Amit Daniel Kachhap]

This patchset introduces a new generic cooling device based on cpufreq
that can be used on non-ACPI platforms.  As a proof of concept, we have
drivers for the following platforms using this mechanism now:

 * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
 * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git 
imx6q_thermal)

There is a small change in cpufreq cooling registration APIs, so a minor
change is needed for Freescale platforms.

Brief Description:

1) The generic cooling devices code is placed inside driver/thermal/*
   as placing inside acpi folder will need un-necessary enabling of acpi
   code.  This code is architecture independent.

2) This patchset adds generic cpu cooling low level implementation
   through frequency clipping.  In future, other cpu related cooling
   devices may be added here.  An ACPI version of this already exists
   (drivers/acpi/processor_thermal.c) .But this will be useful for
   platforms like ARM using the generic thermal interface along with the
   generic cpu cooling devices.  The cooling device registration API's
   return cooling device pointers which can be easily binded with the
   thermal zone trip points.  The important APIs exposed are,

   a) struct thermal_cooling_device *cpufreq_cooling_register(
struct cpumask *clip_cpus)
   b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

3) Samsung exynos platform thermal implementation is done using the
   generic cpu cooling APIs and the new trip type.  The temperature sensor
   driver present in the hwmon folder(registered as hwmon driver) is moved
   to thermal folder and registered as a thermal driver.

A simple data/control flow diagrams is shown below,

Core Linux thermal <->  Exynos thermal interface <- Temperature Sensor
  | |
 \|/|
  Cpufreq cooling device <---

TODO:
*Will send the DT enablement patches later after the driver is merged.

This patch:

Add support for generic cpu thermal cooling low level implementations
using frequency scaling up/down based on the registration parameters.
Different cpu related cooling devices can be registered by the user and
the binding of these cooling devices to the corresponding trip points can
be easily done as the registration APIs return the cooling device pointer.
The user of these APIs are responsible for passing clipping frequency .
The drivers can also register to recieve notification about any cooling
action called.

[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Amit Daniel Kachhap 
Cc: Guenter Roeck 
Cc: SangWook Ju 
Cc: Durgadoss 
Cc: Len Brown 
Cc: Jean Delvare 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Amit Daniel Kachhap 
---
 Documentation/thermal/cpu-cooling-api.txt |   52 +++
 drivers/thermal/Kconfig   |   11 +
 drivers/thermal/Makefile  |1 +
 drivers/thermal/cpu_cooling.c |  512 +
 include/linux/cpu_cooling.h   |   79 +
 5 files changed, 655 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/thermal/cpu-cooling-api.txt
 create mode 100644 drivers/thermal/cpu_cooling.c
 create mode 100644 include/linux/cpu_cooling.h

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
new file mode 100644
index 000..a1f2a6b
--- /dev/null
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -0,0 +1,52 @@
+CPU cooling APIs How To
+===
+
+Written by Amit Daniel Kachhap 
+
+Updated: 12 May 2012
+
+Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
+
+0. Introduction
+
+The generic cpu cooling(freq clipping) provides registration/unregistration 
APIs
+to the caller. The binding of the cooling devices to the trip point is left for
+the user. The registration APIs returns the cooling device pointer.
+
+1. cpu cooling APIs
+
+1.1 cpufreq registration/unregistration APIs
+1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
+   struct cpumask *clip_cpus)
+
+This interface function registers the cpufreq cooling device with the name
+"thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+cooling devices.
+
+   clip_cpus: cpumask of cpus where the frequency constraints will happen.
+
+1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+
+This interface function unregisters the "thermal-cpufreq-%x" cooling 
device.
+
+cdev: Cooling device pointer which has to be unregistered.
+
+
+1.2 CPU cooling action notifier register/unregister interface
+1.2.1 int cputherm_register_notifier(struct notifier_block *nb,
+   unsigned int list)
+
+This interface registers a driver with cpu cooling layer. The driver will
+be notified when any cpu cooling action is called.
+
+nb: notifier function to r

[PATCH] ARM: EXYNOS: Add MFC device tree support

[Arun Kumar K]

From: Naveen Krishna Chatradhi 

This patch adds device tree entry for MFC in the Exynos
machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
MFC v6.x version. So making the required changes in the clock
files and adds MFC to the DT device list.

Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Arun Kumar K 
---
 .../devicetree/bindings/media/s5p-mfc.txt  |   24 
 arch/arm/boot/dts/exynos4210.dtsi  |   10 
 arch/arm/boot/dts/exynos5250.dtsi  |   10 
 arch/arm/mach-exynos/clock-exynos5.c   |2 +-
 arch/arm/mach-exynos/mach-exynos4-dt.c |   22 ++
 arch/arm/mach-exynos/mach-exynos5-dt.c |   22 ++
 6 files changed, 89 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..b9bd266
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,24 @@
+* Samsung Multi Format Codec (MFC)
+
+Mult Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
+
+Required properties:
+  - compatible : value should be either one among the following
+   (a) "samsung,s5p-mfc-v5" for MFC v5 present in Exynos4 SoCs
+   (b) "samsung,s5p-mfc-v6" for MFC v6.x present in Exynos5 SoCs
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : MFC interupt number to the CPU.
+
+  - samsung,mfc-r : Base address of the first memory bank used by MFC
+   for DMA contiguous memory allocation.
+
+  - samsung,mfc-r-size : Size of the first memory bank.
+
+  - samsung,mfc-l : Base address of the second memory bank used by MFC
+   for DMA contiguous memory allocation.
+
+  - samsung,mfc-l-size : Size of the second memory bank.
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..b5ee43d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -56,6 +56,16 @@
interrupts = <0 43 0>;
};
 
+   mfc {
+   compatible = "samsung,s5p-mfc";
+   reg = <0x1340 0x1>;
+   interrupts = <0 94 0>;
+   samsung,mfc-r = <0x4300>;
+   samsung,mfc-r-size = <8388608>;
+   samsung,mfc-l = <0x5100>;
+   samsung,mfc-l-size = <8388608>;
+   };
+
rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..3c762a4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,6 +58,16 @@
interrupts = <0 42 0>;
};
 
+   mfc {
+   compatible = "samsung,s5p-mfc-v6";
+   reg = <0x1100 0x1>;
+   interrupts = <0 96 0>;
+   samsung,mfc-r = <0x4300>;
+   samsung,mfc-r-size = <8388608>;
+   samsung,mfc-l = <0x5100>;
+   samsung,mfc-l-size = <8388608>;
+   };
+
rtc {
compatible = "samsung,s3c6410-rtc";
reg = <0x101E 0x100>;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..c85e7b2 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -607,7 +607,7 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 << 25),
}, {
.name   = "mfc",
-   .devname= "s5p-mfc",
+   .devname= "s5p-mfc-v6",
.enable = exynos5_clk_ip_mfc_ctrl,
.ctrlbit= (1 << 0),
}, {
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b2b5d5f..c4a0e16 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -63,6 +64,7 @@ static const struct of_dev_auxdata 
exynos4210_auxdata_lookup[] __initconst = {
"exynos4210-spi.2", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+   OF_DEV_AUXDATA("samsung,s5p-mfc", 0x1340, "s5p-mfc", NULL),
{},
 };
 
@@ -83,6 +85,25 @@ static char const *exynos4210_dt_compat[] __initdata = {
NULL
 };
 
+static void s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
+   phys_addr_t lbase, unsi

[PATCH] Add MFC device tree support

[Arun Kumar K]

This patch incorporates device tree support for the video codec
IP (MFC) present in Exynos series SoCs.
The driver side support for this will be posted as a separate
patch in the linux-media mailing list.

Naveen Krishna Chatradhi (1):
  ARM: EXYNOS: Add MFC device tree support

 .../devicetree/bindings/media/s5p-mfc.txt  |   24 
 arch/arm/boot/dts/exynos4210.dtsi  |   10 
 arch/arm/boot/dts/exynos5250.dtsi  |   10 
 arch/arm/mach-exynos/clock-exynos5.c   |2 +-
 arch/arm/mach-exynos/mach-exynos4-dt.c |   22 ++
 arch/arm/mach-exynos/mach-exynos5-dt.c |   22 ++
 6 files changed, 89 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unbalanced calls to spi_master_get in coldfire-qspi and s3c64xx SPI master drivers

[Thomas Abraham]

On 14 August 2012 03:14, Guenter Roeck  wrote:
> Hi all,
>
> looking through SPI master drivers, I noticed that the following drivers call
> spi_master_get() in their suspend and resume functions. Yet, there is no
> matching call to spi_master_put(), meaning the reference count will increase
> with each suspend/resume cycle.
> spi-coldfire-qspi.c
> spi-s3c64xx.c
> Other SPI master drivers also support suspend and resume, but do not call
> spi_master_get() in the suspend/resume functions. The spi-pl022 driver calls
> spi_master_suspend() and spi_master_resume() like the above, but does not
> call spi_master_get() either.
>
> This leads me to believe that the above drivers will hang on unload after a
> suspend/resume cycle due to the extra references.
>
> Can someone please have a look and confirm if my understanding is correct ?
> If so I'll send a set of patches to fix the problems.

For spi-s3c64xx.c, yes it does seem that the spi_master_get() and
spi_master_put() calls are not balanced.  The probable change could be

-  struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct spi_master *master = dev_get_drvdata(dev);

Thanks,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html