From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Minimal support for dm814x Date: Thu, 12 Nov 2015 09:41:55 -0800 Message-ID: <20151112174155.GM3218@atomide.com> References: <4999BB3D-4BB5-4F7C-96D7-FB687725CDCC@audioscience.com> <20151109150602.GR3199@atomide.com> <7933071D-84FD-4A85-8CD0-CC504CE1D9D1@audioscience.com> <20151111174028.GF3218@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Matthijs van Duin Cc: "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Delio Brignoli List-Id: linux-omap@vger.kernel.org * Matthijs van Duin [151112 01:21]: > On 11 November 2015 at 18:40, Tony Lindgren wrote: > > Well we do first try to set the rate using the divider only at least for > > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar > > driver for the dm814x adpll where we have a PLL and separate output clocks > > in a single driver as the PLL and output control registers are all mixed in. > > Well the output control *is* part of the PLL block. More importantly, > due to the constraints of DPLL-LJ you may need to consider the > postdivider and PLL config together to produce the desired output > frequency. Yup. > Note BTW that afaik exactly the same two DPLL types are used in nearly > all TI SoCs (with exception of DM816x, and some enhancements have been > made in the latest SoCs), but since the PLLs themselves only have > wires sticking out, the register interface can vary significantly > between devices. Most of them also wrap a layer of abstraction around > them, while it seems the DM814x just directly wired all available > signals into registers, no added sugar. > > Another difference is that normally nearly all DPLLs are DPLL-S (aka > "type A") and often only one is -LJ (aka "type B"), while the > situation is reversed on the DM814x which has only one instance of > DPLL-S and 12 instances of DPLL-LJ. Also unusual is that none have > more than one output divider (no HSDIVIDER blocks present) and only > two (HDMI and USB) make direct use of the undivided dco clock. This > means that, with those two exceptions, you do have complete freedom in > configuring the PLL for the needs of its single output clock. OK > It does however also mean you can't really escape dealing with the > fussiness of DPLL-LJ like you can on other devices (e.g. the am335x > has only one, which is configured correctly by ROM and can't be > reconfigured without breaking USB.) Does the old TI kernel tree driver correctly handle that? Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 12 Nov 2015 09:41:55 -0800 Subject: Minimal support for dm814x In-Reply-To: References: <4999BB3D-4BB5-4F7C-96D7-FB687725CDCC@audioscience.com> <20151109150602.GR3199@atomide.com> <7933071D-84FD-4A85-8CD0-CC504CE1D9D1@audioscience.com> <20151111174028.GF3218@atomide.com> Message-ID: <20151112174155.GM3218@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Matthijs van Duin [151112 01:21]: > On 11 November 2015 at 18:40, Tony Lindgren wrote: > > Well we do first try to set the rate using the divider only at least for > > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar > > driver for the dm814x adpll where we have a PLL and separate output clocks > > in a single driver as the PLL and output control registers are all mixed in. > > Well the output control *is* part of the PLL block. More importantly, > due to the constraints of DPLL-LJ you may need to consider the > postdivider and PLL config together to produce the desired output > frequency. Yup. > Note BTW that afaik exactly the same two DPLL types are used in nearly > all TI SoCs (with exception of DM816x, and some enhancements have been > made in the latest SoCs), but since the PLLs themselves only have > wires sticking out, the register interface can vary significantly > between devices. Most of them also wrap a layer of abstraction around > them, while it seems the DM814x just directly wired all available > signals into registers, no added sugar. > > Another difference is that normally nearly all DPLLs are DPLL-S (aka > "type A") and often only one is -LJ (aka "type B"), while the > situation is reversed on the DM814x which has only one instance of > DPLL-S and 12 instances of DPLL-LJ. Also unusual is that none have > more than one output divider (no HSDIVIDER blocks present) and only > two (HDMI and USB) make direct use of the undivided dco clock. This > means that, with those two exceptions, you do have complete freedom in > configuring the PLL for the needs of its single output clock. OK > It does however also mean you can't really escape dealing with the > fussiness of DPLL-LJ like you can on other devices (e.g. the am335x > has only one, which is configured correctly by ROM and can't be > reconfigured without breaking USB.) Does the old TI kernel tree driver correctly handle that? Regards, Tony