On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa6..5635202 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() during system suspend when
CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by:
On Mon, Dec 30, 2013 at 10:48 AM, boris brezillon
b.brezil...@overkiz.com wrote:
On 19/12/2013 19:22, Felipe Balbi wrote:
that's quite a weird argument from Linus W, considering you _do_ have a
discrete mux on the board.
We have quite a few of such crazy scenarios here at TI and we were
On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote:
The omap-usb-host driver expects the 60MHz functional clock
of the USB host module to be named as init_60m_fclk.
Add this information in the DT binding document.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz
+Tero
Hi Sebastian,
On 01/08/2014 02:38 PM, Sebastian Reichel wrote:
On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa6..5635202 100644
Hi Mark,
On 01/08/2014 03:26 PM, Mark Rutland wrote:
On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote:
The omap-usb-host driver expects the 60MHz functional clock
of the USB host module to be named as init_60m_fclk.
Add this information in the DT binding document.
CC: Lee Jones
On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT phandle?
All those clocks are identically named across the OMAP SoCs and are unique
for each
SoC, so
On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT phandle?
All those clocks are identically named across the OMAP SoCs
On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
It is a clock gate defined like so in the DT clock data
on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
Hi,
On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT phandle?
All those clocks are identically named across the OMAP SoCs and are unique
for each
SoC,
On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote:
On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT phandle?
All those clocks are
On 01/08/2014 04:10 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
It is a clock gate defined like so in the DT clock data
on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
On 01/08/2014 04:25 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote:
On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT
On Wednesday 08 January 2014, Roger Quadros wrote:
OK. I'll update the binding information to reflect all the clocks.
But what about clk_get() vs of_clk_get_by_name() ?
I think the convention these days is to just use clk_get(), which calls
of_clk_get_by_name() internally. Not sure if that's
On 01/08/2014 05:05 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Roger Quadros wrote:
OK. I'll update the binding information to reflect all the clocks.
But what about clk_get() vs of_clk_get_by_name() ?
I think the convention these days is to just use clk_get(), which calls
When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider hasn't been registered yet at that time, which
results in the interrupt being set to 0.
This is especially bad for platform devices
Hi Tony,
On Wednesday 08 January 2014 05:25 AM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140107 15:10]:
* Sricharan R r.sricha...@ti.com [131229 22:30]:
On Friday 27 December 2013 07:19 PM, Sricharan R wrote:
On Thursday 26 December 2013 11:14 PM, Santosh Shilimkar wrote:
On
On 2014-01-02 11:19, Archit Taneja wrote:
At the moment, the omapdrm driver doesn't work on panda/beagle when built-in
the kernel. The problem is that omapdrm doesn't defer probe if resources like
regulator/I2C etc are missing. The first patch fixes that.
The next 3 patches make sure that
On 01/08/2014 12:53 AM, Tony Lindgren wrote:
Well we cannot sanely deprecate the ti,hwmods and move on to
matching hwmod data with DT data based on the compatible flag.
So it's a bit of a blocker for v3.15 or so time frame.
Due to a 'hw feature' around the sidetone this is not as straight
On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider hasn't been registered yet at that time, which
results in the
On 2013-12-17 13:10, Archit Taneja wrote:
DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
region before the start of each frame. The preload ensures the pipeline
doesn't
underflow when the active region of the display starts.
DISPC_GFX/VIDp_PRELOAD registers
On 2014-01-08 01:59, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [131230 05:21]:
The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to
On Tuesday 07 January 2014 05:53 PM, Balaji T K wrote:
On Tuesday 07 January 2014 04:27 PM, Mark Rutland wrote:
On Tue, Jan 07, 2014 at 10:18:15AM +, Balaji T K wrote:
On Monday 06 January 2014 11:49 PM, Mark Rutland wrote:
On Fri, Dec 20, 2013 at 05:35:53PM +, Balaji T K wrote:
Add
On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider
On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
I hope I read this thread correctly, sorry if I missed an important
part. My idea was to add the code not in
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
[...]
Actually I posted a round of patches
* Thierry Reding thierry.red...@gmail.com [140108 04:55]:
When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider hasn't been registered yet at that time, which
results in the
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
It stands to reason that if they push back on the IOMMU variant of what
is essentially the same thing, they will
* Peter Ujfalusi peter.ujfal...@ti.com [140108 05:25]:
On 01/08/2014 12:53 AM, Tony Lindgren wrote:
Well we cannot sanely deprecate the ti,hwmods and move on to
matching hwmod data with DT data based on the compatible flag.
So it's a bit of a blocker for v3.15 or so time frame.
Due to a
Tony,
On 01/07/2014 06:28 PM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [131223 15:01]:
The irq data for rng module defined in hwmod data previously
missed the OMAP_INTC_START relative offset, so the interrupt
number is probably misconfigured during the DT node addition
adjusting for
* Heikki Krogerus heikki.kroge...@linux.intel.com [131209 07:10]:
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
This seems safe to queue via the USB list:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Heikki Krogerus
* Anna, Suman s-a...@ti.com [140108 09:33]:
Tony,
On 01/07/2014 06:28 PM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [131223 15:01]:
The irq data for rng module defined in hwmod data previously
missed the OMAP_INTC_START relative offset, so the interrupt
number is probably
* Jyri Sarha jsa...@ti.com [131105 00:43]:
Modifying the omap2plus_defconfig to enable the audio support for
AM335x EVM and other AM33xx based devices with TLV320AIC3X connected
to McASP.
Signed-off-by: Jyri Sarha jsa...@ti.com
Thanks applying into omap-for-v3.14/fixes-not-urgent.
Tony
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]:
(I'm CCing the MTD list, because GPMC is the memory controller
used for NOR, NAND and OneNAND devices).
Hi all,
Just a small patchset containing two small cleanups and a minor fix
for the GPMC memory controller. The
* Sricharan R r.sricha...@ti.com [140108 05:20]:
On Wednesday 08 January 2014 05:25 AM, Tony Lindgren wrote:
Oops, I noticed some errors on these:
WARNING: drivers/built-in.o(.text+0xcd0): Section mismatch in reference
from the function irqcrossbar_init() to the function
* Nishanth Menon n...@ti.com [140106 16:49]:
Hi Benoit, Tony,
On Wed, Dec 4, 2013 at 6:49 PM, Nishanth Menon n...@ti.com wrote:
Originally attempted partially in [1], the missing binding were
reported as part of Rob's report in [2].
Would you like me to send this series again since I do
* Felipe Balbi ba...@ti.com [131025 08:51]:
Hi,
On Fri, Oct 25, 2013 at 07:44:26AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [131025 07:20]:
enable a few more drivers as modules on omap2plus_defconfig,
this helps us getting more platforms working out of the box
by just
On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
* Thierry Reding thierry.red...@gmail.com [140108 04:55]:
When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
It stands to reason that if they push back on the
On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
The more I think about the iommu case, the more I am
On Wed, Jan 08, 2014 at 09:09:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd
Any pointers? Still present in 3.13-rc7.
On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote:
+Kishon
On 12/03/2013 11:33 PM, Belisko Marek wrote:
Hi,
current 3.13-rcX break usb support on gta04 board (similar to
beagleboard) when booting via board file.
In console we can
On Wednesday 08 January 2014 21:24:08 Thierry Reding wrote:
The problem with devres, or any other solution for that matter, is that
for the cases where we'd need something like this (that is, statically
allocated devices in board setup code) we don't have a fully initialized
struct device.
* Thierry Reding thierry.red...@gmail.com [140108 11:32]:
On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
There's nothing wrong with the interrupt related code paths, we're just
trying to call the functions at a wrong time when thing are not yet
initialized.
The patch
On Wed, Jan 08, 2014 at 11:18:37AM -0800, Tony Lindgren wrote:
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]:
(I'm CCing the MTD list, because GPMC is the memory controller
used for NOR, NAND and OneNAND devices).
Hi all,
Just a small patchset containing two
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [140108 15:39]:
On Wed, Jan 08, 2014 at 11:18:37AM -0800, Tony Lindgren wrote:
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]:
(I'm CCing the MTD list, because GPMC is the memory controller
used for NOR, NAND and
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:
Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.14/fixes-not-urgent-signed
for you to fetch
The following changes since commit adfe9361b236154215d4b0fc8b6d79995394b15c:
ARM: dts: Add basic devices on am3517-evm (2013-12-08 14:15:46 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.14/dt-signed
for you
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:
Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.14/be-signed
for you to fetch changes up to
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:
Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.14/crossbar-signed
for you to fetch changes up
-Original Message-
From: Valkeinen, Tomi
Sent: Wednesday, January 08, 2014 7:44 PM
To: Tony Lindgren; Ivaylo Dimitrov
Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; linux-fb...@vger.kernel.org
Subject: Re: [PATCH 1/2] ARM: omapfb: add
Hi Marek,
I have no idea what is happening there. Have you tried using device tree boot?
Board file boot support would be dropped eventually.
Did you try if I2C read write to the twl4030 device works and all necessary
clocks/supplies are
present?
Kishon, do you know what is causing the USB
On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
Tomi,
I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?
I am using omapfb_vram=10M@0xA000, and I believe it is correct way of
usage.
Thanks,
Vaibhav
AFAIK underflow interrupts could come
53 matches
Mail list logo
