Which git to clone for testing prior to submitting bugs?

Hello,

We're developing a system based on DM3730, and using Beagleboard-xM as a prototype platform.

The 3.2 series kernels provided a working video output on Beagleboard-xM integrated HDMI connector.

We use the kernel parameters: omapfb.mode=dvi:800x480MR-24@60 omapfb.vram=0:6M,1:2M,2:2M omapdss.def_disp=dvi

We upgraded to kernel 3.4.3 in order to take advantage of the kernel
parameter: buddy=spidev

This provided spidev access without requiring that we build a custom kernel.

However in the 3.4 series, dvi output no longer works.

In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore.

I'd like to test the latest appropriate kernel prior to considering these issues as current bugs.

Can someone please advise which git tree to clone, for testing and possible bisect, prior to reporting bugs to this list?

Quoted 5 lines · On Thu, Sep 27, 2012 at 12:19 PM,<[email protected]> wrote:

Hello,

In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore.

"buddy=xyz" is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out..

Quoted 11 lines · Robert Nelson

Quoted 5 lines · On Thu, Sep 27, 2012 at 12:19 PM,<[email protected]> wrote:

Hello,

In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore.

"buddy=xyz" is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out..

Thanks Robert,

The 3.4.4 kernel is plain vanilla plus:

http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz

We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include:

http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz

We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format.

If we still experience issues, I'm trying to understand what to clone to be relevant to this list.

Which tree are patches submitted against here?

If you want to try with the public kernel, then try Linus' tree
(http://git.kernel.org/linus) but I'm not sure if we have beagle XM in mainline yet.

Tony is DM3730 supported in mainline ?

Quoted 6 lines · Robert Nelson

Quoted 4 lines · On Thu, Sep 27, 2012 at 12:19 PM,<[email protected]> wrote:

Hello,

Quoted 8 lines

Quoted 2 lines

In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore.

"buddy=xyz" is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out..

Thanks Robert,

The 3.4.4 kernel is plain vanilla plus:

http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz

We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include:

http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz

We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format.

If we still experience issues, I'm trying to understand what to clone to be relevant to this list.

Which tree are patches submitted against here?

Quoted 6 lines

Thanks Robert,

The 3.4.4 kernel is plain vanilla plus:

http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz

Quoted 7 lines

We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include:

http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz

We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format.

Ah, so my external patchset... Well, for the patch, nothing actually changed between 3.4.3-x1 -> 3.4.4-x1... (besides the stable patchset)

https://github.com/RobertCNelson/stable-kernel/commits/v3.4.x/

(the 3 commits are related to scripts in that git repo.)

So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it..

Quoted 4 lines

So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it..

https://github.com/archlinuxarm/PKGBUILDs/commit/68a9e5a1609fde10a2f31dac8df211f0c3874eb7

It looks like they disabled CONFIG_OMAP_RESET_CLOCKS

I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins...

Quoted 7 lines · Robert Nelson

Quoted 4 lines

So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it..

Quoted 6 lines

https://github.com/archlinuxarm/PKGBUILDs/commit/68a9e5a1609fde10a2f31dac8df211f0c3874eb7

It looks like they disabled CONFIG_OMAP_RESET_CLOCKS

I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins...

Thank you very much Robert!

I found this in your 3.5 series patchset logs:

"beagle: video works now, had to drop the hi-speed pll divider, as the infastructure for it looks to have been removed"

https://github.com/RobertCNelson/stable-kernel/commit/e7c8d9e8894997ae6a1ad9c83292ed75c5ac32c5

Which makes me think 3.5.4 on the beagle with your patches will have DVI again.

Quoted 9 lines · On Thu, Sep 27, 2012 at 3:16 PM,<[email protected]> wrote:

Quoted 7 lines · Robert Nelson

Quoted 4 lines

So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it..

Quoted 4 lines

Quoted 4 lines

It looks like they disabled CONFIG_OMAP_RESET_CLOCKS

I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins...

Quoted 4 lines

"beagle: video works now, had to drop the hi-speed pll divider, as the infastructure for it looks to have been removed"

Quoted 2 lines

https://github.com/RobertCNelson/stable-kernel/commit/e7c8d9e8894997ae6a1ad9c83292ed75c5ac32c5

Correct, dropping that specific patch (1), got 3.5.x working on my beagle again. .( i was distracted with an another project, so i was a little late in testing/stabilizing 3.5.x when porting the v3.4.x patchset ;) ..)

Quoted 13 lines · Robert Nelson

Quoted 11 lines · On Thu, Sep 27, 2012 at 3:16 PM,<[email protected]> wrote:

Quoted 8 lines · Robert Nelson

Quoted 4 lines

So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it..

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

It looks like they disabled CONFIG_OMAP_RESET_CLOCKS

I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins...

Corrected, now: CONFIG_OMAP_RESET_CLOCKS=y

Quoted 5 lines

Quoted 5 lines

"beagle: video works now, had to drop the hi-speed pll divider, as the infastructure for it looks to have been removed"

Quoted 9 lines

Quoted 2 lines

https://github.com/RobertCNelson/stable-kernel/commit/e7c8d9e8894997ae6a1ad9c83292ed75c5ac32c5

Correct, dropping that specific patch (1), got 3.5.x working on my beagle again. .( i was distracted with an another project, so i was a little late in testing/stabilizing 3.5.x when porting the v3.4.x patchset ;) ..)

3.5.4 is booting on beagle xM with the patchset:

http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz

buddy=spidev is working again (Thank You)

However I'm still not seeing DVI console 8-(

These messages appear during boot:

[    0.000000] Kernel command line: console= mpurate=auto buddy=spidev

camera=none vram=18MB omapfb.mode=dvi:800x480MR-24@60 omapfb.vram=0:6M,1:6M,2:6M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rootfstype=ext2 rootwait

[    0.190155] Could not look up dss_hdmi hw_mod

[   10.605987] omapdrm: module is from the staging directory, the quality is
unknown, you have been warned.
[   10.682647] omapdrm omapdrm.0: DMM not available, disable DMM support
[   10.682739] omapdrm omapdrm.0: dvi has no driver.. skipping it
[   10.682769] omapdrm omapdrm.0: lcd has no driver.. skipping it
[   10.815246] fb0: omapdrm frame buffer device
[   10.815338] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0

Once booted, /dev/fb0 is present, but no fb1 or fb2.

The display never even blinks during reboot. No console output appears when I use "console=" and a login prompt is never presented.

Attached are config.gz from running system and gz'd complete dmesg output (hope attachments are OK on the list).

There's another 3.5.4 build scheduled on the panda build farm this afternoon. If you have any config modification suggestions, they'd be very gratefully received.

Ah, so looking at the config, ARCH switched to omapdrm... It kinda works in v3.5.x, but i'd wait till a few more releases...

So, based on that config, they have both "CONFIG_FB_OMAP2" and "CONFIG_DRM_OMAP" enabled.. That's a no-no...

CONFIG_DRM_OMAP
http://cateee.net/lkddb/web-lkddb/DRM_OMAP.html
depends on: ( CONFIG_DRM&& ! CONFIG_CONFIG_FB_OMAP2 )&& ( CONFIG_ARCH_OMAP2PLUS )

Option 1: Stay with omapfb

CONFIG_FB_OMAP2=m -> CONFIG_FB_OMAP2=y
disable: CONFIG_DRM_OMAP

Option 2: Go Experimental route with omapdrm

CONFIG_DRM_OMAP=m
CONFIG_DRM_OMAP_NUM_CRTCS=1

disable: CONFIG_FB_OMAP2

Quoted 6 lines

Quoted 6 lines

Attached are config.gz from running system and gz'd complete dmesg output (hope attachments are OK on the list).

There's another 3.5.4 build scheduled on the panda build farm this afternoon. If you have any config modification suggestions, they'd be very gratefully received.

Also, if your running that config on pre-es (omap4430) panda's..
CONFIG_OMAP4_ERRATA_I688=y& CONFIG_ARCH_HAS_BARRIERS=y

and save your self some debugging time...;)

Regards,

-- Robert Nelson http://www.rcn-ee.com/

Quoted 18 lines · Robert Nelson

Ah, so looking at the config, ARCH switched to omapdrm... It kinda works in v3.5.x, but i'd wait till a few more releases...

So, based on that config, they have both "CONFIG_FB_OMAP2" and "CONFIG_DRM_OMAP" enabled.. That's a no-no...

CONFIG_DRM_OMAP
http://cateee.net/lkddb/web-lkddb/DRM_OMAP.html
depends on: ( CONFIG_DRM&& ! CONFIG_CONFIG_FB_OMAP2 )&& (
CONFIG_ARCH_OMAP2PLUS )

Option 1: Stay with omapfb

CONFIG_FB_OMAP2=m -> CONFIG_FB_OMAP2=y
disable: CONFIG_DRM_OMAP

Option 2: Go Experimental route with omapdrm

Quoted 5 lines

CONFIG_DRM_OMAP=m
CONFIG_DRM_OMAP_NUM_CRTCS=1

disable: CONFIG_FB_OMAP2

I'll follow up once I'm running the new version...

Good morning,

We opted for the "Stay with omapfb", and disabled CONFIG_DRM_OMAP.

Now the dev tree is showing all 3 fb devices, but still no video out 8-(

Boot messages include:

[root@apm002 johnea]# dmesg | grep omapfb

[    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=auto
buddy=spidev camera=none vram=18MB omapfb.mode=dvi
omapfb.vram=0:6M,1:6M,2:6M omapdss.def_disp=dvi root=/dev/mmcblk0p2
rootfstype=ext2 rootwait
[    3.165069] omapfb omapfb: no driver for display: dvi
[    3.165130] omapfb omapfb: no driver for display: lcd
[    3.165161] omapfb omapfb: cannot parse default modes

The "cannot parse default modes" message was eliminated by removing "omapfb.vram=0:6M,1:6M,2:6M" from the boot params.

This made me wonder if the omapfb boot params expected by 3.5.4 had changed. So I tried a bunch of different permutations of boot params, with no effect other than eliminating the "default modes" message mentioned above.

I tried digging into the source to determine currently accepted omapfb boot params, but had no success.

It seems like we're really close. The latest config.gz and tar'd dmesg from the running system are attached.

Thank You again! for any advise on config, boot param, or other changes that could make beagle DVI video work with 3.5.4...

You guys are very close... Your "config-3.5.4-archarm-3" config just needed one more change:

CONFIG_PANEL_TFP410=m -> CONFIG_PANEL_TFP410=y

Quoted 4 lines · Robert Nelson

You guys are very close... Your "config-3.5.4-archarm-3" config just needed one more change:

CONFIG_PANEL_TFP410=m -> CONFIG_PANEL_TFP410=y