Re: [PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver

[Ajay kumar]

Hi Javier,

Thanks for the review.

On Mon, Jun 23, 2014 at 12:05 PM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  wrote:
>> From: Vincent Palatin 
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin 
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Sean Paul 
>> Signed-off-by: Rahul Sharma 
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>>  drivers/gpu/drm/bridge/Kconfig |8 +
>>  drivers/gpu/drm/bridge/Makefile|1 +
>>  drivers/gpu/drm/bridge/ps8622.c|  475 
>> 
>>  include/drm/bridge/ps8622.h|   41 ++
>>  5 files changed, 546 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>>  create mode 100644 include/drm/bridge/ps8622.h
>>
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt 
>> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> new file mode 100644
>> index 000..1afbd9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> @@ -0,0 +1,21 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> +   - compatible: "parade,ps8622"
>> +   - reg: first i2c address of the bridge
>> +   - sleep-gpio: OF device-tree gpio specification
>> +   - reset-gpio: OF device-tree gpio specification
>> +
>> +Optional properties:
>> +   - lane-count: number of DP lanes to use
>> +   - use-external-pwm: backlight will be controlled by an external PWM
>> +
>> +Example:
>> +   ps8622-bridge@48 {
>> +   compatible = "parade,ps8622";
>> +   reg = <0x48>;
>> +   sleep-gpio = <&gpc3 6 1 0 0>;
>> +   reset-gpio = <&gpc3 1 1 0 0>;
>> +   display-timings = <&lcd_display_timings>;
>> +   lane-count = <1>
>> +   };
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index e3fb487..7b843c8 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
>> select DRM_KMS_HELPER
>> select DRM_PANEL
>> ---help---
>> +
>> +config DRM_PS8622
>> +   tristate "Parade eDP/LVDS bridge"
>> +   depends on DRM
>> +   select DRM_KMS_HELPER
>> +   select BACKLIGHT_LCD_SUPPORT
>> +   select BACKLIGHT_CLASS_DEVICE
>> +   ---help---
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index ba8b5b8..b494d4b 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>>
>>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
>>  obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
>> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
>> diff --git a/drivers/gpu/drm/bridge/ps8622.c 
>> b/drivers/gpu/drm/bridge/ps8622.c
>> new file mode 100644
>> index 000..387d332
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>> @@ -0,0 +1,475 @@
>> +/*
>> + * Parade PS8622 eDP/LVDS bridge driver
>> + *
>> + * Copyright (C) 2014 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "drmP.h"
>> +#include "drm_crtc.h"
>> +#include "drm_crtc_helper.h"
>> +
>> +struct ps8622_bridge {
>> +   struct drm_bridge *bridge;
>> +   struct drm_encoder *encoder;
>> +   struct i2c_client *client;
>> +   struct regulator *v12;
>> +   struct backlight_device *bl;
>> +   struct mutex enable_mutex;
>> +
>> +   int gpio_slp_n;
>> +   int gpio_rst_n;
>> +
>> +   u8 max_lane_count;
>> +   u8 lane_count;
>> +
>> +   bool enabled;
>> +};
>> +
>> +struct ps8622_device_data {
>> +   u8 max_lane_count;
>> +};
>> +
>> +static const struct ps8622_device_data ps8622_data = {
>> +   .max_lane_count = 1,
>> +};
>> +
>> +static const struct ps8622_device_data ps8625_data = {
>> +   .max_lane_count = 2,
>> +};
>> +
>> +/* Brightness scale on the Parade chip */
>> +#define PS8622_MAX_BRIGHTNESS 0xff
>> +
>> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
>> +#define PS8622_POWER_RISE_T1_MIN_US 10
>> +

Re: [PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Ajay kumar]

Hi Javier,

Thanks for the review.

On Mon, Jun 23, 2014 at 11:30 AM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> Not an extensive review since I'm not familiar with the graphics stack
> but a few things I noticed are commented below.
>
> On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BACKLIGHT_EN pin to
>> enable/ disable the backlight.
>> Sometimes, we can have LCD_EN switches as well.
>>
>> The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar 
>> Signed-off-by: Rahul Sharma 
>> ---
>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-lvds.c |  262 
>> 
>>  4 files changed, 323 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
>> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> new file mode 100644
>> index 000..7cb6084
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> @@ -0,0 +1,50 @@
>> +panel interface for eDP/lvds panels
>> +
>> +Required properties:
>> +  - compatible: "panel-lvds"
>> +
>> +Optional properties:
>> +   -lcd-en-gpio:
>> +   panel LCD poweron GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to powerup/enable the switch to the LCD panel.
>> +   -led-en-gpio:
>> +   panel LED enable GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to enable the backlight.
>> +   -panel-prepare-delay:
>> +   delay value in ms required for panel_prepare process
>> +   Delay in ms needed for the panel LCD unit to
>> +   powerup completely.
>> +   ex: delay needed till eDP panel throws HPD.
>> +   delay needed so that we cans tart reading edid.
>> +   -panel-enable-delay:
>> +   delay value in ms required for panel_enable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   to powerup, and delay needed between video_enable and
>> +   backlight_enable.
>> +   -panel-disable-delay:
>> +   delay value in ms required for panel_disable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   powerdown, and delay needed between backlight_disable
>> +   and video_disable.
>> +   -panel-unprepare-delay:
>> +   delay value in ms required for panel_post_disable process
>> +   Delay in ms needed for the panel LCD unit to
>> +   to powerdown completely, and the minimum delay needed
>> +   before powering it on again.
>> +   -panel-width-mm: physical panel width [mm]
>> +   -panel-height-mm: physical panel height [mm]
>> +
>> +Example:
>> +
>> +   panel-lvds {
>> +   compatible = "panel-lvds";
>> +   led-en-gpio = <&gpx3 0 1>;
>> +   panel-prepare-delay = <40>;
>> +   panel-enable-delay = <20>;
>> +   panel-disable-delay = <20>;
>> +   panel-unprepare-delay = <30>;
>> +   panel-width-mm = <256>;
>> +   panel-height-mm = <144>;
>> +   };
>
> Recently it's considered a good practice to have the DT binding
> documentation in a separate patch.
Ok, will remember this.

>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 4ec874d..8fe7ee5 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -30,4 +30,14 @@ config DRM_PANEL_S6E8AA0
>> select DRM_MIPI_DSI
>> select VIDEOMODE_HELPERS
>>
>> +config DRM_PANEL_EDP_LVDS
>> +   tristate "support for eDP/LVDS panels"
>> +   depends on OF && DRM_PANEL
>> +   select VIDEOMODE_HELPERS
>> +   help
>> + DRM panel driver for direct eDP panels or LVDS connected
>> + via DP bridges, that need at most a regulator for LCD unit,
>> + a regulator for LED unit and/or enable GPIOs for LCD or LED units.
>> + Delay values can also be specified to support powerup and
>> + powerdown process.
>>  endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 8b9292

Re: [PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Ajay kumar]

Hi Gmeiner,

On Mon, Jun 23, 2014 at 12:55 PM, Christian Gmeiner
 wrote:
> Hi
>
>
> 2014-06-11 20:27 GMT+02:00 Ajay Kumar :
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BACKLIGHT_EN pin to
>> enable/ disable the backlight.
>> Sometimes, we can have LCD_EN switches as well.
>>
>> The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar 
>> Signed-off-by: Rahul Sharma 
>> ---
>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-lvds.c |  262 
>> 
>>  4 files changed, 323 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
>> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> new file mode 100644
>> index 000..7cb6084
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> @@ -0,0 +1,50 @@
>> +panel interface for eDP/lvds panels
>> +
>> +Required properties:
>> +  - compatible: "panel-lvds"
>> +
>> +Optional properties:
>> +   -lcd-en-gpio:
>> +   panel LCD poweron GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to powerup/enable the switch to the LCD panel.
>> +   -led-en-gpio:
>> +   panel LED enable GPIO.
>> +   Indicates which GPIO needs to be powered up as output
>> +   to enable the backlight.
>> +   -panel-prepare-delay:
>> +   delay value in ms required for panel_prepare process
>> +   Delay in ms needed for the panel LCD unit to
>> +   powerup completely.
>> +   ex: delay needed till eDP panel throws HPD.
>> +   delay needed so that we cans tart reading edid.
>> +   -panel-enable-delay:
>> +   delay value in ms required for panel_enable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   to powerup, and delay needed between video_enable and
>> +   backlight_enable.
>> +   -panel-disable-delay:
>> +   delay value in ms required for panel_disable process
>> +   Delay in ms needed for the panel backlight/LED unit
>> +   powerdown, and delay needed between backlight_disable
>> +   and video_disable.
>> +   -panel-unprepare-delay:
>> +   delay value in ms required for panel_post_disable process
>> +   Delay in ms needed for the panel LCD unit to
>> +   to powerdown completely, and the minimum delay needed
>> +   before powering it on again.
>> +   -panel-width-mm: physical panel width [mm]
>> +   -panel-height-mm: physical panel height [mm]
>> +
>
> For what are these two properties are needed?
Actually, these are needed to caluculate DPI(dots/pixels per inch).
That information will be used by the corresponding userspace to
deliver proper size fonts.
You can refer other panel drivers, even they too are using it!

Regards,
Ajay

> If I find some time I will give this patch a try as I need something
> like this for an imx6d based device.
That would be great, Thanks.

Ajay
--
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 3/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback

[Tushar Behera]

On 06/24/2014 09:41 AM, Nicolas Pitre wrote:
> The Chromebook firmware doesn't enable the CCI for the boot cpu, and
> arguably it shouldn't have to either. Let's have the kernel handle the
> CCI on its own for the boot CPU the same way it does it for secondary CPUs
> by using the MCPM loopback.
> 
> Signed-off-by: Nicolas Pitre 
> ---

Tested on top of next-20140623. Verified that all 8 cores are coming up
on Exynos5800 based Peach-pi board.

Tested-by: Tushar Behera 

>  arch/arm/mach-exynos/mcpm-exynos.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 0498d0b887..0c839f94ec 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -290,6 +290,19 @@ static void __naked exynos_pm_power_up_setup(unsigned 
> int affinity_level)
>   "b  cci_enable_port_for_self");
>  }
>  
> +static void __init exynos_cache_off(void)
> +{
> + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A15) {
> + /* disable L2 prefetching on the Cortex-A15 */
> + asm volatile(
> + "mcrp15, 1, %0, c15, c0, 3\n\t"
> + "isb\n\t"
> + "dsb"
> + : : "r" (0x400));
> + }
> + exynos_v7_exit_coherency_flush(all);
> +}
> +
>  static const struct of_device_id exynos_dt_mcpm_match[] = {
>   { .compatible = "samsung,exynos5420" },
>   { .compatible = "samsung,exynos5800" },
> @@ -333,6 +346,8 @@ static int __init exynos_mcpm_init(void)
>   ret = mcpm_platform_register(&exynos_power_ops);
>   if (!ret)
>   ret = mcpm_sync_init(exynos_pm_power_up_setup);
> + if (!ret)
> + ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
>   if (ret) {
>   iounmap(ns_sram_base_addr);
>   return ret;
> 


-- 
Tushar Behera
--
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 0/2] Sound support for Exynos4412 Odroid X2, U3 board

[Daniel Drake]

On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki
 wrote:
> I could reproduce such behaviour on the U3 board, but only with u-boot
> which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather
> than 800 MHz, which was the case in my original environment.
> All fout_mpll child clocks have then different frequency values
> in both cases.
> It's a bit strange though, because frequencies of all the audio
> subsystem clocks seem to be same anyway:

I'm using the standard uboot from hardkernel.

> # cat /sys/kernel/debug/clk/clk_summary

This command makes the kernel totally hang, weird.

# speaker-test -c 2 -t wav -l 2 -p 1024

This plays back fine.

Could it be a problem with the samsung-i2s driver, not correctly
flushing at the right times?
Or do you think the problem is more likely to be clock-related?

Thanks
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 V2 0/2] Sound support for Exynos4412 Odroid X2, U3 board

[Marek Szyprowski]

Hello,

On 2014-06-24 10:35, Daniel Drake wrote:

On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki
 wrote:

I could reproduce such behaviour on the U3 board, but only with u-boot
which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather
than 800 MHz, which was the case in my original environment.
All fout_mpll child clocks have then different frequency values
in both cases.
It's a bit strange though, because frequencies of all the audio
subsystem clocks seem to be same anyway:

I'm using the standard uboot from hardkernel.


# cat /sys/kernel/debug/clk/clk_summary

This command makes the kernel totally hang, weird.


This is known issue with clocks vs. ISP power domain. We should really 
fix this in exynos4 clock driver.



# speaker-test -c 2 -t wav -l 2 -p 1024

This plays back fine.

Could it be a problem with the samsung-i2s driver, not correctly
flushing at the right times?
Or do you think the problem is more likely to be clock-related?


Hard to say right now, but at least we need to test a bit more our 
solutions with different initial clocks configuration.


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: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> On 5/30/2014 12:06 PM, Arnd Bergmann wrote:
> > On Friday 30 May 2014 08:16:05 Rob Herring wrote:
> >> Presumably the ID would be the streamID on ARM's SMMU. How would a
> >> master with 8 streamIDs be described? This is what Calxeda midway has
> >> for SATA and I would expect that to be somewhat common. Either you
> >> need some ID masking or you'll have lots of duplication when you have
> >> windows.
> > 
> > I don't understand the problem. If you have stream IDs 0 through 7,
> > you would have
> > 
> > master@a {
> > ...
> > iommus = <&smmu 0>;
> > };
> > 
> > master@b {
> > ...
> > iommus = <&smmu 1;
> > };
> > 
> > ...
> > 
> > master@12 {
> > ...
> > iommus = <&smmu 7;
> > };
> > 
> > and you don't need a window at all. Why would you need a mask of
> > some sort?
> 
> We have multiple-master SMMUs and each master emits a variable number of
> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> for this) to the StreamIDs due to limited number of StreamID 2 Context
> Bank entries in the SMMU. If my understanding is correct we would
> represent this in the DT like this:
> 
>   iommu {
>   #address-cells = <2>;
>   #size-cells = <0>;
>   };
> 
>   master@a {
>   ...
>   iommus = <&iommu StreamID0 MASK0>,
><&iommu StreamID1 MASK1>,
><&iommu StreamID2 MASK2>;
>   };

Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?

Will
--
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

sdhci_s3c_consider_clock scheduling while atomic - clk_round_rate

[Daniel Drake]

sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts
disabled, and this calls into sdhci_s3c_consider_clock().

The patch "mmc: sdhci-s3c: Cache bus clock rates" addressed some
scheduling while atomic in this function, but there are more issues
here, seen while testing 3.16-rc2 on exynos4412:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:103
in_atomic(): 1, irqs_disabled(): 128, pid: 75, name: mmcqd/0
Preemption disabled at:[<  (null)>]   (null)

CPU: 0 PID: 75 Comm: mmcqd/0 Not tainted 3.16.0-rc2-00028-ge9fe7eb-dirty #77
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0xc4)
[] (dump_stack) from [] (mutex_lock+0x1c/0x3c)
[] (mutex_lock) from [] (clk_prepare_lock+0x6c/0xf4)
[] (clk_prepare_lock) from [] (clk_round_rate+0x10/0x2c)
[] (clk_round_rate) from [] (sdhci_s3c_set_clock+0x4c/0x1e8)
[] (sdhci_s3c_set_clock) from []
(sdhci_cmu_set_clock+0x54/0x140)
[] (sdhci_cmu_set_clock) from []
(sdhci_do_set_ios+0x138/0x58c)
[] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x28/0x34)

clk_round_rate cannot be called here because it takes a mutex.

sdhci_s3c_set_clock() also calls into clk_prepare_enable() which looks
like it could trigger this problem too.

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: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree

[Javier Martinez Canillas]

Hello Doug,

On 06/24/2014 06:05 AM, Doug Anderson wrote:
> Andreas,
> 
> On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber  wrote:
>> Hi Doug,
>>
>> Am 23.06.2014 21:47, schrieb Doug Anderson:
>>> Thanks for posting!  A first pass on this is below...
>>
>> Thanks a lot for your quick review! My first big .dts patch, and no
>> datasheets for the hardware at hand as a user.
>>
>> A first pass of replies to my defense. ;)
>>
>>> On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber  wrote:
>> [...]
 diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
 b/arch/arm/boot/dts/exynos5250-spring.dts
 new file mode 100644
 index 000..e857d44
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos5250-spring.dts
 @@ -0,0 +1,556 @@
 +/*
 + * Google Spring board device tree source
 + *
 + * Copyright (c) 2013 Google, Inc
 + * Copyright (c) 2014 SUSE LINUX Products GmbH
 + *
 + * 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.
 + */
 +
 +/dts-v1/;
 +#include "exynos5250.dtsi"
 +#include "exynos5250-cros-common.dtsi"
>>>
>>> It is possible we may want to backpedal on the use of
>>> "exynos5250-cros-common.dtsi".  I know that Olof (now CCed) said he
>>> wasn't a fan of how it turned out.
>>>
>>> The original idea was that it should include the arbitrary set of
>>> things that are common between a chunk of Chrome OS boards.  As more
>>> boards were introduced things would need to migrate from the "common"
>>> file to the board files.
>>>
>>> At the moment the current conventional wisdom is that some duplication
>>> is better than the confusing movement of everything back and forth.
>>> See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
>>>
>>>

Another option is to identify DTS fragments that are common across boards and
create .dtsi files for these specific chunks instead of trying to group all set
of common things on a single .dtsi file.

For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN
chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the
following files were created to reduce DTS duplication:

arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi

Now that I think about it, is the same that what you did for
arm/boot/dts/cros-ec-keyboard.dtsi.

Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it
more flexible/reusable?

 +/ {
 +   model = "Google Spring";
 +   compatible = "google,spring", "samsung,exynos5250", 
 "samsung,exynos5";
 +
 +   pinctrl@1140 {
>>>
>>> The new best way to do things is to put this down at the bottom.  See
>>> exynos5420-peach-pit as an example:
>>>
>>> &pinctrl_0 {
>>>   ...
>>> }
>>>
>>> Note that I believe it was decided that top-level references like that
>>> should be sorted alphabetically.
>>
>> Thanks for the hint. (My chosen sort order here was by address.)
>>
>>> If you wanted to apply that run to exynos5250-snow I don't think it
>>> would be a terrible idea.
>>
>> I can of course apply changes to Snow, but I cannot test them myself.
> 
> If you want to send up a patch like that I'm happy to give it a once
> over and also to test it.  ...but don't feel obligated
> 
> 
 +   s5m8767_dvs: s5m8767-dvs {
 +   samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
 +   samsung,pin-function = <0>;
 +   samsung,pin-pud = <1>;
 +   samsung,pin-drv = <0>;
 +   };
 +
 +   s5m8767_ds: s5m8767-ds {
 +   samsung,pins = "gpx2-3", "gpx2-4", "gpx2-5";
 +   samsung,pin-function = <0>;
 +   samsung,pin-pud = <1>;
 +   samsung,pin-drv = <0>;
 +   };
 +
 +   tps65090_irq: tps65090-irq {
 +   samsung,pins = "gpx2-6";
 +   samsung,pin-function = <0>;
 +   samsung,pin-pud = <0>;
 +   samsung,pin-drv = <0>;
 +   };
 +
 +   s5m8767_irq: s5m8767-irq {
 +   samsung,pins = "gpx3-2";
 +   samsung,pin-function = <0>;
 +   samsung,pin-pud = <0>;
 +   samsung,pin-drv = <0>;
 +   };
 +
 +   hdmi_hpd_irq: hdmi-hpd-irq {
 +   samsung,pins = "gpx3-7";
 +   samsung,pin-function = <0>;
 +   samsung,pin-pud = <1>;
 +   samsung,pin-drv = <0>;
 +   };
 +   };
 +
 +   pinctrl@1340 {
 +  

Re: [PATCH v2 02/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()

[Lee Jones]

On Wed, 18 Jun 2014, Doug Anderson wrote:

> From: Bill Richardson 
> 
> The lower-level driver may want to provide its own buffers. If so,
> there's no need to allocate new ones.  This already happens to work
> just fine (since we check for size of 0 and use devm allocation), but
> it's good to document it.
> 
> [dianders: Resolved conflicts; documented that no code changes needed
> on mainline]
> 
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Simon Glass 
> ---
> Changes in v2: None
> 
>  include/linux/mfd/cros_ec.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Lee Jones 

> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 7e9fe6e..2ee3190 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -68,8 +68,8 @@ struct cros_ec_msg {
>   * We use this alignment to keep ARM and x86 happy. Probably word
>   * alignment would be OK, there might be a small performance advantage
>   * to using dword.
> - * @din_size: size of din buffer
> - * @dout_size: size of dout buffer
> + * @din_size: size of din buffer to allocate (zero to use static din)
> + * @dout_size: size of dout buffer to allocate (zero to use static dout)
>   * @command_send: send a command
>   * @command_recv: receive a command
>   * @ec_name: name of EC device (e.g. 'chromeos-ec')

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 08/10] mfd: cros_ec: Check result code from EC messages

[Lee Jones]

On Wed, 18 Jun 2014, Doug Anderson wrote:

> From: Bill Richardson 
> 
> Just because the host was able to talk to the EC doesn't mean that the EC
> was happy with what it was told. Errors in communincation are not the same
> as error messages from the EC itself.
> 
> This change lets the EC report its errors separately.
> 
> [dianders: Added common function to cros_ec.c]
> 
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2:
> - Added common function to cros_ec.c
> - Changed to dev_dbg() as per http://crosreview.com/66726
> 
>  drivers/mfd/cros_ec.c   | 18 ++
>  drivers/mfd/cros_ec_i2c.c   |  8 +++-
>  drivers/mfd/cros_ec_spi.c   | 19 ++-
>  include/linux/mfd/cros_ec.h | 12 
>  4 files changed, 39 insertions(+), 18 deletions(-)

Acked-by: Lee Jones 

> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 4851ed2..83e30c6 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -44,6 +44,24 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_prepare_tx);
>  
> +int cros_ec_check_result(struct cros_ec_device *ec_dev,
> +  struct cros_ec_command *msg)
> +{
> + switch (msg->result) {
> + case EC_RES_SUCCESS:
> + return 0;
> + case EC_RES_IN_PROGRESS:
> + dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
> + msg->command);
> + return -EAGAIN;
> + default:
> + dev_dbg(ec_dev->dev, "command 0x%02x returned %d\n",
> + msg->command, msg->result);
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(cros_ec_check_result);
> +
>  static irqreturn_t ec_irq_thread(int irq, void *data)
>  {
>   struct cros_ec_device *ec_dev = data;
> diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
> index 5bb32f5..189e7d1 100644
> --- a/drivers/mfd/cros_ec_i2c.c
> +++ b/drivers/mfd/cros_ec_i2c.c
> @@ -92,12 +92,10 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device 
> *ec_dev,
>   }
>  
>   /* check response error code */
> - if (i2c_msg[1].buf[0]) {
> - dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
> -  msg->command, i2c_msg[1].buf[0]);
> - ret = -EINVAL;
> + msg->result = i2c_msg[1].buf[0];
> + ret = cros_ec_check_result(ec_dev, msg);
> + if (ret)
>   goto done;
> - }
>  
>   /* copy response packet payload and compute checksum */
>   sum = in_buf[0] + in_buf[1];
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 09ca789..c975087 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -289,21 +289,14 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device 
> *ec_dev,
>   goto exit;
>   }
>  
> - /* check response error code */
>   ptr = ec_dev->din;
> - if (ptr[0]) {
> - if (ptr[0] == EC_RES_IN_PROGRESS) {
> - dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
> - ec_msg->command);
> - ret = -EAGAIN;
> - goto exit;
> - }
> - dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
> -  ec_msg->command, ptr[0]);
> - debug_packet(ec_dev->dev, "in_err", ptr, len);
> - ret = -EINVAL;
> +
> + /* check response error code */
> + ec_msg->result = ptr[0];
> + ret = cros_ec_check_result(ec_dev, ec_msg);
> + if (ret)
>   goto exit;
> - }
> +
>   len = ptr[1];
>   sum = ptr[0] + ptr[1];
>   if (len > ec_msg->insize) {
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 60c0880..1f79f16 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -143,6 +143,18 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>  struct cros_ec_command *msg);
>  
>  /**
> + * cros_ec_check_result - Check ec_msg->result
> + *
> + * This is used by ChromeOS EC drivers to check the ec_msg->result for
> + * errors and to warn about them.
> + *
> + * @ec_dev: EC device
> + * @msg: Message to check
> + */
> +int cros_ec_check_result(struct cros_ec_device *ec_dev,
> +  struct cros_ec_command *msg);
> +
> +/**
>   * cros_ec_remove - Remove a ChromeOS EC
>   *
>   * Call this to deregister a ChromeOS EC, then clean up any private data.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/1] ARM: Kconfig.debug: Update Samsung UART config options

[Sachin Kamat]

In a multiplatform config, the low level debug option shows several
UART port entries. Improve the user visible string so that it becomes
clear to the user about Samsung UART ports.
While at it also remove some lines from the help text that are no
longer applicable across all Samsung platforms.

Signed-off-by: Sachin Kamat 
---
 arch/arm/Kconfig.debug |   20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 3548612b0bfe..b92993e59a12 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -617,53 +617,41 @@ choice
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
-   bool "Use S3C UART 0 for low-level debug"
+   bool "Use Samsung S3C UART 0 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
  their output to UART 0. The port must have been initialised
  by the boot-loader before use.
 
- The uncompressor code port configuration is now handled
- by CONFIG_S3C_LOWLEVEL_UART_PORT.
-
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
-   bool "Use S3C UART 1 for low-level debug"
+   bool "Use Samsung S3C UART 1 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
  their output to UART 1. The port must have been initialised
  by the boot-loader before use.
 
- The uncompressor code port configuration is now handled
- by CONFIG_S3C_LOWLEVEL_UART_PORT.
-
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
-   bool "Use S3C UART 2 for low-level debug"
+   bool "Use Samsung S3C UART 2 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
  their output to UART 2. The port must have been initialised
  by the boot-loader before use.
 
- The uncompressor code port configuration is now handled
- by CONFIG_S3C_LOWLEVEL_UART_PORT.
-
config DEBUG_S3C_UART3
depends on PLAT_SAMSUNG && ARCH_EXYNOS
select DEBUG_EXYNOS_UART
-   bool "Use S3C UART 3 for low-level debug"
+   bool "Use Samsung S3C UART 3 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
  their output to UART 3. The port must have been initialised
  by the boot-loader before use.
 
- The uncompressor code port configuration is now handled
- by CONFIG_S3C_LOWLEVEL_UART_PORT.
-
config DEBUG_S3C2410_UART0
depends on ARCH_S3C24XX
select DEBUG_S3C2410_UART
-- 
1.7.9.5

--
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 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb

[Lee Jones]

On Wed, 18 Jun 2014, Doug Anderson wrote:

> From: Andrew Bresticker 
> 
> If we receive EC interrupts after the cros_ec driver has probed, but
> before the cros_ec_keyb driver has probed, the cros_ec IRQ handler
> will not run the cros_ec_keyb notifier and the EC will leave the IRQ
> line asserted.  The cros_ec IRQ handler then returns IRQ_HANDLED and
> the resulting flood of interrupts causes the machine to hang.
> 
> Since the EC interrupt is currently only used for the keyboard, move
> the setup and handling of the EC interrupt to the cros_ec_keyb driver.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2:
> - IRQs should be optional => move EC interrupt to keyboard.
> 
>  drivers/input/keyboard/cros_ec_keyb.c | 58 
> ---
>  drivers/mfd/cros_ec.c | 35 +
>  include/linux/mfd/cros_ec.h   |  2 --
>  3 files changed, 34 insertions(+), 61 deletions(-)

For the MFD changes:
  Acked-by: Lee Jones 
 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
> b/drivers/input/keyboard/cros_ec_keyb.c
> index b8341ab..791781a 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -24,8 +24,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -42,7 +42,6 @@
>   * @dev: Device pointer
>   * @idev: Input device
>   * @ec: Top level ChromeOS device to use to talk to EC
> - * @event_notifier: interrupt event notifier for transport devices
>   */
>  struct cros_ec_keyb {
>   unsigned int rows;
> @@ -55,7 +54,6 @@ struct cros_ec_keyb {
>   struct device *dev;
>   struct input_dev *idev;
>   struct cros_ec_device *ec;
> - struct notifier_block notifier;
>  };
>  
>  
> @@ -173,22 +171,6 @@ static void cros_ec_keyb_process(struct cros_ec_keyb 
> *ckdev,
>   input_sync(ckdev->idev);
>  }
>  
> -static int cros_ec_keyb_open(struct input_dev *dev)
> -{
> - struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> -
> - return blocking_notifier_chain_register(&ckdev->ec->event_notifier,
> - &ckdev->notifier);
> -}
> -
> -static void cros_ec_keyb_close(struct input_dev *dev)
> -{
> - struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> -
> - blocking_notifier_chain_unregister(&ckdev->ec->event_notifier,
> -&ckdev->notifier);
> -}
> -
>  static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t 
> *kb_state)
>  {
>   struct cros_ec_command msg = {
> @@ -203,19 +185,41 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb 
> *ckdev, uint8_t *kb_state)
>   return ckdev->ec->cmd_xfer(ckdev->ec, &msg);
>  }
>  
> -static int cros_ec_keyb_work(struct notifier_block *nb,
> -  unsigned long state, void *_notify)
> +static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
>  {
> + struct cros_ec_keyb *ckdev = data;
> + struct cros_ec_device *ec = ckdev->ec;
>   int ret;
> - struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
> - notifier);
>   uint8_t kb_state[ckdev->cols];
>  
> + if (device_may_wakeup(ec->dev))
> + pm_wakeup_event(ec->dev, 0);
> +
>   ret = cros_ec_keyb_get_state(ckdev, kb_state);
>   if (ret >= 0)
>   cros_ec_keyb_process(ckdev, kb_state, ret);
> + else
> + dev_err(ec->dev, "failed to get keyboard state: %d\n", ret);
>  
> - return NOTIFY_DONE;
> + return IRQ_HANDLED;
> +}
> +
> +static int cros_ec_keyb_open(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> + struct cros_ec_device *ec = ckdev->ec;
> +
> + return request_threaded_irq(ec->irq, NULL, cros_ec_keyb_irq,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + "cros_ec_keyb", ckdev);
> +}
> +
> +static void cros_ec_keyb_close(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> + struct cros_ec_device *ec = ckdev->ec;
> +
> + free_irq(ec->irq, ckdev);
>  }
>  
>  static int cros_ec_keyb_probe(struct platform_device *pdev)
> @@ -246,8 +250,12 @@ static int cros_ec_keyb_probe(struct platform_device 
> *pdev)
>   if (!idev)
>   return -ENOMEM;
>  
> + if (!ec->irq) {
> + dev_err(dev, "no EC IRQ specified\n");
> + return -EINVAL;
> + }
> +
>   ckdev->ec = ec;
> - ckdev->notifier.notifier_call = cros_ec_keyb_work;
>   ckdev->dev = dev;
>   dev_set_drvdata(&pdev->dev, ckdev);
>  
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 83e30c6..4873f9c 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -62,18 +62,6 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
>  }
>  EXPOR

Re: [PATCH v3 0/4] ASoc: samsung: update s3c24xx to dmaengine and common clk framework

[Mark Brown]

On Mon, Jun 23, 2014 at 11:24:03PM +0300, Vasily Khoruzhick wrote:
> This series updates s3c24{xx,12}-i2s driver to use newer DMA and CLK APIs.

Applied all, thanks.


signature.asc
Description: Digital signature

RE: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices

[Pankaj Dubey]

Hi,

On Wednesday, June 18 2014, Lee Jones wrote:
> On Tue, 17 Jun 2014, Tomasz Figa wrote:
> > On 17.06.2014 17:42, Arnd Bergmann wrote:
> > > On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
> > >> Currently a syscon entity can be only registered directly through a
> > >> platform device that binds to a dedicated driver. However in
> > >> certain use cases it is desirable to make a device used with
> > >> another driver a syscon interface provider. For example, certain
> > >> SoCs (e.g. Exynos) contain system controller blocks which perform
> > >> various functions such as power domain control, CPU power
> > >> management, low power mode control, but in addition contain certain
> > >> IP integration glue, such as various signal masks, coprocessor
> > >> power control, etc. In such case, there is a need to have a
> > >> dedicated driver for such system controller but also share
> > >> registers with other drivers. The latter is where the syscon interface 
> > >> is helpful.
> > >>
> > >> This patch decouples syscon object from syscon driver, so that it
> > >> can be registered from any driver in addition to the original
> > >> "syscon" platform driver.
> 
> +1 for this approach.
> 
> Michal, Pankay,
>   Does it also suit your needs?
> 

Sorry for late reply. 
I tested this patch after changing exynos PMU to be a syscon provider and it's 
working well.
So if we can address Arnd's comments, this patch will be helpful in making 
exynos PMU a 
complete platform driver.

Thanks,
Pankaj Dubey

> > >> Signed-off-by: Tomasz Figa 
> > >
> > > Hi Tomasz,
> > >
> > > This seems like a reasonable way of solving the problem, but I think
> > > there is an even better one that we have about in the past: if we
> > > promote syscon from a platform driver into a a drivers/base/ helper
> > > that is independent of the platform device matching, we can use call
> > > syscon_regmap_lookup_* for any device node, whether it's already
> > > bound to a driver or not, which do what you need. It would also make
> > > it easier to call the syscon code before the platform_device
> > > infrastructure gets initialized, which is something a number of
> > > people have asked for, e.g. for using regmap to do SMP bringup or
> > > for clock registration.
> >
> > Basically, unless I'm missing your point, this is what my patch does,
> > except that I don't move it to drivers/base/ and the registration
> > function I added require a pointer to struct device. Indeed,
> > decoupling it further from the driver model, by adding
> > of_syscon_register() should be useful for early users.
> 
> If agreed by Arnd, I think this work can be completed as a subsequent patch.
> 
> > Should I move this to drivers/base/, even though from current location
> > it can be used outside the platform driver anyway?
> 
> If I'm being honest with myself, I'd say that Syscon wasn't really an MFD 
> driver.  I'm
> happy to keep it in there any continue maintaining it, but wouldn't block a 
> move
> either.
> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software
> for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

--
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: MMC error on Exynos4210 board

[Ulf Hansson]

On 23 juni 2014 06:30:08 CEST, Sachin Kamat  wrote:
>Hi Tim,
>
>On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger 
>wrote:
>> On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat 
>wrote:
>>> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung
> wrote:
 On 06/19/2014 07:40 PM, Sachin Kamat wrote:
> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger 
>wrote:
>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat
> wrote:
>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger
> wrote:
 On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat
> wrote:
>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat
> wrote:

>>> I see the below error on Exynos4210 based Origen board with
>linux-next
>>> (20140618).
>>> Reverting the below commit works fine.
>>>
>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator
>infrastucture"

>>>
>>> -- [2.068992] sdhci: Secure Digital Host Controller
>Interface driver
>>> [2.075059] sdhci: Copyright(c) Pierre Ossman
>>> [2.079762] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1251[0]'
>>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2:
>mmc_busclk.2
>>> (5000 Hz)
>>> [2.095322] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1251[0]'
>>> [2.103794] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1251[0]'
>>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator
>found
>>> [2.118117] mmc0: Hardware doesn't report any support
>voltages.
>>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host()
>failed
>>> [2.130080] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1253[0]'
>>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2:
>mmc_busclk.2
>>> (1667 Hz)
>>> [2.145661] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1253[0]'
>>> [2.154139] of_get_named_gpiod_flags: can't parse gpios
>property of
>>> node '/sdhci@1253[0]'
>>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator
>found
>>> [2.168464] mmc0: Hardware doesn't report any support
>voltages.
>>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host()
>failed

>>> [2.336148] Waiting for root device /dev/mmcblk0p1...

> FYI, the board has a 2.8V fixed regulator supply connected to
>the MMC.
> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for
>more details.

 A 2.8v regulator results in mmc->ocr_avail being set to
>MMC_VDD_27_28
 | MMC_VDD_28_29.

 The SDHCI capabilities register only indicates support of three
>voltage levels
   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34

 Right. sdhci capabilities only indicated them.
 But I think SoC can be support the specific VDD range.


 Even if all capability bits of the host controller were set,
>there
 still wouldn't be any overlap.  Thus you see a "Hardware
>doesn't
 report any support voltages" message.

 Previously, this issue was being swept under the rug by cec2e21
>mmc:
 sdhci: Use regulator min/max voltage range according to spec. 
>That
 change hacked up the voltage range checks such that with your
>2.8v
 fixed regulator, the driver would believe the host could
>support
 MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. 
>The
 driver would start down the path of commanding 3.3v-3.4v (the
>highest
 voltage range believed to be supported).  At the last second,
>the
 driver would see the regulator was fixed and blindly skip over
>the set
 voltage operation, saving it from failure.

 Since my patch eliminates the bogus voltage range checks, your
>board
 is now getting caught playing too loose with the SDHCI
>regulator
 voltages.

 Furthermore, the fixed regulator special-case logic that helped
>hide
 your issue should also be considered for removal given that
>fixed
 regulators now behave properly thanks to c00dc35 regulator:
>core:
 Allow regulator_set_voltage for fixed regulators.
>>>
>>> Thanks for the detailed explanation. What do you propose to get
>this fixed
>>
>> It would be nice if the driver could be extended
>> to handle the peculiarities of your board in a deliberate manner
>but
>> limiting the common sdhci driver to supporting only the three
>voltages
>> from the spec also seems sensible.
>
> Until such time that the 

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay Kumar]

Add the missing setting for DP CLKCON register.

This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
 include/video/samsung_fimd.h |4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+   unsigned int has_dp_clkcon:1;
 };
 
 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+   .has_dp_clkcon = 1,
 };
 
 struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
 
+   if (ctx->driver_data->has_dp_clkcon)
+   writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
 }
 
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
 #define BLENDCON_NEW_8BIT_ALPHA_VALUE  (1 << 0)
 #define BLENDCON_NEW_4BIT_ALPHA_VALUE  (0 << 0)
 
+/* Video clock enable for DP */
+#define DP_CLKCON  0x27C
+#define DP_CLK_ENABLE  0x2
+
 /* Notes on per-window bpp settings
  *
  * Value   Win0 Win1 Win2 Win3 Win 4
-- 
1.7.9.5

--
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 v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU.

[Pankaj Dubey]

Hi Tomasz,

On Tuesday, June 17 2014, Tomasz Figa wrote:
> Hi Pankaj,
> 
> [dropping Young-Gun Jang , as my mailer denies to
> send to this address]
> 

Yes, we can drop Young-Gun Jang's email id as it's no more valid.

> Please see my comments inline. I have skipped comments for changed related
to
> regmap, as according to our previous discussion they will be dropped in
next version.
> 
> On 10.05.2014 08:56, Pankaj Dubey wrote:
> > This patch modifies Exynos Power Management Unit (PMU) initialization
> > implementation in following way:
> >
> > - Added platform_device support by registering static platform device.
> > - Added platform struct exynos_pmu_data to hold platform specific data.
> > - For each SoC's PMU support now we can add platform data and statically
> >   bind PMU configuration and SoC specific initialization function.
> > - Probe function will scan DT and based on matching PMU compatibility
> >   string initialize pmu_context which will be platform_data for driver.
> > - Obtain PMU regmap handle using "syscon_regmap_lookup_by_phandle" so
> >   that we can reduce dependency over machine header files.
> > - Separate each SoC's PMU initialization function and make it as part of
> >   platform data.
> > - It also removes uses of soc_is_exynosXYZ() thus making PMU
implementation
> >   independent of "plat/cpu.h".
> >
> > Signed-off-by: Pankaj Dubey 
> > Signed-off-by: Young-Gun Jang 
> > ---
> >  arch/arm/mach-exynos/pmu.c |  266
> > ++--
> >  1 file changed, 210 insertions(+), 56 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> > index 67116a5..6a7fa8e 100644
> > --- a/arch/arm/mach-exynos/pmu.c
> > +++ b/arch/arm/mach-exynos/pmu.c
> > @@ -1,5 +1,5 @@
> >  /*
> > - * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
> > + * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
> >   * http://www.samsung.com/
> >   *
> >   * EXYNOS - CPU PMU(Power Management Unit) support @@ -9,20 +9,33
> @@
> >   * published by the Free Software Foundation.
> >   */
> >
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >
> >  #include "common.h"
> >  #include "regs-pmu.h"
> >
> > -static const struct exynos_pmu_conf *exynos_pmu_config; -static
> > struct regmap *pmu_regmap;
> > +struct exynos_pmu_data {
> > +   const struct exynos_pmu_conf *pmu_config;
> > +   const struct exynos_pmu_conf *pmu_config_extra;
> > +   void (*pmu_init)(void);
> > +   void (*powerdown_conf)(enum sys_powerdown); };
> > +
> > +struct exynos_pmu_context {
> > +   struct device *dev;
> > +   struct exynos_pmu_data *pmu_data;
> > +   struct regmap   *pmu_regmap;
> > +};
> > +
> > +static struct exynos_pmu_context   *pmu_context;
> >
> >  static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
> > -   /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
> > +   /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
> 
> AFAICT those have changed already in patch 08/11.
>

Will correct this.
 
> > { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
> > { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
> > { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
> > @@ -216,7 +229,7 @@ static const struct exynos_pmu_conf
> > exynos4412_pmu_config[] = {  };
> >
> >  static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
> > -   /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
> > +   /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
> 
> Ditto.
> 
> > { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2}
> },
> > { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  {
> 0x0, 0x0, 0x0} },
> > { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{
> 0x0, 0x0, 0x0} },
> > @@ -339,7 +352,7 @@ static unsigned int const
exynos5_list_diable_wfi_wfe[] =
> {
> > EXYNOS5_ISP_ARM_OPTION,
> >  };
> >
> > -static void exynos5_init_pmu(void)
> > +void exynos5_powerdown_conf(enum sys_powerdown mode)
> 
> static
> 


OK.

> >  {
> > unsigned int i;
> > unsigned int tmp;
> > @@ -348,81 +361,222 @@ static void exynos5_init_pmu(void)
> >  * Enable both SC_FEEDBACK and SC_COUNTER
> >  */
> > for (i = 0 ; i < ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
> > -   regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i],
&tmp);
> > +   regmap_read(pmu_context->pmu_regmap,
> > +   exynos5_list_both_cnt_feed[i], &tmp);
> > tmp |= (EXYNOS5_USE_SC_FEEDBACK |
> > EXYNOS5_USE_SC_COUNTER);
> > -   regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i],
tmp);
> > +   regmap_write(pmu_context->pmu_regmap,
> > +   exynos5_list_both_cnt_feed[i], tmp);
> > }
> >
> > /*
> >  * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
> >  */
> > -   regmap_read(pmu_regmap, E

Re: [PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Andreas Färber]

Am 24.06.2014 07:21, schrieb Inki Dae:
> On 2014년 06월 23일 14:32, Rahul Sharma wrote:
>> Allowing only one layer update per vsync can cause issues
>> while there are update available for both layers. There is
>> a good amount of possibility to loose updates if we allow
>> single update per vsync.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index d359501..6773b03 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
>> int win)
>>  static void mixer_layer_update(struct mixer_context *ctx)
>>  {
>>  struct mixer_resources *res = &ctx->mixer_res;
>> -u32 val;
>> -
>> -val = mixer_reg_read(res, MXR_CFG);
>>  
>> -/* allow one update per vsync only */
>> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
>> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> 
> Rahul, it looks good to me and ok as is. But above codes don't consider
> Exynos4 series. In case of Exynos4xxx SoC,
> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
> register are reserved fields. So can you work that patch to be
> considered for Exynos4xxx SoC? That patch would be additional one.
> 
> Anyway, will apply it as is, and I will wait for the additional patch.

If it's not too late, could you fix up "multiple" in the subject? :)

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 4/4] ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3

[Marek Szyprowski]

Hello,

On 2014-06-19 14:43, Daniel Drake wrote:

On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski
 wrote:

This patch moves some parts of exynos4412-odroidx.dts to common
exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and
U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz
instead of 1.4GHz), while U2/U3 differs from X2 by different way of
routing signals to host USB hub. It also lacks some hw modules not yet
supported by those dts files (i.e. LCD & touch panel).

Thanks for this! It is working on ODROID-U2: at least eMMC/SD, LED, serial.

Just 2 minor questions from reviewing:

Odroid-X DTS used to have serial ports at 1382 and 1383, this
patch removes them, but leaves 2.


Right. I've forgot the UART port change. Now I've checked it again and
schematics reveals that Odroid X/X2 and U2/U3 has UART1 available on UART
connector. On the other hand U2/U3 have UART0 RX/TX lines on GPIO connector,
while X/X2 has UART3 lines on the LCD/GPIO connector.


I can understand the idea of removing entries for ports that are not
available on the board, but I've never seen an ODROID with 2 serial
ports - should we bring this down to just the 1 enabled serial port
that is accessible?


That would be best solution, but this way the tty driver name will change
from ttySAC1 to ttySAC0 for UART1 port. Until uart driver gets fixed, I
would keep all 4 uart defined on X/X2 and define only uart 0 and 1 on
U2/U3. I will fix this in the next version of Odroid patches.


Odroid-X DTS used to enable EHCI port 2, but with this refactoring, no
longer does. Intentional?


This was a bug in the initial patch adding usb support. X and X2 uses only
HSCI0 port (ehci port 1).

Thanks for your review!

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

[PATCH 0/4] hwmon: ntc_thermistor: prepose vendor prefix change

[Naveen Krishna Chatradhi]

As Murata is the manufacturer of the NTC (Negative Temperature coefficient)
based Thermistors. ntc_thermistor driver extensively used the prefix "ntc".
But, vendor-prefix should be "murata" instead of "ntc".

This patchset
1. Updates the vendor-prefix, DT bindings and Documentation,
   where ever necessary.
2. Adds thermistor nodes to Exynos5420 and Exynos5800 based boards.

Patches:
1/4. devicetree: bindings: Document murata vendor prefix
 Adds the vendor prefix "murata" to vendor-prefixes.txt.
2/4. hwmon: ntc_thermistor: Use the manufacturer name properly
 Updates the driver, Kconfig, device tree bindings and Documentation
 with the Manufacturer/vendor information.
3/4. ARM: DTS: use new compatible string as per the documentation
 Updates the device node in Exynos4412 based Trats2 board
 with the new device tree bindings.
4/4. ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
 Adds Thermistor nodes to Exynos5420 and Exynos5800 based boards.

This patchset
Naveen Krishna Chatradhi (4):
  devicetree: bindings: Document murata vendor prefix
  hwmon: ntc_thermistor: Use the manufacturer name properly
  ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
  ARM: DTS: use new compatible string as per the documentation

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   12 
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 Documentation/hwmon/ntc_thermistor |8 ++---
 arch/arm/boot/dts/exynos4412-trats2.dts|4 +--
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   32 
 drivers/hwmon/Kconfig  |5 +--
 drivers/hwmon/ntc_thermistor.c |   12 
 8 files changed, 55 insertions(+), 21 deletions(-)

-- 
1.7.9.5

--
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 1/4] devicetree: bindings: Document murata vendor prefix

[Naveen Krishna Chatradhi]

Add Murata Manufacturing Co., Ltd. to the list of device tree
vendor prefixes.

Murata manufactures NTC (Negative Temperature Coefficient) based
Thermistors for small scale applications like Mobiles and PDAs.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Guenter Roeck 
---
This changes is needed for the following reasons

1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
   Thus, giving an error when checked with scripts/checkpatch.pl
2. Murata Manufacturing Co., Ltd. Is the vendor for the
   NTC (Negative Temperature Coefficient) based thermistors.
   Hence, "murata" is the right vendor-prefix, Not "ntc".
3. NTC is a technology used, But the prefix "ntc" is wrongly
   and heavily used in the driver and the documentation.

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4d7f375..a39b7d7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -84,6 +84,7 @@ moxa  Moxa
 mplMPL AG
 mundoreaderMundo Reader S.L.
 mxicy  Macronix International Co., Ltd.
+murata Murata Manufacturing Co., Ltd.
 national   National Semiconductor
 neonodeNeonode Inc.
 netgearNETGEAR
-- 
1.7.9.5

--
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 3/4] ARM: DTS: use new compatible string as per the documentation

[Naveen Krishna Chatradhi]

As Murata is the Manufactures the NTC thermistors. The vendor
name in the compatibility is preposed to change to "murata, ncpXXX"

This patch uses the new compatibility string in exynos4412 based
Trats2 board.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Chanwoo Choi 
---
1. Updates the thermistor node in Exynos4412 based Trats2 dts
   using the new DT bindings for NTC thermistors updated with vendor-prefix

 arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
 
thermistor-ap@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;   /* VCC_1.8V_AP */
pullup-ohm = <10>;   /* 100K */
pulldown-ohm = <10>; /* 100K */
@@ -779,7 +779,7 @@
};
 
thermistor-battery@1 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;   /* VCC_1.8V_AP */
pullup-ohm = <10>;   /* 100K */
pulldown-ohm = <10>; /* 100K */
-- 
1.7.9.5

--
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 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly

[Naveen Krishna Chatradhi]

Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses "NTC" as the vendor name.

This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Guenter Roeck 
---
This changes is needed for the following reasons

1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
   Thus, giving an error when checked with scripts/checkpatch.pl
2. Murata Manufacturing Co., Ltd. Is the vendor for the
   NTC (Negative Temperature Coefficient) based thermistors.
   Hence, "murata" is the right vendor-prefix, Not "ntc".
3. NTC is a technology used, But the prefix "ntc" is wrongly
   and heavily used in the driver and the documentation.

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   12 ++--
 Documentation/hwmon/ntc_thermistor |8 
 drivers/hwmon/Kconfig  |5 +++--
 drivers/hwmon/ntc_thermistor.c |   12 ++--
 5 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
 
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..4e9f344 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
 
 Requires node properties:
 - "compatible" value : one of
-   "ntc,ncp15wb473"
-   "ntc,ncp18wb473"
-   "ntc,ncp21wb473"
-   "ntc,ncp03wb473"
-   "ntc,ncp15wl333"
+   "murata,ncp15wb473"
+   "murata,ncp18wb473"
+   "murata,ncp21wb473"
+   "murata,ncp03wb473"
+   "murata,ncp15wl333"
 - "pullup-uv"  Pull up voltage in micro volts
 - "pullup-ohm" Pull up resistor value in ohms
 - "pulldown-ohm" Pull down resistor value in ohms
@@ -21,7 +21,7 @@ Read more about iio bindings at
 
 Example:
ncp15wb473@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
diff --git a/Documentation/hwmon/ntc_thermistor 
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
 Kernel driver ntc_thermistor
 =
 
-Supported thermistors:
+Supported thermistors from Murata:
 * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, 
NCP15WL333
   Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 
'ncp15wl333'
   Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
 Description
 ---
 
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
 
 The NTC driver provides lookup tables with a linear approximation function
 and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
  will be called pc87427.
 
 config SENSORS_NTC_THERMISTOR
-   tristate "NTC thermistor support"
+   tristate "NTC based thermistor support from Murata"
depends on !OF || IIO=n || IIO
help
  This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
  send notifications about the temperature.
 
  Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333.
+ NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333
+ from Murata.
 
  This driver can also be built as a module.  If so, the module
  will be called ntc-thermistor.
diff --git a/drivers/hwmon/ntc_thermi

[PATCH 4/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC

[Naveen Krishna Chatradhi]

Exynos5420 based Peach PIT and Exynos5800 based PI boards have
4 NTC thermistors to measure temperatures at various points on the
board.

IIO based ADC becomes the parent and NTC thermistors are the childs,
via the HWMON interface.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Doug Anderson 
---
This patch needs
1. MAX77802 PMIC device tree nodes (for ldo9)
   https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
2. Uses the DT documentation for NTC thermistors updated with vendor-prefix

 arch/arm/boot/dts/exynos5420-peach-pit.dts |   32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index b96a66a..852a220 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -751,4 +751,36 @@
timeout-sec = <32>;
 };
 
+&adc {
+   vdd-supply = <&ldo9_reg>;
+   ncp15wb473@3 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 3>;
+   };
+   ncp15wb473@4 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 4>;
+   };
+   ncp15wb473@5 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 5>;
+   };
+   ncp15wb473@6 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 6>;
+   };
+};
+
 #include "cros-ec-keyboard.dtsi"
-- 
1.7.9.5

--
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] phy: phy-samsung-usb2: Change phy power on/power off sequence

[Kamil Debski]

The Exynos4412 USB 2.0 PHY hardware differs from the description provided
in the documentation. Some register bits have different function. This
patch fixes the defines of register bits and changes the way how phys are
powered on and off.

Signed-off-by: Kamil Debski 
---
 drivers/phy/phy-exynos4x12-usb2.c |  112 +
 drivers/phy/phy-samsung-usb2.h|3 +-
 2 files changed, 77 insertions(+), 38 deletions(-)

diff --git a/drivers/phy/phy-exynos4x12-usb2.c 
b/drivers/phy/phy-exynos4x12-usb2.c
index d92a7cc..59d8dd3 100644
--- a/drivers/phy/phy-exynos4x12-usb2.c
+++ b/drivers/phy/phy-exynos4x12-usb2.c
@@ -86,13 +86,23 @@
 #define EXYNOS_4x12_URSTCON_OTG_HLINK  BIT(1)
 #define EXYNOS_4x12_URSTCON_OTG_PHYLINKBIT(2)
 #define EXYNOS_4x12_URSTCON_HOST_PHY   BIT(3)
+/* The following bit defines are presented in the
+ * order taken from the Exynos4412 reference manual.
+ *
+ * During experiments with the hardware and debugging
+ * it was determined that the hardware behaves contrary
+ * to the manual.
+ *
+ * The following bit values were chaned accordingly to the
+ * results of real hardware experiments.
+ */
 #define EXYNOS_4x12_URSTCON_PHY1   BIT(4)
-#define EXYNOS_4x12_URSTCON_HSIC0  BIT(5)
-#define EXYNOS_4x12_URSTCON_HSIC1  BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC0  BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC1  BIT(5)
 #define EXYNOS_4x12_URSTCON_HOST_LINK_ALL  BIT(7)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P0   BIT(8)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P0   BIT(10)
 #define EXYNOS_4x12_URSTCON_HOST_LINK_P1   BIT(9)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P2   BIT(10)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P2   BIT(8)
 
 /* Isolation, configured in the power management unit */
 #define EXYNOS_4x12_USB_ISOL_OFFSET0x704
@@ -188,6 +198,7 @@ static void exynos4x12_setup_clk(struct 
samsung_usb2_phy_instance *inst)
clk = readl(drv->reg_phy + EXYNOS_4x12_UPHYCLK);
clk &= ~EXYNOS_4x12_UPHYCLK_PHYFSEL_MASK;
clk |= drv->ref_reg_val << EXYNOS_4x12_UPHYCLK_PHYFSEL_OFFSET;
+   clk |= EXYNOS_4x12_UPHYCLK_PHY1_COMMON_ON;
writel(clk, drv->reg_phy + EXYNOS_4x12_UPHYCLK);
 }
 
@@ -198,27 +209,22 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
u32 phypwr = 0;
u32 rst;
u32 pwr;
-   u32 mode = 0;
-   u32 switch_mode = 0;
 
switch (inst->cfg->id) {
case EXYNOS4x12_DEVICE:
phypwr =EXYNOS_4x12_UPHYPWR_PHY0;
rstbits =   EXYNOS_4x12_URSTCON_PHY0;
-   mode =  EXYNOS_4x12_MODE_SWITCH_DEVICE;
-   switch_mode =   1;
break;
case EXYNOS4x12_HOST:
phypwr =EXYNOS_4x12_UPHYPWR_PHY1;
-   rstbits =   EXYNOS_4x12_URSTCON_HOST_PHY;
-   mode =  EXYNOS_4x12_MODE_SWITCH_HOST;
-   switch_mode =   1;
+   rstbits =   EXYNOS_4x12_URSTCON_HOST_PHY |
+   EXYNOS_4x12_URSTCON_PHY1 |
+   EXYNOS_4x12_URSTCON_HOST_LINK_P0;
break;
case EXYNOS4x12_HSIC0:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC0;
-   rstbits =   EXYNOS_4x12_URSTCON_HSIC1 |
-   EXYNOS_4x12_URSTCON_HOST_LINK_P0 |
-   EXYNOS_4x12_URSTCON_HOST_PHY;
+   rstbits =   EXYNOS_4x12_URSTCON_HSIC0 |
+   EXYNOS_4x12_URSTCON_HOST_LINK_P1 ;
break;
case EXYNOS4x12_HSIC1:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC1;
@@ -228,11 +234,6 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
};
 
if (on) {
-   if (switch_mode)
-   regmap_update_bits(drv->reg_sys,
-  EXYNOS_4x12_MODE_SWITCH_OFFSET,
-  EXYNOS_4x12_MODE_SWITCH_MASK, mode);
-
pwr = readl(drv->reg_phy + EXYNOS_4x12_UPHYPWR);
pwr &= ~phypwr;
writel(pwr, drv->reg_phy + EXYNOS_4x12_UPHYPWR);
@@ -253,41 +254,78 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
}
 }
 
-static int exynos4x12_power_on(struct samsung_usb2_phy_instance *inst)
+static void exynos4x12_power_on_internal(struct samsung_usb2_phy_instance 
*inst)
 {
-   struct samsung_usb2_phy_driver *drv = inst->drv;
+   if (inst->int_cnt++ > 0)
+   return;
 
-   inst->enabled = 1;
exynos4x12_setup_clk(inst);
-   exynos4x12_phy_pwr(inst, 1);
exynos4x12_isol(inst, 0);
+   exynos4x12_phy_pwr(inst, 1);
+}
+
+static int exynos4x12_power_on(struct samsung_usb2_phy_instance *inst)
+{
+   struct samsung_us

Re: [PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

Hi Ajay,

On 06/24/2014 01:09 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>  include/video/samsung_fimd.h |4 
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..5d3045d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .timing_base = 0x2,
>   .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
>  };
>  
>  struct fimd_win_data {
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (ctx->driver_data->has_dp_clkcon)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +

This code always enables the clock on exynos5. As I understand it should
be enabled only if DP is used.

Regards
Andrzej


>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 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] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay kumar]

On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  wrote:
> Hi Ajay,
>
> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be used if we are using DP.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>>  include/video/samsung_fimd.h |4 
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 33161ad..5d3045d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>   unsigned int has_shadowcon:1;
>>   unsigned int has_clksel:1;
>>   unsigned int has_limited_fmt:1;
>> + unsigned int has_dp_clkcon:1;
>>  };
>>
>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>   .timing_base = 0x2,
>>   .has_shadowcon = 1,
>> + .has_dp_clkcon = 1,
>>  };
>>
>>  struct fimd_win_data {
>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>   if (clkdiv > 1)
>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (ctx->driver_data->has_dp_clkcon)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>> +
>
> This code always enables the clock on exynos5. As I understand it should
> be enabled only if DP is used.
Right!
But, when I searched for the display interface,
only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
So, I thought adding this in driver_data for exynos5 should be fine.

Inki/Andrej - Shall I add it as an optional DT property?

Ajay
>
>
>>   writel(val, ctx->regs + VIDCON0);
>>  }
>>
>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> index b039320..d8f4b0b 100644
>> --- a/include/video/samsung_fimd.h
>> +++ b/include/video/samsung_fimd.h
>> @@ -435,6 +435,10 @@
>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>
>> +/* Video clock enable for DP */
>> +#define DP_CLKCON0x27C
>> +#define DP_CLK_ENABLE0x2
>> +
>>  /* Notes on per-window bpp settings
>>   *
>>   * Value Win0 Win1 Win2 Win3 Win 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 1/4] devicetree: bindings: Document murata vendor prefix

[Mark Rutland]

On Tue, Jun 24, 2014 at 01:19:13PM +0100, Naveen Krishna Chatradhi wrote:
> Add Murata Manufacturing Co., Ltd. to the list of device tree
> vendor prefixes.
> 
> Murata manufactures NTC (Negative Temperature Coefficient) based
> Thermistors for small scale applications like Mobiles and PDAs.
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Guenter Roeck 
> ---
> This changes is needed for the following reasons
> 
> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>Thus, giving an error when checked with scripts/checkpatch.pl
> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>NTC (Negative Temperature Coefficient) based thermistors.
>Hence, "murata" is the right vendor-prefix, Not "ntc".
> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>and heavily used in the driver and the documentation.
> 
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 4d7f375..a39b7d7 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -84,6 +84,7 @@ moxaMoxa
>  mpl  MPL AG
>  mundoreader  Mundo Reader S.L.
>  mxicyMacronix International Co., Ltd.
> +murata   Murata Manufacturing Co., Ltd.

Nit: please keep this list in alphabetical order.

Otherwise, this looks fine to me. With the order fixed:

Acked-by: Mark Rutland 

Mark.

>  national National Semiconductor
>  neonode  Neonode Inc.
>  netgear  NETGEAR
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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

Re: [PATCH 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly

[Mark Rutland]

On Tue, Jun 24, 2014 at 01:19:14PM +0100, Naveen Krishna Chatradhi wrote:
> Murata Manufacturing Co., Ltd is the vendor for
> NTC (Negative Temperature coefficient) based Thermistors.
> But, the driver extensively uses "NTC" as the vendor name.
> 
> This patch corrects the vendor name also updates the
> compatibility strings according to the vendor-prefix.txt
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Guenter Roeck 
> ---
> This changes is needed for the following reasons
> 
> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>Thus, giving an error when checked with scripts/checkpatch.pl
> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>NTC (Negative Temperature Coefficient) based thermistors.
>Hence, "murata" is the right vendor-prefix, Not "ntc".
> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>and heavily used in the driver and the documentation.
> 
>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   12 ++--
>  Documentation/hwmon/ntc_thermistor |8 
>  drivers/hwmon/Kconfig  |5 +++--
>  drivers/hwmon/ntc_thermistor.c |   12 ++--
>  5 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index 5d49f2b..832fe8c 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -48,7 +48,7 @@ adc@12D1 {
>  
>   /* NTC thermistor is a hwmon device */
>   ncp15wb473@0 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";
>   pullup-uv = <180>;
>   pullup-ohm = <47000>;
>   pulldown-ohm = <0>;
> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> index c6f6667..4e9f344 100644
> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> @@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
>  
>  Requires node properties:
>  - "compatible" value : one of
> - "ntc,ncp15wb473"
> - "ntc,ncp18wb473"
> - "ntc,ncp21wb473"
> - "ntc,ncp03wb473"
> - "ntc,ncp15wl333"
> + "murata,ncp15wb473"
> + "murata,ncp18wb473"
> + "murata,ncp21wb473"
> + "murata,ncp03wb473"
> + "murata,ncp15wl333"

So we're outright changing these rather than deprecating the existing
forms?

In general we've pushed back on changes like this, and requested that
the old strings are kept in both documentation and code as deprecated
forms.

Can you guarantee that changing this is not going to stop someone's
board worknig properly? I suspect not.

Mark.

>  - "pullup-uv"Pull up voltage in micro volts
>  - "pullup-ohm"   Pull up resistor value in ohms
>  - "pulldown-ohm" Pull down resistor value in ohms
> @@ -21,7 +21,7 @@ Read more about iio bindings at
>  
>  Example:
>   ncp15wb473@0 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";
>   pullup-uv = <180>;
>   pullup-ohm = <47000>;
>   pulldown-ohm = <0>;
> diff --git a/Documentation/hwmon/ntc_thermistor 
> b/Documentation/hwmon/ntc_thermistor
> index 3bfda94..057b770 100644
> --- a/Documentation/hwmon/ntc_thermistor
> +++ b/Documentation/hwmon/ntc_thermistor
> @@ -1,7 +1,7 @@
>  Kernel driver ntc_thermistor
>  =
>  
> -Supported thermistors:
> +Supported thermistors from Murata:
>  * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, 
> NCP15WL333
>Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 
> 'ncp15wl333'
>Datasheet: Publicly available at Murata
> @@ -15,9 +15,9 @@ Authors:
>  Description
>  ---
>  
> -The NTC thermistor is a simple thermistor that requires users to provide the
> -resistance and lookup the corresponding compensation table to get the
> -temperature input.
> +The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
> +that requires users to provide the resistance and lookup the corresponding
> +compensation table to get the temperature input.
>  
>  The NTC driver provides lookup tables with a linear approximation function
>  and four circuit models with an option not to use any of the four models.
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 08531a1..154851b 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1052,7 +1052,7 @@ config SENSORS_PC87427
> will be called pc87427.
>  
>  config SENSORS_NTC_THERMISTOR
> - tristate "NTC thermistor support"
> + tristate "NTC based thermistor support from Mu

Re: [PATCH 3/4] ARM: DTS: use new compatible string as per the documentation

[Mark Rutland]

On Tue, Jun 24, 2014 at 01:19:15PM +0100, Naveen Krishna Chatradhi wrote:
> As Murata is the Manufactures the NTC thermistors. The vendor
> name in the compatibility is preposed to change to "murata, ncpXXX"
> 
> This patch uses the new compatibility string in exynos4412 based
> Trats2 board.
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Chanwoo Choi 
> ---
> 1. Updates the thermistor node in Exynos4412 based Trats2 dts
>using the new DT bindings for NTC thermistors updated with vendor-prefix
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 11967f4..d35755a 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -771,7 +771,7 @@
>   };
>  
>   thermistor-ap@0 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";

So the previous patch woul have broken this board?

Mark.

>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>   pullup-ohm = <10>;   /* 100K */
>   pulldown-ohm = <10>; /* 100K */
> @@ -779,7 +779,7 @@
>   };
>  
>   thermistor-battery@1 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";
>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>   pullup-ohm = <10>;   /* 100K */
>   pulldown-ohm = <10>; /* 100K */
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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

Re: [PATCH 1/4] devicetree: bindings: Document murata vendor prefix

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:00, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:13PM +0100, Naveen Krishna Chatradhi wrote:
>> Add Murata Manufacturing Co., Ltd. to the list of device tree
>> vendor prefixes.
>>
>> Murata manufactures NTC (Negative Temperature Coefficient) based
>> Thermistors for small scale applications like Mobiles and PDAs.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Guenter Roeck 
>> ---
>> This changes is needed for the following reasons
>>
>> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>>Thus, giving an error when checked with scripts/checkpatch.pl
>> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>>NTC (Negative Temperature Coefficient) based thermistors.
>>Hence, "murata" is the right vendor-prefix, Not "ntc".
>> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>>and heavily used in the driver and the documentation.
>>
>>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 4d7f375..a39b7d7 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -84,6 +84,7 @@ moxaMoxa
>>  mpl  MPL AG
>>  mundoreader  Mundo Reader S.L.
>>  mxicyMacronix International Co., Ltd.
>> +murata   Murata Manufacturing Co., Ltd.
>
> Nit: please keep this list in alphabetical order.

Sure, Will rearrange and re-spin.
>
> Otherwise, this looks fine to me. With the order fixed:
>
> Acked-by: Mark Rutland 

Thanks
>
> Mark.
>
>>  national National Semiconductor
>>  neonode  Neonode Inc.
>>  netgear  NETGEAR
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>



-- 
Shine bright,
(: Nav :)
--
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 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:02, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:14PM +0100, Naveen Krishna Chatradhi wrote:
>> Murata Manufacturing Co., Ltd is the vendor for
>> NTC (Negative Temperature coefficient) based Thermistors.
>> But, the driver extensively uses "NTC" as the vendor name.
>>
>> This patch corrects the vendor name also updates the
>> compatibility strings according to the vendor-prefix.txt
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Guenter Roeck 
>> ---
>> This changes is needed for the following reasons
>>
>> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>>Thus, giving an error when checked with scripts/checkpatch.pl
>> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>>NTC (Negative Temperature Coefficient) based thermistors.
>>Hence, "murata" is the right vendor-prefix, Not "ntc".
>> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>>and heavily used in the driver and the documentation.
>>
>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
>>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   12 ++--
>>  Documentation/hwmon/ntc_thermistor |8 
>>  drivers/hwmon/Kconfig  |5 +++--
>>  drivers/hwmon/ntc_thermistor.c |   12 ++--
>>  5 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> index 5d49f2b..832fe8c 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> @@ -48,7 +48,7 @@ adc@12D1 {
>>
>>   /* NTC thermistor is a hwmon device */
>>   ncp15wb473@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;
>>   pullup-ohm = <47000>;
>>   pulldown-ohm = <0>;
>> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
>> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> index c6f6667..4e9f344 100644
>> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> @@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
>>
>>  Requires node properties:
>>  - "compatible" value : one of
>> - "ntc,ncp15wb473"
>> - "ntc,ncp18wb473"
>> - "ntc,ncp21wb473"
>> - "ntc,ncp03wb473"
>> - "ntc,ncp15wl333"
>> + "murata,ncp15wb473"
>> + "murata,ncp18wb473"
>> + "murata,ncp21wb473"
>> + "murata,ncp03wb473"
>> + "murata,ncp15wl333"
>
> So we're outright changing these rather than deprecating the existing
> forms?
>
> In general we've pushed back on changes like this, and requested that
> the old strings are kept in both documentation and code as deprecated
> forms.

Should have kept the old bindings as deprecated.

>
> Can you guarantee that changing this is not going to stop someone's
> board worknig properly? I suspect not.

As a result of this change, Exynos4412-Trats2 board is broken.
Will re-spin with the deprecated binding.

>
> Mark.
>
>>  - "pullup-uv"Pull up voltage in micro volts
>>  - "pullup-ohm"   Pull up resistor value in ohms
>>  - "pulldown-ohm" Pull down resistor value in ohms
>> @@ -21,7 +21,7 @@ Read more about iio bindings at
>>
>>  Example:
>>   ncp15wb473@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;
>>   pullup-ohm = <47000>;
>>   pulldown-ohm = <0>;
>> diff --git a/Documentation/hwmon/ntc_thermistor 
>> b/Documentation/hwmon/ntc_thermistor
>> index 3bfda94..057b770 100644
>> --- a/Documentation/hwmon/ntc_thermistor
>> +++ b/Documentation/hwmon/ntc_thermistor
>> @@ -1,7 +1,7 @@
>>  Kernel driver ntc_thermistor
>>  =
>>
>> -Supported thermistors:
>> +Supported thermistors from Murata:
>>  * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, 
>> NCP15WL333
>>Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 
>> 'ncp15wl333'
>>Datasheet: Publicly available at Murata
>> @@ -15,9 +15,9 @@ Authors:
>>  Description
>>  ---
>>
>> -The NTC thermistor is a simple thermistor that requires users to provide the
>> -resistance and lookup the corresponding compensation table to get the
>> -temperature input.
>> +The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
>> +that requires users to provide the resistance and lookup the corresponding
>> +compensation table to get the temperature input.
>>
>>  The NTC driver provides lookup tables with a linear approximation function
>>  and four circuit models with an option not to use any of the four models.
>> diff --git a/drivers/hwmon/Kconfig b/drive

Re: [PATCH 3/4] ARM: DTS: use new compatible string as per the documentation

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:03, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:15PM +0100, Naveen Krishna Chatradhi wrote:
>> As Murata is the Manufactures the NTC thermistors. The vendor
>> name in the compatibility is preposed to change to "murata, ncpXXX"
>>
>> This patch uses the new compatibility string in exynos4412 based
>> Trats2 board.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Chanwoo Choi 
>> ---
>> 1. Updates the thermistor node in Exynos4412 based Trats2 dts
>>using the new DT bindings for NTC thermistors updated with vendor-prefix
>>
>>  arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 11967f4..d35755a 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -771,7 +771,7 @@
>>   };
>>
>>   thermistor-ap@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>
> So the previous patch woul have broken this board?

Will keep the deprecated binding. But, still change here.
As, this is the only board currently using the NTC thermistors.

>
> Mark.
>
>>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>>   pullup-ohm = <10>;   /* 100K */
>>   pulldown-ohm = <10>; /* 100K */
>> @@ -779,7 +779,7 @@
>>   };
>>
>>   thermistor-battery@1 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>>   pullup-ohm = <10>;   /* 100K */
>>   pulldown-ohm = <10>; /* 100K */
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>



-- 
Shine bright,
(: Nav :)
--
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: MMC error on Exynos4210 board

[Tim Kryger]

Sure thing.  I'll try to get it sent out later today.

-Tim

On Tue, Jun 24, 2014 at 4:11 AM, Ulf Hansson  wrote:
>
>
> On 23 juni 2014 06:30:08 CEST, Sachin Kamat  wrote:
>>Hi Tim,
>>
>>On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger 
>>wrote:
>>> On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat 
>>wrote:
 On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung
>> wrote:
> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger 
>>wrote:
>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat
>> wrote:
 On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger
>> wrote:
> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat
>> wrote:
>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat
>> wrote:
>
 I see the below error on Exynos4210 based Origen board with
>>linux-next
 (20140618).
 Reverting the below commit works fine.

 Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator
>>infrastucture"
>

 -- [2.068992] sdhci: Secure Digital Host Controller
>>Interface driver
 [2.075059] sdhci: Copyright(c) Pierre Ossman
 [2.079762] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1251[0]'
 [2.088021] s3c-sdhci 1251.sdhci: clock source 2:
>>mmc_busclk.2
 (5000 Hz)
 [2.095322] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1251[0]'
 [2.103794] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1251[0]'
 [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator
>>found
 [2.118117] mmc0: Hardware doesn't report any support
>>voltages.
 [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host()
>>failed
 [2.130080] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1253[0]'
 [2.138352] s3c-sdhci 1253.sdhci: clock source 2:
>>mmc_busclk.2
 (1667 Hz)
 [2.145661] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1253[0]'
 [2.154139] of_get_named_gpiod_flags: can't parse gpios
>>property of
 node '/sdhci@1253[0]'
 [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator
>>found
 [2.168464] mmc0: Hardware doesn't report any support
>>voltages.
 [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host()
>>failed
>
 [2.336148] Waiting for root device /dev/mmcblk0p1...
>
>> FYI, the board has a 2.8V fixed regulator supply connected to
>>the MMC.
>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for
>>more details.
>
> A 2.8v regulator results in mmc->ocr_avail being set to
>>MMC_VDD_27_28
> | MMC_VDD_28_29.
>
> The SDHCI capabilities register only indicates support of three
>>voltage levels
>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>
> Right. sdhci capabilities only indicated them.
> But I think SoC can be support the specific VDD range.
>
>
> Even if all capability bits of the host controller were set,
>>there
> still wouldn't be any overlap.  Thus you see a "Hardware
>>doesn't
> report any support voltages" message.
>
> Previously, this issue was being swept under the rug by cec2e21
>>mmc:
> sdhci: Use regulator min/max voltage range according to spec.
>>That
> change hacked up the voltage range checks such that with your
>>2.8v
> fixed regulator, the driver would believe the host could
>>support
> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.
>>The
> driver would start down the path of commanding 3.3v-3.4v (the
>>highest
> voltage range believed to be supported).  At the last second,
>>the
> driver would see the regulator was fixed and blindly skip over
>>the set
> voltage operation, saving it from failure.
>
> Since my patch eliminates the bogus voltage range checks, your
>>board
> is now getting caught playing too loose with the SDHCI
>>regulator
> voltages.
>
> Furthermore, the fixed regulator special-case logic that helped
>>hide
> your issue should also be considered for removal given that
>>fixed
> regulators now behave properly thanks to c00dc35 regulator:
>>core:
> Allow regulator_set_voltage for fixed regulators.

 Thanks for the detailed explanation. What do you propose to get
>>this fixed
>>>
>>> It would be nice if the driver could

[PATCH 0/6] Various Samsung fixes for v3.16-rc3

[Tomasz Figa]

This series inteds to fix various issues spotted while testing v3.16-rc2.
The patches should be reasonably independent from each other and so could be
picked to respective trees. See descriptions of individual patches for more
information.

Tested on Exynos4412-based Trats2 and Exynos4210-based Trats boards.

AFAIK there is no need to backport those fixes to stable.

Tomasz Figa (6):
  mmc: sdhci-s3c: Fix local I/O clock gating
  ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
  clk: samsung: exynos4: Remove SRC_MASK_ISP gates
  ARM: SAMSUNG: Restore Samsung PM Debug functionality
  ARM: EXYNOS: Fix suspend/resume sequencies
  ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250

 arch/arm/mach-exynos/exynos.c |  6 ++
 arch/arm/mach-exynos/hotplug.c| 10 ++
 arch/arm/mach-exynos/platsmp.c| 34 +++---
 arch/arm/mach-exynos/pm.c | 20 
 arch/arm/plat-samsung/Kconfig |  8 +++-
 arch/arm/plat-samsung/pm-debug.c  |  1 +
 drivers/clk/samsung/clk-exynos4.c | 16 
 drivers/mmc/host/sdhci-s3c.c  | 17 ++---
 8 files changed, 53 insertions(+), 59 deletions(-)

-- 
1.9.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 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality

[Tomasz Figa]

Due to recently merged patches and previous merge conflicts, the Samsung
PM Debug functionality no longer can be enabled. This patch fixes
incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds
missing header inclusion.

Signed-off-by: Tomasz Figa 
---
 arch/arm/plat-samsung/Kconfig| 8 +++-
 arch/arm/plat-samsung/pm-debug.c | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 301b892..483c959 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -412,9 +412,14 @@ config S5P_DEV_MFC
 
 comment "Power management"
 
+config HAVE_SAMSUNG_PM_DEBUG
+   bool
+   help
+ Allow compilation of Samsung PM debugging code.
+
 config SAMSUNG_PM_DEBUG
bool "S3C2410 PM Suspend debug"
-   depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART
+   depends on PM && DEBUG_KERNEL && HAVE_SAMSUNG_PM_DEBUG
help
  Say Y here if you want verbose debugging from the PM Suspend and
  Resume code. See 
@@ -484,6 +489,7 @@ config S5P_SLEEP
 
 config DEBUG_S3C_UART
depends on PLAT_SAMSUNG
+   select HAVE_SAMSUNG_PM_DEBUG
int
default "0" if DEBUG_S3C_UART0
default "1" if DEBUG_S3C_UART1
diff --git a/arch/arm/plat-samsung/pm-debug.c b/arch/arm/plat-samsung/pm-debug.c
index 8f19f66..3960960 100644
--- a/arch/arm/plat-samsung/pm-debug.c
+++ b/arch/arm/plat-samsung/pm-debug.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include 
-- 
1.9.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 1/6] mmc: sdhci-s3c: Fix local I/O clock gating

[Tomasz Figa]

For internal card detection mechanism it is required that the local I/O
clock is always running. However while current implementation accounts
for this, it does so incorrectly leading to race conditions and warnings
about unbalanced clock disables.

This patch fixes it by inverting the logic, which now increases local
I/O clock enable count when internal card detect is used, instead of
decreasing it otherwise.

Signed-off-by: Tomasz Figa 
Cc: Ben Dooks 
Cc: Chris Ball 
Cc: Ulf Hansson 
Cc: linux-...@vger.kernel.org
---
 drivers/mmc/host/sdhci-s3c.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index fa5954a..1795e1f 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -487,8 +487,13 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
goto err_pdata_io_clk;
}
 
-   /* enable the local io clock and keep it running for the moment. */
-   clk_prepare_enable(sc->clk_io);
+   /*
+* Keep local I/O clock enabled for internal card detect pin
+* or runtime PM is disabled.
+*/
+   if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL
+   || !IS_ENABLED(CONFIG_PM_RUNTIME))
+   clk_prepare_enable(sc->clk_io);
 
for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
char name[14];
@@ -611,15 +616,13 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
goto err_req_regs;
}
 
-#ifdef CONFIG_PM_RUNTIME
-   if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL)
-   clk_disable_unprepare(sc->clk_io);
-#endif
return 0;
 
  err_req_regs:
  err_no_busclks:
-   clk_disable_unprepare(sc->clk_io);
+   if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL
+   || !IS_ENABLED(CONFIG_PM_RUNTIME))
+   clk_disable_unprepare(sc->clk_io);
 
  err_pdata_io_clk:
sdhci_free_host(host);
-- 
1.9.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 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250

[Tomasz Figa]

Currently, the Exynos cpuidle driver works correctly only on Exynos4210
and 5250. Trying to use it with just one CPU online on any other Exynos
SoC will lead to system failure, due to unsupported AFTR mode on other
SoCs. This patch fixes the problem by registering the driver only on
supported SoCs and letting others simply use default WFI mode until
support for them is added.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-exynos/exynos.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index f38cf7c..176bbf5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -173,10 +173,8 @@ static struct platform_device exynos_cpuidle = {
 
 void __init exynos_cpuidle_init(void)
 {
-   if (soc_is_exynos5440())
-   return;
-
-   platform_device_register(&exynos_cpuidle);
+   if (soc_is_exynos4210() || soc_is_exynos5250())
+   platform_device_register(&exynos_cpuidle);
 }
 
 void __init exynos_cpufreq_init(void)
-- 
1.9.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 5/6] ARM: EXYNOS: Fix suspend/resume sequencies

[Tomasz Figa]

Due to recent consolidation of Exynos suspend and cpuidle code, some
parts of suspend and resume sequences are executed two times, once from
exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
breaks suspend, at least on Exynos4-based boards.

This patch fixes the issue by removing exynos_pm_syscore_ops completely
and making the code rely only on CPU PM notifier.

Tested on Exynos4210-based Trats board.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-exynos/pm.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 87c0d34..98d4926 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -364,11 +364,6 @@ early_wakeup:
return;
 }
 
-static struct syscore_ops exynos_pm_syscore_ops = {
-   .suspend= exynos_pm_suspend,
-   .resume = exynos_pm_resume,
-};
-
 /*
  * Suspend Ops
  */
@@ -438,19 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block 
*self,
 
switch (cmd) {
case CPU_PM_ENTER:
-   if (cpu == 0) {
-   exynos_pm_central_suspend();
-   exynos_cpu_save_register();
-   }
+   if (cpu == 0)
+   exynos_pm_suspend();
break;
 
case CPU_PM_EXIT:
-   if (cpu == 0) {
-   if (!soc_is_exynos5250())
-   scu_enable(S5P_VA_SCU);
-   exynos_cpu_restore_register();
-   exynos_pm_central_resume();
-   }
+   if (cpu == 0)
+   exynos_pm_resume();
break;
}
 
@@ -475,6 +464,5 @@ void __init exynos_pm_init(void)
tmp |= ((0xFF << 8) | (0x1F << 1));
__raw_writel(tmp, S5P_WAKEUP_MASK);
 
-   register_syscore_ops(&exynos_pm_syscore_ops);
suspend_set_ops(&exynos_suspend_ops);
 }
-- 
1.9.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 3/6] clk: samsung: exynos4: Remove SRC_MASK_ISP gates

[Tomasz Figa]

ISP special clocks have dedicated gating registers and so MUX SRC_MASK
register should not be used. This patch fixes the problem of
Exynos4x12-based boards freezing on system suspend, because those
mux outputs need not to be masked while suspending.

Signed-off-by: Tomasz Figa 
Cc: Mike Turquette 
---
 drivers/clk/samsung/clk-exynos4.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9..7f4a473 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -925,21 +925,13 @@ static struct samsung_gate_clock exynos4x12_gate_clks[] 
__initdata = {
GATE(CLK_RTC, "rtc", "aclk100", E4X12_GATE_IP_PERIR, 15,
0, 0),
GATE(CLK_KEYIF, "keyif", "aclk100", E4X12_GATE_IP_PERIR, 16, 0, 0),
-   GATE(CLK_SCLK_PWM_ISP, "sclk_pwm_isp", "div_pwm_isp",
-   E4X12_SRC_MASK_ISP, 0, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_SCLK_SPI0_ISP, "sclk_spi0_isp", "div_spi0_isp_pre",
-   E4X12_SRC_MASK_ISP, 4, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_SCLK_SPI1_ISP, "sclk_spi1_isp", "div_spi1_isp_pre",
-   E4X12_SRC_MASK_ISP, 8, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_SCLK_UART_ISP, "sclk_uart_isp", "div_uart_isp",
-   E4X12_SRC_MASK_ISP, 12, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_PWM_ISP_SCLK, "pwm_isp_sclk", "sclk_pwm_isp",
+   GATE(CLK_PWM_ISP_SCLK, "pwm_isp_sclk", "div_pwm_isp",
E4X12_GATE_IP_ISP, 0, 0, 0),
-   GATE(CLK_SPI0_ISP_SCLK, "spi0_isp_sclk", "sclk_spi0_isp",
+   GATE(CLK_SPI0_ISP_SCLK, "spi0_isp_sclk", "div_spi0_isp_pre",
E4X12_GATE_IP_ISP, 1, 0, 0),
-   GATE(CLK_SPI1_ISP_SCLK, "spi1_isp_sclk", "sclk_spi1_isp",
+   GATE(CLK_SPI1_ISP_SCLK, "spi1_isp_sclk", "div_spi1_isp_pre",
E4X12_GATE_IP_ISP, 2, 0, 0),
-   GATE(CLK_UART_ISP_SCLK, "uart_isp_sclk", "sclk_uart_isp",
+   GATE(CLK_UART_ISP_SCLK, "uart_isp_sclk", "div_uart_isp",
E4X12_GATE_IP_ISP, 3, 0, 0),
GATE(CLK_WDT, "watchdog", "aclk100", E4X12_GATE_IP_PERIR, 14, 0, 0),
GATE(CLK_PCM0, "pcm0", "aclk100", E4X12_GATE_IP_MAUDIO, 2,
-- 
1.9.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 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code

[Tomasz Figa]

When CPU topology is specified in device tree, cpu_logical_map() does
not return core ID anymore, but rather full MPIDR value. This breaks
existing calculation of PMU register offsets on Exynos SoCs.

This patch fixes the problem by adjusting the code to use only core ID
bits of the value returned by cpu_logical_map() to allow CPU topology to
be specified in device tree on Exynos SoCs.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-exynos/hotplug.c | 10 ++
 arch/arm/mach-exynos/platsmp.c | 34 +++---
 2 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 69fa483..5644dac 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -40,11 +40,13 @@ static inline void cpu_leave_lowpower(void)
 
 static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
 {
+   u32 mpidr = cpu_logical_map(cpu);
+   u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
for (;;) {
 
-   /* make cpu1 to be turned off at next WFI command */
-   if (cpu == 1)
-   exynos_cpu_power_down(cpu);
+   /* Turn the CPU off on next WFI instruction. */
+   exynos_cpu_power_down(core_id);
 
/*
 * here's the WFI
@@ -54,7 +56,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int 
*spurious)
:
: "memory", "cc");
 
-   if (pen_release == cpu_logical_map(cpu)) {
+   if (pen_release == core_id) {
/*
 * OK, proper wakeup, we're done
 */
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 1c8d31e..50b9aad 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -90,7 +90,8 @@ static void exynos_secondary_init(unsigned int cpu)
 static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
unsigned long timeout;
-   unsigned long phys_cpu = cpu_logical_map(cpu);
+   u32 mpidr = cpu_logical_map(cpu);
+   u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
int ret = -ENOSYS;
 
/*
@@ -104,17 +105,18 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 * the holding pen - release it, then wait for it to flag
 * that it has been released by resetting pen_release.
 *
-* Note that "pen_release" is the hardware CPU ID, whereas
+* Note that "pen_release" is the hardware CPU core ID, whereas
 * "cpu" is Linux's internal ID.
 */
-   write_pen_release(phys_cpu);
+   write_pen_release(core_id);
 
-   if (!exynos_cpu_power_state(cpu)) {
-   exynos_cpu_power_up(cpu);
+   if (!exynos_cpu_power_state(core_id)) {
+   exynos_cpu_power_up(core_id);
timeout = 10;
 
/* wait max 10 ms until cpu1 is on */
-   while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
+   while (exynos_cpu_power_state(core_id)
+  != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
 
@@ -145,20 +147,20 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 * Try to set boot address using firmware first
 * and fall back to boot register if it fails.
 */
-   ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
+   ret = call_firmware_op(set_cpu_boot_addr, core_id, boot_addr);
if (ret && ret != -ENOSYS)
goto fail;
if (ret == -ENOSYS) {
-   void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
+   void __iomem *boot_reg = cpu_boot_reg(core_id);
 
if (IS_ERR(boot_reg)) {
ret = PTR_ERR(boot_reg);
goto fail;
}
-   __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
+   __raw_writel(boot_addr, cpu_boot_reg(core_id));
}
 
-   call_firmware_op(cpu_boot, phys_cpu);
+   call_firmware_op(cpu_boot, core_id);
 
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 
@@ -227,22 +229,24 @@ static void __init exynos_smp_prepare_cpus(unsigned int 
max_cpus)
 * boot register if it fails.
 */
for (i = 1; i < max_cpus; ++i) {
-   unsigned long phys_cpu;
unsigned long boot_addr;
+   u32 mpidr;
+   u32 core_id;
int ret;
 
-   phys_cpu = cpu_logical_map(i);
+   mpidr = cpu_logical_map(i);
+   core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
  

Re: [PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

On 06/24/2014 03:14 PM, Ajay kumar wrote:
> On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  wrote:
>> Hi Ajay,
>>
>> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be used if we are using DP.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
>>>  include/video/samsung_fimd.h |4 
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 33161ad..5d3045d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>>   unsigned int has_shadowcon:1;
>>>   unsigned int has_clksel:1;
>>>   unsigned int has_limited_fmt:1;
>>> + unsigned int has_dp_clkcon:1;
>>>  };
>>>
>>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = 
>>> {
>>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>>   .timing_base = 0x2,
>>>   .has_shadowcon = 1,
>>> + .has_dp_clkcon = 1,
>>>  };
>>>
>>>  struct fimd_win_data {
>>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>>   if (clkdiv > 1)
>>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>>
>>> + if (ctx->driver_data->has_dp_clkcon)
>>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>>> +
>> This code always enables the clock on exynos5. As I understand it should
>> be enabled only if DP is used.
> Right!
> But, when I searched for the display interface,
> only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
> So, I thought adding this in driver_data for exynos5 should be fine.

Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.

>
> Inki/Andrej - Shall I add it as an optional DT property?

No, property is redundant. The simplest solution could be to use
CONFIG_DRM_EXYNOS_DP
macro but it is quite ugly.
I guess extending little bit exynos_drm framework to allow detection of
DP in fimd would be better.

Regards
Andrzej

>
> Ajay
>>
>>>   writel(val, ctx->regs + VIDCON0);
>>>  }
>>>
>>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>>> index b039320..d8f4b0b 100644
>>> --- a/include/video/samsung_fimd.h
>>> +++ b/include/video/samsung_fimd.h
>>> @@ -435,6 +435,10 @@
>>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>>
>>> +/* Video clock enable for DP */
>>> +#define DP_CLKCON0x27C
>>> +#define DP_CLK_ENABLE0x2
>>> +
>>>  /* Notes on per-window bpp settings
>>>   *
>>>   * Value Win0 Win1 Win2 Win3 Win 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 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Inki Dae]

2014-06-24 20:38 GMT+09:00 Andreas Färber :
> Am 24.06.2014 07:21, schrieb Inki Dae:
>> On 2014년 06월 23일 14:32, Rahul Sharma wrote:
>>> Allowing only one layer update per vsync can cause issues
>>> while there are update available for both layers. There is
>>> a good amount of possibility to loose updates if we allow
>>> single update per vsync.
>>>
>>> Signed-off-by: Rahul Sharma 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index d359501..6773b03 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
>>> int win)
>>>  static void mixer_layer_update(struct mixer_context *ctx)
>>>  {
>>>  struct mixer_resources *res = &ctx->mixer_res;
>>> -u32 val;
>>> -
>>> -val = mixer_reg_read(res, MXR_CFG);
>>>
>>> -/* allow one update per vsync only */
>>> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
>>> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>>> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>>
>> Rahul, it looks good to me and ok as is. But above codes don't consider
>> Exynos4 series. In case of Exynos4xxx SoC,
>> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
>> register are reserved fields. So can you work that patch to be
>> considered for Exynos4xxx SoC? That patch would be additional one.
>>
>> Anyway, will apply it as is, and I will wait for the additional patch.
>
> If it's not too late, could you fix up "multiple" in the subject? :)

Corrected. :)

Thanks,
Inki Dae

>
> Cheers,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> --
> 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

Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree

[Vincent Palatin]

Re-sending ... the text-only encoding was not properly turned on on
the previous one and irritated the mailing lists.


On Mon, Jun 23, 2014 at 9:05 PM, Doug Anderson  wrote:
>
> Andreas,
>
> On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber  wrote:
> > Hi Doug,
> >
> > Am 23.06.2014 21:47, schrieb Doug Anderson:
> >> Thanks for posting!  A first pass on this is below...
> >
> > Thanks a lot for your quick review! My first big .dts patch, and no
> > datasheets for the hardware at hand as a user.
> >
> > A first pass of replies to my defense. ;)
> >
> >> On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber  wrote:
> > [...]
> >>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
> >>> b/arch/arm/boot/dts/exynos5250-spring.dts
> >>> new file mode 100644
> >>> index 000..e857d44
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >>> @@ -0,0 +1,556 @@
> >>> +/*
> >>> + * Google Spring board device tree source
> >>> + *
> >>> + * Copyright (c) 2013 Google, Inc
> >>> + * Copyright (c) 2014 SUSE LINUX Products GmbH
> >>> + *
> >>> + * 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.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "exynos5250.dtsi"
> >>> +#include "exynos5250-cros-common.dtsi"
> >>
> >> It is possible we may want to backpedal on the use of
> >> "exynos5250-cros-common.dtsi".  I know that Olof (now CCed) said he
> >> wasn't a fan of how it turned out.
> >>
> >> The original idea was that it should include the arbitrary set of
> >> things that are common between a chunk of Chrome OS boards.  As more
> >> boards were introduced things would need to migrate from the "common"
> >> file to the board files.
> >>
> >> At the moment the current conventional wisdom is that some duplication
> >> is better than the confusing movement of everything back and forth.
> >> See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
> >>
> >>
> >>> +/ {
> >>> +   model = "Google Spring";
> >>> +   compatible = "google,spring", "samsung,exynos5250", 
> >>> "samsung,exynos5";
> >>> +
> >>> +   pinctrl@1140 {
> >>
> >> The new best way to do things is to put this down at the bottom.  See
> >> exynos5420-peach-pit as an example:
> >>
> >> &pinctrl_0 {
> >>   ...
> >> }
> >>
> >> Note that I believe it was decided that top-level references like that
> >> should be sorted alphabetically.
> >
> > Thanks for the hint. (My chosen sort order here was by address.)
> >
> >> If you wanted to apply that run to exynos5250-snow I don't think it
> >> would be a terrible idea.
> >
> > I can of course apply changes to Snow, but I cannot test them myself.
>
> If you want to send up a patch like that I'm happy to give it a once
> over and also to test it.  ...but don't feel obligated
>
>
> >>> +   s5m8767_dvs: s5m8767-dvs {
> >>> +   samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   s5m8767_ds: s5m8767-ds {
> >>> +   samsung,pins = "gpx2-3", "gpx2-4", "gpx2-5";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   tps65090_irq: tps65090-irq {
> >>> +   samsung,pins = "gpx2-6";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   s5m8767_irq: s5m8767-irq {
> >>> +   samsung,pins = "gpx3-2";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   hdmi_hpd_irq: hdmi-hpd-irq {
> >>> +   samsung,pins = "gpx3-7";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +   };
> >>> +
> >>> +   pinctrl@1340 {
> >>> +   hsic_reset: hsic-reset {
> >>> +   samsung,pins = "gpe1-0";
> >>> +   samsung,pin-function = <1>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>
> >> I'm pretty sure that the HSIC reset needed some funky code to make it
> >> work and I'm not sure what the status of that is upstream
> >
> > Yeah, you mentioned something along those lines. How

Re: [PATCH] phy: phy-samsung-usb2: Change phy power on/power off sequence

[Daniel Drake]

On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski  wrote:
> The Exynos4412 USB 2.0 PHY hardware differs from the description provided
> in the documentation. Some register bits have different function. This
> patch fixes the defines of register bits and changes the way how phys are
> powered on and off.

I guess this replaces the patch titled "drivers: phy: exynos4x12-phy:
fix HSIC1 power on/off sequence"

Tested on ODROID-U2. Seems to be working as well as the previous patch:
- Internal SMSC hub works on boot and after reboot, tested with USB mouse
- Internal SMSC ethernet device works on boot, but disappears upon
reboot. (same as previous patch, also reproduced by Marek)

Thanks,
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: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree

[Doug Anderson]

Javier,

On Tue, Jun 24, 2014 at 3:06 AM, Javier Martinez Canillas
 wrote:
> Hello Doug,
>
> On 06/24/2014 06:05 AM, Doug Anderson wrote:
> Another option is to identify DTS fragments that are common across boards and
> create .dtsi files for these specific chunks instead of trying to group all 
> set
> of common things on a single .dtsi file.
>
> For example, a quite common design for OMAP2+ based boards is to use a SMSC 
> LAN
> chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the
> following files were created to reduce DTS duplication:
>
> arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
> arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
>
> Now that I think about it, is the same that what you did for
> arm/boot/dts/cros-ec-keyboard.dtsi.
>
> Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make 
> it
> more flexible/reusable?

Yes, I think the config fragments can be cleaner but I think we have
to be judicious about using them.  There are definitely tradeoffs
involved.  The keyboard was such an excessively large thing and
totally duplicated, so moving it out made sense.  Other bits are less
obvious (to me) because there are so many interactions / combinations
and you end up with a bit of spaghetti in terms of which labels are
used by and provided by each fragment.  I guess possibly you could
codify that better...

A few thoughts looking at exynos5420-peach-pit:

* backlight: seems (?) too board specific
* samsung,exynos5420-oscclk: could totally be a fragment, but very small.
* power key: could be a fragment for all boards that happen to use
gpx1-2 for this
* sound: could be a fragment for all devices using
"google,snow-audio-max98090", possibly.


> Personally I think that "status = [enabled | disabled]" only makes sense for 
> IP
> blocks that are part of the SoC but may or may not be used by a board (e.g: 
> i2c
> and spi buses, sdhci and usb host controllers, etc).
>
> DTS should be a description of the hardware so I agree that having a disabled
> node for a device that is not present in the board is not right.

Right.  We'll take a look again in v2 when cros-common isn't used.  I
think this could go in steps:
1. Don't use cros-common for spring
2. Don't use cros-common for snow (fold stuff in)
3. Introduce some fragments.
--
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 5/6] ARM: EXYNOS: Fix suspend/resume sequencies

[Abhilash Kesavan]

Hi Tomasz,

On Tue, Jun 24, 2014 at 7:27 PM, Tomasz Figa  wrote:
> Due to recent consolidation of Exynos suspend and cpuidle code, some
> parts of suspend and resume sequences are executed two times, once from
> exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
> breaks suspend, at least on Exynos4-based boards.
>
> This patch fixes the issue by removing exynos_pm_syscore_ops completely
> and making the code rely only on CPU PM notifier.
>
> Tested on Exynos4210-based Trats board.
>
> Signed-off-by: Tomasz Figa 
> ---
>  arch/arm/mach-exynos/pm.c | 20 
>  1 file changed, 4 insertions(+), 16 deletions(-)
>
A patch from me has recently gone in which converts the soc_is checks
for A9 specific registers to  the A9 part number. This patch will
probably have to be rebased atop it.

Regards,
Abhilash
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index 87c0d34..98d4926 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -364,11 +364,6 @@ early_wakeup:
> return;
>  }
>
> -static struct syscore_ops exynos_pm_syscore_ops = {
> -   .suspend= exynos_pm_suspend,
> -   .resume = exynos_pm_resume,
> -};
> -
>  /*
>   * Suspend Ops
>   */
> @@ -438,19 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block 
> *self,
>
> switch (cmd) {
> case CPU_PM_ENTER:
> -   if (cpu == 0) {
> -   exynos_pm_central_suspend();
> -   exynos_cpu_save_register();
> -   }
> +   if (cpu == 0)
> +   exynos_pm_suspend();
> break;
>
> case CPU_PM_EXIT:
> -   if (cpu == 0) {
> -   if (!soc_is_exynos5250())
> -   scu_enable(S5P_VA_SCU);
> -   exynos_cpu_restore_register();
> -   exynos_pm_central_resume();
> -   }
> +   if (cpu == 0)
> +   exynos_pm_resume();
> break;
> }
>
> @@ -475,6 +464,5 @@ void __init exynos_pm_init(void)
> tmp |= ((0xFF << 8) | (0x1F << 1));
> __raw_writel(tmp, S5P_WAKEUP_MASK);
>
> -   register_syscore_ops(&exynos_pm_syscore_ops);
> suspend_set_ops(&exynos_suspend_ops);
>  }
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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] phy: phy-samsung-usb2: Change phy power on/power off sequence

[Kamil Debski]

Hi Daniel,

> From: Daniel Drake [mailto:dr...@endlessm.com]
> Sent: Tuesday, June 24, 2014 5:09 PM
> 
> On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski 
> wrote:
> > The Exynos4412 USB 2.0 PHY hardware differs from the description
> > provided in the documentation. Some register bits have different
> > function. This patch fixes the defines of register bits and changes
> > the way how phys are powered on and off.
> 
> I guess this replaces the patch titled "drivers: phy: exynos4x12-phy:
> fix HSIC1 power on/off sequence"

Yes, indeed it replaces this patch. I did some more research on how the
hardware actually behaves.

> 
> Tested on ODROID-U2. Seems to be working as well as the previous patch:

Thank you very much for testing.

> - Internal SMSC hub works on boot and after reboot, tested with USB
> mouse
> - Internal SMSC ethernet device works on boot, but disappears upon
> reboot. (same as previous patch, also reproduced by Marek)

By reboot I guess that you mean typing "reboot" or by using SysRq magic
and not power cycling?

If so, I had experienced the same symptoms. I guess that the Ethernet
chip is not reset properly and fails to enumerate without power cycling
(it's nRESET pin is connected to P3V3).

I found that removing regulator-always-on from buck8_reg: BUCK8 in the
dts file fixes this problem.

Best wishes,
-- 
Kamil Debski
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: [PATCH 0/3] MCPM: clarify boot CPU situation wrt CCI

[Kevin Hilman]

Nicolas Pitre  writes:

> For the background story, please see:
>
> http://news.gmane.org/group/gmane.linux.kernel.samsung-soc/thread=32807
>
> I sat on those patches for a while but they are the best I could think of
> in terms of implementation.  To ease merging I suggest I collect all the
> ACK's and Tested-by's and submit them all at once to RMK's patch system.

Reviewed-by: Kevin Hilman 
Tested-by: Kevin Hilman 

I tested this series on Exynos5 Peach Pi (a.k.a. 13" ARM Chromebook 2)
and verified all 8 cores are booting up.

Kevin

P.S. FYI for anyone else wanting to try this on peach-pi, I still need a
couple other out of tree clock related patches in order to boot fully.
Until the final versions are merged, I'm using these:

- Doug's aclk66 clock removal for earlyprintk support
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262225.html
- Leave mau_epll enabled
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.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 v2 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs

[Tomasz Figa]

This patch introduces a driver that handles configuration of CLKOUT pin
of Exynos SoCs that can be used to output certain clocks from inside of
the SoC to a dedicated output pin.

Signed-off-by: Tomasz Figa 
---
 .../devicetree/bindings/arm/samsung/pmu.txt|  30 
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos-clkout.c| 153 +
 3 files changed, 184 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 2a4ab04..f9865e7 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -12,8 +12,38 @@ Properties:
 
  - reg : offset and length of the register set.
 
+ - #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
+   The single specifier cell is used as index to list of clocks
+   provided by PMU, which is currently:
+   0 : SoC clock output (CLKOUT pin)
+
+ - clock-names : list of clock names for particular CLKOUT mux inputs in
+   following format:
+   "clkoutN", where N is a decimal number corresponding to
+   CLKOUT mux control bits value for given input, e.g.
+   "clkout0", "clkout7", "clkout15".
+
+ - clocks : list of phandles and specifiers to all input clocks listed in
+   clock-names property.
+
 Example :
 pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x1004 0x5000>;
+   #clock-cells = <1>;
+   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
+   "clkout4", "clkout8", "clkout9";
+   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
+   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
+   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
+   <&clock CLK_XUSBXTI>;
+};
+
+Example of clock consumer :
+
+usb3503: usb3503@08 {
+   /* ... */
+   clock-names = "refclk";
+   clocks = <&pmu_system_controller 0>;
+   /* ... */
 };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 69e8177..2949a55 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOC_EXYNOS5410)  += clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
+obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-clkout.o
 obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
 obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
 obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
b/drivers/clk/samsung/clk-exynos-clkout.c
new file mode 100644
index 000..3a7cb25
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-clkout.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Tomasz Figa 
+ *
+ * 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.
+ *
+ * Clock driver for Exynos clock output
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EXYNOS_CLKOUT_NR_CLKS  1
+#define EXYNOS_CLKOUT_PARENTS  32
+
+#define EXYNOS_PMU_DEBUG_REG   0xa00
+#define EXYNOS_CLKOUT_DISABLE_SHIFT0
+#define EXYNOS_CLKOUT_MUX_SHIFT8
+#define EXYNOS4_CLKOUT_MUX_MASK0xf
+#define EXYNOS5_CLKOUT_MUX_MASK0x1f
+
+struct exynos_clkout {
+   struct clk_gate gate;
+   struct clk_mux mux;
+   spinlock_t slock;
+   struct clk_onecell_data data;
+   struct clk *clk_table[EXYNOS_CLKOUT_NR_CLKS];
+   void __iomem *reg;
+   u32 pmu_debug_save;
+};
+
+static struct exynos_clkout *clkout;
+
+static int exynos_clkout_suspend(void)
+{
+   clkout->pmu_debug_save = readl(clkout->reg + EXYNOS_PMU_DEBUG_REG);
+
+   return 0;
+}
+
+static void exynos_clkout_resume(void)
+{
+   writel(clkout->pmu_debug_save, clkout->reg + EXYNOS_PMU_DEBUG_REG);
+}
+
+static struct syscore_ops exynos_clkout_syscore_ops = {
+   .suspend = exynos_clkout_suspend,
+   .resume = exynos_clkout_resume,
+};
+
+static void __init exynos_clkout_init(struct device_node *node, u32 mux_mask)
+{
+   const char *parent_names[EXYNOS_CLKOUT_PARENTS];
+   struct clk *parents[EXYNOS_CLKOUT_PARENTS];
+   int parent_count;
+   int ret;
+   int i;
+
+   clkout = kzalloc(sizeof(*clkout), GFP_KERNEL);
+   if (!clkout)
+   return;
+
+   spin_lock_init(&clkout->slock);
+
+   parent_count = 0;
+   for

[PATCH v2 4/4] ARM: dts: exynos: Update PMU node with CLKOUT related data

[Tomasz Figa]

This patch extends nodes of PMU system controller on Exynos4210, 4x12,
5250 and 5420 SoCs with newly defined properties used by Exynos CLKOUT
driver.

Signed-off-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos4210.dtsi | 10 ++
 arch/arm/boot/dts/exynos4x12.dtsi |  7 +++
 arch/arm/boot/dts/exynos5250.dtsi |  3 +++
 arch/arm/boot/dts/exynos5420.dtsi |  3 +++
 4 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..97ea7a9 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = &pinctrl_2;
};
 
+   pmu_system_controller: system-controller@1002 {
+   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
+   "clkout4", "clkout8", "clkout9";
+   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
+   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
+   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
+   <&clock CLK_XUSBXTI>;
+   #clock-cells = <1>;
+   };
+
sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943d..de1f9c7 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -139,6 +139,13 @@
 
pmu_system_controller: system-controller@1002 {
compatible = "samsung,exynos4212-pmu", "syscon";
+   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
+   "clkout4", "clkout8", "clkout9";
+   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
+   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
+   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
+   <&clock CLK_XUSBXTI>;
+   #clock-cells = <1>;
};
 
g2d@1080 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a..492e1ef 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -191,6 +191,9 @@
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x1004 0x5000>;
+   clock-names = "clkout16";
+   clocks = <&clock CLK_FIN_PLL>;
+   #clock-cells = <1>;
};
 
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..481beec 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -724,6 +724,9 @@
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5420-pmu", "syscon";
reg = <0x1004 0x5000>;
+   clock-names = "clkout16";
+   clocks = <&clock CLK_FIN_PLL>;
+   #clock-cells = <1>;
};
 
sysreg_system_controller: syscon@1005 {
-- 
1.9.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 v2 2/4] clk: samsung: exynos4: Add CLKOUT clock hierarchy

[Tomasz Figa]

This patch adds definitions of clocks that are used to drive clock
output signals of particular CMU sub-blocks that are then fed to PMU and
handled by Exynos CLKOUT driver added in further patch.

Signed-off-by: Tomasz Figa 
---
 drivers/clk/samsung/clk-exynos4.c   | 116 ++--
 include/dt-bindings/clock/exynos4.h |   5 ++
 2 files changed, 117 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index f95ae6c..7d1fb99 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -25,10 +25,12 @@
 #define DIV_LEFTBUS0x4500
 #define GATE_IP_LEFTBUS0x4800
 #define E4X12_GATE_IP_IMAGE0x4930
+#define CLKOUT_CMU_LEFTBUS 0x4a00
 #define SRC_RIGHTBUS   0x8200
 #define DIV_RIGHTBUS   0x8500
 #define GATE_IP_RIGHTBUS   0x8800
 #define E4X12_GATE_IP_PERIR0x8960
+#define CLKOUT_CMU_RIGHTBUS0x8a00
 #define EPLL_LOCK  0xc010
 #define VPLL_LOCK  0xc020
 #define EPLL_CON0  0xc110
@@ -98,6 +100,7 @@
 #define GATE_IP_PERIL  0xc950
 #define E4210_GATE_IP_PERIR0xc960
 #define GATE_BLOCK 0xc970
+#define CLKOUT_CMU_TOP 0xca00
 #define E4X12_MPLL_LOCK0x10008
 #define E4X12_MPLL_CON00x10108
 #define SRC_DMC0x10200
@@ -105,6 +108,7 @@
 #define DIV_DMC0   0x10500
 #define DIV_DMC1   0x10504
 #define GATE_IP_DMC0x10900
+#define CLKOUT_CMU_DMC 0x10a00
 #define APLL_LOCK  0x14000
 #define E4210_MPLL_LOCK0x14008
 #define APLL_CON0  0x14100
@@ -114,6 +118,7 @@
 #define DIV_CPU1   0x14504
 #define GATE_SCLK_CPU  0x14800
 #define GATE_IP_CPU0x14900
+#define CLKOUT_CMU_CPU 0x14a00
 #define E4X12_DIV_ISP0 0x18300
 #define E4X12_DIV_ISP1 0x18304
 #define E4X12_GATE_ISP00x18800
@@ -242,6 +247,11 @@ static unsigned long exynos4_clk_regs[] __initdata = {
DIV_CPU1,
GATE_SCLK_CPU,
GATE_IP_CPU,
+   CLKOUT_CMU_LEFTBUS,
+   CLKOUT_CMU_RIGHTBUS,
+   CLKOUT_CMU_TOP,
+   CLKOUT_CMU_DMC,
+   CLKOUT_CMU_CPU,
 };
 
 static const struct samsung_clk_reg_dump src_mask_suspend[] = {
@@ -400,6 +410,23 @@ PNAME(mout_dac_p4210)  = { "sclk_vpll", 
"sclk_hdmiphy", };
 PNAME(mout_pwi_p4210) = { "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
"sclk_usbphy1", "sclk_hdmiphy", "none",
"sclk_epll", "sclk_vpll" };
+PNAME(clkout_left_p4210) = { "sclk_mpll_div_2", "sclk_apll_div_2",
+   "div_gdl", "div_gpl" };
+PNAME(clkout_right_p4210) = { "sclk_mpll_div_2", "sclk_apll_div_2",
+   "div_gdr", "div_gpr" };
+PNAME(clkout_top_p4210) = { "fout_epll", "fout_vpll", "sclk_hdmi24m",
+   "sclk_usbphy0", "sclk_usbphy1", "sclk_hdmiphy",
+   "cdclk0", "cdclk1", "cdclk2", "spdif_extclk",
+   "aclk160", "aclk133", "aclk200", "aclk100",
+   "sclk_mfc", "sclk_g3d", "sclk_g2d",
+   "cam_a_pclk", "cam_b_pclk", "s_rxbyteclkhs0_2l",
+   "s_rxbyteclkhs0_4l" };
+PNAME(clkout_dmc_p4210) = { "div_dmcd", "div_dmcp", "div_acp_pclk", "div_dmc",
+   "div_dphy", "none", "div_pwi" };
+PNAME(clkout_cpu_p4210) = { "fout_apll_div_2", "none", "fout_mpll_div_2",
+   "none", "arm_clk_div_2", "div_corem0",
+   "div_corem1", "div_corem0", "div_atb",
+   "div_periph", "div_pclk_dbg", "div_hpm" };
 
 /* Exynos 4x12-specific parent groups */
 PNAME(mout_mpll_user_p4x12) = { "fin_pll", "sclk_mpll", };
@@ -426,6 +453,29 @@ PNAME(mout_user_aclk266_gps_p4x12) = {"fin_pll", 
"div_aclk266_gps", };
 PNAME(mout_pwi_p4x12) = { "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
"none", "sclk_hdmiphy", "sclk_mpll",
"sclk_epll", "sclk_vpll" };
+PNAME(clkout_left_p4x12) = { "sclk_mpll_user_l_div_2", "sclk_apll_div_2",
+   "div_gdl", "div_gpl" };
+PNAME(clkout_right_p4x12) = { "sclk_mpll_user_r_div_2", "sclk_apll_div_2",
+   "div_gdr", "div_gpr" };
+PNAME(clkout_top_p4x12) = { "fout_epll", "fout_vpll", "sclk_hdmi24m",
+   "sclk_usbphy0", "none", "sclk_hdmiphy",
+   "cdclk0", "cdclk1", "cdclk2", "spdif_extclk",
+   "aclk160", "aclk133", "aclk200", "aclk100",
+   "sclk_mfc", "sclk_g3d", "aclk400_mcuisp",
+   "cam_a_pclk", "cam_b_pclk", "s_rxbyteclkhs0_2l",
+  

Re: [PATCH 1/3] ARM: MCPM: provide infrastructure to allow for MCPM loopback

[Doug Anderson]

Nicolas,

On Mon, Jun 23, 2014 at 9:11 PM, Nicolas Pitre  wrote:
> The kernel already has the responsibility to handle resources such as the
> CCI when hotplugging CPUs, during the booting of secondary CPUs, and when
> resuming from suspend/idle.  It would be more coherent and less confusing
> if the CCI for the boot CPU (or cluster)  was also initialized by the kernel 
> rather than expecting the

nit: wrap long line?

> firmware/bootloader to do it and only in that case. After all, the kernel
> has all the necessary code already and the bootloader shouldn't have to
> care at all.
>
> The CCI may be turned on only when the cache is off. Leveraging the CPU
> suspend code to loop back through the low-level MCPM entry point is all
> that is needed to properly turn on the CCI from the kernel by using the
> same code as for secondary boot.
>
> Let's provide a generic MCPM loopback function that can be invoked by
> backend initialization code to set things (CCI or similar) on the boot
> CPU just as it is done for the other CPUs.
>
> Signed-off-by: Nicolas Pitre 
> ---
>  arch/arm/common/mcpm_entry.c | 52 
> 
>  arch/arm/include/asm/mcpm.h  | 16 ++
>  2 files changed, 68 insertions(+)

Thank you very much for posting!  With your series I'm able to boot
all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on
my desk.

Tested-by: Doug Anderson 


I will note that git yelled about whitespace damage on theis patch:

# pwclient git-am 4406301
Applying patch #4406301 using 'git am'
Description: [1/3] ARM: MCPM: provide infrastructure to allow for MCPM loopback
Applying: ARM: MCPM: provide infrastructure to allow for MCPM loopback
/b/tip/src/third_party/kernel/3.8/.git/rebase-apply/patch:51: trailing
whitespace.

/b/tip/src/third_party/kernel/3.8/.git/rebase-apply/patch:95: trailing
whitespace.
 * to the MCPM low-level entry code before returning to the caller.
warning: 2 lines add whitespace errors.
--
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 v2 1/4] clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy

[Tomasz Figa]

This patch adds missing definitions of clocks from CPU and DMC clock
domains, which are necessary to properly represent CLKOUT clock hierarchy
added in further patch.

Signed-off-by: Tomasz Figa 
---
 drivers/clk/samsung/clk-exynos4.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9..f95ae6c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -397,10 +397,15 @@ PNAME(mout_audio2_p4210) = { "cdclk2", "none", 
"sclk_hdmi24m",
"sclk_epll", "sclk_vpll", };
 PNAME(mout_mixer_p4210)= { "sclk_dac", "sclk_hdmi", };
 PNAME(mout_dac_p4210)  = { "sclk_vpll", "sclk_hdmiphy", };
+PNAME(mout_pwi_p4210) = { "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
+   "sclk_usbphy1", "sclk_hdmiphy", "none",
+   "sclk_epll", "sclk_vpll" };
 
 /* Exynos 4x12-specific parent groups */
 PNAME(mout_mpll_user_p4x12) = { "fin_pll", "sclk_mpll", };
 PNAME(mout_core_p4x12) = { "mout_apll", "mout_mpll_user_c", };
+PNAME(mout_gdl_p4x12)  = { "mout_mpll_user_l", "sclk_apll", };
+PNAME(mout_gdr_p4x12)  = { "mout_mpll_user_r", "sclk_apll", };
 PNAME(sclk_ampll_p4x12)= { "mout_mpll_user_t", "sclk_apll", };
 PNAME(group1_p4x12)= { "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
"none", "sclk_hdmiphy", "mout_mpll_user_t",
@@ -418,6 +423,9 @@ PNAME(aclk_p4412)   = { "mout_mpll_user_t", "sclk_apll", };
 PNAME(mout_user_aclk400_mcuisp_p4x12) = {"fin_pll", "div_aclk400_mcuisp", };
 PNAME(mout_user_aclk200_p4x12) = {"fin_pll", "div_aclk200", };
 PNAME(mout_user_aclk266_gps_p4x12) = {"fin_pll", "div_aclk266_gps", };
+PNAME(mout_pwi_p4x12) = { "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
+   "none", "sclk_hdmiphy", "sclk_mpll",
+   "sclk_epll", "sclk_vpll" };
 
 /* fixed rate clocks generated outside the soc */
 static struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] 
__initdata = {
@@ -451,6 +459,9 @@ static struct samsung_mux_clock exynos4_mux_clks[] 
__initdata = {
MUX(0, "mout_onenand1", mout_onenand1_p, SRC_TOP0, 0, 1),
MUX(CLK_SCLK_EPLL, "sclk_epll", mout_epll_p, SRC_TOP0, 4, 1),
MUX(0, "mout_onenand", mout_onenand_p, SRC_TOP0, 28, 1),
+
+   MUX(0, "mout_dmc_bus", sclk_ampll_p4210, SRC_DMC, 4, 1),
+   MUX(0, "mout_dphy", sclk_ampll_p4210, SRC_DMC, 8, 1),
 };
 
 /* list of mux clocks supported in exynos4210 soc */
@@ -459,6 +470,10 @@ static struct samsung_mux_clock exynos4210_mux_early[] 
__initdata = {
 };
 
 static struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
+   MUX(0, "mout_gdl", sclk_ampll_p4210, SRC_LEFTBUS, 0, 1),
+
+   MUX(0, "mout_gdr", sclk_ampll_p4210, SRC_RIGHTBUS, 0, 1),
+
MUX(0, "mout_aclk200", sclk_ampll_p4210, SRC_TOP0, 12, 1),
MUX(0, "mout_aclk100", sclk_ampll_p4210, SRC_TOP0, 16, 1),
MUX(0, "mout_aclk160", sclk_ampll_p4210, SRC_TOP0, 20, 1),
@@ -472,6 +487,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
__initdata = {
MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
+   MUX(0, "mout_hpm", mout_core_p4210, SRC_CPU, 20, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
@@ -503,10 +519,18 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
__initdata = {
MUX(0, "mout_spi0", group1_p4210, SRC_PERIL1, 16, 4),
MUX(0, "mout_spi1", group1_p4210, SRC_PERIL1, 20, 4),
MUX(0, "mout_spi2", group1_p4210, SRC_PERIL1, 24, 4),
+
+   MUX(0, "mout_pwi", mout_pwi_p4210, SRC_DMC, 16, 4),
 };
 
 /* list of mux clocks supported in exynos4x12 soc */
 static struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
+   MUX(0, "mout_mpll_user_l", mout_mpll_p, SRC_LEFTBUS, 4, 1),
+   MUX(0, "mout_gdl", mout_gdl_p4x12, SRC_LEFTBUS, 0, 1),
+
+   MUX(0, "mout_mpll_user_r", mout_mpll_p, SRC_RIGHTBUS, 4, 1),
+   MUX(0, "mout_gdr", mout_gdr_p4x12, SRC_RIGHTBUS, 0, 1),
+
MUX(CLK_MOUT_MPLL_USER_C, "mout_mpll_user_c", mout_mpll_user_p4x12,
SRC_CPU, 24, 1),
MUX(0, "mout_aclk266_gps", aclk_p4412, SRC_TOP1, 4, 1),
@@ -531,6 +555,7 @@ static struct samsung_mux_clock exynos4x12_mux_clks[] 
__initdata = {
MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
+   MUX(0, "mout_hpm", mout_core_p4x12, SRC_CPU, 20, 1),
  

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Russell King - ARM Linux]

On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
> Hi Kukjin,
> 
> On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan  
> wrote:
> > Signed-off-by: Abhilash Kesavan 
> 
> Do you have any comments on this patch ?

I do.

> > diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> > index d10c351..6dd4a11 100644
> > --- a/arch/arm/mach-exynos/pm.c
> > +++ b/arch/arm/mach-exynos/pm.c
> > @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
> > tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
> > __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
> >
> > -   if (!soc_is_exynos5250())
> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> > exynos_cpu_save_register();
...
> > @@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
> > if (exynos_pm_central_resume())
> > goto early_wakeup;
> >
> > -   if (!soc_is_exynos5250())
> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> > exynos_cpu_restore_register();

It is invalid to check just the part number.  The part number on its
own is meaningless without taking account of the implementor.  Both
the implementor and the part number should be checked at each of these
sites.

Another point: exynos have taken it upon themselves to add code which
saves various ARM core registers.  This is a bad idea, it brings us
back to the days where every platform did their own suspend implementations.

CPU level registers should be handled by CPU level code, not by platform
code.  Is there a reason why this can't be added to the Cortex-A9
support code in proc-v7.S ?

> > @@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
> >
> > s3c_pm_do_restore_core(exynos_core_save, 
> > ARRAY_SIZE(exynos_core_save));
> >
> > -   if (!soc_is_exynos5250())
> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> > scu_enable(S5P_VA_SCU);
> >
> >  early_wakeup:
> > @@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct 
> > notifier_block *self,
> > case CPU_PM_ENTER:
> > if (cpu == 0) {
> > exynos_pm_central_suspend();
> > -   exynos_cpu_save_register();
> > +   if (read_cpuid_part_number() == 
> > ARM_CPU_PART_CORTEX_A9)
> > +   exynos_cpu_save_register();
> > }
> > break;
> >
> > case CPU_PM_EXIT:
> > if (cpu == 0) {
> > -   if (!soc_is_exynos5250())
> > +   if (read_cpuid_part_number() ==
> > +   ARM_CPU_PART_CORTEX_A9) {
> > scu_enable(S5P_VA_SCU);
> > -   exynos_cpu_restore_register();
> > +   exynos_cpu_restore_register();
> > +   }
> > exynos_pm_central_resume();
> > }
> > break;

And presumably with the CPU level code dealing with those registers,
you don't need the calls to save and restore these registers in this
notifier.

Which, by the way, is probably illegal to run as it runs in a read-
lock code path and with the SCU disabled.  As you're calling
scu_enable() that means you're non-coherent with the other CPUs,
and therefore locks don't work.

I think this code is very broken and wrongly architected, and shows
that we're continuing to make the same mistakes that we made all
through the 2000s with platforms doing their own crap rather than
properly thinking about this stuff.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 v2 0/4] Add support for Exynos clock output configuration

[Tomasz Figa]

On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of
internal SoC clocks to be output from the SoC. The hardware structure
of CLKOUT related clocks looks as follows:

CMU |---> clock0 -> |   PMU |
|   |   |
several |---> clock1 -> |   mux |
muxes   |   |   +   |---> CLKOUT
dividers|   ... |   gate|
and gates   |   |   |
|---> clockN -> |   |

Since the block responsible for handling the pin is PMU, not CMU,
a separate driver, that binds to PMU node is required and acquires
all input clocks by standard DT clock look-up. This way we don't need
any cross-IP block drivers and cross-driver register sharing or
nodes for fake devices.

To represent the PMU mux/gate clock, generic composite clock is registered.

Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock,
with some additional patches.

Changes since v1:
(http://www.spinics.net/lists/arm-kernel/msg333276.html)
 - rebased onto next-20140624,
 - fixed #clock-cells values in exynos5250.dtsi and exynos5420.dtsi,
 - temporarily removed ISP CLKOUT clocks on Exynos4x12, until ISP clock
   domain handling gets fixed in Exynos4 clock driver.
Changes since RFC v1:
(https://lkml.org/lkml/2014/5/15/506)
 - rebased onto v5 of "Enable usbphy and hsotg for exynos4" series and
   current HEAD of samsung-clk tree,
 - added handling of suspend/resume in the driver,
 - added missing CPU clocks on Exynos4,
 - added CLK_SET_RATE_PARENT to CMU CLKOUT gates on Exynos4,
 - fixed bit field width on Exynos4,
 - added CLKOUT CMU registers of Exynos4 to save/restore list,
 - added CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT to clkout clock,
 - changed the binding to use 1-cell clock specifier to allow extension
   with further PMU clocks in future, if needed.

Tomasz Figa (4):
  clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy
  clk: samsung: exynos4: Add CLKOUT clock hierarchy
  clk: samsung: Add driver to control CLKOUT line on Exynos SoCs
  ARM: dts: exynos: Update PMU node with CLKOUT related data

 .../devicetree/bindings/arm/samsung/pmu.txt|  30 
 arch/arm/boot/dts/exynos4210.dtsi  |  10 ++
 arch/arm/boot/dts/exynos4x12.dtsi  |   7 +
 arch/arm/boot/dts/exynos5250.dtsi  |   3 +
 arch/arm/boot/dts/exynos5420.dtsi  |   3 +
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos-clkout.c| 153 +++
 drivers/clk/samsung/clk-exynos4.c  | 166 -
 include/dt-bindings/clock/exynos4.h|   5 +
 9 files changed, 374 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c

-- 
1.9.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 3/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback

[Doug Anderson]

Nicolas,

On Mon, Jun 23, 2014 at 9:11 PM, Nicolas Pitre  wrote:
> The Chromebook firmware doesn't enable the CCI for the boot cpu, and
> arguably it shouldn't have to either. Let's have the kernel handle the
> CCI on its own for the boot CPU the same way it does it for secondary CPUs
> by using the MCPM loopback.
>
> Signed-off-by: Nicolas Pitre 
> ---
>  arch/arm/mach-exynos/mcpm-exynos.c | 15 +++
>  1 file changed, 15 insertions(+)

Thank you very much for posting!  With your series I'm able to boot
all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on
my desk.

Tested-by: Doug Anderson 
--
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] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 05:11:14PM +0100, Russell King - ARM Linux wrote:
> Another point: exynos have taken it upon themselves to add code which
> saves various ARM core registers.  This is a bad idea, it brings us
> back to the days where every platform did their own suspend implementations.
> 
> CPU level registers should be handled by CPU level code, not by platform
> code.  Is there a reason why this can't be added to the Cortex-A9
> support code in proc-v7.S ?

BTW, Shawn Guo recently posted a patch to add the diagnostic register
save/restore to proc-v7.S.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Tomasz Figa]

Hi Russell,

On 24.06.2014 18:11, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
>> Hi Kukjin,
>>
>> On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan  
>> wrote:
>>> Signed-off-by: Abhilash Kesavan 
>>
>> Do you have any comments on this patch ?
> 
> I do.
> 
>>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>>> index d10c351..6dd4a11 100644
>>> --- a/arch/arm/mach-exynos/pm.c
>>> +++ b/arch/arm/mach-exynos/pm.c
>>> @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
>>> tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
>>> __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
>>>
>>> -   if (!soc_is_exynos5250())
>>> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>>> exynos_cpu_save_register();
> ...
>>> @@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
>>> if (exynos_pm_central_resume())
>>> goto early_wakeup;
>>>
>>> -   if (!soc_is_exynos5250())
>>> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>>> exynos_cpu_restore_register();
> 
> It is invalid to check just the part number.  The part number on its
> own is meaningless without taking account of the implementor.  Both
> the implementor and the part number should be checked at each of these
> sites.

Just out of curiosity, are you aware of more than one implementor of
Cortex A9 on Exynos SoCs that would differ in having the need for save
and restore of those registers?

> 
> Another point: exynos have taken it upon themselves to add code which
> saves various ARM core registers.  This is a bad idea, it brings us
> back to the days where every platform did their own suspend implementations.
> 
> CPU level registers should be handled by CPU level code, not by platform
> code.  Is there a reason why this can't be added to the Cortex-A9
> support code in proc-v7.S ?

I agree that there is nothing platform specific in saving and restoring
those registers and that this should be probably handled by generic code.

However, when running in non-secure world, the only way to restore this
is to call a firmware operation, which is platform specific. Is there a
way to do something like this from proc-v7.S?

> 
>>> @@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
>>>
>>> s3c_pm_do_restore_core(exynos_core_save, 
>>> ARRAY_SIZE(exynos_core_save));
>>>
>>> -   if (!soc_is_exynos5250())
>>> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>>> scu_enable(S5P_VA_SCU);
>>>
>>>  early_wakeup:
>>> @@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct 
>>> notifier_block *self,
>>> case CPU_PM_ENTER:
>>> if (cpu == 0) {
>>> exynos_pm_central_suspend();
>>> -   exynos_cpu_save_register();
>>> +   if (read_cpuid_part_number() == 
>>> ARM_CPU_PART_CORTEX_A9)
>>> +   exynos_cpu_save_register();
>>> }
>>> break;
>>>
>>> case CPU_PM_EXIT:
>>> if (cpu == 0) {
>>> -   if (!soc_is_exynos5250())
>>> +   if (read_cpuid_part_number() ==
>>> +   ARM_CPU_PART_CORTEX_A9) {
>>> scu_enable(S5P_VA_SCU);
>>> -   exynos_cpu_restore_register();
>>> +   exynos_cpu_restore_register();
>>> +   }
>>> exynos_pm_central_resume();
>>> }
>>> break;
> 
> And presumably with the CPU level code dealing with those registers,
> you don't need the calls to save and restore these registers in this
> notifier.
> 
> Which, by the way, is probably illegal to run as it runs in a read-
> lock code path and with the SCU disabled.  As you're calling
> scu_enable() that means you're non-coherent with the other CPUs,
> and therefore locks don't work.

I don't see the read lock code path you mention. Could you elaborate on
this? By the way, other CPUs are still offline at this point.

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 v2] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Doug Anderson]

Tushar,

On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera  wrote:
> On 06/24/2014 02:19 AM, Doug Anderson wrote:
>> This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
>> including:
>> * The keyboard
>> * The i2c tunnel
>> * The tps65090 under the i2c tunnel
>> * The battery under the i2c tunnel
>>
>> To add extra motivation, it should be noted that tps65090 is one of
>> the things needed to get display-related FETs turned on for pit and
>> pi.
>>
>> Note that this relies on a few outstanding changes:
>> * Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
>>   (spi: s3c64xx: for DT platofrms always get the chipselect info from
>>   DT node) to work properly and match the documented bindings.  See
>>    and
>>   
>>
>> Signed-off-by: Doug Anderson 
>> Tested-by: Javier Martinez Canillas 
>
> Along with the dependency patches on next-20140623, tested keyboard on
> Peach-Pi board.
>
> Tested-by: Tushar Behera 
>
> Some comments below.
>
>> ---
>> Changes in v2:
>> - Now just one patch since mfd patch landed.
>> - Rebased to ToT linux-next
>>
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 
>> +
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 
>> +
>>  2 files changed, 290 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index 7649982..581f385 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>
>> + regulators {
>> + dcdc1 {
>> + ti,enable-ext-control;
>> + };
>> + dcdc2 {
>> + ti,enable-ext-control;
>> + };
>> + dcdc3 {
>> + ti,enable-ext-control;
>> + };
>> + fet1 {
>
> "tps65090_fet1: fet1 {" ?
>
>> + regulator-name = "vcd_led";
>> + };
>> + tps65090_fet2: fet2 {
>
> I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
> also. That way it would be easy to reference them in subsequent DT nodes.
>
> Same comment for Peach-Pi dts file too.

OK.  I added it to all the regulators in tps65090.  That'll probably
be useful for Javier in his max77802 work.

-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 v3] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Doug Anderson]

This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel

To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.

Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
  (spi: s3c64xx: for DT platofrms always get the chipselect info from
  DT node) to work properly and match the documented bindings.  See
   and
  

Signed-off-by: Doug Anderson 
Tested-by: Javier Martinez Canillas 
Tested-by: Tushar Behera 
---
Changes in v3:
- Added aliases for tps65090 regulators as per Tushar.

Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 +
 2 files changed, 290 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..b2f1237 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -25,6 +25,11 @@
"google,pit", "google,peach","samsung,exynos5420",
"samsung,exynos5";
 
+   aliases {
+   /* Assign 20 so we don't get confused w/ builtin ones */
+   i2c20 = "/spi@12d4/cros-ec@0/i2c-tunnel";
+   };
+
backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 100 0>;
@@ -87,6 +92,13 @@
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
};
+
+   vbat: fixed-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat-supply";
+   regulator-boot-on;
+   regulator-always-on;
+   };
 };
 
 &dp {
@@ -231,6 +243,20 @@
samsung,pin-drv = <0>;
};
 
+   ec_irq: ec-irq {
+   samsung,pins = "gpx1-5";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   tps65090_irq: tps65090-irq {
+   samsung,pins = "gpx2-5";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
dp_hpd_gpio: dp_hpd_gpio {
samsung,pins = "gpx2-6";
samsung,pin-function = <0>;
@@ -247,6 +273,19 @@
 };
 
 &pinctrl_3 {
+   /* Drive SPI lines at x2 for better integrity */
+   spi2-bus {
+   samsung,pin-drv = <2>;
+   };
+
+   /* Drive SPI chip select at x2 for better integrity */
+   ec_spi_cs: ec-spi-cs {
+   samsung,pins = "gpb1-2";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <2>;
+   };
+
usb300_vbus_en: usb300-vbus-en {
samsung,pins = "gph0-0";
samsung,pin-function = <1>;
@@ -266,6 +305,111 @@
status = "okay";
 };
 
+&spi_2 {
+   status = "okay";
+   num-cs = <1>;
+   samsung,spi-src-clk = <0>;
+   cs-gpios = <&gpb1 2 0>;
+
+   cros_ec: cros-ec@0 {
+   compatible = "google,cros-ec-spi";
+   interrupt-parent = <&gpx1>;
+   interrupts = <5 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&ec_spi_cs &ec_irq>;
+   reg = <0>;
+   spi-max-frequency = <3125000>;
+
+   controller-data {
+   samsung,spi-feedback-delay = <1>;
+   };
+
+   i2c-tunnel {
+   compatible = "google,cros-ec-i2c-tunnel";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   google,remote-bus = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   sbs,i2c-retry-count = <2>;
+   };
+
+   power-regulator@48 {
+   compatible = "ti,tps65090";
+   reg = <0x48>;
+
+   /*
+* Config irq to disable internal pulls
+* even though we run in polling mode.
+*/
+   pinctrl-names = "default";
+   pinctrl-0 = <&tps65090_irq>;
+
+   vsys1-supply = <&vbat>;
+  

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 06:20:56PM +0200, Tomasz Figa wrote:
> Hi Russell,
> 
> On 24.06.2014 18:11, Russell King - ARM Linux wrote:
> > On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
> >> Hi Kukjin,
> >>
> >> On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan  
> >> wrote:
> >>> Signed-off-by: Abhilash Kesavan 
> >>
> >> Do you have any comments on this patch ?
> > 
> > I do.
> > 
> >>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> >>> index d10c351..6dd4a11 100644
> >>> --- a/arch/arm/mach-exynos/pm.c
> >>> +++ b/arch/arm/mach-exynos/pm.c
> >>> @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
> >>> tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
> >>> __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
> >>>
> >>> -   if (!soc_is_exynos5250())
> >>> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> >>> exynos_cpu_save_register();
> > ...
> >>> @@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
> >>> if (exynos_pm_central_resume())
> >>> goto early_wakeup;
> >>>
> >>> -   if (!soc_is_exynos5250())
> >>> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> >>> exynos_cpu_restore_register();
> > 
> > It is invalid to check just the part number.  The part number on its
> > own is meaningless without taking account of the implementor.  Both
> > the implementor and the part number should be checked at each of these
> > sites.
> 
> Just out of curiosity, are you aware of more than one implementor of
> Cortex A9 on Exynos SoCs that would differ in having the need for save
> and restore of those registers?

That doesn't stop stuff changing in the future.  We've been here before.
Let's do the job properly if we're going to do the job at all.

If people still whine about this, I will force a change to make it
harder to do the wrong thing - I will get rid of the _part_number
interface replacing it with one which always returns the implementor
as well as the part number so both have to be checked.

> > Another point: exynos have taken it upon themselves to add code which
> > saves various ARM core registers.  This is a bad idea, it brings us
> > back to the days where every platform did their own suspend implementations.
> > 
> > CPU level registers should be handled by CPU level code, not by platform
> > code.  Is there a reason why this can't be added to the Cortex-A9
> > support code in proc-v7.S ?
> 
> I agree that there is nothing platform specific in saving and restoring
> those registers and that this should be probably handled by generic code.
> 
> However, when running in non-secure world, the only way to restore this
> is to call a firmware operation, which is platform specific. Is there a
> way to do something like this from proc-v7.S?

We never call firmware operations from assembly code.  However, in exynos'
case, it's not running in non-secure mode because it's happily reading
and writing these registers with no issue.

Platforms running in non-secure mode already have to ensure that various
work-arounds are implemented in their firmware/boot loader, and this
really is no different (we wouldn't need this code in the kernel in the
first place if the firmware/boot loader would get its act together.)

> > And presumably with the CPU level code dealing with those registers,
> > you don't need the calls to save and restore these registers in this
> > notifier.
> > 
> > Which, by the way, is probably illegal to run as it runs in a read-
> > lock code path and with the SCU disabled.  As you're calling
> > scu_enable() that means you're non-coherent with the other CPUs,
> > and therefore locks don't work.
> 
> I don't see the read lock code path you mention. Could you elaborate on
> this? By the way, other CPUs are still offline at this point.

We get there from kernel/cpu_pm.c, when the notifier chain is called.
The notifier chain is called while taking a read lock on
cpu_pm_notifier_lock.

If this is about the last CPU going down, then why the notifier?  Why
not put the code in exynos_suspend_enter() ?  Why add this needless
complexity?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Javier Martinez Canillas]

Hello Doug,

On 06/24/2014 06:28 PM, Doug Anderson wrote:
> Tushar,
> 
> On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera  wrote:
>> On 06/24/2014 02:19 AM, Doug Anderson wrote:
>>> This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
>>> including:
>>> * The keyboard
>>> * The i2c tunnel
>>> * The tps65090 under the i2c tunnel
>>> * The battery under the i2c tunnel
>>>
>>> To add extra motivation, it should be noted that tps65090 is one of
>>> the things needed to get display-related FETs turned on for pit and
>>> pi.
>>>
>>> Note that this relies on a few outstanding changes:
>>> * Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
>>>   (spi: s3c64xx: for DT platofrms always get the chipselect info from
>>>   DT node) to work properly and match the documented bindings.  See
>>>    and
>>>   
>>>
>>> Signed-off-by: Doug Anderson 
>>> Tested-by: Javier Martinez Canillas 
>>
>> Along with the dependency patches on next-20140623, tested keyboard on
>> Peach-Pi board.
>>
>> Tested-by: Tushar Behera 
>>
>> Some comments below.
>>
>>> ---
>>> Changes in v2:
>>> - Now just one patch since mfd patch landed.
>>> - Rebased to ToT linux-next
>>>
>>>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 
>>> +
>>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 
>>> +
>>>  2 files changed, 290 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> index 7649982..581f385 100644
>>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>
>>> + regulators {
>>> + dcdc1 {
>>> + ti,enable-ext-control;
>>> + };
>>> + dcdc2 {
>>> + ti,enable-ext-control;
>>> + };
>>> + dcdc3 {
>>> + ti,enable-ext-control;
>>> + };
>>> + fet1 {
>>
>> "tps65090_fet1: fet1 {" ?
>>
>>> + regulator-name = "vcd_led";
>>> + };
>>> + tps65090_fet2: fet2 {
>>
>> I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
>> also. That way it would be easy to reference them in subsequent DT nodes.
>>
>> Same comment for Peach-Pi dts file too.
> 
> OK.  I added it to all the regulators in tps65090.  That'll probably
> be useful for Javier in his max77802 work.
>

Thanks, in fact I did add both tps65090_dcdc1 and tps65090_dcdc2 labels to be
able to use these regulators as supply for some of the max77802 regulators.

Will rebase on top of this.

Best regards,
Javier

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

Re: [PATCH v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators

[Javier Martinez Canillas]

Hello Mark,

On 06/23/2014 11:47 AM, Mark Brown wrote:
> On Mon, Jun 23, 2014 at 11:28:25AM +0200, Javier Martinez Canillas wrote:
>> On 06/21/2014 10:40 PM, Mark Brown wrote:
> 
>> > That's not really relevant here - I'm asking if the regulators get their
>> > own supplies rather than if anything uses them.
> 
>> Sorry if I keep misunderstanding your question but the regulators in this 
>> PMIC
>> don't have a parent supply/regulator node.
> 
> They should, I'm pretty sure the device does actually regulate one
> supply into another.
> 

Thanks a lot for the clarification. This was not evident to me when I read the
PMIC datasheet and because both the max77xxx Chrome OS 3.8 and mainline max77686
drivers used a simplistic model of the power scheme.

But Doug confirmed to me that some regulators on this PMIC do indeed use others
regulators as a power supply so I'll change this in the next version of the
patch-set.

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: sdhci_s3c_consider_clock scheduling while atomic - clk_round_rate

[Tomasz Figa]

Hi Daniel,

[adding Ulf, Chris and Mike to the discussion]

On 24.06.2014 11:48, Daniel Drake wrote:
> sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts
> disabled, and this calls into sdhci_s3c_consider_clock().
> 
> The patch "mmc: sdhci-s3c: Cache bus clock rates" addressed some
> scheduling while atomic in this function, but there are more issues
> here, seen while testing 3.16-rc2 on exynos4412:
> 
> BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:103
> in_atomic(): 1, irqs_disabled(): 128, pid: 75, name: mmcqd/0
> Preemption disabled at:[<  (null)>]   (null)
> 
> CPU: 0 PID: 75 Comm: mmcqd/0 Not tainted 3.16.0-rc2-00028-ge9fe7eb-dirty #77
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0xc4)
> [] (dump_stack) from [] (mutex_lock+0x1c/0x3c)
> [] (mutex_lock) from [] (clk_prepare_lock+0x6c/0xf4)
> [] (clk_prepare_lock) from [] (clk_round_rate+0x10/0x2c)
> [] (clk_round_rate) from [] 
> (sdhci_s3c_set_clock+0x4c/0x1e8)
> [] (sdhci_s3c_set_clock) from []
> (sdhci_cmu_set_clock+0x54/0x140)
> [] (sdhci_cmu_set_clock) from []
> (sdhci_do_set_ios+0x138/0x58c)
> [] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x28/0x34)
> 
> clk_round_rate cannot be called here because it takes a mutex.
> 
> sdhci_s3c_set_clock() also calls into clk_prepare_enable() which looks
> like it could trigger this problem too.

Apparently this is related to generic sdhci code calling .set_clock()
under spin_lock_irqsave(). For reference, see sdhci_do_set_ios() and
sdhci_tasklet_finish().

Chris, Ulf, any suggestions?

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] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Tomasz Figa]

On 24.06.2014 18:30, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 06:20:56PM +0200, Tomasz Figa wrote:
>> Hi Russell,
>>
>> On 24.06.2014 18:11, Russell King - ARM Linux wrote:
>>> On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
 Hi Kukjin,

 On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan  
 wrote:
> Signed-off-by: Abhilash Kesavan 

 Do you have any comments on this patch ?
>>>
>>> I do.
>>>
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index d10c351..6dd4a11 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
> tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
> __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
>
> -   if (!soc_is_exynos5250())
> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> exynos_cpu_save_register();
>>> ...
> @@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
> if (exynos_pm_central_resume())
> goto early_wakeup;
>
> -   if (!soc_is_exynos5250())
> +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> exynos_cpu_restore_register();
>>>
>>> It is invalid to check just the part number.  The part number on its
>>> own is meaningless without taking account of the implementor.  Both
>>> the implementor and the part number should be checked at each of these
>>> sites.
>>
>> Just out of curiosity, are you aware of more than one implementor of
>> Cortex A9 on Exynos SoCs that would differ in having the need for save
>> and restore of those registers?
> 
> That doesn't stop stuff changing in the future.  We've been here before.
> Let's do the job properly if we're going to do the job at all.

I tend to disagree. The chance of a new Cortex A9 based SoC with
different implementor code showing up is so close to zero that I don't
see increasing of code complexity by adding yet another check justified.

> 
> If people still whine about this, I will force a change to make it
> harder to do the wrong thing - I will get rid of the _part_number
> interface replacing it with one which always returns the implementor
> as well as the part number so both have to be checked.

That might be actually a better option. Something like

if (read_cpuid_impl_and_part() == ARM_CPU(impl, part))

or even

if (ARM_CPU_IS(impl, part))

would keep the checks simple, while still checking both values.

> 
>>> Another point: exynos have taken it upon themselves to add code which
>>> saves various ARM core registers.  This is a bad idea, it brings us
>>> back to the days where every platform did their own suspend implementations.
>>>
>>> CPU level registers should be handled by CPU level code, not by platform
>>> code.  Is there a reason why this can't be added to the Cortex-A9
>>> support code in proc-v7.S ?
>>
>> I agree that there is nothing platform specific in saving and restoring
>> those registers and that this should be probably handled by generic code.
>>
>> However, when running in non-secure world, the only way to restore this
>> is to call a firmware operation, which is platform specific. Is there a
>> way to do something like this from proc-v7.S?
> 
> We never call firmware operations from assembly code.  However, in exynos'
> case, it's not running in non-secure mode because it's happily reading
> and writing these registers with no issue.

Current version of code, yes. However it handles only Exynos-based
boards running in secure mode. For those running in non-secure mode,
mainline does not support sleep yet.

I already have patches to change this, which I was planning to post
after eliminating last issue. The change set includes making this
save/restore being executed only in secure mode.

> 
> Platforms running in non-secure mode already have to ensure that various
> work-arounds are implemented in their firmware/boot loader, and this
> really is no different (we wouldn't need this code in the kernel in the
> first place if the firmware/boot loader would get its act together.)

In ideal world (which I would be glad to be living in)...

We both know that we can't fully rely on firmware. Firmware bugs are
common and in many cases we can't do anything about it, because it
already comes with the device and in many cases it is undesirable to
change it or it can't be done at all.

> 
>>> And presumably with the CPU level code dealing with those registers,
>>> you don't need the calls to save and restore these registers in this
>>> notifier.
>>>
>>> Which, by the way, is probably illegal to run as it runs in a read-
>>> lock code path and with the SCU disabled.  As you're calling
>>> scu_enable() that means you're non-coherent with the other CPUs,
>>> and therefore locks don't work.
>>
>> I don't see the read lock code path you mention. Could you elaborat

Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

[Laura Abbott]

On 6/23/2014 11:32 AM, Kevin Hilman wrote:
> On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera  wrote:
>> Adding linux-samsung-soc and linux-arm-kernel ML for wider audience.
>>
>> On 06/19/2014 04:12 PM, Tushar Behera wrote:
>>> On 06/19/2014 03:02 PM, Tushar Behera wrote:
 On 06/18/2014 09:22 AM, Kevin Hilman wrote:
> On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera  wrote:
>> On 06/17/2014 10:23 PM, Kevin Hilman wrote:
>>> Sachin,
>>>
>>> On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot  
>>> wrote:

 Tree/Branch: mainline
 Git describe: v3.16-rc1-2-gebe0618
 Failed boot tests (console logs at the end)
 ===
  exynos5420-arndale-octa: FAIL:arm-exynos_defconfig
 ste-snowball: FAIL:arm-u8500_defconfig
>>>
>>> FYI... these failures are getting more consistent on my octa board,
>>> but still not failing every time.
>>>
>>> Kevin
>>>
>>
>> Hi Kevin,
>>
>> Same here.
>>
>> Observation: If you soft-reset the board (through the jumpers) after
>> getting this problem, the problem keeps repeating. But if you hard-reset
>> the board (by removing the power cord), the problem doesn't occur during
>> next iteration.
>
> I don't ever use the soft-reset, I only toggle the wall power.  I
> don't ever actually remove the power cord though, I'm using a
> USB-controlled relay to toggle the wall power.
>
> Kevin
>

 Laura,

 We are getting following kernel panic [1] (not always, but quite
 regularly) while booting Arndale-Octa (based on Samsung's Exynos5420)
 board with upstream kernel. I haven't observed this issue with other
 boards yet.

 This issue is observed when I am booting with uImage + dtb (within
 roughly ~10 iterations).

>>>
>>> Some more information:
>>>
>>> The boot logs are provided in pastebin, okay[2] and failed[3].
>>>
>>> In case of boot failures, I am getting a higher value for vm_total_pages
>>> (684424 in [3]). In case of successful boot on my board, it is always
>>> 521232 [2] on my board.
> 
> I can confirm that reverting the "Get rid of meminfo" patch gets the
> Octa board booting reliably again for me also.
> 
> In case it helps, some boot logs for failures from the last copule
> linux-next build/boot cycles can be seen here:
> http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
> http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
> 

Sorry, I missed this yesterday. I'm going to take a look.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 3/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback

[Nicolas Pitre]

On Tue, 24 Jun 2014, Doug Anderson wrote:

> Thank you very much for posting!  With your series I'm able to boot
> all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on
> my desk.
> 
> Tested-by: Doug Anderson 

Thanks to all.  I've submitted those patches, with minor nits fixed, to 
RMK's system as patches 8081 to 8083.


Nicolas
--
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] devicetree: Add generic IOMMU device tree bindings

[Olav Haugan]

On 6/24/2014 2:18 AM, Will Deacon wrote:
> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
>> On 5/30/2014 12:06 PM, Arnd Bergmann wrote:
>>> On Friday 30 May 2014 08:16:05 Rob Herring wrote:
 Presumably the ID would be the streamID on ARM's SMMU. How would a
 master with 8 streamIDs be described? This is what Calxeda midway has
 for SATA and I would expect that to be somewhat common. Either you
 need some ID masking or you'll have lots of duplication when you have
 windows.
>>>
>>> I don't understand the problem. If you have stream IDs 0 through 7,
>>> you would have
>>>
>>> master@a {
>>> ...
>>> iommus = <&smmu 0>;
>>> };
>>>
>>> master@b {
>>> ...
>>> iommus = <&smmu 1;
>>> };
>>>
>>> ...
>>>
>>> master@12 {
>>> ...
>>> iommus = <&smmu 7;
>>> };
>>>
>>> and you don't need a window at all. Why would you need a mask of
>>> some sort?
>>
>> We have multiple-master SMMUs and each master emits a variable number of
>> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
>> for this) to the StreamIDs due to limited number of StreamID 2 Context
>> Bank entries in the SMMU. If my understanding is correct we would
>> represent this in the DT like this:
>>
>>  iommu {
>>  #address-cells = <2>;
>>  #size-cells = <0>;
>>  };
>>
>>  master@a {
>>  ...
>>  iommus = <&iommu StreamID0 MASK0>,
>>   <&iommu StreamID1 MASK1>,
>>   <&iommu StreamID2 MASK2>;
>>  };
> 
> Stupid question, but why not simply describe the masked IDs? What use does
> the `raw' ID have to Linux?

We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?

We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Yuvaraj,

On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D  wrote:
> This patch makes use of mmc_regulator_get_supply() to handle
> the vmmc and vqmmc regulators.Also it moves the code handling
> the these regulators to dw_mci_set_ios().It turned on the vmmc
> and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
> during MMC_POWER_OFF.
>
> Signed-off-by: Yuvaraj Kumar C D 
> ---
>  drivers/mmc/host/dw_mmc.c |   71 
> ++---
>  drivers/mmc/host/dw_mmc.h |2 ++
>  2 files changed, 36 insertions(+), 37 deletions(-)

Perhaps you could CC me on the whole series for the next version since
I was involved in privately reviewing previous versions?

Overall caveat for my review is that I'm nowhere near an SD/MMC expert.


> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 1ac227c..f5cabce 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
> mmc_ios *ios)
> struct dw_mci_slot *slot = mmc_priv(mmc);
> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> u32 regs;
> +   int ret;
>
> switch (ios->bus_width) {
> case MMC_BUS_WIDTH_4:
> @@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
> mmc_ios *ios)
>
> switch (ios->power_mode) {
> case MMC_POWER_UP:
> +   if ((!IS_ERR(mmc->supply.vmmc)) &&
> +   !test_bit(DW_MMC_CARD_POWERED, &slot->flags)) 
> {
> +   ret = regulator_enable(mmc->supply.vmmc);
> +   if (!ret)
> +   set_bit(DW_MMC_CARD_POWERED, &slot->flags);
> +   }

As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
different times.

Also: if you fail to turn on either of the regulators it feels like
you should print a pretty nasty error message since your device will
almost certainly not work.


> set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
> regs = mci_readl(slot->host, PWREN);
> regs |= (1 << slot->id);
> mci_writel(slot->host, PWREN, regs);
> break;
> case MMC_POWER_OFF:
> +   if (!IS_ERR(mmc->supply.vqmmc) &&
> +   test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
> +   ret = regulator_disable(mmc->supply.vqmmc);
> +   if (!ret)
> +   clear_bit(DW_MMC_IO_POWERED, &slot->flags);
> +   }
> +   if (!IS_ERR(mmc->supply.vmmc) &&
> +   test_bit(DW_MMC_CARD_POWERED, &slot->flags)) {
> +   ret = regulator_disable(mmc->supply.vmmc);
> +   if (!ret)
> +   clear_bit(DW_MMC_CARD_POWERED, &slot->flags);
> +   }
> regs = mci_readl(slot->host, PWREN);
> regs &= ~(1 << slot->id);
> mci_writel(slot->host, PWREN, regs);
> break;
> +   case MMC_POWER_ON:
> +   if (!IS_ERR(mmc->supply.vqmmc) &&
> +   !test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
> +   ret = regulator_enable(mmc->supply.vqmmc);
> +   if (!ret)
> +   set_bit(DW_MMC_IO_POWERED, &slot->flags);
> +   }
> default:
> break;
> }
> @@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host, 
> unsigned int id)
> mmc->f_max = freq[1];
> }
>
> -   mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
> +   /*if there are external regulators, get them*/
> +   ret = mmc_regulator_get_supply(mmc);
> +   if (ret == -EPROBE_DEFER)
> +   goto err_setup_bus;
> +
> +   if (!mmc->ocr_avail)
> +   mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>
> if (host->pdata->caps)
> mmc->caps = host->pdata->caps;
> @@ -2133,7 +2165,7 @@ static int dw_mci_init_slot(struct dw_mci *host, 
> unsigned int id)
>
>  err_setup_bus:
> mmc_free_host(mmc);
> -   return -EINVAL;
> +   return ret;
>  }
>
>  static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
> @@ -2375,24 +2407,6 @@ int dw_mci_probe(struct dw_mci *host)
> }
> }
>
> -   host->vmmc = devm_regulator_get_optional(host->dev, "vmmc");
> -   if (IS_ERR(host->vmmc)) {
> -   ret = PTR_ERR(host->vmmc);
> -   if (ret == -EPROBE_DEFER)
> -   goto err_clk_ciu;
> -
> -   dev_info(host->dev, "no vmmc regulator found: %d\n", ret);
> -   host->vmmc = NULL;
> -   } else {
> -   ret = regulator_enable(host->vmmc);
> -   if (ret) {
> -   

Re: [PATCH 2/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Doug Anderson]

Yuvaraj,

On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D  wrote:
> On exynos 5250 and 5420 based boards which uses built-in CD# line
> for card detection.But unfortunately CD# line is on the same voltage
> rails as of I/O voltage rails.When we cut off vqmmc,the consequent
> card detection will break in these boards.
>
> Also if we let alone the vqmmc turned on when vmmc turned off, the
> card could have half way powered and this can damage the card.So
> this patch adds a check so that, if the board used the built-in
> card detection mechanism i.e through CDETECT, it will not turned
> down vqmmc and vmmc both.
>
> Signed-off-by: Yuvaraj Kumar C D 
> ---
>  drivers/mmc/host/dw_mmc.c |   23 +++
>  1 file changed, 23 insertions(+)

Yes, but...

As I mentioned in our separate email thread about this you're now
preventing mmc_power_cycle() from working properly.

IMHO you need the patch I sent you back on April 24th (was it that
long ago?).  Due to the brokenness of exynos (and anyone else that
powers CD off of vqmmc) you need to extend the MMC core to
differentiate several different types of "power off":

* power off because no card is plugged in: you should keep your card on.
* power off because you're power cycling: you should power off your card.
* power off because the system is suspending: you should power off your card.

...the third bullet point is something I hadn't though of until just
now and probably isn't addressed in my old patch...


Also: as we've discussed privately: you could imagine someone
designing an exynos5-based board where they've put the CD on a
separate GPIO.  On a system like this then all these hacks won't be
necessary.

---

Verbatim from my email about this topic on May 28th:

There are two important cases to handle:

1. Properly power cycle both vmmc and vqmmc (at the same time!) in
mmc_power_cycle().

2. DON'T power off for mmc_power_off() unless it's part of
mmc_power_cycle().  Specifically note that mmc_power_off() is called
in a whole bunch of places other than mmc_power_cycle().  For
instance, if we fail to probe a card we'll call mmc_power_off().  All
of these _must_ not turn off power to card detect or else we won't be
able to see future card insertions.  Note that mmc_power_off() might
be called on its own even when a card is inserted.  Look at the end of
mmc_rescan_try_freq().  It will be called if there are errors
attaching a card.


Rules to always remember:

* On all boards you should turn on vmmc and vqmmc at the same time.
It's illegal to have vqmmc on without vmmc and not good to have vmmc
on without vqmmc.

* On exynos you must ensure that vqmmc is on at all times, except
during power cycling of a card.  If vqmmc is not on you can't detect
card insertions or removals since the card detect line won't be
powered.

* To handle errors, you must ensure that mmc_power_cycle() actually
cycles power to the card.
--
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] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> On 6/24/2014 2:18 AM, Will Deacon wrote:
> > On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> >> We have multiple-master SMMUs and each master emits a variable number of
> >> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> >> for this) to the StreamIDs due to limited number of StreamID 2 Context
> >> Bank entries in the SMMU. If my understanding is correct we would
> >> represent this in the DT like this:
> >>
> >>iommu {
> >>#address-cells = <2>;
> >>#size-cells = <0>;
> >>};
> >>
> >>master@a {
> >>...
> >>iommus = <&iommu StreamID0 MASK0>,
> >> <&iommu StreamID1 MASK1>,
> >> <&iommu StreamID2 MASK2>;
> >>};
> > 
> > Stupid question, but why not simply describe the masked IDs? What use does
> > the `raw' ID have to Linux?
> 
> We do describe the masked StreamID (SID) but we need to specify the mask
> that the SMMU should apply to the incoming SIDs, right?
> 
> We have a bus master that emits 43 unique SIDs. However, we have only 40
> SMMU_SMRn registers in the SMMU. So we need to mask out some of the
> incoming SID bits so that the 43 SIDs can match one of 40 entries in the
> SMR.

Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.

There have been patches previously posted by Andreas Herrmann helping here.
I'd be glad to see them revived.

Will
--
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] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 07:16:47PM +0200, Tomasz Figa wrote:
> I tend to disagree. The chance of a new Cortex A9 based SoC with
> different implementor code showing up is so close to zero that I don't
> see increasing of code complexity by adding yet another check justified.

That's your opinion which I strongly disagree with.

> > If people still whine about this, I will force a change to make it
> > harder to do the wrong thing - I will get rid of the _part_number
> > interface replacing it with one which always returns the implementor
> > as well as the part number so both have to be checked.
> 
> That might be actually a better option. Something like
> 
>   if (read_cpuid_impl_and_part() == ARM_CPU(impl, part))
> 
> or even
> 
>   if (ARM_CPU_IS(impl, part))
> 
> would keep the checks simple, while still checking both values.

Indeed, but... Cortex is an ARM Ltd trademark, so I really doubt that
we'll see a Cortex processor implemented by another party other than
ARM.  So, there's no need for ARM_CPU(impl, part).

> > We never call firmware operations from assembly code.  However, in exynos'
> > case, it's not running in non-secure mode because it's happily reading
> > and writing these registers with no issue.
> 
> Current version of code, yes. However it handles only Exynos-based
> boards running in secure mode. For those running in non-secure mode,
> mainline does not support sleep yet.
> 
> I already have patches to change this, which I was planning to post
> after eliminating last issue. The change set includes making this
> save/restore being executed only in secure mode.

As Will has already pointed out, writing to the diagnostic register
becomes a no-op in non-secure mode - it doesn't fault.  So moving
the saving and restoring of this register into generic code, where
other platforms already require it, makes total sense.

Of course, when you have to deal with it in non-secure mode, that's
something that you have to deal with, but in secure mode, platform
code should not have to worry about this level of detail.

> In ideal world (which I would be glad to be living in)...
> 
> We both know that we can't fully rely on firmware. Firmware bugs are
> common and in many cases we can't do anything about it, because it
> already comes with the device and in many cases it is undesirable to
> change it or it can't be done at all.

Yes, I'm aware of the crap situation there.  That doesn't stop us
talking about these aspects though and setting what we expect in the
future - and changing the code to a better structure.

> > We get there from kernel/cpu_pm.c, when the notifier chain is called.
> > The notifier chain is called while taking a read lock on
> > cpu_pm_notifier_lock.
> 
> Your point. Thanks for explaining this. However this will be still
> running with just one CPU online.
> 
> > 
> > If this is about the last CPU going down, then why the notifier?  Why
> > not put the code in exynos_suspend_enter() ?  Why add this needless
> > complexity?
> > 
> 
> This code is used by both system-wide suspend/resume and cpuidle paths.
> Daniel has moved this code to CPU PM notifier as a part of his Exynos
> cpuidle consolidation series to avoid code duplication, as this is the
> common point of both paths.
> 
> To clarify, on suspend/resume path, the notifier is being called from
> syscore_ops registered in kernel/cpu_pm.c, while on cpuidle path, this
> is invoked from exynos_enter_core0_aftr() in
> drivers/cpuidle/cpuidle-exynos.c, which calls cpu_pm_enter().

... which then goes on to call cpu_suspend().  So moving this stuff
into the CPU level makes total sense rather than having every platform
running in secure mode duplicating this functionality.  Thanks for
pointing that out and adding further justification to my assertion.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 3/3] mmc: dw_mmc: Support voltage changes

[Doug Anderson]

Yuvaraj,

On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D  wrote:
> From: Doug Anderson 
>
> For UHS cards we need the ability to switch voltages from 3.3V to
> 1.8V.  Add support to the dw_mmc driver to handle this.  Note that
> dw_mmc needs a little bit of extra code since the interface needs a
> special bit programmed to the CMD register while CMD11 is progressing.
> This means adding a few extra states to the state machine to track.
>
> Signed-off-by: Doug Anderson 
> Signed-off-by: Yuvaraj Kumar C D 
>
> ---
>  drivers/mmc/host/dw_mmc.c  |  145 
> +---
>  drivers/mmc/host/dw_mmc.h  |5 +-
>  include/linux/mmc/dw_mmc.h |2 +
>  3 files changed, 142 insertions(+), 10 deletions(-)

I will note to other interested parties that in the ChromeOS tree we
never actually cleaned up the MMC voltage change stuff enough to make
use of this functionality to actually get UHS cards working (though
the code is exercised as part of WiFi).


> @@ -254,6 +258,32 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
> struct mmc_command *cmd)
> else if (cmd->opcode != MMC_SEND_STATUS && cmd->data)
> cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
>
> +   if (cmd->opcode == SD_SWITCH_VOLTAGE) {
> +   u32 clk_en_a;
> +
> +   /* Special bit makes CMD11 not die */
> +   cmdr |= SDMMC_CMD_VOLT_SWITCH;
> +
> +   /* Change state to continue to handle CMD11 weirdness */
> +   WARN_ON(slot->host->state != STATE_SENDING_CMD);
> +   slot->host->state = STATE_SENDING_CMD11;
> +
> +   /*
> +* We need to disable clock stop while doing voltage switch
> +* according to 7.4.1.2 Voltage Switch Normal Scenario.

I think upstream hasn't tended to like the chapter number references,
though Grant really liked them locally.

> +static int dw_mci_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios)
> +{
> +   struct dw_mci_slot *slot = mmc_priv(mmc);
> +   struct dw_mci *host = slot->host;
> +   u32 uhs;
> +   u32 v18 = SDMMC_UHS_18V << slot->id;
> +   int min_uv, max_uv;
> +   int ret;
> +
> +   /*
> +* Program the voltage.  Note that some instances of dw_mmc may use
> +* the UHS_REG for this.  For other instances (like exynos) the 
> UHS_REG
> +* does no harm but you need to set the regulator directly.  Try both.

I've only worked with exynos which doesn't use UHS_REG for anything,
so the setting of this bit was a best-guess.  If anyone actually had a
chip that uses it then please comment / test.
--
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] devicetree: Add generic IOMMU device tree bindings

[Arnd Bergmann]

On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> > On 6/24/2014 2:18 AM, Will Deacon wrote:
> > > On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> > >> We have multiple-master SMMUs and each master emits a variable number of
> > >> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> > >> for this) to the StreamIDs due to limited number of StreamID 2 Context
> > >> Bank entries in the SMMU. If my understanding is correct we would
> > >> represent this in the DT like this:
> > >>
> > >>iommu {
> > >>#address-cells = <2>;
> > >>#size-cells = <0>;
> > >>};
> > >>
> > >>master@a {
> > >>...
> > >>iommus = <&iommu StreamID0 MASK0>,
> > >> <&iommu StreamID1 MASK1>,
> > >> <&iommu StreamID2 MASK2>;
> > >>};
> > > 
> > > Stupid question, but why not simply describe the masked IDs? What use does
> > > the `raw' ID have to Linux?
> > 
> > We do describe the masked StreamID (SID) but we need to specify the mask
> > that the SMMU should apply to the incoming SIDs, right?
> > 
> > We have a bus master that emits 43 unique SIDs. However, we have only 40
> > SMMU_SMRn registers in the SMMU. So we need to mask out some of the
> > incoming SID bits so that the 43 SIDs can match one of 40 entries in the
> > SMR.
> 
> Hmm, so you're talking about stream matching, right? That doesn't belong in
> the device-tree. I appreciate that the current driver does a terrible job at
> allocating the SMRs (it's bloody difficult!), but we should try to improve
> the dynamic behaviour instead of moving configuration of the SMMU out into
> device-tree, where it's inflexible at best.
> 
> There have been patches previously posted by Andreas Herrmann helping here.
> I'd be glad to see them revived.

Note that there are areas where we have in the past decided that dynamic
configuration is just too hard for the kernel to do and that we're better
off putting the configuration into DT. Pinctrl and clocks are at least
partially in that category.

It's always best if you can get the kernel to do things in the ideal
way where that is possible, but getting there may be just not worth it.

I have no idea where it should be for SMMU, but it's something to consider:
if you can take reasonable shortcuts by reading parts of the configuration
from DT, you may just as well do that.

Arnd
--
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] ARM: DTS: correct the capability string for mmc0

[Doug Anderson]

Hi,

On Mon, Jun 23, 2014 at 4:36 AM, Kukjin Kim  wrote:
> Naveen Krishna Chatradhi wrote:
>>
>> MMC capability for HS200 is parsed in mmc/core/host.c as
>> dts string "mmc-hs200-1_8v".
>>
>> This patch corrects the dts string for Exynos5420 based peach-pit
>> and Exynos5800 based peach-pi boards.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>> b/arch/arm/boot/dts/exynos5420-
>> peach-pit.dts
>> index 7649982..7dea480 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -173,7 +173,7 @@
>>   status = "okay";
>>   num-slots = <1>;
>>   broken-cd;
>> - caps2-mmc-hs200-1_8v;
>> + mmc-hs200-1_8v;
>>   supports-highspeed;
>>   non-removable;
>>   card-detect-delay = <200>;
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-
>> peach-pi.dts
>> index 2c2c137..bb3ee76 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -171,7 +171,7 @@
>>   status = "okay";
>>   num-slots = <1>;
>>   broken-cd;
>> - caps2-mmc-hs200-1_8v;
>> + mmc-hs200-1_8v;
>>   supports-highspeed;
>>   non-removable;
>>   card-detect-delay = <200>;
>> --
>> 1.7.9.5
>
> Applied, thanks.

As an FYI: this patch (while correct) will likely cause sporadic boot
failures until Sonny and my patches land:

* https://patchwork.kernel.org/patch/4323921/
  mmc: dw_mmc: Make sure we don't get stuck when we get an error

* https://patchwork.kernel.org/patch/4213211/
  mmc: dw_mmc: change to use recommended reset procedure

In the very least we got sporadic boot failures locally when we
enabled hs200 and didn't have the "don't get stuck" patch.  I will
also note that it would have been nice had this patch title included
the words exynos and/or pit/pi in it.

-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

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Olav Haugan]

On 6/24/2014 11:11 AM, Will Deacon wrote:
> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
>> On 6/24/2014 2:18 AM, Will Deacon wrote:
>>> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
 We have multiple-master SMMUs and each master emits a variable number of
 StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
 for this) to the StreamIDs due to limited number of StreamID 2 Context
 Bank entries in the SMMU. If my understanding is correct we would
 represent this in the DT like this:

iommu {
#address-cells = <2>;
#size-cells = <0>;
};

master@a {
...
iommus = <&iommu StreamID0 MASK0>,
 <&iommu StreamID1 MASK1>,
 <&iommu StreamID2 MASK2>;
};
>>>
>>> Stupid question, but why not simply describe the masked IDs? What use does
>>> the `raw' ID have to Linux?
>>
>> We do describe the masked StreamID (SID) but we need to specify the mask
>> that the SMMU should apply to the incoming SIDs, right?
>>
>> We have a bus master that emits 43 unique SIDs. However, we have only 40
>> SMMU_SMRn registers in the SMMU. So we need to mask out some of the
>> incoming SID bits so that the 43 SIDs can match one of 40 entries in the
>> SMR.
> 
> Hmm, so you're talking about stream matching, right? That doesn't belong in
> the device-tree. I appreciate that the current driver does a terrible job at
> allocating the SMRs (it's bloody difficult!), but we should try to improve
> the dynamic behaviour instead of moving configuration of the SMMU out into
> device-tree, where it's inflexible at best.

I am talking about SMMU_SMRn[MASK] register bits. This is not something
that can be dynamically detected at run-time. It is configuration at the
same level as the actual StreamIDs.

Thanks,


Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 4/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC

[Doug Anderson]

Naveen,

On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 based Peach PIT and Exynos5800 based PI boards have
> 4 NTC thermistors to measure temperatures at various points on the
> board.
>
> IIO based ADC becomes the parent and NTC thermistors are the childs,
> via the HWMON interface.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Doug Anderson 
> ---
> This patch needs
> 1. MAX77802 PMIC device tree nodes (for ldo9)
>https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
> 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
>
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |   32 
> 
>  1 file changed, 32 insertions(+)

* You forgot: status="okay" for the ADC.  One might question how this
patch was tested.

* Please also include this change for pi.

* We just got through the painful process of sorting this .dts file.
Please sort "&adc" alphabetically.  Kukjin: please confirm that you
will keep an eye on patches and make sure that they are sorted OK.


Other than those problems this seems to work fine to me.

-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

Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

[Laura Abbott]

On 6/24/2014 10:47 AM, Laura Abbott wrote:
> On 6/23/2014 11:32 AM, Kevin Hilman wrote:
>> On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera  wrote:
>>> Adding linux-samsung-soc and linux-arm-kernel ML for wider audience.
>>>
>>> On 06/19/2014 04:12 PM, Tushar Behera wrote:
 On 06/19/2014 03:02 PM, Tushar Behera wrote:
> On 06/18/2014 09:22 AM, Kevin Hilman wrote:
>> On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera  
>> wrote:
>>> On 06/17/2014 10:23 PM, Kevin Hilman wrote:
 Sachin,

 On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot 
  wrote:
>
> Tree/Branch: mainline
> Git describe: v3.16-rc1-2-gebe0618
> Failed boot tests (console logs at the end)
> ===
>  exynos5420-arndale-octa: FAIL:arm-exynos_defconfig
> ste-snowball: FAIL:arm-u8500_defconfig

 FYI... these failures are getting more consistent on my octa board,
 but still not failing every time.

 Kevin

>>>
>>> Hi Kevin,
>>>
>>> Same here.
>>>
>>> Observation: If you soft-reset the board (through the jumpers) after
>>> getting this problem, the problem keeps repeating. But if you hard-reset
>>> the board (by removing the power cord), the problem doesn't occur during
>>> next iteration.
>>
>> I don't ever use the soft-reset, I only toggle the wall power.  I
>> don't ever actually remove the power cord though, I'm using a
>> USB-controlled relay to toggle the wall power.
>>
>> Kevin
>>
>
> Laura,
>
> We are getting following kernel panic [1] (not always, but quite
> regularly) while booting Arndale-Octa (based on Samsung's Exynos5420)
> board with upstream kernel. I haven't observed this issue with other
> boards yet.
>
> This issue is observed when I am booting with uImage + dtb (within
> roughly ~10 iterations).
>

 Some more information:

 The boot logs are provided in pastebin, okay[2] and failed[3].

 In case of boot failures, I am getting a higher value for vm_total_pages
 (684424 in [3]). In case of successful boot on my board, it is always
 521232 [2] on my board.
>>
>> I can confirm that reverting the "Get rid of meminfo" patch gets the
>> Octa board booting reliably again for me also.
>>
>> In case it helps, some boot logs for failures from the last copule
>> linux-next build/boot cycles can be seen here:
>> http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
>> http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
>>
> 
> Sorry, I missed this yesterday. I'm going to take a look.
> 

Were all of 

http://pastebin.com/1iLaizuL
http://pastebin.com/5tdDt4GL
http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log

collected on the same type of board with the same amount of DRAM? I'm seeing a
different amount of total pages across all those logs. All the logs have the
same lowmem limit so it seems like the upper bound was being calculated
incorrectly for passing to free_area_init_node. Nothing is immediately jumping
out at me so can you boot up with a small debug patch?

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..88eac1f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -187,6 +187,8 @@ static void __init zone_sizes_init(unsigned long min, 
unsigned long max_low,
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
struct memblock_region *reg;
 
+   pr_err("XXX min %lx max_low %lx max_high %lx\n", min, max_low, 
max_high);
+   __memblock_dump_all();
/*
 * initialise the zones.
 */

It would be helpful to do this across a few bootups to see if the values are
actually consistent. I'll keep looking in the meantime.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/4] usb: host: xhci-plat: Add support to get PHYs

[Sergei Shtylyov]

Hello.

On 06/10/2014 12:22 AM, Julius Werner wrote:


diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
 u32 port_status_u0;
  /* Compliance Mode Timer Triggered every 2 seconds */
  #define COMP_MODE_RCVRY_MSECS 2000
+   /* phys for the controller */
+   struct phy  *phy2_gen;
+   struct phy  *phy3_gen;
  };



I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.


   Indeed.


There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.



There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that).


   That member has type 'struct usb_phy *' while here we have 'struct phy *' 
-- feel the difference.
   I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd', 
however Greg wasn't eager to pick that up so far. Here's the last posting of 
my patch:


http://marc.info/?l=linux-usb&m=140145917506582

WBR, Sergei

--
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 0/3] MCPM: clarify boot CPU situation wrt CCI

[Doug Anderson]

Kevin,

On Tue, Jun 24, 2014 at 8:35 AM, Kevin Hilman  wrote:
> - Leave mau_epll enabled
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html

Can you drop your mau_epll one and instead pick just
?

I noticed that Tushar has only been pushing for that patch to be
applied and I'm going to guess that the "leave mau_epll enabled" isn't
needed.  I just tested myself and confirmed that things are happy.
--
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] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
>> Tushar Behera  writes:
>>
>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>
>>> Though user manual doesn't specify this dependency, we came across
>>> this issue while disabling the parent of AUDSS mux clocks.
>>>
>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>
>> While this patch works (and fixes the boot problem for me), it seems
>> like it's papering over the real problem.
>>
>
> Thanks for testing.
>
>> Seems like the right fix is actually modelling the clocks properly so
>> that enabling a child clock ensures that the parent is also enabled.
>>
>
> Patch 2/3 was to ensure we have proper clock tree defined for
> Exynos5420. While testing with audio disabled, that patch alone fixed
> the issue. But when audio was enabled (and hence I2S0 was trying to
> access the clocks), we got some kernel oops during late booting, hence
> I came up this solution.
>
> The solution might be a little half-baked because of the urgency to
> push the fix, but will try to dig more into the issue on Monday when I
> resume office.

Which Monday were you referring to?  ;)

...but in all seriousness do you have an official status update on
this patch?  It seems as if it's not needed and all you need is
, but it would be nice to
get an official confirmation.

Thanks!

-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

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera 
> Signed-off-by: Shaik Ameer Basha 
> Reported-by: Kevin Hilman 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've tested this myself now as well.

Tested-by: Doug Anderson 
--
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: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Andreas Färber]

Am 23.06.2014 03:21, schrieb Andreas Färber:
> The display goes dark unfortunately (drm bridge series not yet tested),
> but I am able to log in via ssh over USB ethernet adapter okay.

Tracked this down to the dp-controller@145B node: The pinctrl seems
irrelevant, only commenting out the whole node helps keep the display.
That is, hdmi and fimd nodes don't interfere.

Adding a pwm backlight node like on snow did not help. If it's supposed
to work from GNOME's display brightness slider, it doesn't seem to work.
The 3.8 tree had no backlight node at all.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Doug Anderson]

Andreas,

On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber  wrote:
> Am 23.06.2014 03:21, schrieb Andreas Färber:
>> The display goes dark unfortunately (drm bridge series not yet tested),
>> but I am able to log in via ssh over USB ethernet adapter okay.
>
> Tracked this down to the dp-controller@145B node: The pinctrl seems
> irrelevant, only commenting out the whole node helps keep the display.
> That is, hdmi and fimd nodes don't interfere.

Adding Rahul from Samsung.  I don't know that he's ever tested things
on exynos5250-spring but he might be able to point you in the right
direction.


> Adding a pwm backlight node like on snow did not help. If it's supposed
> to work from GNOME's display brightness slider, it doesn't seem to work.
> The 3.8 tree had no backlight node at all.

I do know that we don't want the exynos pwm backlight for spring.  On
spring the backlight is controlled completely by the bridge chip which
has a PWM on it.

-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

Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Vincent Palatin]

On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber  wrote:
> Am 23.06.2014 03:21, schrieb Andreas Färber:
>> The display goes dark unfortunately (drm bridge series not yet tested),
>> but I am able to log in via ssh over USB ethernet adapter okay.
>
> Tracked this down to the dp-controller@145B node: The pinctrl seems
> irrelevant, only commenting out the whole node helps keep the display.
> That is, hdmi and fimd nodes don't interfere.
>
> Adding a pwm backlight node like on snow did not help.

On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS
bridge (rather than a SoC PWM as on Snow).
You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven
oh, it seems that the PS8622 DRM bridge driver is still in-flight :
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html

> If it's supposed
> to work from GNOME's display brightness slider, it doesn't seem to work.
> The 3.8 tree had no backlight node at all.
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 v2] i2c: exynos5: Properly use the "noirq" variants of suspend/resume

[Doug Anderson]

The original code for the exynos i2c controller registered for the
"noirq" variants.  However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually "noirq" (despite functions named
exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq).

i2c controllers that might have wakeup sources on them seem to need to
resume at noirq time so that the individual drivers can actually read
the i2c bus to handle their wakeup.

NOTE: I took the original review feedback from Wolfram and added
poweroff, thaw, freeze, restore.

This patch has only been compile-tested since I don't have all the
patches needed to make my machine using this i2c driver actually
suspend/resume.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- Added missing CONFIG_PM_SLEEP

 drivers/i2c/busses/i2c-exynos5.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..348b1cd 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -789,8 +789,16 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
 }
 #endif
 
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
-exynos5_i2c_resume_noirq);
+const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+   .suspend_noirq = exynos5_i2c_suspend_noirq,
+   .resume_noirq = exynos5_i2c_resume_noirq,
+   .freeze_noirq = exynos5_i2c_suspend_noirq,
+   .thaw_noirq = exynos5_i2c_resume_noirq,
+   .poweroff_noirq = exynos5_i2c_suspend_noirq,
+   .restore_noirq = exynos5_i2c_resume_noirq,
+#endif
+};
 
 static struct platform_driver exynos5_i2c_driver = {
.probe  = exynos5_i2c_probe,
-- 
2.0.0.526.g5318336

--
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: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Andreas Färber]

Vincent and Doug,

Am 25.06.2014 01:44, schrieb Vincent Palatin:
> On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber  wrote:
>> Am 23.06.2014 03:21, schrieb Andreas Färber:
>>> The display goes dark unfortunately (drm bridge series not yet tested),
>>> but I am able to log in via ssh over USB ethernet adapter okay.
>>
>> Tracked this down to the dp-controller@145B node: The pinctrl seems
>> irrelevant, only commenting out the whole node helps keep the display.
>> That is, hdmi and fimd nodes don't interfere.
>>
>> Adding a pwm backlight node like on snow did not help.
> 
> On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS
> bridge (rather than a SoC PWM as on Snow).
> You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven
> oh, it seems that the PS8622 DRM bridge driver is still in-flight :
> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html

Yeah, that's the one I meant with "drm bridge series" above. :)

Thanks for confirming.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 v2] i2c: s3c2410: resume the I2C controller earlier

[Doug Anderson]

From: Vincent Palatin 

When the wake-up is triggered by the PMIC RTC, the RTC driver is trying
to read the PMIC interrupt status over I2C and fails because the I2C
controller is not resumed yet.
Let's resume the I2C controller earlier in the _noirq phase
(as other hardwares are doing), so we can properly get the wake-up
condition.

Signed-off-by: Vincent Palatin 
Signed-off-by: Doug Anderson 
---
Changes in v2:
- Added missing freeze/thaw/poweroff/restore

 drivers/i2c/busses/i2c-s3c2410.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index e828a1d..ecb389c 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1267,7 +1267,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
return 0;
 }
 
-static int s3c24xx_i2c_resume(struct device *dev)
+static int s3c24xx_i2c_resume_noirq(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
@@ -1285,7 +1285,11 @@ static int s3c24xx_i2c_resume(struct device *dev)
 static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
 #ifdef CONFIG_PM_SLEEP
.suspend_noirq = s3c24xx_i2c_suspend_noirq,
-   .resume = s3c24xx_i2c_resume,
+   .resume_noirq = s3c24xx_i2c_resume_noirq,
+   .freeze_noirq = s3c24xx_i2c_suspend_noirq,
+   .thaw_noirq = s3c24xx_i2c_resume_noirq,
+   .poweroff_noirq = s3c24xx_i2c_suspend_noirq,
+   .restore_noirq = s3c24xx_i2c_resume_noirq,
 #endif
 };
 
-- 
2.0.0.526.g5318336

--
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 v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU.

[Tomasz Figa]

On 24.06.2014 13:28, Pankaj Dubey wrote:
> On Tuesday, June 17 2014, Tomasz Figa wrote:
>> On 10.05.2014 08:56, Pankaj Dubey wrote:

[snip]

>>> +
>>> +   ret = platform_driver_register(&exynos_pmu_driver);
>>> +   if (ret < 0)
>>> +   goto out;
>>> +
>>> +   exynos_pmu_pdev = platform_device_register_simple("exynos-pmu", -1,
>>> +   NULL, 0);
>>
>> Hmm, I don't see the point of making this a platform driver only to
> register respective
>> platform device few lines below. If you take into account the patch for
> syscon I
>> posted as a reply to patch 06/11, you will be able to make this a normal
> platform
>> driver that binds to DT node directly and then register a syscon in probe
> function
>> above.
>>
> 
> Well I updated PMU to be a syscon provider using your patch. It worked well.
> I have following two points to mention here:
> 
> 1: For making PMU a normal platform driver, other than making PMU a syscon
> provider we need to change PMU's DT binding. Basically we need to remove
> "syscon"
> as second compatibility string. I hope this should not be an issue.

I don't see the reason for this. Could you elaborate on this?

I know that the way Linux currently handles multiple compatible strings
is broken, but despite this, if you just make sure your platform driver
registers before syscon platform driver, it should be fine.

> 
> 2: I can see for your syscon patch Arnd has some comments, hopefully we can
> address
> his concern.
> 

Yes. I will get to it after sorting out few other things from my queue.
Or you can do it if you want - the purpose of that RFC patch was just to
show the idea I had in my mind.

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] drm/exynos: Support DP CLKCON register in FIMD driver

[Jingoo Han]

On Tuesday, June 24, 2014 11:15 PM, Andrzej Hajda wrote:
> On 06/24/2014 03:14 PM, Ajay kumar wrote:
> > On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  wrote:
> >> Hi Ajay,
> >>
> >> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
> >>> Add the missing setting for DP CLKCON register.
> >>>
> >>> This register is present on Exynos5 based FIMD controllers,
> >>> and needs to be used if we are using DP.
> >>>
> >>> Signed-off-by: Ajay Kumar 
> >>> ---
> >>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
> >>>  include/video/samsung_fimd.h |4 
> >>>  2 files changed, 9 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> >>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> index 33161ad..5d3045d 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
> >>>   unsigned int has_shadowcon:1;
> >>>   unsigned int has_clksel:1;
> >>>   unsigned int has_limited_fmt:1;
> >>> + unsigned int has_dp_clkcon:1;
> >>>  };
> >>>
> >>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> >>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
> >>> = {
> >>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
> >>>   .timing_base = 0x2,
> >>>   .has_shadowcon = 1,
> >>> + .has_dp_clkcon = 1,
> >>>  };
> >>>
> >>>  struct fimd_win_data {
> >>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager 
> >>> *mgr)
> >>>   if (clkdiv > 1)
> >>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
> >>>
> >>> + if (ctx->driver_data->has_dp_clkcon)
> >>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> >>> +
> >> This code always enables the clock on exynos5. As I understand it should
> >> be enabled only if DP is used.
> > Right!
> > But, when I searched for the display interface,
> > only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
> > So, I thought adding this in driver_data for exynos5 should be fine.

No, it should be selectable. Even some exynos5 based boards use MIPI LCD.

> 
> Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.
> 
> >
> > Inki/Andrej - Shall I add it as an optional DT property?
> 
> No, property is redundant. The simplest solution could be to use
> CONFIG_DRM_EXYNOS_DP
> macro but it is quite ugly.

Right, CONFIG_DRM_EXYNOS_DP is the simplest. But, the macro doesn't
look good.

> I guess extending little bit exynos_drm framework to allow detection of
> DP in fimd would be better.

I agree on Andrzej's opinion.

Best regards,
Jingoo Han

> 
> Regards
> Andrzej
> 
> >
> > Ajay
> >>
> >>>   writel(val, ctx->regs + VIDCON0);
> >>>  }
> >>>
> >>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> >>> index b039320..d8f4b0b 100644
> >>> --- a/include/video/samsung_fimd.h
> >>> +++ b/include/video/samsung_fimd.h
> >>> @@ -435,6 +435,10 @@
> >>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> >>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
> >>>
> >>> +/* Video clock enable for DP */
> >>> +#define DP_CLKCON0x27C
> >>> +#define DP_CLK_ENABLE0x2
> >>> +
> >>>  /* Notes on per-window bpp settings
> >>>   *
> >>>   * Value Win0 Win1 Win2 Win3 Win 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: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

[Andreas Färber]

Am 23.06.2014 20:32, schrieb Kevin Hilman:
> On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera  wrote:
>> Adding linux-samsung-soc and linux-arm-kernel ML for wider audience.
>>
>> On 06/19/2014 04:12 PM, Tushar Behera wrote:
>>> On 06/19/2014 03:02 PM, Tushar Behera wrote:
 On 06/18/2014 09:22 AM, Kevin Hilman wrote:
> On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera  wrote:
>> On 06/17/2014 10:23 PM, Kevin Hilman wrote:
>>> Sachin,
>>>
>>> On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot  
>>> wrote:

 Tree/Branch: mainline
 Git describe: v3.16-rc1-2-gebe0618
 Failed boot tests (console logs at the end)
 ===
  exynos5420-arndale-octa: FAIL:arm-exynos_defconfig
 ste-snowball: FAIL:arm-u8500_defconfig
>>>
>>> FYI... these failures are getting more consistent on my octa board,
>>> but still not failing every time.
>>>
>>> Kevin
>>>
>>
>> Hi Kevin,
>>
>> Same here.
>>
>> Observation: If you soft-reset the board (through the jumpers) after
>> getting this problem, the problem keeps repeating. But if you hard-reset
>> the board (by removing the power cord), the problem doesn't occur during
>> next iteration.
>
> I don't ever use the soft-reset, I only toggle the wall power.  I
> don't ever actually remove the power cord though, I'm using a
> USB-controlled relay to toggle the wall power.
>
> Kevin
>

 Laura,

 We are getting following kernel panic [1] (not always, but quite
 regularly) while booting Arndale-Octa (based on Samsung's Exynos5420)
 board with upstream kernel. I haven't observed this issue with other
 boards yet.

 This issue is observed when I am booting with uImage + dtb (within
 roughly ~10 iterations).

>>>
>>> Some more information:
>>>
>>> The boot logs are provided in pastebin, okay[2] and failed[3].
>>>
>>> In case of boot failures, I am getting a higher value for vm_total_pages
>>> (684424 in [3]). In case of successful boot on my board, it is always
>>> 521232 [2] on my board.
> 
> I can confirm that reverting the "Get rid of meminfo" patch gets the
> Octa board booting reliably again for me also.

Confirming that the revert [1] fixes also the issue I was reporting for
my Arndale Octa. I'm using zImage + dtb and had been resetting via J10.

Regards,
Andreas

[1] https://github.com/afaerber/linux/commits/arndale-octa-next

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/25/2014 04:29 AM, Doug Anderson wrote:
> Tushar,
> 
> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
>>> Tushar Behera  writes:
>>>
 When the output clock of AUDSS mux is disabled, we are getting kernel
 oops while doing a clk_get() on other clocks provided by AUDSS.

 Though user manual doesn't specify this dependency, we came across
 this issue while disabling the parent of AUDSS mux clocks.

 Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>
>>> While this patch works (and fixes the boot problem for me), it seems
>>> like it's papering over the real problem.
>>>
>>
>> Thanks for testing.
>>
>>> Seems like the right fix is actually modelling the clocks properly so
>>> that enabling a child clock ensures that the parent is also enabled.
>>>
>>
>> Patch 2/3 was to ensure we have proper clock tree defined for
>> Exynos5420. While testing with audio disabled, that patch alone fixed
>> the issue. But when audio was enabled (and hence I2S0 was trying to
>> access the clocks), we got some kernel oops during late booting, hence
>> I came up this solution.
>>
>> The solution might be a little half-baked because of the urgency to
>> push the fix, but will try to dig more into the issue on Monday when I
>> resume office.
> 
> Which Monday were you referring to?  ;)
> 

Sorry that I couldn't get deeper into this issue. Thanks for reminding
though.

> ...but in all seriousness do you have an official status update on
> this patch?  It seems as if it's not needed and all you need is
> , but it would be nice to
> get an official confirmation.

I have tested various scenarios with only patch 2/3, which seems to be
sufficient for the time being. I have not encountered the older issue
till now. I was thinking of testing a bit further, but given that you
have already asked for, we can go ahead with only patch 2/3 right now.

In case any further issue comes up, I will post patch 1/3 as per the
review comments that I have got.

> 
> Thanks!
> 
> -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
> 


-- 
Tushar Behera
--
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] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Jaehoon Chung]

On 06/25/2014 03:00 AM, Doug Anderson wrote:
> Yuvaraj,
> 
> On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D  
> wrote:
>> This patch makes use of mmc_regulator_get_supply() to handle
>> the vmmc and vqmmc regulators.Also it moves the code handling
>> the these regulators to dw_mci_set_ios().It turned on the vmmc
>> and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
>> during MMC_POWER_OFF.
>>
>> Signed-off-by: Yuvaraj Kumar C D 
>> ---
>>  drivers/mmc/host/dw_mmc.c |   71 
>> ++---
>>  drivers/mmc/host/dw_mmc.h |2 ++
>>  2 files changed, 36 insertions(+), 37 deletions(-)
> 
> Perhaps you could CC me on the whole series for the next version since
> I was involved in privately reviewing previous versions?
> 
> Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
> 
> 
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 1ac227c..f5cabce 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
>> mmc_ios *ios)
>> struct dw_mci_slot *slot = mmc_priv(mmc);
>> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>> u32 regs;
>> +   int ret;
>>
>> switch (ios->bus_width) {
>> case MMC_BUS_WIDTH_4:
>> @@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
>> struct mmc_ios *ios)
>>
>> switch (ios->power_mode) {
>> case MMC_POWER_UP:
>> +   if ((!IS_ERR(mmc->supply.vmmc)) &&
>> +   !test_bit(DW_MMC_CARD_POWERED, 
>> &slot->flags)) {
>> +   ret = regulator_enable(mmc->supply.vmmc);
>> +   if (!ret)
>> +   set_bit(DW_MMC_CARD_POWERED, &slot->flags);

MMC_CARD_POWERED? I didn't know why it needs.

>> +   }
> 
> As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
> different times.
In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and 
vmmc at different times.

> 
> Also: if you fail to turn on either of the regulators it feels like
> you should print a pretty nasty error message since your device will
> almost certainly not work.
> 
> 
>> set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
>> regs = mci_readl(slot->host, PWREN);
>> regs |= (1 << slot->id);
>> mci_writel(slot->host, PWREN, regs);
>> break;
>> case MMC_POWER_OFF:
>> +   if (!IS_ERR(mmc->supply.vqmmc) &&
>> +   test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
>> +   ret = regulator_disable(mmc->supply.vqmmc);
>> +   if (!ret)
>> +   clear_bit(DW_MMC_IO_POWERED, &slot->flags);
>> +   }
>> +   if (!IS_ERR(mmc->supply.vmmc) &&
>> +   test_bit(DW_MMC_CARD_POWERED, &slot->flags)) 
>> {
>> +   ret = regulator_disable(mmc->supply.vmmc);
>> +   if (!ret)
>> +   clear_bit(DW_MMC_CARD_POWERED, &slot->flags);
>> +   }
>> regs = mci_readl(slot->host, PWREN);
>> regs &= ~(1 << slot->id);
>> mci_writel(slot->host, PWREN, regs);
>> break;
>> +   case MMC_POWER_ON:
>> +   if (!IS_ERR(mmc->supply.vqmmc) &&
>> +   !test_bit(DW_MMC_IO_POWERED, &slot->flags)) {
>> +   ret = regulator_enable(mmc->supply.vqmmc);
>> +   if (!ret)
>> +   set_bit(DW_MMC_IO_POWERED, &slot->flags);
>> +   }
>> default:
>> break;
>> }
>> @@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>> unsigned int id)
>> mmc->f_max = freq[1];
>> }
>>
>> -   mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>> +   /*if there are external regulators, get them*/
>> +   ret = mmc_regulator_get_supply(mmc);
>> +   if (ret == -EPROBE_DEFER)
>> +   goto err_setup_bus;
>> +
>> +   if (!mmc->ocr_avail)
>> +   mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>>
>> if (host->pdata->caps)
>> mmc->caps = host->pdata->caps;
>> @@ -2133,7 +2165,7 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>> unsigned int id)
>>
>>  err_setup_bus:
>> mmc_free_host(mmc);
>> -   return -EINVAL;
>> +   return ret;
>>  }
>>
>>  static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
>> @@ -2375,24 +2407,6 @@ int dw_mci_probe(struct dw_mci *host)
>> }
>> }
>>
>> -   host->vmmc = devm_regulator_get_optional(host->dev, "vmmc");
>> -   if (IS_ERR(host->vmmc)) {
>> -   ret = PTR_ERR

Re: [alsa-devel] [PATCH V2 1/2] ASoC: samsung: Add machine driver for Odroid X2/U3

[Tushar Behera]

On 06/18/2014 09:52 PM, Sylwester Nawrocki wrote:
> This patch adds the sound subsystem driver for Odroid-X2 and
> Odroid-U3 boards. The codec works in I2S master mode; there are
> 2 separate audio routing paths defined as there are differences
> in the signal routing between the X2 and U3 boards, i.e. U3 uses
> single jack for headphones and microphone.
> 
> Signed-off-by: Chen Zhen 
> Signed-off-by: Sylwester Nawrocki 
> ---
>  sound/soc/samsung/Kconfig |8 ++
>  sound/soc/samsung/Makefile|2 +
>  sound/soc/samsung/odroidx2_max98090.c |  191 
> +
>  3 files changed, 201 insertions(+)
>  create mode 100644 sound/soc/samsung/odroidx2_max98090.c
> 

[ ... ]

> +static int odroidx2_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> + struct snd_soc_dai *codec_dai = rtd->codec_dai;
> + int ret;
> +
> + ret = snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
> + SND_SOC_CLOCK_IN);
> + if (ret < 0) {
> + dev_err(codec_dai->dev,
> + "Unable to switch to FLL1: %d\n", ret);
> + return ret;
> + }
> +
> + /* Set the cpu DAI configuration in order to use CDCLK */
> + ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
> + 0, SND_SOC_CLOCK_OUT);
> + if (ret < 0)
> + return ret;
> +

While upstreaming sound-card driver for Snow board, I had a comment from
Mark to move this to probe, if possible. That way, the clock operations
would be done only once and this function and odroidx2_ops can be
removed altogether.

> + dev_dbg(codec_dai->dev, "HiFi DAI %s params: channels: %d, rate: %d\n",
> + snd_pcm_stream_str(substream), params_channels(params),
> + params_rate(params));
> +
> + return 0;
> +}
> +
> +static struct snd_soc_ops odroidx2_ops = {
> + .hw_params  = odroidx2_hw_params,
> +};
> +

[ ... ]

> +
> + ret = snd_soc_register_card(card);

devm_snd_soc_register_card ?

> + if (ret) {
> + dev_err(&pdev->dev, "snd_soc_register_card failed: %d\n", ret);
> + goto err_put_cpu_n;
> + }
> +
> + return 0;
> +
> +err_put_cpu_n:
> + of_node_put(odroidx2_dai[0].cpu_of_node);
> +err_put_cod_n:
> + of_node_put(odroidx2_dai[0].codec_of_node);
> + return ret;
> +}
> +
> +static int odroidx2_audio_remove(struct platform_device *pdev)
> +{
> + struct snd_soc_card *card = platform_get_drvdata(pdev);
> +
> + snd_soc_unregister_card(card);

This can be removed when devm_snd_soc_register_card is used.

-- 
Tushar Behera
--
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] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

[Doug Anderson]

Jaehoon,

On Tue, Jun 24, 2014 at 8:18 PM, Jaehoon Chung  wrote:
> On 06/25/2014 03:00 AM, Doug Anderson wrote:
>> Yuvaraj,
>>
>> On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D  
>> wrote:
>>> This patch makes use of mmc_regulator_get_supply() to handle
>>> the vmmc and vqmmc regulators.Also it moves the code handling
>>> the these regulators to dw_mci_set_ios().It turned on the vmmc
>>> and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
>>> during MMC_POWER_OFF.
>>>
>>> Signed-off-by: Yuvaraj Kumar C D 
>>> ---
>>>  drivers/mmc/host/dw_mmc.c |   71 
>>> ++---
>>>  drivers/mmc/host/dw_mmc.h |2 ++
>>>  2 files changed, 36 insertions(+), 37 deletions(-)
>>
>> Perhaps you could CC me on the whole series for the next version since
>> I was involved in privately reviewing previous versions?
>>
>> Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
>>
>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 1ac227c..f5cabce 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
>>> mmc_ios *ios)
>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>> u32 regs;
>>> +   int ret;
>>>
>>> switch (ios->bus_width) {
>>> case MMC_BUS_WIDTH_4:
>>> @@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
>>> struct mmc_ios *ios)
>>>
>>> switch (ios->power_mode) {
>>> case MMC_POWER_UP:
>>> +   if ((!IS_ERR(mmc->supply.vmmc)) &&
>>> +   !test_bit(DW_MMC_CARD_POWERED, 
>>> &slot->flags)) {
>>> +   ret = regulator_enable(mmc->supply.vmmc);
>>> +   if (!ret)
>>> +   set_bit(DW_MMC_CARD_POWERED, &slot->flags);
>
> MMC_CARD_POWERED? I didn't know why it needs.

I think the idea was to make sure that regulator enables/disables were
balanced.  ...but if the mmc core does this for us then we probably
don't need to worry.


>>> +   }
>>
>> As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
>> different times.
> In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and 
> vmmc at different times.

OK!  Can you explain more?  What instance is one powered but not the other?

I know that we talked to an SD Card manufacturer who told us that
powering their IO lines without their main power rail was a bad thing
(and we in fact saw this causing problems on SD cards).  I would guess
that means that you're either powering vmmc before vqmmc or that vqmmc
somehow doesn't directly enable pullups for IO lines.

If you need vmmc before vqmmc then I'm curious about why...

-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

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Tue, Jun 24, 2014 at 8:09 PM, Tushar Behera  wrote:
> On 06/25/2014 04:29 AM, Doug Anderson wrote:
>> Tushar,
>>
>> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
>>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
 Tushar Behera  writes:

> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS.
>
> Though user manual doesn't specify this dependency, we came across
> this issue while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.

 While this patch works (and fixes the boot problem for me), it seems
 like it's papering over the real problem.

>>>
>>> Thanks for testing.
>>>
 Seems like the right fix is actually modelling the clocks properly so
 that enabling a child clock ensures that the parent is also enabled.

>>>
>>> Patch 2/3 was to ensure we have proper clock tree defined for
>>> Exynos5420. While testing with audio disabled, that patch alone fixed
>>> the issue. But when audio was enabled (and hence I2S0 was trying to
>>> access the clocks), we got some kernel oops during late booting, hence
>>> I came up this solution.
>>>
>>> The solution might be a little half-baked because of the urgency to
>>> push the fix, but will try to dig more into the issue on Monday when I
>>> resume office.
>>
>> Which Monday were you referring to?  ;)
>>
>
> Sorry that I couldn't get deeper into this issue. Thanks for reminding
> though.

No problem.  I know how it is.  I was trying to be funny though
sometimes that doesn't come through very well over email.


>> ...but in all seriousness do you have an official status update on
>> this patch?  It seems as if it's not needed and all you need is
>> , but it would be nice to
>> get an official confirmation.
>
> I have tested various scenarios with only patch 2/3, which seems to be
> sufficient for the time being. I have not encountered the older issue
> till now. I was thinking of testing a bit further, but given that you
> have already asked for, we can go ahead with only patch 2/3 right now.
>
> In case any further issue comes up, I will post patch 1/3 as per the
> review comments that I have got.

Sounds like a plan.  Thanks for getting the original patch sent out so
quickly after I reported it.

Hopefully Kukjin will apply pack 2/3 soon (today?)
--
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 v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU.

[Pankaj Dubey]

Hi,

On Wednesday, June 25 2014 Tomasz Figa write:
> On 24.06.2014 13:28, Pankaj Dubey wrote:
> > On Tuesday, June 17 2014, Tomasz Figa wrote:
> >> On 10.05.2014 08:56, Pankaj Dubey wrote:
> 
> [snip]
> 
> >>> +
> >>> + ret = platform_driver_register(&exynos_pmu_driver);
> >>> + if (ret < 0)
> >>> + goto out;
> >>> +
> >>> + exynos_pmu_pdev = platform_device_register_simple("exynos-pmu",
> -1,
> >>> + NULL, 0);
> >>
> >> Hmm, I don't see the point of making this a platform driver only to
> > register respective
> >> platform device few lines below. If you take into account the patch
> >> for
> > syscon I
> >> posted as a reply to patch 06/11, you will be able to make this a
> >> normal
> > platform
> >> driver that binds to DT node directly and then register a syscon in
> >> probe
> > function
> >> above.
> >>
> >
> > Well I updated PMU to be a syscon provider using your patch. It worked
well.
> > I have following two points to mention here:
> >
> > 1: For making PMU a normal platform driver, other than making PMU a
> > syscon provider we need to change PMU's DT binding. Basically we need
> > to remove "syscon"
> > as second compatibility string. I hope this should not be an issue.
> 
> I don't see the reason for this. Could you elaborate on this?
> 

Currently syscon driver is registered via postcore_initcall whereas exynos
pmu has
arch_initcall. So if we keep syscon as second compatibility in exynos pmu
node,
syscon will be registered first and hence only syscon will be probed.

> I know that the way Linux currently handles multiple compatible strings is
broken,
> but despite this, if you just make sure your platform driver registers
before syscon
> platform driver, it should be fine.
>

Yes, this could be possible if I convert arch_initcall of exynos pmu to
postcore_initcall.

As after converting arch_initcall to postcore_initcall, syscon driver will
not be probed
for exynos pmu node. Also as exynos pmu driver will now register itself as
syscon provider,
I could not see any use of keeping second compatibility as "syscon" in
exynos pmu
node.  Do you think it is still required?

After removing "syscon" compatibility string from exynos pmu node, I have
tested
S2R as well as watchdog driver functionality, which is user of regmap handle
of exynos pmu
and both are working fine on exynos5250.
 
> >
> > 2: I can see for your syscon patch Arnd has some comments, hopefully
> > we can address his concern.
> >
> 
> Yes. I will get to it after sorting out few other things from my queue.
> Or you can do it if you want - the purpose of that RFC patch was just to
> show the idea I had in my mind.
> 

OK, let me post exynos pmu v5, based on your patch, and then if time permits
I will have a look in it.

> Best regards,
> Tomasz

Thanks,
Pankaj Dubey

--
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] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

[Abhilash Kesavan]

Hi Russell and Tomasz,

+Arnd
On Tue, Jun 24, 2014 at 9:41 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
>> Hi Kukjin,
>>
>> On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan  
>> wrote:
>> > Signed-off-by: Abhilash Kesavan 
>>
>> Do you have any comments on this patch ?
>
> I do.
>
>> > diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> > index d10c351..6dd4a11 100644
>> > --- a/arch/arm/mach-exynos/pm.c
>> > +++ b/arch/arm/mach-exynos/pm.c
>> > @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
>> > tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
>> > __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
>> >
>> > -   if (!soc_is_exynos5250())
>> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>> > exynos_cpu_save_register();
> ...
>> > @@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
>> > if (exynos_pm_central_resume())
>> > goto early_wakeup;
>> >
>> > -   if (!soc_is_exynos5250())
>> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>> > exynos_cpu_restore_register();
>
> It is invalid to check just the part number.  The part number on its
> own is meaningless without taking account of the implementor.  Both
> the implementor and the part number should be checked at each of these
> sites.
Thanks for pointing this out. I was not aware of  the implementor id
check requirement.
>
> Another point: exynos have taken it upon themselves to add code which
> saves various ARM core registers.  This is a bad idea, it brings us
> back to the days where every platform did their own suspend implementations.
>
> CPU level registers should be handled by CPU level code, not by platform
> code.  Is there a reason why this can't be added to the Cortex-A9
> support code in proc-v7.S ?
>
>> > @@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
>> >
>> > s3c_pm_do_restore_core(exynos_core_save, 
>> > ARRAY_SIZE(exynos_core_save));
>> >
>> > -   if (!soc_is_exynos5250())
>> > +   if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
>> > scu_enable(S5P_VA_SCU);
>> >
>> >  early_wakeup:
>> > @@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct 
>> > notifier_block *self,
>> > case CPU_PM_ENTER:
>> > if (cpu == 0) {
>> > exynos_pm_central_suspend();
>> > -   exynos_cpu_save_register();
>> > +   if (read_cpuid_part_number() == 
>> > ARM_CPU_PART_CORTEX_A9)
>> > +   exynos_cpu_save_register();
>> > }
>> > break;
>> >
>> > case CPU_PM_EXIT:
>> > if (cpu == 0) {
>> > -   if (!soc_is_exynos5250())
>> > +   if (read_cpuid_part_number() ==
>> > +   ARM_CPU_PART_CORTEX_A9) {
>> > scu_enable(S5P_VA_SCU);
>> > -   exynos_cpu_restore_register();
>> > +   exynos_cpu_restore_register();
>> > +   }
>> > exynos_pm_central_resume();
>> > }
>> > break;
>
> And presumably with the CPU level code dealing with those registers,
> you don't need the calls to save and restore these registers in this
> notifier.
Regarding save/restore of these registers, I could send out a patch
cleaning these out once Shawn's patch gets merged. I'd need some help
testing it out on Exynos4 boards though. For now, is it OK if I just
update to the new function ?
>
> Which, by the way, is probably illegal to run as it runs in a read-
> lock code path and with the SCU disabled.  As you're calling
> scu_enable() that means you're non-coherent with the other CPUs,
> and therefore locks don't work.
>
> I think this code is very broken and wrongly architected, and shows
> that we're continuing to make the same mistakes that we made all
> through the 2000s with platforms doing their own crap rather than
> properly thinking about this stuff.
I see that you have sent a patch out that ensures both part and
implementor number are checked. Currently, my patch has been applied
to the fixes branch of the arm-soc tree and I wanted to know how to
proceed (without it there is a crash on the 5420):
Should I request Arnd to drop it (if possible) and send out a new
patch using your updated function ?

Regards,
Abhilash
--
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