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
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 addres
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
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 entr
Mike,
On Fri, Jun 6, 2014 at 3:31 PM, Mike Turquette 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 whichever
> version you and
Nicolas,
On Fri, Jun 6, 2014 at 3:38 PM, Nicolas Pitre 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 kernel or the fir
On Fri, Jun 06, 2014 at 06:32:42PM +0530, Vivek Gautam wrote:
> On Wed, Jun 4, 2014 at 6:43 PM, Thierry Reding
> 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
> >> wrote:
[...]
> >> > diff --git a/drivers/usb/host/ohc
>> 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
boo
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 operatio
Nicolas,
On Fri, Jun 6, 2014 at 3:35 PM, Nicolas Pitre 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 code at that locati
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 "unsubsc
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 addres
On Fri, 6 Jun 2014, Olof Johansson wrote:
> 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 a
Hi,
To add a few things to Olof's comments:
On Fri, Jun 6, 2014 at 2:49 PM, Olof Johansson 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 that, by
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 54
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 sho
Hi,
On Fri, Jun 6, 2014 at 1:49 PM, Doug Anderson 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 dependency. I'll c
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 entr
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 sho
Hi,
On Fri, Jun 6, 2014 at 2:01 PM, Russell King - ARM Linux
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 --git a/arch/arm/
Hi Olof,
On Sat, Jun 7, 2014 at 2:31 AM, Olof Johansson 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 wrote:
>> > [Adding Nico since he was involved in the original reviews]
>> >
>> > Hi,
>> >
>> > On F
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 04
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 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 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
On Fri, Jun 6, 2014 at 12:09 PM, Abhilash Kesavan
wrote:
> Hi Doug,
>
> On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson wrote:
>> Abhilash,
>>
>> On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
>> wrote:
>>> Hi Doug,
>>>
>>> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson wrote:
Abhilash,
Hi Olof,
On Sat, Jun 7, 2014 at 2:07 AM, Olof Johansson 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
>> wrote:
>> > Hi Dou
[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
> wrote:
> > Hi Doug,
> >
> > On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson wrote:
> >> Abhila
On Sat, Jun 7, 2014 at 12:39 AM, Abhilash Kesavan
wrote:
> Hi Doug,
>
> On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson wrote:
>> Abhilash,
>>
>> On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
>> wrote:
>>> Hi Doug,
>>>
>>> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson wrote:
Abhilash,
Hi Doug,
On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson wrote:
> Abhilash,
>
> On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
> wrote:
>> Hi Doug,
>>
>> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson wrote:
>>> Abhilash,
>>>
>>>
>>>
>>> On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
>>>
Abhilash,
On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan
wrote:
> Hi Doug,
>
> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson wrote:
>> Abhilash,
>>
>>
>>
>> On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
>> wrote:
>>> Hi Doug,
>>>
>>> On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson wrote
Hi Doug,
On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson wrote:
> Abhilash,
>
>
>
> On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
> wrote:
>> Hi Doug,
>>
>> On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson wrote:
>>> Abhilash,
>>>
>>> On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan
>>> wrot
Abhilash,
On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan
wrote:
> Hi Doug,
>
> On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson wrote:
>> Abhilash,
>>
>> On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan
>> wrote:
>>> Hi Doug,
>>>
>>> The first change in the kernel (clearing an iRAM location
Hi Doug,
On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson wrote:
> Abhilash,
>
> On Fri, Jun 6, 2014 at 10:36 AM, 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
Abhilash,
On Fri, Jun 6, 2014 at 10:36 AM, 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
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 cle
Tushar,
On Thu, Jun 5, 2014 at 9:38 PM, Tushar Behera 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] CPU
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_HA
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"
> depe
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,
they
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they
On Fri, Jun 6, 2014 at 5:36 AM, Mark Brown wrote:
> From: Mark Brown
>
> 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 beco
On Fri, Jun 6, 2014 at 9:50 PM, Simon Horman 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 wrote:
>> > On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
>> >> From: Mark Brown
>> >>
>> >> Since the OPP layer is a k
Hi,
On Wed, Jun 4, 2014 at 6:43 PM, Thierry Reding 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
>> wrote:
>> > Using devm_ioremap_resource() API should actually be preferred over
>> > devm_ioremap(), since
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
> On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman wrote:
> > On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
> >> From: Mark Brown
> >>
> >> Since the OPP layer is a kernel library which has been converted to be
> >> directly s
On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman wrote:
> On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
>> From: Mark Brown
>>
>> 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 arc
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: Vive
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. U
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 op
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
---
drivers/phy/phy-core.c | 36
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 Sup
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
> From: Mark Brown
>
> 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
From: Mark Brown
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.
Signed-off-by: Mark B
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
53 matches
Mail list logo