Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 3:04 PM, Mark Brown  wrote:
> On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:
>
>> Anyway, suffice to say that the i2c core needs to be extended to
>> handle the idea that a single device has more than one "compatible"
>> string.  I'll leave it to an eager reader of this thread to implement
>> this since we can also fix our own problem by just listing "max98091"
>> in "sound/soc/codecs/max98090.c" like has always been done in the
>> past.
>
> Why do you need to register multiple compatible strings (I guess for
> fallback purposes?).

I'm no expert, but I think that's part of device tree isn't it?

In the case of max98090 and max98091, they are incredibly similar
pieces of hardware (I think the max98091 simply has more microphones).
If you've got a driver for a max98090 it will work just fine for a
max98091 but you just won't get the extra microphones.

In cases like this then device tree theory says that you should list
both compatible strings: max98091 and max98090, right?  If your OS has
a driver for max98091 it will use it.  ...if it doesn't but it has a
max98090 driver it will try that one.

As far as I understand we _shouldn't_ lie and just say that we have a
max98090 when we really have a max98091.  The device tree is supposed
to describe the hardware and isn't support to care that the OS has a
driver for max98090 but not max98091.

Ironically in our case we have a driver that supports both the 98090
and the 98091 via autodetect.  However, it doesn't know about the
98091 compatible string so if you list yourself as compatible with
98091 then it won't find the driver.

> A quick fix that is about as good is to take the
> first compatible only.

That's how the code works today, actually.  ...but as per above the
current 98090 driver doesn't know about the 98091 compatible string,
so:

compatible = "maxim,max98091", "maxim,max98090";

...won't find the right driver.

--

The quick fix is to add max98091 to the max98090 driver and is what
I'd suggest in this case.  ...but I still think that the above logic
is valid and eventually the i2c core should be fixed.  Please correct
me if I'm wrong.

-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] Exynos4: cpuidle: support dual CPUs with AFTR state

[Daniel Lezcano]

On 06/11/2014 10:50 AM, Krzysztof Kozlowski wrote:

On pią, 2014-04-04 at 11:48 +0200, Daniel Lezcano wrote:

The following driver is for exynos4210. I did not yet finished the other 
boards, so
I created a specific driver for 4210 which could be merged later.

The driver is based on Colin Cross's driver found at:

https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/

This one was based on a 3.4 kernel and an old API.

It has been refreshed, simplified and based on the recent code cleanup I sent
today.

The AFTR could be entered when all the cpus (except cpu0) are down. In order to
reach this situation, the couple idle states are used.

There is a sync barrier at the entry and the exit of the low power function. So
all cpus will enter and exit the function at the same time.

At this point, CPU0 knows the other cpu will power down itself. CPU0 waits for
the CPU1 to be powered down and then initiate the AFTR power down sequence.

No interrupts are handled by CPU1, this is why we switch to the timer broadcast
even if the local timer is not impacted by the idle state.

When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then they both
exit the idle function.

This driver allows the exynos4210 to have the same power consumption at idle
time than the one when we have to unplug CPU1 in order to let CPU0 to reach
the AFTR state.

This patch is a RFC because, we have to find a way to remove the macros
definitions and cpu powerdown function without pulling the arch dependent
headers.

Signed-off-by: Daniel Lezcano 
---
  arch/arm/mach-exynos/common.c|   11 +-
  drivers/cpuidle/Kconfig.arm  |8 ++
  drivers/cpuidle/Makefile |1 +
  drivers/cpuidle/cpuidle-exynos4210.c |  226 ++
  4 files changed, 245 insertions(+), 1 deletion(-)
  create mode 100644 drivers/cpuidle/cpuidle-exynos4210.c


(...)


diff --git a/drivers/cpuidle/cpuidle-exynos4210.c 
b/drivers/cpuidle/cpuidle-exynos4210.c
new file mode 100644
index 000..56f6d51
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-exynos4210.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Copyright (c) 2014 Linaro : Daniel Lezcano 
+ * http://www.linaro.org
+ *
+ * Based on the work of Colin Cross 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+static atomic_t exynos_idle_barrier;


Hi,

Shouldn't the exynos_idle_barrier be initialized here?


As it is a static data it will be initialized to zero.


I know you sent the patch almost 2 months ago but I stomped on this
while testing it on Exynos3250.


No problem. And what results on exynos3250 ?

Thanks !

  -- Daniel


--
  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 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:

> Anyway, suffice to say that the i2c core needs to be extended to
> handle the idea that a single device has more than one "compatible"
> string.  I'll leave it to an eager reader of this thread to implement
> this since we can also fix our own problem by just listing "max98091"
> in "sound/soc/codecs/max98090.c" like has always been done in the
> past.

Why do you need to register multiple compatible strings (I guess for
fallback purposes?).  A quick fix that is about as good is to take the
first compatible only.


signature.asc
Description: Digital signature

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:13 AM, Doug Anderson  wrote:
> Mark,
>
> On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown  wrote:
>> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  
>>> wrote:
>>
>>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>
>> It is?  We should fix that if it's the case...
>
> Yah, I mentioned it to Mark Rutland at the last ELC and he said he
> might take a look at it, but I probably should have posted something
> up to the i2c list.
>
> I made a half-assed attempt to fix it locally in the ChromeOS but
> quickly found that it was going to be a much bigger job than I had
> time for...
>
> https://chromium-review.googlesource.com/#/c/184406/
>
> IIRC i2c_new_device didn't return an error like I thought it would,
> probably trying to deal with the fact that devices might show up at a
> later point in time.
>
>
> Hrm, now that I think about it I wonder if the right answer is just to
> call i2c_new_device for all the compatible strings even if it doesn't
> return an error.  I'd have to go back and try that and re-explore this
> code...

Nope, that didn't work either.  Now I remember trying that before,
too.  It doesn't like you registering two different devices with the
same address:

[2.582539] DOUG: /i2c@12CD/codec@10 (0) max98091
[2.587360] DOUG: /i2c@12CD/codec@10 (0) max98091
[2.591160] DOUG: /i2c@12CD/codec@10 (1) max98090
[2.596686] i2c i2c-7: Failed to register i2c client max98090 at 0x10 (-16)

If you hack out the check for address business:

sysfs: cannot create duplicate filename '/devices/12cd.i2c/i2c-7/7-0010'

Anyway, suffice to say that the i2c core needs to be extended to
handle the idea that a single device has more than one "compatible"
string.  I'll leave it to an eager reader of this thread to implement
this since we can also fix our own problem by just listing "max98091"
in "sound/soc/codecs/max98090.c" like has always been done in the
past.


-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 00/14] arm-soc fixes for 3.16 review

[Jason Cooper]

On Fri, Jun 13, 2014 at 06:01:02PM +0200, Arnd Bergmann wrote:
> here are the fixes I've picked up so far as the last pull request
> for the merge window. I'm sure there will be a lot more in the
> future, but let us know if I missed something 

Please see my pull request that I replied to today.  It has two dts
fixes for NAND ECC handling.

thx,

Jason.
--
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/2] mfd: cros_ec: spi: Fix end of transfer on devices with no spi-msg-delay

[Doug Anderson]

cros_ec_spi makes the assumption that a 0-length message will put the
spi chip select back to normal (non cs_toggle mode).  This used to be
the case back on kernel-3.8 on the spi-s3c64xx driver but doesn't
appear to be true anymore.  It seems like it was a pretty questionable
assumption to begin with, so let's fix the code to be more robust.  We
know that a message with a single 0-length segment _will_ put things
back in order.  Change cros_ec_spi to handle this.

This wasn't a problem on the main user of cros_ec_spi upstream (tegra)
because it specified 'google,cros-ec-spi-msg-delay'.

Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec_spi.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 0b8d328..0cbc3db 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -266,18 +266,14 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
dev_err(ec_dev->dev, "spi transfer failed: %d\n", ret);
}
 
-   /* turn off CS */
+   /*
+* Turn off CS, possibly adding a delay to ensure the rising edge
+* doesn't come too soon after the end of the data.
+*/
spi_message_init(&msg);
-
-   if (ec_spi->end_of_msg_delay) {
-   /*
-* Add delay for last transaction, to ensure the rising edge
-* doesn't come too soon after the end of the data.
-*/
-   memset(&trans, 0, sizeof(trans));
-   trans.delay_usecs = ec_spi->end_of_msg_delay;
-   spi_message_add_tail(&trans, &msg);
-   }
+   memset(&trans, 0, sizeof(trans));
+   trans.delay_usecs = ec_spi->end_of_msg_delay;
+   spi_message_add_tail(&trans, &msg);
 
final_ret = spi_sync(ec_spi->spi, &msg);
ktime_get_ts(&ts);
-- 
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

[PATCH 2/2] 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 "cros-ec-keyboard.dtsi" in order to compile properly.  See
  (ARM: dts: Create a cros-ec-keyboard fragment) at
  .
* Needs (mfd: cros_ec: spi: Fix end of transfer on devices with no
  spi-msg-delay) from this series to work properly.
* 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 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 146 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 146 +
 2 files changed, 292 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..67b7c32 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";
+   };
+
memory {
reg = <0x2000 0x8000>;
};
@@ -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;
+   };
 };
 
 &pinctrl_0 {
@@ -111,6 +123,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>;
+   };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = "gpx3-7";
samsung,pin-function = <0>;
@@ -127,6 +153,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>;
@@ -189,6 +228,111 @@
};
 };
 
+&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 =

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown  wrote:
> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  wrote:
>
>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>
> It is?  We should fix that if it's the case...

Yah, I mentioned it to Mark Rutland at the last ELC and he said he
might take a look at it, but I probably should have posted something
up to the i2c list.

I made a half-assed attempt to fix it locally in the ChromeOS but
quickly found that it was going to be a much bigger job than I had
time for...

https://chromium-review.googlesource.com/#/c/184406/

IIRC i2c_new_device didn't return an error like I thought it would,
probably trying to deal with the fact that devices might show up at a
later point in time.


Hrm, now that I think about it I wonder if the right answer is just to
call i2c_new_device for all the compatible strings even if it doesn't
return an error.  I'd have to go back and try that and re-explore this
code...

-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 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  wrote:

> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(

It is?  We should fix that if it's the case...


signature.asc
Description: Digital signature

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  wrote:
> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

If you want to be a stickler about it, peach-pi actually has a
max98091.  That requires code changes to the i2c driver, though.
...and unfortunately listing two compatible strings for i2c devices is
broken.  :(


> Signed-off-by: Tushar Behera 
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 
> +
>  1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..76f5966 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -78,9 +78,27 @@
> pinctrl-0 = <&usb301_vbus_en>;
> enable-active-high;
> };
> +
> +   sound {
> +   compatible = "google,snow-audio-max98090";
> +
> +   samsung,i2s-controller = <&i2s0>;
> +   samsung,audio-codec = <&max98090>;
> +   };
> +};
> +
> +&i2s0 {
> +   status = "okay";

It would be awfully nice to keep diffs between exynos5420-peach-pit
and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
already gotten messed up with DP/HDMI were added, but there's no need
to make it worse.

Could you add these nodes in the same place within the dts they were
added in exynos5420-peach-pit?
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode

[Sachin Kamat]

Kukjin,

On Sat, May 31, 2014 at 12:12 AM, Kukjin Kim  wrote:
> On 05/31/14 03:19, Andreas Färber wrote:
>>
>> Am 28.05.2014 06:13, schrieb Sachin Kamat:
>>>
>>> Almost all Exynos-series of SoCs that run in secure mode don't need
>>> additional offset for every CPU, with Exynos4412 being the only
>>> exception.
>>>
>>> Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420).
>>>
>>> While at it, fix the coding style (space around *).
>>>
>>> Signed-off-by: Sachin Kamat
>>> Signed-off-by: Tushar Behera
>>> ---
>>>   arch/arm/mach-exynos/firmware.c |9 +++--
>>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>
>>
>> Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to
>> applying the 5410 patches...
>>
>> Tested-by: Andreas Färber
>>
> Andreas, thanks for your test :-)
>
> Sachin, How about exynos4210, 5250, 5260 and 5440?...
> I need to check again, honestly I don't remember all of Exynos SoCs'
> different things ;-) Then will apply into fixes for 3.16.

ping..

 --
Regards,
Sachin.
--
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 00/14] arm-soc fixes for 3.16 review

[Arnd Bergmann]

Hi Everyone,

here are the fixes I've picked up so far as the last pull request
for the merge window. I'm sure there will be a lot more in the
future, but let us know if I missed something or if any of the
patches (in particular mine, some of which I have not posted
before) are not ok.

Arnd Bergmann (6):
  ARM: mvebu: fix randconfig builds for pmsu driver
  ARM: omap2: fix am43xx dependency on l2x0 cache
  ARM: keystone requires ARM_PATCH_PHYS_VIRT
  bus/arm-cci: add dependency on OF && CPU_V7
  remoteproc: da8xx: don't select CMA on no-MMU
  ARM: samsung: make SAMSUNG_DMADEV optional

Dan Carpenter (1):
  misc: vexpress: fix error handling vexpress_syscfg_regmap_init()

Jason Cooper (1):
  ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size

Linus Walleij (1):
  ARM: integrator: fix section mismatch problem

Olof Johansson (1):
  ARM: exynos: move sysram info to exynos.c

Rob Herring (2):
  ARM: exynos: cleanup kconfig option display
  ARM: use menuconfig for sub-arch menus

Sachin Kamat (1):
  ARM: EXYNOS: Fix compilation warning

Stephen Boyd (1):
  ARM: Remove ARCH_HAS_CPUFREQ config option

 arch/arm/Kconfig | 20 +--
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  2 +-
 arch/arm/configs/omap2plus_defconfig |  1 +
 arch/arm/mach-bcm/Kconfig|  7 +++---
 arch/arm/mach-berlin/Kconfig |  6 +
 arch/arm/mach-cns3xxx/Kconfig|  7 +++---
 arch/arm/mach-davinci/Kconfig|  1 -
 arch/arm/mach-exynos/Kconfig |  7 +-
 arch/arm/mach-exynos/common.h|  1 +
 arch/arm/mach-exynos/exynos.c| 31 +++-
 arch/arm/mach-exynos/platsmp.c   | 26 ++--
 arch/arm/mach-highbank/Kconfig   |  1 -
 arch/arm/mach-imx/Kconfig| 10 +++-
 arch/arm/mach-integrator/Kconfig |  2 +-
 arch/arm/mach-integrator/impd1.c | 12 -
 arch/arm/mach-keystone/Kconfig   |  1 +
 arch/arm/mach-moxart/Kconfig |  2 +-
 arch/arm/mach-mvebu/Kconfig  |  8 ++
 arch/arm/mach-mvebu/pmsu.c   |  9 ++-
 arch/arm/mach-nomadik/Kconfig|  4 +--
 arch/arm/mach-omap2/Kconfig  | 11 +
 arch/arm/mach-omap2/common.h |  7 ++
 arch/arm/mach-prima2/Kconfig |  6 ++---
 arch/arm/mach-qcom/Kconfig   |  6 +
 arch/arm/mach-s3c24xx/Kconfig|  2 +-
 arch/arm/mach-s3c64xx/Kconfig|  4 +--
 arch/arm/mach-s5p64x0/Kconfig|  6 +++--
 arch/arm/mach-s5pc100/Kconfig|  3 ++-
 arch/arm/mach-s5pv210/Kconfig|  3 ++-
 arch/arm/mach-shmobile/Kconfig   |  6 ++---
 arch/arm/mach-spear/Kconfig  |  1 -
 arch/arm/mach-tegra/Kconfig  |  8 +++---
 arch/arm/mach-u300/Kconfig   |  6 +
 arch/arm/mach-ux500/Kconfig  |  7 +-
 arch/arm/mach-vexpress/Kconfig   |  8 +++---
 arch/arm/mach-vt8500/Kconfig |  1 -
 arch/arm/mach-zynq/Kconfig   |  1 -
 arch/arm/plat-samsung/Kconfig| 28 ++---
 drivers/bus/Kconfig  |  2 +-
 drivers/misc/vexpress-syscfg.c   | 12 ++---
 drivers/remoteproc/Kconfig   |  2 +-
 41 files changed, 127 insertions(+), 161 deletions(-)

-- 
1.8.3.2

Cc: and...@lunn.ch
Cc: a...@arndb.de
Cc: ben-li...@fluff.org
Cc: dan.carpen...@oracle.com
Cc: daniel.lezc...@linaro.org
Cc: gregory.clem...@free-electrons.com
Cc: ja...@lakedaemon.net
Cc: khil...@linaro.org
Cc: kgene@samsung.com
Cc: linus.wall...@linaro.org
Cc: lorenzo.pieral...@arm.com
Cc: o...@wizery.com
Cc: o...@lixom.net
Cc: pawel.m...@arm.com
Cc: r...@kernel.org
Cc: rt...@ti.com
Cc: li...@arm.linux.org.uk
Cc: sachin.ka...@linaro.org
Cc: santosh.shilim...@ti.com
Cc: sebastian.hesselba...@gmail.com
Cc: shawn@linaro.org
Cc: sb...@codeaurora.org
Cc: t.f...@samsung.com
Cc: t...@atomide.com
Cc: tushar.beh...@linaro.org
Cc: viresh.ku...@linaro.org
Cc:  linux-o...@vger.kernel.org
Cc:  linux-samsung-soc@vger.kernel.org
--
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 11/14] ARM: exynos: cleanup kconfig option display

[Arnd Bergmann]

From: Rob Herring 

The addition of Exynos to multi-platform configs creates a mess of config
options with options appearing before the Exynos config option. This is
due to arch/arm/plat-samsung/Kconfig being included out of order with the
other Samsung platform kconfig files. Reorder the kconfig files and move
all the options into a sub-menu. Some of the options are dead, so remove
those as well.

Signed-off-by: Rob Herring 
Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Arnd Bergmann 
---
 arch/arm/Kconfig  |  3 +--
 arch/arm/plat-samsung/Kconfig | 17 +++--
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9b8f528..245058b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -994,8 +994,6 @@ source "arch/arm/mach-rockchip/Kconfig"
 
 source "arch/arm/mach-sa1100/Kconfig"
 
-source "arch/arm/plat-samsung/Kconfig"
-
 source "arch/arm/mach-socfpga/Kconfig"
 
 source "arch/arm/mach-spear/Kconfig"
@@ -1013,6 +1011,7 @@ source "arch/arm/mach-s5pc100/Kconfig"
 source "arch/arm/mach-s5pv210/Kconfig"
 
 source "arch/arm/mach-exynos/Kconfig"
+source "arch/arm/plat-samsung/Kconfig"
 
 source "arch/arm/mach-shmobile/Kconfig"
 
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 91911e4..301b892 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -35,27 +35,15 @@ config SAMSUNG_PM
  Base platform power management code for samsung code
 
 if PLAT_SAMSUNG
+menu "Samsung Common options"
 
 # boot configurations
 
 comment "Boot options"
 
-config S3C_BOOT_ERROR_RESET
-   bool "S3C Reboot on decompression error"
-   help
- Say y here to use the watchdog to reset the system if the
- kernel decompressor detects an error during decompression.
-
-config S3C_BOOT_UART_FORCE_FIFO
-   bool "Force UART FIFO on during boot process"
-   default y
-   help
- Say Y here to force the UART FIFOs on during the kernel
-uncompressor
-
-
 config S3C_LOWLEVEL_UART_PORT
int "S3C UART to use for low-level messages"
+   depends on ARCH_S3C64XX
default 0
help
  Choice of which UART port to use for the low-level messages,
@@ -502,4 +490,5 @@ config DEBUG_S3C_UART
default "2" if DEBUG_S3C_UART2
default "3" if DEBUG_S3C_UART3
 
+endmenu
 endif
-- 
1.8.3.2

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

Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

[Doug Anderson]

Paul,

On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle  wrote:
> Doug,
>
> On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
>> On Wed, Jun 11, 2014 at 3:37 AM, Paul Bolle  wrote:
>> > On Tue, 2014-05-20 at 09:46 +0100, Lee Jones wrote:
>> >> On Wed, 30 Apr 2014, Doug Anderson wrote:
>> >> > From: Bill Richardson 
>> >> >
>> >> > This just updates include/linux/mfd/cros_ec_commands.h to match the
>> >> > latest EC version (which is the One True Source for such things).  See
>> >> > 
>>
>> I believe most of your questions are answered by checking out the git
>> tree referenced above.  ...but see below for details.  This header is
>> a common interface between the kernel and the EC.
>
> I didn't realize that this was a link to a tree.
>
>> > CONFIG_CHARGER_PROFILE_OVERRIDE doesn't match anything in linux-next. Is
>> > a Kconfig symbol CHARGER_PROFILE_OVERRIDE perhaps queued somewhere?
>>
>> This is a config option on the ChromeOS EC
>> .  Doing a
>> grep there:
>>
>> board/samus/board.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE
>> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
>> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
>> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
>> driver/battery/samus.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
>> driver/battery/samus.c:#endif   /* CONFIG_CHARGER_PROFILE_OVERRIDE */
>> include/config.h:#undef CONFIG_CHARGER_PROFILE_OVERRIDE
>> include/ec_commands.h:  /* Range for CONFIG_CHARGER_PROFILE_OVERRIDE params 
>> */
>> test/test_config.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE
>
> I see. So this is not a Kconfig macro but a general macro with a CONFIG_
> prefix. There are quite a bit of those in the tree already, but still,
> would another prefix also do?

Given that it's an entirely separate project and this is a valid
CONFIG option in that project, it seems a lot to ask them not to use
the CONFIG_ prefix.  Also: the part you are objecting to is only a
comment, right?

We could certainly add extra wording in the comment to make it obvious
that this is a CONFIG option for the EC and not the kernel.  Would
that be enough?  ...or are you trying to use some scripts to
automatically process files to look for CONFIG options?

-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] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start

[Doug Anderson]

Chander,

On Fri, Jun 13, 2014 at 4:54 AM, Chander Kashyap  wrote:
> This patch is effectively changing the mcpm_entry_point address from
> nsbase + 0x1c to nsbase + 0x8
>
> Hence while integrating with mainline u-boot we need to take care for
> new mcpm_entry_point address.
>
> With Chromebook it works straightforward.

Can you explain more and point to the code that is using the nsbase +
0x1c?  Specifically the only code I see that uses the nsbase + 0x1c is
the code that is located at nsbase, which is the code we're
overwriting here.  I'd imagine you're using U-Boot code that looks
something like the bits that start at code_base here:

https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/ce358daf5069f1dc145b0f9d403cfbb028271807/arch/arm/cpu/armv7/exynos/lowlevel.S

With my kernel change you can completely eliminate U-Boot's
installation of this code (or keep it, it makes no difference).

-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/1] ARM: EXYNOS: Fix compilation warning

[Arnd Bergmann]

On Thursday 22 May 2014, Tushar Behera wrote:
> On 05/21/2014 04:56 PM, Sachin Kamat wrote:
> > On 5 May 2014 14:56, Sachin Kamat  wrote:
> >> of_get_flat_dt_prop return type is now const.
> >> Fixes the following compilation warning introduced by commit 9d0c4dfedd96
> >> ("of/fdt: update of_get_flat_dt_prop in prep for libfdt")
> >>
> >> arch/arm/mach-exynos/exynos.c:259:6: warning:
> >> assignment discards ‘const’ qualifier from pointer target type [enabled by 
> >> default]
> >>
> >> Signed-off-by: Sachin Kamat 
> >> Cc: Rob Herring 
> >> ---
> 
> Change looks good.
> 
> Reviewed-by: Tushar Behera 

This hasn't shown up in linux-next yet, and hte bug is still there, so I'm 
applying
it directly to the fixes branch in arm-soc before we get more people sending
the same patch. Thanks!

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: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start

[Nicolas Pitre]

On Fri, 13 Jun 2014, Chander Kashyap wrote:

> This patch is effectively changing the mcpm_entry_point address from
> nsbase + 0x1c to nsbase + 0x8
> 
> Hence while integrating with mainline u-boot we need to take care for
> new mcpm_entry_point address.

Why not inserting a NOP as the first instruction then? That way the 
offset will remain the same.


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] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start

[Chander Kashyap]

On Wed, Jun 11, 2014 at 8:58 PM, Kukjin Kim  wrote:
> On 06/12/14 00:19, Doug Anderson wrote:
>>
>> Chander,
>>
>> On Tue, Jun 10, 2014 at 9:52 PM, Chander Kashyap
>> wrote:
>>>
>>> Hi Doug,
>>>
>>> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre
>>> wrote:

 On Tue, 10 Jun 2014, Doug Anderson wrote:

> My S-state knowledge is not strong, but I believe that Lorenzo's
> questions matter if we're using S2 for CPUidle (where we actually turn
> off power and hot unplug CPUs) but not when we're using S1 for CPUidle
> (where we just enter WFI/WFE).
>
>>>
>>> No Its not plain WFI.
>>>
>>> All cores in Exynos5420 can be powered off independently.
>>> This functionality has been tested.
>>>
>>> Below is the link for the posted patches.
>>>
>>> https://lkml.org/lkml/2014/6/10/194
>>>
>>> And as Nicolas wrote, these patches need MCPM for that.
>>
>>
>> Most excellent!  I should have been more clear that I only knew about
>> how CPUidle worked in our local production kernel.  There I'm pretty
>> sure CPUidle is just WFI/WFE.  If you've got patches to do better then
>> that's great!
>>
>> ...can you confirm that my patch doesn't interfere with your improved
>> CPUidle?  It's been Acked by Nicolas (thanks!) so I'd imagine it will
>> land shortly.  Kukjin: I assume you'll be taking this?
>>

This patch is effectively changing the mcpm_entry_point address from
nsbase + 0x1c to nsbase + 0x8

Hence while integrating with mainline u-boot we need to take care for
new mcpm_entry_point address.

With Chromebook it works straightforward.


> Sure, I will ;-)
>
> Thanks,
> Kukjin
>
> --
> 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: [PATCH v2 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Vivek Gautam]

Hi,


On Wed, Jun 11, 2014 at 9:09 PM, Alan Stern  wrote:
> On Fri, 6 Jun 2014, Vivek Gautam wrote:
>
>> Facilitate getting required 3.3V and 1.0V VDD supply for
>> EHCI controller on Exynos.
>>
>> With patches for regulators' nodes merged in 3.15:
>> c8c253f ARM: dts: Add regulator entries to smdk5420
>> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>>
>> certain perripherals will now need to ensure that,
>> they request VDD regulators in their drivers, and enable
>> them so as to make them working.
>
> "Certain peripherals"?  Don't you mean "certain controllers"?

Right, 'certain controllers'.

>
> Does this mean some controllers don't need to use the VDD regulators?

Actually until the two patches got merged, the USB controllers were
depending on bootloader
for the VDD supply, wherein it was enabled, which ofcourse was bad.
And by 'certain' i meant that above mentioned dt patches enable only the minimum
number of regulators for the system, however leaves other for the
drivers to enable.
Anyways, i will re-do this commit message.

>
>> @@ -193,7 +196,31 @@ static int exynos_ehci_probe(struct platform_device 
>> *pdev)
>>
>>   err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
>>   if (err)
>> - goto fail_clk;
>> + goto fail_regulator1;
>> +
>> + exynos_ehci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> + if (!IS_ERR(exynos_ehci->vdd33)) {
>> + err = regulator_enable(exynos_ehci->vdd33);
>> + if (err) {
>> + dev_err(&pdev->dev,
>> + "Failed to enable 3.3V Vdd supply\n");
>> + goto fail_regulator1;
>> + }
>> + } else {
>> + dev_warn(&pdev->dev, "Regulator 3.3V Vdd supply not found\n");
>> + }
>
> What if this is one of the controllers that don't need to use a VDD
> regulator?  Do you really want to print out a warning in that case?
> Should you call devm_regulator_get_optional() instead?

Right, better to use devm_regulator_get_optional(). Thanks for
pointing this out.




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: samsung: make SAMSUNG_DMADEV optional

[Arnd Bergmann]

The only remaining driver using the samsung dmadev code is the broken
samsung-ac97 sound driver. However, as found by Russell's autobuilder,
the elaborate dependency chains around it cause problems with
circular dependencies.

This is an attempt to simplify those dependencies by making the
SAMSUNG_DMADEV option user-selectable. I also try to keep the
default settings for all related options unchanged, so we don't
introduce any regressions against earlier testing on linux-next.

In particular, all s3c64xx and s5p* platforms keep selecting the
pl330 and pl08x drivers they require, but the select statement
is now moved towards the main platform option, and it remains
optional by unselecting CONFIG_DMADEVICES.

Signed-off-by: Arnd Bergmann 
---
I'd like to apply this into the fixes branch for 3.16. It should
help with the circular dependencies that Russell is seeing, and
also simplify the cleanups we have planned for 3.17.

Any feedback, testing, NAK?

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index d863722..eff95e9 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -18,9 +18,9 @@ config CPU_S3C6410
  Enable S3C6410 CPU support
 
 config S3C64XX_PL080
-   bool "S3C64XX DMA using generic PL08x driver"
+   def_bool DMADEVICES
+   select ARM_AMBA
select AMBA_PL08X
-   select SAMSUNG_DMADEV
 
 config S3C64XX_SETUP_SDHCI
bool
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 6480d5c..a564953 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -9,16 +9,18 @@ if ARCH_S5P64X0
 
 config CPU_S5P6440
bool
+   select ARM_AMBA
+   select PL330_DMA if DMADEVICES
select S5P_SLEEP if PM
-   select SAMSUNG_DMADEV
select SAMSUNG_WAKEMASK if PM
help
  Enable S5P6440 CPU support
 
 config CPU_S5P6450
bool
+   select ARM_AMBA
+   select PL330_DMA if DMADEVICES
select S5P_SLEEP if PM
-   select SAMSUNG_DMADEV
select SAMSUNG_WAKEMASK if PM
help
  Enable S5P6450 CPU support
diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
index c3d5360..769cb0c 100644
--- a/arch/arm/mach-s5pc100/Kconfig
+++ b/arch/arm/mach-s5pc100/Kconfig
@@ -9,8 +9,9 @@ if ARCH_S5PC100
 
 config CPU_S5PC100
bool
+   select ARM_AMBA
+   select PL330_DMA if DMADEVICES
select S5P_EXT_INT
-   select SAMSUNG_DMADEV
help
  Enable S5PC100 CPU support
 
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index ede09e6..94fbf3b 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -11,10 +11,11 @@ if ARCH_S5PV210
 
 config CPU_S5PV210
bool
+   select ARM_AMBA
+   select PL330_DMA if DMADEVICES
select S5P_EXT_INT
select S5P_PM if PM
select S5P_SLEEP if PM
-   select SAMSUNG_DMADEV
help
  Enable S5PV210 CPU support
 
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index f8c1bde..d27908c 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -408,17 +408,16 @@ config SAMSUNG_PM_GPIO
  Include legacy GPIO power management code for platforms not using
  pinctrl-samsung driver.
 
-endif
-
 config SAMSUNG_DMADEV
-   bool
-   select ARM_AMBA
+   bool "Use legacy Samsung DMA abstraction"
+   depends on CPU_S5PV210 || CPU_S5PC100 || ARCH_S5P64X0 || ARCH_S3C64XX
select DMADEVICES
-   select PL330_DMA if (ARCH_EXYNOS5 || ARCH_EXYNOS4 || CPU_S5PV210 || 
CPU_S5PC100 || \
-   CPU_S5P6450 || CPU_S5P6440)
+   default y
help
  Use DMA device engine for PL330 DMAC.
 
+endif
+
 config S5P_DEV_MFC
bool
help

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

Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

[Paul Bolle]

Doug,

On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
> On Wed, Jun 11, 2014 at 3:37 AM, Paul Bolle  wrote:
> > On Tue, 2014-05-20 at 09:46 +0100, Lee Jones wrote:
> >> On Wed, 30 Apr 2014, Doug Anderson wrote:
> >> > From: Bill Richardson 
> >> >
> >> > This just updates include/linux/mfd/cros_ec_commands.h to match the
> >> > latest EC version (which is the One True Source for such things).  See
> >> > 
> 
> I believe most of your questions are answered by checking out the git
> tree referenced above.  ...but see below for details.  This header is
> a common interface between the kernel and the EC.

I didn't realize that this was a link to a tree.

> > CONFIG_CHARGER_PROFILE_OVERRIDE doesn't match anything in linux-next. Is
> > a Kconfig symbol CHARGER_PROFILE_OVERRIDE perhaps queued somewhere?
> 
> This is a config option on the ChromeOS EC
> .  Doing a
> grep there:
> 
> board/samus/board.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE
> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
> common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
> driver/battery/samus.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE
> driver/battery/samus.c:#endif   /* CONFIG_CHARGER_PROFILE_OVERRIDE */
> include/config.h:#undef CONFIG_CHARGER_PROFILE_OVERRIDE
> include/ec_commands.h:  /* Range for CONFIG_CHARGER_PROFILE_OVERRIDE params */
> test/test_config.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE

I see. So this is not a Kconfig macro but a general macro with a CONFIG_
prefix. There are quite a bit of those in the tree already, but still,
would another prefix also do?

Thanks,


Paul Bolle

--
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: Exynos HDMI PHY settings for 85.5MHz

[SHIRISH S]

Hi Daniel.
I have already submitted patch for 85.5MHz (1360x768),  
http://lists.freedesktop.org/archives/dri-devel/2014-May/060358.html
However i cant help in knowing how to get the magic numbers, because its 
provided by our h/w team.
Regards,
Shirish S

--- Original Message ---
Sender : Daniel Drake 
Date   : Jun 12, 2014 19:19 (GMT+05:30)
Title  : Exynos HDMI PHY settings for 85.5MHz

Hi Shirish,

Thanks a lot for your recent patch titled "drm/exynos: add phy
settings for RB resolutions"

Can you tell me more about the process of generating these magic numbers?

I would be very interested in adding 85.5MHz, which is for 1366x768.
Can you help in some way?

Thanks
Daniel
  

Re: [PATCH 0/4] cpufreq: Use cpufreq-cpu0 driver for Exynos3250

[Chanwoo Choi]

Hi Thomas,

On 06/13/2014 04:00 PM, Thomas Abraham wrote:
> On Fri, Jun 13, 2014 at 12:06 PM, Viresh Kumar  
> wrote:
>> cpuf...@vger.kernel.org is dead now. Anyway you should be using linux-pm
>> instead.
>>
>> On 13 June 2014 11:38, Chanwoo Choi  wrote:
>>> This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, 
>>> this
>>> patchset is based on following patchset[1] by Thomas Abraham.
>>>  [1] http://www.spinics.net/lists/linux-samsung-soc/msg31593.html
>>>
>>> Chanwoo Choi (4):
>>>   clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq
>>>   clk: samsung: Add support for cpu clocks of Exynos3250
>>>   Documentation: devicetree: Add cpu clock configuration data binding for 
>>> Exynos3250
>>>   ARM: dts: Exynos: Add cpu clock table and armclk divider table for 
>>> Exynos3250
>>>
>>>  .../devicetree/bindings/clock/exynos3250-clock.txt | 32 
>>> ++
>>>  arch/arm/boot/dts/exynos3250.dtsi  | 28 +++
>>>  drivers/clk/samsung/clk-cpu.c  | 31 
>>> +
>>>  drivers/clk/samsung/clk-exynos3250.c   | 14 +++---
>>>  4 files changed, 96 insertions(+), 9 deletions(-)
>>
>> Nothing really cpufreq specific. Would *eagerly* wait for the patch that
>> removes existing driver files :)
> 
> The next version of the exynos cpufreq cleanup patches are being
> prepared. But exynos4x12 cpufreq driver will not be included for
> cleanup since the boost frequency bindings need more work.

After you send next patchset, I'll rebase it and resend patchset to support 
exynos3250 cpufreq.

Thanks,
Chanwoo Choi

--
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/4] cpufreq: Use cpufreq-cpu0 driver for Exynos3250

[Thomas Abraham]

On Fri, Jun 13, 2014 at 12:06 PM, Viresh Kumar  wrote:
> cpuf...@vger.kernel.org is dead now. Anyway you should be using linux-pm
> instead.
>
> On 13 June 2014 11:38, Chanwoo Choi  wrote:
>> This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this
>> patchset is based on following patchset[1] by Thomas Abraham.
>>  [1] http://www.spinics.net/lists/linux-samsung-soc/msg31593.html
>>
>> Chanwoo Choi (4):
>>   clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq
>>   clk: samsung: Add support for cpu clocks of Exynos3250
>>   Documentation: devicetree: Add cpu clock configuration data binding for 
>> Exynos3250
>>   ARM: dts: Exynos: Add cpu clock table and armclk divider table for 
>> Exynos3250
>>
>>  .../devicetree/bindings/clock/exynos3250-clock.txt | 32 
>> ++
>>  arch/arm/boot/dts/exynos3250.dtsi  | 28 +++
>>  drivers/clk/samsung/clk-cpu.c  | 31 
>> +
>>  drivers/clk/samsung/clk-exynos3250.c   | 14 +++---
>>  4 files changed, 96 insertions(+), 9 deletions(-)
>
> Nothing really cpufreq specific. Would *eagerly* wait for the patch that
> removes existing driver files :)

The next version of the exynos cpufreq cleanup patches are being
prepared. But exynos4x12 cpufreq driver will not be included for
cleanup since the boost frequency bindings need more work.

Thanks,
Thomas.

> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" 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