Re: [PATCH 3/3] ARM: dts: add Panel device support for exynos3250-rinato

[Inki Dae]

On 2014년 11월 28일 20:39, Inki Dae wrote:
> This patch adds MIPI-DSI and MIPI-DSI based S6E63J0X03 AMOLED panel
> device nodes for Exynos3250 Rinato board.

Hi Mr. Kukjin,

Please, ping~

Thanks,
Inki Dae

> 
> Signed-off-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos3250-rinato.dts |   59 
> +++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 79aa916..6e0e90d 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -125,6 +125,65 @@
>   };
>  };
>  
> +&dsi_0 {
> + vddcore-supply = <&ldo6_reg>;
> + vddio-supply = <&ldo6_reg>;
> + samsung,pll-clock-frequency = <2400>;
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + dsi_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + samsung,burst-clock-frequency = <25000>;
> + samsung,esc-clock-frequency = <2000>;
> + };
> + };
> + };
> +
> + panel@0 {
> + compatible = "samsung,s6e63j0x03";
> + reg = <0>;
> + vdd3-supply = <&ldo16_reg>;
> + vci-supply = <&ldo20_reg>;
> + reset-gpios = <&gpe0 1 0>;
> + te-gpios = <&gpx0 6 0>;
> + power-on-delay= <30>;
> + power-off-delay= <120>;
> + reset-delay = <5>;
> + init-delay = <100>;
> + flip-horizontal;
> + flip-vertical;
> + panel-width-mm = <29>;
> + panel-height-mm = <29>;
> +
> + display-timings {
> + timing-0 {
> + clock-frequency = <0>;
> + hactive = <320>;
> + vactive = <320>;
> + hfront-porch = <1>;
> + hback-porch = <1>;
> + hsync-len = <1>;
> + vfront-porch = <150>;
> + vback-porch = <1>;
> + vsync-len = <2>;
> + };
> + };
> +
> + port {
> + dsi_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
> +};
> +
>  &fimd {
>   status = "okay";
>  
> 

--
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/3] ARM: dts: add fimd device support for exynos3250-rinato

[Inki Dae]

On 2014년 11월 28일 20:39, Inki Dae wrote:
> This patch adds fimd device node which is a display controller
> for Exynos3250 Rinato board.

Hi Kukjin,

Please, ping~

Thanks,
Inki Dae

> 
> Signed-off-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos3250-rinato.dts |   11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 80aa8b4..79aa916 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -125,6 +125,17 @@
>   };
>  };
>  
> +&fimd {
> + status = "okay";
> +
> + i80-if-timings {
> + cs-setup = <0>;
> + wr-setup = <0>;
> + wr-act = <1>;
> + wr-hold = <0>;
> + };
> +};
> +
>  &i2c_0 {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 

--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Inki Dae]

On 2015년 01월 02일 22:14, Ajay kumar wrote:
> Hi Daniel,
> 
> This series is sitting out there since long without any ACKs.
> If people can ACK this series, I am ready to rebase and send ASAP.

Acked-by: Inki Dae 

And, for [PATCH V8 5/14] drm/exynos: dp: support drm_bridge,
Signed-off-by: Inki Dae 

Thanks,
Inki Dae

> 
> Regards,
> Ajay Kumar
> 
> On Fri, Jan 2, 2015 at 6:40 PM, Daniel Stone  wrote:
>> Hi Ajay,
>>
>> On 17 December 2014 at 09:31, Javier Martinez Canillas
>>  wrote:
>>>
>>> On 12/16/2014 12:37 AM, Laurent Pinchart wrote:
> You asked Ajay to change his series to use the video port and enpoints
> DT
> bindings instead of phandles, could you please review his latest
> version?
>
> I guess is now too late for 3.19 since we are in the middle of the
> merge
> window but it would be great if this series can at least made it to
> 3.20.

 I don't have time to review the series in details right now, but I'm
 happy
 with the DT bindings, and have no big issue with the rest of the
 patches. I
 don't really like the of_drm_find_bridge() concept introduced in 03/14
 but I
 won't nack it given lack of time to implement an alternative proposal.
 It's an
 internal API, it can always be reworked later anyway.
>>>
>>> Thanks a lot for taking the time to look at the DT bindings, then I guess
>>> that the series are finally ready to be merged?
>>>
>>> Ajay's series don't apply cleanly anymore because it has been a while
>>> since
>>> he posted it but he can rebase on top of 3.19-rc1 once it is released and
>>> re-resend.
>>
>>
>> Do you have any plans to rebase this so it's ready for merging?
>>
>> Thierry, Daniel, Dave - whose tree would this be best to merge through?
>>
>> Cheers,
>> Daniel
> --
> 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
> 

--
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] media: platform: s5p-jpeg: jpeg-hw-exynos4: Remove some unused functions

[Rickard Strandqvist]

Removes some functions that are not used anywhere:
exynos4_jpeg_set_timer_count() exynos4_jpeg_get_frame_size() 
exynos4_jpeg_set_sys_int_enable() exynos4_jpeg_get_fifo_status()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |   35 -
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h |5 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index ab6d6f4..5685577 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -163,15 +163,6 @@ unsigned int exynos4_jpeg_get_int_status(void __iomem 
*base)
return int_status;
 }
 
-unsigned int exynos4_jpeg_get_fifo_status(void __iomem *base)
-{
-   unsigned int fifo_status;
-
-   fifo_status = readl(base + EXYNOS4_FIFO_STATUS_REG);
-
-   return fifo_status;
-}
-
 void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value)
 {
unsigned intreg;
@@ -186,18 +177,6 @@ void exynos4_jpeg_set_huf_table_enable(void __iomem *base, 
int value)
base + EXYNOS4_JPEG_CNTL_REG);
 }
 
-void exynos4_jpeg_set_sys_int_enable(void __iomem *base, int value)
-{
-   unsigned intreg;
-
-   reg = readl(base + EXYNOS4_JPEG_CNTL_REG) & ~(EXYNOS4_SYS_INT_EN);
-
-   if (value == 1)
-   writel(reg | EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
-   else
-   writel(reg & ~EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
-}
-
 void exynos4_jpeg_set_stream_buf_address(void __iomem *base,
 unsigned int address)
 {
@@ -255,22 +234,8 @@ void exynos4_jpeg_set_dec_bitstream_size(void __iomem 
*base, unsigned int size)
writel(size, base + EXYNOS4_BITSTREAM_SIZE_REG);
 }
 
-void exynos4_jpeg_get_frame_size(void __iomem *base,
-   unsigned int *width, unsigned int *height)
-{
-   *width = (readl(base + EXYNOS4_DECODE_XY_SIZE_REG) &
-   EXYNOS4_DECODED_SIZE_MASK);
-   *height = (readl(base + EXYNOS4_DECODE_XY_SIZE_REG) >> 16) &
-   EXYNOS4_DECODED_SIZE_MASK;
-}
-
 unsigned int exynos4_jpeg_get_frame_fmt(void __iomem *base)
 {
return readl(base + EXYNOS4_DECODE_IMG_FMT_REG) &
EXYNOS4_JPEG_DECODED_IMG_FMT_MASK;
 }
-
-void exynos4_jpeg_set_timer_count(void __iomem *base, unsigned int size)
-{
-   writel(size, base + EXYNOS4_INT_TIMER_COUNT_REG);
-}
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
index c228d28..19690e4 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
@@ -21,7 +21,6 @@ void exynos4_jpeg_set_enc_tbl(void __iomem *base);
 void exynos4_jpeg_set_interrupt(void __iomem *base);
 unsigned int exynos4_jpeg_get_int_status(void __iomem *base);
 void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value);
-void exynos4_jpeg_set_sys_int_enable(void __iomem *base, int value);
 void exynos4_jpeg_set_stream_buf_address(void __iomem *base,
 unsigned int address);
 void exynos4_jpeg_set_stream_size(void __iomem *base,
@@ -33,10 +32,6 @@ void exynos4_jpeg_set_encode_tbl_select(void __iomem *base,
 void exynos4_jpeg_set_encode_hoff_cnt(void __iomem *base, unsigned int fmt);
 void exynos4_jpeg_set_dec_bitstream_size(void __iomem *base, unsigned int 
size);
 unsigned int exynos4_jpeg_get_stream_size(void __iomem *base);
-void exynos4_jpeg_get_frame_size(void __iomem *base,
-   unsigned int *width, unsigned int *height);
 unsigned int exynos4_jpeg_get_frame_fmt(void __iomem *base);
-unsigned int exynos4_jpeg_get_fifo_status(void __iomem *base);
-void exynos4_jpeg_set_timer_count(void __iomem *base, unsigned int size);
 
 #endif /* JPEG_HW_EXYNOS4_H_ */
-- 
1.7.10.4

--
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 v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
> On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
> > Odroid U3 fan can work without being registered as OF cooling device
> > (with CONFIG_THERMAL_OF disabled).
> > In this situation it can be controlled via PWM entry at
> > /sys/class/hwmon/hwmon0/pwm1.
> > 
> > Therefore, the thermal_of_cooling_device_register() function needs a stub
> > to allow clean compilation.
> > 
> > Signed-off-by: Lukasz Majewski 
> 
> Acked-by: Eduardo Valentin 

Sorry, too fast,

This is actually
Nacked-by: Eduardo Valentin 

:-)

I get this error:
drivers/thermal/thermal_core.c:1210:1: error: redefinition of
‘thermal_of_cooling_device_register’
 thermal_of_cooling_device_register(struct device_node *np,
  ^
  In file included from drivers/thermal/thermal_core.c:34:0:
  include/linux/thermal.h:321:1: note: previous definition of
  ‘thermal_of_cooling_device_register’ was here
   thermal_of_cooling_device_register(struct device_node *np,
^


We provide the function in thermal core even if CONFIG_THERMAL_OF is not
set.
> 
> > ---
> > Changes for v2:
> > - None
> > ---
> >  include/linux/thermal.h | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > index 2de3d9e..871123c 100644
> > --- a/include/linux/thermal.h
> > +++ b/include/linux/thermal.h
> > @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct device *dev, 
> > int id, void *data,
> > const struct thermal_zone_of_device_ops *ops);
> >  void thermal_zone_of_sensor_unregister(struct device *dev,
> >struct thermal_zone_device *tz);
> > +struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > +  char *type, void *devdata,
> > +  const struct thermal_cooling_device_ops *);
> >  #else
> >  static inline struct thermal_zone_device *
> >  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
> > @@ -342,6 +346,13 @@ void thermal_zone_of_sensor_unregister(struct device 
> > *dev,
> >  {
> >  }
> >  
> > +static inline struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > +  char *type, void *devdata,
> > +  const struct thermal_cooling_device_ops *ops)
> > +{
> > +   return NULL;
> > +}
> >  #endif
> >  struct thermal_zone_device *thermal_zone_device_register(const char *, 
> > int, int,
> > void *, struct thermal_zone_device_ops *,
> > @@ -357,9 +368,6 @@ void thermal_zone_device_update(struct 
> > thermal_zone_device *);
> >  
> >  struct thermal_cooling_device *thermal_cooling_device_register(char *, 
> > void *,
> > const struct thermal_cooling_device_ops *);
> > -struct thermal_cooling_device *
> > -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
> > -  const struct thermal_cooling_device_ops *);
> >  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
> >  struct thermal_zone_device *thermal_zone_get_zone_by_name(const char 
> > *name);
> >  int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
> > *temp);
> > -- 
> > 2.0.0.rc2
> > 




signature.asc
Description: Digital signature

Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
> Odroid U3 fan can work without being registered as OF cooling device
> (with CONFIG_THERMAL_OF disabled).
> In this situation it can be controlled via PWM entry at
> /sys/class/hwmon/hwmon0/pwm1.
> 
> Therefore, the thermal_of_cooling_device_register() function needs a stub
> to allow clean compilation.
> 
> Signed-off-by: Lukasz Majewski 

Acked-by: Eduardo Valentin 

> ---
> Changes for v2:
> - None
> ---
>  include/linux/thermal.h | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 2de3d9e..871123c 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct device *dev, int 
> id, void *data,
>   const struct thermal_zone_of_device_ops *ops);
>  void thermal_zone_of_sensor_unregister(struct device *dev,
>  struct thermal_zone_device *tz);
> +struct thermal_cooling_device *
> +thermal_of_cooling_device_register(struct device_node *np,
> +char *type, void *devdata,
> +const struct thermal_cooling_device_ops *);
>  #else
>  static inline struct thermal_zone_device *
>  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
> @@ -342,6 +346,13 @@ void thermal_zone_of_sensor_unregister(struct device 
> *dev,
>  {
>  }
>  
> +static inline struct thermal_cooling_device *
> +thermal_of_cooling_device_register(struct device_node *np,
> +char *type, void *devdata,
> +const struct thermal_cooling_device_ops *ops)
> +{
> + return NULL;
> +}
>  #endif
>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
> int,
>   void *, struct thermal_zone_device_ops *,
> @@ -357,9 +368,6 @@ void thermal_zone_device_update(struct 
> thermal_zone_device *);
>  
>  struct thermal_cooling_device *thermal_cooling_device_register(char *, void 
> *,
>   const struct thermal_cooling_device_ops *);
> -struct thermal_cooling_device *
> -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
> -const struct thermal_cooling_device_ops *);
>  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
>  struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
>  int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
> *temp);
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v2 5/8] hwmon: thermal: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

Patch subject should use a prefix like:
'arm: dts:'

On Mon, Dec 22, 2014 at 05:27:45PM +0100, Lukasz Majewski wrote:
> With those bindings it is possible to use pwm-fan device available in
> Odroid U3 as a cooling device.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Rename cooling-pwm-values property to cooling-levels
> ---
>  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 
> ++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 60bd1e4..380035d 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -32,11 +32,42 @@
>   };
>   };
>  
> - pwm-fan {
> + fan0: pwm-fan {
>   compatible = "pwm-fan";
>   pwms = <&pwm 0 1 0>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + cooling-levels = <0 102 170 255>;
>   status = "okay";
>   };
> +
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&cpu0 7 7>;
> + };
> + map1 {
> +  trip = <&cpu_alert2>;
> +  cooling-device = <&cpu0 13 13>;
> + };
> + map2 {
> +  trip = <&cpu_alert0>;
> +  cooling-device = <&fan0 0 1>;
> + };
> + map3 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&fan0 1 2>;
> + };
> + map4 {
> +  trip = <&cpu_alert2>;
> +  cooling-device = <&fan0 2 3>;
> + };
> + };
> + };
> + };
>  };
>  
>  &pwm {
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v2 3/8] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:43PM +0100, Lukasz Majewski wrote:
> Several new properties to allow PWM fan working as a cooling device have been
> combined into this single commit.
> 

Patch prefix should look something like 'dt-bindings: ...', or better
'Documentation: devicetree: ...', or 'Documentation: bindings: ...'

> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Rename cooling-pwm-values to cooling-levels
> - Remove default-pulse-width property and stick to default hwmon policy
> ---
>  .../devicetree/bindings/hwmon/pwm-fan.txt  | 23 
> ++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
> b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> index 610757c..001446a 100644
> --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> @@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
>  Required properties:
>  - compatible : "pwm-fan"
>  - pwms   : the PWM that is used to control the PWM fan
> +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
> + which correspond to thermal cooling states
> +
> +Thorough description of the following bindings:
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + thermal-zone {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&fan0 0 1>;
> + };
> + };
> + };
> +
> +for PWM FAN used as cooling device can be found at:
> +./Documentation/devicetree/bindings/thermal/thermal.txt
>  
>  Example:
>   pwm-fan {
>   compatible = "pwm-fan";
>   status = "okay";
>   pwms = <&pwm 0 1 0>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + cooling-levels = <0 102 170 255>;
>   };
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v2 2/8] thermal: Provide stub for thermal_cdev_update() function

[Eduardo Valentin]

On Mon, Dec 22, 2014 at 05:27:42PM +0100, Lukasz Majewski wrote:
> Odroid U3 fan can work without being registered as OF cooling device
> (with CONFIG_THERMAL_OF disabled).
> In this situation it can be controlled via PWM entry at
> /sys/class/hwmon/hwmon0/pwm1.
> 
> Therefore, the thermal_cdev_update() function needs a stub
> to allow clean compilation.

I am not sure I understand what you are attempting to do here. What is
the relation that you see between CONFIG_OF_THERMAL and
thermal_cdev_update? 

> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - New patch
> ---
>  include/linux/thermal.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 871123c..b3515b5 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -332,6 +332,7 @@ struct thermal_cooling_device *
>  thermal_of_cooling_device_register(struct device_node *np,
>  char *type, void *devdata,
>  const struct thermal_cooling_device_ops *);
> +void thermal_cdev_update(struct thermal_cooling_device *);
>  #else
>  static inline struct thermal_zone_device *
>  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
> @@ -353,6 +354,10 @@ thermal_of_cooling_device_register(struct device_node 
> *np,
>  {
>   return NULL;
>  }
> +
> +static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
> +{
> +}
>  #endif
>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
> int,
>   void *, struct thermal_zone_device_ops *,
> @@ -375,7 +380,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
> unsigned long *temp);
>  int get_tz_trend(struct thermal_zone_device *, int);
>  struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
>   struct thermal_cooling_device *, int);
> -void thermal_cdev_update(struct thermal_cooling_device *);
>  void thermal_notify_framework(struct thermal_zone_device *, int);
>  
>  #ifdef CONFIG_NET
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v2 08/17] thermal: exynos: dts: Add default definition of the TMU sensor parameter

[Eduardo Valentin]

On Fri, Jan 02, 2015 at 02:11:41PM -0400, Eduardo Valentin wrote:
> Lukasz,
> 
> On Wed, Dec 10, 2014 at 01:09:47PM +0100, Lukasz Majewski wrote:
> > Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure 
> > the
> > on chip temperature. For this reason it is possible to group TMU 
> > configuration
> > parameters in one dts file.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - None
> > ---
> >  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 
> > +++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> > 
> > diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi 
> > b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> > new file mode 100644
> > index 000..ee6d8bb
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> > @@ -0,0 +1,24 @@
> > +/*
> > + * Device tree sources for Exynos4412 TMU sensor configuration
> > + *
> > + * Copyright (c) 2014 Lukasz Majewski 
> > + *
> > + * 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.
> > + *
> > + */
> > +
> > +#include 
> > +
> > +#thermal-sensor-cells = <0>;
> > +gain = <8>;
> > +reference_voltage = <16>;
> > +noise_cancel_mode = <4>;
> > +efuse_value = <55>;
> > +min_efuse_value = <40>;
> > +max_efuse_value = <100>;
> > +first_point_trim = <25>;
> > +second_point_trim = <85>;
> > +default_temp_offset = <50>;
> > +cal_type = ;
> 
> Are the above properties specific to exynos? For specific DT entries,
> they need to be marked with a prefix. Please read the 'Device Specific
> Data' section of Device tree Documentation [1].
> 
> [1] - http://devicetree.org/Device_Tree_Usage


BTW, you have to update:
Documentation/devicetree/bindings/thermal/exynos-thermal.txt


> > -- 
> > 2.0.0.rc2
> > 




signature.asc
Description: Digital signature

Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree

[Eduardo Valentin]

Lukasz,

On Wed, Dec 10, 2014 at 01:09:39PM +0100, Lukasz Majewski wrote:
> 1. Introduction
> 
> Following patches aim to clean up the current implementation of the thermal
> framework on Exynos devices.
> 
> The main goal was to use a generic code for reading thermal configuration
> (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files
> were removed.
> 
> Around 400 lines of code (LOC) were removed directly by this patch, which
> is around 20% of the Exynos thermal code base.
> 
> This work should NOT bring any functional changes to Exynos thermal 
> subsystem.
> 
> 2. Patch-set structure
> 
> Then the cpu_cooling functionality has been preserved to allow cooling
> devices by reducing operating frequency. Definition of trip points and
> cpufreq's cooling properties were moved to device tree.
> 
> Then the rework of the way in which configuration data is provided to
> the Exynos thermal subsystem was performed. Now device tree is used for
> configuration.
> 
> Patch series end with removing exynos5250/exynos3250 TMU compatibles.
> Both SoCs have thermal management unit (TMU) compatible with the one first 
> introduced at Exynos4412.
> 
> 3. Dead code removal
> 
> Thermal support for some SoCs, previously available in the exynos_tmu_data.c 
> file, was removed since, as of (almost) 3.19-rc1, they didn't have TMU 
> bindings.
> 
> Moreover, support for cpu_cooling devices was preserved only on those
> SoCs which had available and working cpufreq driver.
> 
> 4. Testing
> 
> Test devices:
> - Exynos4210 - Trats (TMU zone + cpu_cooling)
> - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling)
> - Exynos5250 - Arndale (TMU zone + cpu_cooling)
> - Exynos5420 - Arndale-octa (only TMU zones)
> 
> Unfortunately, I don't posses Exynos5440 for testing. Its functionality
> has been preserved in the code, but not tested on the hardware. I would
> be grateful for help in testing.
> 
> 5. This work apply on the following tree:
> 
> kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree
> SHA1: c42c7a44c7a543dcb388c1ee1a798e6ed76ad8cf
> 
> 
> Lukasz Majewski (17):
>   thermal: exynos: cosmetic: Correct comment format
>   thermal: exynos: Provide thermal_exynos.h file to be included in
> device tree files
>   thermal: dts: trats: Enable TMU on the Exynos4210 trats device
>   thermal: dts: exynos: Add LD010 regulator node necessary for TMU on
> Odroid
>   thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device
>   thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu
> cooling functionality
>   thermal: cpu_cooling: Modify exynos thermal code to use device tree
> for cpu cooling configuration
>   thermal: exynos: dts: Add default definition of the TMU sensor
> parameter
>   thermal: dts: Default trip points definition for Exynos5420 SoCs
>   thermal: exynos: dts: Define default thermal-zones for Exynos4
>   thermal: dts: exynos: Trip points and sensor configuration data for
> Exynos5440
>   thermal: exynos: dts: Provide device tree bindings identical to one in
> exynos_tmu_data.c
>   thermal: samsung: core: Exynos TMU rework to use device tree for
> configuration
>   thermal: exynos: Remove exynos_thermal_common.[c|h] files
>   thermal: exynos: Remove exynos_tmu_data.c file
>   thermal: exynos: Make Exynos5250 TMU compatible with Exynos4412
>   thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412
> 
>  arch/arm/boot/dts/exynos3250.dtsi |   6 +-
>  arch/arm/boot/dts/exynos4-cpu-thermal.dtsi|  52 +++
>  arch/arm/boot/dts/exynos4.dtsi|   5 +
>  arch/arm/boot/dts/exynos4210-trats.dts|  19 +
>  arch/arm/boot/dts/exynos4210.dtsi |  43 ++-
>  arch/arm/boot/dts/exynos4212.dtsi |  20 +
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi   |  27 ++
>  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi |  24 ++
>  arch/arm/boot/dts/exynos4412-trats2.dts   |  15 +
>  arch/arm/boot/dts/exynos4412.dtsi |  32 ++
>  arch/arm/boot/dts/exynos4x12.dtsi |   3 +
>  arch/arm/boot/dts/exynos5250.dtsi |  29 +-
>  arch/arm/boot/dts/exynos5420-trip-points.dtsi |  35 ++
>  arch/arm/boot/dts/exynos5420.dtsi |  33 ++
>  arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi |  25 ++
>  arch/arm/boot/dts/exynos5440-trip-points.dtsi |  25 ++
>  arch/arm/boot/dts/exynos5440.dtsi |  18 +
>  drivers/cpufreq/exynos-cpufreq.c  |  23 +-
>  drivers/thermal/samsung/Makefile  |   2 -
>  drivers/thermal/samsung/exynos_thermal_common.c   | 427 
> --
>  drivers/thermal/samsung/exynos_thermal_common.h   | 106 --
>  drivers/thermal/samsung/exynos_tmu.c  | 337 ++---
>  drivers/thermal/samsung/exynos_tmu.h  |  80 +---
>  drivers/thermal/samsung/exynos_tmu_data.c | 264 -
>  include/dt-bindings/

Re: [PATCH v2 07/17] thermal: cpu_cooling: Modify exynos thermal code to use device tree for cpu cooling configuration

[Eduardo Valentin]

On Wed, Dec 10, 2014 at 01:09:46PM +0100, Lukasz Majewski wrote:
> Up till now exynos_tmu_data.c was used for storing CPU cooling configuration
> data. Now the Exynos thermal core code uses device tree to get this data.
> For this purpose generic thermal code for configuring CPU cooling was
> used.

Title prefix also does not help here, I would use 'thermal: exynos: '

> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - None
> ---
>  drivers/cpufreq/exynos-cpufreq.c|  23 -
>  drivers/thermal/samsung/exynos_thermal_common.c | 122 
> ++--
>  drivers/thermal/samsung/exynos_tmu.c|   7 --
>  drivers/thermal/samsung/exynos_tmu.h|   5 -
>  drivers/thermal/samsung/exynos_tmu_data.c   |  42 +---
>  5 files changed, 94 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/cpufreq/exynos-cpufreq.c 
> b/drivers/cpufreq/exynos-cpufreq.c
> index 1e0ec57..fdedb8d 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -18,10 +18,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "exynos-cpufreq.h"
>  
>  static struct exynos_dvfs_info *exynos_info;
> +static struct thermal_cooling_device *cdev;
>  static struct regulator *arm_regulator;
>  static unsigned int locking_frequency;
>  
> @@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
>  
>  static int exynos_cpufreq_probe(struct platform_device *pdev)
>  {
> + struct device_node *np;
>   int ret = -EINVAL;
>  
>   exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> @@ -198,9 +202,24 @@ static int exynos_cpufreq_probe(struct platform_device 
> *pdev)
>   /* Done here as we want to capture boot frequency */
>   locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
>  
> - if (!cpufreq_register_driver(&exynos_driver))
> - return 0;
> + if (cpufreq_register_driver(&exynos_driver))
> + goto err;
>  
> + np = of_find_node_by_path("/cpus/cpu@0");
> + if (!np) {
> + pr_err("failed to find cpu0 node\n");
> + return -ENOENT;
> + }
> + if (of_find_property(np, "#cooling-cells", NULL)) {
> + cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
> + if (IS_ERR(cdev))
> + pr_err("running cpufreq without cooling device: %ld\n",
> +PTR_ERR(cdev));
> + }
> + of_node_put(np);
> +
> + return 0;
> + err:
>   dev_err(&pdev->dev, "failed to register cpufreq driver\n");
>   regulator_put(arm_regulator);
>  err_vdd_arm:
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 6dc3815..00aa688 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -133,47 +133,62 @@ static int exynos_get_crit_temp(struct 
> thermal_zone_device *thermal,
>  static int exynos_bind(struct thermal_zone_device *thermal,
>   struct thermal_cooling_device *cdev)
>  {
> - int ret = 0, i, tab_size, level;
> - struct freq_clip_table *tab_ptr, *clip_data;
>   struct exynos_thermal_zone *th_zone = thermal->devdata;
>   struct thermal_sensor_conf *data = th_zone->sensor_conf;
> + struct device_node *child, *gchild, *np;
> + struct of_phandle_args cooling_spec;
> + unsigned long max, state = 0;
> + int ret = 0, i = 0;
>  
> - tab_ptr = (struct freq_clip_table *)data->cooling_data.freq_data;
> - tab_size = data->cooling_data.freq_clip_count;
> -
> - if (tab_ptr == NULL || tab_size == 0)
> + /*
> +  * Below code is necessary to skip binding when cpufreq's
> +  * frequency table is not yet initialized.
> +  */
> + cdev->ops->get_max_state(cdev, &state);
> + if (!state && !th_zone->cool_dev_size) {
> + th_zone->cool_dev_size = 1;
> + th_zone->cool_dev[0] = cdev;
> + th_zone->bind = false;
>   return 0;
> + }
>  
> - /* find the cooling device registered*/
> - for (i = 0; i < th_zone->cool_dev_size; i++)
> - if (cdev == th_zone->cool_dev[i])
> - break;
> + np = of_find_node_by_path("/thermal-zones/cpu-thermal");
> + if (!np) {
> + pr_err("failed to find thmerla-zones/cpu-thermal node\n");
> + return -ENOENT;
> + }
>  
> - /* No matching cooling device */
> - if (i == th_zone->cool_dev_size)
> - return 0;
> + child = of_get_child_by_name(np, "cooling-maps");
>  
> - /* Bind the thermal zone to the cpufreq cooling device */
> - for (i = 0; i < tab_size; i++) {
> - clip_data = (struct freq_clip_table *)&(tab_ptr[i]);
> - level = cpufreq_cooling_get_level(0, clip_data->freq_clip_max);
> - if (level == THERMAL_CSTATE_INVALID)
> -   

Re: [PATCH v2 06/17] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality

[Eduardo Valentin]

On Wed, Dec 10, 2014 at 01:09:45PM +0100, Lukasz Majewski wrote:
> Presented patch aims to move data necessary for correct CPU cooling device
> configuration from exynos_tmu_data.c to device tree.

I believe the patch title is misleading. Looks like you are changing
something at cpu cooling, but in fact, you are changing DTS files. I
would suggest you to use a prefix like 'arm: dts: '

> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - None
> ---
>  arch/arm/boot/dts/exynos4210-trats.dts  | 15 
>  arch/arm/boot/dts/exynos4210.dtsi   | 20 
>  arch/arm/boot/dts/exynos4212.dtsi   | 20 
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 15 
>  arch/arm/boot/dts/exynos4412.dtsi   | 32 
> +
>  arch/arm/boot/dts/exynos5250.dtsi   | 20 +++-
>  7 files changed, 136 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
> b/arch/arm/boot/dts/exynos4210-trats.dts
> index b59019c..d9dd9a7 100644
> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> @@ -428,6 +428,21 @@
>   status = "okay";
>   };
>  
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> + /* Corresponds to 800MHz at freq_table */
> + cooling-device = <&cpu0 2 2>;
> + };
> + map1 {
> +/* Corresponds to 200MHz at freq_table */
> +cooling-device = <&cpu0 4 4>;
> +};
> +};
> + };
> + };
> +
>   camera {
>   pinctrl-names = "default";
>   pinctrl-0 = <>;
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 807bb5b..10e8915 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -41,6 +41,26 @@
>   #clock-cells = <1>;
>   };
>  
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0x900>;
> + cooling-min-level = <4>;
> + cooling-max-level = <2>;
> + #cooling-cells = <2>; /* min followed by max */
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0x901>;
> + };
> + };
> +
>   sysram@0202 {
>   compatible = "mmio-sram";
>   reg = <0x0202 0x2>;
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
> b/arch/arm/boot/dts/exynos4212.dtsi
> index 3c00e6e..6405954 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -22,6 +22,26 @@
>  / {
>   compatible = "samsung,exynos4212", "samsung,exynos4";
>  
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA00>;
> + cooling-min-level = <13>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max */
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA01>;
> + };
> + };
> +
>   combiner: interrupt-controller@1044 {
>   samsung,combiner-nr = <18>;
>   };
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index eb1c08c..15d45f0 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -375,6 +375,21 @@
>   vtmu-supply = <&ldo10_reg>;
>   status = "okay";
>   };
> +
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> + /* Corresponds to 800MHz at freq_table */
> + cooling-device = <&cpu0 7 7>;
> + };
> + map1 {
> +/* Corresponds to 200MHz at freq_table */
> +cooling-device = <&cpu0 13 13>;
> +  

Re: [PATCH v2 12/17] thermal: exynos: dts: Provide device tree bindings identical to one in exynos_tmu_data.c

[Eduardo Valentin]

Lukasz

On Wed, Dec 10, 2014 at 01:09:51PM +0100, Lukasz Majewski wrote:
> Presented device tree bindings provide data already hardcoded in the
> exynos_tmu_data.c file.
> After this commit, it should be possible to reuse common thermal core
> framework in Exynos SoCs.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Add proper TMU entries for exynos3250.dtsi
> ---
>  arch/arm/boot/dts/exynos3250.dtsi |  4 
>  arch/arm/boot/dts/exynos4.dtsi|  5 +
>  arch/arm/boot/dts/exynos4210.dtsi | 23 ++-
>  arch/arm/boot/dts/exynos4x12.dtsi |  3 +++
>  arch/arm/boot/dts/exynos5250.dtsi |  7 +--
>  arch/arm/boot/dts/exynos5420.dtsi | 33 +
>  arch/arm/boot/dts/exynos5440.dtsi | 18 ++
>  7 files changed, 90 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 693a327..6edfa76 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -18,7 +18,9 @@
>   */
>  
>  #include "skeleton.dtsi"
> +#include "exynos4-cpu-thermal.dtsi"
>  #include 
> +#include 
>  
>  / {
>   compatible = "samsung,exynos3250";
> @@ -188,6 +190,8 @@
>   interrupts = <0 216 0>;
>   clocks = <&cmu CLK_TMU_APBIF>;
>   clock-names = "tmu_apbif";
> + type = ;

Why do we need a 'type' property here? Can't we reuse compatible?

> + #include "exynos4412-tmu-sensor-conf.dtsi"
>   status = "disabled";
>   };
>  
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index e0278ec..1735bb3 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "skeleton.dtsi"
>  
>  / {
> @@ -645,4 +646,8 @@
>   samsung,sysreg = <&sys_reg>;
>   status = "disabled";
>   };
> +
> + tmu: tmu@100C {
> + #include "exynos4412-tmu-sensor-conf.dtsi"
> + };
>  };
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 10e8915..1c52681 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -21,6 +21,8 @@
>  
>  #include "exynos4.dtsi"
>  #include "exynos4210-pinctrl.dtsi"
> +#include "exynos4-cpu-thermal.dtsi"
> +#include 
>  
>  / {
>   compatible = "samsung,exynos4210", "samsung,exynos4";
> @@ -146,16 +148,35 @@
>   reg = <0x0386 0x1000>;
>   };
>  
> - tmu@100C {
> + tmu: tmu@100C {
>   compatible = "samsung,exynos4210-tmu";
>   interrupt-parent = <&combiner>;
>   reg = <0x100C 0x100>;
>   interrupts = <2 4>;
>   clocks = <&clock CLK_TMU_APBIF>;
>   clock-names = "tmu_apbif";
> + gain = <15>;
> + reference_voltage = <7>;
> + type = ;
>   status = "disabled";
>   };
>  
> + thermal-zones {
> + cpu_thermal: cpu-thermal {
> + trips {
> +   cpu_alert0: cpu-alert-0 {
> +   temperature = <85000>; /* millicelsius */
> +   };
> +   cpu_alert1: cpu-alert-1 {
> +   temperature = <10>; /* millicelsius */
> +   };
> +   cpu_alert2: cpu-alert-2 {
> +   temperature = <11>; /* millicelsius */
> +   };
> + };
> + };
> + };
> +
>   g2d@1280 {
>   compatible = "samsung,s5pv210-g2d";
>   reg = <0x1280 0x1000>;
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 2e9f1f7..ee24d83 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -19,6 +19,8 @@
>  
>  #include "exynos4.dtsi"
>  #include "exynos4x12-pinctrl.dtsi"
> +#include "exynos4-cpu-thermal.dtsi"
> +#include 
>  
>  / {
>   aliases {
> @@ -279,6 +281,7 @@
>   reg = <0x100C 0x100>;
>   clocks = <&clock 383>;
>   clock-names = "tmu_apbif";
> + type = ;
>   status = "disabled";
>   };
>  };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index a5bbc1a..2167394 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -20,8 +20,9 @@
>  #include 
>  #include "exynos5.dtsi"
>  #include "exynos5250-pinctrl.dtsi"
> -
> +#include "exynos4-cpu-thermal.dtsi"
>  #include 
> +#include 
>  
>  / {
>   compatible = "samsung,exynos5250", "samsung,exynos5";
> @@ -236,12 +237,14 @@
>   status = "disabl

Re: [PATCH v2 08/17] thermal: exynos: dts: Add default definition of the TMU sensor parameter

[Eduardo Valentin]

Lukasz,

On Wed, Dec 10, 2014 at 01:09:47PM +0100, Lukasz Majewski wrote:
> Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure the
> on chip temperature. For this reason it is possible to group TMU configuration
> parameters in one dts file.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - None
> ---
>  arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 
> +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi 
> b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> new file mode 100644
> index 000..ee6d8bb
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> @@ -0,0 +1,24 @@
> +/*
> + * Device tree sources for Exynos4412 TMU sensor configuration
> + *
> + * Copyright (c) 2014 Lukasz Majewski 
> + *
> + * 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.
> + *
> + */
> +
> +#include 
> +
> +#thermal-sensor-cells = <0>;
> +gain = <8>;
> +reference_voltage = <16>;
> +noise_cancel_mode = <4>;
> +efuse_value = <55>;
> +min_efuse_value = <40>;
> +max_efuse_value = <100>;
> +first_point_trim = <25>;
> +second_point_trim = <85>;
> +default_temp_offset = <50>;
> +cal_type = ;

Are the above properties specific to exynos? For specific DT entries,
they need to be marked with a prefix. Please read the 'Device Specific
Data' section of Device tree Documentation [1].

[1] - http://devicetree.org/Device_Tree_Usage
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Nishanth Menon]

On 01/02/2015 02:55 AM, Tomasz Figa wrote:
> On 30.12.2014 03:23, Nishanth Menon wrote:
>> On 12/23/2014 04:48 AM, Marek Szyprowski wrote:
>>
>>> -static void l2c310_resume(void)
>>> +static void l2c310_configure(void __iomem *base)
>>>   {
>>> -   void __iomem *base = l2x0_base;
>>> +   unsigned revision;
>>>
>>> -   if (!(readl_relaxed(base + L2X0_CTRL) & L2X0_CTRL_EN)) {
>>> -   unsigned revision;
>>> -
>>> -   /* restore pl310 setup */
>>> -   writel_relaxed(l2x0_saved_regs.tag_latency,
>>> -  base + L310_TAG_LATENCY_CTRL);
>>> -   writel_relaxed(l2x0_saved_regs.data_latency,
>>> -  base + L310_DATA_LATENCY_CTRL);
>>> -   writel_relaxed(l2x0_saved_regs.filter_end,
>>> -  base + L310_ADDR_FILTER_END);
>>> -   writel_relaxed(l2x0_saved_regs.filter_start,
>>> -  base + L310_ADDR_FILTER_START);
>>> -
>>> -   revision = readl_relaxed(base + L2X0_CACHE_ID) &
>>> -   L2X0_CACHE_ID_RTL_MASK;
>>> -
>>> -   if (revision >= L310_CACHE_ID_RTL_R2P0)
>>> -   l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
>>> - L310_PREFETCH_CTRL);
>>> -   if (revision >= L310_CACHE_ID_RTL_R3P0)
>>> -   l2c_write_sec(l2x0_saved_regs.pwr_ctrl, base,
>>> - L310_POWER_CTRL);
>>> -
>>> -   l2c_enable(base, l2x0_saved_regs.aux_ctrl, 8);
>>> -
>>> -   /* Re-enable full-line-of-zeros for Cortex-A9 */
>>> -   if (l2x0_saved_regs.aux_ctrl & L310_AUX_CTRL_FULL_LINE_ZERO)
>>> -   set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
>>> -   }
>>> +   /* restore pl310 setup */
>>> +   writel_relaxed(l2x0_saved_regs.tag_latency,
>>> +  base + L310_TAG_LATENCY_CTRL);
>>> +   writel_relaxed(l2x0_saved_regs.data_latency,
>>> +  base + L310_DATA_LATENCY_CTRL);
>>> +   writel_relaxed(l2x0_saved_regs.filter_end,
>>> +  base + L310_ADDR_FILTER_END);
>>> +   writel_relaxed(l2x0_saved_regs.filter_start,
>>> +  base + L310_ADDR_FILTER_START);
>>> +
>>
>> ^^ The above change broke AM437xx. Looks like the change causes the
>> following behavior difference on AM437x. For some reason, touching any
>> of the above 4 registers(even with the values read from the same
>> registers) causes AM437x to go beserk. Comment the 4 writes and we
>> reach shell. looks like l2c310_resume is not invoked prior to this
>> series. :(.. now that we reuse that logic to actually do programming,
>> we start to see the problem.
> 
> OK, I probably have answer for this. Apparently all four register above 
> cannot be written in non-secure mode and they should go through 
> l2c_write_sec(). More on this can be found in CoreLink Level 2 Cache 
> Controller L2C-310 Technical Reference Manual, 3.2. Register summary, 
> table 3.1. I have checked the TRM for r3p3, but I guess this should be 
> uniform for all revisions.

Yep, you seemed to have caught the issue correctly.

> 
> Why this worked before? The registers were not written unless respective 
> properties in DT were present and OMAP do not have them in DT. Current 
> code always writes them, which should not really matter if the code is 
> correct. (But it isn't - writel_relaxed() can't be used directly for 
> those registers.)
> 
> Could you check if replacing those four writel_relaxed() with 
> l2c_write_sec() does the thing?

Considering that
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap4-common.c#n169
has no implementation of DATA,TAG_LATENCY, FILTER_*
I did a few patches for those - separate from this series and posted
(v2 of the series):
https://patchwork.kernel.org/patch/5560231/
https://patchwork.kernel.org/patch/5560211/

Anyways, l2c_write_sec will refuse to write if the read value is same
as requested value - that is exactly what we want here. So, for
testing, I hacked it and remove the check to force the writes
(http://slexy.org/view/s2p8c3gl32)

The replaced raw_writels with secure writes(fix needed for this
patch): http://slexy.org/view/s21PbM73tt

(with secure writes, my patches and force write hack applied):
 1: am437x-sk: BOOT: PASS: http://slexy.org/raw/s2BxqX5NOz
 2: am43xx-epos: BOOT: PASS: http://slexy.org/raw/s2VkKYuYed
 3: am43xx-gpevm: BOOT: PASS: http://slexy.org/raw/s2kO95WSuY
 4: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s21sx5gmUl
 5: pandaboard-vanilla: BOOT: PASS: http://slexy.org/raw/s21lpUJK6r
 6: sdp4430: BOOT: PASS: http://slexy.org/raw/s21UVKHle5


(with just secure writes and none of my patches or hacks applied):
 1: am437x-sk: BOOT: PASS: http://slexy.org/raw/s21UxoDdo5
 2: am43xx-epos: BOOT: PASS: http://slexy.org/raw/s2ECrLZ1FH
 3: am43xx-gpevm: BOOT: PASS: http://slexy.org/raw/s2CowTVA9P
 4: pandaboard-es: BOOT: PASS: http://slexy.org/raw/s205MVIWf0
 5: p

Re: [PATCH v3 1/4] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

[Doug Anderson]

Alim,

On Tue, Dec 30, 2014 at 10:43 PM, Alim Akhtar  wrote:
> From: Seungwon Jeon 
>
> ciu_div may not be common value for all speed mode.
> So, it needs to be attached to CLKSEL timing.

The more time I've spent looking at all of this stuff the less I like
the exynos bindings.  Personally I'd prefer to see the exynos bindings
fixed rather than go further down the path of these bindings.

Specifically:

1. The "drive" really should be specified quite differently.
According to the DesignWare docs, the "drive" phase is there to meet
hold time requirements.  Hold time requirements are different for
different SD/MMC modes and are specified in nanoseconds (SDR104 is
.8ns, ID mode is 5.0ns).  There is a per-SoC parameter needed that
indicates some built-in delay (in nanoseconds) and that shouldn't
change based on clock speed or card mode.

2. The ciu_div really ought to be automatic.  Start out at a divide by
4.  If you end up with both drive and sample at phases of 0, 90, 180,
270 then you can change to divide by 2.

I still haven't looked at every last detail of these delays though, so
please correct me if I'm wrong.  I've added Alex who may have looked
at this more than I have.


With all of the above, there's also the fact that (I think) we should
be moving towards working with the clock phase API since all of your
values are effectively specifying clock phases, just in a very arcane
way.


> This also introduce a new compatibale 'dw-mshc-hs200-timing'
> for selecting hs200 timing value

As per above, I don't think this is needed.


> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> ---
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   15 ++--
>  drivers/mmc/host/dw_mmc-exynos.c   |   81 
> ++--
>  drivers/mmc/host/dw_mmc-exynos.h   |1 +
>  3 files changed, 67 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index ee4fc05..06455de 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -23,10 +23,6 @@ Required Properties:
> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>   specific extensions having an SMU.
>
> -* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
> -  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
> -  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
> -
>  * samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift 
> value
>in transmit mode and CIU clock phase shift value in receive mode for single
>data rate mode operation. Refer notes below for the order of the cells and 
> the
> @@ -37,11 +33,16 @@ Required Properties:
>data rate mode operation. Refer notes below for the order of the cells and 
> the
>valid values.
>
> +* samsung,dw-mshc-hs200-timing: Similar with dw-mshc-sdr-timing.
> +
>Notes for the sdr-timing and ddr-timing values:
>
>  The order of the cells should be
>- First Cell: CIU clock phase shift value for tx mode.
>- Second Cell: CIU clock phase shift value for rx mode.
> +  - Thrid Cell: Specifies the divider value for the card interface
> +unit (ciu) clock. This property is applicable only for Exynos5 SoC's 
> and
> +ignored for Exynos4 SoC's. The valid range of divider value is 0 to 
> 7.
>
>  Valid values for SDR and DDR CIU clock timing for Exynos5250:
>- valid value for tx phase shift and rx phase shift is 0 to 7.
> @@ -79,8 +80,8 @@ Example:
> broken-cd;
> fifo-depth = <0x80>;
> card-detect-delay = <200>;
> -   samsung,dw-mshc-ciu-div = <3>;
> -   samsung,dw-mshc-sdr-timing = <2 3>;
> -   samsung,dw-mshc-ddr-timing = <1 2>;
> +   samsung,dw-mshc-sdr-timing = <2 3 3>;
> +   samsung,dw-mshc-ddr-timing = <1 2 3>;
> +   samsung,dw-mshc-hs200-timing = <0 2 3>;

You are breaking backward compatibility here.  If your change is
merged then all old boards will instantly break.  Since the "dts" and
code changes will likely be merged through different trees you'll end
up with a bunch of broken trees until everything is merged together.
Even if you don't subscribe to the stable bindings theory this is not
acceptable.

-Doug
--
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 RESEND] ARM: exynos_defconfig: Enable options for display panel support

[Javier Martinez Canillas]

Many Exynos devices have a display panel. Most of them just have
a simple panel while others have more complex configurations that
requires an embedded DisplayPort (eDP) to LVDS bridges.

This patch enables the following features to be built in the kernel
image to support both setups:

- Direct Rendering Manager (DRM)
- DRM bridge registration and lookup framework
- Parade ps8622/ps8625 eDP/LVDS bridge
- NXP ptn3460 eDP/LVDS bridge
- Exynos Fully Interactive Mobile Display controller (FIMD)
- Panel registration and lookup framework
- Simple panels
- Backlight & LCD device support

Signed-off-by: Javier Martinez Canillas 
Tested-by: Kevin Hilman 
Signed-off-by: Kukjin Kim 
---

Hello Kukjin,

You dropped this patch since exynos drm was causing boot hangs on some
platforms but the fix for that issue is already in linux-next (commit:
f1e9203 clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable
failure due to domain being gated) so I think it makes sense to enable
the display options again.

NOTE: Display panel is still not working since patch "arm: dts: Exynos5:
Use pmu_system_controller phandle for dp phy" is needed [0] but I think
we should enable display options to catch the regressions easier.

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/11/24/10

 arch/arm/configs/exynos_defconfig | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 22beed3..27cdd52 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -111,11 +111,26 @@ CONFIG_REGULATOR_S2MPA01=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS65090=y
+CONFIG_DRM=y
+CONFIG_DRM_BRIDGE=y
+CONFIG_DRM_PTN3460=y
+CONFIG_DRM_PS8622=y
+CONFIG_DRM_EXYNOS=y
+CONFIG_DRM_EXYNOS_FIMD=y
+CONFIG_DRM_EXYNOS_DP=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SIMPLE=y
 CONFIG_EXYNOS_VIDEO=y
 CONFIG_EXYNOS_MIPI_DSI=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=y
+CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
-- 
2.1.3

--
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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Nishanth Menon]

On 01/02/2015 03:13 AM, Tomasz Figa wrote:

> However I'm not sure about your concern about using l2x0_data before 
> kmemdup(). I don't see any code potentially doing this.

It is not terribly important, but anyways [1] is what I had in mind..



[1]
https://github.com/nmenon/linux-2.6-playground/commit/40f65e4707856f7b35872cf2225bf8beaf43552c#diff-56925866b8b499d75763bf5a1d7f1666L883

-- 
Regards,
Nishanth Menon
--
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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Nishanth Menon]

On 01/02/2015 03:28 AM, Tomasz Figa wrote:
> 
> 
> On 02.01.2015 18:13, Tomasz Figa wrote:
>> On 30.12.2014 23:51, Nishanth Menon wrote:
> Looks like the following also need addressing:
> data->save is called twice (once more after l2cof_init)
> l2c310_init_fns also needs l2c310_configure
> will be nice to use l2x0_data only after we kmemdup data in __l2c_init

 I'll check this.
>>> Thanks.
>>>
>>
>> Apparently the second save in __l2c_init() is not needed and it should
>> have been removed. However it might be a good idea to actually do second
>> save in l2c_enable() after l2c_configure() so that the values actually
>> permitted by hardware and/or secure firmware are stored.
>>
>> l2c310_init_fns needs to be updated indeed.
> 
> Hmm, apparently current patch already adds this (and I missed it reading 
> it at first), so I'm not sure what's your concern about it.

Uggh.. looks like I missed the same as well :( Sorry about that..



-- 
Regards,
Nishanth Menon
--
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 RESEND 1/4] ARM: dts: Add power and lid GPIO keys pinctrl for exynos5250-snow

[Javier Martinez Canillas]

The Exynos5250 Snow Chromebook has GPIO keys for power and lid
so the SoC I/O pins have to be configured in external interrupt
mode. Currently, this is working without setting the pinctrl
lines but is better to set it explicitly instead of relying on
the previous state of the I/O pins.

The DTS snippets were taken from the downstream ChromeOS tree.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5250-snow.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index effaf2a..b9aeec4 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -33,6 +33,8 @@
 
gpio-keys {
compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <&power_key_irq &lid_irq>;
 
power {
label = "Power";
@@ -540,6 +542,13 @@
 };
 
 &pinctrl_0 {
+   power_key_irq: power-key-irq {
+   samsung,pins = "gpx1-3";
+   samsung,pin-function = <0xf>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-6";
samsung,pin-function = <0>;
@@ -575,6 +584,13 @@
samsung,pin-drv = <0>;
};
 
+   lid_irq: lid-irq {
+   samsung,pins = "gpx3-5";
+   samsung,pin-function = <0xf>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = "gpx3-7";
samsung,pin-function = <0>;
-- 
2.1.3

--
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 RESEND 3/4] ARM: dts: Set Peach boards USB WebCam regulators to always on

[Javier Martinez Canillas]

The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have a built-in
Silicon Motion USB UVC WebCam whose power supply is the tps65090 fet5
regulator. Since the camera uses the generic USB Video Class driver and
this does not grab a regulator, mark the regulator as always on so the
USB device is enumerated and usable.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fa74a73..a4c5152 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -831,6 +831,7 @@
};
tps65090_fet5: fet5 {
regulator-name = "camout";
+   regulator-always-on;
};
tps65090_fet6: fet6 {
regulator-name = "lcd_vdd";
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index d603e73..1367276 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -820,6 +820,7 @@
};
tps65090_fet5: fet5 {
regulator-name = "camout";
+   regulator-always-on;
};
tps65090_fet6: fet6 {
regulator-name = "lcd_vdd";
-- 
2.1.3

--
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 RESEND 4/4] ARM: dts: Configure regulators for suspend on exynos Peach boards

[Javier Martinez Canillas]

The regulator core now has support to choose if a regulator
has to be enabled or disabled during system suspend and also
supports changing the regulator operating mode during runtime
and when the system enters into sleep mode.

To lower power during suspend, configure the regulators state
using the same configuration found in the ChromeOS 3.8 kernel

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 81 ++
 2 files changed, 162 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index a4c5152..c47bb70 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "exynos5420.dtsi"
 
 / {
@@ -201,6 +202,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck2_reg: BUCK2 {
@@ -210,6 +214,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck3_reg: BUCK3 {
@@ -219,6 +226,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck4_reg: BUCK4 {
@@ -228,6 +238,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck5_reg: BUCK5 {
@@ -236,6 +249,9 @@
regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck6_reg: BUCK6 {
@@ -245,6 +261,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck7_reg: BUCK7 {
@@ -253,6 +272,9 @@
regulator-max-microvolt = <135>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
buck8_reg: BUCK8 {
@@ -261,6 +283,9 @@
regulator-max-microvolt = <285>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
buck9_reg: BUCK9 {
@@ -269,6 +294,9 @@
regulator-max-microvolt = <200>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
buck10_reg: BUCK10 {
@@ -277,6 +305,9 @@
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+ 

[PATCH RESEND 2/4] ARM: dts: Add lid GPIO key device node for Peach boards

[Javier Martinez Canillas]

The Exynos5420 Peach Pit and Exynos5800 Peach Pi boards have both
a power and lid GPIO keys but only the former was defined in the
DTS. Add DTS snippets for the lid GPIO key too. These were taken
from the downstream ChromeOS 3.8 kernel tree.

Signed-off-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 18 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 19 ++-
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..fa74a73 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -53,7 +53,7 @@
compatible = "gpio-keys";
 
pinctrl-names = "default";
-   pinctrl-0 = <&power_key_irq>;
+   pinctrl-0 = <&power_key_irq &lid_irq>;
 
power {
label = "Power";
@@ -61,6 +61,15 @@
linux,code = ;
gpio-key,wakeup;
};
+
+   lid-switch {
+   label = "Lid";
+   gpios = <&gpx3 4 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
};
 
memory {
@@ -658,6 +667,13 @@
samsung,pin-drv = <0>;
};
 
+   lid_irq: lid-irq {
+   samsung,pins = "gpx3-4";
+   samsung,pin-function = <0xf>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = "gpx3-7";
samsung,pin-function = <0>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e8fdda8..d603e73 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -52,7 +52,7 @@
compatible = "gpio-keys";
 
pinctrl-names = "default";
-   pinctrl-0 = <&power_key_irq>;
+   pinctrl-0 = <&power_key_irq &lid_irq>;
 
power {
label = "Power";
@@ -60,6 +60,16 @@
linux,code = ;
gpio-key,wakeup;
};
+
+   lid-switch {
+   label = "Lid";
+   gpios = <&gpx3 4 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
+
};
 
memory {
@@ -646,6 +656,13 @@
samsung,pin-drv = <0>;
};
 
+   lid_irq: lid-irq {
+   samsung,pins = "gpx3-4";
+   samsung,pin-function = <0xf>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = "gpx3-7";
samsung,pin-function = <0>;
-- 
2.1.3

--
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 RESEND 0/4] Small updates to Snow and Peach Pit/Pi DTS

[Javier Martinez Canillas]

Hello Kukjin,

This series adds some DTS snippets that were missing in the mainline
Snow and Peach Pit/Pi Device Trees but are present in the downstream
ChromeOS kernel.

The series is composed of the following patches:

Javier Martinez Canillas (4):
  ARM: dts: Add power and lid GPIO keys pinctrl for exynos5250-snow
  ARM: dts: Add lid GPIO key device node for Peach boards
  ARM: dts: Set Peach boards USB WebCam regulators to always on
  ARM: dts: Configure regulators for suspend on exynos Peach boards

 arch/arm/boot/dts/exynos5250-snow.dts  |  16 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 100 +++-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 101 -
 3 files changed, 215 insertions(+), 2 deletions(-)

Patch #1 adds some pinctrl lines for the GPIO keys in the Snow DTS.

Patch #2 adds a device node and pinctrl lines for the lid GPIO in
the Peach boards DTS.

Patch #3 sets the regulators that supply voltage to the USB WebCam
in Peach boards as always on.

Patch #4 configures the max77802 regulators on the Peach Pit and Pi
boards to be enabled or disabled during system suspend.

Best regards,
Javier

--
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 RESEND v2 7/7] platform/chrome: Expose Chrome OS Lightbar to users

[Javier Martinez Canillas]

From: Bill Richardson 

This adds some sysfs entries to provide userspace control of the
four-element LED "lightbar" on the Chromebook Pixel. This only instantiates
the lightbar controls if the device actually exists.

To prevent DoS attacks, this interface is limited to 20 accesses/second,
although that rate can be adjusted by a privileged user.

On Chromebooks without a lightbar, this should have no effect. On the
Chromebook Pixel, you should be able to do things like this:

$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo 0x80 > brightness
$ echo 255 > brightness
$
$ cat sequence
S0
$ echo konami > sequence
$ cat sequence
KONAMI
$
$ cat sequence
S0

And

$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo stop > sequence
$ echo "4 255 255 255" > led_rgb
$ echo "0 255 0 0  1 0 255 0  2 0 0 255  3 255 255 0" > led_rgb
$ echo run  > sequence

Test the DoS prevention with this:

$ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
$ echo 500 > interval_msec
$ time (cat version version version version version version version)

Signed-off-by: Bill Richardson 
Reviewed-by: Olof Johansson 
Tested-by: Doug Anderson 
Reviewed-by: Benson Leung 
Signed-off-by: Javier Martinez Canillas 
---

Olof,

Lee Jones suggested that this should live under drivers/led instead but this
an ad-hoc sysfs interface for the Chromebook Pixel lightbar and does not use
neither the LED class nor its sysfs interface (/sys/class/leds/).

Also the sysfs attributes are created in the ChromeOS EC chardev driver probe
function so I belive is part of that driver and it should be in the same dir.

Best regards,
Javier

Changes since v1:
 - Moved from drivers/mfd to drivers/platform/chrome.
 - Modify to use the fixed-size arrays for cros_ec_command in and out buffers.

 drivers/platform/chrome/Makefile   |   2 +-
 drivers/platform/chrome/cros_ec_dev.c  |   2 +
 drivers/platform/chrome/cros_ec_dev.h  |   3 +
 drivers/platform/chrome/cros_ec_lightbar.c | 367 +
 4 files changed, 373 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/chrome/cros_ec_lightbar.c

diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 3e7980b..cc5d2f2 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,5 +1,5 @@
 
 obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
-cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o
+cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o 
cros_ec_lightbar.o
 obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_devs.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index 557f2e8..7bbcb98 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -200,6 +200,7 @@ static int ec_device_probe(struct platform_device *pdev)
 
/* Initialize extra interfaces */
ec_dev_sysfs_init(ec);
+   ec_dev_lightbar_init(ec);
 
return 0;
 }
@@ -208,6 +209,7 @@ static int ec_device_remove(struct platform_device *pdev)
 {
struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
 
+   ec_dev_lightbar_remove(ec);
ec_dev_sysfs_remove(ec);
device_destroy(cros_class, MKDEV(ec_major, 0));
cdev_del(&ec->cdev);
diff --git a/drivers/platform/chrome/cros_ec_dev.h 
b/drivers/platform/chrome/cros_ec_dev.h
index f036132..45d67f7 100644
--- a/drivers/platform/chrome/cros_ec_dev.h
+++ b/drivers/platform/chrome/cros_ec_dev.h
@@ -47,4 +47,7 @@ struct cros_ec_readmem {
 void ec_dev_sysfs_init(struct cros_ec_device *);
 void ec_dev_sysfs_remove(struct cros_ec_device *);
 
+void ec_dev_lightbar_init(struct cros_ec_device *);
+void ec_dev_lightbar_remove(struct cros_ec_device *);
+
 #endif /* _CROS_EC_DEV_H_ */
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c 
b/drivers/platform/chrome/cros_ec_lightbar.c
new file mode 100644
index 000..35fc892
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -0,0 +1,367 @@
+/*
+ * cros_ec_lightbar - expose the Chromebook Pixel lightbar to userspace
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#define pr_fmt(fmt) "cros_ec_lightbar: " f

[PATCH RESEND v2 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device

[Javier Martinez Canillas]

The ChromeOS EC character device is an user-space interface to
allow applications to access the Embedded Controller.

Add a cell for this device so it's spawned from the mfd driver.

Signed-off-by: Javier Martinez Canillas 
---

Changes since v1: None, new patch.

 drivers/mfd/cros_ec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c872e1b..70f9ed5 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -118,6 +118,10 @@ static const struct mfd_cell cros_devs[] = {
.id = 2,
.of_compatible = "google,cros-ec-i2c-tunnel",
},
+   {
+   .name = "cros-ec-dev",
+   .id = 3,
+   },
 };
 
 int cros_ec_register(struct cros_ec_device *ec_dev)
-- 
2.1.3

--
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 RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices

[Javier Martinez Canillas]

From: Bill Richardson 

This adds the LPC interface to the Chrome OS EC. Like the
I2C and SPI drivers, this allows userspace access to the EC.

Signed-off-by: Bill Richardson 
Signed-off-by: Javier Martinez Canillas 
---

Changes since v1: None, new patch.

 drivers/mfd/Kconfig   |  10 ++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/cros_ec_lpc.c | 305 ++
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/mfd/cros_ec_lpc.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..7563786 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -110,6 +110,16 @@ config MFD_CROS_EC_I2C
  a checksum. Failing accesses will be retried three times to
  improve reliability.
 
+config MFD_CROS_EC_LPC
+   tristate "ChromeOS Embedded Controller (LPC)"
+   depends on MFD_CROS_EC
+
+   help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ over an LPC bus. This uses a simple byte-level protocol with a
+ checksum. This is used for userspace access only. The kernel
+ typically has its own communication methods.
+
 config MFD_CROS_EC_SPI
tristate "ChromeOS Embedded Controller (SPI)"
depends on MFD_CROS_EC && SPI && OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..94c1516 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MFD_ASIC3)   += asic3.o tmio_core.o
 obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
 obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
+obj-$(CONFIG_MFD_CROS_EC_LPC)  += cros_ec_lpc.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 
 rtsx_pci-objs  := rtsx_pcr.o rtsx_gops.o rts5209.o rts5229.o 
rtl8411.o rts5227.o rts5249.o
diff --git a/drivers/mfd/cros_ec_lpc.c b/drivers/mfd/cros_ec_lpc.c
new file mode 100644
index 000..700e4cf
--- /dev/null
+++ b/drivers/mfd/cros_ec_lpc.c
@@ -0,0 +1,305 @@
+/*
+ * cros_ec_lpc - LPC access to the Chrome OS Embedded Controller
+ *
+ * Copyright (C) 2012-2015 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard EC
+ * to the AP over some bus (such as i2c, lpc, spi).  The EC does debouncing,
+ * but everything else (including deghosting) is done here.  The main
+ * motivation for this is to keep the EC firmware as simple as possible, since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MYNAME "cros_ec_lpc"
+
+static int ec_response_timed_out(void)
+{
+   unsigned long one_second = jiffies + HZ;
+
+   usleep_range(200, 300);
+   do {
+   if (!(inb(EC_LPC_ADDR_HOST_CMD) & EC_LPC_STATUS_BUSY_MASK))
+   return 0;
+   usleep_range(100, 200);
+   } while (time_before(jiffies, one_second));
+
+   return 1;
+}
+
+static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
+   struct cros_ec_command *msg)
+{
+   struct ec_lpc_host_args args;
+   int csum;
+   int i;
+   int ret = 0;
+
+   if (msg->outsize > EC_PROTO2_MAX_PARAM_SIZE ||
+   msg->insize > EC_PROTO2_MAX_PARAM_SIZE) {
+   dev_err(ec->dev,
+   "invalid buffer sizes (out %d, in %d)\n",
+   msg->outsize, msg->insize);
+   return -EINVAL;
+   }
+
+   /* Now actually send the command to the EC and get the result */
+   args.flags = EC_HOST_ARGS_FLAG_FROM_HOST;
+   args.command_version = msg->version;
+   args.data_size = msg->outsize;
+
+   /* Initialize checksum */
+   csum = msg->command + args.flags +
+   args.command_version + args.data_size;
+
+   /* Copy data and update checksum */
+   for (i = 0; i < msg->outsize; i++) {
+   outb(msg->outdata[i], EC_LPC_ADDR_HOST_PARAM + i);
+   csum += msg->outdata[i];
+   }
+
+   /* Finalize checksum and write args */
+   args.checksum = csum & 0xFF;
+   outb(args.flags, EC_LPC_ADDR_HOST_ARGS);
+   outb(args.command_version, EC_LPC_ADDR_HOST_ARGS + 1);
+   outb(args.data_size, EC_LPC_ADDR_HOST_ARGS + 2);
+   outb(args.checksum, EC_LPC_ADDR_HOST_ARGS + 3);
+
+   /* Here we go */
+   outb(msg

[PATCH RESEND v2 4/7] platform/chrome: Add Chrome OS EC userspace device interface

[Javier Martinez Canillas]

From: Bill Richardson 

This patch adds a device interface to access the
Chrome OS Embedded Controller from user-space.

Signed-off-by: Bill Richardson 
Reviewed-by: Simon Glass 
Signed-off-by: Javier Martinez Canillas 
---

Changes since v1:
 - The cros_ec_dev driver does not belong to drivers/mfd (Lee Jones)
 - Don't call class_create in the probe function (Gwendal Grignou)
 - Don't use the deprecated register_chrdev() function (Gwendal Grignou)
 - Remove struct cros_ec_device *ec global variable (Lee Jones)
 - Arrange structures to be 64-bit safe instead using the IOCTL compact API
   (Alan Cox)
 - Use _CHARDEV instead of _DEV as a postfix to denote that is a character
   device user-space interface (Lee Jones)
 - Remove the CROS_CLASS_NAME define and just use the name directly (Lee Jones)
 - Remove unncessary include headers (Lee Jones)
 - Add a newline when appropiate and remove double new lines (Lee Jones)
 - If *offset == 0, there is no need to do *offset +=, just use = (Lee Jones)
 - Use dev_err() instead of pr_err() when possible (Lee Jones)
 - Remove unnecesary goto and just return an error instead (Lee Jones)
 - Don't set .owner to THIS_MODULE since that is made by the core (Lee Jones)
 - Document the ioctl number used in Documentation/ioctl/ioctl-number.txt

 Documentation/ioctl/ioctl-number.txt  |   1 +
 drivers/platform/chrome/Kconfig   |  14 +-
 drivers/platform/chrome/Makefile  |   1 +
 drivers/platform/chrome/cros_ec_dev.c | 268 ++
 drivers/platform/chrome/cros_ec_dev.h |  47 ++
 5 files changed, 328 insertions(+), 3 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_dev.c
 create mode 100644 drivers/platform/chrome/cros_ec_dev.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 8136e1f..51f4221 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,7 @@ Code  Seq#(hex) Include FileComments
 0xDB   00-0F   drivers/char/mwave/mwavepub.h
 0xDD   00-3F   ZFCP device driver  see drivers/s390/scsi/

+0xEC   00-01   drivers/platform/chrome/cros_ec_dev.h   ChromeOS EC driver
 0xF3   00-3F   drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)

 0xF4   00-1F   video/mbxfb.h   mbxfb
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 440ed77..75dc514 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig CHROME_PLATFORMS
bool "Platform support for Chrome hardware"
-   depends on X86
+   depends on X86 || ARM
---help---
  Say Y here to get to see options for platform support for
  various Chromebooks and Chromeboxes. This option alone does
@@ -16,8 +16,7 @@ if CHROME_PLATFORMS
 
 config CHROMEOS_LAPTOP
tristate "Chrome OS Laptop"
-   depends on I2C
-   depends on DMI
+   depends on I2C && DMI && X86
---help---
  This driver instantiates i2c and smbus devices such as
  light sensors and touchpads.
@@ -27,6 +26,7 @@ config CHROMEOS_LAPTOP
 
 config CHROMEOS_PSTORE
tristate "Chrome OS pstore support"
+   depends on X86
---help---
  This module instantiates the persistent storage on x86 ChromeOS
  devices. It can be used to store away console logs and crash
@@ -38,5 +38,13 @@ config CHROMEOS_PSTORE
  If you have a supported Chromebook, choose Y or M here.
  The module will be called chromeos_pstore.
 
+config CROS_EC_CHARDEV
+tristate "Chrome OS Embedded Controller userspace device interface"
+depends on MFD_CROS_EC
+---help---
+  This driver adds support to talk with the ChromeOS EC from userspace.
+
+  If you have a supported Chromebook, choose Y or M here.
+  The module will be called cros_ec_dev.
 
 endif # CHROMEOS_PLATFORMS
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 2b860ca..10f1361 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,3 +1,4 @@
 
 obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
+obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_dev.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
new file mode 100644
index 000..04cc8eb
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -0,0 +1,268 @@
+/*
+ * cros_ec_dev - expose the Chrome OS Embedded Controller to user-space
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2

[PATCH RESEND v2 6/7] platform/chrome: Create sysfs attributes for the ChromeOS EC.

[Javier Martinez Canillas]

From: Bill Richardson 

This adds the first few sysfs attributes for the Chrome OS EC. These
controls are made available under /sys/devices/virtual/chromeos/cros_ec

flashinfo   - display current flash info
reboot  - tell the EC to reboot in various ways
version - information about the EC software and hardware

Future changes will build on this to add additional controls.

>From a root shell, you should be able to do things like this:

cd /sys/devices/virtual/chromeos/cros_ec
cat flashinfo
cat version
echo rw > reboot
cat version
echo ro > reboot
cat version
echo rw > reboot
cat version
echo cold > reboot

That last command will reboot the AP too.

Signed-off-by: Bill Richardson 
Reviewed-by: Olof Johansson 
Signed-off-by: Javier Martinez Canillas 
---

Changes since v1:
 - Moved from drivers/mfd to drivers/platform/chrome. Suggested by Lee Jones.
 - Modify to use the fixed-size arrays for cros_ec_command in and out buffers.

 drivers/platform/chrome/Makefile|   3 +-
 drivers/platform/chrome/cros_ec_dev.c   |   4 +
 drivers/platform/chrome/cros_ec_dev.h   |   3 +
 drivers/platform/chrome/cros_ec_sysfs.c | 271 
 4 files changed, 280 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/chrome/cros_ec_sysfs.c

diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 10f1361..3e7980b 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,4 +1,5 @@
 
 obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
-obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_dev.o
+cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o
+obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_devs.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index 04cc8eb..557f2e8 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -198,6 +198,9 @@ static int ec_device_probe(struct platform_device *pdev)
return retval;
}
 
+   /* Initialize extra interfaces */
+   ec_dev_sysfs_init(ec);
+
return 0;
 }
 
@@ -205,6 +208,7 @@ static int ec_device_remove(struct platform_device *pdev)
 {
struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
 
+   ec_dev_sysfs_remove(ec);
device_destroy(cros_class, MKDEV(ec_major, 0));
cdev_del(&ec->cdev);
return 0;
diff --git a/drivers/platform/chrome/cros_ec_dev.h 
b/drivers/platform/chrome/cros_ec_dev.h
index 15c54c4..f036132 100644
--- a/drivers/platform/chrome/cros_ec_dev.h
+++ b/drivers/platform/chrome/cros_ec_dev.h
@@ -44,4 +44,7 @@ struct cros_ec_readmem {
 #define CROS_EC_DEV_IOCXCMD   _IOWR(CROS_EC_DEV_IOC, 0, struct cros_ec_command)
 #define CROS_EC_DEV_IOCRDMEM  _IOWR(CROS_EC_DEV_IOC, 1, struct cros_ec_readmem)
 
+void ec_dev_sysfs_init(struct cros_ec_device *);
+void ec_dev_sysfs_remove(struct cros_ec_device *);
+
 #endif /* _CROS_EC_DEV_H_ */
diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
b/drivers/platform/chrome/cros_ec_sysfs.c
new file mode 100644
index 000..fb62ab6
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -0,0 +1,271 @@
+/*
+ * cros_ec_sysfs - expose the Chrome OS EC through sysfs
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#define pr_fmt(fmt) "cros_ec_sysfs: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cros_ec_dev.h"
+
+/* Accessor functions */
+
+static ssize_t show_ec_reboot(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   int count = 0;
+
+   count += scnprintf(buf + count, PAGE_SIZE - count,
+  "ro|rw|cancel|cold|disable-jump|hibernate");
+   count += scnprintf(buf + count, PAGE_SIZE - count,
+  " [at-shutdown]\n");
+   return count;
+}
+
+static ssize_t store_ec_reboot(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   static const struct {
+   const char * const str;
+  

[PATCH RESEND v2 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC

[Javier Martinez Canillas]

The struct cros_ec_command will be used as an ioctl() argument for the
API to control the ChromeOS EC from user-space. So the data structure
has to be 64-bit safe to make it compatible between 32 and 64 avoiding
the need for a compat ioctl interface. Since pointers are self-aligned
to different byte boundaries, use fixed size arrays instead of pointers
for transferring ingoing and outgoing data with the Embedded Controller.

Also, re-arrange struct members by decreasing alignment requirements to
reduce the needing padding size.

Signed-off-by: Javier Martinez Canillas 
---

Hello,

I choose EC_PROTO2_MAX_PARAM_SIZE as the maximum length for the input and
output buffers since I see that is what is assumed in the cros_ec driver
that is the maximum lengths. But the downstream kernel has also suppport
for the EC host command protocol v3 even though there is currently no bus
specific code to handle v3 packets. So I wonder if this is a good max len
or if a different size should be used instead.

Best regards,
Javier

Changes since v1: None, new patch

 drivers/i2c/busses/i2c-cros-ec-tunnel.c | 51 +++--
 drivers/input/keyboard/cros_ec_keyb.c   | 13 +
 drivers/mfd/cros_ec.c   | 15 +-
 include/linux/mfd/cros_ec.h |  8 +++---
 4 files changed, 29 insertions(+), 58 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c 
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 875c22a..fa8dedd 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -182,72 +182,41 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg i2c_msgs[],
const u16 bus_num = bus->remote_bus;
int request_len;
int response_len;
-   u8 *request = NULL;
-   u8 *response = NULL;
int result;
-   struct cros_ec_command msg;
+   struct cros_ec_command msg = { };
 
request_len = ec_i2c_count_message(i2c_msgs, num);
if (request_len < 0) {
dev_warn(dev, "Error constructing message %d\n", request_len);
-   result = request_len;
-   goto exit;
+   return request_len;
}
+
response_len = ec_i2c_count_response(i2c_msgs, num);
if (response_len < 0) {
/* Unexpected; no errors should come when NULL response */
dev_warn(dev, "Error preparing response %d\n", response_len);
-   result = response_len;
-   goto exit;
-   }
-
-   if (request_len <= ARRAY_SIZE(bus->request_buf)) {
-   request = bus->request_buf;
-   } else {
-   request = kzalloc(request_len, GFP_KERNEL);
-   if (request == NULL) {
-   result = -ENOMEM;
-   goto exit;
-   }
-   }
-   if (response_len <= ARRAY_SIZE(bus->response_buf)) {
-   response = bus->response_buf;
-   } else {
-   response = kzalloc(response_len, GFP_KERNEL);
-   if (response == NULL) {
-   result = -ENOMEM;
-   goto exit;
-   }
+   return response_len;
}
 
-   result = ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
+   result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num, bus_num);
if (result)
-   goto exit;
+   return result;
 
msg.version = 0;
msg.command = EC_CMD_I2C_PASSTHRU;
-   msg.outdata = request;
msg.outsize = request_len;
-   msg.indata = response;
msg.insize = response_len;
 
result = cros_ec_cmd_xfer(bus->ec, &msg);
if (result < 0)
-   goto exit;
+   return result;
 
-   result = ec_i2c_parse_response(response, i2c_msgs, &num);
+   result = ec_i2c_parse_response(msg.indata, i2c_msgs, &num);
if (result < 0)
-   goto exit;
+   return result;
 
/* Indicate success by saying how many messages were sent */
-   result = num;
-exit:
-   if (request != bus->request_buf)
-   kfree(request);
-   if (response != bus->response_buf)
-   kfree(response);
-
-   return result;
+   return num;
 }
 
 static u32 ec_i2c_functionality(struct i2c_adapter *adap)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index ffa989f..769f8f7 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -148,16 +148,19 @@ static void cros_ec_keyb_process(struct cros_ec_keyb 
*ckdev,
 
 static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t 
*kb_state)
 {
+   int ret;
struct cros_ec_command msg = {
-   .version = 0,
.command = EC_CMD_MKBP_STATE,
-   .outdata = NULL,
-   .outsize = 0,
-   .indata = kb_state,
 

[PATCH RESEND v2 0/7] platform/chrome: Add user-space dev inferface support

[Javier Martinez Canillas]

Hello,

The mainline ChromeOS Embedded Controller (EC) driver is still missing some
features that are present in the downstream ChromiumOS tree. These are:

  - Low Pin Count (LPC) interface
  - User-space device interface
  - Access to vboot context stored on a block device
  - Access to vboot context stored on EC's nvram
  - Power Delivery Device
  - Support for multiple EC in a system

This is a second version of a series that adds support for the first two of
the missing features: the EC LPC and EC character device interfaces that
are used by user-space to access the ChromeOS EC. The support patches were
taken from the downstream ChromiumOS 3.14 tree with the fixes and cleanups
squashed to have a minimal patch-set.

The version of the ChromeOS EC chardev driver in this series still does not
reflect the latest one that is in the downstream ChromiumOS 3.14 kernel but
makes the delta shorter. Following patches will add the remaining missing
features until both trees are in sync. I preferred to first add the initial
support and then adding the other features to both maintain the original
patch history in the downstream kernel and so preserve the patch authorship
and also make the diff to have a working cros user-space interface smaller.

Version 1 of this series was [0] and added the Chrome EC chardev driver
and the sysfs interface to drivers/mfd since that is what is done in the
downstream ChromiumOS kernel but Lee Jones asked to find a better place
since those are not really multi-function device drivers. So this version
places them under drivers/platform/chrome since MAINTAINERS says that this
sub-directory is "CHROME HARDWARE PLATFORM SUPPORT" which seems a good fit.

A big change in this version is that the ioctl API is modified to make it
64-bit safe and compatible with both 64 and 32 bit user-space binaries.
The data structures passed as arguments to ioctl commands had pointers fields
and these have different byte boundaries alignment requirement so the previous
version had a compat ioctl interface. The feedback was that this had to be
avoided since this was a new ioctl API so the pointers fields were replaced
with a set of fixed-size arrays to be used instead. This has the drawback that
more data could be used and copied between user and kernel space so feedback
is welcomed if there is a better approach to solve this kind of issues.

The patches were tested on an Exynos5420 Peach Pit Chromebook and (thanks to
Bill Richardson) on an x86 Pixel Chromebook using an ectool [1] modified to
use the new ioctl API. The LPC interface driver and the lightbar sysfs driver
were also tested on the Pixel Chromebook.

The series is composed of the following patches:

Bill Richardson (4):
  mfd: cros_ec: Add cros_ec_lpc driver for x86 devices
  platform/chrome: Add Chrome OS EC userspace device interface
  platform/chrome: Create sysfs attributes for the ChromeOS EC.
  platform/chrome: Expose Chrome OS Lightbar to users

Javier Martinez Canillas (3):
  mfd: cros_ec: Use fixed size arrays to transfer data with the EC
  mfd: cros_ec: Add char dev and virtual dev pointers
  mfd: cros_ec: Instantiate ChromeOS EC character device

 Documentation/ioctl/ioctl-number.txt   |   1 +
 drivers/i2c/busses/i2c-cros-ec-tunnel.c|  51 +---
 drivers/input/keyboard/cros_ec_keyb.c  |  13 +-
 drivers/mfd/Kconfig|  10 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/cros_ec.c  |  19 +-
 drivers/mfd/cros_ec_lpc.c  | 305 
 drivers/platform/chrome/Kconfig|  14 +-
 drivers/platform/chrome/Makefile   |   2 +
 drivers/platform/chrome/cros_ec_dev.c  | 274 +
 drivers/platform/chrome/cros_ec_dev.h  |  53 +
 drivers/platform/chrome/cros_ec_lightbar.c | 367 +
 drivers/platform/chrome/cros_ec_sysfs.c| 271 +
 include/linux/mfd/cros_ec.h|  23 +-
 14 files changed, 1342 insertions(+), 62 deletions(-)
 create mode 100644 drivers/mfd/cros_ec_lpc.c
 create mode 100644 drivers/platform/chrome/cros_ec_dev.c
 create mode 100644 drivers/platform/chrome/cros_ec_dev.h
 create mode 100644 drivers/platform/chrome/cros_ec_lightbar.c
 create mode 100644 drivers/platform/chrome/cros_ec_sysfs.c

Patch #1 modified the struct cros_ec_command structure so it can be used
as an ioctl argument and be 64 and 32 bit safe and patch #2 adds fields
to the struct cros_ec_device that will be needed by the EC chardev driver.

Patch #3 adds support for the EC LPC interface used on x86 Chromebooks.

Patch #4 adds the ChromeOS chardev driver and patch #5 instantiates it
from the mfd cros_ec driver.

Patch #6 exposes sysfs attributes that can be used by user space programs
to get information and control the ChromeOS EC.

Patch #7 exposes sysfs attributes that are used to control the lightbar
RGB LEDs found on the Pixel Chromebook.

The patches must be ap

[PATCH RESEND v2 2/7] mfd: cros_ec: Add char dev and virtual dev pointers

[Javier Martinez Canillas]

The ChromeOS Embedded Controller has to be accessed by applications.
A virtual character device is used as an interface with user-space.

Extend the struct cros_ec_device with the fields needed by the driver
of this virtual character device.

Signed-off-by: Javier Martinez Canillas 
---

Changes since v1: None, new patch.

 include/linux/mfd/cros_ec.h | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 71675b1..324a346 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -16,6 +16,7 @@
 #ifndef __LINUX_MFD_CROS_EC_H
 #define __LINUX_MFD_CROS_EC_H
 
+#include 
 #include 
 #include 
 #include 
@@ -59,9 +60,17 @@ struct cros_ec_command {
  *
  * @ec_name: name of EC device (e.g. 'chromeos-ec')
  * @phys_name: name of physical comms layer (e.g. 'i2c-4')
- * @dev: Device pointer
+ * @dev: Device pointer for physical comms device
+ * @vdev: Device pointer for virtual comms device
+ * @cdev: Character device structure for virtual comms device
  * @was_wake_device: true if this device was set to wake the system from
  * sleep at the last suspend
+ * @cmd_readmem: direct read of the EC memory-mapped region, if supported
+ * @offset is within EC_LPC_ADDR_MEMMAP region.
+ * @bytes: number of bytes to read. zero means "read a string" (including
+ * the trailing '\0'). At most only EC_MEMMAP_SIZE bytes can be read.
+ * Caller must ensure that the buffer is large enough for the result when
+ * reading a string.
  *
  * @priv: Private data
  * @irq: Interrupt to use
@@ -90,8 +99,12 @@ struct cros_ec_device {
const char *ec_name;
const char *phys_name;
struct device *dev;
+   struct device *vdev;
+   struct cdev cdev;
bool was_wake_device;
struct class *cros_class;
+   int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
+  unsigned int bytes, void *dest);
 
/* These are used to implement the platform-specific interface */
void *priv;
-- 
2.1.3

--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi Daniel,

This series is sitting out there since long without any ACKs.
If people can ACK this series, I am ready to rebase and send ASAP.

Regards,
Ajay Kumar

On Fri, Jan 2, 2015 at 6:40 PM, Daniel Stone  wrote:
> Hi Ajay,
>
> On 17 December 2014 at 09:31, Javier Martinez Canillas
>  wrote:
>>
>> On 12/16/2014 12:37 AM, Laurent Pinchart wrote:
>> >> You asked Ajay to change his series to use the video port and enpoints
>> >> DT
>> >> bindings instead of phandles, could you please review his latest
>> >> version?
>> >>
>> >> I guess is now too late for 3.19 since we are in the middle of the
>> >> merge
>> >> window but it would be great if this series can at least made it to
>> >> 3.20.
>> >
>> > I don't have time to review the series in details right now, but I'm
>> > happy
>> > with the DT bindings, and have no big issue with the rest of the
>> > patches. I
>> > don't really like the of_drm_find_bridge() concept introduced in 03/14
>> > but I
>> > won't nack it given lack of time to implement an alternative proposal.
>> > It's an
>> > internal API, it can always be reworked later anyway.
>>
>> Thanks a lot for taking the time to look at the DT bindings, then I guess
>> that the series are finally ready to be merged?
>>
>> Ajay's series don't apply cleanly anymore because it has been a while
>> since
>> he posted it but he can rebase on top of 3.19-rc1 once it is released and
>> re-resend.
>
>
> Do you have any plans to rebase this so it's ready for merging?
>
> Thierry, Daniel, Dave - whose tree would this be best to merge through?
>
> Cheers,
> Daniel
--
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 v3 1/4] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

[Ulf Hansson]

On 31 December 2014 at 07:43, Alim Akhtar  wrote:
> From: Seungwon Jeon 
>
> ciu_div may not be common value for all speed mode.
> So, it needs to be attached to CLKSEL timing.
> This also introduce a new compatibale 'dw-mshc-hs200-timing'
> for selecting hs200 timing value

According to the patch you are adding a new DT property not a
"compatible". Please update the commit message.

The rest looks good to me.

Kind regards
Uffe

>
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> ---
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   15 ++--
>  drivers/mmc/host/dw_mmc-exynos.c   |   81 
> ++--
>  drivers/mmc/host/dw_mmc-exynos.h   |1 +
>  3 files changed, 67 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index ee4fc05..06455de 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -23,10 +23,6 @@ Required Properties:
> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>   specific extensions having an SMU.
>
> -* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
> -  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
> -  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
> -
>  * samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift 
> value
>in transmit mode and CIU clock phase shift value in receive mode for single
>data rate mode operation. Refer notes below for the order of the cells and 
> the
> @@ -37,11 +33,16 @@ Required Properties:
>data rate mode operation. Refer notes below for the order of the cells and 
> the
>valid values.
>
> +* samsung,dw-mshc-hs200-timing: Similar with dw-mshc-sdr-timing.
> +
>Notes for the sdr-timing and ddr-timing values:
>
>  The order of the cells should be
>- First Cell: CIU clock phase shift value for tx mode.
>- Second Cell: CIU clock phase shift value for rx mode.
> +  - Thrid Cell: Specifies the divider value for the card interface
> +unit (ciu) clock. This property is applicable only for Exynos5 SoC's 
> and
> +ignored for Exynos4 SoC's. The valid range of divider value is 0 to 
> 7.
>
>  Valid values for SDR and DDR CIU clock timing for Exynos5250:
>- valid value for tx phase shift and rx phase shift is 0 to 7.
> @@ -79,8 +80,8 @@ Example:
> broken-cd;
> fifo-depth = <0x80>;
> card-detect-delay = <200>;
> -   samsung,dw-mshc-ciu-div = <3>;
> -   samsung,dw-mshc-sdr-timing = <2 3>;
> -   samsung,dw-mshc-ddr-timing = <1 2>;
> +   samsung,dw-mshc-sdr-timing = <2 3 3>;
> +   samsung,dw-mshc-ddr-timing = <1 2 3>;
> +   samsung,dw-mshc-hs200-timing = <0 2 3>;
> bus-width = <8>;
> };
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 12a5eaa..be6530e 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -40,6 +40,7 @@ struct dw_mci_exynos_priv_data {
> u8  ciu_div;
> u32 sdr_timing;
> u32 ddr_timing;
> +   u32 hs200_timing;
> u32 cur_speed;
>  };
>
> @@ -71,6 +72,21 @@ static struct dw_mci_exynos_compatible {
> },
>  };
>
> +static inline u8 dw_mci_exynos_get_ciu_div(struct dw_mci *host)
> +{
> +   struct dw_mci_exynos_priv_data *priv = host->priv;
> +
> +   if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4412)
> +   return EXYNOS4412_FIXED_CIU_CLK_DIV;
> +   else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4210)
> +   return EXYNOS4210_FIXED_CIU_CLK_DIV;
> +   else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
> +   priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
> +   return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL64)) + 1;
> +   else
> +   return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL)) + 1;
> +}
> +
>  static int dw_mci_exynos_priv_init(struct dw_mci *host)
>  {
> struct dw_mci_exynos_priv_data *priv = host->priv;
> @@ -85,6 +101,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
>SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
> }
>
> +   priv->ciu_div = dw_mci_exynos_get_ciu_div(host);
> +
> return 0;
>  }
>
> @@ -92,7 +110,7 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
>  {
> struct dw_mci_exynos_priv_data *priv = host->priv;
>
> -   host->bus_hz /= (priv->ciu_div + 1);
> +   host->bus_hz /= priv->ciu_div;
>
> retur

Re: [PATCH v2 2/7] ARM: Exynos: add support for sub-power domains

[Marek Szyprowski]

Hello,

On 2014-12-04 04:45, amit daniel kachhap wrote:

On Wed, Dec 3, 2014 at 6:03 PM, Marek Szyprowski
 wrote:

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences for devices
like TV Mixer or Camera ISP, which needs to have more than one power
domain enabled to be operational.

Signed-off-by: Marek Szyprowski 
---
  Documentation/devicetree/bindings/arm/exynos/power_domain.txt |  2 ++
  arch/arm/mach-exynos/pm_domains.c | 11 ++-
  2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index abde1ea8a119..b884358ebb1a 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,8 @@ Optional Properties:
 - pclkN, clkN: Pairs of parent of input clock and input clock to the
 devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
 are supported currently.
+- samsung,power-domain: phandle to a master power domain that the given domain
+  is a part of

  Node of a device using power domains must have a samsung,power-domain property
  defined with a phandle to respective power domain.
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index 20f267121b3e..fa9a47ddad81 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -108,7 +108,7 @@ static int exynos_pd_power_off(struct generic_pm_domain 
*domain)
  static __init int exynos4_pm_init_power_domain(void)
  {
 struct platform_device *pdev;
-   struct device_node *np;
+   struct device_node *np, *master_np;

 for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
 struct exynos_pm_domain *pd;
@@ -159,6 +159,15 @@ no_clk:

 pm_genpd_init(&pd->pd, NULL, !on);
 of_genpd_add_provider_simple(np, &pd->pd);
+
+   /* make master and slave hierarchy */
+   master_np = of_parse_phandle(np, "samsung,power-domain", 0);
+   if (!master_np)
+   master_np = of_parse_phandle(np, "power-domains", 0);
+   if (master_np) {
+   pm_genpd_add_subdomain_names(master_np->name, np->name);
+   of_node_put(master_np);
+   }
 }

Hi Marek,

In the my patch series posted earlier i added this feature in a
slightly different way. (https://lkml.org/lkml/2014/11/24/320)
Parent PD's are not added in the same loop but in the second loop.
This will make sure that the parents PD are registered before the
child PD's and we can get away from the assumption of child/parent
PD's position in the Device Tree. This is a still a work in progress.
Also posted a patch earlier regarding this,
http://www.spinics.net/lists/linux-samsung-soc/msg39836.html.


Right, your approach seems to be more error prone. Do you plan to resend 
your
patch with the parent domain phandle renamed to generic 'power-domains' 
property,

like Geert suggested?

I would like to send Exynos4 HDMI patches based on top of your work and 
have them

finally merged (they are waiting since v3.17...)

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
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: 3.19-rc1: peach*: display not working (missing patches)

[Javier Martinez Canillas]

[adding Kukjin and Vivek as cc]

Hello Paolo,

On Tue, Dec 23, 2014 at 11:16 AM, Paolo Pisati  wrote:
> Hi,
>
> 3.19-rc1 still misses these two patches:
>
> 156823e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 03c16e7 ARM: exynos_defconfig: Enable options for display panel support156823e
>
> and without them, the display doesn't turn on on my peachpi: can we have them
> queued for rc2?

Yes, Vivek re-posted his dp phy patch a couple of times and I pinged
Kukjin several times about this both during the 3.18 -rc cycle (since
this also affected 3.18 where display is not working) and during the
3.19 merge window but unfortunately it was not picked yet...

I hope he can merge those patches as 3.19 fixes during the -rc cycle
to avoid having another kernel release with a non-working display on
Exynos5 boards.

Best regards,
Javier
--
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] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated

[Javier Martinez Canillas]

Hello Paolo,

On 12/24/2014 05:36 PM, Paolo Pisati wrote:
> On Wed, Dec 10, 2014 at 09:35:31AM -0800, Kevin Hilman wrote:
>> 
>> I confirm it fixes the boot hang in linux-next (next-20141210) on my
>> exynos5800-peach-pi and exynos5420-arndale-octa.  Tested both
>> exynos_defconfig and multi_v7_defconfig.
>> 
>> Tested-by: Kevin Hilman 
> 
> does audio work on your peach pi? because kernel boots fine, but i can't get 
> any
> audio out of it
> 

Audio is not working for me as well. I said before that audio was working
because I tested with the headphone audio jack but I forgot that I had
re-introduced the clk_ignore_unused parameter to my kernel command line
to test the mmc/sdio wifi. Without clk_ignore_unused, I have no audio.

I see that the downstream daisy_max98095 ASoC driver in the ChromeOS tree
grabs some clocks that the mainline sound/soc/samsung/snow.c driver so it
it seems that at least that is missing and may explain why it is working
with clk_ignore_unused.

Best regards,
Javier
--
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: Exynos: convert to generic power domain bindings

[Marek Szyprowski]

This patch replaces all custom samsung,power-domain device tree properties
with generic power domain bindings and updates documentation Samsung's devices
refering to old binding.

Suggested-by: Kevin Hilman 
Signed-off-by: Marek Szyprowski 
---
 .../bindings/arm/exynos/power_domain.txt   |  2 +-
 .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  6 +++---
 .../devicetree/bindings/media/s5p-mfc.txt  |  4 ++--
 .../devicetree/bindings/video/exynos_dsim.txt  |  4 ++--
 .../devicetree/bindings/video/samsung-fimd.txt |  4 ++--
 arch/arm/boot/dts/exynos3250.dtsi  | 11 +++---
 arch/arm/boot/dts/exynos4.dtsi | 25 ++
 arch/arm/boot/dts/exynos4210.dtsi  |  1 +
 arch/arm/boot/dts/exynos4415.dtsi  |  7 ++
 arch/arm/boot/dts/exynos4x12.dtsi  |  7 +++---
 arch/arm/boot/dts/exynos5250.dtsi  | 12 ++-
 arch/arm/boot/dts/exynos5420.dtsi  | 10 ++---
 12 files changed, 60 insertions(+), 33 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index abde1ea8a119..f4445e5a2bbb 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -23,7 +23,7 @@ Optional Properties:
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
 
-Node of a device using power domains must have a samsung,power-domain property
+Node of a device using power domains must have a power-domains property
 defined with a phandle to respective power domain.
 
 Example:
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt 
b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index 6fa4c737af23..729543c47046 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -45,7 +45,7 @@ Required properties:
   Exynos4 SoCs, there needs no "master" clock.
   Exynos5 SoCs, some System MMUs must have "master" clocks.
 - clocks: Required if the System MMU is needed to gate its clock.
-- samsung,power-domain: Required if the System MMU is needed to gate its power.
+- power-domains: Required if the System MMU is needed to gate its power.
  Please refer to the following document:
  Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 
@@ -54,7 +54,7 @@ Examples:
compatible = "samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
-   samsung,power-domain = <&pd_gsc>;
+   power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
};
@@ -66,5 +66,5 @@ Examples:
interrupts = <2 0>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
-   samsung,power-domain = <&pd_gsc>;
+   power-domains = <&pd_gsc>;
};
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 3e3c5f349570..2d5787eac91a 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -28,7 +28,7 @@ Required properties:
for DMA contiguous memory allocation and its size.
 
 Optional properties:
-  - samsung,power-domain : power-domain property defined with a phandle
+  - power-domains : power-domain property defined with a phandle
   to respective power domain.
 
 Example:
@@ -38,7 +38,7 @@ mfc: codec@1340 {
compatible = "samsung,mfc-v5";
reg = <0x1340 0x1>;
interrupts = <0 94 0>;
-   samsung,power-domain = <&pd_mfc>;
+   power-domains = <&pd_mfc>;
clocks = <&clock 273>;
clock-names = "mfc";
 };
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index ca2b4aacd9af..802aa7ef64e5 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -21,7 +21,7 @@ Required properties:
 according to DSI host bindings (see MIPI DSI bindings [1])
 
 Optional properties:
-  - samsung,power-domain: a phandle to DSIM power domain node
+  - power-domains: a phandle to DSIM power domain node
 
 Child nodes:
   Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
@@ -53,7 +53,7 @@ Example:
phy-names = "dsim";
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
-   samsung,power-domain = <&pd_lcd0>;
+   power-domains = <&pd_

Re: [PATCH v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Tomasz Figa]

On 02.01.2015 18:13, Tomasz Figa wrote:

On 30.12.2014 23:51, Nishanth Menon wrote:

Looks like the following also need addressing:
data->save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in __l2c_init


I'll check this.

Thanks.



Apparently the second save in __l2c_init() is not needed and it should
have been removed. However it might be a good idea to actually do second
save in l2c_enable() after l2c_configure() so that the values actually
permitted by hardware and/or secure firmware are stored.

l2c310_init_fns needs to be updated indeed.


Hmm, apparently current patch already adds this (and I missed it reading 
it at first), so I'm not sure what's your concern about it.


Best regards,
Tomasz
--
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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Tomasz Figa]

On 30.12.2014 23:51, Nishanth Menon wrote:

Looks like the following also need addressing:
data->save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in __l2c_init


I'll check this.

Thanks.



Apparently the second save in __l2c_init() is not needed and it should 
have been removed. However it might be a good idea to actually do second 
save in l2c_enable() after l2c_configure() so that the values actually 
permitted by hardware and/or secure firmware are stored.


l2c310_init_fns needs to be updated indeed.

However I'm not sure about your concern about using l2x0_data before 
kmemdup(). I don't see any code potentially doing this.


Best regards,
Tomasz
--
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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Tomasz Figa]

On 30.12.2014 03:23, Nishanth Menon wrote:

On 12/23/2014 04:48 AM, Marek Szyprowski wrote:


-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
  {
-   void __iomem *base = l2x0_base;
+   unsigned revision;

-   if (!(readl_relaxed(base + L2X0_CTRL) & L2X0_CTRL_EN)) {
-   unsigned revision;
-
-   /* restore pl310 setup */
-   writel_relaxed(l2x0_saved_regs.tag_latency,
-  base + L310_TAG_LATENCY_CTRL);
-   writel_relaxed(l2x0_saved_regs.data_latency,
-  base + L310_DATA_LATENCY_CTRL);
-   writel_relaxed(l2x0_saved_regs.filter_end,
-  base + L310_ADDR_FILTER_END);
-   writel_relaxed(l2x0_saved_regs.filter_start,
-  base + L310_ADDR_FILTER_START);
-
-   revision = readl_relaxed(base + L2X0_CACHE_ID) &
-   L2X0_CACHE_ID_RTL_MASK;
-
-   if (revision >= L310_CACHE_ID_RTL_R2P0)
-   l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
- L310_PREFETCH_CTRL);
-   if (revision >= L310_CACHE_ID_RTL_R3P0)
-   l2c_write_sec(l2x0_saved_regs.pwr_ctrl, base,
- L310_POWER_CTRL);
-
-   l2c_enable(base, l2x0_saved_regs.aux_ctrl, 8);
-
-   /* Re-enable full-line-of-zeros for Cortex-A9 */
-   if (l2x0_saved_regs.aux_ctrl & L310_AUX_CTRL_FULL_LINE_ZERO)
-   set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
-   }
+   /* restore pl310 setup */
+   writel_relaxed(l2x0_saved_regs.tag_latency,
+  base + L310_TAG_LATENCY_CTRL);
+   writel_relaxed(l2x0_saved_regs.data_latency,
+  base + L310_DATA_LATENCY_CTRL);
+   writel_relaxed(l2x0_saved_regs.filter_end,
+  base + L310_ADDR_FILTER_END);
+   writel_relaxed(l2x0_saved_regs.filter_start,
+  base + L310_ADDR_FILTER_START);
+


^^ The above change broke AM437xx. Looks like the change causes the
following behavior difference on AM437x. For some reason, touching any
of the above 4 registers(even with the values read from the same
registers) causes AM437x to go beserk. Comment the 4 writes and we
reach shell. looks like l2c310_resume is not invoked prior to this
series. :(.. now that we reuse that logic to actually do programming,
we start to see the problem.


OK, I probably have answer for this. Apparently all four register above 
cannot be written in non-secure mode and they should go through 
l2c_write_sec(). More on this can be found in CoreLink Level 2 Cache 
Controller L2C-310 Technical Reference Manual, 3.2. Register summary, 
table 3.1. I have checked the TRM for r3p3, but I guess this should be 
uniform for all revisions.


Why this worked before? The registers were not written unless respective 
properties in DT were present and OMAP do not have them in DT. Current 
code always writes them, which should not really matter if the code is 
correct. (But it isn't - writel_relaxed() can't be used directly for 
those registers.)


Could you check if replacing those four writel_relaxed() with 
l2c_write_sec() does the thing?


Best regards,
Tomasz
--
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