RE: [PATCH 2/4] powerpc/device-tree: bindings for DSP cores/clusters for Freescale SOCs
> -Original Message- > From: Wood Scott-B07421 > Sent: Sunday, September 20, 2015 5:45 AM > To: Aggrwal Poonam-B10812 > Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org > Subject: Re: [PATCH 2/4] powerpc/device-tree: bindings for DSP > cores/clusters for Freescale SOCs > > On Sat, 2015-09-19 at 23:46 +0530, Poonam Aggrwal wrote: > > From: poonam aggrwal > > > > Device Tree Bindings for DSP CPU clusters and DSP CPUs for Freescale > > PowerPC SOCs which have DSP CPUs in addition to PowerPC CPUs. > > For example B4860 has 3 DSP clusters which have 2 SC3900 cores each. > > > > Signed-off-by: Poonam Aggrwal > > --- > > - based of: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > branch master > > > > This patch was sent earlier and some comments were received. Some have > > been taken care; others we can further discuss. Apologize for not > > following up on them in time. > > .../devicetree/bindings/powerpc/fsl/dsp-cpus.txt | 78 > > ++ > > 1 file changed, 78 insertions(+) > > create mode 100644 > Documentation/devicetree/bindings/powerpc/fsl/dsp- > > cpus.txt > > > > diff --git > > a/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > new file mode 100644 > > index 000..6d901ef > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > @@ -0,0 +1,78 @@ > > > += > == > > +Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which > > +have DSP CPUs in addition to PowerPC cpus. > > +Copyright 2013 Freescale Semiconductor Inc. > > + > > +Power Architecture CPUs in Freescale SOCs are represented in device > > +trees > > as > > +per the definition in ePAPR. > > + > > +Required properties for DSP CPU cluster: > > +- compatible : should be "fsl,sc3900-cluster". > > +- reg : should contain the cluster index > > + > > +Required properties for DSP CPU: > > +- compatible : should be "fsl,sc3900". > > +- reg : should contain index of DSP CPU within the DSP clsuter. > > +- next-level-cache : should point to the phandle of the next-level L2 > > cache. > > Why is the dsp-clusters container only shown in the example, not the binding > itself? I will try to add more description in the binding for cluster; And the structure of dsp cluster (like sub node of DSP cluster is core, etc). Did I get your feedback right? > > -Scott
RE: [PATCH 2/4] powerpc/device-tree: bindings for DSP cores/clusters for Freescale SOCs
> -Original Message- > From: Wood Scott-B07421 > Sent: Sunday, September 20, 2015 5:45 AM > To: Aggrwal Poonam-B10812 <poonam.aggr...@freescale.com> > Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org > Subject: Re: [PATCH 2/4] powerpc/device-tree: bindings for DSP > cores/clusters for Freescale SOCs > > On Sat, 2015-09-19 at 23:46 +0530, Poonam Aggrwal wrote: > > From: poonam aggrwal <poonam.aggr...@freescale.com> > > > > Device Tree Bindings for DSP CPU clusters and DSP CPUs for Freescale > > PowerPC SOCs which have DSP CPUs in addition to PowerPC CPUs. > > For example B4860 has 3 DSP clusters which have 2 SC3900 cores each. > > > > Signed-off-by: Poonam Aggrwal <poonam.aggr...@freescale.com> > > --- > > - based of: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > branch master > > > > This patch was sent earlier and some comments were received. Some have > > been taken care; others we can further discuss. Apologize for not > > following up on them in time. > > .../devicetree/bindings/powerpc/fsl/dsp-cpus.txt | 78 > > ++ > > 1 file changed, 78 insertions(+) > > create mode 100644 > Documentation/devicetree/bindings/powerpc/fsl/dsp- > > cpus.txt > > > > diff --git > > a/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > new file mode 100644 > > index 000..6d901ef > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > > @@ -0,0 +1,78 @@ > > > += > == > > +Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which > > +have DSP CPUs in addition to PowerPC cpus. > > +Copyright 2013 Freescale Semiconductor Inc. > > + > > +Power Architecture CPUs in Freescale SOCs are represented in device > > +trees > > as > > +per the definition in ePAPR. > > + > > +Required properties for DSP CPU cluster: > > +- compatible : should be "fsl,sc3900-cluster". > > +- reg : should contain the cluster index > > + > > +Required properties for DSP CPU: > > +- compatible : should be "fsl,sc3900". > > +- reg : should contain index of DSP CPU within the DSP clsuter. > > +- next-level-cache : should point to the phandle of the next-level L2 > > cache. > > Why is the dsp-clusters container only shown in the example, not the binding > itself? I will try to add more description in the binding for cluster; And the structure of dsp cluster (like sub node of DSP cluster is core, etc). Did I get your feedback right? > > -Scott
RE: [2/3][PATCH][v2] TDM Framework
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
> KH
> Sent: Friday, July 27, 2012 11:42 PM
> To: Singh Sandeep-B37400
> Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [2/3][PATCH][v2] TDM Framework
>
> On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> > +static struct kobj_type tdm_type = {
> > + .sysfs_ops = _ops,
> > + .default_attrs = tdm_attr,
> > +};
>
> Ah, also, as per the documentation in the kernel (go look, it's there), I
> now get to publicly mock you for ignoring the error messages that the
> kernel is giving you when you try to shut down your code path.
>
> Well, to be fair, you are leaking memory like a sieve, so I doubt you
> ever saw those error messages because you never cleaned up after
> yourself, so perhaps I can forgive you, but your users can't, sorry.
> They like to rely on the fact that Linux is a reliable operating system,
> don't cause them to doubt that.
>
> Please fix this code, it's horribly broken. Read
> Documentation/kobject.txt for why. That file was written for a reason,
> and not just because we like writing documentation (hint, we hate to...)
To be honest we are not sysfs experts. Thanks for pointing to the documentation.
We will rework the stuff.
Regards
Poonam
>
> Ugh,
>
> greg k-h
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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: [2/3][PATCH][v2] TDM Framework
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
> KH
> Sent: Friday, July 27, 2012 11:30 PM
> To: Singh Sandeep-B37400
> Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [2/3][PATCH][v2] TDM Framework
>
> On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> > +/* Data structures required for sysfs */ static struct tdm_sysfs attr
> > += {
> > + .attr.name = "use_latest_data",
> > + .attr.mode = 0664,
> > + .cmd_type = TDM_LATEST_DATA,
> > +};
>
> What is this for?
This knob is to control the behavior of the TDM framework with respect to
handling the received TDM frames.
The framework layer receives the TDM frames from the TDM adapter driver,
de-interleaves the data and sends to respective client modules.
In the case when the TDM client module has not consumed the data and emptied
the Buffer, this flag decides whether to discard the un-fetched data, or
discard the latest received data.
>
> > +int tdm_sysfs_init(void)
> > +{
> > + struct kobject *tdm_kobj;
> > + int err = 1;
> > + tdm_kobj = kzalloc(sizeof(*tdm_kobj), GFP_KERNEL);
> > + if (tdm_kobj) {
> > + kobject_init(tdm_kobj, _type);
> > + if (kobject_add(tdm_kobj, NULL, "%s", "tdm")) {
> > + pr_err("tdm: Sysfs creation failed\n");
> > + kobject_put(tdm_kobj);
> > + err = -EINVAL;
> > + goto out;
> > + }
> > + } else {
> > + pr_err("tdm: Unable to allocate tdm_kobj\n");
> > + err = -ENOMEM;
> > + goto out;
> > + }
> > +
> > +out:
> > + return err;
> > +}
>
> You just leaked memory, what are you trying to do here?
>
> And why are you using "raw" kobjects? That's a sure sign that something
> is really wrong.
Will refer the documentation. Not very experienced on this stuff. Thanks for
the comment.
>
> Your code doesn't look like it is tied into the driver model at all, why
> not? What are you trying to do here?
This is a framework layer, not associated to a particular device. TDM adapter
drivers will register to this framework.
We got this comment in internal freescale review list also.
>
> Also, when creating new sysfs entries, like you are attempting to do here
> (unsuccessfully I might add), you must create Documentation/ABI/ files as
> well.
Ok.
>
> And, to top it all off, you do realize you are asking us to do code
> review in the middle of the merge window, when we are all busy doing
> other things?
Apologize for asking a review in the merge window time frame.
Are there any guidelines when to send something for a review? We will be
careful next time.
Regards
Poonam
>
> greg k-h
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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: [2/3][PATCH][v2] TDM Framework
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
KH
Sent: Friday, July 27, 2012 11:30 PM
To: Singh Sandeep-B37400
Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
+/* Data structures required for sysfs */ static struct tdm_sysfs attr
+= {
+ .attr.name = use_latest_data,
+ .attr.mode = 0664,
+ .cmd_type = TDM_LATEST_DATA,
+};
What is this for?
This knob is to control the behavior of the TDM framework with respect to
handling the received TDM frames.
The framework layer receives the TDM frames from the TDM adapter driver,
de-interleaves the data and sends to respective client modules.
In the case when the TDM client module has not consumed the data and emptied
the Buffer, this flag decides whether to discard the un-fetched data, or
discard the latest received data.
+int tdm_sysfs_init(void)
+{
+ struct kobject *tdm_kobj;
+ int err = 1;
+ tdm_kobj = kzalloc(sizeof(*tdm_kobj), GFP_KERNEL);
+ if (tdm_kobj) {
+ kobject_init(tdm_kobj, tdm_type);
+ if (kobject_add(tdm_kobj, NULL, %s, tdm)) {
+ pr_err(tdm: Sysfs creation failed\n);
+ kobject_put(tdm_kobj);
+ err = -EINVAL;
+ goto out;
+ }
+ } else {
+ pr_err(tdm: Unable to allocate tdm_kobj\n);
+ err = -ENOMEM;
+ goto out;
+ }
+
+out:
+ return err;
+}
You just leaked memory, what are you trying to do here?
And why are you using raw kobjects? That's a sure sign that something
is really wrong.
Will refer the documentation. Not very experienced on this stuff. Thanks for
the comment.
Your code doesn't look like it is tied into the driver model at all, why
not? What are you trying to do here?
This is a framework layer, not associated to a particular device. TDM adapter
drivers will register to this framework.
We got this comment in internal freescale review list also.
Also, when creating new sysfs entries, like you are attempting to do here
(unsuccessfully I might add), you must create Documentation/ABI/ files as
well.
Ok.
And, to top it all off, you do realize you are asking us to do code
review in the middle of the merge window, when we are all busy doing
other things?
Apologize for asking a review in the merge window time frame.
Are there any guidelines when to send something for a review? We will be
careful next time.
Regards
Poonam
greg k-h
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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: [2/3][PATCH][v2] TDM Framework
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
KH
Sent: Friday, July 27, 2012 11:42 PM
To: Singh Sandeep-B37400
Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
+static struct kobj_type tdm_type = {
+ .sysfs_ops = tdm_ops,
+ .default_attrs = tdm_attr,
+};
Ah, also, as per the documentation in the kernel (go look, it's there), I
now get to publicly mock you for ignoring the error messages that the
kernel is giving you when you try to shut down your code path.
Well, to be fair, you are leaking memory like a sieve, so I doubt you
ever saw those error messages because you never cleaned up after
yourself, so perhaps I can forgive you, but your users can't, sorry.
They like to rely on the fact that Linux is a reliable operating system,
don't cause them to doubt that.
Please fix this code, it's horribly broken. Read
Documentation/kobject.txt for why. That file was written for a reason,
and not just because we like writing documentation (hint, we hate to...)
To be honest we are not sysfs experts. Thanks for pointing to the documentation.
We will rework the stuff.
Regards
Poonam
Ugh,
greg k-h
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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 UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Anton/Tabi I am not sure which is the best place to configure the pins. Because some drivers do it in one way and some in the other. I actually tried to make the driver similar to ucc_geth because it is a QE driver. The driver has no platform code in the platform files similar to ucc_geth. It is probed along with all the QE devices thorugh of_platform_bus_probe. And the pins are configured for all the QE devices using par_io_init. I thought this to be the most consistent way at that time. How should we close this point? Can we go ahead with the pio-map? Infact the discussion in this thread was very good and I got to know a lot of rationales behind this. Please suggest. Thanks and Regards Poonam From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 10:53 PM To: Tabi Timur Cc: Aggrwal Poonam; Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Kalra Ashish Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries. On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Are you saying that TDM is sharing same pins with the other QE > >device, and we can choose to use/not use some device depending on > >which driver is loaded? > > No. I'd have to closely examine the DTS, but I don't think that UCC > devices share pins at all. But that isn't my point. > > >In that particular case UCC configuration is static, for every UCC. > >So, we can set up all pins in the firmware/board file. > > Yes, but deciding what the UCC does might not be static. At what > point do we declare, "UCC5 is for eth0 and eth0 only"? > > The advantage of putting the pin configurations in the device tree is > that they now become configurable. I can envision a scenario where > UCC5 could be either an Ethernet or a UART, depending on the setting > of some jumpers on the board. That's what the QE was designed for: any > UCC can do any task, and you can even have a UCC change its purpose while the system is running. > So I don't want the pin configurations hard-coded into the kernel. > Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. > For instance, I have a plan (that I keep postponing) to introduce a > new feature in U-Boot where U-Boot can determine the settings of some > board jumpers and modify the device tree accordingly. The instructions > on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... > I can't > support this feature if the kernel calls par_io_config_pin() > regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver
Hi Scott The device tree already has a brg-frequency property in qe node which is the value of BRGCLK. The function get_brg_clk uses this property to find the value of BRGCLK. In case this value is 0(some older u-boots populate bus-frequency property of qe and not the brg-frequency), get_brg_clk uses bus-frequency/2 as BRGCLK. With Regards Poonam -Original Message- From: Wood Scott Sent: Friday, January 25, 2008 1:42 AM To: Aggrwal Poonam Cc: Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Tabi Timur; Kalra Ashish Subject: Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver On Thu, Jan 24, 2008 at 10:24:13AM +0530, Poonam_Aggrwal-b10812 wrote: > + ix) Baud Rate Generator (BRG) > + > + Required properties: > + - compatible : shpuld be "fsl,cpm-brg" > + - fsl,brg-sources : define the input clock for all 16 BRGs. The input > +clock source could be 1 to 24 for CLK1 to CLK24. Zero means that the > +particular BRG will be driven by QE clock(BRGCLK). Should also have a clock-frequency property to specify what BRGCLK is. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver
Hi Scott The device tree already has a brg-frequency property in qe node which is the value of BRGCLK. The function get_brg_clk uses this property to find the value of BRGCLK. In case this value is 0(some older u-boots populate bus-frequency property of qe and not the brg-frequency), get_brg_clk uses bus-frequency/2 as BRGCLK. With Regards Poonam -Original Message- From: Wood Scott Sent: Friday, January 25, 2008 1:42 AM To: Aggrwal Poonam Cc: Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Tabi Timur; Kalra Ashish Subject: Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver On Thu, Jan 24, 2008 at 10:24:13AM +0530, Poonam_Aggrwal-b10812 wrote: + ix) Baud Rate Generator (BRG) + + Required properties: + - compatible : shpuld be fsl,cpm-brg + - fsl,brg-sources : define the input clock for all 16 BRGs. The input +clock source could be 1 to 24 for CLK1 to CLK24. Zero means that the +particular BRG will be driven by QE clock(BRGCLK). Should also have a clock-frequency property to specify what BRGCLK is. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Anton/Tabi I am not sure which is the best place to configure the pins. Because some drivers do it in one way and some in the other. I actually tried to make the driver similar to ucc_geth because it is a QE driver. The driver has no platform code in the platform files similar to ucc_geth. It is probed along with all the QE devices thorugh of_platform_bus_probe. And the pins are configured for all the QE devices using par_io_init. I thought this to be the most consistent way at that time. How should we close this point? Can we go ahead with the pio-map? Infact the discussion in this thread was very good and I got to know a lot of rationales behind this. Please suggest. Thanks and Regards Poonam From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 10:53 PM To: Tabi Timur Cc: Aggrwal Poonam; Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Kalra Ashish Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries. On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Anton Vorontsov wrote: Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? No. I'd have to closely examine the DTS, but I don't think that UCC devices share pins at all. But that isn't my point. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Yes, but deciding what the UCC does might not be static. At what point do we declare, UCC5 is for eth0 and eth0 only? The advantage of putting the pin configurations in the device tree is that they now become configurable. I can envision a scenario where UCC5 could be either an Ethernet or a UART, depending on the setting of some jumpers on the board. That's what the QE was designed for: any UCC can do any task, and you can even have a UCC change its purpose while the system is running. So I don't want the pin configurations hard-coded into the kernel. Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. For instance, I have a plan (that I keep postponing) to introduce a new feature in U-Boot where U-Boot can determine the settings of some board jumpers and modify the device tree accordingly. The instructions on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... I can't support this feature if the kernel calls par_io_config_pin() regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH UCC TDM 0/3] UCC based TDM driver for QE based MPC83xx platforms
Reworked patches after incorporating comments of Andrew, Stephen and
Tabi and Kumar.
Kumar could you please consider them for linux-2.6.25.
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
The driver is right now in misc category and exposes a kind of non
standard interface to the clients.
TDM Driver Interface Details
The TDM driver right now is a misc driver with no subsystem as such.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices.
At every new request of the TDM client to bind with a TDM device, a free
driver instance is allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients(kernel
mode clients) through some APIs.
This interface can be improved by writing a platform independent TDM
layer. Then all the TDM platforms can be supported below this wrapper
layer. This is planned to be done later.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak
git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24
origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH UCC TDM 0/3] UCC based TDM driver for QE based MPC83xx platforms
Reworked patches after incorporating comments of Andrew, Stephen and
Tabi and Kumar.
Kumar could you please consider them for linux-2.6.25.
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
The driver is right now in misc category and exposes a kind of non
standard interface to the clients.
TDM Driver Interface Details
The TDM driver right now is a misc driver with no subsystem as such.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices.
At every new request of the TDM client to bind with a TDM device, a free
driver instance is allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients(kernel
mode clients) through some APIs.
This interface can be improved by writing a platform independent TDM
layer. Then all the TDM platforms can be supported below this wrapper
layer. This is planned to be done later.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for clocks and brg
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added(clocks and brg)
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak
git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24
origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch qe: add function qe_clock_source.
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some other client as such. Please suggest on this.
But you are right as far as Freescale PowerPC platforms are concerned
which have TDM devices. Like, 8315 also has a TDM driver which also
exposes similar interface as 8323 because the client it is talking to is
the same.
Following is the small description of the TDM driver along with
interface details:
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of
the TDM client to bind with a TDM device, a free driver instance is
allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 driver_handle;
u32 (*tdm_read)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data form a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients
through some APIs.
I need your feedback on the interface details. Some changes were
suggested by Andrew for 32 bit tdm handle which I will modify.(Thanks
Andrew)
Please give your ideas about a TDM framework in the kernel and the
interface.
Waiting for your feedback.
Thanks and Regards
Poonam
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 9:01 AM
To: Andrew Morton
Cc: Phillips Kim; Aggrwal Poonam; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Barkowski Michael;
Kalra Ashish; Cutler Richard
Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:
> On Mon, 14 Jan 2008 12:00:51 -0600
> Kim Phillips <[EMAIL PROTECTED]> wrote:
>
>> On Thu, 10 Jan 2008 21:41:20 -0700
>> "Aggrwal Poonam" <[EMAIL PROTECTED]> wrote:
>>
>>> Hello All
>>>
>>> I am waiting for more feedback on the patches.
>>>
>>> If there are no objections please consider them for 2.6.25.
>>>
>> if this isn't going to go through Alessandro Rubini/misc drivers, can
>> it go through the akpm/mm tree?
>>
>
> That would work. But it might be more appropriate to go Kumar-
> >paulus->Linus.
I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about
the driver itself. I'm wondering if we need a TDM framework in the
kernel.
I guess if Poonam could possibly describe how this driver is actually
used that would be helpful. I see we have 8315 with a discrete TDM
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM
as well.
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some other client as such. Please suggest on this.
But you are right as far as Freescale PowerPC platforms are concerned
which have TDM devices. Like, 8315 also has a TDM driver which also
exposes similar interface as 8323 because the client it is talking to is
the same.
Following is the small description of the TDM driver along with
interface details:
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of
the TDM client to bind with a TDM device, a free driver instance is
allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 driver_handle;
u32 (*tdm_read)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data form a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients
through some APIs.
I need your feedback on the interface details. Some changes were
suggested by Andrew for 32 bit tdm handle which I will modify.(Thanks
Andrew)
Please give your ideas about a TDM framework in the kernel and the
interface.
Waiting for your feedback.
Thanks and Regards
Poonam
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 9:01 AM
To: Andrew Morton
Cc: Phillips Kim; Aggrwal Poonam; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Barkowski Michael;
Kalra Ashish; Cutler Richard
Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:
On Mon, 14 Jan 2008 12:00:51 -0600
Kim Phillips [EMAIL PROTECTED] wrote:
On Thu, 10 Jan 2008 21:41:20 -0700
Aggrwal Poonam [EMAIL PROTECTED] wrote:
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
if this isn't going to go through Alessandro Rubini/misc drivers, can
it go through the akpm/mm tree?
That would work. But it might be more appropriate to go Kumar-
paulus-Linus.
I'm ok w/taking the arch/powerpc bits, but Im a bit concerned about
the driver itself. I'm wondering if we need a TDM framework in the
kernel.
I guess if Poonam could possibly describe how this driver is actually
used that would be helpful. I see we have 8315 with a discrete TDM
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM
as well.
- k
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
Thanks Morton for your comments,
I shall incorporate them and reesnd the patch.
With Regards
Poonam
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 2:45 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Barkowski Michael; Phillips Kim; Kalra Ashish;
Cutler Richard
Subject: Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx
platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <[EMAIL PROTECTED]> wrote:
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> The UCC TDM driver basically multiplexes and demultiplexes data from
> different channels. It can interface with for example SLIC kind of
> devices to receive TDM data demultiplex it and send to upper
> applications. At the transmit end it receives data for different
> channels multiplexes it and sends them on the TDM channel. It
> internally uses TSA( Time Slot Assigner) which does multiplexing and
> demultiplexing, UCC to perform SDMA between host buffers and the TSA,
CMX to connect TSA to UCC.
>
> This driver will run on MPC8323E-RDB platforms.
>
> ...
>
> +#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1)) #define
> +NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info = {
> + .uf_info = {
> + .tsa = 1,
> + .cdp = 1,
> + .cds = 1,
> + .ctsp = 1,
> + .ctss = 1,
> + .revd = 1,
> + .urfs = 0x128,
> + .utfs = 0x128,
> + .utfet = 0,
> + .utftt = 0x128,
> + .ufpt = 256,
> + .ttx_trx =
UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc = UCC_FAST_TX_ENCODING_NRZ,
> + .renc = UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc = UCC_FAST_16_BIT_CRC,
> + .synl = UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy = 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c) { #if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts = tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log) {
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp = log ^ 0xFF;
> + sign = (temp & 0x80) >> 7;
> + segment = (temp & 0x70) >> 4;
> + quant = temp & 0x0F;
> + quant <<= 1;
> + quant += 33;
> + quant <<= segment;
> + if (sign)
> + val = 33 - quant;
> + else
> + val = quant - 33;
> +
> + val *= 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear) {
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret = 0;
> + if (linear >= 0)
> + linear = (linear >> 2);
> + else
> + linear = (0xc000 | (linear >> 2));
> +
> + absol = abs(linear) + 33;
> + temp = absol;
> + sign = (linear >= 0) ? 1 : 0;
> + for (i = 0; i < 16; i++) {
> + output = temp
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Thanks Kumar/Morton/Kim I shall make a small paragraph which describes the TDM driver architecture and the interfaces it exposes. As far as 8315 TDM is concerned it is a non QE driver and quite different from this except for the functionality and external interface it exposes. Right now TDM is not a full-fledged bus driver which probably can be done may be very similar to SPI. Please give your suggestions on this. With Regards Poonam -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 15, 2008 9:01 AM To: Andrew Morton Cc: Phillips Kim; Aggrwal Poonam; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Barkowski Michael; Kalra Ashish; Cutler Richard Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote: > On Mon, 14 Jan 2008 12:00:51 -0600 > Kim Phillips <[EMAIL PROTECTED]> wrote: > >> On Thu, 10 Jan 2008 21:41:20 -0700 >> "Aggrwal Poonam" <[EMAIL PROTECTED]> wrote: >> >>> Hello All >>> >>> I am waiting for more feedback on the patches. >>> >>> If there are no objections please consider them for 2.6.25. >>> >> if this isn't going to go through Alessandro Rubini/misc drivers, can >> it go through the akpm/mm tree? >> > > That would work. But it might be more appropriate to go Kumar- > >paulus->Linus. I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about the driver itself. I'm wondering if we need a TDM framework in the kernel. I guess if Poonam could possibly describe how this driver is actually used that would be helpful. I see we have 8315 with a discrete TDM block and I'm guessing 82xx/85xx based CPM parts of some form of TDM as well. - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Thanks Kumar/Morton/Kim I shall make a small paragraph which describes the TDM driver architecture and the interfaces it exposes. As far as 8315 TDM is concerned it is a non QE driver and quite different from this except for the functionality and external interface it exposes. Right now TDM is not a full-fledged bus driver which probably can be done may be very similar to SPI. Please give your suggestions on this. With Regards Poonam -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 15, 2008 9:01 AM To: Andrew Morton Cc: Phillips Kim; Aggrwal Poonam; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Barkowski Michael; Kalra Ashish; Cutler Richard Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote: On Mon, 14 Jan 2008 12:00:51 -0600 Kim Phillips [EMAIL PROTECTED] wrote: On Thu, 10 Jan 2008 21:41:20 -0700 Aggrwal Poonam [EMAIL PROTECTED] wrote: Hello All I am waiting for more feedback on the patches. If there are no objections please consider them for 2.6.25. if this isn't going to go through Alessandro Rubini/misc drivers, can it go through the akpm/mm tree? That would work. But it might be more appropriate to go Kumar- paulus-Linus. I'm ok w/taking the arch/powerpc bits, but Im a bit concerned about the driver itself. I'm wondering if we need a TDM framework in the kernel. I guess if Poonam could possibly describe how this driver is actually used that would be helpful. I see we have 8315 with a discrete TDM block and I'm guessing 82xx/85xx based CPM parts of some form of TDM as well. - k -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
Thanks Morton for your comments,
I shall incorporate them and reesnd the patch.
With Regards
Poonam
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 2:45 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Barkowski Michael; Phillips Kim; Kalra Ashish;
Cutler Richard
Subject: Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx
platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 [EMAIL PROTECTED] wrote:
From: Poonam Aggrwal [EMAIL PROTECTED]
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of
devices to receive TDM data demultiplex it and send to upper
applications. At the transmit end it receives data for different
channels multiplexes it and sends them on the TDM channel. It
internally uses TSA( Time Slot Assigner) which does multiplexing and
demultiplexing, UCC to perform SDMA between host buffers and the TSA,
CMX to connect TSA to UCC.
This driver will run on MPC8323E-RDB platforms.
...
+#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1)) #define
+NEXT_PHASE(x) (((x + 1) MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
+static struct ucc_tdm_info utdm_primary_info = {
+ .uf_info = {
+ .tsa = 1,
+ .cdp = 1,
+ .cds = 1,
+ .ctsp = 1,
+ .ctss = 1,
+ .revd = 1,
+ .urfs = 0x128,
+ .utfs = 0x128,
+ .utfet = 0,
+ .utftt = 0x128,
+ .ufpt = 256,
+ .ttx_trx =
UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
+ .tenc = UCC_FAST_TX_ENCODING_NRZ,
+ .renc = UCC_FAST_RX_ENCODING_NRZ,
+ .tcrc = UCC_FAST_16_BIT_CRC,
+ .synl = UCC_FAST_SYNC_LEN_NOT_USED,
+ },
+ .ucc_busy = 0,
+};
+
+static struct ucc_tdm_info utdm_info[8];
+
+static void dump_siram(struct tdm_ctrl *tdm_c) { #if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
+ int i;
+ u16 phy_num_ts;
+
+ phy_num_ts = tdm_c-physical_num_ts;
+
+ pr_debug(SI TxRAM dump\n);
+ /* each slot entry in SI RAM is of 2 bytes */
+ for (i = 0; i phy_num_ts * 2; i++)
+ pr_debug(%x , in_8(qe_immr-sir.tx[i]));
+ pr_debug(\nSI RxRAM dump\n);
+ for (i = 0; i phy_num_ts * 2; i++)
+ pr_debug(%x , in_8(qe_immr-sir.rx[i]));
+ pr_debug(\n);
+#endif
+}
+
+/*
+ * converts u-law compressed samples to linear PCM
+ * If the CONFIG_TDM_LINEAR_PCM flag is not set the
+ * TDM driver receives u-law compressed data from the
+ * SLIC device. This function converts the compressed
+ * data to linear PCM and sends it to upper layers.
+ */
+static inline int ulaw2int(unsigned char log) {
+ u32 sign, segment, temp, quant;
+ int val;
+
+ temp = log ^ 0xFF;
+ sign = (temp 0x80) 7;
+ segment = (temp 0x70) 4;
+ quant = temp 0x0F;
+ quant = 1;
+ quant += 33;
+ quant = segment;
+ if (sign)
+ val = 33 - quant;
+ else
+ val = quant - 33;
+
+ val *= 4;
+ return val;
+}
+
+/*
+ * converts linear PCM samples to u-law compressed format.
+ * If the CONFIG_TDM_LINEAR_PCM flag is not set the
+ * TDM driver calls this function to convert the PCM samples
+ * to u-law compressed format before sending them to SLIC
+ * device.
+ */
+static inline u8 int2ulaw(short linear) {
+ u8 quant, ret;
+ u16 output, absol, temp;
+ u32 i, sign;
+ char segment;
+
+ ret = 0;
+ if (linear = 0)
+ linear = (linear 2);
+ else
+ linear = (0xc000 | (linear 2));
+
+ absol = abs(linear) + 33;
+ temp = absol;
+ sign = (linear = 0) ? 1 : 0;
+ for (i = 0; i 16; i++) {
+ output = temp 0x8000;
+ if (output)
+ break;
+ temp = 1;
+ }
+ segment = 11 - i;
+ quant = (absol segment) 0x0F;
+ segment--;
+ segment = 4;
+ output = segment + quant;
+ if (absol 8191)
+ output = 0x7F;
+ if (sign)
+ ret ^= 0xFF;
+ else
+ ret ^= 0x7F;
+ return ret;
+}
hrm, how many copies of ulaw/alaw conversion functions do we need in the
tree before someone writes a library function for it?
+ out_be16(rx_bd-status, bd_status);
+ out_be32(rx_bd-buf,
+ tdm_c
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar
Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard
Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar
Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard
Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All I am waiting for more feedback on the patches. If there are no objections please consider them for 2.6.25. With Regards Poonam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aggrwal Poonam Sent: Monday, December 10, 2007 5:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms There are three patches [PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This driver is usable in VoIP iind of applications to interface with SLIC kind of devices to exchange TDM voice samples. [PATCH 2/3] arch/ : Platform changes - device tree entries for UCC TDM driver for MPC8323ERDB platform. - QE changes related to TDM , like, 1) Modified ucc_fast_init so that it can be used by fast UCC based TDM driver. Mainly changes have been made to configure TDM clocks and Fsyncs. 2) Modified get_brg_clk so that it can return the input frequncy and input source of any BRG by reading the corresponding entries from device tree. 3) Added new nodes brg and clocks in the device tree which represent input clocks for different BRGs. 4) Modified qe_setbrg accordingly. - new device tree entries added for clocks and brg [PATCH 3/3] Documentation - Modified Documentation to explain the device tree entries related to UCC TDM driver and the new nodes added(clocks and brg) The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24 plus of_doc_update branches. In brief the steps were git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update git pull . for-2.6.24# merge the other two git pull . for-2.6.25 git checkout -b tdm # clean slate for tdm rebase work Also after applying the patches changes have to be made corresponding to Tabi's patch qe: add function qe_clock_source. The driver has been tested with a VoIP stack and application on MPC8323ERDB. With Regards Poonam -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All I am waiting for more feedback on the patches. If there are no objections please consider them for 2.6.25. With Regards Poonam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aggrwal Poonam Sent: Monday, December 10, 2007 5:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms There are three patches [PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This driver is usable in VoIP iind of applications to interface with SLIC kind of devices to exchange TDM voice samples. [PATCH 2/3] arch/ : Platform changes - device tree entries for UCC TDM driver for MPC8323ERDB platform. - QE changes related to TDM , like, 1) Modified ucc_fast_init so that it can be used by fast UCC based TDM driver. Mainly changes have been made to configure TDM clocks and Fsyncs. 2) Modified get_brg_clk so that it can return the input frequncy and input source of any BRG by reading the corresponding entries from device tree. 3) Added new nodes brg and clocks in the device tree which represent input clocks for different BRGs. 4) Modified qe_setbrg accordingly. - new device tree entries added for clocks and brg [PATCH 3/3] Documentation - Modified Documentation to explain the device tree entries related to UCC TDM driver and the new nodes added(clocks and brg) The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24 plus of_doc_update branches. In brief the steps were git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update git pull . for-2.6.24# merge the other two git pull . for-2.6.25 git checkout -b tdm # clean slate for tdm rebase work Also after applying the patches changes have to be made corresponding to Tabi's patch qe: add function qe_clock_source. The driver has been tested with a VoIP stack and application on MPC8323ERDB. With Regards Poonam -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.
Sorry for late reply as I was on leave for the last week.
With Regards
Poonam
-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; Gala Kumar; [EMAIL PROTECTED]; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk = 0;
>
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + const unsigned int *prop;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency",
);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + prop = of_get_property(brg,
> + "fsl,brg-sources", );
> +
> + brg_src = *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency",
);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> + prop = of_get_property(clocks,
> + "#clock-cells", );
> + /*
> + * clock-cells = 1 only supported right now.
> + */
> + if (*prop != 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop = of_get_property(clocks,
> + "clock-frequency",
);
> +
> + brg_input_freq = *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.
Sorry for late reply as I was on leave for the last week.
With Regards
Poonam
-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; Gala Kumar; [EMAIL PROTECTED]; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
[EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
*/
static unsigned int brg_clk = 0;
-unsigned int get_brg_clk(void)
+u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
{
- struct device_node *qe;
- if (brg_clk)
- return brg_clk;
+ struct device_node *qe, *brg, *clocks;
+ enum qe_clock brg_src;
+ u32 brg_input_freq = 0;
+ u32 brg_num;
+ const unsigned int *prop;
- qe = of_find_node_by_type(NULL, qe);
- if (qe) {
+ *brg_source = 0;
+
+ brg_num = brgclk - QE_BRG1;
+ brg = of_find_compatible_node(NULL, NULL, fsl,cpm-brg);
+ if (brg) {
unsigned int size;
- const u32 *prop = of_get_property(qe, brg-frequency,
size);
- brg_clk = *prop;
- of_node_put(qe);
- };
+ prop = of_get_property(brg,
+ fsl,brg-sources, size);
+
+ brg_src = *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the of_node_put(brg) could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
+ if (brg_src == 0) {
+ *brg_source = 0;
+ if (brg_clk 0) {
+ of_node_put(brg);
+ return brg_clk;
+ }
+ qe = of_find_node_by_type(NULL, qe);
+ if (qe) {
+ unsigned int size;
+ prop = of_get_property
+ (qe, brg-frequency,
size);
+ of_node_put(qe);
+ of_node_put(brg);
+ return *prop;
NULL check here (yes, I know that the old code didn't check).
+ }
+ } else {
+ *brg_source = brg_src + QE_CLK1 - 1;
+ clocks = of_find_compatible_node(NULL, NULL,
+
fsl,cpm-clocks);
+ prop = of_get_property(clocks,
+ #clock-cells, size);
+ /*
+ * clock-cells = 1 only supported right now.
+ */
+ if (*prop != 1)
Again check for NULL (and possibly size).
+ return 0;
+ prop = of_get_property(clocks,
+ clock-frequency,
size);
+
+ brg_input_freq = *(prop+(brg_src - 1));
And again.
+ of_node_put(clocks);
+ of_node_put(brg);
+ return brg_input_freq;
+ }
+ }
return brg_clk;
}
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak
git checkout -b for-2.6.25 origin/for-2.6.25
git checkout -b for-2.6.24 origin/for-2.6.24
git checkout -b of_doc_update origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches [PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This driver is usable in VoIP iind of applications to interface with SLIC kind of devices to exchange TDM voice samples. [PATCH 2/3] arch/ : Platform changes - device tree entries for UCC TDM driver for MPC8323ERDB platform. - QE changes related to TDM , like, 1) Modified ucc_fast_init so that it can be used by fast UCC based TDM driver. Mainly changes have been made to configure TDM clocks and Fsyncs. 2) Modified get_brg_clk so that it can return the input frequncy and input source of any BRG by reading the corresponding entries from device tree. 3) Added new nodes brg and clocks in the device tree which represent input clocks for different BRGs. 4) Modified qe_setbrg accordingly. - new device tree entries added for clocks and brg [PATCH 3/3] Documentation - Modified Documentation to explain the device tree entries related to UCC TDM driver and the new nodes added(clocks and brg) The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24 plus of_doc_update branches. In brief the steps were git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update git pull . for-2.6.24# merge the other two git pull . for-2.6.25 git checkout -b tdm # clean slate for tdm rebase work Also after applying the patches changes have to be made corresponding to Tabi's patch qe: add function qe_clock_source. The driver has been tested with a VoIP stack and application on MPC8323ERDB. With Regards Poonam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches [PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This driver is usable in VoIP iind of applications to interface with SLIC kind of devices to exchange TDM voice samples. [PATCH 2/3] arch/ : Platform changes - device tree entries for UCC TDM driver for MPC8323ERDB platform. - QE changes related to TDM , like, 1) Modified ucc_fast_init so that it can be used by fast UCC based TDM driver. Mainly changes have been made to configure TDM clocks and Fsyncs. 2) Modified get_brg_clk so that it can return the input frequncy and input source of any BRG by reading the corresponding entries from device tree. 3) Added new nodes brg and clocks in the device tree which represent input clocks for different BRGs. 4) Modified qe_setbrg accordingly. - new device tree entries added for clocks and brg [PATCH 3/3] Documentation - Modified Documentation to explain the device tree entries related to UCC TDM driver and the new nodes added(clocks and brg) The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24 plus of_doc_update branches. In brief the steps were git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update git pull . for-2.6.24# merge the other two git pull . for-2.6.25 git checkout -b tdm # clean slate for tdm rebase work Also after applying the patches changes have to be made corresponding to Tabi's patch qe: add function qe_clock_source. The driver has been tested with a VoIP stack and application on MPC8323ERDB. With Regards Poonam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
