| Message ID | 20150415140945.GA30787@deathray (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 04/15/2015 05:09 PM, Michael Welling wrote: > On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: >> On 04/15/2015 12:17 AM, Michael Welling wrote: >>> Greetings, >>> >>> I have developed an AM3354 based SoM and it uses an external SI5351 clock >>> generator to drive the clock inputs for an external duart and I2S audio >>> master clock. With the registration according to the documentation the >>> reference clock is not being detected and hence the clock generator is >>> not working as expect. >>> >>> After trying many different things, I started to look around the mailing >>> lists to find information related to this issue. >>> >>> I came acrossed post that has the exact same issue: >>> https://lkml.org/lkml/2013/2/18/468 >>> >>> Seeing as the patch did not land upstream, I am wondering if there is >>> a solution that I am not seeing. >>> >>> I am willing to provide a patch given appropriate guidance. >> >> Hi Michael, >> >> The info on the email you referenced is kind of obsolete, TI SoCs >> are calling of_clk_init() during boot now, and thus external clock >> nodes should be registered fine also. Maybe you can provide the >> actual DTS patch you are trying out so we can help better...? Are > > See attached patch and console output. I see a bug in your dt data. <snip> + clocks { + ref27: ref27 { + #clock-cells = <0>; + compatibale = "fixed-clock"; This should be compatible, right? DT is annoying in that it doesn't verify property names. + clock-frequency = <27000000>; + }; + }; -Tero > >> you seeing any boot time error / warning prints for your new clock? > > With the debug messages on you see that the reference clock is not being > detected. > > Whilest debugging I found that the of_clk_get is returning an error no matter > which clock I pass it: > http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 > >> >> -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote: > On 04/15/2015 05:09 PM, Michael Welling wrote: > >On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: > >>On 04/15/2015 12:17 AM, Michael Welling wrote: > >>>Greetings, > >>> > >>>I have developed an AM3354 based SoM and it uses an external SI5351 clock > >>>generator to drive the clock inputs for an external duart and I2S audio > >>>master clock. With the registration according to the documentation the > >>>reference clock is not being detected and hence the clock generator is > >>>not working as expect. > >>> > >>>After trying many different things, I started to look around the mailing > >>>lists to find information related to this issue. > >>> > >>>I came acrossed post that has the exact same issue: > >>>https://lkml.org/lkml/2013/2/18/468 > >>> > >>>Seeing as the patch did not land upstream, I am wondering if there is > >>>a solution that I am not seeing. > >>> > >>>I am willing to provide a patch given appropriate guidance. > >> > >>Hi Michael, > >> > >>The info on the email you referenced is kind of obsolete, TI SoCs > >>are calling of_clk_init() during boot now, and thus external clock > >>nodes should be registered fine also. Maybe you can provide the > >>actual DTS patch you are trying out so we can help better...? Are > > > >See attached patch and console output. > > I see a bug in your dt data. > > <snip> > > + clocks { > + ref27: ref27 { > + #clock-cells = <0>; > + compatibale = "fixed-clock"; > > This should be compatible, right? DT is annoying in that it doesn't > verify property names. > Ooops. Now the clock appears in /sys/kernel/debug/clk: root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------------------------- ref27 0 0 27000000 0 0 ... There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? > + clock-frequency = <27000000>; > + }; > + }; > > -Tero > > > > >>you seeing any boot time error / warning prints for your new clock? > > > >With the debug messages on you see that the reference clock is not being > >detected. > > > >Whilest debugging I found that the of_clk_get is returning an error no matter > >which clock I pass it: > >http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 > > > >> > >>-Tero > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: > On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote: >> On 04/15/2015 05:09 PM, Michael Welling wrote: >> >On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: >> >>On 04/15/2015 12:17 AM, Michael Welling wrote: >> >>>Greetings, >> >>> >> >>>I have developed an AM3354 based SoM and it uses an external SI5351 clock >> >>>generator to drive the clock inputs for an external duart and I2S audio >> >>>master clock. With the registration according to the documentation the >> >>>reference clock is not being detected and hence the clock generator is >> >>>not working as expect. >> >>> >> >>>After trying many different things, I started to look around the mailing >> >>>lists to find information related to this issue. >> >>> >> >>>I came acrossed post that has the exact same issue: >> >>>https://lkml.org/lkml/2013/2/18/468 >> >>> >> >>>Seeing as the patch did not land upstream, I am wondering if there is >> >>>a solution that I am not seeing. >> >>> >> >>>I am willing to provide a patch given appropriate guidance. >> >> >> >>Hi Michael, >> >> >> >>The info on the email you referenced is kind of obsolete, TI SoCs >> >>are calling of_clk_init() during boot now, and thus external clock >> >>nodes should be registered fine also. Maybe you can provide the >> >>actual DTS patch you are trying out so we can help better...? Are >> > >> >See attached patch and console output. >> >> I see a bug in your dt data. >> >> <snip> >> >> + clocks { >> + ref27: ref27 { >> + #clock-cells = <0>; >> + compatibale = "fixed-clock"; >> >> This should be compatible, right? DT is annoying in that it doesn't >> verify property names. >> > > Ooops. > > Now the clock appears in /sys/kernel/debug/clk: > root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary > clock enable_cnt prepare_cnt rate accuracy phase > ---------------------------------------------------------------------------------------- > ref27 0 0 27000000 0 0 > ... > > There is still an issue with the si5351. > > I had to comment out the clk_put here for the frequency to show up: > http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 > > Ideas? What is the most recent upstream commit that you are based on? Regards, Mike > >> + clock-frequency = <27000000>; >> + }; >> + }; >> >> -Tero >> >> > >> >>you seeing any boot time error / warning prints for your new clock? >> > >> >With the debug messages on you see that the reference clock is not being >> >detected. >> > >> >Whilest debugging I found that the of_clk_get is returning an error no matter >> >which clock I pass it: >> >http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 >> > >> >> >> >>-Tero >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: > On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: > > On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote: > >> On 04/15/2015 05:09 PM, Michael Welling wrote: > >> >On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: > >> >>On 04/15/2015 12:17 AM, Michael Welling wrote: > >> >>>Greetings, > >> >>> > >> >>>I have developed an AM3354 based SoM and it uses an external SI5351 clock > >> >>>generator to drive the clock inputs for an external duart and I2S audio > >> >>>master clock. With the registration according to the documentation the > >> >>>reference clock is not being detected and hence the clock generator is > >> >>>not working as expect. > >> >>> > >> >>>After trying many different things, I started to look around the mailing > >> >>>lists to find information related to this issue. > >> >>> > >> >>>I came acrossed post that has the exact same issue: > >> >>>https://lkml.org/lkml/2013/2/18/468 > >> >>> > >> >>>Seeing as the patch did not land upstream, I am wondering if there is > >> >>>a solution that I am not seeing. > >> >>> > >> >>>I am willing to provide a patch given appropriate guidance. > >> >> > >> >>Hi Michael, > >> >> > >> >>The info on the email you referenced is kind of obsolete, TI SoCs > >> >>are calling of_clk_init() during boot now, and thus external clock > >> >>nodes should be registered fine also. Maybe you can provide the > >> >>actual DTS patch you are trying out so we can help better...? Are > >> > > >> >See attached patch and console output. > >> > >> I see a bug in your dt data. > >> > >> <snip> > >> > >> + clocks { > >> + ref27: ref27 { > >> + #clock-cells = <0>; > >> + compatibale = "fixed-clock"; > >> > >> This should be compatible, right? DT is annoying in that it doesn't > >> verify property names. > >> > > > > Ooops. > > > > Now the clock appears in /sys/kernel/debug/clk: > > root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary > > clock enable_cnt prepare_cnt rate accuracy phase > > ---------------------------------------------------------------------------------------- > > ref27 0 0 27000000 0 0 > > ... > > > > There is still an issue with the si5351. > > > > I had to comment out the clk_put here for the frequency to show up: > > http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 > > > > Ideas? > > What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab > > Regards, > Mike > > > > >> + clock-frequency = <27000000>; > >> + }; > >> + }; > >> > >> -Tero > >> > >> > > >> >>you seeing any boot time error / warning prints for your new clock? > >> > > >> >With the debug messages on you see that the reference clock is not being > >> >detected. > >> > > >> >Whilest debugging I found that the of_clk_get is returning an error no matter > >> >which clock I pass it: > >> >http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 > >> > > >> >> > >> >>-Tero > >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/15/2015 11:51 PM, Michael Welling wrote: > On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: >> On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: >>> On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote: >>>> On 04/15/2015 05:09 PM, Michael Welling wrote: >>>>> On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: >>>>>> On 04/15/2015 12:17 AM, Michael Welling wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I have developed an AM3354 based SoM and it uses an external SI5351 clock >>>>>>> generator to drive the clock inputs for an external duart and I2S audio >>>>>>> master clock. With the registration according to the documentation the >>>>>>> reference clock is not being detected and hence the clock generator is >>>>>>> not working as expect. >>>>>>> >>>>>>> After trying many different things, I started to look around the mailing >>>>>>> lists to find information related to this issue. >>>>>>> >>>>>>> I came acrossed post that has the exact same issue: >>>>>>> https://lkml.org/lkml/2013/2/18/468 >>>>>>> >>>>>>> Seeing as the patch did not land upstream, I am wondering if there is >>>>>>> a solution that I am not seeing. >>>>>>> >>>>>>> I am willing to provide a patch given appropriate guidance. >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> The info on the email you referenced is kind of obsolete, TI SoCs >>>>>> are calling of_clk_init() during boot now, and thus external clock >>>>>> nodes should be registered fine also. Maybe you can provide the >>>>>> actual DTS patch you are trying out so we can help better...? Are >>>>> >>>>> See attached patch and console output. >>>> >>>> I see a bug in your dt data. >>>> >>>> <snip> >>>> >>>> + clocks { >>>> + ref27: ref27 { >>>> + #clock-cells = <0>; >>>> + compatibale = "fixed-clock"; >>>> >>>> This should be compatible, right? DT is annoying in that it doesn't >>>> verify property names. >>>> >>> >>> Ooops. >>> >>> Now the clock appears in /sys/kernel/debug/clk: >>> root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary >>> clock enable_cnt prepare_cnt rate accuracy phase >>> ---------------------------------------------------------------------------------------- >>> ref27 0 0 27000000 0 0 >>> ... >>> >>> There is still an issue with the si5351. >>> >>> I had to comment out the clk_put here for the frequency to show up: >>> http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 >>> >>> Ideas? >> >> What is the most recent upstream commit that you are based on? > > I am working from 4.0.0-rc7. > > 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. -Tero > >> >> Regards, >> Mike >> >>> >>>> + clock-frequency = <27000000>; >>>> + }; >>>> + }; >>>> >>>> -Tero >>>> >>>>> >>>>>> you seeing any boot time error / warning prints for your new clock? >>>>> >>>>> With the debug messages on you see that the reference clock is not being >>>>> detected. >>>>> >>>>> Whilest debugging I found that the of_clk_get is returning an error no matter >>>>> which clock I pass it: >>>>> http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 >>>>> >>>>>> >>>>>> -Tero >>>> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: > On 04/15/2015 11:51 PM, Michael Welling wrote: > >On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: > >>On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: > >>>On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote: > >>>>On 04/15/2015 05:09 PM, Michael Welling wrote: > >>>>>On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote: > >>>>>>On 04/15/2015 12:17 AM, Michael Welling wrote: > >>>>>>>Greetings, > >>>>>>> > >>>>>>>I have developed an AM3354 based SoM and it uses an external SI5351 clock > >>>>>>>generator to drive the clock inputs for an external duart and I2S audio > >>>>>>>master clock. With the registration according to the documentation the > >>>>>>>reference clock is not being detected and hence the clock generator is > >>>>>>>not working as expect. > >>>>>>> > >>>>>>>After trying many different things, I started to look around the mailing > >>>>>>>lists to find information related to this issue. > >>>>>>> > >>>>>>>I came acrossed post that has the exact same issue: > >>>>>>>https://lkml.org/lkml/2013/2/18/468 > >>>>>>> > >>>>>>>Seeing as the patch did not land upstream, I am wondering if there is > >>>>>>>a solution that I am not seeing. > >>>>>>> > >>>>>>>I am willing to provide a patch given appropriate guidance. > >>>>>> > >>>>>>Hi Michael, > >>>>>> > >>>>>>The info on the email you referenced is kind of obsolete, TI SoCs > >>>>>>are calling of_clk_init() during boot now, and thus external clock > >>>>>>nodes should be registered fine also. Maybe you can provide the > >>>>>>actual DTS patch you are trying out so we can help better...? Are > >>>>> > >>>>>See attached patch and console output. > >>>> > >>>>I see a bug in your dt data. > >>>> > >>>><snip> > >>>> > >>>>+ clocks { > >>>>+ ref27: ref27 { > >>>>+ #clock-cells = <0>; > >>>>+ compatibale = "fixed-clock"; > >>>> > >>>>This should be compatible, right? DT is annoying in that it doesn't > >>>>verify property names. > >>>> > >>> > >>>Ooops. > >>> > >>>Now the clock appears in /sys/kernel/debug/clk: > >>>root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary > >>> clock enable_cnt prepare_cnt rate accuracy phase > >>>---------------------------------------------------------------------------------------- > >>> ref27 0 0 27000000 0 0 > >>>... > >>> > >>>There is still an issue with the si5351. > >>> > >>>I had to comment out the clk_put here for the frequency to show up: > >>>http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 > >>> > >>>Ideas? > >> > >>What is the most recent upstream commit that you are based on? > > > >I am working from 4.0.0-rc7. > > > >7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab > > Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get > in the first place, as far as I understand this destroys the clock > handle, which is still being used later in the code. > > -Tero Not sure how this ever worked. This has been in the code since the initial commit. Sebastian? > > > > >> > >>Regards, > >>Mike > >> > >>> > >>>>+ clock-frequency = <27000000>; > >>>>+ }; > >>>>+ }; > >>>> > >>>>-Tero > >>>> > >>>>> > >>>>>>you seeing any boot time error / warning prints for your new clock? > >>>>> > >>>>>With the debug messages on you see that the reference clock is not being > >>>>>detected. > >>>>> > >>>>>Whilest debugging I found that the of_clk_get is returning an error no matter > >>>>>which clock I pass it: > >>>>>http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131 > >>>>> > >>>>>> > >>>>>>-Tero > >>>> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 16.04.2015 18:17, Michael Welling wrote: > On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: >> On 04/15/2015 11:51 PM, Michael Welling wrote: >>> On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: >>>> On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: [...] >>>>> There is still an issue with the si5351. >>>>> >>>>> I had to comment out the clk_put here for the frequency to show up: >>>>> http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 >>>>> >>>>> Ideas? >>>> >>>> What is the most recent upstream commit that you are based on? >>> >>> I am working from 4.0.0-rc7. >>> >>> 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab >> >> Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get >> in the first place, as far as I understand this destroys the clock >> handle, which is still being used later in the code. > > Not sure how this ever worked. This has been in the code since the > initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: > On 16.04.2015 18:17, Michael Welling wrote: > >On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: > >>On 04/15/2015 11:51 PM, Michael Welling wrote: > >>>On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: > >>>>On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: > [...] > >>>>>There is still an issue with the si5351. > >>>>> > >>>>>I had to comment out the clk_put here for the frequency to show up: > >>>>>http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 > >>>>> > >>>>>Ideas? > >>>> > >>>>What is the most recent upstream commit that you are based on? > >>> > >>>I am working from 4.0.0-rc7. > >>> > >>>7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab > >> > >>Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get > >>in the first place, as far as I understand this destroys the clock > >>handle, which is still being used later in the code. > > > >Not sure how this ever worked. This has been in the code since the > >initial commit. > > The reason it worked before may be related with recent rework of > clk_put() itself and clk cookies instead of pointers. I lost track on > the recent clk subsystem changes here, sorry. > > However, droping the clk immediately surely isn't right. > The thing is, we can remove the clk_put() just because there is no > _remove() for that driver. I remember that back in the days the driver > was mainlined, clk removal wasn't too easy. > > FWIW, as soon as _remove() support will be added by someone, we'll have > to rethink passing struct clk* by platform_data or at least > double-check if we ever used [of_]clk_get() to obtain it. > > Mind to send a patch removing the clk_put() on !IS_ERR and add a proper > error path instead? While of_clk_get() is the only calls that need > cleanup on error in si5351_dt_parse() we should probably move that > calls to the end of this function. Otherwise we'd also have to cleanup > on every of_parse_foo() failure. What would be the proper error path? What cleanup is required? It should be noted that there are more deep rooted issues with the driver that I have noticed. For one the driver behaves differently if the debugging is on and when it is off. Here is what the kernel reports with debugging off: root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------------------------- ref27 0 0 27000000 0 0 xtal 0 0 27000000 0 0 pllb 0 0 599999994 0 0 ms0 0 0 12499999 0 0 clk0 0 0 12499999 0 0 plla 0 0 599999994 0 0 ms2 0 0 8219178 0 0 clk2 0 0 8219178 0 0 ms1 0 0 94117646 0 0 clk1 0 0 94117646 0 0 Here is what the kernel reports with debugging on: clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------------------------- ref27 0 0 27000000 0 0 xtal 0 0 27000000 0 0 pllb 0 0 884736000 0 0 ms0 0 0 18432000 0 0 clk0 0 0 18432000 0 0 plla 0 0 897023997 0 0 ms2 0 0 12287999 0 0 clk2 0 0 12287999 0 0 ms1 0 0 140709646 0 0 clk1 0 0 140709646 0 0 Note this is with the following devicetree entry: si5351: clock-generator { #address-cells = <1>; #size-cells = <0>; #clock-cells = <1>; compatible = "silabs,si5351a-msop"; reg = <0x60>; status = "okay"; /* connect xtal input to 27MHz reference */ clocks = <&ref27>; /* connect xtal input as source of pll0 and pll1 */ silabs,pll-source = <0 0>, <1 0>; clkout0: clkout0 { reg = <0>; silabs,drive-strength = <8>; silabs,multisynth-source = <1>; silabs,clock-source = <0>; silabs,pll-master; clock-frequency = <18432000>; }; clkout1: clkout1 { reg = <1>; silabs,drive-strength = <8>; silabs,multisynth-source = <0>; silabs,clock-source = <0>; clock-frequency = <8000000>; }; clkout2: clkout2 { reg = <2>; silabs,drive-strength = <8>; silabs,multisynth-source = <0>; silabs,clock-source = <0>; silabs,pll-master; clock-frequency = <12288000>; }; }; I am losing hope that this driver is stable enough to even use in production. > > Sebastian > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17.04.2015 00:09, Michael Welling wrote: > On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: >> On 16.04.2015 18:17, Michael Welling wrote: >>> On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: >>>> On 04/15/2015 11:51 PM, Michael Welling wrote: >>>>> On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: >>>>>> On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote: >> [...] >>>>>>> There is still an issue with the si5351. >>>>>>> >>>>>>> I had to comment out the clk_put here for the frequency to show up: >>>>>>> http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 >>>>>>> >>>>>>> Ideas? >>>>>> >>>>>> What is the most recent upstream commit that you are based on? >>>>> >>>>> I am working from 4.0.0-rc7. >>>>> >>>>> 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab >>>> >>>> Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get >>>> in the first place, as far as I understand this destroys the clock >>>> handle, which is still being used later in the code. >>> >>> Not sure how this ever worked. This has been in the code since the >>> initial commit. >> >> The reason it worked before may be related with recent rework of >> clk_put() itself and clk cookies instead of pointers. I lost track on >> the recent clk subsystem changes here, sorry. >> >> However, droping the clk immediately surely isn't right. >> The thing is, we can remove the clk_put() just because there is no >> _remove() for that driver. I remember that back in the days the driver >> was mainlined, clk removal wasn't too easy. >> >> FWIW, as soon as _remove() support will be added by someone, we'll have >> to rethink passing struct clk* by platform_data or at least >> double-check if we ever used [of_]clk_get() to obtain it. >> >> Mind to send a patch removing the clk_put() on !IS_ERR and add a proper >> error path instead? While of_clk_get() is the only calls that need >> cleanup on error in si5351_dt_parse() we should probably move that >> calls to the end of this function. Otherwise we'd also have to cleanup >> on every of_parse_foo() failure. > > What would be the proper error path? > What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. > It should be noted that there are more deep rooted issues with the driver > that I have noticed. For one the driver behaves differently if the debugging > is on and when it is off. I guess you mean #define DEBUG in the driver? > Here is what the kernel reports with debugging off: Do you have any measurement equipment to check what is actually set? > root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary > clock enable_cnt prepare_cnt rate accuracy phase > ---------------------------------------------------------------------------------------- > ref27 0 0 27000000 0 0 > xtal 0 0 27000000 0 0 > pllb 0 0 599999994 0 0 > ms0 0 0 12499999 0 0 > clk0 0 0 12499999 0 0 > plla 0 0 599999994 0 0 > ms2 0 0 8219178 0 0 > clk2 0 0 8219178 0 0 > ms1 0 0 94117646 0 0 > clk1 0 0 94117646 0 0 > > Here is what the kernel reports with debugging on: > clock enable_cnt prepare_cnt rate accuracy phase > ---------------------------------------------------------------------------------------- > ref27 0 0 27000000 0 0 > xtal 0 0 27000000 0 0 > pllb 0 0 884736000 0 0 > ms0 0 0 18432000 0 0 > clk0 0 0 18432000 0 0 Is this what you expect for clk0? > plla 0 0 897023997 0 0 > ms2 0 0 12287999 0 0 > clk2 0 0 12287999 0 0 ditto for clk2? > ms1 0 0 140709646 0 0 > clk1 0 0 140709646 0 0 This is wrong, I agree. Looks like round_rate()/recalc_rate() of msynth or clkout is broken with respect to non-pll-master clocks. I had a quick look at drivers/clk.c too, there has been a lot of churn in clk API since I last booted my device using si5351. Is there any way to try out a less recent kernel, let's say two or three releases before 4.0? We should just confirm that there has been an issue with it before already. I have no clue about the debug on/off issue at the moment. > Note this is with the following devicetree entry: > si5351: clock-generator { > #address-cells = <1>; > #size-cells = <0>; > #clock-cells = <1>; > compatible = "silabs,si5351a-msop"; > reg = <0x60>; > status = "okay"; > > /* connect xtal input to 27MHz reference */ > clocks = <&ref27>; > > /* connect xtal input as source of pll0 and pll1 */ > silabs,pll-source = <0 0>, <1 0>; > > clkout0: clkout0 { > reg = <0>; > silabs,drive-strength = <8>; > silabs,multisynth-source = <1>; > silabs,clock-source = <0>; > silabs,pll-master; > clock-frequency = <18432000>; > }; > > clkout1: clkout1 { > reg = <1>; > silabs,drive-strength = <8>; > silabs,multisynth-source = <0>; > silabs,clock-source = <0>; > clock-frequency = <8000000>; > }; > > clkout2: clkout2 { > reg = <2>; > silabs,drive-strength = <8>; > silabs,multisynth-source = <0>; > silabs,clock-source = <0>; > silabs,pll-master; > clock-frequency = <12288000>; > }; > }; > > I am losing hope that this driver is stable enough to even use in production. Who said it is stable for production use? The driver is written from scratch based on _very_ limited information of the datasheet an appnote. Also, I only have a single setup with si5351, that is no way enough to test every combination. I never heard serious complaints before, so either you help improving this driver or better ask SiLabs for a table-based driver for your specific setup. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index a1c776b..3d2d516 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -401,7 +401,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \ am335x-evmsk.dtb \ am335x-nano.dtb \ am335x-pepper.dtb \ - am335x-lxm.dtb + am335x-lxm.dtb \ + som-3354-200es.dtb dtb-$(CONFIG_ARCH_OMAP4) += \ omap4-duovero-parlor.dtb \ omap4-panda.dtb \ diff --git a/arch/arm/boot/dts/som-3354-200es.dts b/arch/arm/boot/dts/som-3354-200es.dts new file mode 100644 index 0000000..03f06e8 --- /dev/null +++ b/arch/arm/boot/dts/som-3354-200es.dts @@ -0,0 +1,590 @@ +/* + * som-3354-200es.dts - Device Tree file for the SOM-3354M with SOM-200ES. + * + * Copyright (C) 2015 EMAC Inc. + * Copyright (C) 2015 QWERTY Embedded Design + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +/dts-v1/; + +#include "am33xx.dtsi" + +/ { + model = "EMAC SOM-3354M SOM-200ES"; + compatible = "emac,som3354", "ti,am33xx"; + + cpus { + cpu@0 { + cpu0-supply = <&vdd1_reg>; + }; + }; + + memory { + device_type = "memory"; + reg = <0x80000000 0x20000000>; /* 512 MB */ + }; + + leds { + pinctrl-names = "default"; + pinctrl-0 = <&leds_pins>; + + compatible = "gpio-leds"; + + led@0 { + label = "stat"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-state = "on"; + }; + }; + + vmain: fixedregulator@0 { + compatible = "regulator-fixed"; + regulator-name = "vmain"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + backlight { + compatible = "pwm-backlight"; + pwms = <&ecap2 0 50000 0>; + brightness-levels = <0 51 53 56 62 75 101 152 255>; + default-brightness-level = <8>; + }; + + panel { + compatible = "ti,tilcdc,panel"; + pinctrl-names = "default"; + pinctrl-0 = <&lcd_pins>; + status = "okay"; + + enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; + + panel-info { + ac-bias = <255>; + ac-bias-intrpt = <0>; + dma-burst-sz = <16>; + bpp = <16>; + fdd = <0x80>; + tft-alt-mode = <0>; + stn-565-mode = <0>; + mono-8bit-mode = <0>; + sync-edge = <0>; + sync-ctrl = <0>; + raster-order = <1>; + fifo-th = <0>; + }; + + display-timings { + native-mode = <&timing0>; + timing0: 480x272 { + hactive = <480>; + vactive = <272>; + hback-porch = <1>; + hfront-porch = <44>; + hsync-len = <45>; + vback-porch = <1>; + vfront-porch = <13>; + vsync-len = <14>; + clock-frequency = <9000000>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <1>; + }; + }; + }; + + clocks { + ref27: ref27 { + #clock-cells = <0>; + compatibale = "fixed-clock"; + clock-frequency = <27000000>; + }; + }; + +/* + sound { + compatible = "ti,da830-evm-audio"; + ti,model = "SOM3354 CS4271"; + ti,audio-codec = <&cs4271>; + ti,mcasp-controller = <&mcasp0>; + ti,codec-clock-rate = <12288000>; + ti,audio-routing = + "Line Out", "AOUTA+", + "Line Out", "AOUTA-", + "Line Out", "AOUTB+", + "Line Out", "AOUTB-"; + }; +*/ +}; + +&mcasp0 { + pinctrl-names = "default"; + pinctrl-0 = <&mcasp0_pins>; + + status = "okay"; + + op-mode = <0>; /* MCASP_IIS_MODE */ + tdm-slots = <2>; + /* 4 serializers */ + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */ + 2 1 0 0 + >; + tx-num-evt = <2>; + rx-num-evt = <2>; +}; + +&am33xx_pinmux { + + lcd_pins: pinmux_lcd_pins { + pinctrl-single,pins = < + 0xa0 0x00 /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xa4 0x00 /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xa8 0x00 /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xac 0x00 /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xb0 0x00 /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xb4 0x00 /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xb8 0x00 /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xbc 0x00 /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xc0 0x00 /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xc4 0x00 /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xc8 0x00 /* lcd_data10.lcd_data10, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xcc 0x00 /* lcd_data11.lcd_data11, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xd0 0x00 /* lcd_data12.lcd_data12, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xd4 0x00 /* lcd_data13.lcd_data13, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xd8 0x00 /* lcd_data14.lcd_data14, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xdc 0x00 /* lcd_data15.lcd_data15, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + /* 0x3c 0x11 gpmc_ad15.lcd_data16, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT */ + /* 0x38 0x11 gpmc_ad14.lcd_data17, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT */ + 0xe0 0x00 /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xe4 0x00 /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xe8 0x00 /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + >; + }; + + mcasp0_pins: mcasp0_pins { + pinctrl-single,pins = < + 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx (transmit bit clock - SCLK) */ + 0x194 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx (transmit frame sync - LRCLK) */ + 0x198 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_axr0.mcasp0_axr0 (serial data - SDIN) */ + 0x1a8 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mcasp0_axr1.mcasp0_axr1 (serial data - SDOUT) */ + >; + }; + + spi0_pins: spi0_pins { + pinctrl-single,pins = < + 0x150 (PIN_INPUT_PULLUP | MUX_MODE0) /* spi0_sclk */ + 0x154 (PIN_INPUT_PULLUP | MUX_MODE0) /* spi0_d0 */ + 0x158 (PIN_INPUT_PULLUP | MUX_MODE0) /* spi0_d1 */ + 0x15c (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_cs0 */ + 0x160 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_cs1 */ + 0x234 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* fake chip select */ + >; + }; + + can0_pins: pinmux_can0_pins { + pinctrl-single,pins = < + 0x11c (PIN_OUTPUT_PULLUP | MUX_MODE1) /* mii1_txd3.rgmii1_td3 */ + 0x120 (PIN_INPUT_PULLUP | MUX_MODE1) /* mii1_txd2.rgmii1_td2 */ + >; + }; + + i2c0_pins: pinmux_i2c0_pins { + pinctrl-single,pins = < + 0x188 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_sda.i2c0_sda */ + 0x18c (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_scl.i2c0_scl */ + >; + }; + + gpmc_pins: pinmux_gpmc_pins { + pinctrl-single,pins = < + 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */ + 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */ + 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */ + 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */ + 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */ + 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */ + 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */ + 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */ + 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */ + 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /* gpmc_wpn.gpio0_30 */ + 0x7c (PIN_OUTPUT | MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */ + 0x88 (PIN_OUTPUT | MUX_MODE0) /* gpmc_csn3.gpmc_csn3 */ + 0x90 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */ + 0x94 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */ + 0x98 (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen.gpmc_wen */ + 0x9c (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle.gpmc_be0n_cle */ + >; + }; + + uart0_pins: pinmux_uart0_pins { + pinctrl-single,pins = < + 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */ + 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ + >; + }; + + uart1_pins: uart1_pins { + pinctrl-single,pins = < + 0x178 (PIN_OUTPUT | MUX_MODE7) /* uart1_ctsn.uart1_ctsn */ + 0x17c (PIN_OUTPUT | MUX_MODE7) /* uart1_rtsn.uart1_rtsn */ + 0x180 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart1_rxd.uart1_rxd */ + 0x184 (PIN_OUTPUT | MUX_MODE0) /* uart1_txd.uart1_txd */ + >; + }; + + leds_pins: pinmux_leds_pins { + pinctrl-single,pins = < + 0x118 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* mii1_rxdv.gpio3_4 */ + >; + }; + + ecap2_pins: backlight_pins { + pinctrl-single,pins = < + 0x19c MUX_MODE4 /* mcasp0_ahclkr.eCAP2_in_PWM2_out */ + >; + }; + + +}; + +&lcdc { + status = "okay"; +}; + +&epwmss2 { + status = "okay"; + + ecap2: ecap@48304100 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&ecap2_pins>; + }; +}; + +&tscadc { + status = "okay"; + tsc { + ti,wires = <4>; + ti,x-plate-resistance = <200>; + ti,coordinate-readouts = <5>; + ti,wire-config = <0x00 0x11 0x22 0x33>; + ti,charge-delay = <0x4000>; + }; + + adc { + ti,adc-channels = <4 5 6 7>; + }; +}; + +&epwmss2 { + status = "okay"; +}; + +&ehrpwm2 { + status = "okay"; +}; + +&mac { + status = "okay"; +}; + +&davinci_mdio { + status = "okay"; +}; + +&cpsw_emac0 { + phy_id = <&davinci_mdio>, <1>; + phy-mode = "rmii"; +}; + +&cpsw_emac1 { + phy_id = <&davinci_mdio>, <2>; + phy-mode = "rmii"; +}; + +&phy_sel { + rmii-clock-ext; +}; + +&elm { + status = "okay"; +}; + +&spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&spi0_pins>; + status = "okay"; + cs-gpios = <&gpio0 5 0>,<&gpio0 6 0>; + /* + cs4271: cs4271@2 { + compatible = "cirrus,cs4271"; + spi-cpol; + spi-cpha; + reg = <2>; + spi-max-frequency = <1000000>; + status = "okay"; + }; + */ + mcp23s08: mcp23s08@1 { + compatible = "mcp,mcp23s08"; + gpio-controller; + #gpio-cells = <2>; + mcp,spi-present-mask = <0x01>; + spi-max-frequency = <1000000>; + reg = <1>; + status = "okay"; + }; + + flash: m25p80@0 { + compatible = "sst,n25q128a13"; + spi-max-frequency = <40000000>; + reg = <0>; + status = "okay"; + }; +}; + +&gpmc { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&gpmc_pins>; + + ranges = <0x3 0 0x08000000 0x1000000>; /* CS3: DUART */ + + uart@3,0 { + compatible = "ns16550a"; + reg = <0x3 0x0 0x8>; + clock-frequency = <18432000>; + current-speed = <115200>; + bank-width = <2>; + reg-shift = <0>; + reg-io-width = <1>; + gpmc,mux-add-data = <0>; + gpmc,device-width = <1>; + gpmc,wait-pin = <0>; + gpmc,cs-on-ns = <18>; + gpmc,cs-rd-off-ns = <295>; + gpmc,cs-wr-off-ns = <295>; + gpmc,adv-on-ns = <73>; + gpmc,adv-rd-off-ns = <92>; + gpmc,adv-wr-off-ns = <110>; + gpmc,oe-on-ns = <110>; + gpmc,oe-off-ns = <295>; + gpmc,we-on-ns = <92>; + gpmc,we-off-ns = <295>; + gpmc,rd-cycle-ns = <300>; + gpmc,wr-cycle-ns = <300>; + gpmc,access-ns = <276>; + gpmc,page-burst-access-ns = <18>; + gpmc,bus-turnaround-ns = <0>; + gpmc,cycle2cycle-delay-ns = <0>; + gpmc,wait-monitoring-ns = <0>; + gpmc,clk-activation-ns = <0>; + gpmc,wr-data-mux-bus-ns = <129>; + gpmc,wr-access-ns = <276>; + status = "okay"; + }; + + uart@3,1 { + compatible = "ns16550a"; + reg = <0x3 0x8 0x8>; + clock-frequency = <18432000>; + current-speed = <115200>; + bank-width = <2>; + reg-shift = <0>; + reg-io-width = <1>; + status = "okay"; + }; +}; + +&dcan0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&can0_pins>; +}; + +&i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_pins>; + + clock-frequency = <400000>; + + tps: tps@2d { + reg = <0x2d>; + }; + + si5351: clock-generator { + #address-cells = <1>; + #size-cells = <0>; + #clock-cells = <1>; + compatible = "silabs,si5351a-msop"; + reg = <0x60>; + status = "okay"; + + /* connect xtal input to 27MHz reference */ + clocks = <&ref27>; + + /* connect xtal input as source of pll0 and pll1 */ + silabs,pll-source = <0 0>, <1 0>; + + clkout0: clkout0 { + reg = <0>; + silabs,drive-strength = <8>; + silabs,multisynth-source = <0>; + silabs,clock-source = <0>; + silabs,pll-master; + clock-frequency = <18432000>; + }; + + clkout1: clkout1 { + reg = <1>; + silabs,drive-strength = <8>; + silabs,multisynth-source = <1>; + silabs,clock-source = <0>; + silabs,pll-master; + }; + + clkout2: clkout2 { + reg = <2>; + silabs,multisynth-source = <1>; + silabs,clock-source = <0>; + }; + }; +}; + +&mmc1 { + status = "okay"; + vmmc-supply = <&vmain>; + bus-width = <4>; +}; + +&mmc2 { + status = "okay"; + vmmc-supply = <&vmain>; + bus-width = <4>; +}; + +&uart0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&uart0_pins>; +}; + +&uart1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>; +}; + +&usb { + status = "okay"; +}; + +&usb_ctrl_mod { + status = "okay"; +}; + +&usb0_phy { + status = "okay"; +}; + +&usb1_phy { + status = "okay"; +}; + +&usb0 { + status = "okay"; +}; + +&usb1 { + status = "okay"; + dr_mode = "host"; +}; + +&cppi41dma { + status = "okay"; +}; + +#include "tps65910.dtsi" + +&tps { + vcc1-supply = <&vmain>; + vcc2-supply = <&vmain>; + vcc3-supply = <&vmain>; + vcc4-supply = <&vmain>; + vcc5-supply = <&vmain>; + vcc6-supply = <&vmain>; + vcc7-supply = <&vmain>; + vccio-supply = <&vmain>; + + regulators { + vrtc_reg: regulator@0 { + regulator-always-on; + }; + + vio_reg: regulator@1 { + regulator-always-on; + }; + + vdd1_reg: regulator@2 { + /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */ + regulator-name = "vdd_mpu"; + regulator-min-microvolt = <912500>; + regulator-max-microvolt = <1312500>; + regulator-boot-on; + regulator-always-on; + }; + + vdd2_reg: regulator@3 { + /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */ + regulator-name = "vdd_core"; + regulator-min-microvolt = <912500>; + regulator-max-microvolt = <1150000>; + regulator-boot-on; + regulator-always-on; + }; + + vdd3_reg: regulator@4 { + regulator-always-on; + }; + + vdig1_reg: regulator@5 { + regulator-always-on; + }; + + vdig2_reg: regulator@6 { + regulator-always-on; + }; + + vpll_reg: regulator@7 { + regulator-always-on; + }; + + vdac_reg: regulator@8 { + regulator-always-on; + }; + + vaux1_reg: regulator@9 { + regulator-always-on; + }; + + vaux2_reg: regulator@10 { + regulator-always-on; + }; + + vaux33_reg: regulator@11 { + regulator-always-on; + }; + + vmmc_reg: regulator@12 { + regulator-always-on; + }; + }; +}; diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c index 3b2a66f..6afae8f 100644 --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -15,7 +15,7 @@ * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. */ - +#define DEBUG #include <linux/module.h> #include <linux/kernel.h> #include <linux/clkdev.h>