Changing it to 100kHz is needed to make more devices works properly. Controlling the TI DLP Pico projector[1] doesn't work properly at 400kHz, 100kHz and lower work fine. EDID readout is unaffected by this change.
[1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2234
Signed-off-by: Koen Kooi <koen@beagleboard.org>
From: Koen Kooi <koen@beagleboard.org>
Changing it to 100kHz is needed to make more devices works properly. Controlling the TI DLP Pico projector[1] doesn't work properly at 400kHz, 100kHz and lower work fine. EDID readout is unaffected by this change.
[1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2234
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Any comments on this patch?
regards,
Koen
Koen
Personally I would prefer it if this is configurable (either compile
time, but even better through e.g. a function call)
Actually is this an issue at the beagle side or at the pico side?
I guess pico and beagle communicate through the display data channel
on the video bus.
Is this a separate bus than the one that is externally available. If
so, they should be individually controllable.
Frans.
> From: Koen Kooi <koen@beagleboard.org>
>
> Changing it to 100kHz is needed to make more devices works properly.
> Controlling the TI DLP Pico projector[1] doesn't work properly at
> 400kHz, 100kHz and lower work fine. EDID readout is unaffected by
> this change.
>
> [1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2234
>
> Signed-off-by: Koen Kooi <koen@beagleboard.org>Any comments on this patch?
I2C-3 is only used for talking on DVI, right?
Which means EDID ... and maybe DLP/Pico, unless
someone uses it as an I2C adapter. (Which some
folk hack together on PCs...)
Seems harmless to me, but I'd add a comment
explaining why just 100 MHz. (The Pico manual
says 400 KHz should work.)
- Dave
From: Koen Kooi <koen@beagleboard.org>
Changing it to 100kHz is needed to make more devices works properly.
Controlling the TI DLP Pico projector[1] doesn't work properly at
400kHz, 100kHz and lower work fine. EDID readout is unaffected by
this change.[1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2234
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Any comments on this patch?
I2C-3 is only used for talking on DVI, right?
Which means EDID ... and maybe DLP/Pico, unless
someone uses it as an I2C adapter. (Which some
folk hack together on PCs...)Seems harmless to me, but I'd add a comment
explaining why just 100 MHz. (The Pico manual
says 400 KHz should work.)
The updated manual will say 400kHz won't work, the TI DLP engineers were the ones that designed the pico that pointed the i2c speed problem out to me 
I'd be happy to change the patch if needed, but I think the updated manual will take care of most issues.
regards,
Koen
Couldn't find it any more, but I am fairly sure I read somewhere that
some DVI devices only supports 100 khz i2c.
It also seems that the dvi i2c is also based upon access.bus which
according to wikipedia is also limited to 10 and 100 khz
FM
From: Koen Kooi <koen@beagleboard.org>
Changing it to 100kHz is needed to make more devices works properly.
Controlling the TI DLP Pico projector[1] doesn't work properly at
400kHz, 100kHz and lower work fine. EDID readout is unaffected by
this change.[1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2234
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Any comments on this patch?
I2C-3 is only used for talking on DVI, right?
Which means EDID ... and maybe DLP/Pico, unless
someone uses it as an I2C adapter. (Which some
folk hack together on PCs...)Seems harmless to me, but I'd add a comment
explaining why just 100 MHz. (The Pico manual
says 400 KHz should work.)The updated manual will say 400kHz won't work, the TI DLP engineers were the ones that designed the pico that pointed the i2c speed problem out to me
I'd be happy to change the patch if needed, but I think the updated manual will take care of most issues.regards,
Koen
Given that this port is only used on the DVI port for the BeagleBoard, I believe it is appropriate to set it to 100kHz as Koen has done.
That's what I meant to say (kHz not MHZ!) ... except, also add a
comment saying why the (un-obvious) restriction is being made.
Though I did note that since it's a nice level-shifted I2C, some
folk may want to use it for non-DDC purposes [1], where a 100 KHz
limit might not always be wanted.
- Dave
Op 24 jan 2009 om 21:30 heeft David Brownell <david-b@pacbell.net> het volgende geschreven:\
Given that this port is only used on the DVI port for the BeagleBoard,
I believe it is appropriate to set it to 100kHz as Koen has done.That's what I meant to say (kHz not MHZ!) ... except, also add a
comment saying why the (un-obvious) restriction is being made.
In the .c file or commit message?
Regards,
Koen
A one line comment in the C file.
Hi everyone,
Last week, I downloaded the 2.6.29-rc2 (http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=tag;h=d31ce8060b0e875179ba5ca1d40475dc2a082cc7) and compiled it for the BeagleBoard. Everything seems to run fine (I disabled video support because I don't use it). However, there doesn't seem to be audio (twl4030 audio) support for the BeagleBoard; the default configuration (omap3_beagle_defconfig) doesn't enable audio and when I tried to enable ALSA, there's no option for the twl4030 driver. Is audio not yet supported in the last GIT tree? What the latest tag/tree (v2.6.28-omap1???) I should use that has audio support for the BeagleBoard.
I have a few more questions so maybe you guys can help me. The questions I'm going to ask are mostly new and not already answered (I searched the group and coudn't find any answers); I'm sorry if any has been asked before and maybe you can point me in the right direction. I'm new to the OMAP3 processor; I just started experimenting with the BeagleBoard a few weeks back (I also have TI Mistral OMAP3EVM board but I'm using the BeagleBoard since our OMAP3 custom board is based on the BeagleBoard). For the last couple years, I worked on TI's Davinci processor; our project decided recently to go with the OMAP3 because it's more powerful and consumes less power. For this reason, I have to port all our existing software to our new OMAP3 custom board. For the Davinci processor, I used the 2.6.23 GIT version of the kernel (http://source.mvista.com/git/?p=linux-davinci-2.6.git) so I'm a little familiar with the kernel. Here are some questions I have
initially:
1) Is the X-loader really required? Can the BeagleBoard just boot straight to u-boot?
2) The BeagleBoard uses the twl4030 device for its audio (among other things); for our OMAP3 custom board, we're not using that, we're going to continue use the AIC33 codec (like what we used on our Davinci custom board). Is adding support for the AIC33 codec as simple as enabling that option in the OMAP3 GIT kernel configuration under ALSA? Or do I have to do a lot of porting? If so, what is the best approach, i.e. porting the AIC33 initialization/driver code for mthe Davinci GIT kernel into OMAP3 GIT kernel?
3) Is OSS audio API no longer supported? Our existing application uses the OSS audio API; the latest kernel seems to only support ALSA; is OSS emulation (on top of ALSA) working and/or reliable?
4) How reliable is the DSP bridge driver mentioned on the wiki page? On our Davinci board, we used TI's Code-Engine/DSP/BIOS DSPLINK driver to perform ARM-DSP IPC. This past week, I was able to download TI's DSPLINK (now open source, https://www-a.ti.com/downloads/sds_support/targetcontent/link/index.html) and build it with the default BeagleBoard 2.6.22-18 kernel and got the examples to run fine. I'm in the process of getting it to work with the latest OMAP3 GIT tree but I'm stuck now because I can't get the audio to work (my pre-first question).
OK, I think I've asked too many questions but hopefully someone can provide some advice and answers. Thanks in advance!!
Regards,
Andy
Hello,
Hi everyone,
Last week, I downloaded the 2.6.29-rc2
(http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=tag;
h=d31ce8060b0e875179ba5ca1d40475dc2a082cc7) and compiled it for the
BeagleBoard. Everything seems to run fine (I disabled video support
because I don't use it). However, there doesn't seem to be audio (twl4030
audio) support for the BeagleBoard; the default configuration
(omap3_beagle_defconfig) doesn't enable audio and when I tried to enable
ALSA, there's no option for the twl4030 driver. Is audio not yet supported
in the last GIT tree? What the latest tag/tree (v2.6.28-omap1???) I should
use that has audio support for the BeagleBoard.
You need to take this patch sent by Steve Sakoman:
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=80c509fdd74f3b158267374cc55156965c8bf930
This has been sent to l-o also, so you can take the patch from this mailing
list...
2) The BeagleBoard uses the twl4030 device for its audio (among other things); for our OMAP3 custom board, we're not using that, we're going to continue use the AIC33 codec (like what we used on our Davinci custom board). Is adding support for the AIC33 codec as simple as enabling that option in the OMAP3 GIT kernel configuration under ALSA? Or do I have to do a lot of porting? If so, what is the best approach, i.e. porting the AIC33 initialization/driver code for mthe Davinci GIT kernel into OMAP3 GIT kernel?
With ALSA System on Chip (ASoC) porting is pretty simple. There is
already driver for AIC33 (sound/soc/codecs/tlv320aic3x.c), ASoC OMAP
platfrom drivers (sound/soc/omap) and also machine drivers using AIC33
(sound/soc/omap/n810.c and sound/soc/davinci/davinci-evm.c).
So what you need is basically to write your own machine driver using
mostly copy-paste approach.
3) Is OSS audio API no longer supported? Our existing application uses the OSS audio API; the latest kernel seems to only support ALSA; is OSS emulation (on top of ALSA) working and/or reliable?
At least some few OSS applications I have tried were working fine with
OSS emulation.
Jarkko
You need to take this patch sent by Steve Sakoman:
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=80c509fdd74f3b158267374cc55156965c8bf930
This has been sent to l-o also, so you can take the patch from this mailing
list...
Thanks! So where is the official OMAP3 GIT tree located? The one you mentioned above has Steve's patch but the one (Steve's own link) mentioned on the wiki page doesn't. There are 2 or 3 OMAP3 GIT sites out there and I don't know which one is the "official" working one. I just noticed the one sponsored by Montavista is now obsolete.
Regards,
Andy
> 2) The BeagleBoard uses the twl4030 device for its audio (among other things);
for our OMAP3 custom board, we're not using that, we're going to continue use
the AIC33 codec (like what we used on our Davinci custom board). Is adding
support for the AIC33 codec as simple as enabling that option in the OMAP3 GIT
kernel configuration under ALSA? Or do I have to do a lot of porting? If so,
what is the best approach, i.e. porting the AIC33 initialization/driver code for
mthe Davinci GIT kernel into OMAP3 GIT kernel?With ALSA System on Chip (ASoC) porting is pretty simple. There is
already driver for AIC33 (sound/soc/codecs/tlv320aic3x.c), ASoC OMAP
platfrom drivers (sound/soc/omap) and also machine drivers using AIC33
(sound/soc/omap/n810.c and sound/soc/davinci/davinci-evm.c).So what you need is basically to write your own machine driver using
mostly copy-paste approach.> 3) Is OSS audio API no longer supported? Our existing application uses the
OSS audio API; the latest kernel seems to only support ALSA; is OSS emulation
(on top of ALSA) working and/or reliable?At least some few OSS applications I have tried were working fine with
OSS emulation.
Thanks for the advice and pointers. Hopefully, when I get my hands dirty in a few weeks and I get into troubles, people like you on this board can help.
Regards,
Andy
> You need to take this patch sent by Steve Sakoman:
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=
>80c509fdd74f3b158267374cc55156965c8bf930 This has been sent to l-o also,
> so you can take the patch from this mailing list...Thanks! So where is the official OMAP3 GIT tree located? The one you
mentioned above has Steve's patch but the one (Steve's own link) mentioned
on the wiki page doesn't. There are 2 or 3 OMAP3 GIT sites out there and I
don't know which one is the "official" working one. I just noticed the one
sponsored by Montavista is now obsolete.
The link above points to sound-2.6 (Takashi Iwai's tree), the official
ALSA/Sound tree.
AFAIK the official OMAP tree is:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
l-o tree is now at
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Looks like you already got good answers on #2 and #3, but I'll try to
answer #1 and #4 below...
Hi everyone,
Last week, I downloaded the 2.6.29-rc2 (http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=tag;h=d31ce8060b0e875179ba5ca1d40475dc2a082cc7) and compiled it for the BeagleBoard. Everything seems to run fine (I disabled video support because I don't use it). However, there doesn't seem to be audio (twl4030 audio) support for the BeagleBoard; the default configuration (omap3_beagle_defconfig) doesn't enable audio and when I tried to enable ALSA, there's no option for the twl4030 driver. Is audio not yet supported in the last GIT tree? What the latest tag/tree (v2.6.28-omap1???) I should use that has audio support for the BeagleBoard.
I have a few more questions so maybe you guys can help me. The questions I'm going to ask are mostly new and not already answered (I searched the group and coudn't find any answers); I'm sorry if any has been asked before and maybe you can point me in the right direction. I'm new to the OMAP3 processor; I just started experimenting with the BeagleBoard a few weeks back (I also have TI Mistral OMAP3EVM board but I'm using the BeagleBoard since our OMAP3 custom board is based on the BeagleBoard). For the last couple years, I worked on TI's Davinci processor; our project decided recently to go with the OMAP3 because it's more powerful and consumes less power. For this reason, I have to port all our existing software to our new OMAP3 custom board. For the Davinci processor, I used the 2.6.23 GIT version of the kernel (http://source.mvista.com/git/?p=linux-davinci-2.6.git) so I'm a little familiar with the kernel. Here are some questions I have
initially:1) Is the X-loader really required? Can the BeagleBoard just boot straight to u-boot?
It might be possible to configure the ROM bootloader to configure the
external RAM, but I'm not aware of any attempts to do this. X-load is
typically used to configure the external RAM then download u-boot. If
you download the Technical Reference Manual (spruf98b) and look at
Chapter 25 (Applications Processor Initialization), you'll find that
"configuration headers" are discussed in section 25.4.8.2. It could
be possible to create some configuration headers in the ROM code image
to initialize the external RAM and avoid using x-load, but no one in
the community has of yet bothered.
2) The BeagleBoard uses the twl4030 device for its audio (among other things); for our OMAP3 custom board, we're not using that, we're going to continue use the AIC33 codec (like what we used on our Davinci custom board). Is adding support for the AIC33 codec as simple as enabling that option in the OMAP3 GIT kernel configuration under ALSA? Or do I have to do a lot of porting? If so, what is the best approach, i.e. porting the AIC33 initialization/driver code for mthe Davinci GIT kernel into OMAP3 GIT kernel?
3) Is OSS audio API no longer supported? Our existing application uses the OSS audio API; the latest kernel seems to only support ALSA; is OSS emulation (on top of ALSA) working and/or reliable?
4) How reliable is the DSP bridge driver mentioned on the wiki page? On our Davinci board, we used TI's Code-Engine/DSP/BIOS DSPLINK driver to perform ARM-DSP IPC. This past week, I was able to download TI's DSPLINK (now open source, https://www-a.ti.com/downloads/sds_support/targetcontent/link/index.html) and build it with the default BeagleBoard 2.6.22-18 kernel and got the examples to run fine. I'm in the process of getting it to work with the latest OMAP3 GIT tree but I'm stuck now because I can't get the audio to work (my pre-first question).
If you look at the Angstrom Distribution, there are some recent
versions of the kernel where Codec Engine and Link have already been
integrated.
> 1) Is the X-loader really required? Can the BeagleBoard just boot straight to u-boot?
It might be possible to configure the ROM bootloader to configure the
external RAM, but I'm not aware of any attempts to do this. X-load is
typically used to configure the external RAM then download u-boot. If
you download the Technical Reference Manual (spruf98b) and look at
Chapter 25 (Applications Processor Initialization), you'll find that
"configuration headers" are discussed in section 25.4.8.2. It could
be possible to create some configuration headers in the ROM code image
to initialize the external RAM and avoid using x-load, but no one in
the community has of yet bothered.
Thanks for the response. In that case, I won't bother trying to get
rid of the X-loader. If we're designing our custom OMAP3 board using
a different RAM than that of the BeagleBoard (we're planning to use
POP RAM with NOR flash), do I need to modify the X-loader code to
recognize the RAM we're using or it can pretty much detect the RAM and
initially correctly? Also, the wiki page mentioned (besides boot from
MMC and USB) the built-in ROM bootloader can boot from serial; yet,
there seems to be little or none support for it. I'm planning to use
the serial method (seems like the best way to bring up a custom board
initially without depending on many other hardware to work) to load
the x-loader and u-boot. Is there any available serial utility to do
this? I have TI's Mistral OMAP3EVM development and its software tool
includes a serial utility but I can't get it to work with the
BeagleBoard. Our hardware engineer (he has probably posted on this
board the last couple weeks) is currently trying to use the ASSET
Boundary Scan software to access the BeagleBoard NAND flash and see if
he can read/erase/write/etc to it. When we get our new board, we
either have to use the serial boot method to get the x-loader/u-boot
working or the ASSET Boundary Scan software to flash x-loader/u-boot
on there; is getting one of the cheap available JTAG programmers
(BeagleBoardJTAG - eLinux.org) an easier method to initially
bring up a board? Thanks.
Regards,
Andy