Messages in this thread | | | From | <> | Subject | Re: Reset controller within a clock driver | Date | Fri, 27 May 2022 20:52:05 +0000 |
| |
On 27/05/2022 20:26, Stephen Boyd wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Quoting Conor.Dooley@microchip.com (2022-05-27 11:40:59) >> Hi Stephen, >> >> After I sent the fix for the broken resets in clk/microchip/clk-mpfs.c, >> [0] I started looking at making a proper reset controller driver a la >> clk/renesas/{renesas-cpg-mssr,rzgl2l-cpg}.c where the reset controller >> is part of the clock driver file. >> >> I did it that way b/c the reset controller is just a single reg, >> surrounded by registers used by clocks. It's roughly a +130,-10 line >> change to the existing driver. A /very/ rough version that will not >> apply without other cleanup is appended for context. >> >> Before I got around to testing properly and cleaning it up for >> submission, I saw a mail you had sent and wondered if I'd gone for the >> wrong approach [1]. >> >> Should I instead have my clock driver create a device for the reset >> controller to bind to, or is that overkill for a single register & >> Serge's situation is different b/c he'd created a file purely for >> a reset controller? >> > > It's really up to you. It may be better to use auxiliary bus to split > the logic out to different subsystems. I can review the reset code but > I'm not the reset maintainer.
Aye, CC'ed him in case he had an opinion too.
> Historically we've just accepted that > sometimes SoCs combine the clk and reset controls together into a "clock > and reset controller" and so we have the driver register clks and > resets. Using the bus to split up the device will help move these > registration calls to the appropriate subsystem so that the > reviewer/maintainer load is spread around.
SGTM, I'll give it a go. Thanks, Conor.
| |