Makes the function omap_mcspi_runtime_resume depend on CONFIG_PM_RUNTIME.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 41 +++--
1 files changed, 23 insertions(+), 18
Am 20.03.12 23:02, schrieb Arnd Bergmann:
On Tuesday 20 March 2012, Bernhard Walle wrote:
This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
PWM has been used as mode, but the PWM registers are different.
The driver can be used and has been tested in conjunction with
On Tue, Mar 20, 2012 at 9:25 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote:
Hi Keshava,
On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that the echi ports
Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Reviewed-by: Kevin Hilman khil...@ti.com
Cc : Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
This common clk API has been under development for over *two* years
already, with several attempts to merge it. And each previous merge
attempt aborted because someone came along at the last minute to do
exactly what you are doing
Hi,
I have a freshly built beagleboard xM on my desk which is giving me some
trouble:
xM revision A:
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
new xM revision C:
[0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
So the IVA and SGX aren't getting detected,
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
To add a few more thoughts, while I agree with Paul that there is room for
improvement in the APIs, I think the difference in opinion comes when we ask
the question:
When we eventually refine the APIs in the future to be more
On Wed, 2012-03-21 at 12:49 +0800, Ming Lei wrote:
This patch fixes the oos below:
[1.790242] Unable to handle kernel NULL pointer dereference at virtual
address 0004
[1.798632] pgd = c0004000
[1.801638] [0004] *pgd=
[1.805400] Internal error: Oops: 805 [#1]
Hello,
we are factory in China.
we offer USB flash drives USB2.0 and USB3.0
LOGO printed for free.
Hope can help you
Thanks
John
--
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
On Wednesday 21 March 2012, Bernhard Walle wrote:
Am 20.03.12 23:02, schrieb Arnd Bergmann:
On Tuesday 20 March 2012, Bernhard Walle wrote:
This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
PWM has been used as mode, but the PWM registers are different.
The
* Arnd Bergmann wrote:
On Wednesday 21 March 2012, Bernhard Walle wrote:
Am 20.03.12 23:02, schrieb Arnd Bergmann:
On Tuesday 20 March 2012, Bernhard Walle wrote:
This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
PWM has been used as mode, but the PWM registers
On Wed, Mar 21, 2012 at 01:44:01AM -0600, Paul Walmsley wrote:
Hello Saravana,
Certainly a Kconfig help text change seems trivial enough. But even the
resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given
that every single defconfig in arch/arm/defconfig sets it:
$
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for cpu0 only
and why the WFI is not used ?
Daniel Lezcano (7):
ARM: OMAP4: cpuidle -
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 0455858..254f97b 100644
---
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 254f97b..e14cd56 100644
---
We are storing the 'omap4_idle_data' in the private data field
if the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
Also, that simplfies the code.
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
Thanks. Will have a look at your series.
A couple a things call my
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
It is used during the registration. This field has been very useful for
debug when need to
On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
---
It is used during the registration. This
+ Jean,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Hi everyone,
the following patch set directs to enable predecimation for DMA and VRFB
which consists of two pacthes.
The first patch is based on code written by Lajos Molnar la...@ti.com in
Android Kernel, which updates the code with predecimation logic thereby
increasing the downscaling ability
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
Thanks. Will have a
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
The
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote:
On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel
On Wednesday 21 March 2012, Thierry Reding wrote:
* Arnd Bergmann wrote:
On Wednesday 21 March 2012, Bernhard Walle wrote:
Am 20.03.12 23:02, schrieb Arnd Bergmann:
On Tuesday 20 March 2012, Bernhard Walle wrote:
This PWM driver uses the PWM of the TWL4030. The driver for the
On Tuesday 20 March 2012, Paul Walmsley wrote:
Hello Arnd,
On Sat, 17 Mar 2012, Arnd Bergmann wrote:
I think it's rather pointless, because the option is not going to
be user selectable but will get selected by the platform unless I'm
mistaken. The platform maintainers that care
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for cpu0
only
On Sat, Feb 04, 2012 at 07:43:51PM +0200, Grazvydas Ignotas wrote:
When runtime_pm was originally added, it was done in rather confusing
way: omap2430_musb_init() (called from musb_init_controller) would do
runtime_pm_get_sync() and musb_init_controller() itself would do
runtime_pm_put to
On Sat, Feb 04, 2012 at 07:43:52PM +0200, Grazvydas Ignotas wrote:
musb can be suspended at the time some other driver wants to do ulpi
transfers using otg_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
http://article.gmane.org/gmane.linux.kernel/1226122
From: Govindraj.R govindraj.r...@ti.com
Based on Linux-OMAP tree uart branch.
(git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
remotes/origin/uart)
* Removes the cpu checks wherever possible and use version reg
for populating features and errata's
* enable tx wakeup
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
From: Govindraj.R govindraj.r...@ti.com
Minor cleanup, replace all omap34xx/omap44xx cpu checks with
cpu is not omap24xx check.
Cc: Paul Walmsley p...@pwsan.com
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
From: Govindraj.R govindraj.r...@ti.com
From omap36xx onwards the module wakeup enable reg
wer has TX wakeup bit available enable the same
by populating the necessary tx wakeup flag for the
applicable module ip blocks and use the same
while configuaring wer reg.
Also wer is not context restored,
* Arnd Bergmann wrote:
On Wednesday 21 March 2012, Thierry Reding wrote:
I don't have a public tree anywhere. Does anyone have a recommendation where
I could set one up? github or gitorious are the first to come to my mind.
They both work fine and are easy to set up, at least as a
On 03/21/2012 10:56 AM, Santosh Shilimkar wrote:
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
This patchset is a proposition to improve a bit the
On 03/21/2012 11:07 AM, Santosh Shilimkar wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my
On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 03/21/2012 10:56 AM, Santosh Shilimkar wrote:
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
On 03/21/2012 11:49 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 03/21/2012 10:56 AM, Santosh Shilimkar wrote:
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
Define AM33XX control register, in order to allow access to
control register address space, also add CONTROL_SEC_CLK_CTRL
register offset; both are required in clock tree data,
for wdt0 and timer0 clock source select configuration.
CONTROL.SEC_CLK_CTRL register is provided to select/configure
On Mon, Mar 19, 2012 at 17:14:30, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point here. With the above patch, we are almost
missing the capability of registering dmtimer as a clocksource for OMAP.
It will always
On Wed, Mar 21, 2012 at 11:28:47AM +0100, Thierry Reding wrote:
* Arnd Bergmann wrote:
On Wednesday 21 March 2012, Thierry Reding wrote:
I don't have a public tree anywhere. Does anyone have a recommendation
where
I could set one up? github or gitorious are the first to come to my
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point here. With the above patch, we are almost
missing the capability of
The patch does the following
- The pm_runtime_disable is called in the remove not in the error
case of probe.The patch calls the pm_runtime_disable in the error
case.
- Calls pm_runtime_put in the error case.
- The up is not freed in the error path. Fix the memory leak by using
devm_* so
Op 21 mrt. 2012, om 08:36 heeft Koen Kooi het volgende geschreven:
Hi,
I have a freshly built beagleboard xM on my desk which is giving me some
trouble:
xM revision A:
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
new xM revision C:
[0.00] OMAP3630
xM revision A:
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
new xM revision C:
[0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
on a rev. C -xm with kernel 3.2.8:
[0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
maybe u-boot makes
Op 21 mrt. 2012, om 13:29 heeft Peter Meerwald het volgende geschreven:
xM revision A:
[0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
new xM revision C:
[0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
on a rev. C -xm with kernel 3.2.8:
[0.00]
Hi Florian,
On Mon, 2012-03-19 at 13:01 +0200, Tomi Valkeinen wrote:
Hi Florian, Arnd,
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
On Mon, 2012-03-19 at 14:50 +, Mark Brown wrote:
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the regulator
On Mon, 2012-03-19 at 14:56 +, Mark Brown wrote:
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by:
On Mon, 2012-03-19 at 15:02 +, Mark Brown wrote:
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by:
Hi,
On Fri, 2012-03-09 at 02:42 +0200, Grazvydas Ignotas wrote:
If the size of memory region that is being set up is the same as before,
we don't have to do memory and layer busy checks.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
I'm not sure if this is semantically correct,
On Thu, 2012-03-15 at 20:00 +0200, Grazvydas Ignotas wrote:
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Hi Santosh, Daniel,
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior
On Fri, 2012-02-17 at 13:41 +0100, Thomas Weber wrote:
This patch adds support for the Mitsubishi display
AA084SB01. This is a 7 inch LVDS display. It is tested with
an OMAP3 board.
Signed-off-by: Thomas Weber we...@corscience.de
Thanks, I'll add these two panels to omapdss tree.
Tomi
On Wed, 21 Mar 2012, Paul Walmsley wrote:
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
This common clk API has been under development for over *two* years
already, with several attempts to merge it. And each previous merge
attempt aborted because someone came along at the
On Wed, Mar 21, 2012 at 11:03 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote:
On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The 'valid' field
On Wed, Mar 21, 2012 at 10:27 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Wed, Mar 21, 2012 at 8:10 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Tue, Mar 20, 2012 at 11:31 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
In _enable_gpio_irqbank() when
On 03/21/2012 02:31 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 10:27 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the
On 03/21/2012 02:19 PM, Jean Pihet wrote:
Hi Santosh, Daniel,
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code
Ming Lei tom.leim...@gmail.com writes:
This patch fixes the oos below:
As Tero mentioned, please add a bit more description to the changelog
about why the iterator is wrong and repost.
Thanks for the patch. After the above changes, I'll queue this up for v3.4-rc.
Kevin
[1.790242]
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not
On Wed, Mar 21, 2012 at 6:49 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi Santosh, Daniel,
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless omission on my part (see
below). Fix is trivial. I've check all other platforms and confirmed
this problem does not exist for those. Will resend a v9 of the
patchset shortly.
On
Govindraj.R govindraj.r...@ti.com writes:
From: Govindraj.R govindraj.r...@ti.com
Based on Linux-OMAP tree uart branch.
(git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
remotes/origin/uart)
* Removes the cpu checks wherever possible and use version reg
for populating
musb can be suspended at the time some other driver wants to do ulpi
transfers using usb_phy_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
http://article.gmane.org/gmane.linux.kernel/1226122
Add pm_runtime to ulpi functions to rectify this. This also adds
On Wed, Mar 21, 2012 at 9:28 AM, Rob Lee rob@linaro.org wrote:
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless omission on my part (see
below). Fix is trivial. I've check all other platforms and confirmed
this problem
Rob, you should start a new '3.4-fixes' branch containing such
bugfixes that can be pushed to Len after -rc1.
On Wed, Mar 21, 2012 at 4:28 PM, Rob Lee rob@linaro.org wrote:
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless
On Wed, Mar 21, 2012 at 12:10 PM, Felipe Balbi ba...@ti.com wrote:
On Sat, Feb 04, 2012 at 07:43:52PM +0200, Grazvydas Ignotas wrote:
musb can be suspended at the time some other driver wants to do ulpi
transfers using otg_io_* functions, and that can cause data abort,
as it happened with
On Wed, Mar 21, 2012 at 04:35:52PM +0200, Grazvydas Ignotas wrote:
musb can be suspended at the time some other driver wants to do ulpi
transfers using usb_phy_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
thomas2.kl...@uni-dortmund.de wrote:
Am 19.03.2012 23:51, schrieb Tony Lindgren:
* Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]:
Am 16.03.2012 20:33, schrieb Tony Lindgren:
Hi,
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not
On Tue, Mar 20, 2012 at 6:48 PM, Bernhard Walle wa...@corscience.de wrote:
This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
PWM has been used as mode, but the PWM registers are different.
The driver can be used and has been tested in conjunction with
pwm-backlight to
Commit c7e963f616 (net/smsc911x: Add regulator support) breaks
registration of gpmc connected smcs911x devices on machines with
regulator support, but without dummy regulator support.
Commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add
required smsc911x regulators) fixed the issue for boards
Hi Arnd Olof,
Here's a set of fixes that would be nice to get merged during
the merge window before the GPIO changes get merged to avoid
boot issues on many omap boards.
The changes queued in the GPIO tree require getting rid of
OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
unwieldy this would become if it were done for every device. Either the
functionality needs to be moved to Snowball board init code, or a generic
framework needs to be made for attaching regulators to arbitrary devices.
Hrm? Adding
On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
+for (i = 0; i ARRAY_SIZE(smsc911x_refs) * num; i++) {
+int id;
+char *name;
+
+id = board_data[i / num].id;
+if (id != -1)
+
On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
unwieldy this would become if it were done for every device. Either the
functionality needs to be moved to Snowball board init code, or a generic
framework needs to be made for
On 03/21/2012 12:44 AM, Paul Walmsley wrote:
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
To add a few more thoughts, while I agree with Paul that there is room for
improvement in the APIs, I think the difference in opinion comes when we ask
the question:
When we eventually
* Porter, Matt mpor...@ti.com [120321 11:27]:
On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
unwieldy this would become if it were done for every device. Either the
functionality needs to be moved to Snowball board init code,
On 03/19/2012 11:01 AM, Tomi Valkeinen wrote:
Hi Florian, Arnd,
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
(http://marc.info/?l=linux-omapm=133214966902577w=2). I hope to get
fix
On 03/21/2012 12:39 PM, Tomi Valkeinen wrote:
From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 19 Mar 2012 15:05:02 +0200
Subject: [PATCH] OMAPDSS: register dss drivers in module init
We do the dss driver
On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote:
* Porter, Matt mpor...@ti.com [120321 11:27]:
Hrm? Adding regulator supply mappings anywhere other than the
initialisation for a specific board would be extremely unusual and
rather suspicious.
The issue here is that we
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else)
perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock driver developers doesn't
necessarily translate to users of the clock
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]:
On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote:
* Porter, Matt mpor...@ti.com [120321 11:27]:
Hrm? Adding regulator supply mappings anywhere other than the
initialisation for a specific board would be
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:11]:
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else)
perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock
On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote:
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]:
That should be changed to pass in a boolean flag rather than a pointer
to platform device - the board may not have direct access to the
relevant regulator (eg, if
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:41]:
On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote:
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]:
That should be changed to pass in a boolean flag rather than a pointer
to platform device -
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brownbroo...@opensource.wolfsonmicro.com [120321 12:11]:
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else)
perceive that the Kconfig changes would be
1 - 100 of 128 matches
Mail list logo
