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
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 Broadcom and 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 should not be
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 Broadcom and some from
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
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 t-kri...@ti.com
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
On 12/10/2014 09:41 PM, Kevin Hilman wrote:
Hi Tero,
On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo t-kri...@ti.com 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
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,
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
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 into this.
-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
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
-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 back
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
Hi Kevin,
On Monday 08 September 2014 13:13:25 Kevin Hilman wrote:
Laurent Pinchart laurent.pinch...@ideasonboard.com 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
Hi Tero,
Tero Kristo t-kri...@ti.com 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
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 the
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 possible and depend
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 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 = I2C0},
+
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),
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 lsore...@csclub.uwaterloo.ca
---
arch/arm/mach-omap2/timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
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
24 matches
Mail list logo
