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-dev@lists.ozlabs.org; linux-ker...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Leekha Shaveta-B20052 Sent: Monday, April 08, 2013 10:18 AM To: Kumar Gala Cc: linuxppc-dev@lists.ozlabs.org list Subject: RE: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420 -Original Message- From: Leekha Shaveta-B20052 Sent: Friday, April 05, 2013 9:13 PM To: 'Kumar Gala' Cc: linuxppc-dev@lists.ozlabs.org list Subject: RE: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420 -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, April 05, 2013 7:53 PM To: Leekha Shaveta-B20052 Cc: linuxppc-dev@lists.ozlabs.org list Subject: Re: [PATCH 1/4][v2] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420 On Apr 5, 2013, at 1:33 AM, Shaveta Leekha wrote: B4860 and B4420 are similar that share some commonalities * common features have been added in b4si-pre.dtsi and b4si-post.dtsi * differences are added in respective silicon files of B4860 and B4420 There are several things missing from the device trees of B4860 and B4420: * DPAA related nodes (Qman, Bman, Fman, Rman) * DSP related nodes/information * serdes, sfp(security fuse processor), thermal, gpio, maple, cpri, quad timers nodes Signed-off-by: Shaveta Leekha shav...@freescale.com Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Tang Yuantian yuantian.t...@freescale.com Signed-off-by: Varun Sethi varun.se...@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Andy Fleming aflem...@freescale.com Signed-off-by: Vakul Garg va...@freescale.com --- v2: - incorporated review comments on commits message - change unit address of cpu nodes to match the reg property arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 94 ++ arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 49 + arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 138 ++ arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 59 ++ arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 262 +++ arch/powerpc/boot/dts/fsl/b4si-pre.dtsi | 65 +++ 6 files changed, 667 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/b4si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/b4si-pre.dtsi Is there a reason you didn't get rid of b4si-pre.dtsi and just merge it into b4860si-pre.dtsi b4420-pre.dtsi? [SL] No particular reason. I have just tried to re-factored these files as you have suggested. Hence managed the commonalities in B4 files and differences in B4860's and B4420's respective files to reduce duplicity. Regards, Shaveta [SL] Kumar, please suggest. Please suggest , if this re-factoring for pre-si dtsi should not be required. This was done to keep things uniform. Accordingly we will send a re-spin if required. Regards Poonam Regards, Shaveta ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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-dev@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-ker...@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-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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-dev@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-ker...@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-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/3][PATCH][upstream]Adding documentation for TDM
-Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Wednesday, July 25, 2012 2:14 PM To: Aggrwal Poonam-B10812; Singh Sandeep-B37400; linuxppc- d...@lists.ozlabs.org Cc: Singh Sandeep-B37400 Subject: RE: [1/3][PATCH][upstream]Adding documentation for TDM For flexibility you need to allow for 8bit samples being converted as: 1) 8bit raw ulaw or alaw data (unchanged from line). 2) 8bit raw data, bit reversed, any hdlc protocol is bit reversed from audio [1]. 3) 8bit audio, converted from alaw to ulaw 4) 8bit audio, converted from ulaw to alaw 5) 16bit linear converted to/from alaw or ulaw and on a per-timeslot basis. I agree. That we only support very limited samples. But We can add this in second step once the basic framework is in. Also right now the testing infrastructure we have, we won't be able to test all these scenarios. You probably ought to make the application request a specific format - and error the unsupported ones. That would make it easier to add support for other formats later. David there is still configuration interface which needs to be added to the Framework. This is mentioned in the documentation and patch also. But we really need the core stuff which is handling the data get in and things will be added subsequently. I also suspect that this 'framework' isn't that general! All the feedback welcome! We (as a company) use the TDM interface blocks on the MSC8101 and MSC8013 Starecore DSPs as well as some bespoke FPGA logic (which will do ulaw- alaw convertion). The 'framework' would almost certainly be inappropriate for both out hardware and software. Thanks a lot for the feedback. Can you please help to understand what is the scenario and how you use TDM. This will be a big help. More generic the better. Regards Poonam David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/3][PATCH][upstream]Adding documentation for TDM
Thanks David for the comments. Response Inline. Regards Poonam -Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Monday, July 23, 2012 6:02 PM To: Singh Sandeep-B37400; linuxppc-dev@lists.ozlabs.org Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812 Subject: RE: [1/3][PATCH][upstream]Adding documentation for TDM +3. TDM has programmable slot length (8 bits or 16 bits). This can be + configured by: + + #define NUM_BYTES_PER_SLOT 8 I presume you meant NUM_BITS_PER_SLOT ? These constants need name-space protection +or + #define NUM_BYTES_PER_SLOT 16 + This is a mistake, documentation patch not updated with the update design. +depending on the type of sample. For example the sample could be 16 +bit linear +or 8bit u-law encoded etc. +Presently only word length of 16 is supported which is the default +configuration. For flexibility you need to allow for 8bit samples being converted as: 1) 8bit raw ulaw or alaw data (unchanged from line). 2) 8bit raw data, bit reversed, any hdlc protocol is bit reversed from audio [1]. 3) 8bit audio, converted from alaw to ulaw 4) 8bit audio, converted from ulaw to alaw 5) 16bit linear converted to/from alaw or ulaw and on a per-timeslot basis. I agree. That we only support very limited samples. But We can add this in second step once the basic framework is in. Also right now the testing infrastructure we have, we won't be able to test all these scenarios. [1] most hdlc stuff probably can't stand the 10ms epochs though, so this is limited use for serious work. Right now the framework has been customized for voice. We can keep this parameter as a sysfs knob. Please suggest. Regards Poonam David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][upstream] TDM Framework
Sorry the documentation patch got missed in this patchset. Will send it again. Regards Poonam -Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Friday, July 20, 2012 8:20 PM To: Singh Sandeep-B37400 Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400; Aggrwal Poonam- B10812 Subject: Re: [PATCH][upstream] TDM Framework Hi, On Fri, 20 Jul 2012 18:05:13 +0530 sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. I also wondered what TDM is. +++ b/drivers/tdm/Kconfig @@ -0,0 +1,18 @@ +# +# TDM subsystem configuration +# + +menuconfig TDM + tristate TDM support + ---help--- + More information is contained in the directory +file:Documentation/tdm/, ^^ + especially in the file called summary there. ^^^ It might help if those files were included in the patch set ... -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][upstream] TDM Framework
-Original Message- From: Josh Boyer [mailto:jwbo...@gmail.com] Sent: Friday, July 20, 2012 6:57 PM To: Michael Ellerman Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH][upstream] TDM Framework On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Beneath, the framework layer can house different types of TDM drivers to handle various TDM devices, the hardware intricacies of the devices being completely taken care by TDM drivers. TDM ? And here I was thinking I was the only one scratching his head. All I could come up with was Time Division Multiplexing. Sorry for that. TDM refers to Time Division Multiplexing. Actually the first version of this patch set also had a patch which documented TDM basics. We missed it this time. Will just send the TDM documentation patch also. Regards Poonam For your reference: Protip: If you use an acronym a billion times in a patch, expand it at least in one place. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][upstream] TDM Framework
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Aggrwal Poonam-B10812 Sent: Saturday, July 21, 2012 1:07 PM To: Josh Boyer; Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400 Subject: RE: [PATCH][upstream] TDM Framework -Original Message- From: Josh Boyer [mailto:jwbo...@gmail.com] Sent: Friday, July 20, 2012 6:57 PM To: Michael Ellerman Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH][upstream] TDM Framework On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Beneath, the framework layer can house different types of TDM drivers to handle various TDM devices, the hardware intricacies of the devices being completely taken care by TDM drivers. TDM ? And here I was thinking I was the only one scratching his head. All I could come up with was Time Division Multiplexing. Sorry for that. TDM refers to Time Division Multiplexing. Actually the first version of this patch set also had a patch which documented TDM basics. We missed it this time. Will just send the TDM documentation patch also. The documentation patch is at: http://patchwork.ozlabs.org/patch/145857/ Regards Poonam For your reference: Protip: If you use an acronym a billion times in a patch, expand it at least in one place. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][2/3][RFC] TDM Framework
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, April 24, 2012 6:05 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400
Subject: Re: [PATCH][2/3][RFC] TDM Framework
Thanks Scott for the comments, we will incorporate them and send the next
version.
Regards
Poonam
On 03/10/2012 06:57 AM, Poonam Aggrwal wrote:
diff --git a/drivers/Kconfig b/drivers/Kconfig index ad6c1eb..25f7f5b
100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -130,4 +130,5 @@ source drivers/virt/Kconfig
source drivers/net/dpa/NetCommSw/Kconfig
+source drivers/tdm/Kconfig
endmenu
When posting patches to this list, please ensure that they are based on
an upstream Linux kernel and not a Freescale BSP kernel.
Sure, but this was RFC patch set where the primary intention was to get design
level comments.
But we will send the updated patches rebased on upstream head.
+if TDM
+
+config TDM_DEBUG_CORE
+ bool TDM Core debugging messages
+ help
+ Say Y here if you want the TDM core to produce a bunch of debug
+ messages to the system log. Select this if you are having a
+ problem with TDM support and want to see more of what is going
on.
+
+endif # TDM
Please use the normal kernel mechanisms for controlling debug messages.
okay
diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file
mode 100644 index 000..cdda260
--- /dev/null
+++ b/drivers/tdm/tdm-core.c
@@ -0,0 +1,1146 @@
+/* driver/tdm/tdm-core.c
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights
reserved.
+ *
+ * TDM core is the interface between TDM clients and TDM devices.
+ * It is also intended to serve as an interface for line controld
+ * devices later on.
+ *
+ * Author:Hemant Agrawal hem...@freescale.com
+ * Rajesh Gumasta rajesh.guma...@freescale.com
+ *
+ * Modified by Sandeep Kr Singh sand...@freescale.com
+ * Poonam Aggarwal poonam.aggar...@freescale.com
+ * 1. Added framework based initialization of device.
+ * 2. All the init/run time configuration is now done by framework.
+ * 3. Added channel level operations.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as published
+by the
+ * Free Software Foundation; either version 2 of the License, or
+(at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+along
+ * with this program; if not, write to the Free Software Foundation,
+Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* if read write debug required */
+#undef TDM_CORE_DEBUG
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/slab.h
+#include linux/tdm.h
+#include linux/init.h
+#include linux/idr.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/hardirq.h
+#include linux/irqflags.h
+#include linux/list.h
+#include linux/uaccess.h
+#include linux/io.h
+#include device/tdm_fsl.h
What is a reference to tdm_fsl.h doing in the presumably hardware-
independent tdm-core.c?
Need to check that, ideally this include should not be required
+static DEFINE_MUTEX(tdm_core_lock);
+static DEFINE_IDR(tdm_adapter_idr);
+/* List of TDM adapters registered with TDM framework */
+LIST_HEAD(adapter_list);
+
+/* List of TDM clients registered with TDM framework */
+LIST_HEAD(driver_list);
+
+/* In case the previous data is not fetched by the client driver, the
+ * de-interleaving function will discard the old data and rewrite
+the
+ * new data */
+static int use_latest_tdm_data = 1;
Describe when one would want to change this, and provide a better way to
change it (e.g. module parameter or sysfs knob).
Ok, description can be added.
Will also explore the sysfs knob option.
/*
* Linux kernel
* multi-line comment style
* is like this.
*/
Sure
+/* this tasklet is created for each adapter instance */ static void
+tdm_data_tasklet_fn(unsigned long);
+
+/* tries to match client driver with the adapter */ static int
+tdm_device_match(struct tdm_driver *driver, struct tdm_adapter *adap)
+{
+ /* match on an id table if there is one */
+ if (driver-id_table driver-id_table-name[0]) {
+ if (!(strcmp(driver-id_table-name, adap-name)))
+ return (int)driver
RE: [PATCH][2/3][RFC] TDM Framework
-Original Message- From: Aggrwal Poonam-B10812 Sent: Saturday, March 10, 2012 6:27 PM To: linuxppc-dev@lists.ozlabs.org Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812 Subject: [PATCH][2/3][RFC] TDM Framework Any feedback on this patchset? From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Beneath, the framework layer can house different types of TDM drivers to handle various TDM devices, the hardware intricacies of the devices being completely taken care by TDM drivers. This framework layer will allow any type of TDM device to hook with it. For example Freescale controller as on MPC8315, UCC based TDM controller, or any other controller. The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer management. In future this Framework will be extended to provide Interface for Line control devices also. For example SLIC, E1/T1 Framers etc. Limitations/Future Work --- 1. Presently the framework supports only Single Port channelised mode. 2. Also the configurability options are limited which will be extended later on. 3. Only kernel mode TDM clients are supported currently. Support for User mode clients will be added later. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- A couple of todos' are left in the patch, we are working on it and will be addressed in the updated patch set. drivers/Kconfig |1 + drivers/Makefile|1 + drivers/tdm/Kconfig | 25 + drivers/tdm/tdm-core.c | 1146 +++ include/linux/mod_devicetable.h | 11 + include/linux/tdm.h | 347 6 files changed, 1531 insertions(+), 0 deletions(-) create mode 100644 drivers/tdm/Kconfig create mode 100644 drivers/tdm/tdm-core.c create mode 100644 include/linux/tdm.h diff --git a/drivers/Kconfig b/drivers/Kconfig index ad6c1eb..25f7f5b 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -130,4 +130,5 @@ source drivers/virt/Kconfig source drivers/net/dpa/NetCommSw/Kconfig +source drivers/tdm/Kconfig endmenu diff --git a/drivers/Makefile b/drivers/Makefile index cd546eb..362b5ed 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-$(CONFIG_SGI_SN) += sn/ obj-y+= firmware/ obj-$(CONFIG_CRYPTO) += crypto/ +obj-$(CONFIG_TDM)+= tdm/ obj-$(CONFIG_SUPERH) += sh/ obj-$(CONFIG_ARCH_SHMOBILE) += sh/ ifndef CONFIG_ARCH_USES_GETTIMEOFFSET diff --git a/drivers/tdm/Kconfig b/drivers/tdm/Kconfig new file mode 100644 index 000..8db2b05 --- /dev/null +++ b/drivers/tdm/Kconfig @@ -0,0 +1,25 @@ +# +# TDM subsystem configuration +# + +menuconfig TDM + tristate TDM support + ---help--- + More information is contained in the directory file:Documentation/tdm/, + especially in the file called summary there. + If you want TDM support, you should say Y here and also to the + specific driver for your bus adapter(s) below. + + This TDM support can also be built as a module. If so, the module + will be called tdm-core. + +if TDM + +config TDM_DEBUG_CORE + bool TDM Core debugging messages + help + Say Y here if you want the TDM core to produce a bunch of debug + messages to the system log. Select this if you are having a + problem with TDM support and want to see more of what is going on. + +endif # TDM diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file mode 100644 index 000..cdda260 --- /dev/null +++ b/drivers/tdm/tdm-core.c @@ -0,0 +1,1146 @@ +/* driver/tdm/tdm-core.c + * + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved. + * + * TDM core is the interface between TDM clients and TDM devices. + * It is also intended to serve as an interface for line controld + * devices later on. + * + * Author:Hemant Agrawal hem...@freescale.com + * Rajesh Gumasta rajesh.guma...@freescale.com + * + * Modified by Sandeep Kr Singh sand...@freescale.com + * Poonam Aggarwal poonam.aggar...@freescale.com + * 1. Added framework based initialization of device. + * 2. All the init/run time configuration is now done by framework. + * 3. Added channel level operations. + * + * This program is free software; you can redistribute it and/or +modify it + * under the terms of the GNU General Public License as published by +the + * Free Software Foundation; either
RE: [PATCH] Device Tree Bindings for Freescale TDM controller
Thanks Scott for the review.
Will send an updated revision with the comments taken care.
Regards
Poonam
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 17, 2012 12:00 AM
To: Aggrwal Poonam-B10812
Cc: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org;
Singh Sandeep-B37400
Subject: Re: [PATCH] Device Tree Bindings for Freescale TDM controller
On 03/15/2012 08:30 PM, Poonam Aggrwal wrote:
From: Poonam Aggrwal poonam.aggr...@freescale.com
This TDM controller is available in various Freescale SOCs like
MPC8315, P1020, P1022, P1010.
Signed-off-by: Sandeep Singh sand...@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 71
+
1 files changed, 71 insertions(+), 0 deletions(-) create mode 100644
Documentation/devicetree/bindings/tdm/fsl-tdm.txt
diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
new file mode 100644
index 000..61431e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
@@ -0,0 +1,71 @@
+=
+TDM Device Tree Binding
+Copyright (C) 2012 Freescale Semiconductor Inc.
+
+NOTE: The bindings described in this document are preliminary and
+subject to change.
+
+=
+TDM (Time Division Multiplexing)
+
+DESCRIPTION
+
+The TDM is full duplex serial port designed to allow various devices
+including digital signal processors (DSPs) to communicate with a
+variety of serial devices including industry standard framers, codecs,
other DSPs and microprocessors.
+
+The below properties describe the device tree bindings for Freescale
+TDM controller.
+This TDM controller is available on various Freescale Processors like
+MPC8313, P1020, P1022 and P1010.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: Should contain fsl,mpc8315-tdm.
+ So mpc8313 will have compatible = fsl,mpc8315-tdm;
+ p1010 will have compatible fsl,p1010-tdm, fsl,mpc8315-tdm;
Shouldn't mpc8313 have:
compatible = fsl,mpc8313-tdm, fsl,mpc8315-tdm?
I thought we were going to use 8313 as the canonical implementation, not
8315.
MPC8315 was the first FSL platform to have this controller.
MPC8313 does not have TDM.
+ - reg
+ Usage: required
+ Value type: tdm-reg-offset tdm-reg-size dmac-reg-offset dmac-
reg-size
+ Definition: A standard property. Specifies the physical address
+ offset and length of the TDM registers and TDM DMAC registers for
+ the device.
Just say there's two reg resources, and that the first is the TDM
registers and the second is the TDM DMAC registers.
It's typically not going to be the actual physical address, but rather an
offset that gets translated through a parent node's ranges.
Okay, I think we missed this comment, you already gave this earlier.
Sorry for that.
Remove value type; it's standard.
Okay. So just definition must suffice, right?
+ - clock-frequency
+ Usage: optional
+ Value type: u32
+ Definition: The frequency at which the TDM block is operating.
Will this frequency ever need to be 4GHz?
Don't think so, at max this will be CCB, not sure if CCB on our platforms may
get bigger than 4G ever.
Might want to specify as u32 or u64, as ePAPR suggests.
Means Value type: u32 or u64?
In this case the driver must always use 64bit data structure to read this. Is
this correct?
+ - interrupts
+ Usage: required
+ Value type: tdm-err-intr tdm-err-intr-type dmac-intr dmac-intr-
type
+ Definition: This field defines two interrupt specifiers namely
interrupt
+ number and interrupt type for TDM error and TDM DMAC.
What is tdm-err-intr-type? The interrupt specifier encoding is defined
by the interrupt controller. There might be one cell, two cells, four
cells, etc. Remove value type, it's standard.
okay
+ - phy-handle
+ Usage: optional
+ Value type: phandle
+ Definition: Phandle of the line controller node or framer node
eg. SLIC,
+ E1\T1 etc.
Use a forward slash -- this isn't a Windows filesystem path. :-)
Okay, agreed.
+ - fsl-max-time-slots
+ Usage: required
+ Value type: u32
+ Definition: Maximum number of 8-bit time slots in one TDM frame.
+ This is the maximum number which TDM hardware supports.
fsl,tdm-max-time-slots
Sure. This again got missed.
+
+EXAMPLE
+
+ tdm@16000 {
+ device_type = tdm;
No device_type
Okay.
+ compatible = fsl,p1010-tdm, fsl,mpc8315-tdm;
+ reg = 0x16000 0x200 0x2c000 0x2000;
+ clock-frequency = 0;
Show a real clock
RE: [PATCH] p1010rdb: gianfar config does not have queues.
Hello Pankaj, Rajan DO you have any comments on the below patch of gianfar? - fsl,num_rx_queues = 0x8; - fsl,num_tx_queues = 0x8; Have been removed from P1010RDB device tree to avoid a kernel panic. Kumar, as such I see this is the old dts format. Also in the latest sdk tree these properties are defined, not sure it is working on P1010RDB. I can check on this and get back. Regards Poonam -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, March 16, 2012 8:50 PM To: Aggrwal Poonam-B10812 Cc: Robin Holt; U Bhaskar-B22300; PPC list; Eric Dumazet Subject: Re: [PATCH] p1010rdb: gianfar config does not have queues. On Aug 11, 2011, at 9:25 AM, Robin Holt wrote: If I have the the fsl,num_rx_queues and fsl,num_tx_queues properties defined in the p1010's device tree file, I get a kernel panic very shortly after boot. The failure indicates we are configuring the gianfar.c driver for a queue depth greater than actual. Removing the properties got the problem resolved. Signed-off-by: Robin Holt h...@sgi.com To: U Bhaskar-B22300 b22...@freescale.com Cc: PPC list linuxppc-dev@lists.ozlabs.org Cc: Eric Dumazet eric.duma...@gmail.com Poonam, Can you comment on this patch, does it look correct? - k diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi index 7f51104..91566aa 100644 --- a/arch/powerpc/boot/dts/p1010si.dtsi +++ b/arch/powerpc/boot/dts/p1010si.dtsi @@ -258,8 +258,6 @@ device_type = network; model = eTSEC; compatible = fsl,etsec2; - fsl,num_rx_queues = 0x8; - fsl,num_tx_queues = 0x8; local-mac-address = [ 00 00 00 00 00 00 ]; interrupt-parent = mpic; @@ -280,8 +278,6 @@ device_type = network; model = eTSEC; compatible = fsl,etsec2; - fsl,num_rx_queues = 0x8; - fsl,num_tx_queues = 0x8; local-mac-address = [ 00 00 00 00 00 00 ]; interrupt-parent = mpic; @@ -302,8 +298,6 @@ device_type = network; model = eTSEC; compatible = fsl,etsec2; - fsl,num_rx_queues = 0x8; - fsl,num_tx_queues = 0x8; local-mac-address = [ 00 00 00 00 00 00 ]; interrupt-parent = mpic; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ARM + TI DSP device tree repesentation
Hello All I am trying to locate the device tree for OMAP platform which has ARM and TI DSP core. The background is that we are trying to understand how such SOCs with dissimilar cores are represented in linux. Can somebody point me to the correct file. Many Thanks Poonam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx:DTS: Fix tbi node location for Px020RDB
-Original Message-
From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Kumar
Gala
Sent: Wednesday, June 22, 2011 5:04 PM
To: Kushwaha Prabhakar-B32579
Cc: meet2pra...@gmail.com; devicetree-disc...@lists.ozlabs.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/85xx:DTS: Fix tbi node location for Px020RDB
On Jun 7, 2011, at 9:49 PM, Prabhakar Kushwaha wrote:
ten-bit interface (TBI) module is part of SoC not board.
Move tbi entries from board related dts files to Si dts.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch
next)
arch/powerpc/boot/dts/p1020rdb.dts|9 -
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |8
arch/powerpc/boot/dts/p1020si.dtsi|6 +-
arch/powerpc/boot/dts/p2020rdb.dts|8
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |8
arch/powerpc/boot/dts/p2020si.dtsi|6 +-
6 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts
b/arch/powerpc/boot/dts/p1020rdb.dts
index d6a8ae4..a4e5d6c 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -211,14 +211,6 @@
};
};
- mdio@25000 {
-
- tbi0: tbi-phy@11 {
- reg = 0x11;
- device_type = tbi-phy;
- };
- };
-
enet0: ethernet@b {
fixed-link = 1 1 1000 0 0;
phy-connection-type = rgmii-id;
@@ -227,7 +219,6 @@
enet1: ethernet@b1000 {
phy-handle = phy0;
- tbi-handle = tbi0;
phy-connection-type = sgmii;
};
I'm not sure we should do this. The phy address we pick is board
specific so it should NOT be in .dtsi
The TBI phy and it's address is internal to SOC.
Regards
Poonam
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Regarding P2020 in AMP mode
The code looks to be correct in upstream, Can u mention the AMP boot steps you are using. 5.5.2.4 Test Procedure 1. Power on the board 2. Follow the command below at U-boot prompt = setenv serverip = setenv ipaddr = setenv ethact eTSEC2 = setenv bootargs root=/dev/ram rw console=ttyS0,115200 3. Bring up core1's kernel first: = setenv bootm_low 0x1000 = setenv bootm_size 0x800 = tftp 1100 uImage.core1 = tftp 1200 rootfs_min.ext2.gz.uboot = tftp 10c0 p1020rdb_camp_core1.dtb = interrupts off = bootm start 1100 1200 10c0 = bootm loados = bootm ramdisk = bootm fdt = fdt boardsetup = fdt chosen $initrd_start $initrd_end = bootm prep = cpu 1 release $bootm_low - $fdtaddr - As soon as, when you run the cpu 1 release $bootm_low - $fdtaddr - command, Core-1 starts booting and boot-up log can be observed on the UART#2 console. 4. Bring up core0's kernel(on the same u-boot console -UART#1): = setenv bootm_low 0x0 = setenv bootm_size 0x1000 = tftp 100 uImage.core0 = tftp 200 rootfs_min.ext2.gz.uboot = tftp c0 p1020rdb_camp_core0.dtb = bootm 100 200 c0 The main catch here is to use eTSEC2 as active port at u-boot. I think I remember we also faced similar issue. Regards Poonam -Original Message- From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org [mailto:linuxppc-dev- bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Hollis Blanchard Sent: Tuesday, May 10, 2011 1:53 AM To: Prasanna Khanapur Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: Regarding P2020 in AMP mode On 05/07/2011 05:20 AM, Prasanna Khanapur wrote: Hi, I'm running P2020 in AMP mode, each core running its linux os. Ethernet 1(@25000) and Ethernet 2(@26000) assigned to Core0 are working fine. I'm facing problems with Ethernet interface(@24000) assigned to Core1, its not working. I'm using dts file which were added by : http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075594.h tml Looks either there is some mistake in the dts file or my understanding is wrong. MDIO @24000 is defined in core0 dts file though the Ethernet is assigned to Core 1. DTS files : http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p202 0rdb_camp_core0.dts http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p202 0rdb_camp_core1.dts The fixed-link property in core1.dts indicates enet0 should use 1Gb link. Is that device connected to a 1Gb network? -- Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
Hello Felix Please find some comments inline. Regards Poonam -Original Message- From: Kushwaha Prabhakar-B32579 Sent: Tuesday, April 12, 2011 9:26 AM To: Aggrwal Poonam-B10812 Subject: FW: Problem with mini-PCI-E slot on P2020RDB -Original Message- From: Felix Radensky [mailto:fe...@embedded-sol.com] Sent: Monday, April 11, 2011 7:16 PM To: Kushwaha Prabhakar-B32579 Cc: Fabian Bertholm; Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 Subject: Re: Problem with mini-PCI-E slot on P2020RDB Hi Prabhakar, On 04/11/2011 02:09 PM, Kushwaha Prabhakar-B32579 wrote: Hi, Yes. It wil be applicable for all revisions. Regards, Prabhakar I'm sure this is applicable to all revisions, but it doesn't necessarily makes things work. The problem I've reported back in 2009 still exists on P2020RDB revC, even if I use the latest u-boot and kernel and make device tree changes that you've suggested. I've attached the boot log. As such there is no hardware fix related to this issue between RevC to RevD. The solution was a software patch to resolve the issue related to IRQ0. On the other hand, on P1020RDB revD with the same kernel, ath9k driver loads fine and interrupts are arriving. However this only works with u- boot-2010.12. May be you can look at http://old.nabble.com/Problem-with-mini-PCI-E-slot-on-P2020RDB-td26802038.html Felix we do not have the atheros driver for 2.6.38 and the issue is only seen with Atheros not sata_sil. If possible can you send the driver code if possible so that we can try reproducing it. Regards Poonam -Original Message- From: Felix Radensky [mailto:fe...@embedded-sol.com] Sent: Monday, April 11, 2011 2:10 PM To: Kushwaha Prabhakar-B32579 Cc: Fabian Bertholm; Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 Subject: Re: Problem with mini-PCI-E slot on P2020RDB Hi, Assuming I have all patches in place, will this problem be resolved on earlier board revisions (before rev D) ? Felix. On 04/11/2011 12:06 PM, Kushwaha Prabhakar-B32579 wrote: Hi Fabe, Yes .. P1020/P1011 RDB has same issue as of P2020RDB. It was because of some missing patches at u-boot and Linux. U-boot patch : It is already present in open source. Please use latest code base Linux patch : I am in process of posting in open source. Please make mentioned changes of IDSEL. --Prabhakar -Original Message- From: Fabian Bertholm [mailto:fabeisag...@googlemail.com] Sent: Monday, April 11, 2011 1:53 PM To: Kushwaha Prabhakar-B32579 Cc: Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan Vivek-B08308; Felix Radensky; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 Subject: Re: Problem with mini-PCI-E slot on P2020RDB Hello Kushwaha Prabhakar, Our impression is that there is the same issue on the P1020/P1011 RDB. Can you confirm this? Best Regards, Fabe 2011/4/8 Kushwaha Prabhakar-B32579b32...@freescale.com: -Original Message- From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com] Sent: Thursday, April 07, 2011 10:50 PM To: linuxppc-...@ozlabs.org Cc: Kumar Gala; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Felix Radensky; Kushwaha Prabhakar-B32579 Subject: Re: Problem with mini-PCI-E slot on P2020RDB Hello, On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky fe...@embedded-sol.com wrote: Kumar Gala wrote: On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: Thanks a lot. If I understand you correctly, the only way I can get ath9k driver to work on this board using legacy interrupts is to wait for a hardware fix. Right ? Correct I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it used for another purpose? There's a problem with IRQ0 with respect to mini-PCI-E slot. I have Atheros wireless card plugged into it. ath9k wireless driver for this card uses legacy PCI-E interrupts, and I get irq 16: nobody cared message when driver executes request_irq(). Vivek has come to a conclusion that the problem is related to incorrect IRQ0 routing for mini-PCI-E slot on P2020RDB. I would like to understand this issue better, as I seem to be running into something similar, and it puts my board design on hold. Can someone (from Freescale) explain what happens if a PCI Express end point on the mini-PCIe slot raises a legacy interrupt, and where this goes wrong? From what document or source code file can I conclude that the PCIe legacy interrupt is shared with IRQ0? I found this: P1020E/P2020E RDB System Errata, Last Update: 2/15/2010: Problem:IRQ0 held low Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N. See R420 in Rev D schematic. Add 4.7K pull-up (to 3.3.V) for MCU_INT_N. See R423 in Rev D schematic. Hello Leon, Yes you
RE: [PATCH] ATA: Add FSL sata v2 controller support
-Original Message-
From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of
Sergei Shtylyov
Sent: Monday, January 17, 2011 5:18 PM
To: Xu Lei-B33228
Cc: jgar...@pobox.com; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
linux-...@vger.kernel.org
Subject: Re: [PATCH] ATA: Add FSL sata v2 controller support
Hello.
On 17-01-2011 10:10, Xulei wrote:
In FSL sata v2 block, the snoop bit of PRDT Word3 description
information is at bit28 instead of bit22.
This patch adds FSL sata v2 probe and resolve this difference.
Signed-off-by: Xulei b33...@freescale.com
AFAIK, full name is required.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
[...]
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
index 2bbecbb..9ad41dd 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -475,14 +475,14 @@
};
sata@18000 {
- compatible = fsl,mpc8536-sata, fsl,pq-sata;
+ compatible = fsl,p1022-sata, fsl,pq-sata-v2;
Can we fix this compatibity at run time by u-boot?
reg =0x18000 0x1000;
cell-index =1;
interrupts =74 0x2;
};
sata@19000 {
- compatible = fsl,mpc8536-sata, fsl,pq-sata;
+ compatible = fsl,p1022-sata, fsl,pq-sata-v2;
reg =0x19000 0x1000;
cell-index =2;
interrupts =41 0x2;
Please put this into the separate patch and push thru the PPC tree.
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
b0214d0..a56399a 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
[...]
@@ -417,7 +420,8 @@ static void sata_fsl_qc_prep(struct ata_queued_cmd
*qc)
if (qc-flags ATA_QCFLAG_DMAMAP)
num_prde = sata_fsl_fill_sg(qc, (void *)cd,
- ttl_dwords, cd_paddr);
+ ttl_dwords, cd_paddr,
+ host_priv-data_snoop);
Please align these lines uniformly.
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
-Original Message- From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org [mailto:linuxppc-dev- bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Micha Nelissen Sent: Wednesday, June 16, 2010 12:29 PM To: linuxppc-dev@lists.ozlabs.org Subject: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Hi, Attached is a patch to fix large physical address support for the e500v2 core. When 4GB addresses are used, the MAS7 register needs to be valid for tlbsx instruction usage. Please review and apply. [Aggrwal Poonam] This is already being done by u-boot, should linux set it again? Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
-Original Message- From: Micha Nelissen [mailto:mi...@neli.hopto.org] Sent: Wednesday, June 16, 2010 2:55 PM To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Aggrwal Poonam-B10812 wrote: Attached is a patch to fix large physical address support for the This is already being done by u-boot, should linux set it again? Yikes! Took me 5 min to reformat your email. Our version of U-boot does not but it's not latest greatest. IMHO: 1) Linux should not be dependent on U-boot or any other bootloader, or at least as possible 2) U-boot cannot (and does not want to) know whether Linux is going to use large physical addresses. Not sure of other platforms but on 85xx platforms on which I am currently working u-boot does LAW and eLBC programming for 36bit physical address. Hence possibly u-boot has to made aware of large physical address space. Please correct me if I am wrong. Regards, Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
-Original Message- From: Micha Nelissen [mailto:mi...@neli.hopto.org] Sent: Wednesday, June 16, 2010 5:04 PM To: Aggrwal Poonam-B10812 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Aggrwal Poonam-B10812 wrote: Not sure of other platforms but on 85xx platforms on which I am currently working u-boot does LAW and eLBC programming for 36bit physical address. Hence possibly u-boot has to made aware of large physical address space. Please correct me if I am wrong. Yes, I can understand this for SDRAM and local flash interface. For RapidIO we have (local) patches to pass the law address range in the dtb. Perhaps also for PCI-express this might be done; U-boot has nothing to with these high speed interfaces (in our case at least). You are correct , for PCIe and SRIO kinds of interfaces Linux reprograms the address windows. Thanks Poonam Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs
.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list
s.ozlabs.org] On Behalf Of Kumar Gala
Sent: Thursday, September 24, 2009 11:42 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-dev list; Felix Radensky;
linuxppc-rele...@webnode01-prod1.am.freescale.net
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
On Aug 5, 2009, at 11:25 PM, Felix Radensky wrote:
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+++
++
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create
mode 100644
arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/
dts/p2020rdb.dts new file mode 100644 index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+0x1 0x0 0x0 0xffa0 0x0004
+0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch. Also,
are you sure
the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Did you plan on making this change?
I already fixed it in v3 version of the patch, although please consider
the v4 version just sent recently. V4 also makes the comment proper as
suggested by Felix.
Regards
Poonam
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
Partitions should be declared as
partit...@0 {
reg = ...
label = ...
...
}
Felix
RE: [PATCH][v2] powerpc/85xx: Create dts for each core in CAMP mode for P2020RDB
Hello Kumar
Could you please accept this patch if it is fine.
Regards
Poonam
-Original Message-
From: Aggrwal Poonam-B10812
Sent: Saturday, September 19, 2009 10:44 PM
To: linuxppc-...@ozlabs.org
Cc: Aggrwal Poonam-B10812
Subject: [PATCH][v2] powerpc/85xx: Create dts for each core
in CAMP mode for P2020RDB
This patch creates the dts files for each core and splits the
devices between the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1,
crypto, global-util, pci0
core1 has L2, dma2, eth0, pci1, msi.
MPIC is shared between two cores but each core will protect
its interrupts from other core by using protected-sources of mpic.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
- based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
- branch-next
- Removed interrupt properties for serial ports to make them
work in polling mode.
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 363
+
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 184 +
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 10 +-
3 files changed, 556 insertions(+), 1 deletions(-) create
mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
new file mode 100644
index 000..0fe93d0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
@@ -0,0 +1,363 @@
+/*
+ * P2020 RDB Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only
mpic and L2
+cache
+ * can be shared, all the other devices must be assigned to
one core only.
+ * This dts file allows core0 to have memory, l2, i2c, spi,
gpio, dma1,
+usb,
+ * eth1, eth2, sdhc, crypto, global-util, pci0.
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as
published by
+the
+ * Free Software Foundation; either version 2 of the
License, or (at
+your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB, fsl,MPC85XXRDB-CAMP;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ s...@ffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,p2020-immr, simple-bus;
+ ranges = 0x0 0x0 0xffe0 0x10;
+ bus-frequency = 0;// Filled out by uboot.
+
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,p2020-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
+ memory-control...@2000 {
+ compatible = fsl,p2020-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ r...@68 {
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ };
+ };
+
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ serial0: ser...@4500 {
+ cell-index = 0;
+ device_type = serial
RE: [PATCH][v3] powerpc/85xx: P1020RDB Support Added
Hello Kumar
Could you please accept this patch if it is okay.
Regards
POonam
-Original Message-
From: Aggrwal Poonam-B10812
Sent: Monday, August 31, 2009 5:22 PM
To: linuxppc-...@ozlabs.org
Cc: Aggrwal Poonam-B10812
Subject: [PATCH][v3] powerpc/85xx: P1020RDB Support Added
P1020 is another member of Freescale QorIQ series of processors.
It is an e500 based dual core SOC.
Being a scaled down version of P2020 it has following
differences from P2020:
- 533MHz - 800MHz core frequency.
- 256Kbyte L2 cache
- Ethernet controllers with classification capabilities(new
controller).
From board perspective P1020RDB is same as P2020RDB.
* This code adds the basic basic platform support for P1020RDB.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
- based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
- branch-next
- The patch does not contain ethernet support because P1020
contains new eTSEC
controller. The support will be added in the later patches.
arch/powerpc/boot/dts/p1020rdb.dts| 477
+
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 24 ++
2 files changed, 501 insertions(+), 0 deletions(-) create
mode 100644 arch/powerpc/boot/dts/p1020rdb.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts
b/arch/powerpc/boot/dts/p1020rdb.dts
new file mode 100644
index 000..de5672c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -0,0 +1,477 @@
+/*
+ * P1020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as
published by
+the
+ * Free Software Foundation; either version 2 of the
License, or (at
+your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P1020;
+ compatible = fsl,P1020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p1...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p1...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p1020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002;
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ partit...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
+
+ partit...@4 {
+ /* 256KB for DTB Image */
+ reg = 0x0004 0x0004;
+ label = NOR (RO) DTB Image;
+ read-only;
+ };
+
+ partit...@8 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg = 0x0008 0x0038;
+ label = NOR (RO) Linux Kernel Image;
+ read-only;
+ };
+
+ partit...@40 {
+ /* 11MB for JFFS2 based Root
file System */
+ reg = 0x0040 0x00b0;
+ label = NOR (RW) JFFS2 Root
File System;
+ };
+
+ partit...@f0 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment
Variables
RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodeforP2020RDB
-Original Message- From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs .org [mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list s.ozlabs.org] On Behalf Of Kumar Gala Sent: Wednesday, September 16, 2009 7:10 PM To: Aggrwal Poonam-B10812 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodeforP2020RDB On Sep 11, 2009, at 6:47 AM, Aggrwal Poonam-B10812 wrote: Ok, I wrongly understood protected interrupts as reserved for one core. However, I still dislike two devices having the same name. Otherwise it may work if every interrupt is delivered to both cores although statistically only one core will actually have some work to do. Doesn't the kernel complain about unhandled irqs however? We don't see any such messages of unhandled interrupts, although I checked the corresponding files for mpc8572ds, they do not have the interrupts property for the serial ports at all, in both the core0 and core1 dts. Don't know the reason. the p2020 versions shouldn't have an interrupt property in the serial node. The reason we removed it in the 8572 CAMP dts is to make sure we get polling mode. As Gabriel points out sharing the IRQ between the two OSes is not safe. While it might seem to work it will have issues at some point. Thanks for the explanation. Probably we are not seeing an issue, because we are protecting the int 42 in both the dts files. So probably mpic is not forwarding the interrupt to any of the cores. Anyways I will rework the patch and resend. Kind Regards Poonam - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
-Original Message-
From: Gabriel Paubert [mailto:paub...@iram.es]
Sent: Thursday, September 10, 2009 9:33 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each
core in CAMPmodefor P2020RDB
On Thu, Sep 10, 2009 at 08:48:38PM +0530, Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Gabriel Paubert [mailto:paub...@iram.es]
Sent: Thursday, September 10, 2009 3:03 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for
each core in
CAMPmode for P2020RDB
On Thu, Sep 10, 2009 at 02:27:11PM +0530, Poonam Aggrwal wrote:
This patch creates the dts files for each core and splits
the devices
between the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto,
global-util, pci0
core1 has L2, dma2, eth0, pci1, msi.
Surely you mean eth1 and eth2 for core0, no?
Yes you are right , I'll fix this.
At least it's what I gather from the code.
Also both cores have a node called serial0, at different
addresses
but with the same interrupt!
Yes both the UARTS use the same int line in shared mode.
But in the mpic comment line there is serial1, and
interrupt 42 is
the only number which appears in both lists of mpic protected
interrupts.
I am not sure how to handle the shared interrupts in AMP scenario,
although this has been tested and both serials are working
one on each
core.
Ok, I wrongly understood protected interrupts as reserved for
one core. However, I still dislike two devices having the same name.
Otherwise it may work if every interrupt is delivered to both
cores although statistically only one core will actually have
some work to do. Doesn't the kernel complain about unhandled
irqs however?
We don't see any such messages of unhandled interrupts, although I
checked the corresponding files for mpc8572ds, they do not have the
interrupts property for the serial ports at all, in both the core0 and
core1 dts.
Don't know the reason.
Regards,
Gabriel
+
+ serial0: ser...@4500 {
+ cell-index = 0;
+ device_type = serial;
+ compatible = ns16550;
+ reg = 0x4500 0x100;
+ clock-frequency = 0;
+ interrupts = 42 2;
+ interrupt-parent = mpic;
+ };
+
+ mpic: p...@4 {
+ interrupt-controller;
+ #address-cells = 0;
+ #interrupt-cells = 2;
+ reg = 0x4 0x4;
+ compatible = chrp,open-pic;
+ device_type = open-pic;
+ protected-sources =
+ 42 76 77 78 79 /* serial1 , dma2 */
+ 29 30 34 26 /* enet0, pci1 */
+ 0xe0 0xe1 0xe2 0xe3 /* msi */
+ 0xe4 0xe5 0xe6 0xe7
+ ;
+ };
+
+
+ serial0: ser...@4600 {
+ cell-index = 1;
+ device_type = serial;
+ compatible = ns16550;
+ reg = 0x4600 0x100;
+ clock-frequency = 0;
+ interrupts = 42 2;
+ interrupt-parent = mpic;
+ };
+
+
+ mpic: p...@4 {
+ interrupt-controller;
+ #address-cells = 0;
+ #interrupt-cells = 2;
+ reg = 0x4 0x4;
+ compatible = chrp,open-pic;
+ device_type = open-pic;
+ protected-sources =
+ 17 18 43 42 59 47 /*ecm, mem,
i2c, serial0, spi,gpio */
+ 16 20 21 22 23 28 /* L2,
dma1, USB */
+ 03 35 36 40 31 32 33/*
mdio, enet1, enet2 */
+ 72 45 58 25 /*
sdhci, crypto , pci */
+ ;
+ };
+
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmode for P2020RDB
-Original Message-
From: Gabriel Paubert [mailto:paub...@iram.es]
Sent: Thursday, September 10, 2009 3:03 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each
core in CAMPmode for P2020RDB
On Thu, Sep 10, 2009 at 02:27:11PM +0530, Poonam Aggrwal wrote:
This patch creates the dts files for each core and splits
the devices
between the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto,
global-util, pci0
core1 has L2, dma2, eth0, pci1, msi.
Surely you mean eth1 and eth2 for core0, no?
Yes you are right , I'll fix this.
At least it's what I gather from the code.
Also both cores have a node called serial0, at different
addresses but with the same interrupt!
Yes both the UARTS use the same int line in shared mode.
But in the mpic comment line there is serial1, and
interrupt 42 is the only number which appears in both lists
of mpic protected interrupts.
I am not sure how to handle the shared interrupts in AMP scenario,
although this has been tested and both serials are working one on each
core.
Regards
Poonam
Gabriel
---
- based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
- branch-next
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 365
+
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 186 +
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 10 +-
3 files changed, 560 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
new file mode 100644
index 000..ca072da
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
@@ -0,0 +1,365 @@
+/*
+ * P2020 RDB Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only
mpic and
+L2 cache
+ * can be shared, all the other devices must be assigned
to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, spi, gpio,
+dma1, usb,
+ * eth1, eth2, sdhc, crypto, global-util, pci0.
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as
published
+by the
+ * Free Software Foundation; either version 2 of the License, or
+(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB, fsl,MPC85XXRDB-CAMP;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ s...@ffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,p2020-immr, simple-bus;
+ ranges = 0x0 0x0 0xffe0 0x10;
+ bus-frequency = 0;// Filled out by uboot.
+
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,p2020-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
+ memory-control...@2000 {
+ compatible = fsl,p2020-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ r...@68 {
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ };
+ };
+
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c
RE: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, August 11, 2009 7:11 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
+ enet2: ether...@26000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 2;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 0x26000 0x1000;
+ ranges = 0x0 0x26000 0x1000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 31 2 32 2 33 2;
+ interrupt-parent = mpic;
+ phy-handle = phy1;
+ phy-connection-type = rgmii-id;
+ };
was there an answer to why we don't have an mdio node for enet2?
Yes I already replied to it, actually the enet2 (eTSEC3) on RDB is only
exposed as RGMII, and the mdio lines it will use is those of enet0. In
case it also could be configured in SGMII(as in P2020DS), then we would
have needed the mdio node for enet2 to configure the TBI PHY.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Friday, August 07, 2009 4:42 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
See some more comments below.
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
incorporated Felix feedback regarding the partition names.
fixed the vitesse switch ranges entry in device tree.
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..617029f
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as
published
+by the
+ * Free Software Foundation; either version 2 of the License, or
+(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002;
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ partit...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
+
+ partit...@4 {
+ /* 256KB for DTB Image */
+ reg = 0x0004 0x0004;
+ label = NOR (RO) DTB Image;
+ read-only;
+ };
+
+ partit...@8 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg = 0x0008 0x0038;
+ label = NOR (RO) Linux Kernel Image;
+ read-only
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as
published
+by the
+ * Free Software Foundation; either version 2 of the License, or
+(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR (RO) Vitesse-7385
Firmware;
+ read-only;
+ };
Partitions should be declared as
partit...@0 {
reg = ...
label = ...
...
}
Doing it this way is good from readability perspective, but we generally
do not use this convention in our platforms eg 8572DS, etc
Regards
Poonam
Felix
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs
.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list
s.ozlabs.org] On Behalf Of Felix Radensky
Sent: Thursday, August 06, 2009 12:16 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org;
linuxppc-rele...@webnode01-prod1.am.freescale.net
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute
it and/or
+modify it
+ * under the terms of the GNU General Public License as
published
+by the
+ * Free Software Foundation; either version 2 of the
License, or
+(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the
size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR
RE: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs
.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list
s.ozlabs.org] On Behalf Of Felix Radensky
Sent: Thursday, August 06, 2009 12:16 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org;
linuxppc-rele...@webnode01-prod1.am.freescale.net
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Aggrwal Poonam-B10812 wrote:
-Original Message-
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, August 06, 2009 11:56 AM
To: Aggrwal Poonam-B10812
Cc: linuxppc-rele...@webnode01-prod1.am.freescale.net;
linuxppc-...@ozlabs.org
Subject: Re: [PATCH][powerpc/85xx] P2020RDB Platform Support Added
Hi, Poonam
Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on
http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p2020rdb.dts| 586
+
arch/powerpc/configs/mpc85xx_defconfig|1 +
arch/powerpc/platforms/85xx/Kconfig |9 +
arch/powerpc/platforms/85xx/Makefile |3 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 141 +++
5 files changed, 739 insertions(+), 1 deletions(-) create mode
100644 arch/powerpc/boot/dts/p2020rdb.dts
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..d6d8131
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute
it and/or
+modify it
+ * under the terms of the GNU General Public License as
published
+by the
+ * Free Software Foundation; either version 2 of the
License, or
+(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ /* NOR and NAND Flashes */
+ ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0800;
The comment is a bit misleading, CS2 is L2 switch.
Okay will modify it.
Also, are
you sure the CS2 range shouldn't look like
0x2 0x0 0x0 0xffb0 0x0002
That's what L2switch reg property suggests.
Thanks , for catching it!...this is a bug , I changed the
size in the
reg property but not in the ranges.
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ vitesse-7385...@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385
Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR
RE: Newby trying to get Ethernet going on MPC83xx series device.
Can you look into your board specific file
Like board/freescale/mpc8249_mds/mpc8349_mds.c
And check if the buses are getting probed.
For example
static struct of_device_id mpc834x_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
{ .compatible = simple-bus, },
{},
};
static int __init mpc834x_declare_of_platform_devices(void)
{
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
machine_device_initcall(mpc834x_mds,
mpc834x_declare_of_platform_devices);
Regards
Poonam
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@ozla
bs.org] On Behalf Of Li Yang-R58472
Sent: Thursday, February 19, 2009 10:52 AM
To: Dushara Jayasinghe; linuxppc-dev@ozlabs.org
Subject: RE: Newby trying to get Ethernet going on MPC83xx
series device.
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
On Behalf Of Dushara Jayasinghe
Sent: Thursday, February 19, 2009 12:27 PM
To: 'linuxppc-dev@ozlabs.org'
Subject: Newby trying to get Ethernet going on MPC83xx
series device.
Hi I'm having difficulty getting an Ethernet device up on a
dev board
with an MPX8349 controller.
The contents of my .dts file are as follows (based on
mpc8349emitx.dts):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 20 8 21 8 22 8;
interrupt-parent = ipic;
tbi-handle = tbi0;
phy-handle = phy1c;
linux,network-index = 0;
};
ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 25000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 23 8 24 8 25 8;
interrupt-parent = ipic;
/* Vitesse 7385 isn't on the MDIO bus */
fixed-link = 1 1 1000 0 0;
linux,network-index = 1;
tbi-handle = tbi1;
phy-connection-type = gmii;
};
};
I get the following error during the boot sequence:
IP-Config: Device `eth0' not found
I also found that both gfar_init (in gianfar.c) and
gfar_mdio_init (in
gianfar_mii.c) are called but the probe handlers of either of these
devices are not executed.
What am I missing?
Don't find any obvious problem. I suggest you to debug
gfar_of_init() in arch/powerpc/sysdev/fsl_soc.c to see if it
works correctly.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
Probably better would be to check the board file for mpc834x_mds.c
I mean just cross that you probe all the buses which are on the device.
What is fsl,pq2pro-localbus? Do u have such node in dts as the
mpc8349_itx has.
-Original Message-
From: pku@gmail.com [mailto:pku@gmail.com] On Behalf
Of Li Yang-R58472
Sent: Thursday, February 19, 2009 12:50 PM
To: Dushara Jayasinghe
Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812
Subject: Re: Newby trying to get Ethernet going on MPC83xx
series device.
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
dusha...@optiscan.com wrote:
That did it.
I based my board specific file on mpc834x_itx.c which had
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{ .compatible = simple-bus, },
{},
};
Don't know if this is broken?
It's not broken as long as you have compatible = simple-bus
for your soc node.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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]; [EMAIL PROTECTED]; 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; [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]; [EMAIL PROTECTED]; 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Gala Kumar; linuxppc-dev@ozlabs.org; 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/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
FW: [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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[no subject]
With Regards Poonam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
