Hi,
On Tue, Aug 21, 2012 at 03:15:58PM +0300, Felipe Balbi wrote:
Hi guys,
here's a series of cleanup patches to the OMAP serial
driver. A later series could be made re-implementing
DMA using the DMA Engine API. Note that for RX DMA
we could be using RX Timeout IRQ as a hint that we better
Fixes:
CC arch/arm/mach-omap2/twl-common.o arch/arm/mach-omap2/twl-common.c:562:
error: conflicting types for ‘omap_twl4030_audio_init’
arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
‘omap_twl4030_audio_init’ was here
make[1]: *** [arch/arm/mach-omap2/twl-common.o]
Benoit,
On Monday 13 August 2012 04:30 PM, Santosh Shilimkar wrote:
These are the few device tree related patches which has been posted and
reviewed on the list. They are intended for 3.7 merge window but I am
posting them early enough to get into linux-next and linux-omap for testing.
The
Hi Kaehlcke,
On Thu, Aug 23, 2012 at 02:34:19, Matthias Kaehlcke wrote:
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Tested on an AM335x based custom board with a single
Hi Mark,
On 08/22/2012 10:15 PM, Mark Brown wrote:
Applied but this didn't quite apply cleanly, please check that it did so.
The part which removes the omap_mcbsp_6pin_src_mux() function from
sound/soc/omap/mcbsp.c is the one which did not made it.
It failed to apply on top of topic/omap is
On 08/22/2012 11:19 PM, Andreas Kemnade wrote:
if I understand the TRM correctly, according to Figure 21-26 in chapter
21.4.2.3.
if GSYNC is set, the receiver uses the signal from the sample rate generator,
so CLKX does not need to be the CLKR source.
But I tried also with the DEVCONF0
Hello,
The following series will add the needed entries for OMAP McBSP for DeviceTree
and enable the audio support on BeagleBoard when booted with DT.
Regards,
Peter
---
Peter Ujfalusi (6):
ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
ARM/dts: omap2420-h4: Include
The McBSP IP within OMAP2420 and 2430 is different we need to create separate
dtsi files for them.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 39 ++
arch/arm/boot/dts/omap2430.dtsi | 83 +++
2
Since the board is based on OMAP2420 we should include the dedicated dtsi
file (which includes the common omap2 dtsi).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Create the needed sections to be able to probe McBSP ports via DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 69 ++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 47 ++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git
Add the needed sections to enable audio support on BeagleBoard when booted
with DT blob.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git
On Thu, 23 Aug 2012 11:47:59 +0300
Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 08/22/2012 11:19 PM, Andreas Kemnade wrote:
if I understand the TRM correctly, according to Figure 21-26 in chapter
21.4.2.3.
if GSYNC is set, the receiver uses the signal from the sample rate
generator,
Hi AnilKumar,
thanks for your comments
El Thu, Aug 23, 2012 at 07:53:49AM + AnilKumar, Chimata ha dit:
This patch should divide into 2 patches, one patch meant for
MFD changes other for backlight.
will do
+struct tps65217_bl {
+ struct tps65217 *tps;
+ struct device *dev;
+
Hi guys,
here's v3 and hopefully final version of this series. A whole bunch of new
patches added but the good thing is that now I had another engineer's help to
test, so he's got his Tested-by in all patches.
Changes since v2:
. Added a bunch of new patches
. Fixed a problem
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 shubhrajy...@ti.com
Signed-off-by: Ruchika Kharwar
this driver doesn't use any from plat/dmtimer.h, so
we can remove it without any problems.
This will, however cause a problem because omap-serial.c
was relying on indirect inclusion of linux/platform_device.h,
let's fix the issue by including linux/platform_device.h
on omap-serial.c as it should
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 shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
enable RX FIFO for 16 characters and TX FIFO
for 16 spaces.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
From: Vikram Pandita vikram.pand...@ti.com
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 shubhrajy...@ti.com
Signed-off-by: Vikram Pandita
This has been missing from OMAP UART driver
for quite a while and it's simple enough
to implement it.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
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 shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ruchika Kharwar ruch...@ti.com
pm_runtime_enable() needs to be invoked before
pm_runtime_use_autosuspend(), and
pm_runtime_set_autosuspend_delay() functions.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Ruchika Kharwar
this patch is in preparation to a few other changes
which will align on the prototype for function
pointers passed through pdata.
It also helps cleaning up the driver a little by
agregating checks for pdata in a single location.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh
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 shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 330
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
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 shubhrajy...@ti.com
Acked-by: Santosh Shilimkar
From: Ruchika Kharwar ruch...@ti.com
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
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
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 1 +
1
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 shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
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
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 shubhrajy...@ti.com
Acked-by: Santosh
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 shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
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 shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
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
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized
On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
@@ -1266,6 +1267,15 @@ static int omap_i2c_runtime_resume(struct device
*dev)
omap_i2c_write_reg(_dev,
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote:
Fixes:
CC arch/arm/mach-omap2/twl-common.o
arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for
‘omap_twl4030_audio_init’
arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
On Thu, Aug 23, 2012 at 04:51:41PM +0530, Shubhrajyoti wrote:
On Thursday 23 August 2012 12:12 AM, Felipe Balbi wrote:
if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
@@ -1266,6 +1267,15 @@ static int
Hi Timo,
On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen timo.t.kokko...@iki.fi wrote:
The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
avoid problems that occur when MPU goes to sleep in the middle of
sending an IR code. Without such calls it takes ridiculously long for
Which branch needs this?
for-next for sure, haven't tested on any other
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/23/2012 02:22 PM, Mark Brown wrote:
Which branch needs this?
for-3.7, for-next and topic/omap needs this patch.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi,
This series contains miscellaneous improvements for omapdss, which I've made
while implementing device tree support for omapdss. This includes some changes
to arch/arm/:
* remove OMAP4 HDMI gpio handling from board files
* add vdda_hdmi_dac supply for HDMI to twl-common.c
* remove DSS clock
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the
TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the
5V power output to reach 90% of the voltage. This patch adds the delay
to the driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c |3 +++
1 file changed, 3 insertions(+)
diff
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree support.
This patch changes the HDMI driver to use the
Add max value of DSI functional clock to dss_features, so that DSI
driver can use it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss_features.c |2 ++
drivers/video/omap2/dss/dss_features.h |1 +
2 files changed, 3 insertions(+)
diff --git
DSI clocks are now configured dynamically by the DSI driver, so we can
remove the hardcoded clock configuration from the board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 46
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.
However, for
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
or the regulator supplying the vdac, has been enabled by default and
things have worked without the HDMI driver enabling the vdac.
I encountered the problem when implementing HDMI device tree support,
where the regulator was
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev-caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim
When booted with some resource will have their name set to NULL. This can
cause later kernel crash since this is not expected by the platform code.
When we boot without DT the devices are created with platform_device_add()
which itself fixes up the missing resource names:
if (r-name == NULL)
Safety check for the validity of the resource name before calling strcmp().
If the resource name is NULL do not compare it, just skip it.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Greg,
I have experienced with a kernel crash because the r-name was NULL when booting
OMAP4+
Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende
geschreven:
Add tps65217 regulator device tree data to AM335x-Bone by adding
regulator consumers with tightened constraints and regulator-name.
TPS65217 regulator handle can be obtained by using this regulator
name.
On Thu, Aug 23, 2012 at 09:35:01AM +0300, Peter Ujfalusi wrote:
Fixes:
CC arch/arm/mach-omap2/twl-common.o
arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for
‘omap_twl4030_audio_init’
arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of
Makes it easier to just do 'make dtbs' for whatever the kernel was
configured for, just like some other platforms.
Signed-off-by: Olof Johansson o...@lixom.net
---
arch/arm/mach-omap2/Makefile.boot | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/Makefile.boot
On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo t...@kernel.org wrote:
This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
I've tested it
Signed-off-by: Rob Clark r...@ti.com
---
On Thu, Aug 23, 2012 at 03:08:59PM -0500, Clark, Rob wrote:
On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo t...@kernel.org wrote:
This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
I've
Hi Tomi,
On 08/21/2012 06:09 AM, Tomi Valkeinen wrote:
Hi Florian,
Here are two small fixes for omapfb and omapdss. The first one fixes an old
bug
that causes colors to be wrong on fb console. The other fixes SDI output that
got broken in the previous merge window.
Applied both patches.
On Mon, 20 Aug 2012, Felipe Balbi wrote:
On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Mon, Aug 20, 2012
Signed-off-by: Peter Meerwald pme...@pmeerw.net
---
drivers/usb/otg/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 13fd1ddf..fefca18 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -58,7
On Wed, 18 Jul 2012, Javier Martinez Canillas wrote:
On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote:
On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote:
*
Hi Takashi,
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
...
Maybe the lack of audio support in drm is because the audio users should
not talk to drm directly but to a lower level component (omapdrm,
At Thu, 23 Aug 2012 20:44:32 -0500,
Ricardo Neri wrote:
Hi Takashi,
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen
Hi Koen,
On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende
geschreven:
Add tps65217 regulator device tree data to AM335x-Bone by adding
regulator consumers with tightened constraints and regulator-name.
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev-caps are initialized, and
the result was that
69 matches
Mail list logo
