* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:
Hi,
* Paul Walmsley p...@pwsan.com [120726 13:07]:
On Wed, 25 Jul 2012, Paul Walmsley wrote:
These IP blocks and the ECAP IP blocks have periods in their names.
The
* Paul Walmsley p...@pwsan.com [120810 15:59]:
On Fri, 10 Aug 2012, Kevin Hilman wrote:
Under some circumstances, drivers may leave an omap_device enabled due
to driver programming errors, or due to a failure in the drivers
probe method.
Using the recently added omap_device
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:
Hi,
* Paul Walmsley p...@pwsan.com [120726 13:07]:
On Wed, 25 Jul 2012, Paul Walmsley wrote:
These IP blocks
From: Aneesh V ane...@ti.com
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we have to have some mechanism to initialize _mpu_rt_va before
core_init call, which will take DT resources and
On Tue, Aug 14, 2012 at 11:52 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Tue, Aug 14, 2012 at 11:46:35, Shilimkar, Santosh wrote:
On Mon, Aug 13, 2012 at 11:05 PM, Vaibhav Hiremath hvaib...@ti.com
wrote:
[...]
Also, does it make sense to get rid of hardcoded values above?
On Fri, Aug 17, 2012 at 12:15 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Aug 13, 2012 at 10:57:06AM +0530, Shilimkar, Santosh wrote:
Greg,
On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 17, 2012 at 11:28 PM, Greg KH
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we have to have some mechanism to initialize _mpu_rt_va
* Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]:
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we
On Fri, Aug 17, 2012 at 15:28:51, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]:
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath,
On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote:
Hi All,
Paul,
From last couple of days I am almost spending my whole time trying to
get to somewhere on below issue and based on my understanding and
learning so far I started feeling that, probably we might have made
wrong decision to remove
On Thu, Aug 16, 2012 at 04:40:59PM +0300, Peter Ujfalusi wrote:
in order to be able to add DT support for the McBSP driver which is used on
all
OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack:
Tony, are you OK with these changes going via ASoC?
--
To unsubscribe
These are minor cleanup patches which will be useful for the future series on
outputs. It's harder to add output entities in DSS when there are more
omap_dss_device references in the driver. The first 2 reduces that a bit. The
third patch just removes some left over fields from omap_dss_device
Many of the DSI functions receive the connected panel's omap_dss_device pointer
as an argument. The platform device pointer is then derived via omap_dss_device
pointers.
Most of these functions don't really require omap_dss_device pointer anymore
since we now keep copies of parameters in the
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
is an enabled display connected to the manager before trying to see the state of
the GO bit.
The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled
Passive matrix support was removed recently. The acb and acbi pin declarations
in omap_dss_device struct weren't removed by accident. Remove these fields
from omap_dss_device.
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h |4
1 file changed, 4 deletions(-)
diff
Hi Guys,
On 08/17/2012 11:58 AM, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]:
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav
Hi Vaibhav,
On 08/17/2012 11:51 AM, Hiremath, Vaibhav wrote:
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we have
On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
On 7/14/2012 3:56 AM, Jon Hunter wrote:
OMAP3 devices may or may not have security features enabled. Security
enabled
devices are known
Hi Vaibhav,
On 08/17/2012 12:12 PM, Vaibhav Hiremath wrote:
On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote:
Hi All,
Paul,
From last couple of days I am almost spending my whole time trying to
get to somewhere on below issue and based on my understanding and
learning so far I started
On Fri, 2012-08-17 at 16:19 +0530, Archit Taneja wrote:
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if
there
is an enabled display connected to the manager before trying to see the state
of
the GO bit.
The checks related to the display can be replaced by
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
Acked-by: Tony Lindgren t...@atomide.com
--
To
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
* Mark Brown broo...@opensource.wolfsonmicro.com [120817 03:18]:
On Thu, Aug 16, 2012 at 04:40:59PM +0300, Peter Ujfalusi wrote:
in order to be able to add DT support for the McBSP driver which is used on
all
OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack:
On 08/17/2012 04:07 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Is this the case also for 2420? I thought some only had a FIFO at
one port?
IRCC (I
On Thu, 2012-08-16 at 16:48 +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
specific
initializations in various functions are cleaned and the necessary
On 08/17/2012 04:14 PM, Jarkko Nikula wrote:
On 08/17/2012 04:07 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Is this the case also for 2420? I thought
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the
Fix inconsistency between mach-types and CONFIG_ name that prevents touchbook
board from booting.
Signed-off-by: Radek Pilar mr...@mrkva.eu
diff -ur linux-3.5.1/arch/arm/mach-omap2/Kconfig
linux-3.5.1-mrkva/arch/arm/mach-omap2/Kconfig
--- linux-3.5.1/arch/arm/mach-omap2/Kconfig 2012-08-09
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards,
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com wrote:
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses
On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman svenk...@ti.com wrote:
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com
wrote:
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes
Essentially, a lot of cleanups leading up to adding a new
feature for OMAP HSMMC. The idea is to convert to the use
of software timer instead of IP timer for timekeeping, due
to the limitations of the counting range of the IP timer.
Also added myself as OMAP HSMMC maintainer.
Patch 9/10 is in
HPI can be issued only in programming state to bring the card to
transfer state. If the card is already in transfer state, doing
a HPI is redundant.
Fix this by adding transfer state to the list of exceptions to
doing HPI and return without error.
Signed-off-by: Venkatraman S svenk...@ti.com
---
ext_csd exported through debugfs is printed in reverse order (from
byte 511 to 0), which causes confusion.
Fix the for loop to print ext_csd in natural order.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Get rid of some unnecessary includes in the driver and
a few unused variables.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 50e08f0..0ec4e55 100644
The function mmc_omap_report_irq uses raw printks and the
actual output was disabled by a static variable. Make
the function use dev_vdbg macro and use it under the
standard CONFIG_MMC_DEBUG flag.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 29
Some straight forward cleanup of unnecessary #include's
and host variables. Some of the verbose and redundant
debug messages are converted to use dev_vdbg.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 14 --
1 file changed, 4 insertions(+), 10
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer. Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
Remove code which manipulates IP reset and SYSCONFIG directly in the
driver.
Signed-off-by: Venkatraman S svenk...@ti.com
---
Flushing spurious IRQs from HSMMC IP is done twice in
omap_hsmmc_irq and omap_hsmmc_do_irq.
Consolidate them to one location.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git
Consolidate the duplicated code around the handling of CMD_TIMEOUT,
CMD_CRC, DATA_TIMEOUT, DATA_CRC and CARD_ERR handling into a
single function.
This generally shrinks code bloat, but is also required for implementing
software based guard timers.
Signed-off-by: Venkatraman S svenk...@ti.com
---
I can continue to look after this driver.
Signed-off-by: Venkatraman S svenk...@ti.com
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 72c2681..75e3c3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4933,8 +4933,10 @@ S:
omap hsmmc controller IP has an inbuilt timer that can be programmed to
guard against unresponsive operations. But it's range is very narrow,
and it's maximum countable time is a few seconds.
Card maintenance operations like BKOPS and SECURE DISCARD and long
stream writes like packed command
On Thu, Aug 16, 2012 at 08:49:30PM +0530, Shubhrajyoti D wrote:
Remove the call of platform_set_drvdata(pdev, NULL) as they are not
needed anymore.
Applied, thanks. These calls were never *needed* people just like to
put them in.
--
To unsubscribe from this list: send the line unsubscribe
48 matches
Mail list logo
