From: "Gupta, Pekon"
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes.
+---+---+--
From: "Gupta, Pekon"
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes,
selectable via DTB.
+---+--
From: "Gupta, Pekon"
This patch series makes ECC scheme selection for omap2-nand driver more
user-friendly.It also adds scalability for large page-sized NAND devices,
and adding new ECC schemes in future.
[PATCH 1/2]
- clean-up and optimization for supported ECC schemes.
- added
On 15/05/13 20:18, Aaro Koskinen wrote:
> Hi,
>
> Is it expected that after boot you get 0 brightness i.e. a seemingly
> blank display on N900 with 3.10-rc1?
>
> First thought after seeing a blank display was that the probe
> issues are still there, but everything was fine and after setting
> /sy
On 12:36 Wed 15 May , Eduardo Valentin wrote:
> On 15-05-2013 11:23, Benoit Cousson wrote:
> > Hi Eduardo,
> >
> > On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
> >> Include bandgap devices for OMAP4460 devices.
> >>
> >> Cc: "Benoît Cousson"
> >> Cc: Tony Lindgren
> >> Cc: Russell King
>
On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote:
> * Mark A. Greer [130514 18:57]:
> > On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote:
> > > Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
> > > changed PM to not access IVA registers on omaps that don't
Hi,
Is it expected that after boot you get 0 brightness i.e. a seemingly
blank display on N900 with 3.10-rc1?
First thought after seeing a blank display was that the probe
issues are still there, but everything was fine and after setting
/sys/class/backlight/acx565akm/brightness you get a picture
* Mark A. Greer [130514 18:57]:
> On Tue, May 14, 2013 at 05:25:37PM -0700, Tony Lindgren wrote:
> > Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
> > changed PM to not access IVA registers on omaps that don't have
> > them. Turns out we still need to idle iva2 as otherwise iva2_
On 11:46-20130515, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> A1-A3 = gpio_wk7
> ES = gpio_110
>
> There is no change to LED D2
>
> Abstract away the pinmux and the LED definitions for the two board
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts
On 15-05-2013 11:23, Benoit Cousson wrote:
> Hi Eduardo,
>
> On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
>> Include bandgap devices for OMAP4460 devices.
>>
>> Cc: "Benoît Cousson"
>> Cc: Tony Lindgren
>> Cc: Russell King
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-disc...@lists.ozl
The "ti,no_idle_on_suspend" property was required to keep ocmcram clocks
running during idle.
But commit 72bb6f9 (ARM: OMAP: omap_device: don't attempt late suspend
if no driver bound), added in v3.6 should prevent any automatic clock
gating for devices without drivers bound. Since there is no dr
Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
C
"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
Reviewed-by: Felipe Balbi
---
arch/arm/mach-omap2/ser
Hi Kevin,
Resending this patch series again on top of 3.10-rc1.
This is a cleanup series done in response to the
serial driver fixes done for "no_console_suspend" case.
This cleanups mainly include getting
rid of using "omap_device_disable_idle_on_suspend" api for both dt and non dt
case
as the
Hi,
On Wednesday 15 May 2013 08:27 PM, Sourav Poddar wrote:
On Wednesday 15 May 2013 08:27 PM, Greg KH wrote:
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Reviewed-by: Felipe Balbi
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/omap-serial.c | 34 +++
Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion from mpc52xx_uart driver.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Reviewed-by: Felipe Balbi
Reviewed-by: Kevin Hilman
Tested-by: Kevin H
Hi Greg,
I have rebased this patch series on top of 3.10-rc1.
This patch series contains fixes around the issue that
the console UART should not idled on suspend while using
"no_console_suspend" in bootargs.
The approach thought of is to modify the serial core/serial driver to bypass
runtime PM
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
> Include bandgap devices for OMAP4460 devices.
>
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc
On Friday 10 May 2013 07:32 PM, Nishanth Menon wrote:
> On 11:09-20130426, Kevin Hilman wrote:
>> Rajendra Nayak writes:
>>
>> [...]
>>
>>> OMAP UART IP needs manual idle modes based on functional state of the
>>> IP. Currently this is handled by the driver with function pointers
>>> implemented i
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/b
This patch add the bandgap entry for OMAP4430 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
a
Introduce HAS_BANDGAP config entry. This config is a
boolean value so that arch code can flag is they
feature a bandgap device.
This config entry follows the same idea behind
ARCH_HAS_CPUFREQ.
Cc: Russell King
Cc: Tony Lindgren
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel
Hello,
Idea is to add the missing bits under arch/arm/*omap* required
to enable by default the ti-soc-thermal driver. I am planing to
move it out of staging tree. It would be interesting to get
feedback from other ppl. By enabling it by default we could reach
more ppl for testing it across the sup
On Wednesday 15 May 2013 08:27 PM, Greg KH wrote:
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
Hi Greg,
Sourav Poddar writes:
Move "uart_console" def
Hello,
Idea is to add the missing bits under arch/arm/*omap* required
to enable by default the ti-soc-thermal driver. I am planing to
move it out of staging tree. It would be interesting to get
feedback from other ppl. By enabling it by default we could reach
more ppl for testing it across the sup
On Wed, May 15, 2013 at 08:13:09PM +0530, Sourav Poddar wrote:
> Hi Greg,
> On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
> >On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
> >>Hi Greg,
> >>
> >>Sourav Poddar writes:
> >>
> >>>Move "uart_console" definition to serial core header
From: Santosh Shilimkar
UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.
So remove the un-used slave idle platforms hooks now.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra nayak
Si
_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)
However the same programming logic is missing when it comes to sidle mod
From: Santosh Shilimkar
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
framework such a way tha
changes in v3:
1. Fix the patch ordering issue (which otherwise broke git-bisect) as pointed
out by Kevin Hilman. I missed re-sending these out with the fix in time for
the 3.10 merge window. Thanks to Nishanth Menon for picking these up and doing
a rebase against 3.10-rc1.
Thanks also to Sourav an
Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.
The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSU
From: Santosh Shilimkar
With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.
While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: Vaibhav Bedia
Tested-by: Sourav Poddar
Signed-off-by: Rajendra
From: Santosh Shilimkar
OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function point
Hi Greg,
On Saturday 27 April 2013 03:48 AM, Greg KH wrote:
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
Hi Greg,
Sourav Poddar writes:
Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion
On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [130503 10:55]:
> > Looks like we can get VBUS interrupt before the ID interrupt
how can this happen ? VBUS interrupt happens when you connect to a port
which is sourcing VBUS to you, while ID interrupt happens when
Hi,
I am working on a dm3730 based camera.
The sensor input clock is provided by the cpu via the CAM_XCLK pin.
Here is the corresponding log :
[9.115966] Entering cam_set_xclk
[9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz
[9.121337] ov10x33 1-0010: sensor
On Wednesday 15 May 2013 02:24 AM, Andreas Fenkart wrote:
> OMAP4430 TRM chap. 25.4.5.2
> To reduce dynamic consumption, an efficient idle scheme is based on the
> following:
> • An efficient local autoclock gating for each module
> • The implementation of control sideband signals between the PRCM
On Tuesday 14 May 2013 10:27 PM, Vincent Stehlé wrote:
> From: Vincent Stehlé
>
> OMAP5 needs SCU in SMP.
>
> This fixes the following link errors:
>
> arch/arm/mach-omap2/built-in.o: In function `scu_gp_set':
> arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode'
>
NM
On 05/15/2013 12:29 AM, Nishanth Menon wrote:
> $subject - add a space?
> s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
Will fix.
> On 09:17-20130514, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio
On 23/04/13 09:14, Kishon Vijay Abraham I wrote:
> After the device names are created using PLATFORM_DEVID_AUTO, the old
> device names given in usb_bind_phy are no longer valid causing the musb
> controller not to get the phy reference. Updated the usb_bind_phy with
> the new device names to get M
On 15.05.2013 10:37, Yegor Yefremov wrote:
> On 14.05.2013 15:01, Yegor Yefremov wrote:
>> On 14.05.2013 14:52, Felipe Balbi wrote:
>>> On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote:
Trying to boot 3.10-rc1 on an am3515 based board. With the same
.config as 3.7 the system
PSTATE shows current state of data lines.
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2b2ec09..61c0254 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -53,6 +53,7 @@
#define OMAP_HSMMC_RSP54
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4db8de5..2b2ec09 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -224,6 +224,7 @@ struct omap_hsmmc_host {
struct pinctrl *pinctrl;
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of th
No changes to the patches itself.
Only the dependency on some omap-gpio enable_irq/disable_irq patch
has been removed.
While developing, I was struck by a bug with disable_irq. After reviewing
the disable_irq code path, I thought the interrrupt got never disabled
for omap. After fixing the bug I
On 14.05.2013 15:01, Yegor Yefremov wrote:
> On 14.05.2013 14:52, Felipe Balbi wrote:
>> On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote:
>>> Trying to boot 3.10-rc1 on an am3515 based board. With the same
>>> .config as 3.7 the system comes to RTC stops there. I've also tried
>>> ma
On Mon, 2013-04-22 at 10:38 +0100, Mark Jackson wrote:
> I'm trying to work out how to generate a "valid" UBI image, but I keep
> getting a "cannot get enough PEBs" warning.
>
> I generate my image (destined for a 64MB NAND partition) using:-
>
> $ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m
49 matches
Mail list logo
