All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: David Henningsson <david.henningsson@canonical.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph
Date: Tue, 27 Jul 2010 17:47:03 +0200	[thread overview]
Message-ID: <s5hmxtdvseg.wl%tiwai@suse.de> (raw)
In-Reply-To: <4C4EFC4C.40707@canonical.com>

At Tue, 27 Jul 2010 17:33:32 +0200,
David Henningsson wrote:
> 
> 2010-07-27 16:57, Jaroslav Kysela skrev:
> > A little off topic: hda-compiler . I'm playing with an idea to have the
> > hda-intel driver behaviour description (patches) in a firmware file.
> 
> There seem to be more than one thought in that area. Recently there has
> been some discussion (at least on Ubuntu Developer Summit) whether the
> device-tree[1] structure could be used in this area as well.
> Since we would then have separate device-tree files, we could update
> them independent of the kernel.

Did it come from Andy?  I've heard the idea to use OF from Grant in
the last year, and yes, this is feasible.  But I'm not sure how much
gain we'd get in the end.

For new devices, except for a few ones like AD or Conexant, we usually
write the generic tree parser so that BIOS information can be parsed
dynamically.  If BIOS information is broken or insufficient, we can
add some hints for correction, via sysfs for debugging or statically
in the code for production.  And the rest of the problem is very
specific to devices, and requires often some quirks in the parser
itself.  So, in this scenario, there is little room OF can help.
We'd like rather to avoid the static data, no matter in which form.

Meanwhile, the deployment of OF can be helpful if we move the whole
parser stuff to the user-space and push the parsed/compiled tree info
into the kernel (i.e. "firmware").  In such a case, OF representation
can be more flexible; and the kernel has already the infrastructure.


thanks,

Takashi

  reply	other threads:[~2010-07-27 15:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 11:31 hda-verb, hda-analyzer, hda-emu and codecgraph David Henningsson
2010-07-27 13:14 ` Takashi Iwai
2010-07-27 14:07   ` Jaroslav Kysela
2010-07-27 14:15     ` Takashi Iwai
2010-07-27 14:57       ` Jaroslav Kysela
2010-07-27 15:31         ` Takashi Iwai
2010-07-27 15:33         ` hda-compiler, was: " David Henningsson
2010-07-27 15:47           ` Takashi Iwai [this message]
2010-07-27 16:33             ` David Henningsson
2010-07-27 20:51               ` Takashi Iwai
2010-07-27 21:22                 ` Jaroslav Kysela

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=s5hmxtdvseg.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.