date:20140623

This series adds UHS support for dw_mmc driver.
Patch[1] reworks the handling of vmmc and vqmmc regulators.
Patch[2] handles the case where in some boards uses built-in CD line for
card detection and connected to a same voltage domain as of the IO rails.
Patch[3] was taken from chrome tree originally developed by Doug Anderson.

These patches were tested on exynos based chromebook with 3.16-rc1.

Doug Anderson (1):
  mmc: dw_mmc: Support voltage changes

Yuvaraj Kumar C D (2):
  mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
  mmc: dw_mmc: Dont cut off vqmmc and vmmc

 drivers/mmc/host/dw_mmc.c  |  239 +++-
 drivers/mmc/host/dw_mmc.h  |7 +-
 include/linux/mmc/dw_mmc.h |2 +
 3 files changed, 201 insertions(+), 47 deletions(-)

-- 
1.7.10.4

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

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

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 yuvaraj...@samsung.com
---
 drivers/mmc/host/dw_mmc.c |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index f5cabce..e034bce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -932,6 +932,25 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
spin_unlock_bh(host-lock);
 }
 
+/*
+ * some of the boards use controller CD line for card detection.Unfortunately
+ * CD line is bind to the same volatge domain as of the IO lines.If we turn off
+ * IO voltage domain, CD line wont work.
+ * Return true when controller CD line is used for card detection or return
+ * false.
+ */
+static bool dw_mci_builtin_cd(struct dw_mci_slot *slot)
+{
+   struct dw_mci_board *brd = slot-host-pdata;
+   struct mmc_host *mmc = slot-mmc;
+
+   if ((brd-quirks  DW_MCI_QUIRK_BROKEN_CARD_DETECTION) 
+   !IS_ERR_VALUE(mmc_gpio_get_cd(mmc)))
+   return true;
+   else
+   return false;
+}
+
 static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 {
struct dw_mci_slot *slot = mmc_priv(mmc);
@@ -988,6 +1007,10 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+   if (dw_mci_builtin_cd(slot) 
+   !test_bit(DW_MMC_CARD_PRESENT, slot-flags))
+   return;
+
if (!IS_ERR(mmc-supply.vqmmc) 
test_bit(DW_MMC_IO_POWERED, slot-flags)) {
ret = regulator_disable(mmc-supply.vqmmc);
-- 
1.7.10.4

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

[PATCH 3/3] mmc: dw_mmc: Support voltage changes

From: Doug Anderson diand...@chromium.org

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 diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com

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

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index e034bce..38eb548 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -29,6 +29,7 @@
 #include linux/irq.h
 #include linux/mmc/host.h
 #include linux/mmc/mmc.h
+#include linux/mmc/sd.h
 #include linux/mmc/sdio.h
 #include linux/mmc/dw_mmc.h
 #include linux/bitops.h
@@ -235,10 +236,13 @@ err:
 }
 #endif /* defined(CONFIG_DEBUG_FS) */
 
+static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
+
 static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command 
*cmd)
 {
struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
+   struct dw_mci *host = slot-host;
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 cmdr;
cmd-error = -EINPROGRESS;
@@ -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.
+*
+* It's assumed that by the next time the CLKENA is updated
+* (when we set the clock next) that the voltage change will
+* be over, so we don't bother setting any bits to synchronize
+* with dw_mci_setup_bus().
+*/
+   clk_en_a = mci_readl(host, CLKENA);
+   clk_en_a = ~(SDMMC_CLKEN_LOW_PWR  slot-id);
+   mci_writel(host, CLKENA, clk_en_a);
+   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
+SDMMC_CMD_PRV_DAT_WAIT, 0);
+   }
+
if (cmd-flags  MMC_RSP_PRESENT) {
/* We expect a response, so set this bit */
cmdr |= SDMMC_CMD_RESP_EXP;
@@ -776,11 +806,15 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, 
bool force_clkinit)
unsigned int clock = slot-clock;
u32 div;
u32 clk_en_a;
+   u32 sdmmc_cmd_bits = SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT;
+
+   /* We must continue to set bit 28 in CMD until the change is complete */
+   if (host-state == STATE_WAITING_CMD11_DONE)
+   sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
 
if (!clock) {
mci_writel(host, CLKENA, 0);
-   mci_send_cmd(slot,
-SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+   mci_send_cmd(slot, sdmmc_cmd_bits, 0);
} else if (clock != host-current_speed || force_clkinit) {
div = host-bus_hz / clock;
if (host-bus_hz % clock  host-bus_hz  clock)
@@ -804,15 +838,13 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, 
bool force_clkinit)
mci_writel(host, CLKSRC, 0);
 
/* inform CIU */
-   mci_send_cmd(slot,
-SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+   mci_send_cmd(slot, sdmmc_cmd_bits, 0);
 
/* set clock to desired speed */
mci_writel(host, CLKDIV, div);
 
/* inform CIU */
-   mci_send_cmd(slot,
-SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+   mci_send_cmd(slot, sdmmc_cmd_bits, 0);
 
/* enable clock; only low power if no SDIO */
clk_en_a = SDMMC_CLKEN_ENABLE  slot-id;
@@ -821,8 +853,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool 
force_clkinit)
mci_writel(host, CLKENA, clk_en_a);
 
/* inform CIU */
-   mci_send_cmd(slot,
-SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+   mci_send_cmd(slot,

[PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators

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 yuvaraj...@samsung.com
---
 drivers/mmc/host/dw_mmc.c |   71 ++---
 drivers/mmc/host/dw_mmc.h |2 ++
 2 files changed, 36 insertions(+), 37 deletions(-)

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);
+   }
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) {
-   if (ret != -EPROBE_DEFER)
-   dev_err(host-dev,
-   regulator_enable fail: %d\n, ret);
-   goto err_clk_ciu;
-   }
-   }
-
host-quirks = host-pdata-quirks;
 
spin_lock_init(host-lock);
@@ -2536,8 +2550,6 @@ err_workqueue:
 err_dmaunmap:
if (host-use_dma  host-dma_ops-exit)
host-dma_ops-exit(host);
-   if (host-vmmc)
-   regulator_disable(host-vmmc);
 
 err_clk_ciu:
if (!IS_ERR(host-ciu_clk))
@@ -2573,9 +2585,6 @@ void dw_mci_remove(struct dw_mci *host)
if (host-use_dma  host-dma_ops-exit)
host-dma_ops-exit(host);
 
-   if (host-vmmc)
-   regulator_disable(host-vmmc);
-

[PATCH] ARM: DTS: correct the capability string for mmc0

2014-06-23 Thread Naveen Krishna Chatradhi

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 ch.nav...@samsung.com
---
 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

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

2014-06-23 Thread Kukjin Kim

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 ch.nav...@samsung.com
 ---
  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.

- 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

[PATCH 1/1] ARM: EXYNOS: Remove unused code in common.h

2014-06-23 Thread Sachin Kamat

PINCTRL_EXYNOS is always selected by Exynos platform in its
machine Kconfig. Thus the code in the else part is never used.
Remove it.

Signed-off-by: Sachin Kamat sachin.ka...@samsung.com
---
 arch/arm/mach-exynos/common.h |4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1ee91763fa7c..3371669dabc6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -125,11 +125,7 @@ void exynos_init_late(void);
 
 void exynos_firmware_init(void);
 
-#ifdef CONFIG_PINCTRL_EXYNOS
 extern u32 exynos_get_eint_wake_mask(void);
-#else
-static inline u32 exynos_get_eint_wake_mask(void) { return 0x; }
-#endif
 
 #ifdef CONFIG_PM_SLEEP
 extern void __init exynos_pm_init(void);
-- 
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: Enabling 8 cores on 5420

2014-06-23 Thread Daniel Lezcano


On 06/22/2014 11:30 PM, Alim Akhtar wrote:

Hi
PTAL https://patchwork.kernel.org/patch/4315711/
I hope your tree already includes
http://www.gossamer-threads.com/lists/linux/kernel/1940123



Hi Alim,

I applied the patches above and set the configuration option for 
EXYNOS_MCPM but I have:


[7.769420] CPU1: failed to boot: -19
[7.778360] CPU2: failed to boot: -19
[7.806411] CPU4: failed to boot: -19
[7.811294] CPU3: failed to boot: -19
[7.815333] CPU7: failed to boot: -19
[7.826401] CPU6: failed to boot: -19
[7.829711] CPU5: failed to boot: -19

Is there something I missed ?

Thanks !

  -- Daniel


On Mon, Jun 23, 2014 at 2:32 AM, Andreas Färber afaer...@suse.de wrote:

Am 30.05.2014 11:25, schrieb Daniel Lezcano:


Hi all,

I am trying an upstream kernel + some patches to enable ethernet on
arndale octa.

Unfortunately, only 4 cores boot up. The other ones fail to boot.

[12.179453] CPU6: failed to come online
[13.189479] CPU7: failed to come online
[14.199479] CPU4: failed to come online
[15.209743] CPU5: failed to come online

What should I do to enable those 8 cores ? Is there a patchset somewhere
to do so ?


Ping? Confirmed still present on Arndale Octa with kgene's for-next +
patch to get 2-4 up.

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







--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ 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 V4 00/10] drm: exynos: few patches to enhance bridge chip support

2014-06-23 Thread Rahul Sharma

Hi Ajay, Inki,

I tested this series for Exynos5420 based peach-pit board,
Exynos5800 based Peach-pi board and Exynos5250 based
Snow board. I verified with the chrome test environment and
able to see upto Login Screen. DPMS on/off functionality and
S2R is also working fine for Display. therefore:

Tested-by: Rahul Sharma rahul.sha...@samsung.com

Regards,
Rahul Sharma.

On 20 June 2014 21:21, Inki Dae inki@samsung.com wrote:
 2014-06-20 17:06 GMT+09:00 Ajay kumar ajayn...@gmail.com:
 ping.

 I will have a review soon but I'm afraid that I cannot have a test yet
 because I have no any board with panel based on eDP and LVDS so wait
 for until I get a board.
 Otherwise, can anyone give me tested-by? and I'd happy to give me
 reviewed-by so that I can pick this patch series up.

 Thanks,
 Inki Dae


 On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar ajaykumar...@samsung.com 
 wrote:
 This series is based on exynos-drm-next branch of Inki Dae's tree at:
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

 I have tested this after adding few DT changes for exynos5250-snow,
 exynos5420-peach-pit and exynos5800-peach-pi boards.

 This patchset also consolidates various inputs from the drm community
 regarding the bridge chaining concept:
 (1) [RFC V2 0/3] drm/bridge: panel and chaining
 http://www.spinics.net/lists/linux-samsung-soc/msg30160.html
 (2) [RFC V3 0/3] drm/bridge: panel and chaining
 http://www.spinics.net/lists/linux-samsung-soc/msg30507.html

 Changes since V2:
 -- Address comments from Jingoo Han for ps8622 driver
 -- Address comments from Daniel, Rob and Thierry regarding
bridge chaining
 -- Address comments from Thierry regarding the names for
new drm_panel functions

 Changes since V3:
 -- Remove hotplug based initialization of exynos_dp
 -- Make exynos_dp work directly with drm_panel, remove
dependency on panel_binder
 -- Minor cleanups in panel_binder and panel_lvds driver

 The following patches can be divided into 2 groups:
 patches 1 to 4: add drm_panel support to exynos_dp(peach-pi)
 patches 5 to 10: chaining of bridges and drm_panel(snow and 
 peach-pit)

 Ajay Kumar (8):
   [PATCH V4 1/10] drm/exynos: Move DP setup out of hotplug workqueue
   [PATCH V4 2/10] drm/panel: add prepare and unprepare routines
   [PATCH V4 3/10] drm/exynos: dp: modify driver to support drm_panel
   [PATCH V4 4/10] drm/panel: Add driver for lvds/edp based panels
   [PATCH V4 5/10] drm/bridge: add helper functions to support bridge chain
   [PATCH V4 6/10] drm/bridge: Add a driver which binds drm_bridge with 
 drm_panel
   [PATCH V4 7/10] drm/bridge: ptn3460: Support bridge chaining
   [PATCH V4 8/10] drm/exynos: dp: create bridge chain using ptn3460 and
   panel_binder

 Vincent Palatin (1):
   [PATCH V4 9/10] drm/bridge: Add ps8622/ps8625 bridge driver

 Rahul Sharma (1):
   [PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
  .../devicetree/bindings/panel/panel-lvds.txt   |   50 +++
  .../devicetree/bindings/video/exynos_dp.txt|2 +
  drivers/gpu/drm/bridge/Kconfig |   15 +
  drivers/gpu/drm/bridge/Makefile|2 +
  drivers/gpu/drm/bridge/panel_binder.c  |  193 
  drivers/gpu/drm/bridge/ps8622.c|  475 
 
  drivers/gpu/drm/bridge/ptn3460.c   |  136 +-
  drivers/gpu/drm/exynos/Kconfig |1 +
  drivers/gpu/drm/exynos/exynos_dp_core.c|   87 +++-
  drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
  drivers/gpu/drm/panel/Kconfig  |   10 +
  drivers/gpu/drm/panel/Makefile |1 +
  drivers/gpu/drm/panel/panel-lvds.c |  262 +++
  include/drm/bridge/panel_binder.h  |   44 ++
  include/drm/bridge/ps8622.h|   41 ++
  include/drm/bridge/ptn3460.h   |   15 +-
  include/drm/drm_crtc.h |   72 +++
  include/drm/drm_panel.h|   18 +
  19 files changed, 1309 insertions(+), 138 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
  create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
  create mode 100644 include/drm/bridge/panel_binder.h
  create mode 100644 include/drm/bridge/ps8622.h

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

2014-06-23 Thread Tomasz Figa

Hi Rahul,

On 23.06.2014 15:58, Rahul Sharma wrote:
 Hi Ajay, Inki,
 
 I tested this series for Exynos5420 based peach-pit board,
 Exynos5800 based Peach-pi board and Exynos5250 based
 Snow board. I verified with the chrome test environment and
 able to see upto Login Screen. DPMS on/off functionality and
 S2R is also working fine for Display. therefore:

What tree did you apply this patches onto? I don't see S2R support for
Exynos5420 or 5800 in current linux-next (e.g. there are no PMU tables
present for these SoCs).

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 V4 04/10] drm/panel: Add driver for lvds/edp based panels

2014-06-23 Thread Javier Martinez Canillas

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 ajaykumar...@samsung.com 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 ajaykumar...@samsung.com
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  .../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.

 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 8b92921..eaafa01 100644
 --- a/drivers/gpu/drm/panel/Makefile
 +++ b/drivers/gpu/drm/panel/Makefile
 @@ -1,3 +1,4 @@
  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o

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

2014-06-23 Thread Javier Martinez Canillas

Hello Ajay,

On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
 From: Vincent Palatin vpala...@chromium.org

 This patch adds drm_bridge driver for parade DisplayPort
 to LVDS bridge chip.

 Signed-off-by: Vincent Palatin vpala...@chromium.org
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Sean Paul seanp...@chromium.org
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../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 linux/module.h
 +#include linux/backlight.h
 +#include linux/delay.h
 +#include linux/err.h
 +#include linux/fb.h
 +#include linux/gpio.h
 +#include linux/i2c.h
 +#include linux/of.h
 +#include linux/of_gpio.h
 +#include linux/pm.h
 +#include linux/regulator/consumer.h
 +
 +#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
 +#define PS8622_POWER_RISE_T1_MAX_US 1
 +#define PS8622_RST_HIGH_T2_MIN_US 3000
 +#define PS8622_RST_HIGH_T2_MAX_US 3

Re: [PATCH V2 0/2] Sound support for Exynos4412 Odroid X2, U3 board

2014-06-23 Thread Sylwester Nawrocki

On 23/06/14 11:40, Daniel Drake wrote:
 I tested ODROID-U2's 3.5mm analog headphone jack output with:
 
 # speaker-test -c 2 -t wav -l 2
 
 On my x86 laptop this command takes ~6 seconds and produces audible output:
 Front left, front right, front left, front right
 
 When those words are reproduced over the speakers, there is a
 corresponding message printed to stdout which synchronizes nicely.
 
 On ODROID-U2 the same command doesn't work quite right - execution
 takes only 3.5 seconds and the audible output is truncated:
 Front left, front right, front
 and the stdout messages do not really coincide with the audio being
 reproduced at that time.
 
 No pulseaudio or anything like that.
 
 Can you reproduce this?

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:

# cat /sys/kernel/debug/clk/clk_summary
...
fout_epll   0   019200
   mout_audss   0   019200
  dout_rp   0   01920
 dout_aud_bus   0   01920
  mout_i2s0 0   019200
 dout_i2s0  0   019200
   sclk_epll0   019200
  audss 0   019200

So there might be some other difference I'm overlooking.
Will let you know as soon I find out anything else.

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

2014-06-23 Thread Sylwester Nawrocki

On 23/06/14 18:32, Sylwester Nawrocki wrote:
 On 23/06/14 11:40, Daniel Drake wrote:
  I tested ODROID-U2's 3.5mm analog headphone jack output with:
  
  # speaker-test -c 2 -t wav -l 2
  
  On my x86 laptop this command takes ~6 seconds and produces audible output:
  Front left, front right, front left, front right
  
  When those words are reproduced over the speakers, there is a
  corresponding message printed to stdout which synchronizes nicely.
  
  On ODROID-U2 the same command doesn't work quite right - execution
  takes only 3.5 seconds and the audible output is truncated:
  Front left, front right, front
  and the stdout messages do not really coincide with the audio being
  reproduced at that time.

Is it still wrong when you set the period manually to 1024, i.e.

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

?

--
Thanks,
Sylwester
--
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 04/10] drm/panel: Add driver for lvds/edp based panels

2014-06-23 Thread Christian Gmeiner

Hi


2014-06-11 20:27 GMT+02:00 Ajay Kumar ajaykumar...@samsung.com:
 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 ajaykumar...@samsung.com
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  .../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?

If I find some time I will give this patch a try as I need something
like this for an imx6d based device.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
--
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/4] Documentation: devicetree: Fix tps65090 typos

Andreas,

On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
 It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt 
 b/Documentation/devicetree/bindings/regulator/tps65090.txt
 index 34098023..ca69f5e 100644
 --- a/Documentation/devicetree/bindings/regulator/tps65090.txt
 +++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
 @@ -45,8 +45,8 @@ Example:
 infet5-supply = some_reg;
 infet6-supply = some_reg;
 infet7-supply = some_reg;
 -   vsys_l1-supply = some_reg;
 -   vsys_l2-supply = some_reg;
 +   vsys-l1-supply = some_reg;
 +   vsys-l2-supply = some_reg;

Your change matches the code and all existing device trees in the
Linux kernel.  I also see plenty of other bindings with dashes, so
this seems reasonable.

Reviewed-by: Doug Anderson diand...@chromium.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

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

On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera trbli...@gmail.com 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 trbli...@gmail.com 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 khil...@linaro.org
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

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

Andreas,

Thanks for posting!  A first pass on this is below...


On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
 Adds initial support for the HP Chromebook 11.

 Cc: Vincent Palatin vpala...@chromium.org
 Cc: Doug Anderson diand...@chromium.org
 Cc: Stephan van Schaik step...@synkhronix.com
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  arch/arm/boot/dts/Makefile  |   1 +
  arch/arm/boot/dts/exynos5250-spring.dts | 556 
 
  2 files changed, 557 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 5986ff6..dc2c5aa 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 exynos5250-arndale.dtb \
 exynos5250-smdk5250.dtb \
 exynos5250-snow.dtb \
 +   exynos5250-spring.dtb \
 exynos5260-xyref5260.dtb \
 exynos5410-smdk5410.dtb \
 exynos5420-arndale-octa.dtb \
 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.

If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.


 +   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


 +   };
 +
 +   vbat: vbat-fixed-regulator {
 +   compatible = regulator-fixed;
 +   regulator-name = vbat-supply;
 +   regulator-boot-on;
 +   };
 +
 +   usb@1200 {
 +   status = okay;
 +   };
 +
 +   usb3_vbus_reg: regulator-usb3 {
 +   compatible = regulator-fixed;
 +   regulator-name = P5.0V_USB3CON;
 +   regulator-min-microvolt

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

Andreas,

On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
 From: Andreas Färber andreas.faer...@web.de

 Hello,

 Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15
 based attempts by Stephan and me that broke for 3.16, I've prepared a
 device tree for the HP Chromebook 11 aka Google Spring.

 The first three patches should be good to go and contain documentation
 fixes found while comparing exynos5250-snow.dts vs. /proc/device-tree.

 The main patch was tested using a chained non-verified U-Boot (simplefb)
 and a rootfs on USB-attached SD card.
 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.

 Audio support is likely missing as my focus was getting USB booting.
 Not included is touchpad support, as atmel,atmel_mxt_tp is not
 documented to be available upstream. And no /dev/mmcblk0 or Wifi yet.
 Also when the screen stayed on, the embedded controller's keymap seems
 hardcoded to US English with system settings not taking effect; but
 surely we don't want per-keyboard device tree files to remedy that.

+Benson may be able to answer this.  I believe generally non-US
keyboard layouts are handled at a higher level.
--
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

2014-06-23 Thread Benson Leung

On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson diand...@chromium.org wrote:
 Also when the screen stayed on, the embedded controller's keymap seems
 hardcoded to US English with system settings not taking effect; but
 surely we don't want per-keyboard device tree files to remedy that.

 +Benson may be able to answer this.  I believe generally non-US
 keyboard layouts are handled at a higher level.

There's no such thing as a notion of US versus non-US keyboard layouts
at the embedded controller level or even in the kernel. Indeed, this
should all be handled in user space.

The chromeos firmware and kernel should return the correct key codes
for every key pressed on keyboards with the ANSI layout (US based), or
ISO (UK and most other countries).

The only differences are :
* the ISO keyboard has an extra key, which is immediately to the right
of the Left Shift key. This must return KEY_102ND key code from the
input layer.
* the ISO keyboard has a  different location for the | \ key, which
accomodates the upside L shaped Enter key on the right side of the
keyboard. The keycode for this key is KEY_BACKSLASH.

Basically, all of this should be verified using evtest to test that
the ec and kernel have the keys right.

If you are having other problems with keyboard layout being stuck to
US QWERTY, please check your user space.

-- 
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.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 v3 4/4] ASoC: samsung: s3c24xx-i2s: Move to clk_prepare_enable/clk_disable_unprepare

Use clk_prepare_enable/clk_disable_unprepare to make the driver
work properly with common clock framework.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 sound/soc/samsung/s3c24xx-i2s.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 6f3ee87..e8b9852 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -373,7 +373,7 @@ static int s3c24xx_i2s_probe(struct snd_soc_dai *dai)
pr_err(failed to get iis_clock\n);
return PTR_ERR(s3c24xx_i2s.iis_clk);
}
-   clk_enable(s3c24xx_i2s.iis_clk);
+   clk_prepare_enable(s3c24xx_i2s.iis_clk);
 
/* Configure the I2S pins (GPE0...GPE4) in correct mode */
s3c_gpio_cfgall_range(S3C2410_GPE(0), 5, S3C_GPIO_SFN(2),
@@ -397,7 +397,7 @@ static int s3c24xx_i2s_suspend(struct snd_soc_dai *cpu_dai)
s3c24xx_i2s.iisfcon = readl(s3c24xx_i2s.regs + S3C2410_IISFCON);
s3c24xx_i2s.iispsr = readl(s3c24xx_i2s.regs + S3C2410_IISPSR);
 
-   clk_disable(s3c24xx_i2s.iis_clk);
+   clk_disable_unprepare(s3c24xx_i2s.iis_clk);
 
return 0;
 }
@@ -405,7 +405,7 @@ static int s3c24xx_i2s_suspend(struct snd_soc_dai *cpu_dai)
 static int s3c24xx_i2s_resume(struct snd_soc_dai *cpu_dai)
 {
pr_debug(Entered %s\n, __func__);
-   clk_enable(s3c24xx_i2s.iis_clk);
+   clk_prepare_enable(s3c24xx_i2s.iis_clk);
 
writel(s3c24xx_i2s.iiscon, s3c24xx_i2s.regs + S3C2410_IISCON);
writel(s3c24xx_i2s.iismod, s3c24xx_i2s.regs + S3C2410_IISMOD);
-- 
2.0.0

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

[PATCH v3 2/4] ASoC: samsung: drop support for legacy S3C24XX DMA API

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 sound/soc/samsung/Kconfig  |   3 -
 sound/soc/samsung/Makefile |   2 -
 sound/soc/samsung/dma.c| 454 -
 3 files changed, 459 deletions(-)

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 98767d3..17547a4 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -13,9 +13,6 @@ config SND_SOC_SAMSUNG
 config SND_S3C_DMA
tristate
 
-config SND_S3C_DMA_LEGACY
-   tristate
-
 config SND_S3C24XX_I2S
tristate
 
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 6d0212b..6469199 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -1,6 +1,5 @@
 # S3c24XX Platform Support
 snd-soc-s3c-dma-objs := dmaengine.o
-snd-soc-s3c-dma-legacy-objs := dma.o
 snd-soc-idma-objs := idma.o
 snd-soc-s3c24xx-i2s-objs := s3c24xx-i2s.o
 snd-soc-s3c2412-i2s-objs := s3c2412-i2s.o
@@ -11,7 +10,6 @@ snd-soc-pcm-objs := pcm.o
 snd-soc-i2s-objs := i2s.o
 
 obj-$(CONFIG_SND_S3C_DMA) += snd-soc-s3c-dma.o
-obj-$(CONFIG_SND_S3C_DMA_LEGACY) += snd-soc-s3c-dma-legacy.o
 obj-$(CONFIG_SND_S3C24XX_I2S) += snd-soc-s3c24xx-i2s.o
 obj-$(CONFIG_SND_SAMSUNG_AC97) += snd-soc-ac97.o
 obj-$(CONFIG_SND_S3C2412_SOC_I2S) += snd-soc-s3c2412-i2s.o
diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
deleted file mode 100644
index d9dc7bc..000
--- a/sound/soc/samsung/dma.c
+++ /dev/null
@@ -1,454 +0,0 @@
-/*
- * dma.c  --  ALSA Soc Audio Layer
- *
- * (c) 2006 Wolfson Microelectronics PLC.
- * Graeme Gregory graeme.greg...@wolfsonmicro.com or li...@wolfsonmicro.com
- *
- * Copyright 2004-2005 Simtec Electronics
- * http://armlinux.simtec.co.uk/
- * Ben Dooks b...@simtec.co.uk
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  option) any later version.
- */
-
-#include linux/slab.h
-#include linux/dma-mapping.h
-#include linux/module.h
-
-#include sound/soc.h
-#include sound/pcm_params.h
-
-#include asm/dma.h
-#include mach/hardware.h
-#include mach/dma.h
-
-#include dma.h
-
-#define ST_RUNNING (10)
-#define ST_OPENED  (11)
-
-static const struct snd_pcm_hardware dma_hardware = {
-   .info   = SNDRV_PCM_INFO_INTERLEAVED |
-   SNDRV_PCM_INFO_BLOCK_TRANSFER |
-   SNDRV_PCM_INFO_MMAP |
-   SNDRV_PCM_INFO_MMAP_VALID,
-   .buffer_bytes_max   = 128*1024,
-   .period_bytes_min   = PAGE_SIZE,
-   .period_bytes_max   = PAGE_SIZE*2,
-   .periods_min= 2,
-   .periods_max= 128,
-   .fifo_size  = 32,
-};
-
-struct runtime_data {
-   spinlock_t lock;
-   int state;
-   unsigned int dma_loaded;
-   unsigned int dma_period;
-   dma_addr_t dma_start;
-   dma_addr_t dma_pos;
-   dma_addr_t dma_end;
-   struct s3c_dma_params *params;
-};
-
-static void audio_buffdone(void *data);
-
-/* dma_enqueue
- *
- * place a dma buffer onto the queue for the dma system
- * to handle.
- */
-static void dma_enqueue(struct snd_pcm_substream *substream)
-{
-   struct runtime_data *prtd = substream-runtime-private_data;
-   dma_addr_t pos = prtd-dma_pos;
-   unsigned int limit;
-   struct samsung_dma_prep dma_info;
-
-   pr_debug(Entered %s\n, __func__);
-
-   limit = (prtd-dma_end - prtd-dma_start) / prtd-dma_period;
-
-   pr_debug(%s: loaded %d, limit %d\n,
-   __func__, prtd-dma_loaded, limit);
-
-   dma_info.cap = (samsung_dma_has_circular() ? DMA_CYCLIC : DMA_SLAVE);
-   dma_info.direction =
-   (substream-stream == SNDRV_PCM_STREAM_PLAYBACK
-   ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
-   dma_info.fp = audio_buffdone;
-   dma_info.fp_param = substream;
-   dma_info.period = prtd-dma_period;
-   dma_info.len = prtd-dma_period*limit;
-
-   if (dma_info.cap == DMA_CYCLIC) {
-   dma_info.buf = pos;
-   prtd-params-ops-prepare(prtd-params-ch, dma_info);
-   prtd-dma_loaded += limit;
-   return;
-   }
-
-   while (prtd-dma_loaded  limit) {
-   pr_debug(dma_loaded: %d\n, prtd-dma_loaded);
-
-   if ((pos + dma_info.period)  prtd-dma_end) {
-   dma_info.period  = prtd-dma_end - pos;
-   pr_debug(%s: corrected dma len %ld\n,
-   __func__, dma_info.period);
-   }
-
-   dma_info.buf = pos;
-   prtd-params-ops-prepare(prtd-params-ch, dma_info);
-
-   prtd-dma_loaded++;
-   pos += prtd-dma_period;
-   if (pos =

[PATCH v3 3/4] ASoC: samsung: s3c2412-i2s: Move to clk_prepare_enable/clk_disable_unprepare

Use clk_prepare_enable/clk_disable_unprepare to make the driver
work properly with common clock framework.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 sound/soc/samsung/s3c2412-i2s.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index d9d27cc..d6bc6dc 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -76,7 +76,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
/* Set MPLL as the source for IIS CLK */
 
clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, mpll));
-   clk_enable(s3c2412_i2s.iis_cclk);
+   clk_prepare_enable(s3c2412_i2s.iis_cclk);
 
s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
 
@@ -89,7 +89,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
 
 static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
 {
-   clk_disable(s3c2412_i2s.iis_cclk);
+   clk_disable_unprepare(s3c2412_i2s.iis_cclk);
 
return 0;
 }
-- 
2.0.0

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

[PATCH v3 1/4] ASoC: samsung: s3c24{xx,12}-i2s: port to use generic dmaengine API

Use dmaengine instead of legacy s3c24xx DMA API for s3c24xx and s3c2412

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 sound/soc/samsung/Kconfig   |  9 +++
 sound/soc/samsung/dmaengine.c   |  3 +++
 sound/soc/samsung/s3c-i2s-v2.c  | 17 +
 sound/soc/samsung/s3c2412-i2s.c | 47 +-
 sound/soc/samsung/s3c24xx-i2s.c | 56 +++--
 5 files changed, 56 insertions(+), 76 deletions(-)

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 753b8c9..98767d3 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,11 +1,10 @@
 config SND_SOC_SAMSUNG
tristate ASoC support for Samsung
depends on PLAT_SAMSUNG
-   select S3C2410_DMA if ARCH_S3C24XX
+   select S3C24XX_DMAC if ARCH_S3C24XX
select S3C64XX_PL080 if ARCH_S3C64XX
-   select SND_S3C_DMA if !ARCH_S3C24XX
-   select SND_S3C_DMA_LEGACY if ARCH_S3C24XX
-   select SND_SOC_GENERIC_DMAENGINE_PCM if !ARCH_S3C24XX
+   select SND_S3C_DMA
+   select SND_SOC_GENERIC_DMAENGINE_PCM
help
  Say Y or M if you want to add support for codecs attached to
  the Samsung SoCs' Audio interfaces. You will also need to
@@ -19,7 +18,6 @@ config SND_S3C_DMA_LEGACY
 
 config SND_S3C24XX_I2S
tristate
-   select S3C24XX_DMA
 
 config SND_S3C_I2SV2_SOC
tristate
@@ -27,7 +25,6 @@ config SND_S3C_I2SV2_SOC
 config SND_S3C2412_SOC_I2S
tristate
select SND_S3C_I2SV2_SOC
-   select S3C2410_DMA
 
 config SND_SAMSUNG_PCM
tristate
diff --git a/sound/soc/samsung/dmaengine.c b/sound/soc/samsung/dmaengine.c
index a0e4e79..506f5bf 100644
--- a/sound/soc/samsung/dmaengine.c
+++ b/sound/soc/samsung/dmaengine.c
@@ -17,6 +17,7 @@
 
 #include linux/module.h
 #include linux/amba/pl08x.h
+#include linux/platform_data/dma-s3c24xx.h
 
 #include sound/core.h
 #include sound/pcm.h
@@ -29,6 +30,8 @@
 
 #ifdef CONFIG_ARCH_S3C64XX
 #define filter_fn pl08x_filter_id
+#elif defined(CONFIG_ARCH_S3C24XX)
+#define filter_fn s3c24xx_dma_filter
 #else
 #define filter_fn NULL
 #endif
diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 0ff4bbe..de6c321 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -392,8 +392,6 @@ static int s3c2412_i2s_trigger(struct snd_pcm_substream 
*substream, int cmd,
int capture = (substream-stream == SNDRV_PCM_STREAM_CAPTURE);
unsigned long irqs;
int ret = 0;
-   struct s3c_dma_params *dma_data =
-   snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
 
pr_debug(Entered %s\n, __func__);
 
@@ -424,13 +422,6 @@ static int s3c2412_i2s_trigger(struct snd_pcm_substream 
*substream, int cmd,
 
local_irq_restore(irqs);
 
-   /*
-* Load the next buffer to DMA to meet the reqirement
-* of the auto reload mechanism of S3C24XX.
-* This call won't bother S3C64XX.
-*/
-   s3c2410_dma_ctrl(dma_data-channel, S3C2410_DMAOP_STARTED);
-
break;
 
case SNDRV_PCM_TRIGGER_STOP:
@@ -644,12 +635,6 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
/* record our i2s structure for later use in the callbacks */
snd_soc_dai_set_drvdata(dai, i2s);
 
-   i2s-regs = ioremap(base, 0x100);
-   if (i2s-regs == NULL) {
-   dev_err(dev, cannot ioremap registers\n);
-   return -ENXIO;
-   }
-
i2s-iis_pclk = clk_get(dev, iis);
if (IS_ERR(i2s-iis_pclk)) {
dev_err(dev, failed to get iis_clock\n);
@@ -729,7 +714,7 @@ int s3c_i2sv2_register_component(struct device *dev, int id,
   struct snd_soc_component_driver *cmp_drv,
   struct snd_soc_dai_driver *dai_drv)
 {
-   struct snd_soc_dai_ops *ops = dai_drv-ops;
+   struct snd_soc_dai_ops *ops = (struct snd_soc_dai_ops *)dai_drv-ops;
 
ops-trigger = s3c2412_i2s_trigger;
if (!ops-hw_params)
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 08c059b..d9d27cc 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -33,25 +33,19 @@
 #include regs-i2s-v2.h
 #include s3c2412-i2s.h
 
-static struct s3c_dma_client s3c2412_dma_client_out = {
-   .name   = I2S PCM Stereo out
-};
-
-static struct s3c_dma_client s3c2412_dma_client_in = {
-   .name   = I2S PCM Stereo in
-};
-
 static struct s3c_dma_params s3c2412_i2s_pcm_stereo_out = {
-   .client = s3c2412_dma_client_out,
+   .client =
+   (struct s3c_dma_client *)s3c2412_i2s_pcm_stereo_out,
.channel= DMACH_I2S_OUT,
-   .dma_addr   = S3C2410_PA_IIS + S3C2412_IISTXD,
+   .ch_name= tx,
.dma_size   = 4,
 };
 
 static struct s3c_dma_params

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

This series updates s3c24{xx,12}-i2s driver to use newer DMA and CLK APIs.

v2: use hardcoded dma channel number
v3: rebase onto v3.16-rc1, add common clk framework-related changes

Vasily Khoruzhick (4):
  ASoC: samsung: s3c24{xx,12}-i2s: port to use generic dmaengine API
  ASoC: samsung: drop support for legacy S3C24XX DMA API
  ASoC: samsung: s3c2412-i2s: Move to
clk_prepare_enable/clk_disable_unprepare
  ASoC: samsung: s3c24xx-i2s: Move to
clk_prepare_enable/clk_disable_unprepare

 sound/soc/samsung/Kconfig   |  12 +-
 sound/soc/samsung/Makefile  |   2 -
 sound/soc/samsung/dma.c | 454 
 sound/soc/samsung/dmaengine.c   |   3 +
 sound/soc/samsung/s3c-i2s-v2.c  |  17 +-
 sound/soc/samsung/s3c2412-i2s.c |  51 +++--
 sound/soc/samsung/s3c24xx-i2s.c |  62 +++---
 7 files changed, 61 insertions(+), 540 deletions(-)
 delete mode 100644 sound/soc/samsung/dma.c

-- 
2.0.0

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

[PATCH 1/2] clk: samsung: fix several typos to fix boot on s3c2410

There's a several typos in a driver: 2410 instead of S3C2410
and wrong argument to ARRAY_SIZE(). They prevent s3c2410
from properly booting.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 drivers/clk/samsung/clk-s3c2410.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-s3c2410.c 
b/drivers/clk/samsung/clk-s3c2410.c
index ba07168..bd9a873 100644
--- a/drivers/clk/samsung/clk-s3c2410.c
+++ b/drivers/clk/samsung/clk-s3c2410.c
@@ -378,7 +378,7 @@ void __init s3c2410_common_clk_init(struct device_node *np, 
unsigned long xti_f,
if (!np)
s3c2410_common_clk_register_fixed_ext(ctx, xti_f);
 
-   if (current_soc == 2410) {
+   if (current_soc == S3C2410) {
if (_get_rate(xti) == 12 * MHZ) {
s3c2410_plls[mpll].rate_table = pll_s3c2410_12mhz_tbl;
s3c2410_plls[upll].rate_table = pll_s3c2410_12mhz_tbl;
@@ -432,7 +432,7 @@ void __init s3c2410_common_clk_init(struct device_node *np, 
unsigned long xti_f,
samsung_clk_register_fixed_factor(ctx, s3c2410_ffactor,
ARRAY_SIZE(s3c2410_ffactor));
samsung_clk_register_alias(ctx, s3c2410_aliases,
-   ARRAY_SIZE(s3c2410_common_aliases));
+   ARRAY_SIZE(s3c2410_aliases));
break;
case S3C2440:
samsung_clk_register_mux(ctx, s3c2440_muxes,
-- 
2.0.0

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

[PATCH 2/2] clk: samsung: add more aliases for s3c24xx

Without these aliases clock lookup fails in s3c2410fb,
s3cmci, s3c2410-nand, s3c24xx-i2s, and i2c-s3c2410 drivers.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
 drivers/clk/samsung/clk-s3c2410.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/samsung/clk-s3c2410.c 
b/drivers/clk/samsung/clk-s3c2410.c
index bd9a873..140f473 100644
--- a/drivers/clk/samsung/clk-s3c2410.c
+++ b/drivers/clk/samsung/clk-s3c2410.c
@@ -152,6 +152,11 @@ struct samsung_clock_alias s3c2410_common_aliases[] 
__initdata = {
ALIAS(HCLK, NULL, hclk),
ALIAS(MPLL, NULL, mpll),
ALIAS(FCLK, NULL, fclk),
+   ALIAS(PCLK, NULL, watchdog),
+   ALIAS(PCLK_SDI, NULL, sdi),
+   ALIAS(HCLK_NAND, NULL, nand),
+   ALIAS(PCLK_I2S, NULL, iis),
+   ALIAS(PCLK_I2C, NULL, i2c),
 };
 
 /* S3C2410 specific clocks */
-- 
2.0.0

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

[PATCH v2] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

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
  https://patchwork.kernel.org/patch/4346701/ and
  https://patchwork.kernel.org/patch/4346711/

Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
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
@@ -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;
+   vsys2-supply = vbat;
+   vsys3-supply = vbat;
+   infet1-supply = vbat;
+

Re: [PATCH 1/2] clk: samsung: fix several typos to fix boot on s3c2410

2014-06-23 Thread Heiko Stübner

Am Montag, 23. Juni 2014, 23:29:09 schrieb Vasily Khoruzhick:
 There's a several typos in a driver: 2410 instead of S3C2410
 and wrong argument to ARRAY_SIZE(). They prevent s3c2410
 from properly booting.
 
 Signed-off-by: Vasily Khoruzhick anars...@gmail.com

Thanks for catching these.
Reviewed-by: Heiko Stuebner he...@sntech.de

 ---
  drivers/clk/samsung/clk-s3c2410.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/clk/samsung/clk-s3c2410.c
 b/drivers/clk/samsung/clk-s3c2410.c index ba07168..bd9a873 100644
 --- a/drivers/clk/samsung/clk-s3c2410.c
 +++ b/drivers/clk/samsung/clk-s3c2410.c
 @@ -378,7 +378,7 @@ void __init s3c2410_common_clk_init(struct device_node
 *np, unsigned long xti_f, if (!np)
   s3c2410_common_clk_register_fixed_ext(ctx, xti_f);
 
 - if (current_soc == 2410) {
 + if (current_soc == S3C2410) {
   if (_get_rate(xti) == 12 * MHZ) {
   s3c2410_plls[mpll].rate_table = pll_s3c2410_12mhz_tbl;
   s3c2410_plls[upll].rate_table = pll_s3c2410_12mhz_tbl;
 @@ -432,7 +432,7 @@ void __init s3c2410_common_clk_init(struct device_node
 *np, unsigned long xti_f, samsung_clk_register_fixed_factor(ctx,
 s3c2410_ffactor,
   ARRAY_SIZE(s3c2410_ffactor));
   samsung_clk_register_alias(ctx, s3c2410_aliases,
 - ARRAY_SIZE(s3c2410_common_aliases));
 + ARRAY_SIZE(s3c2410_aliases));
   break;
   case S3C2440:
   samsung_clk_register_mux(ctx, s3c2440_muxes,

--
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/2] clk: samsung: add more aliases for s3c24xx

2014-06-23 Thread Heiko Stübner

Am Montag, 23. Juni 2014, 23:29:10 schrieb Vasily Khoruzhick:
 Without these aliases clock lookup fails in s3c2410fb,
 s3cmci, s3c2410-nand, s3c24xx-i2s, and i2c-s3c2410 drivers.
 
 Signed-off-by: Vasily Khoruzhick anars...@gmail.com
Reviewed-by: Heiko Stuebner he...@sntech.de

 ---
  drivers/clk/samsung/clk-s3c2410.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/clk/samsung/clk-s3c2410.c
 b/drivers/clk/samsung/clk-s3c2410.c index bd9a873..140f473 100644
 --- a/drivers/clk/samsung/clk-s3c2410.c
 +++ b/drivers/clk/samsung/clk-s3c2410.c
 @@ -152,6 +152,11 @@ struct samsung_clock_alias s3c2410_common_aliases[]
 __initdata = { ALIAS(HCLK, NULL, hclk),
   ALIAS(MPLL, NULL, mpll),
   ALIAS(FCLK, NULL, fclk),
 + ALIAS(PCLK, NULL, watchdog),
 + ALIAS(PCLK_SDI, NULL, sdi),
 + ALIAS(HCLK_NAND, NULL, nand),
 + ALIAS(PCLK_I2S, NULL, iis),
 + ALIAS(PCLK_I2C, NULL, i2c),
  };
 
  /* S3C2410 specific clocks */

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

2014-06-23 Thread Andreas Färber

Am 23.06.2014 22:11, schrieb Benson Leung:
 On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson diand...@chromium.org wrote:
 Also when the screen stayed on, the embedded controller's keymap seems
 hardcoded to US English with system settings not taking effect; but
 surely we don't want per-keyboard device tree files to remedy that.

 +Benson may be able to answer this.  I believe generally non-US
 keyboard layouts are handled at a higher level.
 
 There's no such thing as a notion of US versus non-US keyboard layouts
 at the embedded controller level or even in the kernel. Indeed, this
 should all be handled in user space.
 
 The chromeos firmware and kernel should return the correct key codes
 for every key pressed on keyboards with the ANSI layout (US based), or
 ISO (UK and most other countries).
 
 The only differences are :
 * the ISO keyboard has an extra key, which is immediately to the right
 of the Left Shift key. This must return KEY_102ND key code from the
 input layer.
 * the ISO keyboard has a  different location for the | \ key, which
 accomodates the upside L shaped Enter key on the right side of the
 keyboard. The keycode for this key is KEY_BACKSLASH.
 
 Basically, all of this should be verified using evtest to test that
 the ec and kernel have the keys right.

Hm, we may be talking about two different things here? I have been doing
a minimum system bring-up for 3.16, with openSUSE userspace.
My YaST-selected system keymap (German with deadkeys) is not taking
effect on German Spring at the *framebuffer console* (tty1) - evdev is
not involved at that level AIUI.

Backspace and L-shaped enter keys work okay. The keymap here should be
identical to that in the original German device and seemed to match that
in the exynos5250-snow.dts file.

I just checked (w/ dp-controller, hdmi, fimd commented out in my patch):
* An external USB keyboard does not work correctly either.
* In X11 (xdm), both internal and USB keyboard work as expected.

Similar situation in ChromeOS IIRC, with keymap correct at graphical
login but not on the right-arrow console - although I don't know the
ChromeOS userland too well to judge if it was configured correctly.

 If you are having other problems with keyboard layout being stuck to
 US QWERTY, please check your user space.

On my Raspberry Pi for instance, the equivalent openSUSE Factory works
just fine with German keymap for USB keyboard. Might any related kernel
config options be missing in exynos_defconfig? Anything in particular I
should check in user space?

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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Tomasz,

On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 21.06.2014 01:53, Doug Anderson wrote:
 Kevin,

 On Fri, Jun 20, 2014 at 4:13 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 Kevin,

 On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote:
 Hi Doug,

 Doug Anderson diand...@chromium.org writes:

 On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org 
 wrote:
 Doug Anderson diand...@chromium.org writes:

 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.

 I suspect usage of the noirq variants pre-dates the existence of the
 late/early callbacks in the PM core, but based on the description above,
 I suspect what you actually want is the late/early callbacks.

 I think it actually really needs noirq.  ;)

 Yes, it appears it does.   Objection withdrawn.

 I just wanted to be sure because since the introduction of late/early,
 the need for noirq should be pretty rare, but there certainly are needs.

 tangent
 In this case though, the need for it has more to do with the
 lack of a way for us to describe non parent-child device dependencies
 than whether or not IRQs are enabled or not.
 /tangent

 Actually, I'm not sure that's true, but I'll talk through it and you
 can point to where I'm wrong (I often am!)

 If you're a wakeup device then you need to be ready to handle
 interrupts as soon as the noirq phase of resume is done, right?

 As soon as the noirq phase of your own driver is done, correct.

 Said another way: you need to be ready to handle interrupts _before_
 the normal resume code is called and be ready to handle interrupts
 even _before_ the early resume code is called.

 Correct.

 That means if you are implementing a bus that's needed by any devices
 with wakeup interrupts then it's your responsibility to also be
 prepared to run this early.

 In this particular case the max77686 driver doesn't need to do
 anything at all to be ready to handle interrupts.  It's suspend and
 resume code is just boilerplate enable wakeups / disable wakeups and
 it has no noirq code.  The max77686 driver doesn't have any noirq
 wake call because it would just be empty.

 Said another way: the problem isn't that the max77686 wakeup gets
 called before the i2c wakeup.  The problem is that i2c is needed ASAP
 once IRQs are enabled and thus needs to be run noirq.

 Does that sound semi-correct?

 Yes that's correct.

 My point above was (trying to be) that ultimately this is an ordering
 issue.  e.g. the bus device needs to be ready before wakeup devices on
 that bus can handle wakeup interrupts etc.  The way we're handling that
 ordering is by the implied ordering of noirq, late/early and normal
 callbacks.  That's convenient, but not exactly obvious.

 It works because we dont' typically need too many layers here, but it
 would be much more understandable if we could describe this kind of
 dependency in a way that the suspend/resume code would suspend/resume
 things in the right order rather than by tinkering with callback levels
 (since otherwise suspend/resume ordering just depends on probe order.)

 This issue then usually gets me headed down my usual rant path about how
 I think runtime PM is much better suited for handling ordering and
 dependencies becuase it automatically handles parent/child dependencies
 and non parent/child dependencies can be handled by taking advantage of
 the get/put APIs which are refcounted, ect etc. but that's another can
 worms.

 Ah, I gotcha.  Yes, I'm a fan of having explicit dependency orderings too.

 So I guess in this case the truly correct way to handle it is:

 1. i2c controller should have Runtime PM even though (as per the code
 now) there's nothing you can do to it to save power under normal
 circumstances.  So the runtime suspend code would be a no-op.

 2. When the i2c controller is told to runtime resume, it should
 double-check if a full SoC poweroff has happened since the last time
 it checked.  In this case it should reinit its hardware.

 3. If the i2c controller gets a full resume callback then it should
 also reinit the hardware just so it's not sitting in a half-configured
 state until the first peripheral uses it.

 If later someone finds a way to power gate the i2c controller when no
 active transfers are going (and we actually save non-trivial power
 doing this) then we've got a nice place to put that code.

 NOTE: Unless we can actually save power by power gating the i2c
 peripheral when there are no active transfers, we

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Doug Anderson diand...@chromium.org writes:

[...]

 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)

The reason is because noirq in the suspend/resume path actually means
no *device* IRQs for that specific device.

It's often assumed that the noirq callbacks are called with *all*
interrupts disabled, but that's not the case.  Only the IRQs for that
specific device are disabled when its noirq callbacks run.

Kevin
--
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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Doug Anderson diand...@chromium.org writes:

 Kevin,

 On Fri, Jun 20, 2014 at 4:13 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 Kevin,

 On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote:
 Hi Doug,

 Doug Anderson diand...@chromium.org writes:

 On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 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.

 I suspect usage of the noirq variants pre-dates the existence of the
 late/early callbacks in the PM core, but based on the description above,
 I suspect what you actually want is the late/early callbacks.

 I think it actually really needs noirq.  ;)

 Yes, it appears it does.   Objection withdrawn.

 I just wanted to be sure because since the introduction of late/early,
 the need for noirq should be pretty rare, but there certainly are needs.

 tangent
 In this case though, the need for it has more to do with the
 lack of a way for us to describe non parent-child device dependencies
 than whether or not IRQs are enabled or not.
 /tangent

 Actually, I'm not sure that's true, but I'll talk through it and you
 can point to where I'm wrong (I often am!)

 If you're a wakeup device then you need to be ready to handle
 interrupts as soon as the noirq phase of resume is done, right?

 As soon as the noirq phase of your own driver is done, correct.

 Said another way: you need to be ready to handle interrupts _before_
 the normal resume code is called and be ready to handle interrupts
 even _before_ the early resume code is called.

 Correct.

 That means if you are implementing a bus that's needed by any devices
 with wakeup interrupts then it's your responsibility to also be
 prepared to run this early.

 In this particular case the max77686 driver doesn't need to do
 anything at all to be ready to handle interrupts.  It's suspend and
 resume code is just boilerplate enable wakeups / disable wakeups and
 it has no noirq code.  The max77686 driver doesn't have any noirq
 wake call because it would just be empty.

 Said another way: the problem isn't that the max77686 wakeup gets
 called before the i2c wakeup.  The problem is that i2c is needed ASAP
 once IRQs are enabled and thus needs to be run noirq.

 Does that sound semi-correct?

 Yes that's correct.

 My point above was (trying to be) that ultimately this is an ordering
 issue.  e.g. the bus device needs to be ready before wakeup devices on
 that bus can handle wakeup interrupts etc.  The way we're handling that
 ordering is by the implied ordering of noirq, late/early and normal
 callbacks.  That's convenient, but not exactly obvious.

 It works because we dont' typically need too many layers here, but it
 would be much more understandable if we could describe this kind of
 dependency in a way that the suspend/resume code would suspend/resume
 things in the right order rather than by tinkering with callback levels
 (since otherwise suspend/resume ordering just depends on probe order.)

 This issue then usually gets me headed down my usual rant path about how
 I think runtime PM is much better suited for handling ordering and
 dependencies becuase it automatically handles parent/child dependencies
 and non parent/child dependencies can be handled by taking advantage of
 the get/put APIs which are refcounted, ect etc. but that's another can
 worms.

 Ah, I gotcha.  Yes, I'm a fan of having explicit dependency orderings too.

 So I guess in this case the truly correct way to handle it is:

 1. i2c controller should have Runtime PM even though (as per the code
 now) there's nothing you can do to it to save power under normal
 circumstances.  So the runtime suspend code would be a no-op.

 2. When the i2c controller is told to runtime resume, it should
 double-check if a full SoC poweroff has happened since the last time
 it checked.  In this case it should reinit its hardware.

 3. If the i2c controller gets a full resume callback then it should
 also reinit the hardware just so it's not sitting in a half-configured
 state until the first peripheral uses it.

 If later someone finds a way to power gate the i2c controller when no
 active transfers are going (and we actually save non-trivial power
 doing this) then we've got a nice place to put that code.

 NOTE: Unless we can actually save power by power gating the i2c
 peripheral when there are no active transfers, we would also just have
 the i2c_xfer() init the hardware if needed.  Maybe that's kinda

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

2014-06-23 Thread Tomasz Figa

On 24.06.2014 00:19, Kevin Hilman wrote:
 Doug Anderson diand...@chromium.org writes:
 
 [...]
 
 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)
 
 The reason is because noirq in the suspend/resume path actually means
 no *device* IRQs for that specific device.
 
 It's often assumed that the noirq callbacks are called with *all*
 interrupts disabled, but that's not the case.  Only the IRQs for that
 specific device are disabled when its noirq callbacks run.

Thanks for clarifying this. This means that we should be fine with the
noirq variant then.

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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Kevin,

On Mon, Jun 23, 2014 at 3:19 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 [...]

 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)

 The reason is because noirq in the suspend/resume path actually means
 no *device* IRQs for that specific device.

 It's often assumed that the noirq callbacks are called with *all*
 interrupts disabled, but that's not the case.  Only the IRQs for that
 specific device are disabled when its noirq callbacks run.

Ah, so even with my fix of moving to noirq we could still be broken if
the system decided to enable interrupts for the device before the i2c
controller get resumed then we'd still be SOL.

...oh, but if it matches probe order then maybe we're guaranteed for
that not to happen?  We know that we will probe the i2c bus before the
devices on it, right?

-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] i2c: exynos5: Properly use the noirq variants of suspend/resume

2014-06-23 Thread Tomasz Figa



On 24.06.2014 00:27, Doug Anderson wrote:
 Kevin,
 
 On Mon, Jun 23, 2014 at 3:19 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 [...]

 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine 
 because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)

 The reason is because noirq in the suspend/resume path actually means
 no *device* IRQs for that specific device.

 It's often assumed that the noirq callbacks are called with *all*
 interrupts disabled, but that's not the case.  Only the IRQs for that
 specific device are disabled when its noirq callbacks run.
 
 Ah, so even with my fix of moving to noirq we could still be broken if
 the system decided to enable interrupts for the device before the i2c
 controller get resumed then we'd still be SOL.
 
 ...oh, but if it matches probe order then maybe we're guaranteed for
 that not to happen?  We know that we will probe the i2c bus before the
 devices on it, right?

If the mentioned device is a child of the I2C controller then the
parent-child relation determines the order. Otherwise (e.g. another,
non-I2C interrupt source that just triggers some operation on an I2C
device like voltage regulator) we're doomed. ;)

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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Kevin,

On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman khil...@linaro.org wrote:
 So I guess in this case the truly correct way to handle it is:

 1. i2c controller should have Runtime PM even though (as per the code
 now) there's nothing you can do to it to save power under normal
 circumstances.  So the runtime suspend code would be a no-op.

 2. When the i2c controller is told to runtime resume, it should
 double-check if a full SoC poweroff has happened since the last time
 it checked.  In this case it should reinit its hardware.

 3. If the i2c controller gets a full resume callback then it should
 also reinit the hardware just so it's not sitting in a half-configured
 state until the first peripheral uses it.

 If later someone finds a way to power gate the i2c controller when no
 active transfers are going (and we actually save non-trivial power
 doing this) then we've got a nice place to put that code.

 NOTE: Unless we can actually save power by power gating the i2c
 peripheral when there are no active transfers, we would also just have
 the i2c_xfer() init the hardware if needed.  Maybe that's kinda gross,
 though.

 Yes, this is how we manage the i2c controller on OMAP.

 Essentially, between every xfer, the hw is disabled and can potentially
 lose context, so eveery xfer requires a hw init.  We use the runtime PM
 autosuspend feature so that it stays alive for X milliseconds so
 bursty i2c xfers are not punished.

 Have a look at drivers/i2c/busses/i2c-omap.c.

 You'll notice there are not callbacks for system suspend/resume, it's
 only doing runtime PM.

OK, cool!  That might be a bit too aggressive of a change for what I
can take on right now.  I've filed http://crbug.com/388007 to see if
Samsung can take a look at this.

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

2014-06-23 Thread Andreas Färber

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 afaer...@suse.de 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.

 +   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. However it's the
equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?

 +   };
 +
 +   vbat: vbat-fixed-regulator {
 +   compatible = regulator-fixed;
 +   regulator-name = vbat-supply;
 +   regulator-boot-on;
 +   };
 +
 +   usb@1200 {
 +   status = okay;
 +   };
 +
 +   usb3_vbus_reg: regulator-usb3 {
 +   compatible = regulator-fixed;
 +   regulator-name = P5.0V_USB3CON;
 +   regulator-min-microvolt = 500;
 +   regulator-max-microvolt = 500;
 +   gpio = gpe1 0 1;
 +   pinctrl-names = default;
 +   pinctrl-0 = hsic_reset;
 +   enable-active-high;
 +   };
 +
 +   phy@1210 {
 +   vbus-supply = usb3_vbus_reg;
 +   };
 +
 +   usb@1211 {
 +   samsung,vbus-gpio = gpx1 1 0;
 +   status = okay;
 +   };
 +
 +

Re: [PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

Tomasz,

On Mon, Jun 23, 2014 at 3:31 PM, Tomasz Figa tomasz.f...@gmail.com wrote:


 On 24.06.2014 00:27, Doug Anderson wrote:
 Kevin,

 On Mon, Jun 23, 2014 at 3:19 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 [...]

 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine 
 because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)

 The reason is because noirq in the suspend/resume path actually means
 no *device* IRQs for that specific device.

 It's often assumed that the noirq callbacks are called with *all*
 interrupts disabled, but that's not the case.  Only the IRQs for that
 specific device are disabled when its noirq callbacks run.

 Ah, so even with my fix of moving to noirq we could still be broken if
 the system decided to enable interrupts for the device before the i2c
 controller get resumed then we'd still be SOL.

 ...oh, but if it matches probe order then maybe we're guaranteed for
 that not to happen?  We know that we will probe the i2c bus before the
 devices on it, right?

 If the mentioned device is a child of the I2C controller then the
 parent-child relation determines the order. Otherwise (e.g. another,
 non-I2C interrupt source that just triggers some operation on an I2C
 device like voltage regulator) we're doomed. ;)

Wow, that would be seriously screwed up.

OK, so to summarize my current plans: I won't spin this patch and we
can see what Wolfram thinks.  It may not be as beautiful as Kevin's
suggestion to use Runtime PM but I also don't think it's insane.
...and I've got a request in to Samsung to use Runtime PM in the long
run.

If anyone at Samsung working on suspend/resume on exynos5420-pit or
exynos5800-pi wants to add their Tested-by (or bug reports) I'm sure
that would be appreciated.

-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/4] Documentation: devicetree: Fix s2mps11 and s5m8767 typos

2014-06-23 Thread Andreas Färber

Am 23.06.2014 05:21, schrieb Sachin Kamat:
 On Mon, Jun 23, 2014 at 6:51 AM, Andreas Färber afaer...@suse.de wrote:
 It's LDO2, not LD02.

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +-
  Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
 b/Documentation/devicetree/bindings/mfd/s2mps11.txt
 index d81ba30..55ab4f4 100644
 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
 +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
 @@ -81,7 +81,7 @@ as per the datasheet of s2mps11.
   - valid values for n are:
 - S2MPS11: 1 to 38
 - S2MPS14: 1 to 25
 - - Example: LDO1, LD02, LDO28
 + - Example: LDO1, LDO2, LDO28
 - BUCKn
   - valid values for n are:
 - S2MPS11: 1 to 10
 diff --git 
 a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
 b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
 index d290988..2019131 100644
 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
 +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
 @@ -86,7 +86,7 @@ as per the datasheet of s5m8767.

 - LDOn
   - valid values for n are 1 to 28
 - - Example: LDO1, LD02, LDO28
 + - Example: LDO1, LDO2, LDO28
 - BUCKn
   - valid values for n are 1 to 9.
   - Example: BUCK1, BUCK2, BUCK9
 --
 
 Very keen observation :)
 
 Reviewed-by: Sachin Kamat sachin.ka...@samsung.com

A font that distinguishes the zero with a dot or dash helps! :)

I was wondering which character to type, and found two undocumented
s5m8767_pmic properties downstream (s5m-core,enable-low-jitter and
s5m-core,device_type = 0x2), which I then left out.

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 1/4] Documentation: devicetree: Fix s2mps11 and s5m8767 typos

Andreas,

On Mon, Jun 23, 2014 at 4:06 PM, Andreas Färber afaer...@suse.de wrote:
 I was wondering which character to type, and found two undocumented
 s5m8767_pmic properties downstream (s5m-core,enable-low-jitter and
 s5m-core,device_type = 0x2), which I then left out.

I don't know much about s5m-core,device_type, but I doubt it's
needed.  You can see http://crosreview.com/42202 for details.  I
haven't looked but I'd bet that we just get this from the compatible
string now.

I did do a (very!) quick look and I see that low-jitter was originally
implemented in the local 3.4 kernel at http://crosreview.com/43624.
...and the local 3.8 kernel at http://crosreview.com/66037.

NOTE: it's pretty important to make sure low-jitter is turned on for
Chromebooks if you actually want full functionality.  At least on
exynos5250-snow (with the max77686 PMIC) you'd get occasional (and
very strange and very hard to debug) TPM errors if you didn't have
low-jitter.  The TPM is part of the security model on Chromebooks and
you might have a hard time accessing the encrypted parts of the disk
without 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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Doug Anderson diand...@chromium.org writes:

 Kevin,

 On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman khil...@linaro.org wrote:
 So I guess in this case the truly correct way to handle it is:

 1. i2c controller should have Runtime PM even though (as per the code
 now) there's nothing you can do to it to save power under normal
 circumstances.  So the runtime suspend code would be a no-op.

 2. When the i2c controller is told to runtime resume, it should
 double-check if a full SoC poweroff has happened since the last time
 it checked.  In this case it should reinit its hardware.

 3. If the i2c controller gets a full resume callback then it should
 also reinit the hardware just so it's not sitting in a half-configured
 state until the first peripheral uses it.

 If later someone finds a way to power gate the i2c controller when no
 active transfers are going (and we actually save non-trivial power
 doing this) then we've got a nice place to put that code.

 NOTE: Unless we can actually save power by power gating the i2c
 peripheral when there are no active transfers, we would also just have
 the i2c_xfer() init the hardware if needed.  Maybe that's kinda gross,
 though.

 Yes, this is how we manage the i2c controller on OMAP.

 Essentially, between every xfer, the hw is disabled and can potentially
 lose context, so eveery xfer requires a hw init.  We use the runtime PM
 autosuspend feature so that it stays alive for X milliseconds so
 bursty i2c xfers are not punished.

 Have a look at drivers/i2c/busses/i2c-omap.c.

 You'll notice there are not callbacks for system suspend/resume, it's
 only doing runtime PM.

 OK, cool!  That might be a bit too aggressive of a change for what I
 can take on right now.  I've filed http://crbug.com/388007 to see if
 Samsung can take a look at this.

Sure.  While I think moving to runtime PM is the right thing to do, that
alone shouldn't block this patch.

Kevin
--
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] i2c: exynos5: Properly use the noirq variants of suspend/resume

Tomasz Figa tomasz.f...@gmail.com writes:

 On 24.06.2014 00:27, Doug Anderson wrote:
 Kevin,
 
 On Mon, Jun 23, 2014 at 3:19 PM, Kevin Hilman khil...@linaro.org wrote:
 Doug Anderson diand...@chromium.org writes:

 [...]

 On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I'm not sure noirq is going to work correctly, at least not with current
 callbacks. I can see a call to clk_prepare_enable() there which needs to
 acquire a mutex.

 Nice catch, thanks!  :)

 OK, looking at that now.  Interestingly this doesn't seem to cause us
 problems in our ChromeOS 3.8 tree.  I just tried enabling:
   CONFIG_DEBUG_ATOMIC_SLEEP=y

 ...and confirmed that I got it on right:

 # zgrep -i atomic /proc/config.gz
 CONFIG_DEBUG_ATOMIC_SLEEP=y

 I can suspend/resume with no problems.  My bet is that it works fine 
 because:

 * resume_noirq is not considered atomic in the sense enforced by
 CONFIG_DEBUG_ATOMIC_SLEEP (at least not in 3.8--I haven't tried on
 ToT)

 The reason is because noirq in the suspend/resume path actually means
 no *device* IRQs for that specific device.

 It's often assumed that the noirq callbacks are called with *all*
 interrupts disabled, but that's not the case.  Only the IRQs for that
 specific device are disabled when its noirq callbacks run.
 
 Ah, so even with my fix of moving to noirq we could still be broken if
 the system decided to enable interrupts for the device before the i2c
 controller get resumed then we'd still be SOL.
 
 ...oh, but if it matches probe order then maybe we're guaranteed for
 that not to happen?  We know that we will probe the i2c bus before the
 devices on it, right?

 If the mentioned device is a child of the I2C controller then the
 parent-child relation determines the order. Otherwise (e.g. another,
 non-I2C interrupt source that just triggers some operation on an I2C
 device like voltage regulator) we're doomed. ;)

Exactly.  There are lots of dragons hiding here.   

Runtime PM is your friend. ;)

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

Using s5p-sss hw crypto causes ipsec to break

2014-06-23 Thread Sonny Rao

Hi, I've been investigating an issue relating to hardware crypto which
is that when I enable the s5p-sss module for hardware cryptographic
acceleration on Samsung Exynos SoCs the in-kernel IPSec seems to
break, although cryptographic operations on filesystems/block devices
using this driver seem to work fine.

Originally we were looking at an older kernel (3.8 with patches), but
I've now verified on linux-next from 20140612 (after 3.15) with a few
additional patches (to enable both s5p-sss and Exynos5420) that this
is still the case.

It looks like what is happening in the kernel is that IPsec ends up
with this callstack

esp_output()- crypto_aead_givencrypt()-
crypto_authenc_givencrypt()- eseqiv_givencrypt() -
crypto_ablkcipher_encrypt()


which calls into the s5p-sss driver and that is returning -EINPROGRESS
(or possibly -EBUSY), and that is passed all the way back up the call
stack and that seems to be treated as an error condition by the ipsec
stack.

For example esp_output does this:

   err = crypto_aead_givencrypt(req);
if (err == -EINPROGRESS)
goto error;

if (err == -EBUSY)
err = NET_XMIT_DROP;

So, I'm not sure how this is supposed to work, or if s5p-sss is doing
something wrong.

In the case of the block layer, it seems to be tolerant of the
-EINPROGRESS return code.  I looked at some of the other hw crypto
drivers which are similar to s5p-sss and they also seem to return
-EINPROGRESS or -EBUSY in a similar way.

I was also wondering if esp shouldn't be using the ablkcipher
interface if it isn't tolerant of the -EINPROGRESS?
--
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: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC

2014-06-23 Thread Chanwoo Choi

Hi Tomasz,

On 06/20/2014 12:21 PM, Naveen Krishna Ch wrote:
 Hello Tomasz,
 
 On 20 June 2014 06:00, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 20.06.2014 02:28, Chanwoo Choi wrote:
 On 06/20/2014 09:24 AM, Tomasz Figa wrote:
 On 20.06.2014 02:22, Chanwoo Choi wrote:
 Hi Tomasz,

 On 06/18/2014 04:58 PM, Tomasz Figa wrote:
 Hi Chanwoo,

 On 18.06.2014 04:20, Chanwoo Choi wrote:
 This patch control special clock for ADC in Exynos series's FSYS block.
 If special clock of ADC is registerd on clock list of common clk 
 framework,
 Exynos ADC drvier have to control this clock.

 Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
 - 'adc' clock: bus clock for ADC

 Exynos3250 has additional 'sclk_adc' clock as following:
 - 'sclk_adc' clock: special clock for ADC which provide clock to 
 internal ADC

 Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' 
 clock
 in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 
 'sclk_adc'
 clock in FSYS_BLK.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/iio/adc/exynos_adc.c | 93 
 ++--
  1 file changed, 81 insertions(+), 12 deletions(-)

 diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
 index c30def6..6b026ac 100644
 --- a/drivers/iio/adc/exynos_adc.c
 +++ b/drivers/iio/adc/exynos_adc.c
 @@ -41,7 +41,8 @@

  enum adc_version {
   ADC_V1,
 - ADC_V2
 + ADC_V2,
 + ADC_V2_EXYNOS3250,
  };

  /* EXYNOS4412/5250 ADC_V1 registers definitions */
 @@ -85,9 +86,11 @@ enum adc_version {
  #define EXYNOS_ADC_TIMEOUT   (msecs_to_jiffies(100))

  struct exynos_adc {
 + struct device   *dev;
   void __iomem*regs;
   void __iomem*enable_reg;
   struct clk  *clk;
 + struct clk  *sclk;
   unsigned intirq;
   struct regulator*vdd;
   struct exynos_adc_ops   *ops;
 @@ -96,6 +99,7 @@ struct exynos_adc {

   u32 value;
   unsigned intversion;
 + boolneeds_sclk;

 This should be rather a part of the variant struct. See my comments to
 patch 1/4.

 OK, I'll include 'needs_sclk' in variant structure.


  };

  struct exynos_adc_ops {
 @@ -103,11 +107,21 @@ struct exynos_adc_ops {
   void (*clear_irq)(struct exynos_adc *info);
   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
   void (*stop_conv)(struct exynos_adc *info);
 + void (*disable_clk)(struct exynos_adc *info);
 + int (*enable_clk)(struct exynos_adc *info);
  };

  static const struct of_device_id exynos_adc_match[] = {
 - { .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
 - { .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
 + {
 + .compatible = samsung,exynos-adc-v1,
 + .data = (void *)ADC_V1,
 + }, {
 + .compatible = samsung,exynos-adc-v2,
 + .data = (void *)ADC_V2,
 + }, {
 + .compatible = samsung,exynos3250-adc-v2,
 + .data = (void *)ADC_V2_EXYNOS3250,
 + },
   {},
  };
  MODULE_DEVICE_TABLE(of, exynos_adc_match);
 @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct 
 exynos_adc *info)
   writel(con, ADC_V1_CON(info-regs));
  }

 +static void exynos_adc_disable_clk(struct exynos_adc *info)
 +{
 + if (info-needs_sclk)
 + clk_disable_unprepare(info-sclk);
 + clk_disable_unprepare(info-clk);
 +}
 +
 +static int exynos_adc_enable_clk(struct exynos_adc *info)
 +{
 + int ret;
 +
 + ret = clk_prepare_enable(info-clk);
 + if (ret) {
 + dev_err(info-dev, failed enabling adc clock: %d\n, ret);
 + return ret;
 + }
 +
 + if (info-needs_sclk) {
 + ret = clk_prepare_enable(info-sclk);
 + if (ret) {
 + clk_disable_unprepare(info-clk);
 + dev_err(info-dev,
 + failed enabling sclk_tsadc clock: %d\n, 
 ret);
 + }
 + }
 +
 + return 0;
 +}
 +
  static struct exynos_adc_ops exynos_adc_v1_ops = {
   .init_hw= exynos_adc_v1_init_hw,
   .clear_irq  = exynos_adc_v1_clear_irq,
   .start_conv = exynos_adc_v1_start_conv,
   .stop_conv  = exynos_adc_v1_stop_conv,
 + .disable_clk= exynos_adc_disable_clk,
 + .enable_clk = exynos_adc_enable_clk,
  };

  static void exynos_adc_v2_init_hw(struct exynos_adc *info)
 @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
   .start_conv = exynos_adc_v2_start_conv,
   .clear_irq  = exynos_adc_v2_clear_irq,
   .stop_conv  = exynos_adc_v2_stop_conv,
 + .disable_clk= exynos_adc_disable_clk,
 + .enable_clk = exynos_adc_enable_clk,

 Based on the fact that all variants use the same function, I don't think
 there is a reason to add .{disable,enable}_clk in the ops struct. If
 they diverge in future, they could be added later, but right now it
 doesn't have any value.

 OK, I'll not add .{disable,enable}_clk and then just use following 
 functions for

Re: [PATCH v6 1/6] clk: samsung: add infrastructure to register cpu clocks

2014-06-23 Thread amit daniel kachhap

On Tue, Jun 17, 2014 at 8:55 PM, Thomas Abraham thomas...@samsung.com wrote:
 From: Thomas Abraham thomas...@samsung.com

 The CPU clock provider supplies the clock to the CPU clock domain. The
 composition and organization of the CPU clock provider could vary among
 Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
 and gates. This patch defines a new clock type for CPU clock provider and
 adds infrastructure to register the CPU clock providers for Samsung
 platforms.

 Cc: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 ---
  drivers/clk/samsung/Makefile  |2 +-
  drivers/clk/samsung/clk-cpu.c |  577 
 +
  drivers/clk/samsung/clk.h |5 +
  3 files changed, 583 insertions(+), 1 deletion(-)
  create mode 100644 drivers/clk/samsung/clk-cpu.c

 diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
 index 69e8177..f4edd31 100644
 --- a/drivers/clk/samsung/Makefile
 +++ b/drivers/clk/samsung/Makefile
 @@ -2,7 +2,7 @@
  # Samsung Clock specific Makefile
  #

 -obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
 +obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o clk-cpu.o
  obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
  obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
  obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
 new file mode 100644
 index 000..c40f7b5
 --- /dev/null
 +++ b/drivers/clk/samsung/clk-cpu.c
 @@ -0,0 +1,577 @@
 +/*
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + * Author: Thomas Abraham thomas...@samsung.com
 + *
 + * 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.
 + *
 + * This file contains the utility functions to register the CPU clocks
 + * for Samsung platforms.
 +*/
 +
 +#include linux/errno.h
 +#include clk.h
 +
 +#define E4210_SRC_CPU  0x0
 +#define E4210_STAT_CPU 0x200
 +#define E4210_DIV_CPU0 0x300
 +#define E4210_DIV_CPU1 0x304
 +#define E4210_DIV_STAT_CPU00x400
 +#define E4210_DIV_STAT_CPU10x404
 +
 +#define MAX_DIV8
 +#define DIV_MASK   7
 +#define DIV_MASK_ALL   0x
 +#define MUX_MASK   7
 +
 +#define E4210_DIV0_RATIO0_MASK 0x7
 +#define E4210_DIV1_HPM_MASK((0x7  4) | (0x7  0))
 +#define E4210_MUX_HPM_MASK (1  20)
 +#define E4210_DIV0_ATB_SHIFT   16
 +#define E4210_DIV0_ATB_MASK(DIV_MASK  E4210_DIV0_ATB_SHIFT)
 +
 +#define E4210_CPU_DIV0(apll, pclk_dbg, atb, periph, corem1, corem0)\
 +   (((apll)  24) | ((pclk_dbg)  20) | ((atb)  16) |  \
 +   ((periph)  12) | ((corem1)  8) | ((corem0)   4))
 +#define E4210_CPU_DIV1(hpm, copy)  \
 +   (((hpm)  4) | ((copy)  0))
 +
 +#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
 +   (((apll  24) | (pclk_dbg  20) | (atb  16) |   \
 +(periph  12) | (acp  8) | (cpud  4)))
 +#define E5250_CPU_DIV1(hpm, copy)  \
 +   (((hpm)  4) | (copy))
 +
 +#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud)  \
 +   (((apll  24) | (pclk_dbg  20) | (atb  16) |   \
 +(cpud  4)))
 +#define E5420_KFC_DIV(kpll, pclk, aclk)  
   \
 +   (((kpll  24) | (pclk  20) | (aclk  4)))
 +
 +enum cpuclk_type {
 +   EXYNOS4210,
 +   EXYNOS5250,
 +   EXYNOS5420,
 +};
 +
 +/**
 + * struct exynos4210_cpuclk_data: config data to setup cpu clocks.
 + * @prate: frequency of the primary parent clock (in KHz).
 + * @div0: value to be programmed in the div_cpu0 register.
 + * @div1: value to be programmed in the div_cpu1 register.
 + *
 + * This structure holds the divider configuration data for dividers in the 
 CPU
 + * clock domain. The parent frequency at which these divider values are 
 valid is
 + * specified in @prate. The @prate is the frequency of the primary parent 
 clock.
 + * For CPU clock domains that do not have a DIV1 register, the @div1 member
 + * is optional.
 + */
 +struct exynos4210_cpuclk_data {
 +   unsigned long   prate;
 +   unsigned intdiv0;
 +   unsigned intdiv1;
 +};
 +
 +/**
 + * struct exynos_cpuclk: information about clock supplied to a CPU core.
 + * @hw:handle between CCF and CPU clock.
 + * @alt_parent: alternate parent clock to use when switching the speed
 + * of the primary parent clock.
 + * @ctrl_base: base address of the clock controller.
 + * @offset: offset from the ctrl_base address where the CPU clock div/mux
 + * registers can be accessed.
 + * @lock: cpu clock domain register access lock.
 + * @type: type of the CPU clock.
 + * @data: optional data

Re: [PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

2014-06-23 Thread Rahul Sharma

Hi Tomasz,

On 23 June 2014 20:08, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Rahul,

 On 23.06.2014 15:58, Rahul Sharma wrote:
 Hi Ajay, Inki,

 I tested this series for Exynos5420 based peach-pit board,
 Exynos5800 based Peach-pi board and Exynos5250 based
 Snow board. I verified with the chrome test environment and
 able to see upto Login Screen. DPMS on/off functionality and
 S2R is also working fine for Display. therefore:

 What tree did you apply this patches onto? I don't see S2R support for
 Exynos5420 or 5800 in current linux-next (e.g. there are no PMU tables
 present for these SoCs).

I verified them with inflight patches and some private patches. All of them
are available at
https://github.com/exynos-reference/kernel/tree/linux-3.16-rc1-ui-s2r

Regards,
Rahul Sharma.


 Best regards,
 Tomasz
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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

Andreas,

On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de 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 afaer...@suse.de 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. However it's the
 equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?

On snow locally I see USB2 vbus is gpx1-1 and USB3 vbus is gpx2-7.  I
don't see that in spring.

This will take more time than I have right now to track down.  I added
Julius to the thread in case he has time to answer and can suggest
what to do for upstream purposes.  I may be able to look more
tomorrow.

You can always send up the next version and include this and we'll
look at it again.


 +   };
 +
 +   vbat: vbat-fixed-regulator {
 +   compatible = regulator-fixed;
 +   regulator-name = vbat-supply;
 +   regulator-boot-on;
 +   };
 +
 +   usb@1200 {
 +   status = okay;
 +   };
 +
 +

[PATCH 0/3] MCPM: clarify boot CPU situation wrt CCI

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.


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

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

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
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 n...@linaro.org
---
 arch/arm/common/mcpm_entry.c | 52 
 arch/arm/include/asm/mcpm.h  | 16 ++
 2 files changed, 68 insertions(+)

diff --git a/arch/arm/common/mcpm_entry.c b/arch/arm/common/mcpm_entry.c
index f91136ab44..5e7284a3f8 100644
--- a/arch/arm/common/mcpm_entry.c
+++ b/arch/arm/common/mcpm_entry.c
@@ -12,11 +12,13 @@
 #include linux/kernel.h
 #include linux/init.h
 #include linux/irqflags.h
+#include linux/cpu_pm.h
 
 #include asm/mcpm.h
 #include asm/cacheflush.h
 #include asm/idmap.h
 #include asm/cputype.h
+#include asm/suspend.h
 
 extern unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
 
@@ -146,6 +148,56 @@ int mcpm_cpu_powered_up(void)
return 0;
 }
 
+#ifdef CONFIG_ARM_CPU_SUSPEND
+
+static int __init nocache_trampoline(unsigned long _arg)
+{
+   void (*cache_disable)(void) = (void *)_arg;
+   unsigned int mpidr = read_cpuid_mpidr();
+   unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+   phys_reset_t phys_reset;
+
+   mcpm_set_entry_vector(cpu, cluster, cpu_resume);
+   setup_mm_for_reboot();
+
+   __mcpm_cpu_going_down(cpu, cluster);
+   BUG_ON(!__mcpm_outbound_enter_critical(cpu, cluster));
+   cache_disable();
+   __mcpm_outbound_leave_critical(cluster, CLUSTER_DOWN);
+   __mcpm_cpu_down(cpu, cluster);
+
+   phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
+   phys_reset(virt_to_phys(mcpm_entry_point));
+   BUG();
+}
+   
+int __init mcpm_loopback(void (*cache_disable)(void))
+{
+   int ret;
+
+   /*
+* We're going to soft-restart the current CPU through the
+* low-level MCPM code by leveraging the suspend/resume
+* infrastructure. Let's play it safe by using cpu_pm_enter()
+* in case the CPU init code path resets the VFP or similar.
+*/
+   local_irq_disable();
+   local_fiq_disable();
+   ret = cpu_pm_enter();
+   if (!ret) {
+   ret = cpu_suspend((unsigned long)cache_disable, 
nocache_trampoline);
+   cpu_pm_exit();
+   }
+   local_fiq_enable();
+   local_irq_enable();
+   if (ret)
+   pr_err(%s returned %d\n, __func__, ret);
+   return ret;
+}
+
+#endif
+
 struct sync_struct mcpm_sync;
 
 /*
diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
index 94060adba1..ff73affd45 100644
--- a/arch/arm/include/asm/mcpm.h
+++ b/arch/arm/include/asm/mcpm.h
@@ -217,6 +217,22 @@ int __mcpm_cluster_state(unsigned int cluster);
 int __init mcpm_sync_init(
void (*power_up_setup)(unsigned int affinity_level));
 
+/**
+ * mcpm_loopback - make a run through the MCPM low-level code
+ *
+ * @cache_disable: pointer to function performing cache disabling
+ *
+ * This exercises the MCPM machinery by soft resetting the CPU and branching
+ * to the MCPM low-level entry code before returning to the caller.  
+ * The @cache_disable function must do the necessary cache disabling to
+ * let the regular kernel init code turn it back on as if the CPU was
+ * hotplugged in. The MCPM state machine is set as if the cluster was
+ * initialized meaning the power_up_setup callback passed to mcpm_sync_init()
+ * will be invoked for all affinity levels. This may be useful to initialize
+ * some resources such as enabling the CCI that requires the cache to be off, 
or simply for testing purposes.
+ */
+int __init mcpm_loopback(void (*cache_disable)(void));
+
 void __init mcpm_smp_set_ops(void);
 
 #else
-- 
1.8.4.108.g55ea5f6

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

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 n...@linaro.org
---
 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;
-- 
1.8.4.108.g55ea5f6

--
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/3] ARM: TC2: test the MCPM loopback during boot