On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dss_init_features function
providing a
much more generic and cleaner interface. The OMAP version and revision
On Tue, Aug 21, 2012 at 04:35:26PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
Everytime we're done
On Tue, Aug 21, 2012 at 4:02 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-08-20 at 18:54 +0530, Chandrabhanu Mahapatra wrote:
This is a alternative to HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com to
prevent
Hi,
On Tue, Aug 21, 2012 at 02:02:46PM +0300, Felipe Balbi wrote:
On Tue, Aug 21, 2012 at 04:35:26PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012
Hi Jon,
On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote:
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
This patch series add AM33XX regulators (tps65910/tps65217) device
tree data to am335x-evm and am335x-bone dts files. These patches
are based on Tony L devel-dt tree with these patches
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg73843.html
and these patches has been tested on AM335x
Add device tree data for tps65217 regulator by adding all tps65217
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65217 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree include file (tps65217.dtsi). This patch
was
Add device tree data for tps65910 regulator by adding all tps65910
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65910 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree include file (tps65910.dtsi). This patch
was
Add tps65910 regulator device tree data to AM335x-EVM by adding
regulator consumers with tightened constraints and regulator-name.
TPS65910 regulator handle can be obtained by using this regulator
name.
This patch also add I2C node with I2C frequency and tps65910 PMIC
I2C slave address.
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.
This patch also add I2C node with I2C frequency and tps65217 PMIC
I2C slave address.
On Tue, Aug 21, 2012 at 4:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-08-20 at 18:52 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dispc_init_features function
providing
a much more generic and cleaner interface. The OMAP version and
On Tue, 2012-08-21 at 16:36 +0530, Mahapatra, Chandrabhanu wrote:
On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dss_init_features function
providing a
Hi,
On Tue, Aug 21, 2012 at 4:17 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:15:39PM +0530, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Cc: Benoit Cousson
Hi,
On Tue, Aug 21, 2012 at 4:15 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This
Hi,
On Tue, Aug 21, 2012 at 4:16 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
+static struct platform_driver smsc_driver = {
+ .driver = {
+ .name = smsc-keypad,
+ .of_match_table =
On Tue, 21 Aug 2012 12:15:44 +0300
Felipe Balbi ba...@ti.com wrote:
Even if we enter our IRQ handler just to notice
that the our device didn't generate the IRQ,
that still means handling and IRQ, so let's
return IRQ_HANDLED.
That looks wrong - you'll defeat the stuck IRQ protection. If we
Hi Afzal,
Thanks for the patches!
On 08/21/12 13:45, Afzal Mohammed wrote:
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things
Hi,
On Tue, Aug 21, 2012 at 4:23 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Aug 21, 2012 at 04:15:40PM +0530, Sourav Poddar wrote:
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.
Cc: Benoit Cousson b-cous...@ti.com
Cc:
On Tue, Aug 21, 2012 at 12:50:05PM +0100, Alan Cox wrote:
On Tue, 21 Aug 2012 12:15:44 +0300
Felipe Balbi ba...@ti.com wrote:
Even if we enter our IRQ handler just to notice
that the our device didn't generate the IRQ,
that still means handling and IRQ, so let's
return IRQ_HANDLED.
Hi,
On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote:
+ if (type IRQ_TYPE_LEVEL_HIGH)
+ sg-int_lvl[bank] |= bit;
+ else if (type IRQ_TYPE_LEVEL_LOW)
+ sg-int_lvl[bank] = ~bit;
+ else
+ return -EINVAL;
this looks
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote:
Ricardo Neri wrote:
I was wondering about how much sense does it make to you guys use a
snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP
connection change notification as well, so I think
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
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.
Signed-off-by: Felipe Balbi
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by:
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 9 +++--
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
use PIO instead ;-)
All patches were tested on my pandaboard, but I'd
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by:
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/serial_reg.h | 4
1 file changed, 4
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.
Acked-by: Santosh Shilimkar
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.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by:
Hi,
On Tue, Aug 21, 2012 at 5:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote:
+ if (type IRQ_TYPE_LEVEL_HIGH)
+ sg-int_lvl[bank] |= bit;
+ else if (type IRQ_TYPE_LEVEL_LOW)
+ sg-int_lvl[bank]
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file
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 Tue, Aug 21, 2012 at 05:50:28PM +0530, Poddar, Sourav wrote:
Hi,
On Tue, Aug 21, 2012 at 5:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote:
+ if (type IRQ_TYPE_LEVEL_HIGH)
+ sg-int_lvl[bank] |= bit;
+
On 08/21/2012 02:05 PM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote:
Ricardo Neri wrote:
I was wondering about how much sense does it make to you guys use a
snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP
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:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to
propagate events from the HDMI output (e.g., display getting
On Tue, Aug 21, 2012 at 04:15:37PM +0530, Sourav Poddar wrote:
+config MFD_SMSC
+ bool Support for the SMSC ECE1099 series chips
+ depends on I2C=y MFD_CORE REGMAP_I2C
This needs to select REGMAP_I2C not depend on it. REGMAP_I2C will only
be enabled by being selected.
+int
On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote:
+ regmap_read(smsc-regmap, SMSC_DEV_ID, ret);
+ dev_dbg(i2c-dev, SMSC Device ID: %d\n, ret);
I'd make these log messages dev_info() or something.
dev_info() ? It'lll just make boot noisier for no good reason. Which
user wants
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
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
On 08/21/2012 02:05 PM, Mark Brown wrote:
- sound/core/ctljack.c which was added later and provides separate
in-kernel and userspace APIs and is currently only used by HDA.
This is wrong. PulseAudio uses the new ctljack
On Tue, Aug 21, 2012 at 07:39:55AM -0500, Clark, Rob wrote:
Does ASoC support 'hotplug' of audio devices? If so, maybe it makes
some sense to have some support in drm core. At least all the edid
parsing stuff to determine if the display supports audio should be
generic and not driver
On Tue, Aug 21, 2012 at 03:42:45PM +0300, Felipe Balbi wrote:
On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote:
+ regmap_read(smsc-regmap, SMSC_DEV_ID, ret);
+ dev_dbg(i2c-dev, SMSC Device ID: %d\n, ret);
I'd make these log messages dev_info() or something.
dev_info() ?
On Tue, Aug 21, 2012 at 02:22:22PM +0100, Mark Brown wrote:
On Tue, Aug 21, 2012 at 03:42:45PM +0300, Felipe Balbi wrote:
On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote:
+ regmap_read(smsc-regmap, SMSC_DEV_ID, ret);
+ dev_dbg(i2c-dev, SMSC Device ID: %d\n, ret);
On 08/21/2012 08:42 AM, Andreas Kemnade wrote:
Hi,
I tried a couple of times with different kernels to use mcbsp1 of dm3730
in master mode (so that it sends out clocks).
The result always is that I can send data out. but arecord gets no input. It
waits for input but does not get anything,
On Tue, Aug 21, 2012 at 04:27:44PM +0300, Felipe Balbi wrote:
I still beg to differ. Even if it fails, dmesg will still contain the
message (provided you have it enabled). I really don't think we want
this to print to console on every boot.
Only if it's enabled which is the trick...
If
On Tue, Aug 21, 2012 at 02:49:37PM +0100, Mark Brown wrote:
On Tue, Aug 21, 2012 at 04:27:44PM +0300, Felipe Balbi wrote:
I still beg to differ. Even if it fails, dmesg will still contain the
message (provided you have it enabled). I really don't think we want
this to print to console on
On Tue, Aug 21, 2012 at 04:47:26PM +0530, AnilKumar Ch wrote:
This patch series add AM33XX regulators (tps65910/tps65217) device
tree data to am335x-evm and am335x-bone dts files. These patches
are based on Tony L devel-dt tree with these patches
On Tue, Aug 21, 2012 at 04:52:41PM +0300, Felipe Balbi wrote:
Fair enough, we have quiet, but I'm not sure that's enough argument to
allow any simple driver to start poluting dmesg with whatever random
messages.
I think if the driver is just logging to say I'm running that's noise
and I do
Hi,
On Tue, Aug 21, 2012 at 03:08:03PM +0100, Mark Brown wrote:
On Tue, Aug 21, 2012 at 04:52:41PM +0300, Felipe Balbi wrote:
Fair enough, we have quiet, but I'm not sure that's enough argument to
allow any simple driver to start poluting dmesg with whatever random
messages.
I think
On Tue, Aug 21, 2012 at 05:09:24PM +0300, Felipe Balbi wrote:
You can't possibly understand what that'll print. First of all, VEN_ID_H
and VEN_ID_L should be ORed together. Second, the user will see the same
message four times in a row, with different values, but see that driver
claims that
On 21/08/12 06:49 AM, Tomi Valkeinen wrote:
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
+
+ /* ChiMei G121S1-L01 */
+ {
+ {
...
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+
To reflect the final devicetree node structure of McBSPs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hello,
the initial OMAP McBSP DT structure was not able to describe the IP (and it's
versions) correctly.
The main issue was the sidetone block of McBSP2/3 on OMAP3.
With this
On Tue, Aug 21, 2012 at 03:22:18PM +0300, Felipe Balbi wrote:
On Tue, Aug 21, 2012 at 05:50:28PM +0530, Poddar, Sourav wrote:
If I am understanding correctly, if they both uses the same bit we cannot
use both for a particular user. ?
we can, it's just a bit more complex. If a user request
Hi,
On Tue, Aug 21, 2012 at 04:01:36PM +0300, Felipe Balbi wrote:
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
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
Flushing spurious IRQs from HSMMC IP is done twice in
omap_hsmmc_irq and omap_hsmmc_do_irq.
spurious IRQ is flushed in start of omap_hsmmc_do_irq
and irq acked at the end of omap_hsmmc_do_irq
Consolidate them to one
Hi Venkat,
Some doubts below.
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer.
At init only right?
Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
On 08/21/2012 05:17 AM, AnilKumar Ch wrote:
Add device tree data for tps65910 regulator by adding all tps65910
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65910 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree
On Tue, Aug 21, 2012 at 09:48:21AM -0600, Stephen Warren wrote:
This .dtsi file adds a node for every single regulator within the
TPS65910, which in turn means that of_regulator_match() will find a node
for every regulator, and in turn every regulator will be registered. On
some boards, not
On 20 August 2012 09:49, Benoit Cousson b-cous...@ti.com wrote:
On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote:
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset
On 08/21/2012 10:38 AM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 09:48:21AM -0600, Stephen Warren wrote:
This .dtsi file adds a node for every single regulator within
the TPS65910, which in turn means that of_regulator_match() will
find a node for every regulator, and in turn every
On Tue, Aug 21, 2012 at 12:05:15PM -0600, Stephen Warren wrote:
On 08/21/2012 10:38 AM, Mark Brown wrote:
This isn't the general view for the regualtor API - we generally
want all regulators to be registered in order to allow us to see
what's going on with things even if we've not figured
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:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to
propagate events from the HDMI output
On 08/21/2012 08:16 AM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
On 08/21/2012 02:05 PM, Mark Brown wrote:
- sound/core/ctljack.c which was added later and provides separate
in-kernel and userspace APIs and is currently only used by HDA.
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
Newer IP's have wr_access and wr_data_mux_bus fields. Use
IP revision values to determine availability of these
fields and hence decide on whether to configure them.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c |
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
Divider value for a certain sync clk is determined solely
based on gpmc fclk. CS# does not have any role here, thus
remove presence of CS# in clock divider calculation API.
Signed-off-by: Afzal Mohammed af...@ti.com
---
From: Omar Ramirez Luna omar.rami...@ti.com
The patch to expose hwmod assert/deassert functions through omap_device
has been accepted and queued for 3.7[1], however these two patches are
needed to make the API functional. Hence a revised version is being sent
according to previous comments:
-
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
IP block isn't fully
Hi Felipe,
Thanks for the review
On Tuesday 21 August 2012 02:35 PM, Felipe Balbi wrote:
On Tue, Aug 21, 2012 at 11:47:43AM +0530, Shubhrajyoti D wrote:
Remove the macro MOD_REG_BIT instead make the bit field modifications
directly. This deletes a branch operation in cases where the the set
101 - 172 of 172 matches
Mail list logo
