Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx]
>> Sent: Thursday, September 09, 2010 8:52 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@xxxxxxxxxxxxxxx; tony@xxxxxxxxxxx
>> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
>> 
>> Santosh Shilimkar <santosh.shilimkar@xxxxxx> writes:
>> 
>> > This series has few fixes, hacks to get omap4 es2.0 working
>> > on mainline. The patches are generated against the mainline
>> > 2.6.36-rc3.
>> 
>> Hi Santosh, thanks for this...
>> 
>> > The series is boot tested tested on 4430 SDP, Blaze with
>> > omap_4430sdp_defconfig with file over NFS and MMC.
>> >
>> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
>> > SDPs. Same observation with Panda
>> >
>> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
>> > boot hangs. Same observation with Panda
>> 
>> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>>
> I observed the same with MMC. Ramdisk boot worked for me on PANDA.

Note that I said "now working".  I think you read my message as "not
working."

IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
your series to current l-o master, and it works.

>> However, rootfs over NFS is not yet working, presumably because the
>> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
>> properly.
>>
> This is correct. We need to get the MMC fixed o.w panda is unusable in
> it's current form.
>
>> 
>> > [    5.794616] regulator_init_complete: incomplete constraints, leaving
>> VUSIM on
>> > [    5.802764] regulator_init_complete: incomplete constraints, leaving
>> VPP on
>> > [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
>> 00:53:12 UTC (9      )
>> > [    5.849304] mmc0: new high speed MMC card at address 0001
>> > [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
>> > [    5.862091]  mmcblk0: unknown partition table
>> > [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
>> latency 0: 6
>> 
>> Based on this message, this is not a mainline kernel, but one where the
>> omap_device conversion for MMC has been applied.
>> 
> This is mainline 2.6.36-rc3.... 
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

Then I don't understand where the 'omap_device: mmci-omap-hs.1:...'
message is coming from in your kernel boot log.

It should not be present in a mainline kernel as the MMC conversion to
hwmod/omap_device is not in mainline, or linux-omap.

That's why I assumed your boot log excerpt came from an internal kernel
and not a mainline kernel.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux