On Wed, Jul 17, 2019 at 6:15 PM Angus Ainslie <angus@xxxxxxxx> wrote: > > On 2019-07-17 09:06, Daniel Baluta wrote: > > On Wed, Jul 17, 2019 at 5:33 PM Lucas Stach <l.stach@xxxxxxxxxxxxxx> > > wrote: > >> > >> Hi Daniel, > >> > >> Am Mittwoch, den 17.07.2019, 17:16 +0300 schrieb Daniel Baluta: > >> > > On Wed, Jul 17, 2019 at 1:59 PM Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > >> > > > >> > > The SAI block on the i.MX8M moved the register layout, as 2 version > >> > > registers were added at the start of the register map. We deal with > >> > > this by moving the start of the regmap, so both register layouts > >> > > look the same to accesses going through the regmap. > >> > > > >> > > Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx> > >> > > >> > This is a little bit tricky. We need the verid register in order > >> > to differentiate IPs which can support 1:1 ratio for bclk:mclk > >> > >> And this patch doesn't prevent this usage. If needed we can just read > >> the verid via a plain readl on the base mapping in the probe function > >> and cache it in struct fsl_sai. This seems way less intrusive than > >> carrying a register offset through all of the regmap accessors and > >> validation functions. I simply haven't implemented it in this patch, > >> as > >> I had no need for it right now. > > > > I must admit this is a very clever idea! Anyhow, I'm having some > > concerns > > because unfortunately not all registers were shifted by 8 bytes. > > > > See: imx6sx [1] (page 3575) and imx8X [2] (page 5512) RMs. > > > > We have something like this: > > > > i.mx6 SX: > > > > 00: TCSR > > 04: TCR1 > > 08: TCR2 > > 0C: TCR3 > > .... > > 60: TMR > > 80: RCSR > > > > i.mx 8X > > > > 00: VERID > > 04: PARAM > > 08: TCSR > > 0C: TCR1 > > ... > > 60: TMR > > 88: RCSR > > > > We could split it into an upper and a lower regmap. Only the lower would > need the version register offset. That would work but will be unnecessary complicated. Let me send the imx8M support as we implemented in our tree by Friday. It has the disadvantage that we've wrapped all shifted register with a macro but I don't see other solution. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
