On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
wrote:
> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > wrote:
> >> After thinking bit more on this, the problem seems to be coming
> >> mainly because the gpio device is run
On Fri, Aug 31, 2012 at 07:06:54PM -0700, Tony Lindgren wrote:
> * Mark Brown [120831 17:28]:
> > There's a topic/omap branch in ASoC which you can pull in to help reduce
> > conflicts, or I could merge this there if that's sensible.
> Thanks. Did not see it yet at
> git://opensource.wolfsonmic
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash
---
Resenting patch because ARM & OMAP mailing list was not copied.
:100644 100644 bb31bff... 6b469bd... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dt
On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote:
> On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> wrote:
>
>> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
>> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
>> > wrote:
>
>> >> After thinking bit more on this, the problem
Hi Vaibhav,
On 09/05/2012 10:05 PM, Vaibhav Hiremath wrote:
> On 9/5/2012 7:57 PM, Benoit Cousson wrote:
>> Hi Paul,
>>
>> On 08/24/2012 06:20 PM, Peter Ujfalusi wrote:
>>> Hi Paul,
>>>
>>> On 08/24/2012 06:38 PM, Paul Walmsley wrote:
Do we need both this one and your '[PATCH] driver core: Ch
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
> I see your point, however for now I can see no better way of referencing
> the data (of type struct snd_soc_card) then passing it to
> snd_soc_register_card(). But for this to work, I would have to register
> successfully an
Hi Tony,
On Mon, Sep 03, 2012 at 11:04:10, Mohammed, Afzal wrote:
> On Mon, Aug 27, 2012 at 14:04:44, Mohammed, Afzal wrote:
> > On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote:
> > > This hangs n800 during the boot.
Paul reported that n800 stopped booting on OMAP baseline [1]
due to an mm
On Thu, 6 Sep 2012 12:57:46 +0530 "Shilimkar, Santosh"
wrote:
> On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote:
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> >> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar,
On Wed, Sep 05, 2012 at 19:16:58, Marc Kleine-Budde wrote:
> On 09/05/2012 01:41 PM, AnilKumar Ch wrote:
> > Add Bosch D_CAN controller device tree data to AM33XX dtsi
> > file by adding d_can device nodes with all the necessary
> > parameters.
> >
> > Signed-off-by: AnilKumar Ch
> > ---
> > arc
On 09/06/2012 08:09 AM, AnilKumar, Chimata wrote:
> On Thu, Sep 06, 2012 at 04:56:10, Tony Lindgren wrote:
>> * Marc Kleine-Budde [120905 06:55]:
>>> On 09/05/2012 01:54 PM, Marc Kleine-Budde wrote:
On 09/05/2012 01:12 PM, AnilKumar Ch wrote:
> Adds suspend/resume functionality of d_can d
On Thu, Sep 06, 2012 at 13:07:29, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 09/05/2012 10:05 PM, Vaibhav Hiremath wrote:
> > On 9/5/2012 7:57 PM, Benoit Cousson wrote:
> >> Hi Paul,
> >>
> >> On 08/24/2012 06:20 PM, Peter Ujfalusi wrote:
> >>> Hi Paul,
> >>>
> >>> On 08/24/2012 06:38 PM, Paul Wa
On Thu, Sep 6, 2012 at 1:21 PM, NeilBrown wrote:
> On Thu, 6 Sep 2012 12:57:46 +0530 "Shilimkar, Santosh"
> wrote:
>
>> On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote:
>> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
>> > wrote:
>> >
>> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown
Marc,
On Tue, Sep 04, 2012 at 21:05:17, Stephen Warren wrote:
> On 09/02/2012 10:54 PM, AnilKumar Ch wrote:
> > Modify c_can binding documentation according to recent review comments
> > on device tree data addition patches.
> >
> > Signed-off-by: AnilKumar Ch
>
> Reviewed-by: Stephen Warren
>
On 09/06/2012 11:26 AM, AnilKumar, Chimata wrote:
> Marc,
>
> On Tue, Sep 04, 2012 at 21:05:17, Stephen Warren wrote:
>> On 09/02/2012 10:54 PM, AnilKumar Ch wrote:
>>> Modify c_can binding documentation according to recent review comments
>>> on device tree data addition patches.
>>>
>>> Signed-o
On Thu, Sep 06, 2012 at 15:00:34, Marc Kleine-Budde wrote:
> On 09/06/2012 11:26 AM, AnilKumar, Chimata wrote:
> > Marc,
> >
> > On Tue, Sep 04, 2012 at 21:05:17, Stephen Warren wrote:
> >> On 09/02/2012 10:54 PM, AnilKumar Ch wrote:
> >>> Modify c_can binding documentation according to recent rev
Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and third one
adds dcan DT data.
Reason behind combining these patches is to apply cleanly on
linux-omap tree, because these are sequential patches.
These patches were tested on A
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 43 +
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am33xx.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33
On 09/03/2012 06:54 AM, AnilKumar Ch wrote:
> Modify c_can binding documentation according to recent review comments
> on device tree data addition patches.
>
> Signed-off-by: AnilKumar Ch
> ---
> Changes from v1:
> - Separated from "Add DT for AM33XX devices" patch series
> - Incorpo
On 09/06/2012 11:42 AM, Marc Kleine-Budde wrote:
> On 09/03/2012 06:54 AM, AnilKumar Ch wrote:
>> Modify c_can binding documentation according to recent review comments
>> on device tree data addition patches.
>>
>> Signed-off-by: AnilKumar Ch
>> ---
>> Changes from v1:
>> - Separated from "A
On Thu, Sep 06, 2012 at 15:12:29, Marc Kleine-Budde wrote:
> On 09/03/2012 06:54 AM, AnilKumar Ch wrote:
> > Modify c_can binding documentation according to recent review comments
> > on device tree data addition patches.
> >
> > Signed-off-by: AnilKumar Ch
> > ---
> > Changes from v1:
> > -
Modify c_can binding documentation according to recent review comments
on device tree data addition patches.
Signed-off-by: AnilKumar Ch
---
Changes from v2:
- Incorporated Marc's comments on v2
* Fixed typo mistake by renaming d_can1 to dcan1
Changes from v1:
- Separat
On 09/06/2012 12:02 PM, AnilKumar Ch wrote:
> Modify c_can binding documentation according to recent review comments
> on device tree data addition patches.
>
> Signed-off-by: AnilKumar Ch
Thanks, I've updated my master branch.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde
Add support when the kernel has been booted with DT blob. In this case the
pdata is NULL, we need to reach up to the core node and check if the codec
part has been enabled to determine if we need to coexist with the codec or
not.
Signed-off-by: Peter Ujfalusi
---
drivers/input/misc/twl4030-vibra
When the kernel has been booted with DT blob the platform data is NULL for
the driver.
We need to construct the pdata based on the DT information for runtime use.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 57 +++---
1 file changed, 49
This commit adds an empty of_find_node_by_name() function for !CONFIG_OF
builds.
Signed-off-by: Peter Ujfalusi
---
include/linux/of.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index 1b11632..5c7a158 100644
--- a/include/linux/of.h
+++ b/inc
The external mute (if it is in use) is handled by a GPIO line. Prepare to
remove the set_hs_extmute callback and replace it with:
hs_extmute_gpio: the GPIO number to use for external mute
When the users of set_hs_extmute has been converted the callback can be removed.
Signed-off-by: Peter Ujfalus
Remove the use of set_hs_extmute callback and let the codec driver to
handle the extmute GPIO.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 9 ++---
arch/arm/mach-omap2/include/mach/board-zoom.h | 2 --
sound/soc/omap/zoom2.c| 4 --
Allocate the private data with devm_kzalloc.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 27ccea4..413e698 100644
--- a/sound/soc/codecs/twl4030.c
We no longer have users for the set_hs_extmute callback which has been
replaced by hs_extmute_gpio so the codec driver can handle the external
mute if it is needed by the board.
Signed-off-by: Peter Ujfalusi
---
include/linux/i2c/twl.h| 2 --
sound/soc/codecs/twl4030.c | 6 --
2 files ch
Access the pdata via a pointer within the twl4030_priv structure.
In preparation for DeviceTree support.
Signed-off-by: Peter Ujfalusi
---
sound/soc/codecs/twl4030.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/t
Support for loading the twl4030 audio module via devicetree.
Sub devices for codec and vibra will be created as mfd devices once the
core MFD driver is loaded when the kernel is booted with a DT blob.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/mfd/twl4030-audio.txt | 46 +
twl-core has API to get the boot time configured HFCLK rate which has the
same rate as the audio MCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index
Hello,
Generated on top of:
git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap
Changed since v2:
- Added commit message to patch 2 (as Tero requested it)
- Fixed patch 6 (dt: Add empty...) since the previous patch caused x86_64 build
to fail due to missing struct before device
To clean up the module probe and remove functions.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index ac04b4f..efa2d42 100644
--- a/drive
Place the MODULE_* lines in the same block and add MODULE_DESCRIPTION.
Rearange the platform_driver structure at the same time.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/
CFG_BOOT register's HFCLK_FREQ field hold information about the used HFCLK
frequency.
Add possibility for users to get the configured rate based on this
register.
This register was configured during boot, without it the chip would not
operate correctly, so we can trust on this information.
Signed-
Hi,
On Mon, Aug 6, 2012 at 6:37 PM, Kishon Vijay Abraham I wrote:
> All phy related programming like enabling/disabling the clocks, powering
> on/off the phy is taken care of by this driver. It is also used for OTG
> related functionality like srp.
>
> This also includes device tree support for u
To facilitate the device tree support the probe function need to be rearanged.
Small cleanup in the APLL frequency selection part as well.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-audio.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
dif
On Wed, Sep 05, 2012 at 01:27:21PM -0700, Greg KH wrote:
> On Thu, Aug 23, 2012 at 01:32:43PM +0300, Felipe Balbi wrote:
> > The driver doesn't need to know about its platform_device.
> >
> > Everything the driver needs can be done through the
> > struct device pointer. In case we need to use the
On Wed, Sep 05, 2012 at 01:27:49PM -0700, Greg KH wrote:
> On Thu, Aug 23, 2012 at 01:33:00PM +0300, Felipe Balbi wrote:
> > From: Vikram Pandita
> >
> > Software flow control register bits were not defined correctly.
> >
> > Also clarify the IXON and IXOFF logic to reflect what userspace wants.
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
to pm_runtime_pm_autosuspend() we make sure
that this will always be the case.
The idea behind this patch is to make sure we
will always reinitialize the pm timer so that
we don't fall into a situation where p
by the time we call our first pm_runtme_get_sync()
after enable pm_runtime, our resume method might
be called. To avoid problems, we must make sure
that our dev->drvdata is set correctly before
our resume method gets called.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Fe
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/
if platform_get_drvdata() returns NULL, that's
quite a nasty bug on the driver which we want to
catch ASAP. Otherwise, that check is hugely
unneeded.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 9 +++--
1 file cha
Two functions:
omap_serial_fill_features_erratas() and
of_get_uart_port_info() are only called from probe().
Marking them as __devinit gives us another
oportunity to free some code after .init.text
is done.
Tested-by: Shubhrajyoti D
Signed-off-by: Ruchika Kharwar
Signed-off-by: Felipe Balbi
---
From: Ruchika Kharwar
This patch unlocks the port lock before calling a serial_core API
and re-acquires the port lock after calling it.
This patch fixes a system freeze issue seen when the serial_core
API uart_write_wakeup() eventually attempts to acquire the port lock
already acquired by omap se
it makes no sense to mark our IRQ handler inline
since it's passed as a function pointer when
enabling the IRQ line.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/
From: Vikram Pandita
Software flow control register bits were not defined correctly.
Also clarify the IXON and IXOFF logic to reflect what userspace wants.
Cc: sta...@vger.kernel.org
Tested-by: Shubhrajyoti D
Signed-off-by: Vikram Pandita
Signed-off-by: Shubhrajyoti D
Acked-by: Tony Lindgren
nobody needs to access the uart_omap_port structure
other than omap-serial.c file. Let's move that
structure definition to the C source file in order
to prevent anyone from accessing our structure.
Tested-by: Shubhrajyoti D
Acked-by: Tony Lindgren
Signed-off-by: Felipe Balbi
---
arch/arm/plat-
enable RX FIFO for 16 characters and TX FIFO
for 16 spaces.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial
this driver doesn't use any from , so
we can remove it without any problems.
This will, however cause a problem because omap-serial.c
was relying on indirect inclusion of ,
let's fix the issue by including
on omap-serial.c as it should be.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
if we would reach serial_omap_get_char() while
Data Ready bit isn't set, we would return from
it without kicking our pm timer. This would mean
we would, eventually, have an unbalanced
pm_runtime_get on our device which would prevent
it from ever sleeping again.
Tested-by: Shubhrajyoti D
Signed-of
This has been missing from OMAP UART driver
for quite a while and it's simple enough
to implement it.
Tested-by: Shubhrajyoti D
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/omap-serial.c b/dri
From: Ruchika Kharwar
pm_runtime_enable() needs to be invoked before
pm_runtime_use_autosuspend(), and
pm_runtime_set_autosuspend_delay() functions.
Tested-by: Shubhrajyoti D
Signed-off-by: Nishanth Menon
Signed-off-by: Ruchika Kharwar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap
When we're running our hardirq handler, there's
not need to disable IRQs with spin_lock_irqsave()
because IRQs are already disabled. It also makes
no difference if we save or not IRQ flags.
Switch over to simple spin_lock/spin_unlock and
drop the "flags" variable.
Tested-by: Shubhrajyoti D
Signe
receive_chars() was getting too big and too difficult
to follow. By splitting it into separate RDI and RSLI
handlers, we have smaller functions which are easy
to understand and only touch the pieces which they need
to touch.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Fe
since all other IRQ types now do all necessary
checks inside their handlers, transmit_chars()
was the only one left expecting serial_omap_irq()
to check THRE for it. We can move THRE check to
transmit_chars() in order to make serial_omap_irq()
more uniform.
Tested-by: Shubhrajyoti D
Acked-by: San
On Wed, 2012-09-05 at 19:13 +0530, Archit Taneja wrote:
> On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
> > This reverts commit 1d71f42b35ed66d90a9a39bc515bb16cfe2d4a46.
> >
> > Adding fifo merge feature as an omapdss internal configuration was a
> > mistake. We cannot hide from th
quite a few changes here, though they are
pretty obvious. In summary we're making sure
to detect which interrupt type we need to
handle before calling the underlying interrupt
handling procedure.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/
Hi guys,
here's v4 of the omap uart patchset. No changes other than a rebase on top of
Greg's tty-next branch and Tony's Acked-by being added to a couple patches
Note: I'm resending the series with Vikram's Software Flow Control fix anyway
as it can just be ignored if it's decided it needs to go
OMAP has some extra Interrupt types which can
be really useful for SW. Let's define them
so we can later use those in OMAP's serial driver.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
include/linux/serial_reg.h | 4
1 file changed, 4 insertions(+)
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Tested-by: Shubhrajyoti D
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file changed, 12 inse
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct omap_dev
On 9/6/2012 12:34 AM, Jon Hunter wrote:
> Currently the dmtimer posted mode is being enabled when the function
> __omap_dm_timer_reset() is called. This function is only being called for
> OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
> for OMAP2+ timers that are NOT
On 9/6/2012 12:34 AM, Jon Hunter wrote:
> The OMAP dmtimer driver does not currently have a function to disable the
> timer interrupts. For some timer instances the timer interrupt enable
> function can be used to disable the interrupts because the same interrupt
> enable register is used to disa
On 9/6/2012 12:34 AM, Jon Hunter wrote:
> This series includes several fixes for the OMAP DMTIMER driver and a few
> clean-ups to simplify some of the code. This series is based upon 3.6-rc4.
>
> Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda.
> Testing includes ...
> 1.
On Thursday 06 September 2012, ABRAHAM, KISHON VIJAY wrote:
> > diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> > b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> > index d2fe064..bb0c7f4 100644
> > --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> > ++
On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote:
> On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
> > Now that fifo merge has been removed, nobody uses the extra_info related
> > completion code, which can be removed.
>
> I think this might come into use when we fix the usag
Add the needed properties for twl6040 so the GPO functionality can be used
by other drivers.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-sdp.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index f3ff4192..
Hello,
twl6040 has GPO functionality. The driver for it is going via MFD tree.
This series adds the needed properties to twl6040 in the dts files so other
drivers can use the GPO lines.
Regards,
Peter
---
Peter Ujfalusi (2):
ARM/dts: omap4-sdp: Enable GPO functionality for twl6040
ARM/dts: om
Add the needed properties for twl6040 so the GPO functionality can be used
by other drivers.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-panda.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index d28
On Thu, Sep 06, 2012 at 05:01:46PM +0300, Pantelis Antoniou wrote:
> Marking functions as __init or __devinit and calling them at other times
> leads to predictable crashes (if you're lucky).
>
> Remove them for now.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/usb/musb/musb_core.c|
On Thu, Sep 06, 2012 at 01:03:02PM +, Arnd Bergmann wrote:
> On Thursday 06 September 2012, ABRAHAM, KISHON VIJAY wrote:
> > > diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> > > b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> > > index d2fe064..bb0c7f4 100644
Hi,
On Thu, Sep 06, 2012 at 05:02:45PM +1000, NeilBrown wrote:
> On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> wrote:
>
> > On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> > > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > > wrote:
>
> > >> After thinking bit more on
Thanks Linus,
On 09/01/2012 02:10 AM, Linus Walleij wrote:
> On Thu, Aug 30, 2012 at 11:16 AM, Peter Ujfalusi
> wrote:
>
>> Hi Samuel, Linus,
> (...)
>> Did you had time to look at this series? Do you want me to resend it?
>
> I have provided my ACK on the GPIO part assuming you're taking this
On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote:
On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote:
On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
Now that fifo merge has been removed, nobody uses the extra_info related
completion code, which can be removed.
All -
We've been doing some suspend/resume testing and found that on occasion
(on the order of 1 in 5000 cycles) the system would lock up. The
problem was traced into the MUSB subsystem. Specifically, the interrupt
requested inside musb_core.c is of the non-threaded type (e.g. it runs
in th
Hi,
On Sun, 2012-09-02 at 22:12 +0300, Dimitar Dimitrov wrote:
> Very rare kernel crashes are reported on a custom OMAP4 board. Kernel
> panics due to corrupted completion structure while executing
> dispc_irq_wait_handler(). Excerpt from kernel log:
>
> Internal error: Oops - undefined instruc
On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote:
> On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote:
> > On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote:
> >> On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
> >>> Now that fifo merge has been removed, nobody
Felipe let me know of the patch that I didn't see in the queue.
Thanks!
- Tim
On 09/06/12 08:35, Tim Nordell wrote:
All -
We've been doing some suspend/resume testing and found that on occasion
(on the order of 1 in 5000 cycles) the system would lock up. The problem
was traced into the MUSB s
On 07/23/2012 10:24 AM, Jon Hunter wrote:
> Hi Rob,
>
> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in O
Hi Vaihbav,
On 08/27/2012 02:31 PM, Vaibhav Hiremath wrote:
> This series is trivial patch-series and should be considered as
> preparation for the future where we supposed to get rid of
> hwmod dependency.
>
> 1/2: Converts all hex numbers to lowercase, fixing inconsistency
> 2/2: Add reg and in
Hi,
On 09/05/2012 07:43 PM, Pantelis Antoniou wrote:
> The driver in question (twl4030.c) does not call snd_soc_codec_set_cache_io().
> However the snd-soc core does call it in sound/soc/soc-core.c in
> soc_probe_codec.
>
> I do see that there's a commit 98d3088e534a2a61f6690b5426909b0c3b57a785
On Thursday 06 September 2012 07:12 PM, Tomi Valkeinen wrote:
On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote:
On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote:
On Wed, 2012-09-05 at 19:01 +0530, Archit Taneja wrote:
On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wr
Hi,
On Sep 6, 2012, at 5:01 PM, Peter Ujfalusi wrote:
> Hi,
>
> On 09/05/2012 07:43 PM, Pantelis Antoniou wrote:
>> The driver in question (twl4030.c) does not call
>> snd_soc_codec_set_cache_io().
>> However the snd-soc core does call it in sound/soc/soc-core.c in
>> soc_probe_codec.
>>
>> I
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Errata Titles:
>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>> after wakeup (OMAP3/4)
>> i767: Delay needed to read some GP timer registers after wakeup (OMAP5
On Thursday 06 September 2012 12:32 PM, NeilBrown wrote:
> From: NeilBrown
> Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
>
> Current kernel will wake from suspend on an event on any active
> GPIO even if enable_irq_wake() wasn't called.
>
> There are two reasons that the
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> Currently the dmtimer posted mode is being enabled when the function
>> __omap_dm_timer_reset() is called. This function is only being called for
>> OMAP1 timers and OMAP2+ timers that are being used
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> The OMAP dmtimer driver does not currently have a function to disable the
>> timer interrupts. For some timer instances the timer interrupt enable
>> function can be used to disable the interrupts be
On Thu, 2012-09-06 at 19:31 +0530, Archit Taneja wrote:
> On Thursday 06 September 2012 07:12 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-09-06 at 19:05 +0530, Archit Taneja wrote:
> >> On Thursday 06 September 2012 06:34 PM, Tomi Valkeinen wrote:
> >>> On Wed, 2012-09-05 at 19:01 +0530, Archit Tane
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
>
>
> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>> This series includes several fixes for the OMAP DMTIMER driver and a few
>> clean-ups to simplify some of the code. This series is based upon 3.6-rc4.
>>
>> Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3
On 09/06/2012 09:06 AM, Jon Hunter wrote:
>
> On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
>>
>>
>> On 9/6/2012 12:34 AM, Jon Hunter wrote:
>>> Errata Titles:
>>> i103: Delay needed to read some GP timer, WD timer and sync timer registers
>>> after wakeup (OMAP3/4)
>>> i767: Delay needed
On 09/05/2012 04:41 PM, Hiremath, Vaibhav wrote:
...
> There are other patches which are pending,
>
> arm/dts: AM33XX: Convert all hex numbers to lower-case
> https://patchwork.kernel.org/patch/1377351/
> arm/dts: AM33XX: Specify reg and interrupt property for all nodes
> https://patchwork.kernel
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/Kconfig
Hi Felipe,
A proper answer required some instrumentation printks().
So what I did is that I peppered each function marked with a removed
__init or __devinit with a
> printk(KERN_INFO "%s:%d (%s) %s\n", __FILE__, __LINE__, KBUILD_MODNAME,
> __func__);
>
Both omap2430 & musb_hdrc are compiled
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to
This patch series adds device tree support for MUSB.
The glue layer is now made to write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.
Previously th
1 - 100 of 179 matches
Mail list logo
