While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43 seco
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Signed-off-by: Len Sorensen
---
arch/arm/mach-omap2/timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-om
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but
On 11/26/2014 03:51 PM, Arnd Bergmann wrote:
> On Wednesday 26 November 2014 15:38:09 Dave Gerlach wrote:
>> +
>> +static const struct wkup_m3_wakeup_src wakeups[] = {
>> + {.irq_nr = 35, .src = "USB0_PHY"},
>> + {.irq_nr = 36, .src = "USB1_PHY"},
>> + {.irq_nr = 40, .src = "I2
On Fri, Dec 12, 2014 at 01:40:01PM -0600, Nishanth Menon wrote:
> we try and avoid soc_is or cpu_is as much as possible and depend usually
> on compatible to mark the change..
Well you can't use the dtb really, since it depends on the chip revision
and how it started at power on. After all if you
On 14:23-20141212, Lennart Sorensen wrote:
> I was trying to avoid making the code mroe complicated for the other
> CPUs using this code, but I suppose since it runs only at boot once,
> that probably isn't really a great concern.
we try and avoid soc_is or cpu_is as much as possi
On Fri, Dec 12, 2014 at 11:37:41AM -0600, Nishanth Menon wrote:
> -sricharan, as the email ID is defunct.
So I noticed.
> On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
> > On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
> >> Errata i856 for the AM572x (DRA7xx) points out that
Hi Tero,
Tero Kristo writes:
> The new usage of determine_rate and set_rate_and_parent calls for
> OMAP DPLLs assumes the DPLLs must have two parents defined, even
> if it is the same clock. Legacy clock data did not fullfill this
> requirement and caused a boot crash. Fixed by adding the missin
Hi Kevin,
On Monday 08 September 2014 13:13:25 Kevin Hilman wrote:
> Laurent Pinchart writes:
> > On Monday 28 July 2014 23:52:34 Grant Likely wrote:
> >> On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
> >> > On 07/28/2014 05:05 PM, Grant Likely wrote:
> >> >> On Thu, 12 Jun 2014 19:5
Hi Grygorii,
I've found this mail deep inside my inbox :-)
On Wednesday 30 July 2014 16:25:31 Grygorii Strashko wrote:
> On 07/30/2014 03:06 AM, Laurent Pinchart wrote:
> > On Monday 28 July 2014 23:52:34 Grant Likely wrote:
> >> On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
> >>> On
-sricharan, as the email ID is defunct.
On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
> On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
>> Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
>> crystal is not enabled at power up. Instead the CPU falls ba
CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'")
Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with
v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via
different trees causing the resulta
> -Original Message-
> From: Catalin Crenguta [mailto:catalin.creng...@gmail.com]
> I have tried your patches by cloning [1] and copying the relevant files over
> the kernel I've cloned from [2].
> It compiles & runs, but I'm seeing lots of pen-down/pen-up events when I'm
> not touching the
On Friday 12 December 2014 02:10 AM, Sebastian Andrzej Siewior wrote:
> On 12/11/2014 09:34 PM, Nicolae Rosia wrote:
>> Hello,
>
> Hi,
>
>> Any updates on this series? I don't see it applied in [1] or [2].
>
> I manage to freeze am335x-evm with those patches and I think Vignesh
> is looking in
Hello,
I have tried your patches by cloning [1] and copying the
relevant files over the kernel I've cloned from [2].
It compiles & runs, but I'm seeing lots of pen-down/pen-up
events when I'm not touching the screen.
Any suggestions?
Hardware: Beaglebone Black with BB-View 4.3 Cape from Farnell
Hi!
After updating tree based on -pali to
2756d373a3f45a3a9ebf4ac389f9e0e02bd35a93 (and trimming down dts to
make it boot, as I'm still hiting dts size limit), video stops
working.
I also found this nastiness in dmesg:
Ideas welcome.
Best regards,
On 12/10/2014 09:41 PM, Kevin Hilman wrote:
Hi Tero,
On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo wrote:
Currently, DPLLs are hiding the gory details of switching parent
within set_rate, which confuses the common clock code and is wrong.
Fixed by applying the new determine_rate() and set_rate_a
While the change for determine_rate clock operation was merged,
the OMAP counterpart using these calls was overlooked for some reason,
and caused boot failures on at least OMAP4 platforms. Fixed by updating
the DPLL API calls to use the new parameters.
Signed-off-by: Tero Kristo
Fixes: 646cafc6aa
Hi,
These patches fix a couple of bugs in linux-next. I didn't see official
patch for #1 anywhere so posted here, was discussed under a thread on
linux-omap list though.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kern
The new usage of determine_rate and set_rate_and_parent calls for
OMAP DPLLs assumes the DPLLs must have two parents defined, even
if it is the same clock. Legacy clock data did not fullfill this
requirement and caused a boot crash. Fixed by adding the missing
parent information to the DPLL clocks.
Hi Pavel,
>> What needs to be done is the bring up of the device including the proper
>> UART settings and speed and then just run the firmware downloads. All
>> firmware files on the Nokia devices where just HCI commands with vendor
>> specific details. Some from CSR, some from
Hi!
> > I have created provisional device tree binding, and the driver still
> > works.
>
> I don't have time to look at the code now, but I have some comments
> regarding the binding.
> >
> > &uart2 {
> > +compatible = "brcm,uart,bcm2048";
>
> This does not look correct. The uart s
Hi!
> What needs to be done is the bring up of the device including the proper
> UART settings and speed and then just run the firmware downloads. All
> firmware files on the Nokia devices where just HCI commands with vendor
> specific details. Some from CSR, some from Broad
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset state.
This is actually required since pcf doesn't have a reset line and even after
warm reset (by invoking "reboot" in prompt) the pcf lines maintains it's
pr
24 matches
Mail list logo
