mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Geoffrey Wossum <geoffrey@pager.net>
To: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: kernel@avr32linux.org, linux-kernel@vger.kernel.org
Subject: Re: AT32 ASoC Driver Patches on alsa-devel
Date: Thu, 5 Jun 2008 12:10:47 -0500	[thread overview]
Message-ID: <200806051210.47986.geoffrey@pager.net> (raw)
In-Reply-To: <20080605182409.6285ee4b@hskinnemo-gx745.norway.atmel.com>

On Thursday 05 June 2008 11:24:09 am Haavard Skinnemoen wrote:
> Geoffrey Wossum <geoffrey@pager.net> wrote:
> > On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
> > > Geoffrey Wossum <geoffrey@pager.net> wrote:

> > To paraphrase Andy Tanenbaum, the great thing about standards is there's
> > so many to choose from.
>
> Heh.

I quote that a lot.  Along with Philip K. Dicks's "Sometimes an appropriate 
response to reality is to go insane."

> Hmm...I take it you're talking about the SSC driver? That is supposed
> to be usable on AT91 as well, so perhaps the right thing to do is
> porting the AT91 driver over to use it.

Yes, the SSC code.  It'd be cool if it abstracted out even more, but I 
understand the difficulties in making that happen.

> I see you've added a few SSC-related constants...those should probably
> go into include/linux/atmel-ssc.h.

I wasn't sure if having these in atmel-ssc.h fit with ya'lls plans for it, but 
if it does, great.


> >  But I needed an AT32 layer quickly, and I don't
> > have any AT91 hardware, so I couldn't really go mucking about in the AT91
> > code since I wouldn't be able to test it.  I don't feel especially bad,
> > though, since at91_mci.c and atmel-mci.c commit essentially the same sin.
>
> Yeah, I guess you're right. I do have a long-term goal merging those
> two drivers, but it will be a bit difficult because the DMA interface
> is quite different.

The PDC interface is closer (if not exactly the same).  One issue is the SSC 
interface, which you have said could be used on the AT91.  After that, the 
main differences are that the DMA buffer has to be allocated differently, and 
the mmap() implementation is different.

> That's certainly a good reason, though I don't understand why reusing
> code isn't important on non-SoC platforms.

Please don't take my answer as authoritative, but I think it's because on a 
typical PC the exact CODEC being used tends to be hidden from you.  And you 
normally don't use I2S or PCM directly.  A PC sound card is more of a black 
box.

> Another good reason, but again I don't understand why power management
> isn't important on PCs.

It is important, and becoming more important all the time.  I think the main 
reasons this isn't a priority on a PC right now are:
 - I think PC sound cards tend to be black boxes regarding power consumption, 
especially those white box cards you can get at Fry's and similar places.   
 - A few extra mA aren't as important when you're plugged in, or you have a 
laptop, which has a honkin' big battery compared to a PDA type device
 - A few extra mA are dwarfed by other things in a PC, like the processor.  My 
Intel T7200 burns 34 W at full tilt.  The AT32AP7000 is going to be something 
like, what, 250 mW?  Even throttled all the way down my T7200 is going to be 
13 W.  Turning off all or part of the CODEC and saving 15 - 30 mW is a lot 
bigger deal on the AVR32 than it would be on my laptop.
 - As you say, there is more code due to the power management, which requires 
modifying a lot of working drivers, for little benefit in the forseeable 
future.

---
Geoffrey




  parent reply	other threads:[~2008-06-05 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200806050851.47319.geoffrey@pager.net>
2008-06-05 14:22 ` Haavard Skinnemoen
2008-06-05 15:00   ` Geoffrey Wossum
2008-06-05 16:24     ` Haavard Skinnemoen
2008-06-05 16:54       ` Takashi Iwai
2008-06-05 17:06         ` Haavard Skinnemoen
2008-06-06  6:15           ` Takashi Iwai
2008-06-05 17:10       ` Geoffrey Wossum [this message]
2008-06-06  9:29         ` Haavard Skinnemoen
2008-06-06 12:07           ` Mark Brown
2008-06-06 14:32           ` Geoffrey Wossum
2008-06-05 15:22   ` Mark Brown
2008-06-05 16:40     ` Haavard Skinnemoen
2008-06-06 11:37       ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200806051210.47986.geoffrey@pager.net \
    --to=geoffrey@pager.net \
    --cc=haavard.skinnemoen@atmel.com \
    --cc=kernel@avr32linux.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®