Without software reset the secondary CPU does not power up and
exynos_boot_secondary() ends with pen_release equal to 1. This can be
observed in dmesg:
CPU1: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC
From: Mark Brown broo...@linaro.org
Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user selectable and
requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
has become redundant and can be removed. Do so.
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user selectable and
requiring architectures to enable it explicitly the
The RFC version of this series was posted long time back, around December
last year [1].
This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv2 0/6] phy: simplified phy lookup [2], applied against 'usb-next'
branch of Greg's usb tree.
Tested on peach-pit boards with
Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed
Some quirky PHYs may require to be calibrated post the host
controller initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems is one such PHY
which needs to calibrated post xhci's reset at initialization
time and at resume time, to get the controller work at SuperSpeed.
Signed-off-by:
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller.
The PHY core provides a calibration funtionality now to do so.
Therefore, facilitate getting the two possible PHY types for
xhci controller, viz.
On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman ho...@verge.net.au wrote:
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman ho...@verge.net.au wrote:
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
Since the OPP layer is a kernel library which has been
Hi,
On Wed, Jun 4, 2014 at 6:43 PM, Thierry Reding thierry.red...@gmail.com wrote:
On Wed, Jun 04, 2014 at 03:41:20PM +0530, Vivek Gautam wrote:
Hi,
On Sat, May 10, 2014 at 5:30 PM, Vivek Gautam gautam.vi...@samsung.com
wrote:
Using devm_ioremap_resource() API should actually be
On Fri, Jun 6, 2014 at 9:50 PM, Simon Horman ho...@verge.net.au wrote:
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman ho...@verge.net.au wrote:
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
From: Mark Brown
On Fri, Jun 6, 2014 at 5:36 AM, Mark Brown broo...@kernel.org wrote:
From: Mark Brown broo...@linaro.org
Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user selectable and
requiring architectures to enable it explicitly
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
On 06/06/2014 05:36 AM, Mark Brown wrote:
[...]
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0ba4826..524b027 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -12,7 +12,6 @@ config ARCH_OMAP3
bool TI OMAP3
depends on
On Fri, Jun 06, 2014 at 09:50:06PM +0900, Simon Horman wrote:
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
I'm not sure about the expected merge order for this kind of change vs
queued up stuff in the renesas git tree, but I believe the following
patch selects ARCH_HAS_OPP:
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]
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 workaround in the
mainline kernel. Rather, we should remove the check from our u-boot.
However AFAIR a
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
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,
The first change in the kernel (clearing an iRAM location) is needed
because of an unnecessary change
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,
The
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 11:32 PM, Doug Anderson diand...@google.com wrote:
Abhilash,
On Fri, Jun 6,
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
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, 2014 at 11:50 PM, Doug Anderson diand...@google.com wrote:
Abhilash,
On Fri, Jun 6,
On Sat, Jun 7, 2014 at 12:39 AM, 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,
[Adding Nico since he was involved in the original reviews]
Hi,
On Fri, Jun 06, 2014 at 11:20:56AM -0700, Doug Anderson 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 11:32 PM, Doug Anderson
Hi Olof,
On Sat, Jun 7, 2014 at 2:07 AM, Olof Johansson o...@lixom.net wrote:
[Adding Nico since he was involved in the original reviews]
Hi,
On Fri, Jun 06, 2014 at 11:20:56AM -0700, Doug Anderson wrote:
Abhilash,
On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
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,
On Friday, June 06, 2014 02:08:50 PM Mark Brown wrote:
--cU9XODsizZBnwgll
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Fri, Jun 06, 2014 at 09:50:06PM +0900, Simon Horman wrote:
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
I'm not sure
On Sat, Jun 07, 2014 at 02:16:27AM +0530, Abhilash Kesavan wrote:
Hi Olof,
On Sat, Jun 7, 2014 at 2:07 AM, Olof Johansson o...@lixom.net wrote:
[Adding Nico since he was involved in the original reviews]
Hi,
On Fri, Jun 06, 2014 at 11:20:56AM -0700, Doug Anderson wrote:
Abhilash,
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 --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index
Hi Olof,
On Sat, Jun 7, 2014 at 2:31 AM, Olof Johansson o...@lixom.net wrote:
On Sat, Jun 07, 2014 at 02:16:27AM +0530, Abhilash Kesavan wrote:
Hi Olof,
On Sat, Jun 7, 2014 at 2:07 AM, Olof Johansson o...@lixom.net wrote:
[Adding Nico since he was involved in the original reviews]
Hi,
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
On Fri, 6 Jun 2014, Olof Johansson wrote:
On Sat, Jun 07, 2014 at 02:16:27AM +0530, Abhilash Kesavan wrote:
My answer is not use mainline u-boot primarily because I am not sure
mainline u-boot actually works on 5420 :).
And I'm saying that's not the answer primarily because we should
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 of code at that location. That code expects the
kernel to fill in a few slots with addresses that it uses to jump back
to the kernel's
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
On Fri, 6 Jun 2014, Abhilash Kesavan 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 workaround in the
mainline kernel. Rather, we should
On Fri, Jun 06, 2014 at 05:34:21PM -0400, Nicolas Pitre wrote:
On Fri, 6 Jun 2014, Olof Johansson wrote:
On Sat, Jun 07, 2014 at 02:16:27AM +0530, Abhilash Kesavan wrote:
My answer is not use mainline u-boot primarily because I am not sure
mainline u-boot actually works on 5420 :).
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
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 of code at that location. That code expects the
kernel to fill in a few slots with addresses
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 by the kernel or the firmware?
Nicolas
--
To unsubscribe from this list: send the line
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 of
This is somewhat off-topic, but given the various concepts discussed in
this thread I'm beginning to wonder how they will be implemented. The
current implementation hooks the IOMMU API into the DMA mapping API, and
the way this is done is by setting a single IOMMU (or rather a set of
IOMMU
If this is all that is needed to solve the problem being discussed in
the other thread I have absolutely no issue with such a workaround going
into mainline.
This plus the CCI fix that Andrew is planning to post.
Right - we'll need a patch to enable the CCI port for the cluster we
booted on
On Fri, Jun 06, 2014 at 06:32:42PM +0530, Vivek Gautam wrote:
On Wed, Jun 4, 2014 at 6:43 PM, Thierry Reding thierry.red...@gmail.com
wrote:
On Wed, Jun 04, 2014 at 03:41:20PM +0530, Vivek Gautam wrote:
On Sat, May 10, 2014 at 5:30 PM, Vivek Gautam gautam.vi...@samsung.com
wrote:
[...]
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 by the
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
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 of code at that location. That code expects the
kernel to fill in a few slots with addresses that it uses to jump back
to the kernel's
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 to include in our
clock tree. If any of the children need to be turned on then the big
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 of code at that location. That code expects the
kernel to fill in a few slots with addresses
Hi Nicolas,
The first man of the incoming cluster enables its snoops via the
power_up_setup function. During secondary boot-up, this does not occur
for the boot cluster. Hence, I enable the snoops for the boot cluster
as a one-time setup from the u-boot prompt. After secondary boot-up
there is no
52 matches
Mail list logo
