* Re: Please pull from 'for_paulus' branch
From: Zang Roy-r61911 @ 2007-07-25 6:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0707231556210.4203@blarg.am.freescale.net>
On Tue, 2007-07-24 at 05:01, Kumar Gala wrote:
> Please pull from 'for_paulus' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> for_paulus
>
> Sorry I wasn't able to get this pull request out before -rc1 got
> released,
> but had some issues w/accessing email/accounts this weekend.
>
> to receive the following updates:
Could you help to pick up the 7448hpc2 cuboot support patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038952.html
Roy
^ permalink raw reply
* Re: Circular queue
From: Misbah khan @ 2007-07-25 6:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46A5B5BA.2080707@dlasys.net>
hi ....
Yes ofcourse there is a data structure for circular buffer implementation in
the driver but for the version 2.6.10 and onwards. Just see the
documentation on header file <linux/kfifo.h> I myself never tried with this
,where in i had implimented a circular buffer in the kernel and you need to
take care with the read index and write index. I suggest you to built your
own circular buffer insted on relaying on the standered because as far as i
know you should not relay on something new and untested . If you feel any
problem in the implementation i can help you in that.
regard
Misbah
David H. Lynch Jr.-2 wrote:
>
> Is there a standard linux datastructure and routines to manage
> circular queues ?
>
> I have a device that is not fundimentally different from a serial
> character device
> except it is faster and the fundimental data type is 36 bits large.
>
> I have coded my own routines to setup and maintain a simple circular
> queue,
> but I was hoping that there might be something more standard that
> already exists.
>
> Anyone know of anything ?
>
>
>
>
>
>
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too
> numerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes
> a touch of genius - and a lot of courage to move in the opposite
> direction."
> Albert Einstein
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Circular-queue-tf4134423.html#a11777050
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Benjamin Herrenschmidt @ 2007-07-25 6:22 UTC (permalink / raw)
To: Alan Curry; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200707250128.l6P1SWSF1336935@shell01.TheWorld.com>
On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote:
> As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
> on the PegasosPPC. This is because of a feature/bug in the OF device tree:
> the "device_type" attribute is an empty string instead of "8042" as the
> kernel expects. This patch (against 2.6.22.1) adds a secondary detection
> which looks for a device whose *name* is "8042" if there is no device whose
> *type* is "8042".
>
> Signed-off-by: Alan Curry <pacman@world.std.com>
Doesn't it have something in "compatible" instead ? that would be the
way to go.
Ben.
^ permalink raw reply
* Re: [PATCH] xmon consistency clean up
From: Benjamin Herrenschmidt @ 2007-07-25 6:21 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707250257.l6P2va65006958@toshiba.co.jp>
On Wed, 2007-07-25 at 11:57 +0900, Ishizaki Kou wrote:
> This patch cleans up xmon to keep consistency.
>
> In xmon, we should use console I/O functions that are named the same
> as user space stdio functions. But commit
> 4d404edce30f911004850d472e05a31efd751662 broke this consistency.
>
> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> ---
>
> Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> ===================================================================
> --- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
> +++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
> @@ -133,7 +133,7 @@ void xmon_printf(const char *format, ...
> xmon_write(xmon_outbuf, n);
> }
>
> -void xmon_puts(const char *str)
> +void xmon_fputs(const char *str)
> {
> xmon_write(str, strlen(str));
Nah, keep it xmon_puts, since it doesn't take a stream argument and
define a "puts" for use by xmon core.
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] Don't try to allocate resources for a POWERPC PHB
From: Kumar Gala @ 2007-07-25 5:48 UTC (permalink / raw)
To: benh, linuxppc-dev
The Freescale PCI PHBs actual report back values in the BAR registers
this causes issues in that we try to allocate resources for them
and will get error messages like the following on MPC8544 DS:
PCI: Failed to allocate mem resource #1:80000000@0 for 0000:00:00.0
To address this if we are class PCI_CLASS_PROCESSOR_POWERPC, a normal
header type, and the PHB don't try to assign resources.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/pci_32.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 721a694..39f8cb1 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -508,6 +508,13 @@ pcibios_allocate_resources(int pass)
struct resource *r;
for_each_pci_dev(dev) {
+ int class = dev->class >> 8;
+
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
+ (dev->bus->parent == NULL))
+ continue;
+
pci_read_config_word(dev, PCI_COMMAND, &command);
for (idx = 0; idx < 6; idx++) {
r = &dev->resource[idx];
@@ -550,6 +557,10 @@ pcibios_assign_resources(void)
/* Don't touch classless devices and host bridges */
if (!class || class == PCI_CLASS_BRIDGE_HOST)
continue;
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
+ (dev->bus->parent == NULL))
+ continue;
for (idx = 0; idx < 6; idx++) {
r = &dev->resource[idx];
--
1.5.2.2
^ permalink raw reply related
* Re: Interrupts on xilinx ml403
From: Misbah khan @ 2007-07-25 4:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11765540.post@talk.nabble.com>
hi ...
Well you are always welcome to contact me . Just look at the configuration
of registers are proper or not and you have followed Bigendian format or
not. more than 90 % of the problem comes when you dont configure the
controler registers properly.
----Misbah
Mirek23 wrote:
>
> I will try to go further with that after trying Grant's suggestion. When I
> still have a problem I will contact you.
>
> Best Regards
>
> Mirek
>
> Misbah khan wrote:
>>
>> hi ..
>>
>> If you could send me the code and the config related doc . I could then
>> be able to suggest you something. As per the understanding of the problem
>> i guess you are not congiguring the interrupt controller properly. you
>> have to use correct IRQ no for that ports then other configuration such
>> as interrupt type, and whenever you service the interrupt you have to
>> clear the interrupt etc are to be taken care ....Please see the interrupt
>> controller register and do your settings correctly . If the same persists
>> then you please send me the code and the documents then only i could give
>> the exact explaination on this
>>
>> ----misbah
>>
>> Mirek23 wrote:
>>>
>>> Dear All,
>>>
>>> I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
>>> evaluation board.
>>>
>>> I have setup the virtex-4 FPGA to deal with Themac and Serial
>>> interfaces. As input/output devices I have chosen 8 LEDs and DIP
>>> Switches.
>>>
>>> With such a configuration I am able to control from Linux user
>>> applications via GPIO driver the LEDs and DIP Switches.
>>>
>>> Right now I just wanted to make use of the interrupts. I have configured
>>> the Dip switches to use interrupt. The interrupt accoures when the DIP
>>> Switches state has changed.
>>>
>>> In the BSP generated by EDK 9.1 I see that macro :
>>>
>>> #define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1
>>>
>>> has changed from zero to one.
>>> The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before.
>>> This is due to the fact that
>>> TEMAC uses one interrupt line.
>>>
>>> Does it mean that DIP Switches do not use INTC interrupt controller?
>>> How to handle the DIP Switches interrupt?
>>> Does the Interrupt handler routine have to acknowledge the interrupt
>>> from Dip Switches?
>>>
>>> Many thanks in advance for any hint on that.
>>>
>>> Best Regards
>>>
>>> Mirek
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11776097
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Xilinx TEMAC driver
From: Grant Likely @ 2007-07-25 4:29 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <46A5C305.5000903@dlasys.net>
On 7/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> Hopefully this is not too much of a mess.
>
> This is a very preliminary patch to add support for the Xilinx TEMAC.
> This is closer approximation to a normal linux driver.
> There are no external dependencies aside from a properly setup
> xparameters.h and
> platform data structure for the TEMAC - i.e. no need for xilinx_edk,
> xilinx_common, ...
> The whole driver is in a single source file.
> It autonegotiates, and it actually works in some Pico Firmware where
> the MV/Xilinx driver does not.
Hooray! Thanks for posting your work. I'm keen to try this on my
platform. Comments below.
General comments:
- Remove the c++ (//) style comments
- indentation should be by tabs, not spaces. Run the whole file
through the scripts/Lindent utility.
- Your patch has been damaged by your mailer (by wrapping lines). I
cannot apply this patch as-is. Maybe take a look at git-send-email
for sending patches.
- Keep lines < 80 characters long.
- CamelCaseVariablesStructuresAndFunctions don't match the Linux coding style.
- rather than commenting out DEBUG_PRINTK's, instead add "#define
DEBUG" before the #include statements, and use the dev_dbg() macro.
>
> Somewhere long ago this started out based on the Xilinx code from
> the Trek Webserver sample.
> As such it is also losely based on the xilinx_edk code.
> Hopefully, I remembered to provide proper attribution. This is
> preliminary so things like that will get fixed.
> It includes support for the LocalLink TEMAC, though the LL_TEMAC
> performance is poor, and I could not figure
> out anyway to make it interrupt driven so it had a fairly high rate
> of dropped packets.
> It ONLY supports the FIFO based PLB TEMAC. If you want SGDMA add it
> or use the Xilinx/MV driver.
>
> There is alot of cruft in the driver that needs yanked, bits and
> peices of #ifdefed out code from the xilinx EDK or ldd3
> or whatever I thought I needed, and have not yet been willing to delete.
>
> I am also using dman near the same identical source for a TEMAC
> driver for GreenHills, and there are likely some
> #ifdef's that only make sense in that context.
>
> At somepoint I will try to clean all of the above crap out.
>
> I also need to clean up my git tree so that I can produce a proper
> patch.
>
> Enough caveats - patch follows.
>
>
>
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 7d57f4a..fe5aa83 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2332,6 +2337,59 @@ config ATL1
>
> endif # NETDEV_1000
>
> +config PICO_TEMAC
> + tristate "Pico Xilinx 10/100/1000 Mbit Local Link/PLB TEMAC support"
Drop the PICO name, this should work with any TEMAC implementation.
> + depends on XILINX_VIRTEX && !XILINX_OLD_TEMAC && !XILINX_TEMAC
> + select MII
> + select NET_POLL_CONTROLLER
> +# select PHYLIB
Drop the commented out bits, they can always be added back in when
phylib support is added.
> + help
> + This driver supports Tri-Mode, 10/100/1000 Mbit EMAC IP
> + from Xilinx EDK.
> +
> +config PICO_DEBUG_TEMAC
> + bool 'Pico TEMAC Debugging'
> + default y
> + depends on PICO_TEMAC && PICO_DEBUG
> +
> +
> #
> # 10 Gigabit Ethernet
> #
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index a77affa..2248dd4 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -227,3 +227,8 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
> obj-$(CONFIG_FS_ENET) += fs_enet/
>
> obj-$(CONFIG_NETXEN_NIC) += netxen/
> +obj-$(CONFIG_PICO_TEMAC) += temac.o
> diff --git a/drivers/net/temac.c b/drivers/net/temac.c
> new file mode 100644
> index 0000000..01d30c4
> --- /dev/null
> +++ b/drivers/net/temac.c
> @@ -0,0 +1,3742 @@
> +/*
> +
> + linux/drivers/net/temac.c
> +
> + Driver for Xilinx hard temac ethernet NIC's
> +
> + Author: David H. Lynch Jr. <dhlii@dlasys.net>
> + Copyright (C) 2005 DLA Systems
> + The author may be reached as dhlii@sdlasys.net, or C/O
> + DLA Systems
> + 354 Rudy Dam rd.
> + Lititz PA 17543
Drop the contact info, you can add stuff to MAINTAINERS if you prefer
in a separate patch.
> +
> +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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + things that need looked at:
> + process_transmits
> + temac_EtherRead
> + temac_hard_start_xmit
> + ehter_reset
> + temac_get_link_status
> +
> +$Id: temac.c,v 0.10 2005/12/14 10:03:27 dhlii Exp $
Drop the CVS-fu. It's irrelevant for mainline.
> +
> +*/
> +#define DRV_NAME "temac"
> +#define DRV_DESCRIPTION "Xilinx hard Tri-Mode Eth MAC driver"
> +#define DRV_VERSION "0.10a"
> +#define DRV_RELDATE "07/10/2006"
For mainline submission, VERSION and RELDATE are irrelevant.
> +
> +#if defined(__KERNEL__)
> +#define LINUX 1
> +#endif
> +static const char version[] = DRV_NAME ".c:v" DRV_VERSION " "
> DRV_RELDATE " David H. Lynch Jr. (dhlii@dlasys.net)\n";
> +
> +#if defined(LINUX)
Heh; I'm pretty sure we're running on Linux here.
> +#include <linux/module.h>
> +#include <linux/ioport.h>
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/init.h>
> +#include <linux/skbuff.h>
> +#include <linux/spinlock.h>
> +#include <linux/crc32.h>
> +
> +#include <linux/mii.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/xilinx_devices.h>
> +#include <linux/ethtool.h>
> +#include <asm/delay.h>
> +#include <asm/irq.h>
> +#include <asm/io.h>
> +
> +#define FRAME_ALIGNMENT 8 /* Byte
> alignment of ethernet frames */
> +typedef char EthFrame[9000] __attribute__ ((aligned(FRAME_ALIGNMENT)));
> +
> +#define TRUE 1
> +#define FALSE 0
> +
> +#define TEMAC_RX_TIMEOUT (jiffies + ((1 * HZ)/5))
> +#define TEMAC_TX_TIMEOUT (jiffies + (2 * HZ))
> +#define TEMAC_MII_TIMEOUT (jiffies + (2 * HZ)) /* timer
> wakeup time : 2 second */
> +
> +/*
> +Transmit timeout, default 5 seconds.
> + */
> +static int
> +watchdog = 5000;
> +module_param(watchdog, int, 0400);
> +MODULE_PARM_DESC(watchdog, "transmit timeout in milliseconds");
Is this best done as a module parm? I would think this is something
you'd want to change of the fily... then again, it's just a watchdog
timer. How often is in necessary to fiddle with the timeout?
> +
> +static struct platform_device *temac_device;
> +
> +/* for exclusion of all program flows (processes, ISRs and BHs) */
> +DEFINE_SPINLOCK(XTE_spinlock);
Avoid uppercase in variable defines.
> +#define res_size(_r) (((_r)->end - (_r)->start) + 1)
> +#define EnetDbPrint(dev,msg)
Avoid CamelCaseFunctionsAndDefines.
> +#define Success 0
> +#define Failure -1
0 as success is a pretty well defined convention. Don't add new
defines for it here.
> +#define Error int
Remove this, just use 'int'
<snip>
> +
> +#define db_printf DEBUG_PRINTK
> +/* use 0 for production, 1 for verification, >1 for debug */
> +#if defined(CONFIG_PICO_DEBUG_TEMAC)
> +#define DEBUG_FUNC if (lp->dbg)
> {dbg_printk("\n%s:%s()",DRV_NAME, __FUNCTION__);}
> +#define DEBUG_FUNC_EXIT if (lp->dbg) {dbg_printk("\n%s:%s()
> exit",DRV_NAME,__FUNCTION__);}
> +#define DEBUG_FUNC_EX(ret) if (lp->dbg)
> {dbg_printk("\n%s:%s(%d)exit",DRV_NAME,__FUNCTION__,ret);}
> +#define DEBUG_PRINTL(args...) if (lp->dbg) dbg_printk("\n" __FILE__
> ": " args)
> +#define DEBUG_PRINTK(args...) if (lp->dbg) dbg_printk(args)
> +#define DEBUG_PUTS(fmt...) if (lp->dbg) dbg_puts(fmt)
> +void dbg_printk(unsigned char *fmt, ...);
> +static unsigned int debug = 1;
> +#else
> +#define DEBUG_FUNC do { } while(0)
> +#define DEBUG_FUNC_EXIT do { } while(0)
> +#define DEBUG_PRINTL(args...) do { } while(0)
> +#define DEBUG_PRINTK(args...) do { } while(0)
> +#define DEBUG_PUTS(args...) do { } while(0)
> +#define dump_skb(lp, skb) 0
> +#define dump_skb_data(lp, skb, str) 0
> +static unsigned int debug = 1;
> +#endif
Not a good idea to add your own debug print functions. Drivers should
use dev_dbg(), dev_info(), etc. Or in the odd case where the dev
structure is not available, user the pr_debug() macro.
<snip>
> +/* This type encapsulates a packet FIFO channel and support attributes to
> + * allow unaligned data transfers.
> + */
> +struct temac_pktFifo {
> + u32 Hold[2]; /* Holding register */
> + unsigned ByteIndex; /* Holding register index */
> + unsigned Width; /* Width of packet FIFO's
> keyhole data port in bytes */
> + u32 RegBaseAddress; /**< Base address of
> registers */
> + u32 DataBaseAddress; /**< Base address of data
> for FIFOs */
> +} ;
> +
> +struct temac_local {
> +#if defined(LINUX)
> + struct sk_buff *deferred_skb; /* buffer for one
> skb in case no room is available for transmission */
> +
> +// void *RxFramePtr; /* Address of first
> RxFrame */
> + unsigned MaxFrameSz; /* Size in bytes of
> largest frame for Tx or Rx */
> +// u32 RxPktFifoDepth; /**< Depth of
> receive packet FIFO in bits */
> +// u32 TxPktFifoDepth; /**< Depth of
> transmit packet FIFO in bits */
> +// u16 MacFifoDepth; /**< Depth of the
> status/length FIFOs in entries */
> +
> + struct resource *nic_addr_res; /* resources found */
> + struct resource *phy_addr_res;
> + struct resource *nic_addr_req; /* resources
> requested */
> + struct resource *phy_addr_req;
> + void __iomem *nic_vaddr; /* Register I/O base
> address */
> +
> + struct mii_if_info mii_if;
> +#else
> + EnetDevice enetDevice;
> + InterruptHandler handler;
> + struct sk_buff __skb[(NUM_TX_BDS+NUM_RX_BDS) +
> (MAX_CACHE_LINE_SIZE/sizeof(struct sk_buff))];
> + char name[20];
> + u32 base_addr;
> + u8 dev_addr[6];
> +
> + u32 disablecount;
> + u32 enablecount;
> + u32 tx_reset_pending;
> + u32 rx_reset_pending;
> + u32 reads_denied_during_reset;
> + u32 writes_denied_during_reset;
> +
> + int devno;
> + Error (*GetLinkStatus)(struct temac_local *
> lp, LinkSpeed *linkSpeed, LinkStatus *linkStatus, LinkDuplex *linkDuplex);
> +
> + PHY mii_if;
> + u32 trans_start;
> + u32 last_rx;
> +#endif
> + unsigned int mii:1; /* mii port
> available */
> + u8 regshift;
> + u32 msg_enable; /* debug message
> level */
> + struct net_device_stats stats; /* Statistics for
> this device */
> + unsigned int phy_mode; /* dcr */
> + u16 phy_addr;
> + u32 phy_status;
> + unsigned int poll:1;
> + unsigned int dbg:1; /* debug ? */
> + unsigned int nic_type; /* plb/ll */
> + int LinkSpeed; /* Speed of link
> 10/100/1000 */
> + u32 options; /* Current options
> word */
> +// u32 TxPktFifoErrors; /**< Number of Tx
> packet FIFO errors detected */
> +// u32 TxStatusErrors;
> +// u32 RxPktFifoErrors; /**< Number of Rx
> packet FIFO errors detected */
> +// u32 RxRejectErrors;
> +// u32 FifoErrors; /**< Number of
> length/status FIFO errors detected */
> +// u32 IpifErrors; /**< Number of IPIF
> transaction and data phase errors detected */
> +// u32 Interrupts; /**< Number of
Remove the commented out members; they can be added in when needed.
<snip>
> +static u32
> +_ior(u32 offset) {
> + u32 value;
> + value = (*(volatile u32 *) (offset));
> + __asm__ __volatile__("eieio");
> + return value;
> +}
> +
> +static void
> +_iow(u32 offset, u32 value) {
> + (*(volatile u32 *) (offset) = value);
> + __asm__ __volatile__("eieio");
> +}
> +
> +static u32
> +ior(struct net_device *ndev, int offset) {
> + return _ior(ndev->base_addr + offset);
> +}
> +
> +static u32
> +ios(struct net_device *ndev) {
> + return ior(ndev, XTE_IPIER_OFFSET) & ior(ndev, XTE_IPISR_OFFSET);
> +}
> +
> +static void
> +iow(struct net_device *ndev, int offset, u32 value) {
> + _iow(ndev->base_addr + offset, value);
> +}
Don't define new IO functions. Use the ones in <asm/io.h>
> +
> +/***************************************************************************
> + * Reads an MII register from the MII PHY attached to the Xilinx Temac.
> + *
> + * Parameters:
> + * dev - the temac device.
> + * phy_addr - the address of the PHY [0..31]
> + * reg_num - the number of the register to read. 0-6 are defined by
> + * the MII spec, but most PHYs have more.
> + * reg_value - this is set to the specified register's value
> + *
> + * Returns:
> + * Success or Failure
> + */
> +static Error
> +g_mdio_read(struct net_device *ndev, int phy_id, int reg_num, u16 *
> reg_val) {
what does the 'g_' prefix signify?
<snip>
> + switch (ii) {
> + case MII_ANI:
> + disp_mii(ndev, "ANI", ii);
> + break;
> + case MII_SSR:
> + disp_mii(ndev, "SSR", ii);
> + break;
> + case MII_ISR:
> + disp_mii(ndev, "ISR", ii);
> + break;
> + case MII_BMCR:
> + disp_mii(ndev, "MCR", ii);
> + break;
> + case MII_BMSR:
> + disp_mii(ndev, "MSR", ii);
> + break;
> + case MII_PHYSID1:
> + disp_mii(ndev,"PHYSID1",ii);
> + break;
> + case MII_PHYSID2:
> + disp_mii(ndev,"PHYSID2",ii);
> + break;
> + case MII_ADVERTISE:
> + disp_mii(ndev,"ADV", ii);
> + break;
> + case MII_LPA:
> + disp_mii(ndev,"LPA", ii);
> + break;
> + case MII_EXPANSION:
> + disp_mii(ndev,"EXPANSION", ii);
> + break;
> + case MII_CTRL1000:
> + disp_mii(ndev,"CTRL1000", ii);
> + break;
> + case MII_STAT1000:
> + disp_mii(ndev,"STAT1000", ii);
> + break;
> + case MII_ESTATUS:
> + disp_mii(ndev,"ESTATUS", ii);
> + break;
> + case MII_DCOUNTER:
> + disp_mii(ndev,"DCOUNTER", ii);
> + break;
> + case MII_NWAYTEST:
> + disp_mii(ndev,"NWAYTEST", ii);
> + break;
> + case MII_RERRCOUNTER:
> + disp_mii(ndev,"RERRCOUNT", ii);
> + break;
> + case MII_SREVISION:
> + disp_mii(ndev,"SREVISION",ii);
> + break;
> + case MII_RESV1:
> + disp_mii(ndev,"RESV1",ii);
> + break;
> + case MII_LBRERROR:
> + disp_mii(ndev,"LBERROR",ii);
> + break;
> + case MII_PHYADDR:
> + disp_mii(ndev,"PHYADDR",ii);
> + break;
> + case MII_RESV2:
> + disp_mii(ndev,"RESV2",ii);
> + break;
> + case MII_TPISTATUS:
> + disp_mii(ndev,"TPISTATUS",ii);
> + break;
> + case MII_NCONFIG:
> + disp_mii(ndev,"NCONFIG",ii);
> + break;
> +#if 0
> + case MII_FCSCOUNTER:
> + disp_mii(ndev,"FCSCOUNTER",ii);
> + break;
> +#endif
This case statement is a *really* good candidate to be replaced with a
lookup table.
> + default:
> + disp_mii(ndev,0, ii);
> + break;
> + }
> + }
> + /*
> + Print TEMAC Receiver and Transmitter configuration
> + */
> + DEBUG_PRINTK("\nReading Hard TEMAC Regs:\n");
> +
> + for (ii = 0x200,jj = 0; ii <= 0x3a4; ii += 4) {
> + switch (ii) {
> + case XTE_RXC0_OFFSET:
> + disp_emac_cfg(ndev, "RxCW0", ii, jj++);
> + break;
> + case XTE_RXC1_OFFSET:
> + disp_emac_cfg(ndev, "RxCW1", ii, jj++);
> + break;
> + case XTE_TXC_OFFSET:
> + disp_emac_cfg(ndev, "TxCW", ii, jj++);
> + break;
> + case XTE_FCC_OFFSET:
> + disp_emac_cfg(ndev, "Flow", ii, jj++);
> + break;
> + case XTE_EMCFG_OFFSET:
> + disp_emac_cfg(ndev, "ModeCfg", ii, jj++);
> + break;
> + case XTE_MC_OFFSET:
> + disp_emac_cfg(ndev, "MgmtCfg", ii, jj++);
> + break;
> + case XTE_UAW0_OFFSET:
> + disp_emac_cfg(ndev, "MacAddr0", ii, jj++);
> + break;
> + case XTE_UAW1_OFFSET:
> + disp_emac_cfg(ndev, "MacAddr1", ii, jj++);
> + break;
> + case XTE_MAW0_OFFSET:
> + disp_emac_cfg(ndev, "AtAddr0", ii, jj++);
> + break;
> + case XTE_MAW1_OFFSET:
> + disp_emac_cfg(ndev, "AtAddr1", ii, jj++);
> + break;
> + case XTE_AFM_OFFSET:
> + disp_emac_cfg(ndev, "AtCAF", ii, jj++);
> + break;
> + case XGP_IRSTATUS:
> + disp_emac_cfg(ndev, "ISR", ii, jj++);
> + break;
> + case XGP_IRENABLE:
> + disp_emac_cfg(ndev, "IER", ii, jj++);
> + break;
Same with this one.
> + default:
> + break;
> + }
> + }
> + DEBUG_PRINTK("\n");
> +
> + if (lp->nic_type == TEMAC_PLB) {
> + DEBUG_PRINTK("\nReading PLB TEMAC Regs:\n");
> +
> + for (ii = 0x0,jj = 4;ii <= 0x1020; ii += 4) {
> + switch (ii) {
> + case XTE_DISR_OFFSET:
> + disp_temac_cfg(ndev, "DISR", ii, jj++);
> + break;
> + case XTE_DIPR_OFFSET:
> + disp_temac_cfg(ndev, "DIPR", ii, jj++);
> + break;
> + case XTE_DIER_OFFSET:
> + disp_temac_cfg(ndev, "DIER", ii, jj++);
> + break;
> + case XTE_DGIE_OFFSET:
> + disp_temac_cfg(ndev, "DGIE", ii, jj++);
> + break;
> + case XTE_IPISR_OFFSET:
> + disp_temac_cfg(ndev, "IPISR", ii, jj++);
> + break;
> + case XTE_IPIER_OFFSET:
> + disp_temac_cfg(ndev, "IPIER", ii, jj++);
> + break;
> + case XTE_DSR_OFFSET:
> + disp_temac_cfg(ndev, "MIR", ii, jj++);
> + break;
> + case XTE_TPLR_OFFSET:
> + // disp_temac_cfg(ndev, "TPLR", ii, jj++); // do
> not try to display this register - BAD things will happen
> + break;
> + case XTE_CR_OFFSET:
> + disp_temac_cfg(ndev, "CR", ii, jj++);
> + break;
> + case XTE_TSR_OFFSET:
> + // disp_temac_cfg(ndev, "TSR", ii, jj++);
> + break;
> + case XTE_RPLR_OFFSET:
> + // disp_temac_cfg(ndev, "RPLR", ii, jj++);
> + break;
> + case XTE_RSR_OFFSET:
> + disp_temac_cfg(ndev, "RSR", ii, jj++);
> + break;
> + case XTE_TPPR_OFFSET:
> + disp_temac_cfg(ndev, "TPPR", ii, jj++);
> + break;
Ditto
> + default:
> + break;
> + }
> + }
> + }
> + DEBUG_PRINTK("\nDisplaying Options:\n");
> +
> + for (ii = 0, jj = 0;ii < 32; ii++) {
> + if ( lp->options & ( 1 << ii)) {
> + jj++;
> + if ((jj % 4) == 0) DEBUG_PRINTK("\n\t");
> + switch ( 1 << ii) {
> + case XTE_PROMISC_OPTION:
> + DEBUG_PRINTK("PROMISC ");
> + break;
> + case XTE_JUMBO_OPTION:
> + DEBUG_PRINTK("JUMBO ");
> + break;
> + case XTE_VLAN_OPTION:
> + DEBUG_PRINTK("VLAN ");
> + break;
> + case XTE_FLOW_CONTROL_OPTION:
> + DEBUG_PRINTK("FLOW_CONTROL ");
> + break;
> + case XTE_FCS_STRIP_OPTION:
> + DEBUG_PRINTK("FCS_STRIP ");
> + break;
> + case XTE_FCS_INSERT_OPTION:
> + DEBUG_PRINTK("FCS_INSERT ");
> + break;
> + case XTE_LENTYPE_ERR_OPTION:
> + DEBUG_PRINTK("LENTYPE ERR ");
> + break;
> + case XTE_POLLED_OPTION:
> + DEBUG_PRINTK("POLLED ");
> + break;
> + case XTE_REPORT_RXERR_OPTION:
> + DEBUG_PRINTK("REPORT_RXERR ");
> + break;
> + case XTE_TRANSMITTER_ENABLE_OPTION:
> + DEBUG_PRINTK("TRANSMITTER_ENABLE ");
> + break;
> + case XTE_RECEIVER_ENABLE_OPTION:
> + DEBUG_PRINTK("RECEIVER_ENABLE ");
> + break;
> + case XTE_BROADCAST_OPTION:
> + DEBUG_PRINTK("BROADCAST ");
> + break;
> + case XTE_MULTICAST_CAM_OPTION:
> + DEBUG_PRINTK("MULTICAST_CAM ");
> + break;
> + case XTE_REPORT_TXSTATUS_OVERRUN_OPTION:
> + DEBUG_PRINTK("REPORT_TXSTATUS_OVERRUN ");
> + break;
> + case XTE_ANEG_OPTION:
> + DEBUG_PRINTK("ANEG ");
> + break;
Ditto
<snip>
> +
> +static u8
> +recvBd[] = {
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00
> +};
Global variables are automatically zeroed. No need to zero it explicitly.
<snip>
> +#else
> + plb_temac_interrupt(ndev);
> +#...
>
> [Message clipped]
Heh; too big for my email client.... anyway; clean up the basic
comments, eliminate the non-Linux stuff and repost. It will be much
easier to review when the coding style issues are sorted out. Also,
take a look at your mailer and make sure you can email inline patches
without word wrapping.
Cheers and thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] xmon consistency clean up
From: Ishizaki Kou @ 2007-07-25 2:57 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This patch cleans up xmon to keep consistency.
In xmon, we should use console I/O functions that are named the same
as user space stdio functions. But commit
4d404edce30f911004850d472e05a31efd751662 broke this consistency.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
---
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
@@ -133,7 +133,7 @@ void xmon_printf(const char *format, ...
xmon_write(xmon_outbuf, n);
}
-void xmon_puts(const char *str)
+void xmon_fputs(const char *str)
{
xmon_write(str, strlen(str));
}
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.h
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
@@ -2,10 +2,11 @@
#define printf xmon_printf
#define putchar xmon_putchar
+#define fputs(str,stream) xmon_fputs(str) /* stream is ignored. */
extern int xmon_putchar(int c);
extern int xmon_getchar(void);
-extern void xmon_puts(const char *);
+extern void xmon_fputs(const char *);
extern char *xmon_gets(char *, int);
extern void xmon_printf(const char *, ...);
extern void xmon_map_scc(void);
Index: linux-powerpc-git/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/xmon.c
+++ linux-powerpc-git/arch/powerpc/xmon/xmon.c
@@ -833,7 +833,7 @@ cmds(struct pt_regs *excp)
mdelay(2000);
return cmd;
case '?':
- xmon_puts(help_string);
+ fputs(help_string, stdout);
break;
case 'b':
bpt_cmds();
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during boot on PowerBook G3 in 0.0 seconds
From: Benjamin Herrenschmidt @ 2007-07-25 2:07 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Rutger Nijlunsing
In-Reply-To: <20070724185946.722f34b5.kim.phillips@freescale.com>
> for the enumerated PHYs. As the original commit comment states, I was
> getting these messages:
>
> prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
> prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01
Well, I would say it's a bug to try to translate addresses accross such
a boundary. Thus the PHY enumeration code is bogus.
> > I also wonder why it hangs on the powerbook... Rutger, I would expect to
> > see that complaint warning with the reverted patch, what does it say ?
> >
> > My Wallstreet (also based on Grackle) doesn't have the problem. Also can
> > you send me a tarball of /proc/device-tree ?
>
> I don't have any of those machines, but it seems that older kernels
> running on the Lombard emitted:
>
> device-tree: Duplicate name in /cpus/PowerPC,750@0, renamed to "l2-cache#1"
That's a different matter.
> messages*. Experimenting with adding two chosen nodes (due to a prior
> thread on this list**) results in a hung kernel on the 8360 also, so
> perhaps they're related (and the kernel's tolerance to duplicate
> entries has changed, which explains where I had seen the chosen node
> being renamed).
>
> but yeah, size-cells should be allowed to be 0 (even address-cells) and
> it may be the case that the Lombard needs some fixup code.
Ben.
^ permalink raw reply
* [PATCH] powerpc: Pegasos keyboard detection
From: Alan Curry @ 2007-07-25 1:28 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <200707230616.l6N6GaPg1212004@shell01.TheWorld.com>
As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
on the PegasosPPC. This is because of a feature/bug in the OF device tree:
the "device_type" attribute is an empty string instead of "8042" as the
kernel expects. This patch (against 2.6.22.1) adds a secondary detection
which looks for a device whose *name* is "8042" if there is no device whose
*type* is "8042".
Signed-off-by: Alan Curry <pacman@world.std.com>
--- arch/powerpc/kernel/setup-common.c.orig 2007-07-24 19:04:17.000000000 -0500
+++ arch/powerpc/kernel/setup-common.c 2007-07-24 19:06:36.000000000 -0500
@@ -487,6 +487,10 @@ int check_legacy_ioport(unsigned long ba
switch(base_port) {
case I8042_DATA_REG:
np = of_find_node_by_type(NULL, "8042");
+ /* Pegasos has no device_type on its 8042 node, look for the
+ * name instead */
+ if (!np)
+ np = of_find_node_by_name(NULL, "8042");
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
^ permalink raw reply
* Re: [patch 1/3] ps3: Disk Storage Driver
From: Andrew Morton @ 2007-07-25 1:21 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, Jens Axboe,
linux-kernel, Alessandro Rubini, linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <18086.41665.610756.139183@cargo.ozlabs.ibm.com>
On Wed, 25 Jul 2007 11:09:21 +1000 Paul Mackerras <paulus@samba.org> wrote:
> Also, I prefer the style where the ? and : operators have a space
> after them but not before them, rather than a space either side.
Could I point out that your likes and dislikes are immaterial? The whole
point here is to get kernel code looking consistent. That means that
basically everyone ends up doing things which they'd prefer not to do.
That certainly applies to me.
The idea is that the benefit of making things consistent exceeds the costs
of some individuals adopting styles which they are less used to.
So telling people what you do and don't like is simply irrelevant, except
for when it is used as an input in determining what the standard kernel
style is to be. (And that is largely determined by observing what we have
now).
And sure, major subsytems can and do go off and do their own thing - ia64
for example has done a lot of that, pretty consistently. The world hasn't
ended as a result.
^ permalink raw reply
* Re: Which Git Tree to pull from?
From: Paul Mackerras @ 2007-07-25 1:14 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D9010895F78D@EMPBEDEX.empirix.com>
Morrison, Tom writes:
> I am a little confused here. I've been working in an older (2.6.11)
>
> ppc release and haven't been paying much attention to where I
>
> should be getting the latest / stable git tree (for powerpc).
>
>
>
> I am working on an e500/8548 branch - it looks like Kumar's
>
> Git tree looks relatively new with lots of new patches...?
Unlike the bad old days when stuff used to accumulate for ages in
various trees without getting merged into Linus' tree, these days
stuff gets merged into Linus' tree and released in the official
releases pretty promptly. So Linus' releases are the canonical ones
for powerpc.
I have a tree where I put stuff that will be going to Linus at the
next opportunity, but currently it is identical to Linus' tree. It
doesn't accumulate any long-term difference from Linus' tree.
Kumar's tree currently has some stuff for 8xxx pci support that looks
to have missed the merge window that just closed. If you want that
specific stuff you can use his tree. That stuff should get merged
into Linus' tree once 2.6.23 has been released.
Paul.
^ permalink raw reply
* Re: [patch 1/3] ps3: Disk Storage Driver
From: Paul Mackerras @ 2007-07-25 1:09 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, linux-kernel,
Alessandro Rubini, linuxppc-dev, Jens Axboe, Geert Uytterhoeven,
Andrew Morton
In-Reply-To: <46A5E610.7000508@shadowen.org>
Andy Whitcroft writes:
> Ok, this is something we need to decide on. Currently we only ask for
> consistent spacing on all the mathematic operators. This is mostly as
> we do see a large number of non-spaced uses in defines and the like.
>
> I am happy to expand these tests so they are always spaced on both sides
> style if that is the preference.
It depends very much on the context - on the precedence and relative
importance of one operator with respect to other operators and the
statement as a whole. In general I prefer spaces around binary
operators, but there are situations where not putting spaces around
some operators can enhance the readability of the statement as a
whole.
If checkpatch.pl starts whinging about operators without spaces that
will just be yet another reason not to use it IMHO.
Also, I prefer the style where the ? and : operators have a space
after them but not before them, rather than a space either side.
Paul.
^ permalink raw reply
* Re: [PATCH] Re: 2.6.22-git hangs during boot on PowerBook G3 in 0.0 seconds
From: Kim Phillips @ 2007-07-24 23:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Rutger Nijlunsing
In-Reply-To: <1185234923.5439.158.camel@localhost.localdomain>
On Tue, 24 Jul 2007 09:55:23 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > After hours of fun git bisecting, finally found the commit to revert
> > > to make my PowerBook G3 Lombard boot again. This does not result in
> > > the complains the reverted commit was revering to.
> >
> > ..but it does on my MPC8360.
>
> In which circumstances are you trying to translate an address with no
> size cell ?
for the enumerated PHYs. As the original commit comment states, I was
getting these messages:
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01
> I also wonder why it hangs on the powerbook... Rutger, I would expect to
> see that complaint warning with the reverted patch, what does it say ?
>
> My Wallstreet (also based on Grackle) doesn't have the problem. Also can
> you send me a tarball of /proc/device-tree ?
I don't have any of those machines, but it seems that older kernels
running on the Lombard emitted:
device-tree: Duplicate name in /cpus/PowerPC,750@0, renamed to "l2-cache#1"
messages*. Experimenting with adding two chosen nodes (due to a prior
thread on this list**) results in a hung kernel on the 8360 also, so
perhaps they're related (and the kernel's tolerance to duplicate
entries has changed, which explains where I had seen the chosen node
being renamed).
but yeah, size-cells should be allowed to be 0 (even address-cells) and
it may be the case that the Lombard needs some fixup code.
Kim
* http://lists.infradead.org/pipermail/linux-pcmcia/2007-April/004503.html
** http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039758.html
^ permalink raw reply
* [PATCH] [POWERPC] iSeries: fix section mismatch warning in lpevents
From: Stephen Rothwell @ 2007-07-24 23:29 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
WARNING: vmlinux.o(.text+0x4f568): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.setup_hvlpevent_queue' and '.process_hvlpevents')
setup_hvlpevent_queue is only called from __init code so make it __init
as well.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/lpevents.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/lpevents.c b/arch/powerpc/platforms/iseries/lpevents.c
index 91df52a..34bdbbe 100644
--- a/arch/powerpc/platforms/iseries/lpevents.c
+++ b/arch/powerpc/platforms/iseries/lpevents.c
@@ -182,7 +182,7 @@ static int set_spread_lpevents(char *str)
}
__setup("spread_lpevents=", set_spread_lpevents);
-void setup_hvlpevent_queue(void)
+void __init setup_hvlpevent_queue(void)
{
void *eventStack;
--
1.5.2.4
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: fix section mismatch warnings
From: Stephen Rothwell @ 2007-07-24 23:27 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
WARNING: vmlinux.o(.text+0x8124): Section mismatch: reference to .init.text:.iSeries_early_setup (between '.__start_initialization_iSeries' and '.__mmu_off')
WARNING: vmlinux.o(.text+0x8128): Section mismatch: reference to .init.text:.early_setup (between '.__start_initialization_iSeries' and '.__mmu_off')
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/head_64.S | 7 ++++---
include/asm-powerpc/ppc_asm.h | 12 ++++++++++++
2 files changed, 16 insertions(+), 3 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 8cdd48e..1448af9 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -809,8 +809,9 @@ system_reset_iSeries:
mtmsrd r24 /* RI on */
lhz r24,PACAPACAINDEX(r13) /* Get processor # */
cmpwi 0,r24,0 /* Are we processor 0? */
- beq .__start_initialization_iSeries /* Start up the first processor */
- mfspr r4,SPRN_CTRLF
+ bne 1f
+ b .__start_initialization_iSeries /* Start up the first processor */
+1: mfspr r4,SPRN_CTRLF
li r5,CTRL_RUNLATCH /* Turn off the run light */
andc r4,r4,r5
mtspr SPRN_CTRLT,r4
@@ -1611,7 +1612,7 @@ _GLOBAL(generic_secondary_smp_init)
#endif
#ifdef CONFIG_PPC_ISERIES
-_STATIC(__start_initialization_iSeries)
+_INIT_STATIC(__start_initialization_iSeries)
/* Clear out the BSS */
LOAD_REG_IMMEDIATE(r11,__bss_stop)
LOAD_REG_IMMEDIATE(r8,__bss_start)
diff --git a/include/asm-powerpc/ppc_asm.h b/include/asm-powerpc/ppc_asm.h
index fa083d8..6532572 100644
--- a/include/asm-powerpc/ppc_asm.h
+++ b/include/asm-powerpc/ppc_asm.h
@@ -181,6 +181,18 @@ name: \
.type GLUE(.,name),@function; \
GLUE(.,name):
+#define _INIT_STATIC(name) \
+ .section ".text.init.refok"; \
+ .align 2 ; \
+ .section ".opd","aw"; \
+name: \
+ .quad GLUE(.,name); \
+ .quad .TOC.@tocbase; \
+ .quad 0; \
+ .previous; \
+ .type GLUE(.,name),@function; \
+GLUE(.,name):
+
#else /* 32-bit */
#define _GLOBAL(n) \
--
1.5.2.4
^ permalink raw reply related
* "do section mismatch check on full vmlinux" breaks powerpc build
From: Nathan Lynch @ 2007-07-24 22:41 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev
Hello-
2.6.23-rc1 breaks the build for 64-bit powerpc for me (using
maple_defconfig):
LD vmlinux.o
powerpc64-unknown-linux-gnu-ld: dynreloc miscount for
kernel/built-in.o, section .opd
powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
This is on a i386 host with:
powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.2
GNU ld version 2.16.1
Reverting the following commit fixes it:
commit 741f98fe298a73c9d47ed53703c1279a29718581
Author: Sam Ravnborg <sam@ravnborg.org>
Date: Tue Jul 17 10:54:06 2007 +0200
kbuild: do section mismatch check on full vmlinux
However, I see a possibly related binutils patch:
http://article.gmane.org/gmane.comp.gnu.binutils/33650
Will there be a kbuild fix for this or should I update my binutils?
^ permalink raw reply
* Re: support for MPC8220?
From: Robert Schwebel @ 2007-07-24 21:11 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C066B5B56@usa0300ms03.na.xerox.net>
On Mon, Jul 23, 2007 at 11:27:00AM -0400, Leisner, Martin wrote:
> Is there support for MPC8220 in current kernels?
8220? Are you sure? That part doesn't exist on the freescale site.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Patches for -rc2
From: Guennadi Liakhovetski @ 2007-07-24 21:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Hi Paul,
could we get these 2 patches:
http://patchwork.ozlabs.org/linuxppc/patch?id=12556
http://patchwork.ozlabs.org/linuxppc/patch?id=12538
in for -rc2 if there are no further objections, as seems to be the case.
They let linkstation work with new i2c API and thus fix a regression.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH] eHEA: net_poll support
From: Jeff Garzik @ 2007-07-24 20:37 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200707231605.03459.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> net_poll support for eHEA added
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
> ---
>
>
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 22 +++++++++++++++++++++-
> 2 files changed, 22 insertions(+), 2 deletions(-)
applied
^ permalink raw reply
* Re: [patch 1/3] ps3: Disk Storage Driver
From: Andrew Morton @ 2007-07-24 16:43 UTC (permalink / raw)
To: Jeff Garzik
Cc: Axboe, James E.J. Bottomley, linux-scsi, Jens, Jens Axboe,
linux-kernel, Alessandro Rubini, linuxppc-dev, Paul Mackerras,
Geert Uytterhoeven
In-Reply-To: <46A5F275.7060905@garzik.org>
On Tue, 24 Jul 2007 08:37:09 -0400 Jeff Garzik <jeff@garzik.org> wrote:
> Andy Whitcroft wrote:
> > Andrew Morton wrote:
> >
> >>> + start_sector = req->sector*priv->blocking_factor;
> >>> + sectors = req->nr_sectors*priv->blocking_factor;
> >> s/*/ * /. checkpatch missed this.
> >
> > Ok, this is something we need to decide on. Currently we only ask for
> > consistent spacing on all the mathematic operators. This is mostly as
> > we do see a large number of non-spaced uses in defines and the like.
> >
> > I am happy to expand these tests so they are always spaced on both sides
> > style if that is the preference.
>
> That is most definitely the preference: spaces surround operators.
>
I must say that I find it hard to object to
start = radix_tree_next_hole(&mapping->page_tree, offset, max+1);
but when the expression is more complex the spaces help.
^ permalink raw reply
* [PATCH] 86xx: Remove unnecessary loops_per_jiffy initialization code.
From: Jon Loeliger @ 2007-07-24 16:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 5b01ec7..566c311 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -326,23 +326,13 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
static void __init
mpc86xx_hpcn_setup_arch(void)
{
+#ifdef CONFIG_PCI
struct device_node *np;
+#endif
if (ppc_md.progress)
ppc_md.progress("mpc86xx_hpcn_setup_arch()", 0);
- np = of_find_node_by_type(NULL, "cpu");
- if (np != 0) {
- const unsigned int *fp;
-
- fp = of_get_property(np, "clock-frequency", NULL);
- if (fp != 0)
- loops_per_jiffy = *fp / HZ;
- else
- loops_per_jiffy = 50000000 / HZ;
- of_node_put(np);
- }
-
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
mpc86xx_add_bridge(np);
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 21/25] [POWERPC] 85xxCDS: Delay 8259 cascade hookup.
From: Kumar Gala @ 2007-07-24 15:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18085.59414.38125.30777@cargo.ozlabs.ibm.com>
On Jul 24, 2007, at 6:52 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> From: Randy Vinson <rvinson@mvista.com>
>
>> +device_initcall(mpc85xx_cds_8259_attach);
>
> I don't see any platform test in mpc85xx_cds_8259_attach to make sure
> it only does its stuff on suitable platforms. Looks like it needs
> one.
I've added a is_machine(mpc85xx_cds) into the patch in my tree to
handle this.
- k
^ permalink raw reply
* Re: Interrupts on xilinx ml403
From: Mirek23 @ 2007-07-24 15:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11758237.post@talk.nabble.com>
I will try to go further with that after trying Grant's suggestion. When I
still have a problem I will contact you.
Best Regards
Mirek
Misbah khan wrote:
>
> hi ..
>
> If you could send me the code and the config related doc . I could then be
> able to suggest you something. As per the understanding of the problem i
> guess you are not congiguring the interrupt controller properly. you have
> to use correct IRQ no for that ports then other configuration such as
> interrupt type, and whenever you service the interrupt you have to clear
> the interrupt etc are to be taken care ....Please see the interrupt
> controller register and do your settings correctly . If the same persists
> then you please send me the code and the documents then only i could give
> the exact explaination on this
>
> ----misbah
>
> Mirek23 wrote:
>>
>> Dear All,
>>
>> I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
>> evaluation board.
>>
>> I have setup the virtex-4 FPGA to deal with Themac and Serial interfaces.
>> As input/output devices I have chosen 8 LEDs and DIP Switches.
>>
>> With such a configuration I am able to control from Linux user
>> applications via GPIO driver the LEDs and DIP Switches.
>>
>> Right now I just wanted to make use of the interrupts. I have configured
>> the Dip switches to use interrupt. The interrupt accoures when the DIP
>> Switches state has changed.
>>
>> In the BSP generated by EDK 9.1 I see that macro :
>>
>> #define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1
>>
>> has changed from zero to one.
>> The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before.
>> This is due to the fact that
>> TEMAC uses one interrupt line.
>>
>> Does it mean that DIP Switches do not use INTC interrupt controller?
>> How to handle the DIP Switches interrupt?
>> Does the Interrupt handler routine have to acknowledge the interrupt from
>> Dip Switches?
>>
>> Many thanks in advance for any hint on that.
>>
>> Best Regards
>>
>> Mirek
>>
>>
>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11765540
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Interrupts on xilinx ml403
From: Mirek23 @ 2007-07-24 15:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40707200812w3427c12dwd10b08c8433af2fc@mail.gmail.com>
Hi Grant,
Thanks for the suggestion. I will fix that and see what the EDK will
generate.
Best Regards
Mirek
Grant Likely-2 wrote:
>
> On 7/20/07, Mirek23 <miroslaw.dach@psi.ch> wrote:
>> Does it mean that DIP Switches do not use INTC interrupt controller?
>> How to handle the DIP Switches interrupt?
>> Does the Interrupt handler routine have to acknowledge the interrupt from
>> Dip Switches?
>
> It probably means that the GPIO irq out line is not hooked up to your
> INTC in the system.mhs file.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11765478
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