On Thu, 7 May 2020 14:13:42 +0800 "Ramuthevar, Vadivel MuruganX" <vadivel.muruganx.ramuthevar@xxxxxxxxxxxxxxx> wrote: > Hi Boris, > > Thank you very much for the review comments and your time... > > On 7/5/2020 1:28 pm, Boris Brezillon wrote: > > On Thu, 7 May 2020 08:15:37 +0800 > > "Ramuthevar,Vadivel MuruganX" > > <vadivel.muruganx.ramuthevar@xxxxxxxxxxxxxxx> wrote: > > > >> + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); > >> + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN, > >> + ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); > > > > Seriously, did you really think I would not notice what you're doing > > here? > Yes , I know that you have very good understanding about this. > You're reading the previous value which either contains a default > > mapping or has the mapping set by the bootloader, and write it back to > > the register along with a new mask and the REGEN bit set (which > > BTW is wrong since you don't mask out other fields before updating > > them). > There is no other field get overwritten > This confirms that this Core -> FPI address translation exists > > and has to be set properly, so please stop lying about that. > > Sorry, there is no SW translation, as I have mentioned that it's > optional only, for safer side , reading and writing the default values. Then write EBU_ADDR_SEL_REGEN and we'll if see that works. I suspect it won't. > The memory region to enabled that's my concern so written the same > register values. I don't buy that, sorry. > > This will not be impact other fields, so please see below for reference > > The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish > and control memory regions for external accesses. > > Reset Value: 17400001H See, as suspected the reset value is exactly what you expect.