Hi Mark:
Thanks for your explanation.
On Fri, Sep 13, 2024 at 10:44 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> On Fri, Sep 13, 2024 at 08:02:02AM +0600, Binbin Zhou wrote:
> > On Thu, Sep 5, 2024 at 8:05 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> > > > +/*
> > > > + * es8323 register cache
> > > > + * We can't read the es8323 register space when we
> > > > + * are using 2 wire for device control, so we cache them instead.
> > > > + */
> > > > +static u16 es8323_reg[] = {
> > > > + 0x06, 0x1C, 0xC3, 0xFC, /* 0 */
> > > > + 0xC0, 0x00, 0x00, 0x7C, /* 4 */
>
> > > There's a bunch of regmap reimplementation in the driver, the cache and
> > > I/O code all looks totally generic. Just use regmap.
>
> > Sorry, I don't really understand this point.
> > Do you mean to use regmap_read()/regmap_write() instead of
> > snd_soc_component_read()/snd_soc_component_write()?
>
> > If so, are there any rules for using snd_soc_component_xxx()?
>
> No, it's fine to use the component wrappers if you happen to have a
> component to hand. What's an issue is things like writing your own
> register cache code (the above bit is part of an open coded cache
> implementation), or I2C read/write functions if there's not something
> unusual with how the device does I/O.
Indeed, I misunderstood it before. As I understand it, we should use
regmap_config.reg_defaults instead of
snd_soc_component_driver.{read/write}.
Thanks.
Binbin
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]