* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 18:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Vivek Mahajan
In-Reply-To: <20091119174546.GB6845@b07421-ec1.am.freescale.net>
On Nov 19, 2009, at 11:45 AM, Scott Wood wrote:
> On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
>>>> +config FSL_85XX_CACHE_SRAM_BASE
>>>> + hex
>>>> + depends on FSL_85XX_CACHE_SRAM
>>>> + default "0xfff00000"
>>>> +
>>>
>>> I really don't like setting the physical address this way, can we
>>> not do this via the device tree?
>>
>> At a high level I think we should add something like the following in
>> the .dts:
>>
>> sram@fff00000 {
>> fsl,sram-ctrl-handle = <&L2>;
>> reg = <0xfff00000 0xNNNN>;
>> compatible = "fsl,mpc85xx-l2-sram";
>> }
>>
>> the NNNN can be the size the sram is configured as.
>
> I don't see why this needs to go in the device tree, if it's the
> kernel
> that is setting it up. The kernel can pick any address and size it
> wants.
It can, we just don't normally do physical address allocation in the
kernel. I just dont want it as a compile time thing. Either .dts or
make it runtime allocated by the kernel.
- k
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: John Linn @ 2009-11-19 17:36 UTC (permalink / raw)
To: Stephen Neuendorffer, Alon Ziv, Arnd Bergmann, linuxppc-dev
In-Reply-To: <977C41F842E66D4CB2E41332313B615008FC3C2F@XSJ-EXCHVS1.xlnx.xilinx.com>
NAK also.
Yes we can generate a different device tree to fix this issue.
Thanks,
John
> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Thursday, November 19, 2009 10:23 AM
> To: Alon Ziv; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: John Linn; grant.likely@secretlab.ca
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> =
> NAK.
> =
> If the problem is in the device trees that are being generated, we
should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
> the IP changes so often.
> =
> Steve
> =
> > -----Original Message-----
> > From:
linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> > bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of
Alon Ziv
> > Sent: Thursday, November 19, 2009 5:49 AM
> > To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: Bug in drivers/serial/of_serial.c?
> >
> > On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > > I'd still add support for the compatible=3D"ns16550a" property
> > > so that we do the right thing for future systems.
> > >
> >
> > OK...
> > ---
> > Xilinx 16550 UART is actually 16550A-compatible
> >
> > Signed-off-by: Alon Ziv <alonz@discretix.com>
> >
> > diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> > index 02406ba..241be77 100644
> > --- a/drivers/serial/of_serial.c
> > +++ b/drivers/serial/of_serial.c
> > @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> > of_device *ofdev)
> > static struct of_device_id __devinitdata of_platform_serial_table[]
=3D {
> > { .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
> > *)PORT_8250, },
> > { .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
> > *)PORT_16450, },
> > + { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
> > .data =3D (void *)PORT_16550A, },
> > { .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
> > *)PORT_16550, },
> > + { .type =3D "serial", .compatible =3D "ns16550a", .data =3D (void
> > *)PORT_16550A, },
> > { .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
> > *)PORT_16750, },
> > { .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
> > *)PORT_16850, },
> > #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
> >
************************************************************************
**********************
> > IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for
> the
> > named recipient(s) only.
> > If you have received this email in error, please notify the system
manager or the sender
> immediately
> > and do
> > not disclose the contents to anyone or make copies thereof.
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
From: Stephen Neuendorffer @ 2009-11-19 17:32 UTC (permalink / raw)
To: Alon Ziv, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE38@Exchange.discretix.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:57 AM
> To: Stephen Neuendorffer; linuxppc-dev
> Cc: John Linn
> Subject: RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
> =
> Hi,
> =
> On Monday, November 16, 2009, Stephen wrote:
> > There are at least two other ways that you might be able to reset a
> > board:
> > 1) Internally through the ICAP device.
> > 2) Through a GPIO connected externally to the reset logic.
> >
> =
> Unfortunately none of these is relevant for the specific board in
> question (Xilinx ML510 reference system)...
Well, board !=3D system. :) ML510 could easily include an ICAP device.
> > Probably it would be best to have a mechanism in the device tree
which
> > references the reset mechanism?
> =
> I am sorely lacking in expertise for this :(, and wouldn't even know
> where to begin... Is it possible at all to add custom information
into
> the device tree? And even if yes--how will platform code bind to the
> reset mechanism?
> =
> > [...] In any event, you probably don't want a driver to
> > eplicitly reference the plaform code. If you want to do it
explicitly
> > like this, it would better to have the plaform code reference the
> driver
> > mechanism.
> =
> I don't see how this can be done: if the driver is to publish some
> "driver_reset_system" function to the platform code, it needs _some_
> mechanism for telling this fact to the system...
Think of it this way: The driver is usable on many more platforms than
just
the one you've modified. Your addition of the hook into the platform
code
requires that that hook always be there. It would be much better to
provide a configuration-based way of allowing the platform code to
make use of the sysace reset, if it desires.
> And such a mechanism
> won't look all that different from my callback, IMO (except it may be
> slightly prettied up).
The callback isn't the problem, it's how the callback gets registered
with
the platform code/device tree.
> Of course, one obvious thing that must be done is move this code out
of
> arch/powerpc/platforms/44x/virtex.c and into (e.g.)
> arch/powerpc/kernel/setup-common.c, and add some
> "set_machine_restart_function" wrapper to access it more cleanly (also
> defining this function as a null function when inapplicable). If this
> satisfies your standards, I can easily post an updated patch :)
The driver isn't even powerpc specific, it could also be used on the
microblaze,
and I think you'll find alot of resistance to adding that kind of hook
to an architecture
that has just spent a bunch of time getting rid of alot of direct
binding between
platform code and drivers. Grant, do you have a comment here?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Scott Wood @ 2009-11-19 17:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Kumar Gala, Vivek Mahajan
In-Reply-To: <2B43D645-7977-4C24-A3EF-C55A392228B4@kernel.crashing.org>
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
> >>+config FSL_85XX_CACHE_SRAM_BASE
> >>+ hex
> >>+ depends on FSL_85XX_CACHE_SRAM
> >>+ default "0xfff00000"
> >>+
> >
> >I really don't like setting the physical address this way, can we
> >not do this via the device tree?
>
> At a high level I think we should add something like the following in
> the .dts:
>
> sram@fff00000 {
> fsl,sram-ctrl-handle = <&L2>;
> reg = <0xfff00000 0xNNNN>;
> compatible = "fsl,mpc85xx-l2-sram";
> }
>
> the NNNN can be the size the sram is configured as.
I don't see why this needs to go in the device tree, if it's the kernel
that is setting it up. The kernel can pick any address and size it
wants.
-Scott
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: John Linn, Alon Ziv, linuxppc-dev
In-Reply-To: <200911191833.08254.arnd@arndb.de>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Arnd
Bergmann
> Sent: Thursday, November 19, 2009 9:33 AM
> To: Stephen Neuendorffer
> Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Bug in drivers/serial/of_serial.c?
> =
> On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> > If the problem is in the device trees that are being generated, we
> > should fix the issue there.
> > We've been trying to avoid putting the fully specified IP versions
in
> > the kernel like this, since
> > the IP changes so often.
> =
> No, the problem that Alon has is that the firmware currently has no
> way whatsoever to give a correct device tree, because of-serial.c
> does not even know about ns16550a.
> =
> The patch adds both a special-case for the specific uart he
> is using so that one is grandfathered in and a new compatible
> value so future boards can specify both ns16550a and ns16550.
That's true... The 16550a line still needs to get added, but not the
xlnx-
specific line.
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: watchdog exception on 8548CDS during cpu_idle
From: Scott Wood @ 2009-11-19 17:37 UTC (permalink / raw)
To: Ming Lei; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <7301F255FCB62048851F165FFAAF9BD106E9B3F0E5@HQ-EXCH-7.corp.brocade.com>
On Wed, Nov 18, 2009 at 03:53:27PM -0800, Ming Lei wrote:
>
> I used the vanilla linux 2.6.30 and compiled with mpc85xx_defconfig(enable CONFIG_BOOK_WDT) and then ran on 8548CDS and soon after I saw the prompt I hit this watchdog.
>
> bash-2.04# PowerPC Book-E Watchdog Exception
> NIP: c000b740 LR: c00088dc CTR: c000b6b0
> REGS: cfffbf10 TRAP: 3202 Not tainted (2.6.30)
> MSR: 00029000 <EE,ME,CE> CR: 28028048 XER: 20000000
> TASK = c04f4458[0] 'swapper' THREAD: c052c000
> GPR00: c000b6b0 c052df90 c04f4458 00800000 80804080 0000001d c053af48 00069000
> GPR08: ffffffff 00000000 08954400 00000000 002167ee 7f652f31 0ffad800 0fff0000
> GPR16: 00000000 00000000 00000000 00000000 00000000 f30a620b 0ff50450 00000000
> GPR24: 00000000 00000000 c053506c c0534fa0 c0534fa0 c052c034 00000008 c052c000
> NIP [c000b740] e500_idle+0x90/0x94
> LR [c00088dc] cpu_idle+0x98/0xec
> Call Trace:
> [c052df90] [c000889c] cpu_idle+0x58/0xec (unreliable)
> [c052dfb0] [c00023ec] rest_init+0x5c/0x70
> [c052dfc0] [c04c16f4] start_kernel+0x22c/0x290
> [c052dff0] [c0000398] skpinv+0x2b0/0x2ec
> Instruction dump:
> 7c90faa6 548402ce 7c841b78 4c00012c 7c90fba6 4c00012c 7ce000a6 64e70004
> 60e78000 7c0004ac 7ce00124 4c00012c <48000000> 812b00a0 912b0090 39600000
>
> Have anyone seen this before? Why the EE bit is on in the stack trace?
> I put show_regs in watchdog exception handler in traps.c. I verified
> that EE is off when entering the watchdog exception handler. Can I
> trust this stack trace?
EE is there because it was set in the context that got interrupted, just
as all the other state is for the interrupted context.
-Scott
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 17:33 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, Alon Ziv, linuxppc-dev
In-Reply-To: <c2bc536b-3765-4ead-b942-88bb25253ad3@VA3EHSMHS013.ehs.local>
On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> If the problem is in the device trees that are being generated, we
> should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
> the kernel like this, since
> the IP changes so often.
No, the problem that Alon has is that the firmware currently has no
way whatsoever to give a correct device tree, because of-serial.c
does not even know about ns16550a.
The patch adds both a special-case for the specific uart he
is using so that one is grandfathered in and a new compatible
value so future boards can specify both ns16550a and ns16550.
Arnd <><
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:22 UTC (permalink / raw)
To: Alon Ziv, Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE47@Exchange.discretix.com>
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 5:49 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > I'd still add support for the compatible=3D"ns16550a" property
> > so that we do the right thing for future systems.
> >
> =
> OK...
> ---
> Xilinx 16550 UART is actually 16550A-compatible
> =
> Signed-off-by: Alon Ziv <alonz@discretix.com>
> =
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 02406ba..241be77 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> of_device *ofdev)
> static struct of_device_id __devinitdata of_platform_serial_table[] =3D
{
> { .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
> *)PORT_8250, },
> { .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
> *)PORT_16450, },
> + { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
> .data =3D (void *)PORT_16550A, },
> { .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
> *)PORT_16550, },
> + { .type =3D "serial", .compatible =3D "ns16550a", .data =3D (void
> *)PORT_16550A, },
> { .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
> *)PORT_16750, },
> { .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
> *)PORT_16850, },
> #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
>
************************************************************************
**********************
> IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for the
> named recipient(s) only.
> If you have received this email in error, please notify the system
manager or the sender immediately
> and do
> not disclose the contents to anyone or make copies thereof.
> =
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:20 UTC (permalink / raw)
To: Alon Ziv, Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE31@Exchange.discretix.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:47 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> Hi,
> =
> On Monday, November 16, 2009, Arnd wrote:
> > > - { .type =3D "serial", .compatible =3D "ns16550", .data =3D
(void
> *)PORT_16550, },
> > > + { .type =3D "serial", .compatible =3D "ns16550", .data =3D
(void
> *)PORT_16550A, },
> >
> > Does not seem logical. If the device claims compatibility with
> ns16550, we should
> > not automatically assume it's an ns16550a. Why not add another line
> for
> >
> =
> Unfortunately, there is no way to change what the device claims--it's
> encoded into the OpenFirmware tree by the EDK tools.
> And, in any case, the device is actually not lying: it _is_ compatible
> with NS16550--just with a non-buggy one. Unfortunately the kernel
> driver for 8250-class UARTs makes the conservative choice to assume
any
> 16550 is one of the (early, buggy) revisions where the FIFO was
> non-functional; any 16550 with working UART is classed as a 16550A.
Definitely changing what is generated by EDK seems to make sense here...
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 16:08 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4B056158.5060104@embedded-sol.com>
Hi,
The problem goes away if I remove the call to
tg3_set_power_state(tp, PCI_D3hot);
from tg3_close().
Some relevant stuff from dmesg:
pci 0002:05:00.0: PME# supported from D3hot D3cold
pci 0002:05:00.0: PME# disabled
tg3.c:v3.102 (September 1, 2009)
tg3 0002:05:00.0: enabling device (0000 -> 0002)
tg3 0002:05:00.0: PME# disabled
tg3 mdio bus: probed
eth2: Tigon3 [partno(BCM57760) rev 57780001] (PCI Express) MAC address
00:10:18:00:00:00
eth2: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=500:01)
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth2: dma_rwctrl[76180000] dma_mask[64-bit]
Is my problem related to hardware or it's a tg3 driver bug ?
Thanks a lot.
Felix.
Felix Radensky wrote:
> Hi,
>
> I have a problem with tg3 driver on a custom MPC8536 based board
> running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
> linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
>
> The problem I'm seeing is that the downing and interface leads to
> permanent link loss, even after interface is upped again. E.g, to
> reproduce the problem it is sufficient to run:
>
> modprobe tg3
> ifconfig eth2 up
> ifconfig eth2 down
> ifconfig eth2 up
>
> After ifdown PHY LEDs also go down and do not come back
> after ifup. Ethtool reports that no link is detected. After reloading
> the driver the link comes back.
>
> Am I the only one seeing this problem ?
> Any help on fixing this is appreciated.
>
> Thanks a lot.
>
> Felix.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Greg KH @ 2009-11-19 16:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Alon Ziv, linuxppc-dev, linux-serial
In-Reply-To: <200911191509.31270.arnd@arndb.de>
On Thu, Nov 19, 2009 at 03:09:31PM +0100, Arnd Bergmann wrote:
> On Thursday 19 November 2009, Alon Ziv wrote:
> > On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > > I'd still add support for the compatible="ns16550a" property
> > > so that we do the right thing for future systems.
> > >
> >
> > OK...
> > ---
> > Xilinx 16550 UART is actually 16550A-compatible
> >
> > Signed-off-by: Alon Ziv <alonz@discretix.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Does this go through the powerpc or the tty tree?
> I'd be happy if either Ben or Greg could pick this up.
>
> I'm happy to keep maintaining the driver itself but it
> would be nice to know a definite subsystem maintainer
> responsible for it.
>
> Greg, if you want to take patches for of_serial.c generally,
> I'll start forwarding them to you as they come in and make
> sure they apply to your tree.
Sure, I would be glad to do so, send them on.
thanks,
greg k-h
^ permalink raw reply
* tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 15:16 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Hi,
I have a problem with tg3 driver on a custom MPC8536 based board
running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
The problem I'm seeing is that the downing and interface leads to
permanent link loss, even after interface is upped again. E.g, to
reproduce the problem it is sufficient to run:
modprobe tg3
ifconfig eth2 up
ifconfig eth2 down
ifconfig eth2 up
After ifdown PHY LEDs also go down and do not come back
after ifup. Ethtool reports that no link is detected. After reloading
the driver the link comes back.
Am I the only one seeing this problem ?
Any help on fixing this is appreciated.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Kumar Gala @ 2009-11-19 14:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20091119144558.GQ30489@zod.rchland.ibm.com>
On Nov 19, 2009, at 8:45 AM, Josh Boyer wrote:
> On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
>> Hi Ben,
>>
>> Please pull the next branch of the 4xx tree to get the following
>> commits.
>>
>> I have some other things in the middle of being worked that may or
>> may not
>> make it in time for the next release, so I wanted to get these
>> commits into
>> your tree now rather than wait.
>
> Erm... ping? I see you've updated your next branch but not pulled
> this
> still...
Also my next branch.
- k
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2009-11-19 14:45 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20091104185519.GI31934@zod.rchland.ibm.com>
On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
>Hi Ben,
>
>Please pull the next branch of the 4xx tree to get the following commits.
>
>I have some other things in the middle of being worked that may or may not
>make it in time for the next release, so I wanted to get these commits into
>your tree now rather than wait.
Erm... ping? I see you've updated your next branch but not pulled this
still...
josh
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 14:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Vivek Mahajan
In-Reply-To: <181208B7-AC0B-4634-A04E-46468D376719@freescale.com>
On Nov 19, 2009, at 8:21 AM, Kumar Gala wrote:
>> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
>> platforms/85xx/Kconfig
>> index d3a975e..b6f23c3 100644
>> --- a/arch/powerpc/platforms/85xx/Kconfig
>> +++ b/arch/powerpc/platforms/85xx/Kconfig
>> @@ -144,6 +144,15 @@ config SBC8560
>> help
>> This option enables support for the Wind River SBC8560 board
>>
>> +config FSL_85XX_CACHE_SRAM
>> + bool
>> + select PPC_LIB_RHEAP
>> +
>> +config FSL_85XX_CACHE_SRAM_BASE
>> + hex
>> + depends on FSL_85XX_CACHE_SRAM
>> + default "0xfff00000"
>> +
>
> I really don't like setting the physical address this way, can we
> not do this via the device tree?
At a high level I think we should add something like the following in
the .dts:
sram@fff00000 {
fsl,sram-ctrl-handle = <&L2>;
reg = <0xfff00000 0xNNNN>;
compatible = "fsl,mpc85xx-l2-sram";
}
the NNNN can be the size the sram is configured as.
- k
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 14:21 UTC (permalink / raw)
To: Vivek Mahajan; +Cc: linuxppc-dev
In-Reply-To: <1256129459-10685-3-git-send-email-vivek.mahajan@freescale.com>
On Oct 21, 2009, at 7:50 AM, Vivek Mahajan wrote:
> This adds QorIQ based Cache-SRAM support as under:-
>
> * A small abstraction over powerpc's remote heap allocator
> * Exports mpc85xx_cache_sram_alloc()/free() APIs
> * Supports only one contiguous SRAM window
> * Defines FSL_85XX_CACHE_SRAM and its base address
>
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> ---
> v2: mbar(1) -> eieio() as per Kumar G.
> v3: Fixed cache-sram ways computation
>
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++++++
> arch/powerpc/platforms/85xx/Kconfig | 9 ++
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95 ++++++++++++
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 141 +++++++++++++++
> +++
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 184 +++++++++++++++
> +++++++++
> 6 files changed, 478 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
>
> diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/
> powerpc/include/asm/fsl_85xx_cache_sram.h
> new file mode 100644
> index 0000000..2af2bdc
> --- /dev/null
> +++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * Cache SRAM handling for QorIQ platform
should say PQ3 & some QorIQ platforms
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> +
> + * This file is derived from the original work done
> + * by Sylvain Munaut for the Bestcomm SRAM allocator.
> + *
> + * 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.
> + */
> +
> +#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
> +#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
> +
> +#include <asm/rheap.h>
> +#include <linux/spinlock.h>
> +
> +/*
> + * Cache-SRAM
> + */
> +
> +struct mpc85xx_cache_sram {
> + phys_addr_t base_phys;
> + void *base_virt;
> + unsigned int size;
> + rh_info_t *rh;
> + spinlock_t lock;
> +};
> +
> +extern void mpc85xx_cache_sram_free(void *ptr);
> +extern void *mpc85xx_cache_sram_alloc(unsigned int size,
> + phys_addr_t *phys, unsigned int align);
> +
> +#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
> platforms/85xx/Kconfig
> index d3a975e..b6f23c3 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -144,6 +144,15 @@ config SBC8560
> help
> This option enables support for the Wind River SBC8560 board
>
> +config FSL_85XX_CACHE_SRAM
> + bool
> + select PPC_LIB_RHEAP
> +
> +config FSL_85XX_CACHE_SRAM_BASE
> + hex
> + depends on FSL_85XX_CACHE_SRAM
> + default "0xfff00000"
> +
I really don't like setting the physical address this way, can we not
do this via the device tree?
> endif # MPC85xx
>
> config TQM85xx
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
> Makefile
> index 9d4b174..745994c 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
> obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
> obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
> obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
> +obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
> fsl_85xx_cache_sram.o
> obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
> obj-$(CONFIG_RAPIDIO) += fsl_rio.o
> obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/
> powerpc/sysdev/fsl_85xx_cache_ctlr.h
> new file mode 100644
> index 0000000..8c4a4ac
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc
> + *
> + * QorIQ based Cache Controller Memory Mapped Registers
PQ3 or some QorIQ
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * 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.
> + */
> +
> +#ifndef __FSL_85XX_CACHE_CTLR_H__
> +#define __FSL_85XX_CACHE_CTLR_H__
> +
> +#define L2CR_L2FI 0x40000000 /* L2 flash invalidate */
> +#define L2CR_L2IO 0x00200000 /* L2 instruction only */
> +#define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */
> +#define L2CR_SRAM_FULL 0x00010000 /* L2SRAM full size */
> +#define L2CR_SRAM_HALF 0x00020000 /* L2SRAM half size */
> +#define L2CR_SRAM_TWO_HALFS 0x00030000 /* L2SRAM two half sizes */
> +#define L2CR_SRAM_QUART 0x00040000 /* L2SRAM one quarter size */
> +#define L2CR_SRAM_TWO_QUARTS 0x00050000 /* L2SRAM two quarter size */
> +#define L2CR_SRAM_EIGHTH 0x00060000 /* L2SRAM one eighth size */
> +#define L2CR_SRAM_TWO_EIGHTH 0x00070000 /* L2SRAM two eighth size */
> +
> +#define L2SRAM_OPTIMAL_SZ_SHIFT 0x00000003 /* Optimum size for
> L2SRAM */
> +
> +#define L2SRAM_BAR_MSK_LO18 0xFFFFC000 /* Lower 18 bits */
> +#define L2SRAM_BARE_MSK_HI4 0x0000000F /* Upper 4 bits */
> +
> +enum cache_sram_lock_ways {
> + LOCK_WAYS_ZERO,
> + LOCK_WAYS_EIGHTH,
> + LOCK_WAYS_TWO_EIGHTH,
> + LOCK_WAYS_HALF = 4,
> + LOCK_WAYS_FULL = 8,
> +};
> +
> +struct mpc85xx_l2ctlr {
> + u32 ctl; /* 0x000 - L2 control */
> + u8 res1[0xC];
> + u32 ewar0; /* 0x010 - External write address 0 */
> + u32 ewarea0; /* 0x014 - External write address extended 0 */
> + u32 ewcr0; /* 0x018 - External write ctrl */
> + u8 res2[4];
> + u32 ewar1; /* 0x020 - External write address 1 */
> + u32 ewarea1; /* 0x024 - External write address extended 1 */
> + u32 ewcr1; /* 0x028 - External write ctrl 1 */
> + u8 res3[4];
> + u32 ewar2; /* 0x030 - External write address 2 */
> + u32 ewarea2; /* 0x034 - External write address extended 2 */
> + u32 ewcr2; /* 0x038 - External write ctrl 2 */
> + u8 res4[4];
> + u32 ewar3; /* 0x040 - External write address 3 */
> + u32 ewarea3; /* 0x044 - External write address extended 3 */
> + u32 ewcr3; /* 0x048 - External write ctrl 3 */
> + u8 res5[0xB4];
> + u32 srbar0; /* 0x100 - SRAM base address 0 */
> + u32 srbarea0; /* 0x104 - SRAM base addr reg ext address 0 */
> + u32 srbar1; /* 0x108 - SRAM base address 1 */
> + u32 srbarea1; /* 0x10C - SRAM base addr reg ext address 1 */
> + u8 res6[0xCF0];
> + u32 errinjhi; /* 0xE00 - Error injection mask high */
> + u32 errinjlo; /* 0xE04 - Error injection mask low */
> + u32 errinjctl; /* 0xE08 - Error injection tag/ecc control */
> + u8 res7[0x14];
> + u32 captdatahi; /* 0xE20 - Error data high capture */
> + u32 captdatalo; /* 0xE24 - Error data low capture */
> + u32 captecc; /* 0xE28 - Error syndrome */
> + u8 res8[0x14];
> + u32 errdet; /* 0xE40 - Error detect */
> + u32 errdis; /* 0xE44 - Error disable */
> + u32 errinten; /* 0xE48 - Error interrupt enable */
> + u32 errattr; /* 0xE4c - Error attribute capture */
> + u32 erradrrl; /* 0xE50 - Error address capture low */
> + u32 erradrrh; /* 0xE54 - Error address capture high */
> + u32 errctl; /* 0xE58 - Error control */
> + u8 res9[0x1A4];
> +};
> +
> +extern int instantiate_cache_sram(struct of_device *dev, unsigned
> int size);
> +extern void remove_cache_sram(struct of_device *dev);
> +
> +#endif /* __FSL_85XX_CACHE_CTLR_H__ */
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/
> powerpc/sysdev/fsl_85xx_cache_sram.c
> new file mode 100644
> index 0000000..6744083
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * Simple memory allocator abstraction for QorIQ (P1/P2) based
> Cache-SRAM
PQ3 or some QorIQ
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * This file is derived from the original work done
> + * by Sylvain Munaut for the Bestcomm SRAM allocator.
> + *
> + * 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <asm/pgtable.h>
> +#include <asm/fsl_85xx_cache_sram.h>
> +
> +struct mpc85xx_cache_sram *cache_sram;
> +
> +void *mpc85xx_cache_sram_alloc(unsigned int size,
> + phys_addr_t *phys, unsigned int align)
> +{
> + unsigned long offset;
> + unsigned long flags;
> +
> + if (!size || (size > cache_sram->size) || (align > cache_sram-
> >size)) {
> + pr_err("%s(): size(=%x) or align(=%x) zero or too big\n",
> + __func__, size, align);
> + return NULL;
> + }
> +
> + if ((align & (align - 1)) || align <= 1) {
> + pr_err("%s(): align(=%x) must be power of two and >1\n",
> + __func__, align);
> + return NULL;
> + }
> +
> + spin_lock_irqsave(&cache_sram->lock, flags);
> + offset = rh_alloc_align(cache_sram->rh, size, align, NULL);
> + spin_unlock_irqrestore(&cache_sram->lock, flags);
> +
> + if (IS_ERR_VALUE(offset))
> + return NULL;
> +
> + *phys = cache_sram->base_phys + offset;
> +
> + return (unsigned char *)cache_sram->base_virt + offset;
> +}
> +EXPORT_SYMBOL(mpc85xx_cache_sram_alloc);
> +
> +void mpc85xx_cache_sram_free(void *ptr)
> +{
> + unsigned long flags;
> + BUG_ON(!ptr);
> +
> + spin_lock_irqsave(&cache_sram->lock, flags);
> + rh_free(cache_sram->rh, ptr - cache_sram->base_virt);
> + spin_unlock_irqrestore(&cache_sram->lock, flags);
> +}
> +EXPORT_SYMBOL(mpc85xx_cache_sram_free);
> +
> +int __init instantiate_cache_sram(struct of_device *dev, unsigned
> int size)
> +{
> + if (cache_sram) {
> + dev_err(&dev->dev, "Already initialized cache-sram\n");
> + return -EBUSY;
> + }
> +
> + cache_sram = kzalloc(sizeof(struct mpc85xx_cache_sram), GFP_KERNEL);
> + if (!cache_sram) {
> + dev_err(&dev->dev, "Out of memory for cache_sram structure\n");
> + return -ENOMEM;
> + }
> +
> + cache_sram->base_phys = CONFIG_FSL_85XX_CACHE_SRAM_BASE;
> + cache_sram->size = size;
> +
> + if (!request_mem_region(cache_sram->base_phys, cache_sram->size,
> + "fsl_85xx_cache_sram")) {
> + dev_err(&dev->dev, "%s: request memory failed\n",
> + dev->node->full_name);
> + kfree(cache_sram);
> + return -ENXIO;
> + }
> +
> + cache_sram->base_virt = ioremap_flags(cache_sram->base_phys,
> + cache_sram->size, _PAGE_COHERENT | PAGE_KERNEL);
> + if (!cache_sram->base_virt) {
> + dev_err(&dev->dev, "%s: ioremap_flags failed\n",
> + dev->node->full_name);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> + kfree(cache_sram);
> + return -ENOMEM;
> + }
> +
> + cache_sram->rh = rh_create(sizeof(unsigned int));
> + if (IS_ERR(cache_sram->rh)) {
> + dev_err(&dev->dev, "%s: Unable to create remote heap\n",
> + dev->node->full_name);
> + iounmap(cache_sram->base_virt);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> + kfree(cache_sram);
> + return PTR_ERR(cache_sram->rh);
> + }
> +
> + rh_attach_region(cache_sram->rh, 0, cache_sram->size);
> + spin_lock_init(&cache_sram->lock);
> +
> + dev_info(&dev->dev, "[base:0x%x, size:0x%x] configured and loaded
> \n",
> + cache_sram->base_phys, cache_sram->size);
> + return 0;
> +}
> +
> +void remove_cache_sram(struct of_device *dev)
> +{
> + BUG_ON(!cache_sram);
> +
> + rh_detach_region(cache_sram->rh, 0, cache_sram->size);
> + rh_destroy(cache_sram->rh);
> +
> + iounmap(cache_sram->base_virt);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> +
> + kfree(cache_sram);
> + cache_sram = NULL;
> +
> + dev_info(&dev->dev, "MPC85xx Cache-SRAM driver unloaded\n");
> +}
> diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/
> sysdev/fsl_85xx_l2ctlr.c
> new file mode 100644
> index 0000000..c851547
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * QorIQ (P1/P2) L2 controller init for Cache-SRAM instantiation
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <asm/io.h>
> +
> +#include "fsl_85xx_cache_ctlr.h"
> +
> +static char *param;
> +struct mpc85xx_l2ctlr __iomem *l2ctlr;
> +
> +static long get_cache_sram_size(void)
> +{
> + unsigned long val;
> +
> + if (!param || (strict_strtoul(param, 0, &val) < 0))
> + return -EINVAL;
> +
we should use memparse()
> + return val;
> +}
> +
> +static int __init get_cmdline_param(char *str)
> +{
> + if (!str)
> + return 0;
> +
> + param = str;
> + return 1;
> +}
> +
> +__setup("cache-sram-size=", get_cmdline_param);
> +
> +static int __devinit mpc85xx_l2ctlr_of_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + long rval;
> + unsigned int rem;
> + unsigned char ways;
> + const unsigned int *prop;
> + unsigned int l2cache_size;
> + unsigned int sram_size;
> +
> + if (!dev->node) {
> + dev_err(&dev->dev, "Device's OF-node is NULL\n");
> + return -EINVAL;
> + }
> +
> + prop = of_get_property(dev->node, "cache-size", NULL);
> + if (!prop) {
> + dev_err(&dev->dev, "Missing L2 cache-size\n");
> + return -EINVAL;
> + }
> + l2cache_size = *prop;
> +
> + rval = get_cache_sram_size();
> + if (rval <= 0) {
> + dev_err(&dev->dev,
> + "Entire L2 as cache, Aborting Cache-SRAM stuff\n");
> + return -EINVAL;
> + }
> +
> + rem = l2cache_size % (unsigned int)rval;
> + ways = LOCK_WAYS_FULL * (unsigned int)rval / l2cache_size;
> + if (rem || (ways & (ways - 1))) {
> + dev_err(&dev->dev, "Illegal cache-sram-size in command line\n");
> + return -EINVAL;
> + }
> +
> + sram_size = (unsigned int)rval;
> +
> + l2ctlr = of_iomap(dev->node, 0);
> + if (!l2ctlr) {
> + dev_err(&dev->dev, "Can't map L2 controller\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Write bits[0-17] to srbar0
> + */
> + out_be32(&l2ctlr->srbar0,
> + CONFIG_FSL_85XX_CACHE_SRAM_BASE & L2SRAM_BAR_MSK_LO18);
> +
> + /*
> + * Write bits[18-21] to srbare0
> + */
> + out_be32(&l2ctlr->srbarea0,
> + (CONFIG_FSL_85XX_CACHE_SRAM_BASE >> 10) & L2SRAM_BARE_MSK_HI4);
> +
> + clrsetbits_be32(&l2ctlr->ctl, L2CR_L2E, L2CR_L2FI);
> +
> + switch (ways) {
> + case LOCK_WAYS_EIGHTH:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_EIGHTH);
> + break;
> +
> + case LOCK_WAYS_TWO_EIGHTH:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_QUART);
> + break;
> +
> + case LOCK_WAYS_HALF:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_HALF);
> + break;
> +
> + case LOCK_WAYS_FULL:
> + default:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_FULL);
> + break;
> + }
> + eieio();
> +
> + rval = instantiate_cache_sram(dev, sram_size);
> + if (rval < 0) {
> + dev_err(&dev->dev, "Can't instantiate Cache-SRAM\n");
> + iounmap(l2ctlr);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int __devexit mpc85xx_l2ctlr_of_remove(struct of_device *dev)
> +{
> + BUG_ON(!l2ctlr);
> +
> + iounmap(l2ctlr);
> + remove_cache_sram(dev);
> + dev_info(&dev->dev, "MPC85xx L2 controller unloaded\n");
> +
> + return 0;
> +}
> +
> +static struct of_device_id mpc85xx_l2ctlr_of_match[] = {
> + {
> + .compatible = "fsl,p2020-l2-cache-controller",
> + },
> + {},
> +};
> +
> +static struct of_platform_driver mpc85xx_l2ctlr_of_platform_driver
> = {
> + .name = "fsl-l2ctlr",
> + .match_table = mpc85xx_l2ctlr_of_match,
> + .probe = mpc85xx_l2ctlr_of_probe,
> + .remove = __devexit_p(mpc85xx_l2ctlr_of_remove),
> +};
> +
> +static __init int mpc85xx_l2ctlr_of_init(void)
> +{
> + return of_register_platform_driver
> (&mpc85xx_l2ctlr_of_platform_driver);
> +}
> +
> +static void __exit mpc85xx_l2ctlr_of_exit(void)
> +{
> + of_unregister_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
> +}
> +
> +subsys_initcall(mpc85xx_l2ctlr_of_init);
> +module_exit(mpc85xx_l2ctlr_of_exit);
> +
> +MODULE_DESCRIPTION("Freescale MPC85xx L2 controller init");
> +MODULE_LICENSE("GPL v2");
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 14:09 UTC (permalink / raw)
To: Alon Ziv; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE47@Exchange.discretix.com>
On Thursday 19 November 2009, Alon Ziv wrote:
> On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > I'd still add support for the compatible="ns16550a" property
> > so that we do the right thing for future systems.
> >
>
> OK...
> ---
> Xilinx 16550 UART is actually 16550A-compatible
>
> Signed-off-by: Alon Ziv <alonz@discretix.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Does this go through the powerpc or the tty tree?
I'd be happy if either Ben or Greg could pick this up.
I'm happy to keep maintaining the driver itself but it
would be nice to know a definite subsystem maintainer
responsible for it.
Greg, if you want to take patches for of_serial.c generally,
I'll start forwarding them to you as they come in and make
sure they apply to your tree.
Arnd <><
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 02406ba..241be77 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> of_device *ofdev)
> static struct of_device_id __devinitdata of_platform_serial_table[] = {
> { .type = "serial", .compatible = "ns8250", .data = (void
> *)PORT_8250, },
> { .type = "serial", .compatible = "ns16450", .data = (void
> *)PORT_16450, },
> + { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b",
> .data = (void *)PORT_16550A, },
> { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550, },
> + { .type = "serial", .compatible = "ns16550a", .data = (void
> *)PORT_16550A, },
> { .type = "serial", .compatible = "ns16750", .data = (void
> *)PORT_16750, },
> { .type = "serial", .compatible = "ns16850", .data = (void
> *)PORT_16850, },
> #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
^ permalink raw reply
* Re: [PATCH] sata_fsl: Split hard and soft reset
From: Kumar Gala @ 2009-11-19 13:57 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-ppc list, linux-ide, Ashish Kalra, Jeff Garzik,
Jiang Yutang
In-Reply-To: <FF648E22-3953-4121-9DCE-862BAC5995B9@kernel.crashing.org>
On Nov 19, 2009, at 7:51 AM, Kumar Gala wrote:
>
> On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote:
>
>>
>> On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote:
>>
>>> From: Jiang Yutang <b14898@freescale.com>
>>>
>>> Split sata_fsl_softreset() into hard and soft resets to make
>>> error-handling more efficient & device and PMP detection more
>>> reliable.
>>>
>>> Also includes fix for PMP support, driver tested with Sil3726,
>>> Sil4726 & Exar PMP controllers.
>>>
>>> [AV: Also fixes resuming from deep sleep on MPC8315 CPUs]
>>>
>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>> drivers/ata/sata_fsl.c | 84 ++++++++++++++++++++++++
>>> +-----------------------
>>> 1 files changed, 44 insertions(+), 40 deletions(-)
>>
>> Jeff,
>>
>> any update on this going in for .32?
>
> Jeff?
slightly ignore me, for some reason I didn't see your reply.
- k
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Kumar Gala @ 2009-11-19 13:55 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1258441832-20133-1-git-send-email-leoli@freescale.com>
On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
> Rather than the original intelligent way, we grant user more freedom.
> This enables user to map cacheable memory not managed by Linux.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> The only direct users of this function is fb_mmap() and /dev/mem mmap.
> Although I'm not sure if anything is depending on the intelligent
> setting of
> cacheability.
is there some reason to change this?
- k
>
> arch/powerpc/mm/mem.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 579382c..0fd267e 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file,
> unsigned long pfn,
> if (ppc_md.phys_mem_access_prot)
> return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
>
> - if (!page_is_ram(pfn))
> + if (file->f_flags & O_SYNC)
> vma_prot = pgprot_noncached(vma_prot);
>
> return vma_prot;
> --
> 1.6.4
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] sata_fsl: Split hard and soft reset
From: Kumar Gala @ 2009-11-19 13:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, Jiang Yutang, Ashish Kalra, linux-ppc list
In-Reply-To: <795A2621-9D6C-4D1F-B07B-24E15C55B03F@kernel.crashing.org>
On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote:
>
> On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote:
>
>> From: Jiang Yutang <b14898@freescale.com>
>>
>> Split sata_fsl_softreset() into hard and soft resets to make
>> error-handling more efficient & device and PMP detection more
>> reliable.
>>
>> Also includes fix for PMP support, driver tested with Sil3726,
>> Sil4726 & Exar PMP controllers.
>>
>> [AV: Also fixes resuming from deep sleep on MPC8315 CPUs]
>>
>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/ata/sata_fsl.c | 84 ++++++++++++++++++++++++
>> +-----------------------
>> 1 files changed, 44 insertions(+), 40 deletions(-)
>
> Jeff,
>
> any update on this going in for .32?
Jeff?
- k
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Alon Ziv @ 2009-11-19 13:49 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
In-Reply-To: <200911191441.27581.arnd@arndb.de>
On Thursday, November 19, 2009, Arnd Bergmann wrote:
> I'd still add support for the compatible=3D"ns16550a" property
> so that we do the right thing for future systems.
>=20
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv <alonz@discretix.com>
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] =3D =
{
{ .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
*)PORT_8250, },
{ .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
*)PORT_16450, },
+ { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
=2Edata =3D (void *)PORT_16550A, },
{ .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
*)PORT_16550, },
+ { .type =3D "serial", .compatible =3D "ns16550a", .data =3D (void
*)PORT_16550A, },
{ .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
*)PORT_16750, },
{ .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
*************************************************************************=
*********************
IMPORTANT: The contents of this email and any attachments are confidentia=
l. They are intended for the=20
named recipient(s) only.
If you have received this email in error, please notify the system manage=
r or the sender immediately and do=20
not disclose the contents to anyone or make copies thereof.
^ permalink raw reply related
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 13:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alon Ziv
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE44@Exchange.discretix.com>
On Thursday 19 November 2009, Alon Ziv wrote:
> Is the following better?
>
> ---
> [PATCH] Xilinx 16550 UART is actually 16550A-compatible
>
Yes, that's better because it's guaranteed not to break any
other system, while fixing yours.
I'd still add support for the compatible="ns16550a" property
so that we do the right thing for future systems.
Arnd <><
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Alon Ziv @ 2009-11-19 13:32 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
In-Reply-To: <200911191401.37531.arnd@arndb.de>
Hi,
On Thursday, November 19, 2009, Arnd wrote:
> In that case, add another entry for the device encoded in the firmware
> itself. The ns16550 entry should be the second one after a more
specific
> one telling which device it is exactly.
>=20
Is the following better?
---
[PATCH] Xilinx 16550 UART is actually 16550A-compatible
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..40bf8f4 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,6 +161,7 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] =3D =
{
{ .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
*)PORT_8250, },
{ .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
*)PORT_16450, },
+ { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
=2Edata =3D (void *)PORT_16550A, },
{ .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
*)PORT_16550, },
{ .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
*)PORT_16750, },
{ .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
*)PORT_16850, },
*************************************************************************=
*********************
IMPORTANT: The contents of this email and any attachments are confidentia=
l. They are intended for the=20
named recipient(s) only.
If you have received this email in error, please notify the system manage=
r or the sender immediately and do=20
not disclose the contents to anyone or make copies thereof.
^ permalink raw reply related
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 13:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alon Ziv
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE31@Exchange.discretix.com>
On Thursday 19 November 2009, Alon Ziv wrote:
> On Monday, November 16, 2009, Arnd wrote:
> > > - { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550, },
> > > + { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550A, },
> >
> > Does not seem logical. If the device claims compatibility with
> ns16550, we should
> > not automatically assume it's an ns16550a. Why not add another line
> for
> >
>
> Unfortunately, there is no way to change what the device claims--it's
> encoded into the OpenFirmware tree by the EDK tools.
> And, in any case, the device is actually not lying: it is compatible
> with NS16550--just with a non-buggy one. Unfortunately the kernel
> driver for 8250-class UARTs makes the conservative choice to assume any
> 16550 is one of the (early, buggy) revisions where the FIFO was
> non-functional; any 16550 with working UART is classed as a 16550A.
In that case, add another entry for the device encoded in the firmware
itself. The ns16550 entry should be the second one after a more specific
one telling which device it is exactly.
Arnd <><
^ permalink raw reply
* RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
From: Alon Ziv @ 2009-11-19 12:57 UTC (permalink / raw)
To: Stephen Neuendorffer, linuxppc-dev; +Cc: John Linn
In-Reply-To: <56a3f016-525a-4eb2-9a0f-1477ea2eee91@VA3EHSMHS019.ehs.local>
Hi,
On Monday, November 16, 2009, Stephen wrote:
> There are at least two other ways that you might be able to reset a
> board:
> 1) Internally through the ICAP device.
> 2) Through a GPIO connected externally to the reset logic.
>=20
Unfortunately none of these is relevant for the specific board in
question (Xilinx ML510 reference system)...
> Probably it would be best to have a mechanism in the device tree which
> references the reset mechanism?
I am sorely lacking in expertise for this :(, and wouldn't even know
where to begin... Is it possible at all to add custom information into
the device tree? And even if yes--how will platform code bind to the
reset mechanism?
> [...] In any event, you probably don't want a driver to
> eplicitly reference the plaform code. If you want to do it explicitly
> like this, it would better to have the plaform code reference the
driver
> mechanism.
I don't see how this can be done: if the driver is to publish some
"driver_reset_system" function to the platform code, it needs _some_
mechanism for telling this fact to the system... And such a mechanism
won't look all that different from my callback, IMO (except it may be
slightly prettied up).
Of course, one obvious thing that must be done is move this code out of
arch/powerpc/platforms/44x/virtex.c and into (e.g.)
arch/powerpc/kernel/setup-common.c, and add some
"set_machine_restart_function" wrapper to access it more cleanly (also
defining this function as a null function when inapplicable). If this
satisfies your standards, I can easily post an updated patch :)
-az
*************************************************************************=
*********************
IMPORTANT: The contents of this email and any attachments are confidentia=
l. They are intended for the=20
named recipient(s) only.
If you have received this email in error, please notify the system manage=
r or the sender immediately and do=20
not disclose the contents to anyone or make copies thereof.
^ 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