On Fri, Jan 30, 2015 at 03:55:35PM -0800, Tony Lindgren wrote:
The following changes since commit 1f43c45df7afb706470f7d81d983dd7763a9452f:
ARM: dts: dra72-evm: Add qspi device (2015-01-20 10:07:25 -0800)
are available in the git repository at:
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and figure out that it's not due to
probe defer, but
On 02/06/2015 08:32 PM, Peter Zijlstra wrote:
On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote:
Certainly looks much simpler, but it adds quite a bit of data to the
omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.
ls -al vmlinux
w/o any the lockdep
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the
When CONFIG_PM_SLEEP=n, the following compilation warnings appear:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
‘ti_bandgap_suspend’ defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
scripts/checkkconfigsymbols.py indicates that omap1_defconfig
references the following obsolete Kconfig symbols:
CONFIG_BT_L2CAP
CONFIG_BT_SCO
CONFIG_DEBUG_ERRORS
CONFIG_EXPERIMENTAL
CONFIG_FB_OMAP_BOOTLOADER_INIT
CONFIG_LEDS_CPU
CONFIG_MACH_OMAP_HTCWIZARD
CONFIG_MTD_CHAR
CONFIG_MTD_DEBUG
Building an OMAP1510-only Kconfig generates the following warnings:
arch/arm/mach-omap1/pm.c: In function ‘omap1_pm_idle’:
arch/arm/mach-omap1/pm.c:123:2: warning: #warning Enable 32kHz OS timer in
order to allow sleep states in idle [-Wcpp]
#warning Enable 32kHz OS timer in order to allow
On 02/06/15 11:37, Russell King - ARM Linux wrote:
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and
No functional change. Modified few things so that there are no
code duplication while implementing chained TRB.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/ep0.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git
dwc3 can do only max packet aligned transfers. So in case request length
is not max packet aligned and is bigger than DWC3_EP0_BOUNCE_SIZE
two chained TRBs is required to handle the transfer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
*) Did eumeration testing with g_zero in kernel
On Fri, 6 Feb 2015, Quentin Lambert wrote:
On 06/02/2015 03:15, Stephen Boyd wrote:
Thanks for the coccinelle patch. Thinking more about it, I don't think
we care if the pointer is dereferenced because that would require a
definition of struct clk and that is most likely not the case
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO:
On 06/02/2015 03:15, Stephen Boyd wrote:
Thanks for the coccinelle patch. Thinking more about it, I don't think
we care if the pointer is dereferenced because that would require a
definition of struct clk and that is most likely not the case outside of
the clock framework. Did you scan the
From: Grygorii Strashko grygorii.stras...@linaro.org
Fix following build warning if CONFIG_PM_SLEEP is not set:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
'ti_bandgap_suspend' defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
On 02/06/2015 04:13 PM, Peter Zijlstra wrote:
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882]
On 02/06/15 01:12, Julia Lawall wrote:
On Fri, 6 Feb 2015, Quentin Lambert wrote:
On 06/02/2015 03:15, Stephen Boyd wrote:
Thanks for the coccinelle patch. Thinking more about it, I don't think
we care if the pointer is dereferenced because that would require a
definition of struct clk and
* George Cherian george.cher...@ti.com [150206 05:05]:
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
Thank I totally missed that, updated patch below.
Do you have some testcase that easily triggers BABBLE
on
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
On 02/05/2015 10:05 PM, Tony Lindgren wrote:
We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.
The ATL hwmod can be used in nested way when it is selected to be the
functional clock for McASP. For this lockdep validator will trigger false
positive warning.
By assigning separate class to atl locking will sort this out.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
In case when hwmods are used in nested way the lockdep validator will print out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO: possible recursive locking detected ]
[4.526176]
Add lockdep_class member to struct omap_hwmod and use this number to
specify the subclass of the given hwmod's lock.
When defining the hwmods the lockdep_level can be initialized to indicate
that this lock might be used in a nested fashion.
DRA7x's ATL hwmod is one example for this since McASP can
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
On 02/05/15 16:42, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
Actually we can bury the __clk_create_clk() inside
__of_clk_get_from_provider(). We should also move __clk_get()
Hi,
On Fri, Feb 06, 2015 at 05:25:35PM +0530, Kishon Vijay Abraham I wrote:
dwc3 can do only max packet aligned transfers. So in case request length
is not max packet aligned and is bigger than DWC3_EP0_BOUNCE_SIZE
two chained TRBs is required to handle the transfer.
Signed-off-by: Kishon
Tony,
On Fri, Feb 6, 2015 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
* George Cherian george.cher...@ti.com [150206 05:05]:
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
Thank I totally missed that,
On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote:
Certainly looks much simpler, but it adds quite a bit of data to the
omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.
ls -al vmlinux
w/o any the lockdep warning fixes:
110109168
With my series
25 matches
Mail list logo
