From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>,
alsa-devel@alsa-project.org,
Takashi Sakamoto <o-takashi@sakamocchi.jp>
Subject: Re: Prague Audio miniconference - topics for discussion?
Date: Thu, 21 Sep 2017 09:43:34 +0100 [thread overview]
Message-ID: <20170921084334.4tkdvysf4nfo5yip@localhost.localdomain> (raw)
In-Reply-To: <20170920174505.64nieg6plut36cl5@sirena.co.uk>
On Wed, Sep 20, 2017 at 06:45:05PM +0100, Mark Brown wrote:
> As previously announced[1] by Takashi our annual Linux audio
> miniconference will be held this year at the SuSE offices in Prague on
> 27th October (the week of ELC-E). Thanks again to SuSe for sponsoring
> this. As with previous years let's pull together an agenda through a
> mailing list discussion - if people could reply to this mail with any
> topics they'd like to discuss we can take it from there. Of course if
> we can sort things out more quickly via the mailing list that's even
> better!
>
> I'll start things off by mentining the TLV issues that Sakamoto-san was
> raising - do we have any better ideas to handle larger binary controls
> than what's currently being done?
>
> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/124623.html
Yeah I would second that, I have a patch chain that pulls some
bits of Sakamoto-san's previous work and updates the usage in the
ADSP driver that I was hoping to send out for comments before the
meeting. Don't think I will be able to get it out this week but
probably next week. Although that is really just tidying up the
current solution rather than looking at other alternatives.
I would also quite like to start some discussions about what
might be some sensible first steps towards Lar's plans around
rate domains.
Also I might like to have a quick discussion around ways of
handling very large register maps. Obviously, the size of the
regmaps on our CODECs are starting to annoy more than a few
maintainers and it would be good to have a quick discussion on
sensible ways to break that down and make it more managable for
review. Primarily, I have been thinking about grouping more of
the registers with the drivers that are using them and having
less of it centralised in large header files and tables within
the MFD system.
Thanks,
Charles
next prev parent reply other threads:[~2017-09-21 8:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 17:45 Prague Audio miniconference - topics for discussion? Mark Brown
2017-09-21 8:43 ` Charles Keepax [this message]
2017-09-29 0:45 ` Eric Laurent
2017-10-02 14:57 ` Takashi Sakamoto
2017-10-03 9:51 ` Peter Ujfalusi
2017-10-06 12:55 ` Takashi Iwai
2017-10-23 12:36 ` 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=20170921084334.4tkdvysf4nfo5yip@localhost.localdomain \
--to=ckeepax@opensource.cirrus.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=o-takashi@sakamocchi.jp \
--cc=tiwai@suse.de \
/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