Quoting Abel Vesa (2018-11-08 04:29:39) > On Wed, Nov 07, 2018 at 04:18:35PM -0800, Stephen Boyd wrote: > > Quoting Abel Vesa (2018-11-07 12:26:25) > > > On Wed, Nov 07, 2018 at 11:01:02AM -0800, Stephen Boyd wrote: > > > > > > > > > > > > What's the plan to clean it up? > > > > > > So I'm doing this in our internal tree first to make sure I don't break > > > the > > > other (newer) socs. > > > > > > I already have a prototype in testing but it's a long way to upstream it. > > > > > > Basically, I'm replacing all of this with a single, more like a composite, > > > more complex, clock type that does all the magic inside. > > > > > > One of the problems is the fact that the bypasses can have the same > > > sources > > > and in my case, I'm implementing that as a list of parents name, but the > > > parent names list doesn't work with duplicates, so I have to find some > > > other > > > way to do it. > > > > > > Once I have something clean and tested enough I'll send it upstream. > > > > Ok. Thanks for the info. > > > > Just to avoid any kind of confusion. > > The whole refactoring of the SCCG clock will be done in a separate (later) > change > and will not be part of this patchset. > > I already sent the 12th version of this current patch series and I would > really > like to get this in ASAP so that the booting up of imx8mq will not be delayed. >
Ok. Well we're in rc1 right now, and so we're not merging new drivers into mainline. I can merge the clk driver into clk-next, but you'll have to wait for the stabilization period to end (approximately 6 or 7 weeks) before this can get into the next kernel version. It will be in linux-next much sooner of course.
