Thomas,
On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
The call to regulator_enable() is prior to the call to mmc_add_host().
Hence, call to mmc_fre_host is not required in this case. So the above
change should be right.
Are you sure that mmc_free_host() is
Thomas,
On Wed, Apr 10, 2013 at 6:56 AM, Doug Anderson diand...@chromium.org wrote:
On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
The call to regulator_enable() is prior to the call to mmc_add_host().
Hence, call to mmc_fre_host is not required in this case
Naveen,
On Fri, Apr 12, 2013 at 9:36 PM, Naveen Krishna Ch
naveenkrishna...@gmail.com wrote:
Can some one review this and get this fix into the tree.
I think the ball is in your court. Lars responded to your RFC patch
here and requested that you do a reset of the bus in the case of being
Mark,
On Mon, Mar 11, 2013 at 10:36 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Mar 6, 2013 at 3:42 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated
From: Thomas Abraham thomas.abra...@linaro.org
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Signed-off-by: Doug Anderson
. The changes committed during the
earlier patch has also been reverted here.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
Doug,
Would you please test whether this patch works for Snow?
Yup, it works for me. I did the basic testing
Olof,
On Wed, May 8, 2013 at 11:19 AM, Olof Johansson o...@lixom.net wrote:
Seems like this should be selected by the SoC (ARCH_EXYNOS5) instead
of the board. Actually, I'm not sure we need the board Kconfig entry
long-term; all boards will be dt-only.
Good point. Hopefully someone at
) will eventually move over to the common code.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Moved to the arch level as suggested by Olof.
arch/arm/mach-exynos/Kconfig | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b
Tomasz / Olof,
On Thu, May 9, 2013 at 2:45 AM, Tomasz Figa t.f...@samsung.com wrote:
Nothing stops you from doing that on your own. I tend to push back
onto the maintainers to get them engaged in their own housekeeping,
but anyone is free to :)
I will probably leave this to the maintainers at
. Also add basic dependencies for the PINCTRL_EXYNOS
kernel config.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Moved to chip level as per Tomasz.
- Update PINCTRL Kconfig for exynos.
Changes in v2:
- Moved to the arch level as suggested by Olof.
arch/arm/mach-exynos
++
1 files changed, 6 insertions(+), 0 deletions(-)
Thanks for updating the bindings. This looks good.
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
Arun,
On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes from v1
Ch ch.nav...@samsung.com
---
This change was tested on top of
https://lkml.org/lkml/2014/4/21/481 from Doug.
drivers/iio/adc/exynos_adc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Reported-by: Doug Anderson diand...@chromium.org
Reviewed-by: Doug Anderson diand
Naveen,
On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch maintains the following order in
probe(), remove(), resume() and suspend() calls
regulator enable, clk prepare enable
...
clk disable
Naveen,
On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
ADC module on Exynos5 SoCs runs at 600KSPS. At this conversion rate,
waiting for 1000 msecs is wasteful (incase of h/w failure).
Hence, reduce the time out to 100msecs and use
---
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 50
++
1 file changed, 26 insertions(+), 24 deletions(-)
Reviewed-by: Doug Anderson diand...@chromium.org
--
To unsubscribe from
-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/iio/adc/exynos_adc.c |1 +
1 file changed, 1 insertion(+)
Seems reasonable.
Reviewed-by: Doug Anderson diand...@chromium.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body
Tomasz and Arun,
On Sat, Apr 26, 2014 at 4:32 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Arun,
On 24.04.2014 06:17, Arun Kumar K wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson
;
+ writel(1, info-enable_reg);
exynos_adc_hw_init(info);
return 0;
--
1.7.9.5
Other than nit, looks good to me.
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
Vikas,
On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan sajjan.li...@gmail.com wrote:
Hi shaik,
+Doug, Abhilash,
On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
From: Cho KyongHo pullip@samsung.com
Signed-off-by: Cho KyongHo pullip@samsung.com
Anton,
On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson diand...@chromium.org wrote:
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control
Arun,
On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes from v1
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Separate out packet sizing from packet stuffing.
- Get rid of useless dev_dbg.
- Check command_sendrecv against NULL.
- Don't check np against NULL.
- Get rid of useless error on memory alloc fail.
- Get rid of useless
one last transfer after the timeout expires.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
We're adding i2c tunneling to the list of things that goes over
cros_ec. i2c tunneling can be slooow, so increase our deadline to
100ms to account for that.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
The main transfer function for cros_ec_spi can be called by more than
one client at a time. Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
Changes in v2:
- Removed i2c20 alias
(1):
mfd: cros_ec: spi: calculate delay between transfers correctly
Doug Anderson (5):
mfd: cros_ec: spi: Add mutex to cros_ec_spi
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
i2c: ChromeOS EC tunnel driver
this impacts commands with a long
turnaround time such as EC firmware reads and writes.
Signed-off-by: David Hendricks dhend...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker
EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew
-by: Doug Anderson diand...@chromium.org
Applied to the togreg branch of iio.git
I wasn't sure if this one was technically a fix, but as it isn't
marked clearly as such it can go in during the next merge window.
I won't have pushed this out to a non rebasing branch until tomorrow
so
/dts/exynos5420.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
This looks reasonable to me.
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
Arun,
On Wed, Apr 30, 2014 at 4:08 AM, Arun Kumar K arun...@samsung.com wrote:
+ memory {
+ reg = 0x2000 0x8000;
As mentioned in the other thread, I think this should be 0 0
+pinctrl_0 {
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+
Hi,
On Thu, May 1, 2014 at 7:15 AM, Mark Brown broo...@kernel.org wrote:
On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
Okay, I will extend the existing clock driver to support XCLKOUT.
It may make more sense to add another clock driver for this clock
depending on how things
Tomasz,
On Thu, May 1, 2014 at 10:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 01.05.2014 17:40, Doug Anderson wrote:
Arun,
On Wed, Apr 30, 2014 at 4:08 AM, Arun Kumar K arun...@samsung.com wrote:
+ memory {
+ reg = 0x2000 0x8000;
As mentioned
Mark,
On Thu, May 1, 2014 at 11:49 AM, Mark Brown broo...@kernel.org wrote:
On Thu, May 01, 2014 at 11:17:58AM -0700, Olof Johansson wrote:
so it looks like tps_pdata is NULL. Should likely be a check for it?
Yes, just about to post a fix.
Doh, was working on it at the same time.
belongs below this one (since the start pin is
larger than the start pin of i2c7-hs-bus). Tomasz probably has a
definite opinion on this.
Otherwise, this looks great to me. Perhaps you could send up the 5250 one, too?
Reviewed-by: Doug Anderson diand...@chromium.org
--
To unsubscribe from this list
Tomasz,
On Fri, May 2, 2014 at 10:10 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Arun,
On 02.05.2014 15:03, Arun Kumar K wrote:
Adds support for google peach-pi board having the
Exynos5800 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand
Arnd,
On Fri, May 2, 2014 at 11:52 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 May 2014 18:33:39 Arun Kumar K wrote:
From: Alim Akhtar alim.akh...@samsung.com
Exynos5800 clock structure is mostly similar to 5420 with only
a small delta changes. So the 5420 clock file is re-used for
Arun,
On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile
On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Well, if you can use the device tree of peach-pit board and boot peach-pi
and vice-versa and it won't cause any hardware failures then I guess it's
fine to keep this string.
I believe you can actually make it a good
Anton,
On Mon, May 5, 2014 at 10:11 PM, Anton Vorontsov an...@enomsg.org wrote:
On Mon, May 05, 2014 at 09:51:28AM -0700, Olof Johansson wrote:
All the rest of this series has been acked and applied. Do you have
time to review this patch?
Thanks! :)
FWIW, I've seen very little email
Tomasz,
On Thu, Apr 24, 2014 at 9:57 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Arun,
On 14.04.2014 08:35, Arun Kumar K wrote:
The newer versions of exynos5250 based Snow boards have
atmel trackpad. Updating relevant nodes for the same.
Signed-off-by: Arun Kumar K arun...@samsung.com
: Doug Anderson diand...@chromium.org
If we happened to get a data error at just the wrong time the dw_mmc
driver could get into a state where it would never complete its
request. That would leave the caller just hanging there.
We fix this two ways and both of the two fixes on their own
Seungwon,
On Mon, May 12, 2014 at 9:52 PM, Seungwon Jeon tgih@samsung.com wrote:
Hi Doug,
On Tue, May 13, 2014, Doug Anderson wrote:
Seungwon,
On Sat, May 10, 2014 at 7:11 AM, Seungwon Jeon tgih@samsung.com wrote:
On Fri, May 09, 2014, Sonny Rao wrote:
On Thu, May 8, 2014 at 2
Thomas,
On Tue, May 13, 2014 at 6:11 PM, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
+static int exynos4210_armclk_pre_rate_change(struct clk_notifier_data *ndata,
+ struct exynos_cpuclk *armclk, void __iomem *base)
+{
+
Stephen,
On Thu, May 15, 2014 at 11:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 04/17/2014 11:59 AM, Doug Anderson wrote:
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
Did the MFD patches at the start of this series get applied yet? I
Heiko,
On Thu, May 15, 2014 at 12:17 PM, Heiko Stübner he...@sntech.de wrote:
Am Donnerstag, 15. Mai 2014, 11:18:44 schrieb Doug Anderson:
Thomas,
On Tue, May 13, 2014 at 6:11 PM, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
+static int
Kukjin,
On Thu, May 15, 2014 at 12:38 PM, Kukjin Kim kgene@samsung.com wrote:
On 04/30/14 22:03, Ajay kumar wrote:
Hi,
Hi,
On Tue, Apr 15, 2014 at 4:24 AM, Olof Johanssono...@lixom.net wrote:
Hi Sachin,
On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamatsachin.ka...@linaro.org
wrote:
Heiko,
On Thu, May 15, 2014 at 1:12 PM, Heiko Stübner he...@sntech.de wrote:
Hi Doug,
Am Donnerstag, 15. Mai 2014, 12:36:45 schrieb Doug Anderson:
On Thu, May 15, 2014 at 12:17 PM, Heiko Stübner he...@sntech.de wrote:
Am Donnerstag, 15. Mai 2014, 11:18:44 schrieb Doug Anderson:
Thomas
Tomasz,
On Thu, May 15, 2014 at 2:14 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Chirantan,
On 15.05.2014 23:07, Chirantan Ekbote wrote:
The multi core timer and the ARM architected timer are two different
interfaces to the same underlying hardware timer. This causes some
strange
Tomasz,
On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
NOTE: if for some reason we need to keep the MCT around, we're
definitely going to need to account for the fact that tweaking it
affects the arch timer. ...and having the arch timer is really nice
since:
[Let
Tomasz,
On Thu, May 15, 2014 at 4:25 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 16.05.2014 01:18, David Riley wrote:
On Thu, May 15, 2014 at 4:03 PM, Chirantan Ekbote
chiran...@chromium.org wrote:
Hi Tomasz,
On Thu, May 15, 2014 at 3:44 PM, Doug Anderson diand...@chromium.org
wrote
, May 15, 2014 at 3:44 PM, Doug Anderson diand...@chromium.org
wrote:
Tomasz,
On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa tomasz.f...@gmail.com
wrote:
NOTE: if for some reason we need to keep the MCT around, we're
definitely going to need to account for the fact that tweaking it
affects
Seungwon,
On Thu, May 15, 2014 at 6:46 PM, Seungwon Jeon tgih@samsung.com wrote:
On Wed, May 14, 2014, Doug Anderson wrote:
Seungwon,
On Mon, May 12, 2014 at 9:52 PM, Seungwon Jeon tgih@samsung.com wrote:
Hi Doug,
On Tue, May 13, 2014, Doug Anderson wrote:
Seungwon,
On Sat
Kukjin,
On Fri, May 16, 2014 at 5:02 PM, Kukjin Kim kgene@samsung.com wrote:
On 05/17/14 07:56, Chirantan Ekbote wrote:
Anyway, I'm by no means opposed to switching to arch timers. They
provide a well designed, generic interface and drivers shared by
multiple platforms, which means more
every 2 seconds for AC
detect, which is sufficient.
For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't). If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).
Signed-off-by: Doug
Seungwon,
On Mon, May 19, 2014 at 6:51 PM, Seungwon Jeon tgih@samsung.com wrote:
+ } else {
+ /*
+* If we don't have a command
complete now we'll
+* never
anything else we end the
request and unblock anyone waiting.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@gmail.com
---
Changes in v2:
- Removed TODO
- Set cmd to NULL before calling dw_mci_request_end()
drivers/mmc/host/dw_mmc.c | 46
Tomasz,
On Thu, May 15, 2014 at 3:44 PM, Doug Anderson diand...@chromium.org wrote:
Tomasz,
On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
NOTE: if for some reason we need to keep the MCT around, we're
definitely going to need to account for the fact that tweaking
Kukjin,
On Wed, May 21, 2014 at 11:34 AM, Chirantan Ekbote
chiran...@chromium.org wrote:
On Wed, May 21, 2014 at 9:20 AM, Tomasz Figa t.f...@samsung.com wrote:
On 21.05.2014 15:24, Kukjin Kim wrote:
BTW, since
exynos5260, exynos5420 and exynos5800 doesn't support arch timer, we
have been
. That's because the UART clocks are also children of
aclk66_peric. You'll hang.
There's no good place to put a clock enable for earlyprintk, which is
handled by a bunch of assembly code. The best we can do is to handle
this in the clock driver.
Signed-off-by: Doug Anderson diand...@chromium.org
every 2 seconds for AC
detect, which is sufficient.
For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't). If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).
Signed-off-by: Doug
Vincent,
On Thu, May 29, 2014 at 1:42 PM, Vincent Guittot
vincent.guit...@linaro.org wrote:
In summary, we've got the following MCT patches proposed to go upstream:
1. MCT scheduler clock: http://crosreview.com/56363 and
http://crosreview.com/56364
2. Speed MCT access:
Tomasz,
On Thu, May 29, 2014 at 10:02 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi,
On 30.05.2014 00:29, Mike Turquette wrote:
Quoting Doug Anderson (2014-05-29 14:21:36)
Right now if you've got earlyprintk enabled on exynos5420-peach-pit
then you'll get a hang on boot. Here's why:
1
Javier,
On Fri, May 30, 2014 at 7:00 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
@@ -1239,3 +1251,15 @@ static void __init exynos5800_clk_init(struct
device_node *np)
exynos5x_clk_init(np, EXYNOS5800);
}
CLK_OF_DECLARE(exynos5800_clk,
. That's because the UART clocks are also children of
aclk66_peric. You'll hang.
There's no good place to put a clock enable for earlyprintk, which is
handled by a bunch of assembly code. The best we can do is to handle
this in the clock driver.
Signed-off-by: Doug Anderson diand...@chromium.org
Kukjin,
On Wed, May 28, 2014 at 10:38 AM, Doug Anderson diand...@chromium.org wrote:
Kukjin,
On Wed, May 21, 2014 at 11:34 AM, Chirantan Ekbote
chiran...@chromium.org wrote:
On Wed, May 21, 2014 at 9:20 AM, Tomasz Figa t.f...@samsung.com wrote:
On 21.05.2014 15:24, Kukjin Kim wrote:
BTW
there is no reason from a software perspective to clear the
counter before starting it. This also fixes the problems described in
the previous paragraph.
Cc: Olof Johansson o...@lixom.net
Cc: Doug Anderson diand...@chromium.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
use the lower half. Doing so brings us down to 1014429 us for
100 gettimeofday in userspace (and doesn't even require assembly
code). That would be an alternative to this change.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/clocksource/exynos_mct.c | 5 +++--
1 file changed
...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/clocksource/exynos_mct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index ba3a683..7cbe4aa 100644
--- a/drivers/clocksource
/tracing/
echo function_graph current_tracer
You'll get a crash.
Fix this (but still let other readers of the MCT be trace-enabled) by
adding an extra function. It's important to keep other users of MCT
traceable because the MCT is actually quite slow.
Signed-off-by: Doug Anderson diand
Thomas,
On Wed, Jun 4, 2014 at 11:05 AM, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 4 Jun 2014, Doug Anderson wrote:
As we saw in (clocksource: exynos_mct: cache mct upper count), the
time spent reading the MCT shows up fairly high in real-world
profiles. That means that it's worth
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 93 ++-
1 file changed, 3 insertions(+), 90 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 079fdf9
Vincent,
On Thu, Jun 5, 2014 at 12:55 AM, Vincent Guittot
vincent.guit...@linaro.org wrote:
On 4 June 2014 19:30, Doug Anderson diand...@chromium.org wrote:
From: Mandeep Singh Baines m...@chromium.org
Saves one register read. Note that the upper count only changes every
~178 seconds
Tomasz,
On Thu, Jun 5, 2014 at 4:18 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 04.06.2014 20:49, Doug Anderson wrote:
Thomas,
On Wed, Jun 4, 2014 at 11:05 AM, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 4 Jun 2014, Doug Anderson wrote:
As we saw in (clocksource: exynos_mct
Tomasz / Mike,
On Fri, May 30, 2014 at 9:32 AM, Doug Anderson diand...@chromium.org wrote:
Right now if you've got earlyprintk enabled on exynos5420-peach-pit
then you'll get a hang on boot. Here's why:
1. The i2c-s3c2410 driver will probe at subsys_initcall. It will
enable its clock
Tomasz,
On Thu, Jun 5, 2014 at 12:14 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 05.06.2014 20:48, Doug Anderson wrote:
Tomasz / Mike,
On Fri, May 30, 2014 at 9:32 AM, Doug Anderson diand...@chromium.org wrote:
Right now if you've got earlyprintk enabled on exynos5420-peach-pit
Tomasz,
On Thu, Jun 5, 2014 at 12:31 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
One more question that just came to my mind: Why it is just the
aclk66_peri and not its children related to UARTs?
Can you re-read out the original patch description and see if it
answers that? Basically: the
) this clock is exported as part of
the common clock bindings. Remove it since there are no in-kernel
device trees using it and no reason anyone out of tree should refer to
it either.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Now just remove aclk66_peric from the tree
Hi,
On Thu, Jun 5, 2014 at 1:10 PM, Doug Anderson diand...@chromium.org wrote:
Hmmm, I think I've convinced myself that your suggestion of just
removing this gate from the table is the right thing to do. Patch
will be coming up soon.
It's here https://patchwork.kernel.org/patch/4308631
Mike,
On Thu, Jun 5, 2014 at 5:03 PM, Mike Turquette mturque...@linaro.org wrote:
Quoting Doug Anderson (2014-06-05 13:35:14)
The aclk66_peric clock is a gate clock with a whole bunch of gates
underneath it. This big gate isn't very useful to include in our
clock tree. If any
Hi,
When I try to boot linuxnext on my exynos5420-peach-pit chromebook I
have problems bringing up extra CPUs:
1. They don't come up
2. As they're coming up you can see U-Boot print out (!). This sounds
similar to something that was happening during bringup where the other
CPUs didn't realize
Tushar,
On Thu, Jun 5, 2014 at 9:38 PM, Tushar Behera trbli...@gmail.com wrote:
On 06/06/2014 06:38 AM, Doug Anderson wrote:
Hi,
When I try to boot linuxnext on my exynos5420-peach-pit chromebook I
have problems bringing up extra CPUs:
1. They don't come up
[ ... ]
[1.125030] CPU1
Abhilash,
On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug,
The first change in the kernel (clearing an iRAM location) is needed
because of an unnecessary change that we are carrying in the Chrome
U-boot. There is no reason for us to have the
Abhilash,
On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug,
On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson diand...@google.com wrote:
Abhilash,
On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug
Abhilash,
On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug,
On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson diand...@google.com wrote:
Abhilash,
On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug
On Fri, Jun 6, 2014 at 12:09 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug,
On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson diand...@google.com wrote:
Abhilash,
On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Doug,
On Fri, Jun 6
Hi,
On Fri, Jun 6, 2014 at 2:01 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jun 06, 2014 at 01:49:11PM -0700, Doug Anderson wrote:
This works and IMHO is much cleaner because it totally removes the
U-Boot dependency. I'll cleanup to not be so insane and post:
diff
is implemented for systems using exynos-mcpm we'll
need to make sure we reinstall our fixed up code after resume. ...but
that's not anything new since IRAM (and thus the address of the
mcpm_entry_point) is lost across suspend/resume anyway.
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch
Hi,
On Fri, Jun 6, 2014 at 1:49 PM, Doug Anderson diand...@google.com wrote:
Are you talking about the re-writing the mcpm entry point address
post-resume ?
Or even (as Andrew points out) just don't use it.
This works and IMHO is much cleaner because it totally removes the
U-Boot
Hi,
To add a few things to Olof's comments:
On Fri, Jun 6, 2014 at 2:49 PM, Olof Johansson o...@lixom.net wrote:
What we can do, though, is to publicly shame you all Google People very
strongly for not making firmware updates in the field safer and easier.
After all you must all know already
Nicolas,
On Fri, Jun 6, 2014 at 3:35 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Fri, 6 Jun 2014, Doug Anderson wrote:
On exynos mcpm systems the firmware is hardcoded to jump to an address
in SRAM (0x02073000) when secondary CPUs come up. By default the
firmware puts a bunch
Nicolas,
On Fri, Jun 6, 2014 at 3:38 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Fri, 6 Jun 2014, Doug Anderson wrote:
Note that handling CPU resume in a way that can be updated by RW
firmware is non-trivial and requires some SRAM to be saved across
suspend/resume.
Saved
Mike,
On Fri, Jun 6, 2014 at 3:31 PM, Mike Turquette mturque...@linaro.org wrote:
Anyways, getting back on point, Tomasz was right about the whole clk_get
thing. So I'm happy to take either V1 or V3 of your patch. I will be
submitting a second PR for 3.16 next week and it will include
is implemented for systems using exynos-mcpm we'll
need to make sure we reinstall our fixed up code after resume. ...but
that's not anything new since IRAM (and thus the address of the
mcpm_entry_point) is lost across suspend/resume anyway.
Signed-off-by: Doug Anderson diand...@chromium.org
Krzystof,
On Mon, Jun 9, 2014 at 3:16 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote:
MAX77802 is a PMIC that contains 10 high efficiency Buck regulators,
32 Low-dropout (LDO) regulators, two 32kHz buffered clock
Lorenzo,
On Sat, Jun 7, 2014 at 11:12 AM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Fri, Jun 06, 2014 at 10:43:05PM +0100, Doug Anderson wrote:
On exynos mcpm systems the firmware is hardcoded to jump to an address
in SRAM (0x02073000) when secondary CPUs come up. By default
Tomasz,
On Fri, Jun 6, 2014 at 4:41 PM, Mike Turquette mturque...@linaro.org wrote:
Quoting Tomasz Figa (2014-06-05 15:26:31)
On 05.06.2014 22:35, Doug Anderson wrote:
The aclk66_peric clock is a gate clock with a whole bunch of gates
underneath it. This big gate isn't very useful
Kevin and Nicolas,
On Mon, Jun 9, 2014 at 1:27 PM, Kevin Hilman khil...@linaro.org wrote:
Nicolas Pitre nicolas.pi...@linaro.org writes:
On Sat, 7 Jun 2014, Abhilash Kesavan wrote:
Hi Nicolas,
The first man of the incoming cluster enables its snoops via the
power_up_setup function. During
101 - 200 of 710 matches
Mail list logo
