* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-18 16:51 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <4767F271.4090703@freescale.com>
On Tue, Dec 18, 2007 at 10:16:49AM -0600, Scott Wood wrote:
> David Gibson wrote:
> >In this case the driver and binding have been developed together and
> >for the time being it does require PHY nodes, obviously. I'm saying
> >that maybe that requirement ought to be changed.
>
> I don't see why.
>
> >Well, phandle is only used to find the phy node itself, so it doesn't
> >count. The only piece of information there is the reg - the PHY id.
> >Following a phandle to another node is a fairly complex way of finding
> >a single integer.
> >
> >Eh, I guess it's ok, but just directly giving the PHY id or a probe
> >mask in the MAC node would also be fine (we do this for 4xx EMAC).
>
> It's not just a simple integer -- it also tells you which mdio bus it's on.
Exactly. And at least one board (MPC8568E-MDS) using this feature:
UECs are using PHYs placed on the TSEC's MDIO bus. This is hardware
configurable, and could be contrariwise: TSECs can use PHYs that
are under control of UEC MDIO bus controller.
That's why we're naming PHYs as bus:phyid.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
From: Kumar Gala @ 2007-12-18 16:42 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071218162032.GB28931@xyzzy.farnsworth.org>
On Dec 18, 2007, at 10:20 AM, Dale Farnsworth wrote:
> On Sat, Dec 15, 2007 at 05:17:41PM +1100, Benjamin Herrenschmidt
> wrote:
>>
>> On Thu, 2007-11-22 at 08:46 -0700, Dale Farnsworth wrote:
>>> This is needed for the ppc32 /dev/oldmem driver of crash dump.
>>
>> Kumar's working (well, last I heard he was) on a fixmap mechanism
>> so we can do that sort of thing without CONFIG_HIGHMEM, you may
>> want to sync with him here, that would allow to shrink the crash
>> kernel by not having highmem selected.
>>
>> Cheers,
>> Ben.
>
> Kumar, are you close to posting something that would make the
> patch below unnecessary (or change it significantly)? If so,
> I'll hold off.
My plan is to get the fixmap stuff posted this week.
- k
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Dale Farnsworth @ 2007-12-18 16:38 UTC (permalink / raw)
To: Dale Farnsworth, Linuxppc-dev
In-Reply-To: <20071216064056.GH21311@localhost.localdomain>
On Sun, Dec 16, 2007 at 05:40:56PM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote:
> > David Gibson wrote:
> > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > > > Device tree source file for the Emerson Katana Qp board
> >
> > [snip]
> >
> > > > + mv64x60@f8100000 { /* Marvell Discovery */
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + model = "mv64460"; /* Default */
> > > > + compatible = "marvell,mv64x60";
> >
> > [snip]
> >
> > > > + mdio {
> > >
> > > There must be some way of actuall accessing the mdio bus, so this node
> > > ought to have a 'reg' property and unit address.
> >
> > There is no way for the cpu to directly access the mdio bus. The
> > mdio bus is internally accessed by the ethernet MAC. That being the
> > case, maybe it makes more sense to move the mdio node inside of the
> > multiethernet node, as follows, but I don't see how we can give it
> > a reg property or a unit address.
>
> Ah, I see. If the mdio interface isn't distinct from the other
> pieces, then it probably shouldn't get a device node at all. Having
> an explicit mdio bus with the phys hanging off it is convenient for
> hardware which actually works that way, but it doesn't have to be done
> like that.
>
> Of course, then the question is where to hang the phy nodes, which
> look like they have information you need. Since you already have a
> local addressing scheme for the MACs under the multiethernet, what
> probably makes sense would be to hang the phys directly under the
> multiethernet, using an encoding scheme for the reg properties so that
> the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs
> are 0x80000000, 0x80000001, 0x80000002).
Ugh. They really are two separate address spaces. One is an
intra-register index, and the other really is an mdio address,
even though it's only indirectly addressable. Combining them would
obfuscate. I'm proceding with an mdio node under the multiethernet
node as I posted below. Let me know if you feel strongly that that
should be changed.
> Incidentally, although I suggested it, I'm not all that fond of the
> "multiethernet" name, it was just the first thing that occurred to me.
I'm not fond of it either. Sometimes, naming is hard. :)
I'll see if we can come up with something better.
Thanks,
-Dale
> >
> > multiethernet@2000 {
> > reg = <0x2000 0x2000>;
> > ethernet@0 {
> > device_type = "network";
> > compatible = "marvell,mv64360-eth";
> > reg = <0>;
> > interrupts = <32>;
> > interrupt-parent = <&PIC>;
> > phy = <&PHY0>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > };
> > ethernet@1 {
> > device_type = "network";
> > compatible = "marvell,mv64360-eth";
> > reg = <1>;
> > interrupts = <33>;
> > interrupt-parent = <&PIC>;
> > phy = <&PHY1>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > };
> > mdio {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > device_type = "mdio";
> > compatible = "marvell,mv64360-mdio";
> > PHY0: ethernet-phy@1 {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <1>;
> > };
> > PHY1: ethernet-phy@3 {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <3>;
> > };
> > };
> > };
^ permalink raw reply
* Re: Raising list size limit
From: Josh Boyer @ 2007-12-18 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <2420E261-C9AB-49B8-8F99-C24C7A865044@kernel.crashing.org>
On Tue, 18 Dec 2007 09:54:15 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
>
> > On Tue, 18 Dec 2007 14:36:27 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi,
> >>
> >> I am considering raising the limit on the size of postings to
> >> 400k. Does
> >> anyone have a real problem with this? Limiting message size was
> >> done to
> >> limit the damage of larges spams (and we don;t get very many of
> >> those on
> >> the list) and to ease the pain for people downloading emails over a
> >> slow
> >> (like dialup) link (and are there many of those left?).
> >
> > Fine by me!
>
> Do you really have patches that are 400k?
Nope. But I don't really care if I get them.
josh
^ permalink raw reply
* Re: USB configuration
From: Scott Wood @ 2007-12-18 16:19 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14389002.post@talk.nabble.com>
Misbah khan wrote:
> hi ...
>
> The montavista version we are using is " 2.6.10_mvl401-8272ads "
>
> Montavista people says that they are supporting USB host interface ....
If MV claims that they support the MPC82xx USB host controller, then you
should be talking to MV... it's not supported in the mainline kernel.
-Scott
^ permalink raw reply
* Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
From: Dale Farnsworth @ 2007-12-18 16:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1197699461.6696.45.camel@pasglop>
On Sat, Dec 15, 2007 at 05:17:41PM +1100, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-11-22 at 08:46 -0700, Dale Farnsworth wrote:
> > This is needed for the ppc32 /dev/oldmem driver of crash dump.
>
> Kumar's working (well, last I heard he was) on a fixmap mechanism
> so we can do that sort of thing without CONFIG_HIGHMEM, you may
> want to sync with him here, that would allow to shrink the crash
> kernel by not having highmem selected.
>
> Cheers,
> Ben.
Kumar, are you close to posting something that would make the
patch below unnecessary (or change it significantly)? If so,
I'll hold off.
-Dale
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > ---
> > include/asm-powerpc/highmem.h | 18 ++++++++++++++++++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
> > index f7b21ee..88d9e05 100644
> > --- a/include/asm-powerpc/highmem.h
> > +++ b/include/asm-powerpc/highmem.h
> > @@ -117,6 +117,24 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
> > pagefault_enable();
> > }
> >
> > +/* This is the same as kmap_atomic() but can map memory that doesn't
> > + * have a struct page associated with it.
> > + */
> > +static inline void *kmap_atomic_pfn(unsigned long pfn, enum km_type type)
> > +{
> > + unsigned int idx;
> > + unsigned long vaddr;
> > +
> > + pagefault_disable();
> > +
> > + idx = type + KM_TYPE_NR * smp_processor_id();
> > + vaddr = KMAP_FIX_BEGIN + idx * PAGE_SIZE;
> > + set_pte_at(&init_mm, vaddr, kmap_pte+idx, pfn_pte(pfn, kmap_prot));
> > + flush_tlb_page(NULL, vaddr);
> > +
> > + return (void*) vaddr;
> > +}
> > +
> > static inline struct page *kmap_atomic_to_page(void *ptr)
> > {
> > unsigned long idx, vaddr = (unsigned long) ptr;
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Scott Wood @ 2007-12-18 16:16 UTC (permalink / raw)
To: Scott Wood, Anton Vorontsov, Kumar Gala, Stephen Rothwell,
linuxppc-dev, Kim Phillips
In-Reply-To: <20071218035108.GA10212@localhost.localdomain>
David Gibson wrote:
> In this case the driver and binding have been developed together and
> for the time being it does require PHY nodes, obviously. I'm saying
> that maybe that requirement ought to be changed.
I don't see why.
> Well, phandle is only used to find the phy node itself, so it doesn't
> count. The only piece of information there is the reg - the PHY id.
> Following a phandle to another node is a fairly complex way of finding
> a single integer.
>
> Eh, I guess it's ok, but just directly giving the PHY id or a probe
> mask in the MAC node would also be fine (we do this for 4xx EMAC).
It's not just a simple integer -- it also tells you which mdio bus it's on.
-Scott
^ permalink raw reply
* Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-18 16:15 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071218005348.GC9489@localhost.localdomain>
David Gibson wrote:
> I mean, obviously the MDIO bus is accessed via some of the
> board-control registers. What I'm questioning is whether it makes
> sense to have a distinct node to represent the mdio bus, or whether
> the phys should just hang straight of the bcsr node.
Ah, I see. I think it does make sense, because it's a bus; if there
were another bus-like thing on the bcsr, there'd be conflicts over what
the children mean.
>>>> + soc@f0000000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + device_type = "soc";
>>> Ditch the device_type.
>> No, it's used by the bootwrapper. I'll get rid of it if you want to
>> write a find_node_by_compatible() function. :-)
>
> Well, now that libfdt is merged, there is one :-p.
OK, it just needs exporting via ops. I'll put it on my to-do list, but
I don't think it should hold up board support patches.
-Scott
^ permalink raw reply
* Re: [PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms
From: Dale Farnsworth @ 2007-12-18 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1197699385.6696.43.camel@pasglop>
On Sat, Dec 15, 2007 at 05:16:25PM +1100, Benjamin Herrenschmidt wrote:
> > index 8b642ab..db0e749 100644
> > --- a/arch/powerpc/kernel/misc_32.S
> > +++ b/arch/powerpc/kernel/misc_32.S
> > @@ -816,6 +816,75 @@ relocate_new_kernel:
> > /* r4 = reboot_code_buffer */
> > /* r5 = start_address */
> >
> > +#ifdef CONFIG_E500
> > + /*
> > + * Since we can't turn off the MMU, we must create an identity
> > + * map for kernel low memory. We start by invalidating the
> > + * TLB entries we don't need.
> > + *
> > + * First, invalidate the TLB0 entries
> > + */
> > + li r6, 0x04
> > + tlbivax 0, r6
> > +#ifdef CONFIG_SMP
> > + tlbsync
> > +#endif
> > + msync
> > +
>
> This is really E500 specific or should it be CONFIG_FSL_BOOKE ?
>
> Ben.
I agree that CONFIG_FSL_BOOKE is more appropriate. I'll reflect that
in the next respin.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH v2 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Scott Wood @ 2007-12-18 16:09 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071218004329.GB9489@localhost.localdomain>
David Gibson wrote:
> On Mon, Dec 17, 2007 at 09:15:17AM -0600, Scott Wood wrote:
>> Enh. That can get icky as well, and the bootwrapper isn't necessarily
>> even used for u-boot, and I'd rather not require it be used just for this.
>
> So make the template in the u-boot form, and poke it as necessary from
> the redboot wrapper.
I'd rather not, given that I have limited access to a board with redboot
to test on, and that it's just a cosmetic change. Separate device trees
are fine for now, and hopefully will motivate work on dtc templates.
-Scott
^ permalink raw reply
* Re: Raising list size limit
From: Olof Johansson @ 2007-12-18 16:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <2420E261-C9AB-49B8-8F99-C24C7A865044@kernel.crashing.org>
On Tue, Dec 18, 2007 at 09:54:15AM -0600, Kumar Gala wrote:
>
> On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
>
> > On Tue, 18 Dec 2007 14:36:27 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi,
> >>
> >> I am considering raising the limit on the size of postings to
> >> 400k. Does
> >> anyone have a real problem with this? Limiting message size was
> >> done to
> >> limit the damage of larges spams (and we don;t get very many of
> >> those on
> >> the list) and to ease the pain for people downloading emails over a
> >> slow
> >> (like dialup) link (and are there many of those left?).
> >
> > Fine by me!
>
> Do you really have patches that are 400k?
I'm guessing stuff such as "dtc merge" could reach those sizes?
Since it's somewhat common to cross-post patches (especially some of the
@de.ibm.com guys seem to post to 2-5 lists at a time), having a limit
higher than other lists could mean we see the same (large) patches several
times in case they bounce from other lists and get reposted. But it should
be a small fraction of the traffic no matter what.
-Olof
^ permalink raw reply
* Re: Raising list size limit
From: Kumar Gala @ 2007-12-18 15:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20071218060105.368f0bd4@zod.rchland.ibm.com>
On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
> On Tue, 18 Dec 2007 14:36:27 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi,
>>
>> I am considering raising the limit on the size of postings to
>> 400k. Does
>> anyone have a real problem with this? Limiting message size was
>> done to
>> limit the damage of larges spams (and we don;t get very many of
>> those on
>> the list) and to ease the pain for people downloading emails over a
>> slow
>> (like dialup) link (and are there many of those left?).
>
> Fine by me!
Do you really have patches that are 400k?
- k
^ permalink raw reply
* Re: [PATCH 1/7] Copy mpc-i2c to preserve support for ARCH=ppc and allow changes on ARCH=powerpc
From: Kumar Gala @ 2007-12-18 15:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20071218023915.8530.67500.stgit@terra.home>
On Dec 17, 2007, at 8:39 PM, Jon Smirl wrote:
> Temporarily copy the mpc-i2c driver to continue support for the ppc
> architecture until it is removed in mid-2008. This file should be
> deleted as part of ppc's final removal.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> arch/ppc/configs/TQM8540_defconfig | 2
> arch/ppc/configs/TQM8541_defconfig | 2
> arch/ppc/configs/TQM8555_defconfig | 2
> arch/ppc/configs/TQM8560_defconfig | 2
> arch/ppc/configs/mpc834x_sys_defconfig | 2
> arch/ppc/configs/mpc8540_ads_defconfig | 2
> arch/ppc/configs/mpc8548_cds_defconfig | 2
> arch/ppc/configs/mpc8555_cds_defconfig | 2
> arch/ppc/configs/mpc8560_ads_defconfig | 2
> drivers/i2c/busses/Kconfig | 16 +
> drivers/i2c/busses/Makefile | 1
> drivers/i2c/busses/i2c-mpc-ppc.c | 418 +++++++++++++++++++++++
> +++++++++
> 12 files changed, 443 insertions(+), 10 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-mpc-ppc.c
Nak.
Just ifdef the probe functionality in i2c-mpc.c based on
CONFIG_PPC_MERGE. Your patch set shows the reason you should do
this. You provide fixes to the error path handling, but only for i2c-
mpc.c and not i2c-mpc-ppc.c.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Kumar Gala @ 2007-12-18 15:53 UTC (permalink / raw)
To: avorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071215162331.GA24999@localhost.localdomain>
On Dec 15, 2007, at 10:23 AM, Anton Vorontsov wrote:
>
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <16 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
In addition to David's comments. I've added cell-index:
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <3100 100>;
interrupts = <f 8>;
interrupt-parent = < &ipic >;
dfsrr;
};
^ permalink raw reply
* [PATCH] [POWERPC] Add fixed-phy support for fs_enet
From: Jochen Friedrich @ 2007-12-18 15:25 UTC (permalink / raw)
To: Paul Mackerras, Vitaly Bordug
Cc: linuxppc-dev, Garzik, Jeff, Kernel, Linux, netdev
This patch adds support to use the fixed-link property
of an ethernet node to fs_enet for the
CONFIG_PPC_CPM_NEW_BINDING case.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Jeff Garzik <jeff@garzik.org>
Acked-by: Vitali Bordug <vitb@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..8220c70 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1174,8 +1174,15 @@ static int __devinit find_phy(struct device_node *np,
struct device_node *phynode, *mdionode;
struct resource res;
int ret = 0, len;
+ const u32 *data;
+
+ data = of_get_property(np, "fixed-link", NULL);
+ if (data) {
+ snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data);
+ return 0;
+ }
- const u32 *data = of_get_property(np, "phy-handle", &len);
+ data = of_get_property(np, "phy-handle", &len);
if (!data || len != 4)
return -EINVAL;
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
From: Vitaly Bordug @ 2007-12-18 15:10 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <4767042E.2070903@garzik.org>
On Mon, 17 Dec 2007 18:20:14 -0500
Jeff Garzik wrote:
> Jochen Friedrich wrote:
> > This patch adds support to use the fixed-link property
> > of an ethernet node to fs_enet for the
> > CONFIG_PPC_CPM_NEW_BINDING case.
> >
> > Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
Jochen,
will you resend the patch with all acks to paulus? I'll do that if not.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: dtc: Remove remaining old-style checks
From: Jon Loeliger @ 2007-12-18 13:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071218035438.GA10348@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The remaining old-style tree checking code: check_root(), check_cpus()
> and check_memory() really aren't that useful. They mostly check for
> the presence of particular nodes and properties. That's inherently
> prone to false-positives, because we could be dealing with an
> artificial tree (like many of the testcases) or it could be expected
> that the missing properties are filled in by a bootloader or other
> agent.
>
> If any of these checks really turns out to be useful, we can
> reimplement them later in a better conceived way on top of the new
> checking infrastructure. For now, just get rid of them, removing the
> last vestiges of the old-style checking code (hoorah).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* [PATCH] Platform Changes for UCC TDM driver for MPC8323ERDB. Also includes related QE changes.
From: Poonam_Aggrwal-b10812 @ 2007-12-18 9:02 UTC (permalink / raw)
To: rubini, linuxppc-dev, netdev, kumar.gala
Cc: michael.barkowski, rich.cutler, ashish.kalra
From: Poonam Aggrwal <b10812@freescale.com>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <b10812@freescale.com>
Signed-off-by: Ashish Kalra <ashish.kalra@freescale.com>
Signed-off-by: Kim Phillips <Kim.Phillips@freescale.com>
Signed-off-by: Michael Barkowski <michael.barkowski@freescale.com>
---
Incorporated comments of Stephen and Tabi. Please review if they look
fine.
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++++++
arch/powerpc/sysdev/qe_lib/qe.c | 205 ++++++++++++++++++++++++--
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +++++
include/asm-powerpc/qe.h | 8 +
include/asm-powerpc/ucc.h | 4 +
include/asm-powerpc/ucc_fast.h | 4 +
7 files changed, 568 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:ucc_pin@01 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0 /* CLK11 */
+ 3 16 1 0 2 0 /* BRG9 */
+ 3 1b 1 0 2 0 /* BRG3 */
+ 0 0 3 0 2 0 /* TDMATxD0 */
+ 0 4 3 0 2 0 /* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:ucc_pin@02 {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+ * CLK11 is 1024KHz,
+ * all other clocks unused
+ * #clock-cells define number of cells
+ * used by the clock-frequency.
+ * right now only #clock cells=1 is
+ * implemented. Provision is there to
+ * handle frequencies >4Gig
+ */
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ brg@640 {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+ * 1-24 for CLK1 to CLK24.
+ * BRG9 uses CLK11,BRG1 and BRG2-8 use
+ * the QE clock.
+ */
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
spi@4c0 {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ ucc@2000 {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
ucc@3000 {
device_type = "network";
compatible = "ucc_geth";
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1df3b4a..f1bc902 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -149,20 +149,189 @@ 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;
+ int ret;
+ 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);
- };
- return brg_clk;
+ prop = of_get_property(brg,
+ "fsl,brg-sources", &size);
+ of_node_put(brg);
+
+ if (prop && *prop >= 1 && *prop <= 24)
+ brg_src = *(prop + brg_num);
+ else {
+ printk(KERN_ERR "%s: invalid fsl,brg-sources in device "
+ "tree\n", __FUNCTION__);
+ ret = -EINVAL;
+ goto err;
+ }
+ if (brg_src == 0) {
+ *brg_source = 0;
+ if (brg_clk > 0)
+ return brg_clk;
+ qe = of_find_node_by_type(NULL, "qe");
+ if (qe) {
+ unsigned int size;
+ prop = of_get_property
+ (qe, "brg-frequency", &size);
+ if (!prop) {
+ printk(KERN_ERR "%s: QE brg-frequency"
+ "not present in device tree\n",
+ __FUNCTION__);
+ ret = -EINVAL;
+ of_node_put(qe);
+ goto err;
+ }
+ if (*prop) {
+ of_node_put(qe);
+ brg_clk = *prop;
+ return *prop;
+ } else {
+ /*
+ * Older versions of U-Boot do not initialize
+ * the brg-frequency property, so in this case
+ * we assume the BRG frequency is half the QE
+ * bus frequency.
+ */
+ prop = of_get_property(qe,
+ "bus-frequency", NULL);
+ of_node_put(qe);
+ if (!prop) {
+ printk(KERN_ERR "%s: "
+ " QE bus-frequency not present"
+ " in device tree\n",
+ __FUNCTION__);
+ ret = -EINVAL;
+ goto err;
+ }
+ if (*prop) {
+ brg_clk = *prop / 2;
+ return brg_clk;
+ } else {
+ printk(KERN_ERR "%s: invalid"
+ " QE bus-frequency in device"
+ " tree\n", __FUNCTION__);
+ ret = -EINVAL;
+ goto err;
+ }
+ }
+ } else {
+ printk(KERN_ERR "%s: no qe node in device tree"
+ "\n", __FUNCTION__);
+ ret = EINVAL;
+ goto err;
+ }
+ } else {
+ *brg_source = brg_src + QE_CLK1 - 1;
+ clocks = of_find_compatible_node(NULL, NULL,
+ "fsl,cpm-clocks");
+ if (!clocks) {
+ printk(KERN_ERR "%s: no clocks node in device"
+ " tree \n", __FUNCTION__);
+ ret = -EINVAL;
+ goto err;
+ } else {
+ prop = of_get_property(clocks,
+ "#clock-cells", &size);
+ /*
+ * clock-cells = 1 only supported right now.
+ */
+ if (!prop || *prop != 1) {
+ printk(KERN_ERR "%s: invalid "
+ "#clock-cells value in device tree \n",
+ __FUNCTION__);
+ of_node_put(clocks);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ prop = of_get_property(clocks,
+ "clock-frequency", &size);
+ if (!prop) {
+ printk(KERN_ERR "%s: no"
+ " #clock-frequency prop in device"
+ " tree\n", __FUNCTION__);
+ of_node_put(clocks);
+ ret = -EINVAL;
+ goto err;
+ }
+ brg_input_freq = *(prop+(brg_src - 1));
+ of_node_put(clocks);
+ return brg_input_freq;
+ }
+ }
+ } else {
+ printk(KERN_ERR "%s: no brg node in device tree\n",
+ __FUNCTION__);
+ ret = -EINVAL;
+ goto err;
+ }
+err: return ret;
+}
+
+u32 qe_brg_src(int brg_num, enum qe_clock brg_src)
+{
+ u32 clock_bits, shift;
+
+ clock_bits = 0;
+
+ switch (brg_num) {
+ case 1:
+ case 2:
+ case 5:
+ case 6:
+ switch (brg_src) {
+ case QE_CLK3: clock_bits = 1; break;
+ case QE_CLK5: clock_bits = 2; break;
+ default: break;
+ }
+ break;
+ case 3:
+ case 4:
+ case 7:
+ case 8:
+ switch (brg_src) {
+ case QE_CLK9: clock_bits = 1; break;
+ case QE_CLK15: clock_bits = 2; break;
+ default: break;
+ }
+ break;
+ case 9:
+ case 10:
+ switch (brg_src) {
+ case QE_CLK11: clock_bits = 1; break;
+ default: break;
+ }
+ break;
+ case 11:
+ case 15:
+ case 16:
+ switch (brg_src) {
+ case QE_CLK13: clock_bits = 1; break;
+ default: break;
+ }
+ break;
+ default: clock_bits = 0; break;
+ }
+ shift = 14;
+
+ if (!clock_bits)
+ return -ENOENT;
+
+ clock_bits <<= shift;
+
+ return clock_bits;
}
/* Program the BRG to the given sampling rate and multiplier
@@ -177,11 +346,18 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier)
{
u32 divisor, tempval;
u32 div16 = 0;
+ u32 brg_clock;
+ enum qe_clock brgsrc;
+ u32 src_bits = 0;
if ((brg < QE_BRG1) || (brg > QE_BRG16))
return -EINVAL;
- divisor = get_brg_clk() / (rate * multiplier);
+ brg_clock = get_brg_clk(brg, &brgsrc);
+ if (brg_clock < 0)
+ return -EINVAL;
+
+ divisor = brg_clock / (rate * multiplier);
if (divisor > QE_BRGC_DIVISOR_MAX + 1) {
div16 = QE_BRGC_DIV16;
@@ -194,8 +370,11 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier)
if (!div16 && (divisor & 1))
divisor++;
+ if (brgsrc > 0)
+ src_bits = qe_brg_src(brg - QE_BRG1 + 1, brgsrc);
+
tempval = ((divisor - 1) << QE_BRGC_DIVISOR_SHIFT) |
- QE_BRGC_ENABLE | div16;
+ QE_BRGC_ENABLE | div16 | src_bits;
out_be32(&qe_immr->brg.brgc[brg - QE_BRG1], tempval);
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 0e348d9..f2de0ed 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -213,3 +213,268 @@ int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
return 0;
}
+
+int ucc_set_tdm_rxtx_clk(int tdm_num, char *clk_src, enum comm_dir mode)
+{
+ enum qe_clock clock;
+ u32 clock_bits, shift;
+ struct qe_mux *qe_mux_reg = NULL;
+
+ clock_bits = 0;
+ qe_mux_reg = &qe_immr->qmx;
+
+ if ((tdm_num > 3 || tdm_num < 0))
+ return -EINVAL;
+
+ /* The communications direction must be RX or TX */
+ if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
+ return -EINVAL;
+
+ clock = qe_clock_source(clk_src);
+ switch (mode) {
+ case COMM_DIR_RX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK3: clock_bits = 6; break;
+ case QE_CLK8: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 28;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK5: clock_bits = 6; break;
+ case QE_CLK10: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 24;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK7: clock_bits = 6; break;
+ case QE_CLK12: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 20;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK9: clock_bits = 6; break;
+ case QE_CLK14: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 16;
+ break;
+ default:
+ break;
+ }
+ break;
+ case COMM_DIR_TX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK4: clock_bits = 6; break;
+ case QE_CLK9: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 12;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK6: clock_bits = 6; break;
+ case QE_CLK11: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 8;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK8: clock_bits = 6; break;
+ case QE_CLK13: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 4;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG3: clock_bits = 1; break;
+ case QE_BRG4: clock_bits = 2; break;
+ case QE_CLK1: clock_bits = 4; break;
+ case QE_CLK2: clock_bits = 5; break;
+ case QE_CLK10: clock_bits = 6; break;
+ case QE_CLK15: clock_bits = 7; break;
+ default: break;
+ }
+ shift = 0;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+
+ if (!clock_bits)
+ return -ENOENT;
+
+ clock_bits <<= shift;
+
+ qe_mux_reg->cmxsi1cr_l |= clock_bits;
+
+ return 0;
+}
+
+int ucc_set_tdm_rxtx_sync(int tdm_num, char *sync_src, enum comm_dir mode)
+{
+ enum qe_clock clock;
+ u32 shift, clock_bits;
+ struct qe_mux *qe_mux_reg = NULL;
+ int source;
+
+ source = -1;
+ qe_mux_reg = &qe_immr->qmx;
+
+ if ((tdm_num > 3 || tdm_num < 0))
+ return -EINVAL;
+
+ /* The communications direction must be RX or TX */
+ if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
+ return -EINVAL;
+
+ switch (mode) {
+ case COMM_DIR_RX:
+ if (strcasecmp("RSYNC", sync_src) == 0) {
+ source = 0;
+ shift = 0;
+ break;
+ }
+ clock = qe_clock_source(sync_src);
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG10: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 30;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG10: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 28;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG11: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 26;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG11: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 24;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ break;
+ case COMM_DIR_TX:
+ if (strcasecmp("TSYNC", sync_src) == 0) {
+ source = 0;
+ shift = 0;
+ break;
+ }
+ clock = qe_clock_source(sync_src);
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG10: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 14;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG10: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 12;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG11: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 10;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG9: source = 1; break;
+ case QE_BRG11: source = 2; break;
+ default: source = -1; break;
+ }
+ shift = 8;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ break;
+ default:
+ source = -1;
+ break;
+ }
+
+ if (source == -1)
+ return -ENOENT;
+
+ clock_bits = (u32) source;
+ clock_bits <<= shift;
+
+
+ qe_mux_reg->cmxsi1syr |= clock_bits;
+
+ return 0;
+}
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 3223acb..9c8559f 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -327,6 +327,43 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
ucc_fast_free(uccf);
return -EINVAL;
}
+ } else {
+ /* TDM Rx clock routing */
+ if ((uf_info->tdm_rx_clk != NULL) &&
+ ucc_set_tdm_rxtx_clk(uf_info->ucc_num,
+ uf_info->tdm_rx_clk, COMM_DIR_RX)) {
+ printk(KERN_ERR "%s: illegal value for TDM RX clock",
+ __FUNCTION__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+ /* TDM Tx clock routing */
+ if ((uf_info->tdm_tx_clk != NULL) &&
+ ucc_set_tdm_rxtx_clk(uf_info->ucc_num,
+ uf_info->tdm_tx_clk, COMM_DIR_TX)) {
+ printk(KERN_ERR "%s: illegal value for TDM TX clock",
+ __FUNCTION__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+ /* TDM Rx sync routing */
+ if ((uf_info->tdm_rx_sync != NULL) &&
+ ucc_set_tdm_rxtx_sync(uf_info->ucc_num,
+ uf_info->tdm_rx_sync, COMM_DIR_RX)) {
+ printk(KERN_ERR "%s: illegal value for TDM RX"
+ "Frame sync", __FUNCTION__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+ /* TDM Tx sync routing */
+ if ((uf_info->tdm_tx_sync != NULL) &&
+ ucc_set_tdm_rxtx_sync(uf_info->ucc_num,
+ uf_info->tdm_tx_sync, COMM_DIR_TX)) {
+ printk(KERN_ERR "%s: illegal value for TDM TX"
+ "Frame sync", __FUNCTION__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
}
/* Set interrupt mask register at UCC level. */
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index bcf60be..51de236 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -497,6 +497,14 @@ struct ucc_slow_pram {
#define UCC_GETH_UCCE_RXF1 0x00000002
#define UCC_GETH_UCCE_RXF0 0x00000001
+/* Transparent UCC Event Register (UCCE) */
+#define UCC_TRANS_UCCE_GRA 0x0080
+#define UCC_TRANS_UCCE_TXE 0x0010
+#define UCC_TRANS_UCCE_RXF 0x0008
+#define UCC_TRANS_UCCE_BSY 0x0004
+#define UCC_TRANS_UCCE_TXB 0x0002
+#define UCC_TRANS_UCCE_RXB 0x0001
+
/* UPSMR, when used as a UART */
#define UCC_UART_UPSMR_FLC 0x8000
#define UCC_UART_UPSMR_SL 0x4000
diff --git a/include/asm-powerpc/ucc.h b/include/asm-powerpc/ucc.h
index 46b09ba..153db97 100644
--- a/include/asm-powerpc/ucc.h
+++ b/include/asm-powerpc/ucc.h
@@ -42,6 +42,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num);
int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
enum comm_dir mode);
+int ucc_set_tdm_rxtx_clk(int tdm_num, char *clk_src, enum comm_dir mode);
+
+int ucc_set_tdm_rxtx_sync(int tdm_num, char *clk_src, enum comm_dir mode);
+
int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int set, u32 mask);
/* QE MUX clock routing for UCC
diff --git a/include/asm-powerpc/ucc_fast.h b/include/asm-powerpc/ucc_fast.h
index f529f70..d267983 100644
--- a/include/asm-powerpc/ucc_fast.h
+++ b/include/asm-powerpc/ucc_fast.h
@@ -152,6 +152,10 @@ struct ucc_fast_info {
enum ucc_fast_rx_decoding_method renc;
enum ucc_fast_transparent_tcrc tcrc;
enum ucc_fast_sync_len synl;
+ char *tdm_rx_clk;
+ char *tdm_tx_clk;
+ char *tdm_rx_sync;
+ char *tdm_tx_sync;
};
struct ucc_fast_private {
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH] Fix sleep on powerbook 3400
From: Johannes Berg @ 2007-12-18 11:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18277.49950.354034.86146@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
> Sleep on the powerbook 3400 has been broken since the change that made
> powerbook_sleep_3400 call pmac_suspend_devices(), which disables
> interrupts. There are a couple of loops in powerbook_sleep_3400 that
> depend on interrupts being enabled, and in fact it has to have
> interrupts enabled at the point of going to sleep since it is an
> interrupt from the PMU that wakes it up.
Do you want me to rebase my patches on top of this?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Raising list size limit
From: Josh Boyer @ 2007-12-18 12:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20071218143627.94f76142.sfr@canb.auug.org.au>
On Tue, 18 Dec 2007 14:36:27 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi,
>
> I am considering raising the limit on the size of postings to 400k. Does
> anyone have a real problem with this? Limiting message size was done to
> limit the damage of larges spams (and we don;t get very many of those on
> the list) and to ease the pain for people downloading emails over a slow
> (like dialup) link (and are there many of those left?).
Fine by me!
josh
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Juergen Beisert @ 2007-12-18 10:41 UTC (permalink / raw)
To: Arnon Kaufman; +Cc: linuxppc-dev
In-Reply-To: <47656048.7060809@gmail.com>
On Sunday 16 December 2007 18:28, Arnon Kaufman wrote:
> Robert Schwebel wrote:
>> On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
>>> does any one succeed running a functional FEC and ATA (pata) running
>>> together?
>>
>> Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
>> http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-ti=
ny/
>
> thanks, my kernels are already patched and still observing that kind of
> behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2.
I tried our kernel (see link above) with an external harddisk and NFS. I=20
copied various files from the harddisk to NFS root and vice versa. No data=
=20
corruption.
Can you check our patch stack on your hardware?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
From: Jochen Friedrich @ 2007-12-18 10:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, linuxppc-dev
In-Reply-To: <4767042E.2070903@garzik.org>
Hi Jeff,
> ACK, pass this through paulus?
Yes, that's fine for me.
Thanks,
Jochen
^ permalink raw reply
* Re: USB configuration
From: Misbah khan @ 2007-12-18 9:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071217213341.630cbdf5@kernel.crashing.org>
hi ...
The montavista version we are using is " 2.6.10_mvl401-8272ads "
Montavista people says that they are supporting USB host interface ....
but still why i am facing the problem ????
Yes i have enabled generic support but i guess its fine ....
----Misbah <><
Vitaly Bordug-2 wrote:
>
> On Thu, 6 Dec 2007 05:27:14 -0800 (PST)
> Misbah khan wrote:
>
>>
>> HI all ...
>> I have configured the Montavista Kernel for USB support and for
>> PPC8272-ADS board I need to know that how could i test that my USB is
>> working ????
>>
>
> I'm not sure what MV version you are trying to use, but there is no
> support for USB host(I am about 8272ads).
> MV supports USB gadget though...
>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>> file under it ????
>>
> you enabled generic usb support. But no HW/driver picking it up
>>
>> its also creating the directory :- /sys/bus/usb/ but doesent
>> contain any file under it ????
>>
> same reason
>>
>> Please let me know the procedure to test whether my USB configuration
>> is all right ????
>>
> First, if you want to use USB host, you'll have to develop the driver
> first or assist someone doing that (there yet another such attempt
> recently initiated - see linuxppc-dev logs)
>
>> Thank u
>> Misbah <><
>
>
> --
> Sincerely, Vitaly
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/USB-configuration-tp14192347p14389002.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: USB configuration
From: Misbah khan @ 2007-12-18 9:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4766940E.4090801@freescale.com>
I have configured MPC82xx USB controler
the debug msg is this " g_file_storage gadget: controller 'mpc8272_udc' not
recognized "
Is this the problem ?????
USB Led is also not glowing where in all the other configurations are
registered success ....viz
/----------------------------------------------------------------------------------------------------
7:255.255.248.0:cashel:eth1:off
PID hash table entries: 512 (order: 9, 8192 bytes)
hr_time_init: arch_to_nsec = 83886080, nsec_to_arch = 107374182
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 62208k available (1952k kernel code, 588k data, 108k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
mpc8272ads: Init
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 1 of device 0000:00:00.0
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a60 (irq = 43) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
fs_enet.c:v1.0 (Aug 8, 2005)
fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
st: Version 20041025, fixed bufsize 32768, s/g segs 256
osst :I: Tape driver with OnStream support version 0.99.1
osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
USB Universal Host Controller Interface driver v2.2
sl811: driver sl811-hcd, 06 Dec 2004
usbcore: registered new driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB
modems and ISDN adapters
drivers/usb/class/bluetty.c: USB Bluetooth support registered
usbcore: registered new driver bluetty
drivers/usb/class/bluetty.c: USB Bluetooth tty driver v0.13
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
MPC8272 USB peripheral device
g_file_storage gadget: controller 'mpc8272_udc' not recognized
g_file_storage gadget: no file given for LUN0
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
device=eth1, addr=192.168.33.136, mask=255.255.248.0,
gw=192.168.32.47,
host=cashel, domain=, nis-domain=(none),
bootserver=192.168.33.96, rootserver=192.168.33.96, rootpath=
Looking up port of RPC 100003/2 on 192.168.33.96
Looking up port of RPC 100005/1 on 192.168.33.96
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 108k init
INIT: version 2.85 booting
Setting up IP spoofing protection: rp_filter.
Disable TCP/IP Explicit Congestion Notification: done.
Starting network interfaces: /sbin/ifup: interface lo already configured
done.
Starting portmap daemon: portmap.
INIT: Entering runlevel: 3
Starting internet superserver: inetd.
MontaVista(R) Linux(R) Professional Edition 4.0.1 (0502020)
----------------------------------------------------------------------------------------------------/
--------Misbah<><
Scott Wood-2 wrote:
>
> Misbah khan wrote:
>> I have configured for mass storage device still i am not getting the
>> debug
>> msg that the kernel has detected the pen drive (after i connect the pen
>> drive ).
>>
>> " Initializing USB Mass Storage driver...
>> usbcore: registered new driver usb-storage
>> USB Mass Storage support registered.
>> "
>
> Did you get any output indicating that the USB controller was found and
> initialized? This *is* a PCI-based OHCI controller you're trying to
> use, and not the CPM USB, right? Do other PCI devices work?
>
> -Scott
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/USB-configuration-tp14192347p14387839.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* How about the I2S audio driver for arch/powerpc within MPC5200B
From: TomX @ 2007-12-18 9:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi, all:
I am now using the sound/ppc/mpc52xx_aic26.c from snapshot of denx. And with
this, need use the arch/ppc, not the arch/powerpc. Is somebody have finished
change this files to arch/poweprc. I have try, but it seems a lot work
needed and must familar with arch/powerpc.
Many thanks,
Best Regards,
Tao
--
View this message in context: http://www.nabble.com/How-about-the-I2S-audio-driver-for-arch-powerpc-within-MPC5200B-tp14387041p14387041.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox