Which git to clone for testing prior to submitting bugs?

Which git to clone for testing prior to submitting bugs?

[linux]

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?

Thank You

John Andrews
linux@johnea.net

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

On Thu, Sep 27, 2012 at 12:19 PM,  <linux@johnea.net> wrote:
>
> 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.

"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..

> 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?

Regards,

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

Re: Which git to clone for testing prior to submitting bugs?

[linux]

On 09/27/2012 11:25 AM, Robert Nelson wrote:
> On Thu, Sep 27, 2012 at 12:19 PM,<linux@johnea.net>  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?

Thanks again!

johnea

Re: Which git to clone for testing prior to submitting bugs?

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

Hi,

On Thu, Sep 27, 2012 at 11:56:51AM -0700, linux@johnea.net wrote:
> On 09/27/2012 11:25 AM, Robert Nelson wrote:
> >On Thu, Sep 27, 2012 at 12:19 PM,<linux@johnea.net>  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 ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Which git to clone for testing prior to submitting bugs?

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [120927 12:01]:
> 
> 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.

Yes
 
> Tony is DM3730 supported in mainline ?

Yes

Tony

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

On Thu, Sep 27, 2012 at 1:56 PM,  <linux@johnea.net> wrote:
> On 09/27/2012 11:25 AM, Robert Nelson wrote:
>>
>> On Thu, Sep 27, 2012 at 12:19 PM,<linux@johnea.net>  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.

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..

Looking at the 3.4.4 commit log
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-3.4.y;pg=5

No omapdss changes...

>
> 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 it's for arm/omap side tony's tree:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary

For the display:
http://gitorious.org/linux-omap-dss2/linux

But everything is now based on mainline..

Regards,

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

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

>> 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.
>
> 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..

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...

Regards,

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

Re: Which git to clone for testing prior to submitting bugs?

[linux]

On 09/27/2012 12:39 PM, Robert Nelson wrote:

>>
>> 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...

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.

I just received a kernel to test from the archlinuxarm devs, if spidev is still missing, I'll pass along your advice regarding CONFIG_OMAP_RESET_CLOCKS.

Thanks again for your help! I'll follow up with the results...

johnea

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

On Thu, Sep 27, 2012 at 3:16 PM,  <linux@johnea.net> wrote:
> On 09/27/2012 12:39 PM, Robert Nelson wrote:
>
>>>
>>> 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...
>
>
> 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.

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 ;) ..)

But at the same time, that was using a nice feature (hi speed pll:
.dispc_fclk_src = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,) to get a
higher pixel clock's on 3.2/3.4 to easier support displays that needed
an exact pixel clock. However since we didn't push that mainline and
no other board actually used that in mainline, it was wiped on a
cleanup (2). ;)

1: https://github.com/RobertCNelson/stable-kernel/blob/v3.5.x/patches/beagle/0001-beagleboard-reinstate-usage-of-hi-speed-PLL-divider.patch
2: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=b6e695abe710ee1ae248463d325169efac487e17

Regards,

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

Re: Which git to clone for testing prior to submitting bugs?

[linux]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

On 09/27/2012 01:41 PM, Robert Nelson wrote:
> On Thu, Sep 27, 2012 at 3:16 PM,<linux@johnea.net>  wrote:
>> On 09/27/2012 12:39 PM, Robert Nelson wrote:
>>
>>>>
>>>> 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..
>>>

>>>
>>> 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

>>
>> "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
>>

>
> 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.

Thanks again for your insight!

johnea


[-- Attachment #2: config-3.5.4-archarm.gz --]
[-- Type: application/gzip, Size: 23130 bytes --]

[-- Attachment #3: dmesg-3.5.4.txt.gz --]
[-- Type: application/gzip, Size: 7329 bytes --]

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

On Fri, Sep 28, 2012 at 1:49 PM,  <linux@johnea.net> wrote:
> On 09/27/2012 01:41 PM, Robert Nelson wrote:
>>
>> On Thu, Sep 27, 2012 at 3:16 PM,<linux@johnea.net>  wrote:
>>>
>>> On 09/27/2012 12:39 PM, Robert Nelson wrote:
>>>
>>>>>
>>>>> 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..
>>>>
>>>>
>
>>>>
>>>> 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
>
>
>>>
>>> "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
>>>
>
>>
>> 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.

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

> 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/

Re: Which git to clone for testing prior to submitting bugs?

[linux]

On 09/28/2012 12:18 PM, Robert Nelson wrote:
> 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
>
>> >  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/

Thanks Robert!

I passed along to the distro devs to include in today's build.

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

johnea

Re: Which git to clone for testing prior to submitting bugs?

[johnea]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

On 09/28/2012 12:46 PM, linux@johnea.net wrote:
> On 09/28/2012 12:18 PM, Robert Nelson wrote:
>> 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
>>
  
> 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...

johnea

[-- Attachment #2: config-3.5.4-archarm-3.gz --]
[-- Type: application/gzip, Size: 25137 bytes --]

[-- Attachment #3: dmesg-3.5.4-3.gz --]
[-- Type: application/gzip, Size: 6911 bytes --]

Re: Which git to clone for testing prior to submitting bugs?

[Robert Nelson]

> 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

Tested on my Beagle xM...

Regards,

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

Re: Which git to clone for testing prior to submitting bugs?

[linux]

On 10/01/2012 09:50 AM, Robert Nelson wrote:
> 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

Thank You Robert!

Starting a new build now...

johnea

Re: Which git to clone for testing prior to submitting bugs?

[linux]

On 10/01/2012 09:57 AM, linux@johnea.net wrote:
> On 10/01/2012 09:50 AM, Robert Nelson wrote:
>> 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
>

That did it! We've got X running on BeagleboardxM DVI with 3.5.4.

We're also starting testing of 3.6.0 this afternoon, since it's official now. Although the main thing for my application was having buddy=spidev and working DVI video in the same kernel, which we now have with 3.5.4.

Thank you again Robert for your patient support!

johnea