From mboxrd@z Thu Jan 1 00:00:00 1970 From: Giulio Benetti Date: Thu, 11 Feb 2021 20:20:43 +0100 Subject: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family In-Reply-To: References: <20210210000446.695832-1-mr.bossman075@gmail.com> <20210210000446.695832-2-mr.bossman075@gmail.com> <3866f8ae-769a-5aee-a22b-91c0e415f68c@benettiengineering.com> <7c787e3f-9869-c268-f1bb-91e387c4217f@gmail.com> <7bf8d1c2-f910-9619-096e-a55b9e0bf1af@benettiengineering.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2/11/21 7:54 PM, Jesse T wrote: [SNIP] > > > > The IPG_CLK_24M needs a different prescaler and a second enable bit. > > This will completely bypass all other clock sources making the > check for > > the clock rate useless. > > Yes, in the operative way yes, you could also avoid passing clock > source > through dts, but this way we check that the right clock source is > passed > to dts, and that is the correct way to work I think. > > > It will also mean that even if we don't have a > > correct clock source it will work at the correct timing. > > Yes if they provide 24Mhz. > > I wanted it to be like that at the moment, because a lot of imx SoCs > setup GPT like that. Take a look here: > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/timer.c#L80-99 > > This way the imx6* and imx7 could add their .compatible to this driver > in the future. If someone will need some specific tweaking then they > would send a patch adding such new DT property, like using 32K source. > But that comes next IMHO, otherwise we should describe entirely GPT > peripheral but what we need at the moment is getting 1ms tick like lot > of other imx SoCs already do. > > The other chance would be to treat all the clock sources possibilities, > but, at least for me, to begin this is sufficient and can be > improved later. > > > I changed it to use only the 24MHz clock and ignore all others, > > Ok > > > at some > > point it would be nice to have it only as a backup clock if the > ccm was > > not configured. > > I don't understand what you mean with backup clock can you elaborate > more? > > If we have a clock source that is 0, we can still use the 24MHz clock as > that is an always known source, and isn't?controlled by the ccm. > Therefore if we have a dummy clock the soc will still have delays and > timeouts at the right time. But this would make it so that we never > return an error from clk_get_rate(&clk); I'm not sure it is that safe. I'd prefer something that doesn't work at all rather than something that works by a default specified inside a driver. Since we're trying to imitate linux driver I would avoid this solution. Often code is exchanged between u-boot, linux etc. so I'd prefer to keep it like linux does. Best regards -- Giulio Benetti Benetti Engineering sas > > Thank you > > Best regards > -- > Giulio Benetti > Benetti Engineering sas >