Mailinglist Archive: radeonhd (333 mails)

[Mark Struberg <struberg@xxxxxxxx>]

I came across the following kernel-2.6.27 commit in ALSA:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e6dd47bf365f8f7bccea10f22fbbdbecce429e8

I'm curious if this overlaps/how this combines with your work?

txs and LieGrue,
strub

--- Michael Cree <mcree@xxxxxxxxxxxx> schrieb am Fr, 10.10.2008:

> Von: Michael Cree <mcree@xxxxxxxxxxxx>
> Betreff: Re: [radeonhd] HDMI support including Audio
> An: "Christian König" <deathsimple@xxxxxxxxxxx>
> CC: "radeonhd" <radeonhd@xxxxxxxxxxxx>
> Datum: Freitag, 10. Oktober 2008, 1:44
> On 10/10/2008, at 11:31 AM, Christian König wrote:
> > Am Freitag, den 10.10.2008, 09:46 +1300 schrieb
> Michael Cree:
> > > Right, I have also tried this patch (plus patch
> number 0002). System
> > > is Alpha architecture, with HD 2400 Pro card,
> RV610, which admittedly
> > > doesn't match the list of compatible hardware
> given for the patch,  
> > > but
> > > thought I'd try anyway.
> > In theory this path should work on RV610 just fine, it
> was tested
> > successfully on RV630 wich is AFAIK not so much
> different.
>
> Good.
>
> > > I verified that the sound files (signed 16bit,
> 44.1kHz, pcm) would
> > > play through my other sound devices (on board
> sound chip, and a cheap
> > > surround sound card), but aplay would hang and not
> return when  
> > > playing
> > > via the ATI HDMI sound device (was breakable with
> ctrl-c).
> > > Examination of /proc/interrupts revealed that
> interrupts were not
> > > clocking up for the ATI HDMI interrupt. This is
> evidence that things
> > > are not working as they should.
> > That's odd, even without this patch interrupts are
> initialized at  
> > bootup
> > by atombios. But since your system is alpha based i
> don't even know  
> > how
> > video gets initialized, does it use some kind of x86
> emulation or does
> > this rely on radeonhd to fully setup video stuff?
>
> I've got the video card plugged in a miata variant
> alpha and the SRM  
> (the alpha equivalent of a BIOS) does have x86 emulation
> for the  
> purposes of posting video cards, but it is far too old and
> can't post  
> the RV610 video card.  I bring the system up on serial port
> console.   
> My understanding is it is the X server that contains the
> x86 emulation  
> code that POSTs the video card; at least the display powers
> up and the  
> Gnome login window appears when X is started.  This is a
> system that  
> would definitely benefit from having the video card
> initialisation  
> code in the kernel rather than in X!  The initialisation of
> the card  
> is not perfect; the display appears with all the colours
> all mixed  
> up.  Running 'xgamma -gamma 1.0' repeatedly, slowly
> fixes up the  
> colours until the display is quite useable and seems to be
> working in  
> all other aspects.
>
> I do have another slightly newer Alpha on which the SRM can
> POST the  
> RV610 video card, but other issues arise with using the
> card, and its  
> my main production system, so require better stability and
> features  
> than radeonhd can provide at the moment.
>
> > Could you make of register dump with rhd_dump of the
> 7300-73ff range?
> > Could you also send me a log with X started with the
> "-logverbose 7"
> > option? Maybe i can do something about this.
>
> Not at the moment as I am not at the machine.  I'll try
> and have a go  
> at this later today when I get home.
>
> I also noted a number of "unaligned trap"
> warnings appearing in the  
> kernel log due to the Xorg process.  I don't recall
> seeing them prior  
> to this date, but will need to investigate further to
> verify whether  
> they are due to the latest radeonhd plus audio.  The
> unaligned traps,  
> on Alpha, are not a show stopper, it just means the kernel
> emulated a  
> misaligned memory access the CPU couldn't perform. The
> main detriment  
> is a large performance hit. But I understand that on the
> Sparc  
> platform misaligned accesses result in shutting down the
> process that  
> generated them so ultimately, one should avoid them, if you
> want  
> generally portable code.  I will investigate further to
> verify whether  
> the radeonhd driver is causing them, or whether it is
> something else  
> in Xorg.
>
> Thanks for the clarification of DVI versus HDMI.
>
> Michael.
>
> --
> To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
> For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx


     
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx