Hi Stephen, Thanks for your reply. On Thu, 4 Aug 2022 at 23:05, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Tomer Maimon (2022-08-04 07:01:30) > > On Sat, 30 Jul 2022 at 01:56, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > > > > > Because it is jumbled in some range? > > Yes. > > > > > > > > > > > I do see a way to combine the clock and the reset driver, the NPCM > > > > reset driver is serving other NPCM BMC's. > > > > Should we use regmap to handle the clock registers instead of ioremap? > > > > > > Sure? Using regmap or not looks like a parallel discussion. How does it > > > help use platform APIs? > > I mean to use regmap API instead of platform API for handing the clock > > and reset registers. > > the regmap API gives only one user access to R/W (lock). > > I will be happy to get more suggestions, on how should we solve this situation. > > > > Using platform APIs means using platform_*() functions, not of_*() > functions, which are open-firmware/DT related. Regmap can be used to > operate on registers mapped as __iomem, which is different from platform > APIs. I will use platform_get_resource() and devm_ioremap_resource() functions in the next version. > > Is having a lock even necessary? Do the reset and clk controls live You are right, lock use is not necessary. > within a shared register where we would need to prevent one driver from > accessing that register at the same time as the other? reset and clk drivers are living fine with shared registers, we don't need to handle the register access between the clk and the reset drivers. Best regards, Tomer
