Re: OMAP: clock DT conversion issues with omap36xx
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote: > On 13/02/14 11:03, Tomi Valkeinen wrote: > > On 12/02/14 15:18, Tomi Valkeinen wrote: > > > >> However, I hacked together the patch below, which "fixes" the issue for > >> 96m and dss fclk. It sets the clock parents so that the x2 clocks are > >> skipped, and makes the x2 clock nodes compatible with "unused", making > >> them effectively disappear. I only verified dss fclk, so Christoph, can > >> you verify the 96m clock? > > > > Aaand the hack patch I sent is crap... We can't skip the x2 clock path, > > as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is > > present on 3630 also. > > > > I think the best and simplest way to fix this is by setting the > > multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I > > didn't think of it yesterday. > > > > I have a bunch of other patches needed to get the clocks right, so I'll > > send a series separately a bit later today. > > I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o > and arm lists, which hopefully solves issues discussed in this thread. Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock and DSS-clocks are fine now. If you want, you can add my: Tested-by: Christoph Fritz to your series "OMAP: OMAP3 DSS related clock patches". The only issue left on current mainline for a83x board is that twl4030 (tps65920) doesn't set VIO as on next-20140120. Thanks -- Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On 13/02/14 11:03, Tomi Valkeinen wrote: > On 12/02/14 15:18, Tomi Valkeinen wrote: > >> However, I hacked together the patch below, which "fixes" the issue for >> 96m and dss fclk. It sets the clock parents so that the x2 clocks are >> skipped, and makes the x2 clock nodes compatible with "unused", making >> them effectively disappear. I only verified dss fclk, so Christoph, can >> you verify the 96m clock? > > Aaand the hack patch I sent is crap... We can't skip the x2 clock path, > as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is > present on 3630 also. > > I think the best and simplest way to fix this is by setting the > multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I > didn't think of it yesterday. > > I have a bunch of other patches needed to get the clocks right, so I'll > send a series separately a bit later today. I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o and arm lists, which hopefully solves issues discussed in this thread. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On 12/02/14 15:18, Tomi Valkeinen wrote: > However, I hacked together the patch below, which "fixes" the issue for > 96m and dss fclk. It sets the clock parents so that the x2 clocks are > skipped, and makes the x2 clock nodes compatible with "unused", making > them effectively disappear. I only verified dss fclk, so Christoph, can > you verify the 96m clock? Aaand the hack patch I sent is crap... We can't skip the x2 clock path, as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is present on 3630 also. I think the best and simplest way to fix this is by setting the multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I didn't think of it yesterday. I have a bunch of other patches needed to get the clocks right, so I'll send a series separately a bit later today. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On 12/02/14 15:18, Tomi Valkeinen wrote: However, I hacked together the patch below, which fixes the issue for 96m and dss fclk. It sets the clock parents so that the x2 clocks are skipped, and makes the x2 clock nodes compatible with unused, making them effectively disappear. I only verified dss fclk, so Christoph, can you verify the 96m clock? Aaand the hack patch I sent is crap... We can't skip the x2 clock path, as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is present on 3630 also. I think the best and simplest way to fix this is by setting the multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I didn't think of it yesterday. I have a bunch of other patches needed to get the clocks right, so I'll send a series separately a bit later today. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On 13/02/14 11:03, Tomi Valkeinen wrote: On 12/02/14 15:18, Tomi Valkeinen wrote: However, I hacked together the patch below, which fixes the issue for 96m and dss fclk. It sets the clock parents so that the x2 clocks are skipped, and makes the x2 clock nodes compatible with unused, making them effectively disappear. I only verified dss fclk, so Christoph, can you verify the 96m clock? Aaand the hack patch I sent is crap... We can't skip the x2 clock path, as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is present on 3630 also. I think the best and simplest way to fix this is by setting the multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I didn't think of it yesterday. I have a bunch of other patches needed to get the clocks right, so I'll send a series separately a bit later today. I just sent the OMAP: OMAP3 DSS related clock patches series to l-o and arm lists, which hopefully solves issues discussed in this thread. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote: On 13/02/14 11:03, Tomi Valkeinen wrote: On 12/02/14 15:18, Tomi Valkeinen wrote: However, I hacked together the patch below, which fixes the issue for 96m and dss fclk. It sets the clock parents so that the x2 clocks are skipped, and makes the x2 clock nodes compatible with unused, making them effectively disappear. I only verified dss fclk, so Christoph, can you verify the 96m clock? Aaand the hack patch I sent is crap... We can't skip the x2 clock path, as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is present on 3630 also. I think the best and simplest way to fix this is by setting the multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I didn't think of it yesterday. I have a bunch of other patches needed to get the clocks right, so I'll send a series separately a bit later today. I just sent the OMAP: OMAP3 DSS related clock patches series to l-o and arm lists, which hopefully solves issues discussed in this thread. Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock and DSS-clocks are fine now. If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com to your series OMAP: OMAP3 DSS related clock patches. The only issue left on current mainline for a83x board is that twl4030 (tps65920) doesn't set VIO as on next-20140120. Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
Hi Tomi, On Wed, Feb 12, 2014 at 2:18 PM, Tomi Valkeinen wrote: > Hi Tero, Christoph, > > On 07/02/14 12:12, Christoph Fritz wrote: >> On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: >>> On 01/29/2014 01:21 PM, Christoph Fritz wrote: > Currently I only analyzed sys_clkout2 (see attachments for full > clk_summary files): > > clk_summary__next-20140115__works_as_expected: > dpll4_m2_ck1 19600 > dpll4_m2x2_ck 1 19600 > omap_192m_alwon_fck 1 19600 >omap_96m_alwon_fck 1 2 > 9600 > per_96m_fck 0 69600 > mcbsp4_fck 0 19600 > mcbsp3_fck 0 29600 > mcbsp2_fck 0 29600 > cm_96m_fck 2 39600 > clkout2_src_ck 1 1 > 9600 > sys_clkout2 1 1 > 2400 > > For real, on pin sys_clkout2 are correctly 24 Mhz measured. > > clk_summary__next-20140124__sysclkout2_dss_fails: > dpll4_m2_ck1 19600 > dpll4_m2x2_mul_ck 1 119200 > dpll4_m2x2_ck 1 119200 >omap_192m_alwon_fck 0 0 > 19200 >omap_96m_alwon_fck 1 2 > 19200 > per_96m_fck 0 619200 > mcbsp4_fck 0 119200 > mcbsp3_fck 0 219200 > mcbsp2_fck 0 219200 > cm_96m_fck 2 319200 > clkout2_src_ck 1 1 > 19200 > sys_clkout2 1 1 > 2400 > > For real, on pin sys_clkout2 are only ~12 Mhz measured. >>> >>> Hey Christoph, >>> >>> I had a chance to look at this in more detail, and it looks like your >>> patch above was almost the correct one (except that I think you modified >>> wrong property and also modified the clock node for all omap3 variants.) >>> Can you give this one a shot? Can you also send me the clk-summary dump >>> with this patch (with the relevant nodes)? >> >> dpll4_m2_ck1 19600 0 >> dpll4_m2x2_mul_ck 1 119200 0 >>dpll4_m2x2_ck 1 119200 0 >> omap_192m_alwon_fck 0 019200 >> 0 >> omap_96m_alwon_fck 1 29600 >> 0 >> per_96m_fck 0 69600 0 >> mcbsp4_fck 0 19600 0 >> mcbsp3_fck 0 29600 0 >> mcbsp2_fck 0 29600 0 >> cm_96m_fck 2 39600 0 >> clkout2_src_ck 1 19600 >> 0 >>sys_clkout2 1 12400 >> 0 >> >> Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, >> you can add my: >> Tested-by: Christoph Fritz >> >> Below is my clock fix for dss: >> >> From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 >> From: Christoph Fritz >> Date: Fri, 7 Feb 2014 10:51:15 +0100 >> Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree > > Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the > problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have > x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B > DPLL on OMAP3 SoCs. > > Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an > extra /2 divider to that clock path. So the 96m clock first gets > mutiplied by 2, even though the HW doesn't do that, and then divided by > 2, even though the HW doesn't do that. > > Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping > the x2 clock nodes totally, which is much better. However, it leaves the > old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it > does when omapdss sets the fclk), the unused x2 clocks do recalcs, > breaking
Re: OMAP: clock DT conversion issues with omap36xx
Hi Tero, Christoph, On 07/02/14 12:12, Christoph Fritz wrote: > On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: >> On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. >> >> Hey Christoph, >> >> I had a chance to look at this in more detail, and it looks like your >> patch above was almost the correct one (except that I think you modified >> wrong property and also modified the clock node for all omap3 variants.) >> Can you give this one a shot? Can you also send me the clk-summary dump >> with this patch (with the relevant nodes)? > > dpll4_m2_ck1 19600 0 > dpll4_m2x2_mul_ck 1 119200 0 >dpll4_m2x2_ck 1 119200 0 > omap_192m_alwon_fck 0 019200 > 0 > omap_96m_alwon_fck 1 29600 0 > per_96m_fck 0 69600 0 > mcbsp4_fck 0 19600 0 > mcbsp3_fck 0 29600 0 > mcbsp2_fck 0 29600 0 > cm_96m_fck 2 39600 0 > clkout2_src_ck 1 19600 > 0 >sys_clkout2 1 12400 > 0 > > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, > you can add my: > Tested-by: Christoph Fritz > > Below is my clock fix for dss: > > From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 > From: Christoph Fritz > Date: Fri, 7 Feb 2014 10:51:15 +0100 > Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B DPLL on OMAP3 SoCs. Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an extra /2 divider to that clock path. So the 96m clock first gets mutiplied by 2, even though the HW doesn't do that, and then divided by 2, even though the HW doesn't do that. Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping the x2 clock nodes totally, which is much better. However, it leaves the old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it does when omapdss sets the fclk), the unused x2 clocks do recalcs, breaking everything. This last bit is a bit guesswork, I didn't actually verify it, but the fact is that if I remove the x2 clocks totally, omapdss work fine. Sooo... What should be done
Re: OMAP: clock DT conversion issues with omap36xx
Hi Tero, Christoph, On 07/02/14 12:12, Christoph Fritz wrote: On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 29600 0 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B DPLL on OMAP3 SoCs. Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an extra /2 divider to that clock path. So the 96m clock first gets mutiplied by 2, even though the HW doesn't do that, and then divided by 2, even though the HW doesn't do that. Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping the x2 clock nodes totally, which is much better. However, it leaves the old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it does when omapdss sets the fclk), the unused x2 clocks do recalcs, breaking everything. This last bit is a bit guesswork, I didn't actually verify it, but the fact is that if I remove the x2 clocks totally, omapdss work fine. Sooo... What should be done is create new DPLL4 clock paths for OMAP3630, which do not have the x2 clocks at all. I tried to do that, but it wasn't trivial (at least to me who is
Re: OMAP: clock DT conversion issues with omap36xx
Hi Tomi, On Wed, Feb 12, 2014 at 2:18 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Tero, Christoph, On 07/02/14 12:12, Christoph Fritz wrote: On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 2 9600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 296000 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B DPLL on OMAP3 SoCs. Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an extra /2 divider to that clock path. So the 96m clock first gets mutiplied by 2, even though the HW doesn't do that, and then divided by 2, even though the HW doesn't do that. Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping the x2 clock nodes totally, which is much better. However, it leaves the old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it does when omapdss sets the fclk), the unused x2 clocks do recalcs, breaking everything. This last bit is a bit guesswork, I didn't actually verify it, but the fact is that if I remove the x2 clocks totally, omapdss work fine. Sooo... What should be done is create new DPLL4 clock paths for OMAP3630, which
Re: OMAP: clock DT conversion issues with omap36xx
On 10/02/14 22:54, Christoph Fritz wrote: >> I wonder if I'm still missing some patch? > > Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The > clock registers are all fine now as before the dt clock conversion > patches. No, Beagle xM doesn't use DSI, plain DPI. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On 10/02/14 22:54, Christoph Fritz wrote: I wonder if I'm still missing some patch? Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The clock registers are all fine now as before the dt clock conversion patches. No, Beagle xM doesn't use DSI, plain DPI. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote: > On 07/02/14 12:12, Christoph Fritz wrote: > > > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, > > you can add my: > > Tested-by: Christoph Fritz > > > > Below is my clock fix for dss: > > > > From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 > > From: Christoph Fritz > > Date: Fri, 7 Feb 2014 10:51:15 +0100 > > Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree > > > > OMAP36xx has different hardware implementation for the dpll4_m4_ck tree > > compared to other OMAP3 variants. Reflect this properly in the dts file. > > I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get > beagle-xM working. Pinmuxing was wrong, but after fixing that, the > clk_set_rate for dss fclk failed. I applied Tero's and your patches, but > now when starting omapdss I see: > > [ 19.704193] omap clock: module associated with clock > dss1_alwon_fck_3430es2 didn't enable in 1000 > 00 tries > > I wonder if I'm still missing some patch? Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The clock registers are all fine now as before the dt clock conversion patches. I suppose you are using current linus tree. I tested 'next' but didn't get DSS working. I guessed that it would have something to do with early DSS DT integration issues. I'll rebase my current dt board support patchset for LILLY-A83X to current linus tree and investigate DSS further. Thanks -- Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote: On 07/02/14 12:12, Christoph Fritz wrote: Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get beagle-xM working. Pinmuxing was wrong, but after fixing that, the clk_set_rate for dss fclk failed. I applied Tero's and your patches, but now when starting omapdss I see: [ 19.704193] omap clock: module associated with clock dss1_alwon_fck_3430es2 didn't enable in 1000 00 tries I wonder if I'm still missing some patch? Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The clock registers are all fine now as before the dt clock conversion patches. I suppose you are using current linus tree. I tested 'next' but didn't get DSS working. I guessed that it would have something to do with early DSS DT integration issues. I'll rebase my current dt board support patchset for LILLY-A83X to current linus tree and investigate DSS further. Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
Hi, On 07/02/14 12:12, Christoph Fritz wrote: > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, > you can add my: > Tested-by: Christoph Fritz > > Below is my clock fix for dss: > > From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 > From: Christoph Fritz > Date: Fri, 7 Feb 2014 10:51:15 +0100 > Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree > > OMAP36xx has different hardware implementation for the dpll4_m4_ck tree > compared to other OMAP3 variants. Reflect this properly in the dts file. I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get beagle-xM working. Pinmuxing was wrong, but after fixing that, the clk_set_rate for dss fclk failed. I applied Tero's and your patches, but now when starting omapdss I see: [ 19.704193] omap clock: module associated with clock dss1_alwon_fck_3430es2 didn't enable in 1000 00 tries I wonder if I'm still missing some patch? Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: > On 01/29/2014 01:21 PM, Christoph Fritz wrote: > >> Currently I only analyzed sys_clkout2 (see attachments for full > >> clk_summary files): > >> > >> clk_summary__next-20140115__works_as_expected: > >> dpll4_m2_ck1 19600 > >> dpll4_m2x2_ck 1 19600 > >> omap_192m_alwon_fck 1 19600 > >>omap_96m_alwon_fck 1 29600 > >> per_96m_fck 0 69600 > >> mcbsp4_fck 0 19600 > >> mcbsp3_fck 0 29600 > >> mcbsp2_fck 0 29600 > >> cm_96m_fck 2 39600 > >> clkout2_src_ck 1 1 > >> 9600 > >> sys_clkout2 1 1 > >> 2400 > >> > >> For real, on pin sys_clkout2 are correctly 24 Mhz measured. > >> > >> clk_summary__next-20140124__sysclkout2_dss_fails: > >> dpll4_m2_ck1 19600 > >> dpll4_m2x2_mul_ck 1 119200 > >> dpll4_m2x2_ck 1 119200 > >>omap_192m_alwon_fck 0 0 > >> 19200 > >>omap_96m_alwon_fck 1 2 > >> 19200 > >> per_96m_fck 0 619200 > >> mcbsp4_fck 0 119200 > >> mcbsp3_fck 0 219200 > >> mcbsp2_fck 0 219200 > >> cm_96m_fck 2 319200 > >> clkout2_src_ck 1 1 > >> 19200 > >> sys_clkout2 1 1 > >> 2400 > >> > >> For real, on pin sys_clkout2 are only ~12 Mhz measured. > > Hey Christoph, > > I had a chance to look at this in more detail, and it looks like your > patch above was almost the correct one (except that I think you modified > wrong property and also modified the clock node for all omap3 variants.) > Can you give this one a shot? Can you also send me the clk-summary dump > with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 29600 0 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz Below is my clock fix for dss: >From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. before omap dt clock conversion: dpll4_m4_ck1 15760 dpll4_m4x2_ck 1 15760 dss1_alwon_fck_3430es2 2 45760 after omap dt clock conversion: dpll4_m4_ck0 19600 0 dpll4_m4x2_mul_ck 0 119200 0 dpll4_m4x2_ck 0 119200 0 dss1_alwon_fck_3430es2 0 419200 0 with this patch: dpll4_m4_ck1 15760 0 dss1_alwon_fck_3430es2 2 45760 0 dpll4_m4x2_mul_ck 0 011520 0 dpll4_m4x2_ck 0 011520 0 Signed-off-by: Christoph Fritz ---
Re: OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 29600 0 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. before omap dt clock conversion: dpll4_m4_ck1 15760 dpll4_m4x2_ck 1 15760 dss1_alwon_fck_3430es2 2 45760 after omap dt clock conversion: dpll4_m4_ck0 19600 0 dpll4_m4x2_mul_ck 0 119200 0 dpll4_m4x2_ck 0 119200 0 dss1_alwon_fck_3430es2 0 419200 0 with this patch: dpll4_m4_ck1 15760 0 dss1_alwon_fck_3430es2 2 45760 0 dpll4_m4x2_mul_ck 0 011520 0 dpll4_m4x2_ck 0 011520 0 Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- arch/arm/boot/dts/omap36xx-clocks.dtsi |8
Re: OMAP: clock DT conversion issues with omap36xx
Hi, On 07/02/14 12:12, Christoph Fritz wrote: Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get beagle-xM working. Pinmuxing was wrong, but after fixing that, the clk_set_rate for dss fclk failed. I applied Tero's and your patches, but now when starting omapdss I see: [ 19.704193] omap clock: module associated with clock dss1_alwon_fck_3430es2 didn't enable in 1000 00 tries I wonder if I'm still missing some patch? Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
Due to a regression since next-20140122 the following errors are present:
- pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
in this set, erroneously outputs only 12 Mhz.
Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.
- omap_dss, which gets configured by the third patch in this set, fails
to do 'dss_set_fck_rate(fck);' in
drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:
| omapdss_dss: probe of omapdss_dss failed with error -22
| omapdss CORE error: Failed to initialize DSS platform driver
| panel-dpi panel-dpi.0: failed to find video source 'dpi.0
Both regressions seem to have something to do with the clock framework.
Could this be related to the DT clock conversion patches?
Yea its definitely possible, as the clock DT conversion touches pretty
much everything. Have you tried whether this works properly with legacy
boot? Personally I don't have access to any omap3 devices that would
have display and have no possibility to check this out myself. Anyway,
my initial guess is that some clock divider setup might be wrong with
omap3, or we are missing some ti,set-rate-parent flag for some clock
node which prevents escalating clk_set_rate properly. However, it should
be easy to debug this by looking at the clock node in question, and its
parent nodes to see if there are any problems.
Currently I only analyzed sys_clkout2 (see attachments for full
clk_summary files):
clk_summary__next-20140115__works_as_expected:
dpll4_m2_ck1 19600
dpll4_m2x2_ck 1 19600
omap_192m_alwon_fck 1 19600
omap_96m_alwon_fck 1 29600
per_96m_fck 0 69600
mcbsp4_fck 0 19600
mcbsp3_fck 0 29600
mcbsp2_fck 0 29600
cm_96m_fck 2 39600
clkout2_src_ck 1 19600
sys_clkout2 1 12400
For real, on pin sys_clkout2 are correctly 24 Mhz measured.
clk_summary__next-20140124__sysclkout2_dss_fails:
dpll4_m2_ck1 19600
dpll4_m2x2_mul_ck 1 119200
dpll4_m2x2_ck 1 119200
omap_192m_alwon_fck 0 019200
omap_96m_alwon_fck 1 219200
per_96m_fck 0 619200
mcbsp4_fck 0 119200
mcbsp3_fck 0 219200
mcbsp2_fck 0 219200
cm_96m_fck 2 319200
clkout2_src_ck 1 119200
sys_clkout2 1 12400
For real, on pin sys_clkout2 are only ~12 Mhz measured.
Hey Christoph,
I had a chance to look at this in more detail, and it looks like your
patch above was almost the correct one (except that I think you modified
wrong property and also modified the clock node for all omap3 variants.)
Can you give this one a shot? Can you also send me the clk-summary dump
with this patch (with the relevant nodes)?
From: Tero Kristo
Date: Tue, 4 Feb 2014 17:37:37 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck
OMAP36xx has different hardware implementation for the omap96m_alwon_fck
compared to other OMAP3 variants. Reflect this properly in the dts file.
Signed-off-by: Tero Kristo
---
arch/arm/boot/dts/omap36xx-clocks.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253..24869cb 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -70,6 +70,10 @@
};
};
+_96m_alwon_fck {
+ clock-div = <2>;
+};
+
_clockdomains {
dpll4_clkdm: dpll4_clkdm {
compatible = "ti,clockdomain";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
Due to a regression since next-20140122 the following errors are present:
- pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
in this set, erroneously outputs only 12 Mhz.
Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.
- omap_dss, which gets configured by the third patch in this set, fails
to do 'dss_set_fck_rate(fck);' in
drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:
| omapdss_dss: probe of omapdss_dss failed with error -22
| omapdss CORE error: Failed to initialize DSS platform driver
| panel-dpi panel-dpi.0: failed to find video source 'dpi.0
Both regressions seem to have something to do with the clock framework.
Could this be related to the DT clock conversion patches?
Yea its definitely possible, as the clock DT conversion touches pretty
much everything. Have you tried whether this works properly with legacy
boot? Personally I don't have access to any omap3 devices that would
have display and have no possibility to check this out myself. Anyway,
my initial guess is that some clock divider setup might be wrong with
omap3, or we are missing some ti,set-rate-parent flag for some clock
node which prevents escalating clk_set_rate properly. However, it should
be easy to debug this by looking at the clock node in question, and its
parent nodes to see if there are any problems.
Currently I only analyzed sys_clkout2 (see attachments for full
clk_summary files):
clk_summary__next-20140115__works_as_expected:
dpll4_m2_ck1 19600
dpll4_m2x2_ck 1 19600
omap_192m_alwon_fck 1 19600
omap_96m_alwon_fck 1 29600
per_96m_fck 0 69600
mcbsp4_fck 0 19600
mcbsp3_fck 0 29600
mcbsp2_fck 0 29600
cm_96m_fck 2 39600
clkout2_src_ck 1 19600
sys_clkout2 1 12400
For real, on pin sys_clkout2 are correctly 24 Mhz measured.
clk_summary__next-20140124__sysclkout2_dss_fails:
dpll4_m2_ck1 19600
dpll4_m2x2_mul_ck 1 119200
dpll4_m2x2_ck 1 119200
omap_192m_alwon_fck 0 019200
omap_96m_alwon_fck 1 219200
per_96m_fck 0 619200
mcbsp4_fck 0 119200
mcbsp3_fck 0 219200
mcbsp2_fck 0 219200
cm_96m_fck 2 319200
clkout2_src_ck 1 119200
sys_clkout2 1 12400
For real, on pin sys_clkout2 are only ~12 Mhz measured.
Hey Christoph,
I had a chance to look at this in more detail, and it looks like your
patch above was almost the correct one (except that I think you modified
wrong property and also modified the clock node for all omap3 variants.)
Can you give this one a shot? Can you also send me the clk-summary dump
with this patch (with the relevant nodes)?
From: Tero Kristo t-kri...@ti.com
Date: Tue, 4 Feb 2014 17:37:37 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck
OMAP36xx has different hardware implementation for the omap96m_alwon_fck
compared to other OMAP3 variants. Reflect this properly in the dts file.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap36xx-clocks.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253..24869cb 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -70,6 +70,10 @@
};
};
+omap_96m_alwon_fck {
+ clock-div = 2;
+};
+
cm_clockdomains {
dpll4_clkdm: dpll4_clkdm {
compatible = ti,clockdomain;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: OMAP: clock DT conversion issues with omap36xx
On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote: > On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: > > To help us debug similar problems, I wrote a tool today: > > https://github.com/nmenon/ctt-dump - it is a simple memory read utility, > > Input file is CTT dump-out > > For example: 3630 CTT is here: > > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip > > > > to give an idea - i posted a screen shot here: > > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob > > > > After generating the the rd1 file from CTT, > > we pick up the registers using ctt-dump -> any tool which can do > > register reads could do, but it might be handy having this. > > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium > > importing it back into CTT and after setting up the correct sysclk, we > > can compare clock frequencies Vs debugfs output - example: > > http://slexy.org/view/s21iQyDTct > > > > > > I mean, it is awesome having to debugfs data, but with nascent > > systems, it is always good to compare to what the hardware is really > > configured to - and CTT is the easy way to deal with it. > > Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on > this hardware here (omap3-lil-a83x). Its corresponding rd1 file, > generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware > has a 26 Mhz crystal. > > The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE > right. 0x2 is CM_96M_FCLK not CORE_CLK for example. > > > This is the diff of clk registers before and after DT clock > conversion patches: > > --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 > +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 > @@ -22,23 +22,23 @@ > 0x48004c10 0x002f > 0x48004c30 0x023f > 0x48004c40 0x0014 > -0x48004d00 0x10370037 > +0x48004d00 0xf0371037 > 0x48004d04 0x0017 > 0x48004d40 0x09900c00 > 0x48004d44 0x0483600c > 0x48004d48 0x0009 > 0x48004d4c 0x780c > 0x48004d50 0x0001 > -0x48004d70 0x0092 > -0x48004e00 0x0001 > +0x48004d70 0x009a > +0x48004e00 0x > 0x48004e10 0x0001 > 0x48004e30 0x0001 > -0x48004e40 0x100f > +0x48004e40 0x1009 > 0x48004f00 0x > 0x48004f10 0x > 0x48004f30 0x0001 > 0x48004f40 0x0004 > -0x48005000 0x00040800 > +0x48005000 0x0800 > 0x48005010 0x00078fff > 0x48005030 0x0007 > 0x48005040 0x00ff Origin files of this diff added as attachment to this mail. DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x009a 0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105 DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0x10370037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x0092 0x48004e00 0x0001 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x100f 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x00040800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105
Re: OMAP: clock DT conversion issues with omap36xx
On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote: On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump - any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Origin files of this diff added as attachment to this mail. DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x009a 0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105 DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0x10370037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x0092 0x48004e00 0x0001 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x100f 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x00040800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105
Re: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote: > > Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding > ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock > node. Hmm, doesn't change anything here. Thanks -- Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: > To help us debug similar problems, I wrote a tool today: > https://github.com/nmenon/ctt-dump - it is a simple memory read utility, > Input file is CTT dump-out > For example: 3630 CTT is here: > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip > > to give an idea - i posted a screen shot here: > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob > > After generating the the rd1 file from CTT, > we pick up the registers using ctt-dump -> any tool which can do > register reads could do, but it might be handy having this. > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium > importing it back into CTT and after setting up the correct sysclk, we > can compare clock frequencies Vs debugfs output - example: > http://slexy.org/view/s21iQyDTct > > > I mean, it is awesome having to debugfs data, but with nascent > systems, it is always good to compare to what the hardware is really > configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Thanks -- Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump - any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote: Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding ti,min-div = 2; and ti,max-div = 4; to properties of the clock node. Hmm, doesn't change anything here. Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 05:21 AM, Christoph Fritz wrote: > On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: >> On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: >>> > Due to a regression since next-20140122 the following errors are present: > > - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch > in this set, erroneously outputs only 12 Mhz. > Just out of curiosity, configuring it to 48 Mhz puts out desired 24 > Mhz. > > - omap_dss, which gets configured by the third patch in this set, fails > to do 'dss_set_fck_rate(fck);' in > drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads > to: > > | omapdss_dss: probe of omapdss_dss failed with error -22 > | omapdss CORE error: Failed to initialize DSS platform driver > | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 > >Both regressions seem to have something to do with the clock framework. >Could this be related to the DT clock conversion patches? >>> >>> Yea its definitely possible, as the clock DT conversion touches pretty >>> much everything. Have you tried whether this works properly with legacy >>> boot? Personally I don't have access to any omap3 devices that would >>> have display and have no possibility to check this out myself. Anyway, >>> my initial guess is that some clock divider setup might be wrong with >>> omap3, or we are missing some ti,set-rate-parent flag for some clock >>> node which prevents escalating clk_set_rate properly. However, it should >>> be easy to debug this by looking at the clock node in question, and its >>> parent nodes to see if there are any problems. >> >> Currently I only analyzed sys_clkout2 (see attachments for full >> clk_summary files): To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump -> any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 01:21 PM, Christoph Fritz wrote: On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? Yea its definitely possible, as the clock DT conversion touches pretty much everything. Have you tried whether this works properly with legacy boot? Personally I don't have access to any omap3 devices that would have display and have no possibility to check this out myself. Anyway, my initial guess is that some clock divider setup might be wrong with omap3, or we are missing some ti,set-rate-parent flag for some clock node which prevents escalating clk_set_rate properly. However, it should be easy to debug this by looking at the clock node in question, and its parent nodes to see if there are any problems. Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 19600 sys_clkout2 1 12400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 019200 omap_96m_alwon_fck 1 219200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 119200 sys_clkout2 1 12400 For real, on pin sys_clkout2 are only ~12 Mhz measured. So I added this patch: Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck. So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1. --- arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index cb04d4b..b594050 100644 --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi @@ -212,7 +212,7 @@ #clock-cells = <0>; compatible = "fixed-factor-clock"; clocks = <_m2_ck>; - clock-mult = <2>; + clock-mult = <1>; clock-div = <1>; }; And it works again. But due to the fact that sys_clkout2 was at 12 Mhz instead of 24, shouldn't it have been at 48 caused by "clock-mult = 2 ? Any ideas on that? I reverted the patch above and added: Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock node. -Tero From: Tero Kristo Date: Wed, 29 Jan 2014 11:03:46 +0200 Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck OMAP36xx has different hardware implementation for the omap96m_alwon_fck compared to other OMAP3 variants. Reflect this
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 01:21 PM, Christoph Fritz wrote: On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? Yea its definitely possible, as the clock DT conversion touches pretty much everything. Have you tried whether this works properly with legacy boot? Personally I don't have access to any omap3 devices that would have display and have no possibility to check this out myself. Anyway, my initial guess is that some clock divider setup might be wrong with omap3, or we are missing some ti,set-rate-parent flag for some clock node which prevents escalating clk_set_rate properly. However, it should be easy to debug this by looking at the clock node in question, and its parent nodes to see if there are any problems. Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 19600 sys_clkout2 1 12400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 019200 omap_96m_alwon_fck 1 219200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 119200 sys_clkout2 1 12400 For real, on pin sys_clkout2 are only ~12 Mhz measured. So I added this patch: Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck. So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1. --- arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index cb04d4b..b594050 100644 --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi @@ -212,7 +212,7 @@ #clock-cells = 0; compatible = fixed-factor-clock; clocks = dpll4_m2_ck; - clock-mult = 2; + clock-mult = 1; clock-div = 1; }; And it works again. But due to the fact that sys_clkout2 was at 12 Mhz instead of 24, shouldn't it have been at 48 caused by clock-mult = 2 ? Any ideas on that? I reverted the patch above and added: Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding ti,min-div = 2; and ti,max-div = 4; to properties of the clock node. -Tero From: Tero Kristo t-kri...@ti.com Date: Wed, 29 Jan 2014 11:03:46 +0200 Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck OMAP36xx has different hardware implementation for the omap96m_alwon_fck compared to other OMAP3 variants. Reflect this
Re: OMAP: clock DT conversion issues with omap36xx
On 01/29/2014 05:21 AM, Christoph Fritz wrote: On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? Yea its definitely possible, as the clock DT conversion touches pretty much everything. Have you tried whether this works properly with legacy boot? Personally I don't have access to any omap3 devices that would have display and have no possibility to check this out myself. Anyway, my initial guess is that some clock divider setup might be wrong with omap3, or we are missing some ti,set-rate-parent flag for some clock node which prevents escalating clk_set_rate properly. However, it should be easy to debug this by looking at the clock node in question, and its parent nodes to see if there are any problems. Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump - any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
