On Mon, May 30, 2011 at 6:03 PM, Santosh Shilimkar
wrote:
> While trying out V3.0-rc1, I noticed couple of regressions. Am
> posting this in case anybody come across same issues.
>
> 1.OMAP MMC code keep throwing "Pbias Voltage is not same as LDO" error
> continuously.
>
> Balaji is planning post
* Janusz Krzysztofik [110530 15:43]:
>
> Detected and corrected while building for Amstrad Delta, confirmed with
> omap1_defconfig.
Thanks, will queue this fix.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
M
The test command :
# cyclictest -l1 -m -a0 -t1 -n -p99 -i200 -h200 -q
I run the following command to increase cpu's burden at the same time.
# while true; do hackbench; sleep 1;done
cyclictest and hackbench can be get in
git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.g
Forward-declare platform_device structure in
arch/arm/plat-omap/include/plat/flash.h, otherwise compilation may break
with:
In file included from arch/arm/mach-omap1/flash.c:15:
arch/arm/plat-omap/include/plat/flash.h:14: warning: 'struct platform_device'
declared inside parameter list
arch/arm/
Include from
arch/arm/plat-omap/include/plat/flash.h, otherwise compilation may break
with:
In file included from arch/arm/mach-omap1/flash.c:15:
arch/arm/plat-omap/include/plat/flash.h:14: warning: 'struct platform_device'
declared inside parameter list
arch/arm/plat-omap/include/plat/flash.h
On Mon, May 30, 2011 at 11:44:01PM +0200, Janusz Krzysztofik wrote:
> Include from
> arch/arm/plat-omap/include/plat/flash.h, otherwise compilation may break
> with:
>
> In file included from arch/arm/mach-omap1/flash.c:15:
> arch/arm/plat-omap/include/plat/flash.h:14: warning: 'struct platform
On Mon, May 30, 2011 at 09:38:10AM +0300, Tomi Valkeinen wrote:
> On Fri, 2011-05-20 at 21:16 +0530, Avinash.H.M wrote:
> > The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
> > special sequence to reset the module. The sequence is
> > - Disable the I2C.
> > - Write to SOF
On Mon, May 30, 2011 at 5:57 PM, Laurent Pinchart
wrote:
> Thanks for the patch, but I've already applied something similar to my tree.
> Sorry :-)
np, thanks. I'm just playing with omap3isp a bit and wanted to get rid
of that "hey what did I do wrong this time" feeling every time I
recompiled it
Hi Ohad,
On Sunday 29 May 2011 09:04:51 Ohad Ben-Cohen wrote:
> Trivially fix this:
>
> drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg':
> drivers/media/video/omap3isp/isp.c:394: warning: zero-length gnu_printf
> format string
Thanks for the patch, but I've already applied somethin
Hi,
* Koen Kooi [110527 06:28]:
>
> @@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
> printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
> omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> break;
> + case 2:
> + printk(KERN_INFO
eMMC does not handle power off when not in sleep state,
Skip regulator disable during probe when eMMC is
not in known state - state left by bootloader.
Resolves eMMC failure on OMAP4
mmc0: error -110 whilst initialising MMC card
Signed-off-by: Balaji T K
---
arch/arm/mach-omap2/board-4430sdp.c
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
"Pbias Voltage is not same as LDO"
Signed-off-by: Balaji T K
---
arch/arm/mach-omap2/hsmmc.c
Balaji T K (2):
ARM: OMAP4: MMC: increase delay for pbias
ARM: OMAP4: MMC: no regulator off during probe for eMMC
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/hsmmc.c | 16 +---
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/i
On Mon, May 30, 2011 at 08:44, Santosh Shilimkar
wrote:
> On 5/30/2011 7:06 PM, Sergei Shtylyov wrote:
>>
>> Hello.
>>
>> Santosh Shilimkar wrote:
>>
>>> The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
>>
>> Please specify that commit's summary in parens -- for the human re
On Monday, May 30, 2011, Jean Pihet wrote:
> Rafael,
Hi,
> On Sat, May 28, 2011 at 11:01 AM, Rafael J. Wysocki wrote:
> > On Saturday, May 28, 2011, Kevin Hilman wrote:
> >> Some platforms wish to implement their PM core suspend code as
> >> modules. To do so, these functions need to be exporte
On 5/30/2011 7:06 PM, Sergei Shtylyov wrote:
Hello.
Santosh Shilimkar wrote:
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
Please specify that commit's summary in parens -- for the human readers.
Oh, and you don't need quotes around commit ID too.
Yes I missed tha
Hello.
Santosh Shilimkar wrote:
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
Please specify that commit's summary in parens -- for the human readers.
Oh, and you don't need quotes around commit ID too.
for OMAP2 and OMAP4 since it's really just noise in the boo
Tony,
On 5/30/2011 1:35 PM, Tony Lindgren wrote:
* Kevin Hilman [110527 14:24]:
FYI... I just found this, but won't be able to look into it until next
week, so if anyone needs a weekend debug project...
Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+
busybox initramfs
From: Laurent Pinchart
Subject: [PATCH 0/2] OMAP3 IOMMU fixes
Date: Mon, 30 May 2011 14:47:07 +0200
> Hi everybody,
>
> Here are two OMAP3 IOMMU fixes required to support big and/or unaligned memory
> buffers.
>
> Laurent Pinchart (2):
> omap3: iovmm: Work around sg_alloc_table size limitatio
The IOMMU virtual memory mapping API requires page-aligned buffers.
There's no hardware reason behind such a restriction. Remove it by
rounding the address of the first page entry down, and adding the offset
back to the IOMMU virtual address.
Signed-off-by: Laurent Pinchart
Cc: Hiroshi DOYU
---
sg_alloc_table can only allocate multi-page scatter-gather list tables
if the architecture supports scatter-gather lists chaining. ARM doesn't
fit in that category.
The IOMMU driver abuses the sg table structure only to hold page
addresses without ever passing the table to the device.
Use __sg_al
Hi everybody,
Here are two OMAP3 IOMMU fixes required to support big and/or unaligned memory
buffers.
Laurent Pinchart (2):
omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
omap3: iovmm: Support non page-aligned buffers in iommu_vmap
arch/arm/plat-omap/iovmm.c | 46 ++
While trying out V3.0-rc1, I noticed couple of regressions. Am
posting this in case anybody come across same issues.
1.OMAP MMC code keep throwing "Pbias Voltage is not same as LDO" error
continuously.
Balaji is planning post right fix for the same, but just
in case you get around this issue,
d
On 05/30/2011 04:01 AM, Vladimir Pantelic wrote:
[..]
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
I guess at the time that CHIP_IS_OMAP4430 was introduced it was totally
unthinkable that another 44xx based chip would ever exist?
I think it
Hi,
On Mon, May 30, 2011 at 2:56 PM, sureshbalijepalli
wrote:
>
> Hi,
> Iam very new to the omap platforms . recetly i got(pandaboard). I
> ported ubuntu on it .
> please direct me how can i make a croos compilation .
>
>
I am not clear what exactly you are looking for.. The websites
www.pandaboa
Op 29 mei 2011, om 23:04 heeft Steve Calfee het volgende geschreven:
> For instance Beagleboard xm uboot
> cannot access the ethernet because it is usb based, and uboot cannot
> access its own environment in flash - because it is running from a new
> microsd based flash system.
U-boot has suppo
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
for OMAP2 and OMAP4 since it's really just noise in the boot log
and PM init is always called.
Signed-off-by: Santosh Shilimkar
Cc: Kevin Hilman
---
Generated against mainline v3.0-rc1.
arch/arm/mach-omap2/pm24xx.c |1
Hi,
Iam very new to the omap platforms . recetly i got(pandaboard). I
ported ubuntu on it .
please direct me how can i make a croos compilation .
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Nishanth Menon wrote:
From: Aneesh V
Make all hwmod data used for OMAP4430 available for
the OMAP44XX class so that OMAP4460 can use them.
We will modify the required 4460 hwmod in further patch(es).
[n...@ti.com: just rebased to .39]
Signed-off-by: Nishanth Menon
Signed-off-by: Aneesh V
---
On 5/30/2011 4:15 AM, Paul Walmsley wrote:
On Fri, 27 May 2011, Tomi Valkeinen wrote:
However, VENC doesn't use the standard syscontrol mechanism, so that
cannot be done via omap_device interface anyway.
struct omap_hwmod_class has a .reset function pointer for this purpose.
It's already been
On 5/29/2011 11:04 PM, Steve Calfee wrote:
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman wrote:
"Cousson, Benoit" writes:
[...]
In general we do not want to reset nor idle an IP that was potentially
already properly configured by bootloader or early Linux boot code.
Actually, the opposit
On 5/30/2011 1:38 PM, Jean Pihet wrote:
On Mon, May 30, 2011 at 9:21 AM, Santosh Shilimkar
wrote:
Kevin,
On 5/27/2011 10:48 AM, Santosh Shilimkar wrote:
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
On Mon, May 30, 2011 at 9:21 AM, Santosh Shilimkar
wrote:
> Kevin,
>
> On 5/27/2011 10:48 AM, Santosh Shilimkar wrote:
>>
>> On 5/27/2011 4:32 AM, Kevin Hilman wrote:
>>>
>>> Move suspend wakeup timer from suspend path to be triggered based
>>> on clockevent suspend path.
>>>
>>> When gptimers are
On Mon, May 30, 2011 at 9:18 AM, Santosh Shilimkar
wrote:
> On 5/27/2011 4:32 AM, Kevin Hilman wrote:
>>
>> Remove OMAP3-specific register dumping feature from PM debug layer.
>> This is removed because:
>>
>> - it's ugly
>> - it's OMAP3-specific, and will obviously not scale to OMAP4+
>> - usersp
* Kevin Hilman [110527 14:24]:
> FYI... I just found this, but won't be able to look into it until next
> week, so if anyone needs a weekend debug project...
>
> Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+
> busybox initramfs) kernel on my 3430/n900 just fine. I the
On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/pm-debug.c | 119
>
> arch/arm/mach-omap2/pm.h | 4 -
> arch/arm/mach-omap2/pm24xx.c | 6 +-
> 3 files changed, 2 insertions(+),
On Mon, May 30, 2011 at 9:15 AM, Santosh Shilimkar
wrote:
> On 5/27/2011 4:32 AM, Kevin Hilman wrote:
>>
>> Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is
>> currently available as an OMAP-specific debugfs entry.
>>
>> This duplicates existing ARM-generic functionality avail
Rafael,
On Sat, May 28, 2011 at 11:01 AM, Rafael J. Wysocki wrote:
> On Saturday, May 28, 2011, Kevin Hilman wrote:
>> Some platforms wish to implement their PM core suspend code as
>> modules. To do so, these functions need to be exported to modules.
>
> Hmm. What happens if the module is not
Kevin,
On 5/27/2011 10:48 AM, Santosh Shilimkar wrote:
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
When gptimers are eventually converted to be a driver, the wakeup
timer feature can be made to be a dri
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Remove OMAP3-specific register dumping feature from PM debug layer.
This is removed because:
- it's ugly
- it's OMAP3-specific, and will obviously not scale to OMAP4+
- userspace /dev/mem-based tools (like omapconf) can do this much better
Fully agree
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Signed-off-by: Kevin Hilman
Do you plan to keep wroking the patch which dumps registers
before and after WFI ?
Ofcourse this patch is in your pm-debug branch.
For this change
Acked-by: Santosh Shilimkar
--
To unsubscribe from this list: send the
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is
currently available as an OMAP-specific debugfs entry.
This duplicates existing ARM-generic functionality available as a
boot-time option using the boot cmdline option 'hohlt'.
If run
42 matches
Mail list logo
