Re: [PATCH] clk: debug clock tree
On Monday 24 December 2012 11:07 PM, Mike Turquette wrote: On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad wrote: On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote: Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Thanks Mike!! Are you going to take a crack at JSON-formatted output for clk-dump? I will work on it. Thanks, Mike Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad wrote: > On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: >> >> On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad >> wrote: >>> >>> On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: > > On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad > wrote: >> >> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. >> It helps to view all the clock registered in tree format. >> > Prashant, > > Thanks for submitting this. We've been talking about having a single > file for representing the tree for some time. > > Regarding the output format had you considered using a well known > format which can be parsed using well known parsing libs? This avoids > needing a custom parser just for this one file. JSON springs to mind > as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. >> For example: >> clockenable_cnt prepare_cnt rate >> - >>i2s0_sync 0 02400 >>spdif_in_sync 0 02400 >> spdif_mux 0 02400 >> spdif0 02400 >> spdif_doubler 0 04800 >>spdif_div 0 04800 >> spdif_2x0 04800 >>> Even I think that output must be easily human-readable. How about adding >>> sysfs to switch between human-readable and machine-readable format? >>> I will try come up with a implementation. >>> >> Do you mean a sysfs file which controls the output format? How about >> just two different files? One can be clk-dump (machine readable) and >> the other is clk-summary (human readable). > > > It is also fine. Is this patch ok for human-readable format? or any > suggestions? > I will change the file name to clk-summary. > Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Are you going to take a crack at JSON-formatted output for clk-dump? Thanks, Mike >> >> Regards, >> Mike > > -- 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: [PATCH] clk: debug clock tree
On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Are you going to take a crack at JSON-formatted output for clk-dump? Thanks, Mike Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Monday 24 December 2012 11:07 PM, Mike Turquette wrote: On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Thanks Mike!! Are you going to take a crack at JSON-formatted output for clk-dump? I will work on it. Thanks, Mike Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote: Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad wrote: > On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: >> >> On 12/13/2012 09:27 AM, Mike Turquette wrote: >>> >>> On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad >>> wrote: Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. >>> Prashant, >>> >>> Thanks for submitting this. We've been talking about having a single >>> file for representing the tree for some time. >>> >>> Regarding the output format had you considered using a well known >>> format which can be parsed using well known parsing libs? This avoids >>> needing a custom parser just for this one file. JSON springs to mind >>> as something lightweight and well-understood. >> >> One advantage of the format below is that it's very easily >> human-readable, and it's not too hard to parse (although I guess you'd >> have to parse the indent level to get parent/child relation, which would >> suck a bit). Is there room to provide both? Otherwise, I guess the >> kernel could include a script to convert from JSON/whatever into the >> format below. >> For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 >> >> > > Even I think that output must be easily human-readable. How about adding > sysfs to switch between human-readable and machine-readable format? > I will try come up with a implementation. > Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). Regards, Mike -- 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: [PATCH] clk: debug clock tree
On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote: Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. -- 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: [PATCH] clk: debug clock tree
On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. -- 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: [PATCH] clk: debug clock tree
On Fri, Dec 14, 2012 at 2:43 AM, Peter De Schrijver wrote: > On Thu, Dec 13, 2012 at 07:01:31PM +0100, Stephen Warren wrote: >> On 12/13/2012 09:27 AM, Mike Turquette wrote: >> > On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad >> > wrote: >> >> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. >> >> It helps to view all the clock registered in tree format. >> >> >> > >> > Prashant, >> > >> > Thanks for submitting this. We've been talking about having a single >> > file for representing the tree for some time. >> > >> > Regarding the output format had you considered using a well known >> > format which can be parsed using well known parsing libs? This avoids >> > needing a custom parser just for this one file. JSON springs to mind >> > as something lightweight and well-understood. >> >> One advantage of the format below is that it's very easily >> human-readable, and it's not too hard to parse (although I guess you'd >> have to parse the indent level to get parent/child relation, which would >> suck a bit). Is there room to provide both? Otherwise, I guess the >> kernel could include a script to convert from JSON/whatever into the >> format below. > > We already have the clk directory for an easy to parse version. So I think > this one should be focused on being human readable. > I'm really not sure the clk directory structure is such a good idea. Hopping around directories and dumping a few files feels like a strange way to get at the data. Another key point is atomicity. The prepare_lock mutex is only held for each individual read of a file under the current clock directory implementation. So if you wish to read several different clock rates there is a caveat that the rates could change between reads. The "summary" file that dumps all of the data improves on this since it could hold the prepare_lock mutex across the operation. This last point makes me realize that the current code above either needs to hold that lock or at least use hlist_for_each_entry_safe since clocks could be removed from the lists during the operation. As such it is a bit unsafe. I'm OK letting the two implementations live along side each other but I am also sure that the clock summary dump should be reasonably machine readable. Regards, Mike > Cheers, > > Peter. -- 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: [PATCH] clk: debug clock tree
On Thu, Dec 13, 2012 at 07:01:31PM +0100, Stephen Warren wrote: > On 12/13/2012 09:27 AM, Mike Turquette wrote: > > On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad > > wrote: > >> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. > >> It helps to view all the clock registered in tree format. > >> > > > > Prashant, > > > > Thanks for submitting this. We've been talking about having a single > > file for representing the tree for some time. > > > > Regarding the output format had you considered using a well known > > format which can be parsed using well known parsing libs? This avoids > > needing a custom parser just for this one file. JSON springs to mind > > as something lightweight and well-understood. > > One advantage of the format below is that it's very easily > human-readable, and it's not too hard to parse (although I guess you'd > have to parse the indent level to get parent/child relation, which would > suck a bit). Is there room to provide both? Otherwise, I guess the > kernel could include a script to convert from JSON/whatever into the > format below. We already have the clk directory for an easy to parse version. So I think this one should be focused on being human readable. Cheers, Peter. -- 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: [PATCH] clk: debug clock tree
On Thu, Dec 13, 2012 at 07:01:31PM +0100, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. We already have the clk directory for an easy to parse version. So I think this one should be focused on being human readable. Cheers, Peter. -- 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: [PATCH] clk: debug clock tree
On Fri, Dec 14, 2012 at 2:43 AM, Peter De Schrijver pdeschrij...@nvidia.com wrote: On Thu, Dec 13, 2012 at 07:01:31PM +0100, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. We already have the clk directory for an easy to parse version. So I think this one should be focused on being human readable. I'm really not sure the clk directory structure is such a good idea. Hopping around directories and dumping a few files feels like a strange way to get at the data. Another key point is atomicity. The prepare_lock mutex is only held for each individual read of a file under the current clock directory implementation. So if you wish to read several different clock rates there is a caveat that the rates could change between reads. The summary file that dumps all of the data improves on this since it could hold the prepare_lock mutex across the operation. This last point makes me realize that the current code above either needs to hold that lock or at least use hlist_for_each_entry_safe since clocks could be removed from the lists during the operation. As such it is a bit unsafe. I'm OK letting the two implementations live along side each other but I am also sure that the clock summary dump should be reasonably machine readable. Regards, Mike Cheers, Peter. -- 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: [PATCH] clk: debug clock tree
On 12/13/2012 09:27 AM, Mike Turquette wrote: > On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote: >> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. >> It helps to view all the clock registered in tree format. >> > > Prashant, > > Thanks for submitting this. We've been talking about having a single > file for representing the tree for some time. > > Regarding the output format had you considered using a well known > format which can be parsed using well known parsing libs? This avoids > needing a custom parser just for this one file. JSON springs to mind > as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. >> For example: >>clockenable_cnt prepare_cnt rate >> - >> i2s0_sync 0 02400 >> spdif_in_sync 0 02400 >> spdif_mux 0 02400 >>spdif0 02400 >> spdif_doubler 0 04800 >> spdif_div 0 04800 >> spdif_2x0 04800 -- 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: [PATCH] clk: debug clock tree
On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote:
> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir.
> It helps to view all the clock registered in tree format.
>
Prashant,
Thanks for submitting this. We've been talking about having a single
file for representing the tree for some time.
Regarding the output format had you considered using a well known
format which can be parsed using well known parsing libs? This avoids
needing a custom parser just for this one file. JSON springs to mind
as something lightweight and well-understood.
> For example:
>clockenable_cnt prepare_cnt rate
> -
> i2s0_sync 0 02400
> spdif_in_sync 0 02400
> spdif_mux 0 02400
>spdif0 02400
> spdif_doubler 0 04800
> spdif_div 0 04800
> spdif_2x0 04800
> clk_32k2 232768
> blink_override 1 132768
>blink1 132768
> clk_m 2 21200
> clk_out_3_mux 0 01200
>clk_out_30 01200
> pll_ref 3 31200
>pll_e_mux0 01200
> pll_e 0 01
> cml0 0 01
> cml1 0 01
> pciex 0 01
>pll_d2 0 0100
> pll_d2_out0 0 050
>pll_d0 0100
> pll_d_out00 050
> dsib_mux 0 050
> dsib0 050
> dsia 0 050
>
> Signed-off-by: Prashant Gaikwad
> ---
> drivers/clk/clk.c | 59
> +
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 56e4495e..7daf201 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -34,6 +34,59 @@ static struct dentry *rootdir;
> static struct dentry *orphandir;
> static int inited = 0;
>
> +static void clk_tree_show_one(struct seq_file *s, struct clk *c, int level)
> +{
> + if (!c)
> + return;
> +
> + seq_printf(s, "%*s%-*s %-11d %-12d %-10lu",
> + level * 3 + 1, "",
> + 30 - level * 3, c->name,
> + c->enable_count, c->prepare_count, c->rate);
> + seq_printf(s, "\n");
> +}
> +
> +static void clk_tree_show_subtree(struct seq_file *s, struct clk *c, int
> level)
> +{
> + struct clk *child;
> + struct hlist_node *tmp;
> +
> + if (!c)
> + return;
> +
> + clk_tree_show_one(s, c, level);
> +
> + hlist_for_each_entry(child, tmp, >children, child_node)
> + clk_tree_show_subtree(s, child, level + 1);
> +}
> +
> +static int clk_tree_show(struct seq_file *s, void *data)
> +{
> + struct clk *c;
> + struct hlist_node *tmp;
> +
> + seq_printf(s, " clockenable_cnt
> prepare_cnt rate\n");
> + seq_printf(s,
> "-\n");
> +
If we want this to be machine readable then we can probably drop the
heading and line of dashes altogether.
> + hlist_for_each_entry(c, tmp, _root_list, child_node)
> + clk_tree_show_subtree(s, c, 0);
> +
> + return 0;
> +}
> +
> +
> +static int clk_tree_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, clk_tree_show, inode->i_private);
> +}
> +
> +static const struct file_operations clk_tree_fops = {
> + .open = clk_tree_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= single_release,
> +};
> +
> /* caller must hold prepare_lock */
> static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
> {
> @@ -167,12 +220,18 @@ static int __init clk_debug_init(void)
> {
> struct clk *clk;
> struct hlist_node *tmp;
> + struct dentry *d;
>
> rootdir = debugfs_create_dir("clk", NULL);
>
> if
Re: [PATCH] clk: debug clock tree
On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote:
Adds debug file clock_tree in /sys/kernel/debug/clk dir.
It helps to view all the clock registered in tree format.
Prashant,
Thanks for submitting this. We've been talking about having a single
file for representing the tree for some time.
Regarding the output format had you considered using a well known
format which can be parsed using well known parsing libs? This avoids
needing a custom parser just for this one file. JSON springs to mind
as something lightweight and well-understood.
For example:
clockenable_cnt prepare_cnt rate
-
i2s0_sync 0 02400
spdif_in_sync 0 02400
spdif_mux 0 02400
spdif0 02400
spdif_doubler 0 04800
spdif_div 0 04800
spdif_2x0 04800
clk_32k2 232768
blink_override 1 132768
blink1 132768
clk_m 2 21200
clk_out_3_mux 0 01200
clk_out_30 01200
pll_ref 3 31200
pll_e_mux0 01200
pll_e 0 01
cml0 0 01
cml1 0 01
pciex 0 01
pll_d2 0 0100
pll_d2_out0 0 050
pll_d0 0100
pll_d_out00 050
dsib_mux 0 050
dsib0 050
dsia 0 050
Signed-off-by: Prashant Gaikwad pgaik...@nvidia.com
---
drivers/clk/clk.c | 59
+
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 56e4495e..7daf201 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -34,6 +34,59 @@ static struct dentry *rootdir;
static struct dentry *orphandir;
static int inited = 0;
+static void clk_tree_show_one(struct seq_file *s, struct clk *c, int level)
+{
+ if (!c)
+ return;
+
+ seq_printf(s, %*s%-*s %-11d %-12d %-10lu,
+ level * 3 + 1, ,
+ 30 - level * 3, c-name,
+ c-enable_count, c-prepare_count, c-rate);
+ seq_printf(s, \n);
+}
+
+static void clk_tree_show_subtree(struct seq_file *s, struct clk *c, int
level)
+{
+ struct clk *child;
+ struct hlist_node *tmp;
+
+ if (!c)
+ return;
+
+ clk_tree_show_one(s, c, level);
+
+ hlist_for_each_entry(child, tmp, c-children, child_node)
+ clk_tree_show_subtree(s, child, level + 1);
+}
+
+static int clk_tree_show(struct seq_file *s, void *data)
+{
+ struct clk *c;
+ struct hlist_node *tmp;
+
+ seq_printf(s,clockenable_cnt
prepare_cnt rate\n);
+ seq_printf(s,
-\n);
+
If we want this to be machine readable then we can probably drop the
heading and line of dashes altogether.
+ hlist_for_each_entry(c, tmp, clk_root_list, child_node)
+ clk_tree_show_subtree(s, c, 0);
+
+ return 0;
+}
+
+
+static int clk_tree_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, clk_tree_show, inode-i_private);
+}
+
+static const struct file_operations clk_tree_fops = {
+ .open = clk_tree_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
/* caller must hold prepare_lock */
static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
{
@@ -167,12 +220,18 @@ static int __init clk_debug_init(void)
{
struct clk *clk;
struct hlist_node *tmp;
+ struct dentry *d;
rootdir = debugfs_create_dir(clk, NULL);
if (!rootdir)
return -ENOMEM;
+ d = debugfs_create_file(clock_tree, S_IRUGO,
Re: [PATCH] clk: debug clock tree
On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad pgaik...@nvidia.com wrote: Adds debug file clock_tree in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 -- 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/
