LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:53 UTC (permalink / raw)
  To: Josh Boyer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071015134813.6aacdcca@weaponx.rchland.ibm.com>

Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:27:23 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Valentine Barshak wrote:
>>> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
>>> These PHY chips are used on PowerPC 440EPx boards.
>>> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>>>
>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>>  drivers/net/ibm_newemac/phy.c |   39 +++++++++++++++++++++++++++++++++++++++
>>>  1 files changed, 39 insertions(+)
>>>
>>> --- linux.orig/drivers/net/ibm_newemac/phy.c	2007-06-15 21:45:18.000000000 +0400
>>> +++ linux/drivers/net/ibm_newemac/phy.c	2007-06-15 20:45:15.000000000 +0400
>>> @@ -306,8 +306,47 @@
>>>  	.ops		= &cis8201_phy_ops
>>>  };
>>>  
>>> +static struct mii_phy_def bcm5248_phy_def = {
>>> +
>>> +	.phy_id		= 0x0143bc00,
>>> +	.phy_id_mask	= 0x0ffffff0,
>>> +	.name		= "BCM5248 10/100 SMII Ethernet",
>>> +	.ops		= &generic_phy_ops
>>> +};
>>> +
>>> +static int m88e1111_init(struct mii_phy *phy)
>>> +{
>>> +	printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>>> +	phy_write(phy, 0x14, 0x0ce3);
>>> +	phy_write(phy, 0x18, 0x4101);
>>> +	phy_write(phy, 0x09, 0x0e00);
>>> +	phy_write(phy, 0x04, 0x01e1);
>>> +	phy_write(phy, 0x00, 0x9140);
>>> +	phy_write(phy, 0x00, 0x1140);
>>> +
>>> +	return  0;
>>> +}
>>> +
>>> +static struct mii_phy_ops m88e1111_phy_ops = {
>>> +	.init		= m88e1111_init,
>>> +	.setup_aneg	= genmii_setup_aneg,
>>> +	.setup_forced	= genmii_setup_forced,
>>> +	.poll_link	= genmii_poll_link,
>>> +	.read_link	= genmii_read_link
>>> +};
>>> +
>>> +static struct mii_phy_def m88e1111_phy_def = {
>>> +
>>> +	.phy_id		= 0x01410CC0,
>>> +	.phy_id_mask	= 0x0ffffff0,
>>> +	.name		= "Marvell 88E1111 Ethernet",
>>> +	.ops		= &m88e1111_phy_ops,
>>> +};
>>> +
>>>  static struct mii_phy_def *mii_phy_table[] = {
>>>  	&cis8201_phy_def,
>>> +	&bcm5248_phy_def,
>>> +	&m88e1111_phy_def,
>>>  	&genmii_phy_def,
>> Seems sane to me -- ACK -- but we have multiple people sending me 
>> patches for a single driver.  That's normal for janitorial cleanups 
>> across the whole tree, but discouraged when multiple people are actively 
>> working on the same driver.
>>
>> Please coordinate, and have ONE person send me patches...
> 
> Who else is sending you patches?  Valentine is the only one I've seen
> send patches recently...

It's a zoo :)
Al Viro (3):
       typo in ibm_newemac/rgmii.c
       skb->tail in ibm_newemac should be skb_tail_pointer()
       ibm_newemac annotations (iomem, NULL noise)

David Gibson (1):
       Device tree aware EMAC driver

Michael Ellerman (3):
       Update ibm_newemac to use dcr_host_t.base
       Add dcr_host_t.base in dcr_read()/dcr_write()
       Use dcr_host_t.base in dcr_unmap()

Roland Dreier (2):
       ibm_new_emac: Nuke SET_MODULE_OWNER() use
       ibm_emac: Convert to use napi_struct independent of struct net_device

vbarshak@ru.mvista.com (1):
       Fix typo in new EMAC driver.

^ permalink raw reply

* Re: [PATCH v2] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
From: Jeff Garzik @ 2007-10-15 18:51 UTC (permalink / raw)
  To: Emil Medve; +Cc: netdev, akpm, leoli, linuxppc-dev
In-Reply-To: <1192455830-1028-1-git-send-email-Emilian.Medve@Freescale.com>

Emil Medve wrote:
> drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
> drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this function)
> drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported only once
> drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
> make[2]: *** [drivers/net/ucc_geth.o] Error 1
> 
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
> 
> Here is a convenient link for the culprit patch: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
> 
> netdev-2.6> scripts/checkpatch.pl 0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch 
> Your patch has no obvious style problems and is ready for submission.

applied

^ permalink raw reply

* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 18:48 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4713B10B.5000607@garzik.org>

On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> Valentine Barshak wrote:
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> > 
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> >  drivers/net/ibm_newemac/phy.c |   39 +++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 39 insertions(+)
> > 
> > --- linux.orig/drivers/net/ibm_newemac/phy.c	2007-06-15 21:45:18.000000000 +0400
> > +++ linux/drivers/net/ibm_newemac/phy.c	2007-06-15 20:45:15.000000000 +0400
> > @@ -306,8 +306,47 @@
> >  	.ops		= &cis8201_phy_ops
> >  };
> >  
> > +static struct mii_phy_def bcm5248_phy_def = {
> > +
> > +	.phy_id		= 0x0143bc00,
> > +	.phy_id_mask	= 0x0ffffff0,
> > +	.name		= "BCM5248 10/100 SMII Ethernet",
> > +	.ops		= &generic_phy_ops
> > +};
> > +
> > +static int m88e1111_init(struct mii_phy *phy)
> > +{
> > +	printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> > +	phy_write(phy, 0x14, 0x0ce3);
> > +	phy_write(phy, 0x18, 0x4101);
> > +	phy_write(phy, 0x09, 0x0e00);
> > +	phy_write(phy, 0x04, 0x01e1);
> > +	phy_write(phy, 0x00, 0x9140);
> > +	phy_write(phy, 0x00, 0x1140);
> > +
> > +	return  0;
> > +}
> > +
> > +static struct mii_phy_ops m88e1111_phy_ops = {
> > +	.init		= m88e1111_init,
> > +	.setup_aneg	= genmii_setup_aneg,
> > +	.setup_forced	= genmii_setup_forced,
> > +	.poll_link	= genmii_poll_link,
> > +	.read_link	= genmii_read_link
> > +};
> > +
> > +static struct mii_phy_def m88e1111_phy_def = {
> > +
> > +	.phy_id		= 0x01410CC0,
> > +	.phy_id_mask	= 0x0ffffff0,
> > +	.name		= "Marvell 88E1111 Ethernet",
> > +	.ops		= &m88e1111_phy_ops,
> > +};
> > +
> >  static struct mii_phy_def *mii_phy_table[] = {
> >  	&cis8201_phy_def,
> > +	&bcm5248_phy_def,
> > +	&m88e1111_phy_def,
> >  	&genmii_phy_def,
> 
> Seems sane to me -- ACK -- but we have multiple people sending me 
> patches for a single driver.  That's normal for janitorial cleanups 
> across the whole tree, but discouraged when multiple people are actively 
> working on the same driver.
> 
> Please coordinate, and have ONE person send me patches...

Who else is sending you patches?  Valentine is the only one I've seen
send patches recently...

josh

^ permalink raw reply

* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Scott Wood @ 2007-10-15 18:47 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071015155730.GA30008@localhost.localdomain>

On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
> >    Is the entity described as "localbus" indeed so *board* specific?
> 
> That's what booting-without-of.txt gives as an example.

The board should have been left out of that.  Your compatible should be
something like "fsl,mpc8568-localbus", possibly with some canonical mpc85xx
chip as well, chosen to represent 85xx localbus in general.

-Scott

^ permalink raw reply

* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-15 18:46 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <12696686.post@talk.nabble.com>


Hello

I'm also working with ML403 board from Xilinx and have the same problem as
you. The boot process stops after decompressing with the message "Now
booting the kernel". We also used gcc-4.1.0 for the cross compilation. So, I
would be glad to know, which gcc version have you used to get a working
kernel!

Thanks,
Andreas



Junqiang Hu wrote:
> 
> 
> Hi Grant,
> 
>    Thank you so much for the reply!  Fortunately I got it work now -- it's
> the crosstool compiler problem.  Originally I was using gcc-4.1.0, yet
> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
> miscompile the kernel, so I changed to another version, and now I can let
> it go!
> 
>   Right now still not fully booted because of the SystemACE problem, or
> maybe the partition is not correct.  I'm still working on it, hopefully to
> get it solved soon :-)
> 
> Thanks,
> -J.
> 
> 
> Grant Likely-2 wrote:
>> 
>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>
>>>
>>> Dear friends,
>>>
>>>    I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>>  board.  The Linux version I'm using is 2.4; the cross-compiler is
>>> gcc-4.1.0, glibc 2.3.6.  When booting the kernel, it shows:
>>>       loaded at:     00400000 004B51E4
>>>       board data at: 00000000 00000018
>>>       relocated to:  0040526C 00405284
>>>       zimage at:     00405B2B 004B177C
>>>       avail ram:     004B6000 60000000
>> 
>> I strongly recommend moving to a 2.6 kernel.  Recent mainline has
>> support for the Xilinx ppc built in.
>>>
>>>       Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>> rw
>>>       Uncompressing Linux...done.
>>>       Now booting the kernel
>>>
>>> Then it hangs. First it seems to me that the "avail ram" is not correct,
>>> since I configured only 32MB SDRAM.  Moreover, if it's first powered on,
>>> the
>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>> investigate
>>> the problem using xmd.  When  launched, it says:
>> 
>> (If you're using u-boot) You might have a mismatch between the board
>> info structure used by u-boot and the one used by Linux.
>> 
>> Also, you should use your debugger to inspect the __log_buf memory of
>> the kernel.  A common problem is the kernel starts booting, but the
>> console is setup incorrectly and so you see nothing.  But, you can
>> read the console output directly from memory if you look at the
>> __log_buf region (find the address in the System.map file; you might
>> need to subtract 0xC0000000 from the address to view the memory)
>> 
>> Cheers,
>> 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/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13219154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: [PATCH take2] [POWERPC] i2c: adds support for i2c bus on 8xx
From: Scott Wood @ 2007-10-15 18:31 UTC (permalink / raw)
  To: Jochen Friedrich
  Cc: Carsten Juttner, linux-kernel, i2c, linuxppc-embedded@ozlabs.org
In-Reply-To: <47134A94.60606@scram.de>

On Mon, Oct 15, 2007 at 01:10:12PM +0200, Jochen Friedrich wrote:
> Using the port of 2.4 code from Vitaly Bordug <vitb@kernel.crashing.org>
> and the actual algorithm used by the i2c driver of the DBox code on
> cvs.tuxboc.org from Tmbinc, Gillem (htoa@gmx.net). Renamed
> i2c-algo-8xx.c to i2c-algo-cpm.c and i2c-rpx.c to i2c-8xx.c. Added
> original i2c-rpx.c as i2c-8xx-ppc.c for pre-OF (arch ppc) devices.

Do we really need to be adding features for arch/ppc at this point?  It'll
be going away in June.  arch/ppc-specific things outside of arch/ppc itself
will also be more likely to be missed in the removal.

Also, please post inline rather than as an attachment; attachments are
harder to quote in a reply.

> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
> index 8848e63..a526c02 100644
> --- a/arch/powerpc/boot/dts/mpc885ads.dts
> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
> @@ -213,6 +213,15 @@
>  				fsl,cpm-command = <0080>;
>  				linux,network-index = <2>;
>  			};
> +
> +			i2c@860 {
> +				device_type = "i2c";

No device_type.

> +				compatible = "fsl-i2c-cpm";

Should be fsl,cpm-i2c.  Is cpm2 i2c the same?  If not, it should be
fsl,cpm1-i2c.  It's probably best to specify it anyway, along with
fsl,mpc885-i2c.

> diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> index 2cf1b6a..350018b 100644
> --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> @@ -175,6 +175,12 @@ static void __init init_ioports(void)
>  
>  	/* Set FEC1 and FEC2 to MII mode */
>  	clrbits32(&mpc8xx_immr->im_cpm.cp_cptr, 0x00000180);
> +
> +#ifdef CONFIG_I2C_8XX
> +	setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x00000030);
> +	setbits32(&mpc8xx_immr->im_cpm.cp_pbdir, 0x00000030);
> +	setbits16(&mpc8xx_immr->im_cpm.cp_pbodr, 0x0030);
> +#endif

Please add this to mpc885ads_pins, rather than poking the registers
directly.  The relevant lines are:

	{CPM_PORTB, 26, CPM_PIN_OUTPUT},
	{CPM_PORTB, 27, CPM_PIN_OUTPUT},

> +static const char *i2c_regs = "regs";
> +static const char *i2c_pram = "pram";
> +static const char *i2c_irq = "interrupt";
> +
> +static int __init fsl_i2c_cpm_of_init(void)
> +{
> +	struct device_node *np;
> +	unsigned int i;
> +	struct platform_device *i2c_dev;
> +	int ret;
> +
> +	for (np = NULL, i = 0;
> +	     (np = of_find_compatible_node(np, "i2c", "fsl-i2c-cpm")) != NULL;
> +	     i++) {

Why not just make an of_platform device instead of this glue code?

> diff --git a/drivers/i2c/algos/Kconfig b/drivers/i2c/algos/Kconfig
> index 014dfa5..7a8200e 100644
> --- a/drivers/i2c/algos/Kconfig
> +++ b/drivers/i2c/algos/Kconfig
> @@ -14,6 +14,18 @@ config I2C_ALGOBIT
>  	  This support is also available as a module.  If so, the module 
>  	  will be called i2c-algo-bit.
>  
> +config I2C_ALGOCPM
> +	tristate "I2C MPC8xx CPM and MPC8260 CPM2 interfaces"
> +	depends on ( 8xx || 8260 ) && I2C
> +	help
> +	  CPM I2C Algorithm, supports the CPM I2C interface for mpc8xx
> +	  and mpc8260 CPUs. Say Y if you own a CPU of this class 

What if I'm just borrowing it? :-)

> +static irqreturn_t cpm_iic_interrupt(int irq, void *dev_id)
> +{
> +	struct i2c_adapter *adap;
> +	struct i2c_algo_cpm_data *cpm;
> +	i2c8xx_t *i2c;
> +	int i;
> +
> +	adap = (struct i2c_adapter *) dev_id;
> +	cpm = adap->algo_data;
> +	i2c = cpm->i2c;
> +
> +	/* Clear interrupt.
> +	 */
> +	i = in_8(&i2c->i2c_i2cer);
> +	out_8(&i2c->i2c_i2cer, i);
> +
> +	if (cpm_debug)
> +		dev_dbg(&adap->dev, "Interrupt: %x\n", i);
> +
> +	/* Get 'me going again.
> +	 */
> +	wake_up_interruptible(&cpm->iic_wait);
> +
> +	return IRQ_HANDLED;
> +}

Should only return IRQ_HANDLED if the event register was non-zero.

> +static int cpm_iic_init(struct i2c_adapter *adap)
> +{
> +	struct i2c_algo_cpm_data *cpm = adap->algo_data;
> +	iic_t *iip = cpm->iip;
> +	i2c8xx_t *i2c = cpm->i2c;
> +	unsigned char brg;
> +	int ret, i;
> +
> +	if (cpm_debug)
> +		dev_dbg(&adap->dev, "cpm_iic_init()\n");

Can you fold the if statement into a macro?  Or just do a raw dev_dbg with
no test, like most drivers do.

> +	ret = 0;
> +	init_waitqueue_head(&cpm->iic_wait);
> +	mutex_init(&cpm->iic_mutex);
> +	/* Initialize the parameter ram.
> +	 * We need to make sure many things are initialized to zero,
> +	 * especially in the case of a microcode patch.
> +	 */
> +	out_be32(&iip->iic_rstate, 0);
> +	out_be32(&iip->iic_rdp, 0);
> +	out_be16(&iip->iic_rbptr, 0);
> +	out_be16(&iip->iic_rbc, 0);
> +	out_be32(&iip->iic_rxtmp, 0);
> +	out_be32(&iip->iic_tstate, 0);
> +	out_be32(&iip->iic_tdp, 0);
> +	out_be16(&iip->iic_tbptr, 0);
> +	out_be16(&iip->iic_tbc, 0);
> +	out_be32(&iip->iic_txtmp, 0);

This appears to be done twice, here and in cpm_reset_iic_params.

> +		u16 v = mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_INIT_TRX) | CPM_CR_FLG;

Should use fsl,cpm-command rather than hardcoded constants.

> +	/* Select an arbitrary address.  Just make sure it is unique.
> +	 */
> +	out_8(&i2c->i2c_i2add, 0xfe);

It's a 7-bit address...  and are you sure that 0x7e is unique?  Does this
driver even support slave operation?

> +	/* Make clock run at 60 kHz.
> +	 */
> +	/* brg = ppc_proc_freq / (32 * 2 * 60000) - 3; */
> +	brg = 7;
> +	out_8(&i2c->i2c_i2brg, brg);

Why is this hardcoded?

> +	out_8(&i2c->i2c_i2mod, 0x00);
> +	out_8(&i2c->i2c_i2com, 0x01);	/* Master mode */
> +
> +	/* Disable interrupts.
> +	 */
> +	out_8(&i2c->i2c_i2cmr, 0);
> +	out_8(&i2c->i2c_i2cer, 0xff);
> +
> +	/* Allocate TX and RX buffers */
> +	for (i = 0; i < CPM_MAXBD; i++) {
> +		cpm->rxbuf[i] = (unsigned char *)dma_alloc_coherent(
> +			NULL, CPM_MAX_READ + 1, &cpm->rxdma[i], GFP_KERNEL);
> +		if (!cpm->rxbuf[i]) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +		cpm->txbuf[i] = (unsigned char *)dma_alloc_coherent(
> +			NULL, CPM_MAX_READ + 1, &cpm->txdma[i], GFP_KERNEL);
> +		if (!cpm->txbuf[i]) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +	}
> +
> +	/* Install interrupt handler.
> +	 */
> +	if (request_irq(cpm->irq, cpm_iic_interrupt, 0, "8xx_i2c", adap)) {

cpm-i2c, not 8xx.

> +		ret = -EIO;
> +		goto out;
> +	}
> +
> +	return 0;
> +out:
> +	for (i = 0; i < CPM_MAXBD; i++) {
> +		if (cpm->rxbuf[i]) dma_free_coherent(NULL, CPM_MAX_READ + 1,
> +			cpm->rxbuf[i], cpm->rxdma[i]);
> +		if (cpm->txbuf[i]) dma_free_coherent(NULL, CPM_MAX_READ + 1,
> +			cpm->txbuf[i], cpm->txdma[i]);
> +	}

Please put a newline between the if test and the if body.

> +static void force_close(struct i2c_adapter *adap)
> +{
> +	struct i2c_algo_cpm_data *cpm = adap->algo_data;
> +	i2c8xx_t *i2c = cpm->i2c;
> +	if (cpm->reloc == 0) {	/* micro code disabled */
> +		cpm8xx_t *cp = cpm->cp;
> +		u16 v =
> +		    mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_CLOSE_RXBD) | CPM_CR_FLG;

Why only if there's no microcode relocation?

> +static void cpm_parse_message(struct i2c_adapter *adap, struct i2c_msg *pmsg,
> +	int num, int tx, int rx)
> +{
> +	cbd_t *tbdf, *rbdf;
> +	u_char addr;
> +	u_char *tb;
> +	u_char *rb;
> +	struct i2c_algo_cpm_data *cpm = adap->algo_data;
> +	iic_t *iip = cpm->iip;
> +	int i, dscan;
> +
> +	tbdf = (cbd_t *) cpm_dpram_addr(in_be16(&iip->iic_tbase));
> +	rbdf = (cbd_t *) cpm_dpram_addr(in_be16(&iip->iic_rbase));
> +
> +	/* This chip can't do zero lenth writes. However, the i2c core uses

s/lenth/length/

> +	if (pmsg->flags & I2C_M_RD) {
> +		if (cpm_debug)
> +			dev_dbg(&adap->dev, "rx sc %04x, rx sc %04x\n",
> +				tbdf[tx].cbd_sc, rbdf[rx].cbd_sc);
> +		if (tbdf[tx].cbd_sc & BD_SC_NAK) {
> +			if (cpm_debug)
> +				dev_dbg(&adap->dev, "IIC read; no ack\n");
> +			if (pmsg->flags & I2C_M_IGNORE_NAK)
> +				return 0;
> +			else
> +				return -EREMOTEIO;

s/EREMOTEIO/EIO/

> +static int cpm_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +{
> +	struct i2c_algo_cpm_data *cpm = adap->algo_data;
> +	i2c8xx_t *i2c = cpm->i2c;
> +	iic_t *iip = cpm->iip;
> +	struct i2c_msg *pmsg, *rmsg;
> +	int ret, i;
> +	int tptr;
> +	int rptr;
> +	cbd_t *tbdf, *rbdf;
> +
> +	if (num > CPM_MAXBD)
> +		return -EREMOTEIO;
> +
> +	/* Check if we have any oversized READ requests */
> +	for (i = 0; i < num; i++) {
> +		pmsg = &msgs[i];
> +		if (pmsg->len >= CPM_MAX_READ)
> +			return -EREMOTEIO;
> +	}

s/EREMOTEIO/EINVAL/

> +
> +	mutex_lock(&cpm->iic_mutex);
> +
> +	/* check for and use a microcode relocation patch */
> +	if (cpm->reloc)
> +		cpm_reset_iic_params(cpm);

On every transfer?

> +	while (tptr < num) {
> +		/* Check for outstanding messages */
> +		dev_dbg(&adap->dev, "test ready.\n");
> +		if (!(tbdf[tptr].cbd_sc & BD_SC_READY)) {
> +			dev_dbg(&adap->dev, "ready.\n");
> +			rmsg = &msgs[tptr];
> +			ret = cpm_check_message(adap, rmsg, tptr, rptr);
> +			tptr++;
> +			if (rmsg->flags & I2C_M_RD)
> +				rptr++;
> +			if (ret) {
> +				force_close(adap);
> +				mutex_unlock(&cpm->iic_mutex);
> +				return -EREMOTEIO;

s/-EREMOTEIO/ret/

> +config I2C_8XX
> +	tristate "MPC8xx CPM with Open Firmware"

It's not really Open Firmware... just a flat device tree.

> diff --git a/drivers/i2c/busses/i2c-8xx.c b/drivers/i2c/busses/i2c-8xx.c
> new file mode 100644
> index 0000000..c38b52e
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-8xx.c
> @@ -0,0 +1,170 @@
> +/*
> + * Embedded Planet RPX Lite MPC8xx CPM I2C interface.
> + * Copyright (c) 1999 Dan Malek (dmalek@jlc.net).
> + *
> + * moved into proper i2c interface;
> + * Brad Parker (brad@heeltoe.com)
> + *
> + * (C) 2007 Montavista Software, Inc.
> + * Vitaly Bordug <vitb@kernel.crashing.org>
> + *
> + * RPX lite specific parts of the i2c interface
> + * Update:  There actually isn't anything RPXLite-specific about this module.
> + * This should work for most any 8xx board.  The console messages have been
> + * changed to eliminate RPXLite references.

So let's change the title at the top of the file...

> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/stddef.h>
> +#include <linux/platform_device.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c-algo-cpm.h>
> +#include <linux/of_device.h>

Why are you including platform_device, and running glue code in fsl_soc.c,
if this is an of_platform driver?

> +#include <linux/of_platform.h>
> +#include <asm/mpc8xx.h>
> +#include <asm/commproc.h>
> +#include <asm/fs_pd.h>
> +
> +
> +struct m8xx_i2c {
> +	char *base;
> +	struct of_device *ofdev;
> +	struct i2c_adapter adap;
> +	struct i2c_algo_cpm_data *algo_8xx;
> +};
> +
> +static struct i2c_algo_cpm_data m8xx_data;
> +
> +static const struct i2c_adapter m8xx_ops = {
> +	.owner		= THIS_MODULE,
> +	.name		= "i2c-8xx",
> +	.id		= I2C_HW_MPC8XX_EPON,
> +	.algo_data	= &m8xx_data,
> +	.dev.parent	= &platform_bus,
> +	.class		= I2C_CLASS_HWMON,
> +};

It's not on the platform bus; it's on the soc of_platform bus.  Why is this
embedded in the i2c_adapter struct anyway?  i2c_adapter should hold a
pointer to whatever the probe function gives you.

> +	data->irq = irq_of_parse_and_map(np, 0);
> +	if (data->irq < 0)
> +		return -EINVAL;
> +
> +	if (of_address_to_resource(np, 1, &r))
> +		return -EINVAL;
> +
> +	data->iip = ioremap(r.start, r.end - r.start + 1);
> +	if (data->iip == NULL)
> +		return -EINVAL;
> +
> +	/* Check for and use a microcode relocation patch.
> +	 */
> +	data->reloc = data->iip->iic_rpbase;
> +	if (data->reloc)
> +		data->iip = (iic_t *)&cp->cp_dpmem[data->iip->iic_rpbase];
> +
> +	if (of_address_to_resource(np, 0, &r))
> +		return -EINVAL;
> +
> +	data->i2c = ioremap(r.start, r.end - r.start + 1);

Use of_iomap.

> +	if (data->i2c == NULL)
> +		return -EINVAL;
> +
> +	/* Allocate space for two transmit and two receive buffer
> +	 * descriptors in the DP ram.
> +	 */
> +	data->dp_addr = cpm_dpalloc(sizeof(cbd_t) * 4, 8);

Please use the new muram_dpalloc name.

> +	if (!data->dp_addr)
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
> +static int i2c_8xx_probe(struct of_device *ofdev,
> +			 const struct of_device_id *match)
> +{
> +	int result;
> +	struct m8xx_i2c *i2c;
> +
> +	i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
> +	if (!i2c)
> +		return -ENOMEM;
> +
> +	i2c->ofdev = ofdev;
> +	i2c->algo_8xx = &m8xx_data;
> +
> +	m8xx_iic_init(i2c);
> +
> +	dev_set_drvdata(&ofdev->dev, i2c);
> +
> +	i2c->adap = m8xx_ops;
> +	i2c_set_adapdata(&i2c->adap, i2c);
> +	i2c->adap.dev.parent = &ofdev->dev;
> +
> +	result = i2c_cpm_add_bus(&i2c->adap);
> +	if (result < 0) {
> +		printk(KERN_ERR "i2c-8xx: Unable to register with I2C\n");
> +		kfree(i2c);
> +	}
> +
> +	return result;
> +}
> +
> +static int i2c_8xx_remove(struct of_device *ofdev)
> +{
> +	struct m8xx_i2c *i2c = dev_get_drvdata(&ofdev->dev);
> +
> +	i2c_cpm_del_bus(&i2c->adap);
> +	dev_set_drvdata(&ofdev->dev, NULL);
> +
> +	kfree(i2c);
> +	return 0;
> +}
> +
> +static struct of_device_id i2c_8xx_match[] = {
> +	{
> +		.type = "i2c",
> +		.compatible = "fsl,i2c-cpm",
> +	},
> +	{},
> +};
> +

Why is an 8xx driver matching all i2c cpm (i.e. what about cpm2)?

-Scot

^ permalink raw reply

* Re: [PATCH 1/5] Update ibm_newemac to use dcr_host_t.base
From: Jeff Garzik @ 2007-10-15 18:34 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <33ee227bae85a8d7ccde69a717cff47000888354.1192440801.git.michael@ellerman.id.au>

Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the
> ibm_newemac code, rather than storing it separately.
> 
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>  drivers/net/ibm_newemac/mal.c |    9 +++++----
>  drivers/net/ibm_newemac/mal.h |    5 ++---
>  2 files changed, 7 insertions(+), 7 deletions(-)

applied 1-5

^ permalink raw reply

* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-15 18:33 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <4713A616.3090103@ru.mvista.com>

Hello, I wrote:

>>@@ -797,6 +796,53 @@ void __init clocksource_init(void)
>> 	       clock->name, clock->mult, clock->shift);
>> }

>>+static int decrementer_set_next_event(unsigned long evt,
>>+				      struct clock_event_device *dev)
>>+{
>>+	set_dec(evt);

>     I'd use (evt - 1) since the interrupt gets generated at 0xffffffff count, 
> not 0 (on classic CPUs).  With you removing of the code that compensated for 
> the errors, they will accumulate.  And no, this wouldn't be enough anyway, 
> since on 40x and Book E you'll need to set it for evt anyway, since the 
> interrupt happens at 0 count...

    What that means is that the off-by-one-clock drift is introduced for 
classic CPUs (not 40x or Book E which interrupt at 0).  And this has dealt 
with months ago in the clockevent driver in the -rt patch.  So much for my 
efforts...

>     NAK the patch.

    It's too late for NAKs -- I should've given these patches more attention 
(yet I was in hospital for 1.5 months).

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:27 UTC (permalink / raw)
  To: Valentine Barshak, jwboyer, Michael Ellerman; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071015175717.GA4602@ru.mvista.com>

Valentine Barshak wrote:
> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC 440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
>  drivers/net/ibm_newemac/phy.c |   39 +++++++++++++++++++++++++++++++++++++++
>  1 files changed, 39 insertions(+)
> 
> --- linux.orig/drivers/net/ibm_newemac/phy.c	2007-06-15 21:45:18.000000000 +0400
> +++ linux/drivers/net/ibm_newemac/phy.c	2007-06-15 20:45:15.000000000 +0400
> @@ -306,8 +306,47 @@
>  	.ops		= &cis8201_phy_ops
>  };
>  
> +static struct mii_phy_def bcm5248_phy_def = {
> +
> +	.phy_id		= 0x0143bc00,
> +	.phy_id_mask	= 0x0ffffff0,
> +	.name		= "BCM5248 10/100 SMII Ethernet",
> +	.ops		= &generic_phy_ops
> +};
> +
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> +	printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> +	phy_write(phy, 0x14, 0x0ce3);
> +	phy_write(phy, 0x18, 0x4101);
> +	phy_write(phy, 0x09, 0x0e00);
> +	phy_write(phy, 0x04, 0x01e1);
> +	phy_write(phy, 0x00, 0x9140);
> +	phy_write(phy, 0x00, 0x1140);
> +
> +	return  0;
> +}
> +
> +static struct mii_phy_ops m88e1111_phy_ops = {
> +	.init		= m88e1111_init,
> +	.setup_aneg	= genmii_setup_aneg,
> +	.setup_forced	= genmii_setup_forced,
> +	.poll_link	= genmii_poll_link,
> +	.read_link	= genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> +	.phy_id		= 0x01410CC0,
> +	.phy_id_mask	= 0x0ffffff0,
> +	.name		= "Marvell 88E1111 Ethernet",
> +	.ops		= &m88e1111_phy_ops,
> +};
> +
>  static struct mii_phy_def *mii_phy_table[] = {
>  	&cis8201_phy_def,
> +	&bcm5248_phy_def,
> +	&m88e1111_phy_def,
>  	&genmii_phy_def,

Seems sane to me -- ACK -- but we have multiple people sending me 
patches for a single driver.  That's normal for janitorial cleanups 
across the whole tree, but discouraged when multiple people are actively 
working on the same driver.

Please coordinate, and have ONE person send me patches...

^ permalink raw reply

* [PATCH] PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
From: Valentine Barshak @ 2007-10-15 17:58 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: netdev
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>

This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/platforms/44x/Kconfig |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

--- linux.orig/arch/powerpc/platforms/44x/Kconfig	2007-07-30 15:05:50.000000000 +0400
+++ linux/arch/powerpc/platforms/44x/Kconfig	2007-07-30 17:59:05.000000000 +0400
@@ -48,10 +48,9 @@
 config 440EPX
 	bool
 	select PPC_FPU
-# Disabled until the new EMAC Driver is merged.
-#	select IBM_NEW_EMAC_EMAC4
-#	select IBM_NEW_EMAC_RGMII
-#	select IBM_NEW_EMAC_ZMII
+	select IBM_NEW_EMAC_EMAC4
+	select IBM_NEW_EMAC_RGMII
+	select IBM_NEW_EMAC_ZMII
 
 config 440GP
 	bool

^ permalink raw reply

* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-15 18:07 UTC (permalink / raw)
  To: benh
  Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel,
	Steven Rostedt
In-Reply-To: <1190858397.11034.22.camel@pasglop>

Benjamin Herrenschmidt wrote:

>>>I'm about to release a new -rt patch based on -rc8. This patch series
>>>blew up totally in trying to get it applied. I'm leaving it out, so after
>>>I release the next series, could you update these patches.

>>    No wonder here: the -rt patch already has much of this code since around 
>>2.6.21.  They have been submitted by me, mostly... and this patchset is 
>>against the Linus' tree.

> Proper approach is to rip off what is altready in -rt there and replace
> it with Tony patch set.

    Tony's patchset is broken at places compared to what is in -rt. So that 
would be proper *double standard* approach. :-/

> Ben.

WBR, Sergei

^ permalink raw reply

* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-15 18:05 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: linuxppc-dev, Paul Mackerras, Steven Rostedt, Realtime Kernel
In-Reply-To: <1190836713.23376.41.camel@chaos>

Hello.

Thomas Gleixner wrote:

>>>    No wonder here: the -rt patch already has much of this code since around
>>>2.6.21.  They have been submitted by me, mostly... and this patchset is
>>>against the Linus' tree.

>>That would explain it ;-)

>>I was searching the linux-rt-users mailing list for any patches, and
>>pulled in any that looked legit. These happen to in that mailing list too.

> I'll sort that out along with the other hrt updates.

   Eh... poor you. Tony got clockevent driver reengineered for no apparent 
reason.  And he's introduced the jiffy drift by deleting the main loop from 
timer_interrupt(). Yet this borken version was preferred to what was known 
working since about 2.6.18 and included into 2.6.21-rt patchset.  I don't like 
that policy. Will you be pushing fixes from -rt to PowerPC, or will it fall on 
my shoulders now?

> 	tglx

WBR, Sergei

^ permalink raw reply

* my git tree rebased
From: Kumar Gala @ 2007-10-15 18:00 UTC (permalink / raw)
  To: linuxppc-dev list

For anyone using my git tree I've rebased it now that the merge  
window for 2.6.24 is ongoing and removed all branches.

The master/HEAD now is in sync with Linus's tree.  I'll be starting  
of a fixes-2.6.24 branch at some point as well as for-2.6.25 branch.

I'll try to keep the master branch as a merge of the various patches  
that exist in the other branches.  Please use the master to create  
any patches against.

- k

^ permalink raw reply

* [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Valentine Barshak @ 2007-10-15 17:57 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: netdev, jeff
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>

This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <sr@denx.de>

Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 drivers/net/ibm_newemac/phy.c |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+)

--- linux.orig/drivers/net/ibm_newemac/phy.c	2007-06-15 21:45:18.000000000 +0400
+++ linux/drivers/net/ibm_newemac/phy.c	2007-06-15 20:45:15.000000000 +0400
@@ -306,8 +306,47 @@
 	.ops		= &cis8201_phy_ops
 };
 
+static struct mii_phy_def bcm5248_phy_def = {
+
+	.phy_id		= 0x0143bc00,
+	.phy_id_mask	= 0x0ffffff0,
+	.name		= "BCM5248 10/100 SMII Ethernet",
+	.ops		= &generic_phy_ops
+};
+
+static int m88e1111_init(struct mii_phy *phy)
+{
+	printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
+	phy_write(phy, 0x14, 0x0ce3);
+	phy_write(phy, 0x18, 0x4101);
+	phy_write(phy, 0x09, 0x0e00);
+	phy_write(phy, 0x04, 0x01e1);
+	phy_write(phy, 0x00, 0x9140);
+	phy_write(phy, 0x00, 0x1140);
+
+	return  0;
+}
+
+static struct mii_phy_ops m88e1111_phy_ops = {
+	.init		= m88e1111_init,
+	.setup_aneg	= genmii_setup_aneg,
+	.setup_forced	= genmii_setup_forced,
+	.poll_link	= genmii_poll_link,
+	.read_link	= genmii_read_link
+};
+
+static struct mii_phy_def m88e1111_phy_def = {
+
+	.phy_id		= 0x01410CC0,
+	.phy_id_mask	= 0x0ffffff0,
+	.name		= "Marvell 88E1111 Ethernet",
+	.ops		= &m88e1111_phy_ops,
+};
+
 static struct mii_phy_def *mii_phy_table[] = {
 	&cis8201_phy_def,
+	&bcm5248_phy_def,
+	&m88e1111_phy_def,
 	&genmii_phy_def,
 	NULL
 };

^ permalink raw reply

* Re: [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Kumar Gala @ 2007-10-15 18:00 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4713A474.1000301@ru.mvista.com>


On Oct 15, 2007, at 12:33 PM, Sergei Shtylyov wrote:

> Anton Vorontsov wrote:
>
>> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
>> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/ 
>> boot/dts/mpc8568mds.dts
>> index 8e15dba..1198363 100644
>> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
>> @@ -47,12 +47,45 @@
>>  		#address-cells = <2>;
>>  		#size-cells = <1>;
>>  		reg = <e0005000 d8>;
>> -		ranges = <1 0 f8000000 0008000>;
>> +		ranges = <1 0 f8000000 0008000
>> +			  0 0 fe000000 2000000>;
>>
>>  		bcsr@1,0 {
>>  			device_type = "board-control";
>>  			reg = <1 0 8000>;
>>  		};
>> +
>> +		flash@0,0 {
>> +			compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>> +			reg = <0 0 2000000>;
>> +			probe-type = "CFI";
>
>     I don't get it -- has physmap_of.c rewrite been already committed?
> If yes, you don't need probe_type; if no, your "compatible" won't  
> work...
> Well, I see that the driver rewrite has been committed (when I  
> wasn't looking
> 8-)...

Any NOR flash nodes should conform to the "new" bindings from David  
Gibson, et al.  Not sure about the status of those being in  
physmap_of.c w/regards to 2.6.24.

- k

^ permalink raw reply

* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-15 17:40 UTC (permalink / raw)
  To: Tony Breeds
  Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <20070921032603.0D3EA32C887@thor>

Hello.

Tony Breeds wrote:

> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>

    I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it.  And I'm not sure why this crippled version (lacking 40x/ Book E specific
clockevents implementation) is preferred over mine, unless this implementation
was only aimed at PPC64 machines...

> Index: working/arch/powerpc/Kconfig
> ===================================================================
> --- working.orig/arch/powerpc/Kconfig
> +++ working/arch/powerpc/Kconfig
> @@ -30,6 +30,9 @@ config GENERIC_TIME
>  config GENERIC_TIME_VSYSCALL
>  	def_bool y
>
> +config GENERIC_CLOCKEVENTS
> +	def_bool y
> +
>  config GENERIC_HARDIRQS
>  	bool
>  	default y

    Also, have the deterministic CPU accounting incompatibility with
clockevents been dealt with?

> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
[...]
> @@ -519,10 +541,12 @@ void __init iSeries_time_init_early(void
>  void timer_interrupt(struct pt_regs * regs)
>  {
>  	struct pt_regs *old_regs;
> -	int next_dec;
>  	int cpu = smp_processor_id();
> -	unsigned long ticks;
> -	u64 tb_next_jiffy;
> +	struct clock_event_device *evt = &per_cpu(decrementers, cpu);
> +
> +	/* Ensure a positive value is written to the decrementer, or else
> +	 * some CPUs will continuue to take decrementer exceptions */
> +	set_dec(DECREMENTER_MAX);

    BookE and 40x CPUs don't need this.

>  #ifdef CONFIG_PPC32
>  	if (atomic_read(&ppc_n_lost_interrupts) != 0)
> @@ -532,7 +556,6 @@ void timer_interrupt(struct pt_regs * re
>  	old_regs = set_irq_regs(regs);
>  	irq_enter();
>  
> -	profile_tick(CPU_PROFILING);
>  	calculate_steal_time();
>  
>  #ifdef CONFIG_PPC_ISERIES
> @@ -540,44 +563,20 @@ void timer_interrupt(struct pt_regs * re
>  		get_lppaca()->int_dword.fields.decr_int = 0;
>  #endif
>  
> -	while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
> -	       >= tb_ticks_per_jiffy) {
> -		/* Update last_jiffy */
> -		per_cpu(last_jiffy, cpu) += tb_ticks_per_jiffy;
> -		/* Handle RTCL overflow on 601 */
> -		if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
> -			per_cpu(last_jiffy, cpu) -= 1000000000;

    I don't see where the patch removes those variables themselves...

[...]

> -		write_seqlock(&xtime_lock);
> -		tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
> -		if (__USE_RTC() && tb_next_jiffy >= 1000000000)
> -			tb_next_jiffy -= 1000000000;
> -		if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
> -			tb_last_jiffy = tb_next_jiffy;
> -			do_timer(1);
> -		}
> -		write_sequnlock(&xtime_lock);
> -	}

    Again, where those variables are removed?

> -	
> -	next_dec = tb_ticks_per_jiffy - ticks;
> -	set_dec(next_dec);
> +	if (evt->event_handler)
> +		evt->event_handler(evt);
> +	else
> +		evt->set_next_event(DECREMENTER_MAX, evt);

    We have already set it to DECREMENTER_MAX at the start of the function.
Please remove the 'else' part...

> @@ -797,6 +796,53 @@ void __init clocksource_init(void)
>  	       clock->name, clock->mult, clock->shift);
>  }
>  
> +static int decrementer_set_next_event(unsigned long evt,
> +				      struct clock_event_device *dev)
> +{
> +	set_dec(evt);

    I'd use (evt - 1) since the interrupt gets generated at 0xffffffff count, 
not 0 (on classic CPUs).  With you removing of the code that compensated for 
the errors, they will accumulate.  And no, this wouldn't be enough anyway, 
since on 40x and Book E you'll need to set it for evt anyway, since the 
interrupt happens at 0 count...
    NAK the patch.  And I really don't understand why you're throwing alway 
already tested/working code...

> +	return 0;
> +}
> +
> +static void decrementer_set_mode(enum clock_event_mode mode,
> +				 struct clock_event_device *dev)
> +{
> +	if (mode != CLOCK_EVT_MODE_ONESHOT)
> +		decrementer_set_next_event(DECREMENTER_MAX, dev);
> +}
> +
> +static void register_decrementer_clockevent(int cpu)
> +{
> +	struct clock_event_device *dec = &per_cpu(decrementers, cpu);
> +
> +	*dec = decrementer_clockevent;
> +	dec->cpumask = cpumask_of_cpu(cpu);
> +
> +	printk(KERN_ERR "clockevent: %s mult[%lx] shift[%d] cpu[%d]\n",

    This is a mistake indeed. :-P

WBR, Sergei

^ permalink raw reply

* Re: jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails
From: N. van Bolhuis @ 2007-10-15 17:25 UTC (permalink / raw)
  To: linux-mtd, linuxppc-embedded


OK, so there's nothing wrong with the linux-mtd mailing
list. It's alive.
I guess the archives are moved to
www.infradead.org/pipermail/linux-mtd and many existing
pages still refer to list.infradead.org/pipermail/linux-mtd

To be complete and to provide an answer (to my own question)
I'll show what I did to make things work.

Btw. in my previous post I mentioned somewhere

"It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
 listed in the jedec_table[] entry for cfi->device_type=2=X16) and both pair
 of unlock addresses (which do get the chip in autoselect mode) do not match."

This is incorrect.
"0x0aaa 0x0555" is not listed in the jedec_table[] entry for x16. It's selected
because of the finfo_uaddr function having this if statement:

 
if (uaddr != MTD_UADDR_NOT_SUPPORTED ) {
    uaddr = finfo->uaddr[0];
}

return uaddr;

So, in x16 always "0x0aaa 0x0555" (entry for x8) is considered to be the unlock
address.

But this doesn't hurt me since our 16 bit AMD/Spansion flash device needs to
be recognized in 8 bit mode anyway since (obviously) it is used in 8 bit mode.


Looking through the archives shows more developers have dealt with this problem.
The unlock_addr function is suspicious. There's even a patch for this function
to make things work, but dwmw2 rejected it because things are supposed to be shifted
automatically for different device modes (x8, x16, x32).
Somewhere in the archives it is mentioned the device id should be read from
address 2 (and not 1) (for an AM29LV800 in byte mode). I suffer from this problem too.
Also somewhere in the archives the finfo_uaddr function is blamed, in particular
the if statement I showed above.

Obviously the jedec_probe simply doesn't work for all possible flash device and
(embedded) board configurations. This is exactly what the comment
in jedec_probe.c (above the function jedec_match) suggests.

I added the following to jedec_probe.c to make things work:

#define AM29LV160DTBYTE 0x0001

        }, {
                .mfr_id         = MANUFACTURER_AMD,
                .dev_id         = AM29LV160DTBYTE,
                .name           = "S29AL016D TB (byte mode)",
                .uaddr          = {
                        [0] = MTD_UADDR_0x0AAA_0x0555 /* x8 */
                },
                .DevSize        = SIZE_2MiB,
                .CmdSet         = P_ID_AMD_STD,
                .NumEraseRegions= 4,
                .regions        = {
                        ERASEINFO(0x10000,31),
                        ERASEINFO(0x08000,1),
                        ERASEINFO(0x02000,2),
                        ERASEINFO(0x04000,1)
                }




Not wanting to break functionality for some native 8 bit flash devices we use
(which do read their device id on address 1) I added device id 0x0001 since
it is guaranteed to be the same as the manfacturer id and was still free.


BR, 
N. van Bolhuis. 

-- 
This message has been scanned for viruses and is believed to be clean

^ permalink raw reply

* Re: Refactor booting-without-of.txt
From: Olof Johansson @ 2007-10-15 17:40 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710151014q5e151ea9w3f589d9e89e95905@mail.gmail.com>

Hi,

On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> >
> > The flat device tree is, in spite of what some people would like it to be,
> > not open firmware, nor is it the same as their bindings. So I think we'd
> > be doing ourselves a disservice by continuing to associate them together.
> > All it would take is a rename of the directory, unfortunately i don't
> > have any suggestions on better names though.
> 
> I think I need to stick with the of prefix.  All the support API in
> include/linux/of_* is prefixed with "of_" already, so convention is
> established.
> 
> How about Documentation/of-device-tree?

Sounds good to me, even though it doesn't really address the original
OF separation comment. :)

Maybe it's enough to document the difference between the linux-specific
flat device tree bindings and classic 1275-style bindings in the top
readme in that directory. Either way, it's not worth arguing over,
your suggestion is good enough.

> > Looks reasonable. The other way to cut it would be to slice along vendor
> > boundaries, but I think I like the functional partitioning you suggested
> > better.
> 
> I think vendor partitioning makes sense for non-common devices that
> don't easily fit into a particular mold (soc glue nodes come to mind).
>  Other than that, the functional partitioning
> lets us start with defining common property usage for a given device
> type and follow up with device specific properties.

Yep, it could always be added down the road in case it's needed.


-Olof

^ permalink raw reply

* Re: [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Sergei Shtylyov @ 2007-10-15 17:33 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071015161631.GB30512@localhost.localdomain>

Anton Vorontsov wrote:

> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.

> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>

> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
> index 8e15dba..1198363 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -47,12 +47,45 @@
>  		#address-cells = <2>;
>  		#size-cells = <1>;
>  		reg = <e0005000 d8>;
> -		ranges = <1 0 f8000000 0008000>;
> +		ranges = <1 0 f8000000 0008000
> +			  0 0 fe000000 2000000>;
>  
>  		bcsr@1,0 {
>  			device_type = "board-control";
>  			reg = <1 0 8000>;
>  		};
> +
> +		flash@0,0 {
> +			compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
> +			reg = <0 0 2000000>;
> +			probe-type = "CFI";

    I don't get it -- has physmap_of.c rewrite been already committed?
If yes, you don't need probe_type; if no, your "compatible" won't work...
Well, I see that the driver rewrite has been committed (when I wasn't looking 
8-)...

> +			bank-width = <2>;
> +			device-width = <1>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			hrcw@0 {
> +				label = "hrcw";
> +				reg = <0 20001>;

    What?! Odd sized partition? Don't try to follow both the old and new 
partition device tree specs -- you'll only get yourself into trouble with 
this.  The size-cell doesn't bear r/o flag in the new paritions spec.

> +				read-only;
> +			};
> +
> +			kernel@20000 {
> +				label = "kernel";
> +				reg = <20000 200000>;
> +			};
> +
> +			rootfs@220000 {
> +				label = "rootfs";
> +				reg = <220000 1d60000>;
> +			};
> +
> +			uboot@1f80000 {
> +				label = "u-boot";
> +				reg = <1f80000 80000>;
> +				read-only;

    Well, this is not even consistent... :-)

> +			};
> +		};
>  	};

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Josh Boyer @ 2007-10-15 17:26 UTC (permalink / raw)
  To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071012130305.GA14682@ru.mvista.com>


On Fri, 12 Oct 2007 17:03:05 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:

> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>

Could you send the phy part to Jeff Garzik and the netdev list by
itself?  That way it will get picked up and we'll update the Kconfig
with a later patch.

josh

^ permalink raw reply

* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-15 17:17 UTC (permalink / raw)
  To: keng_629; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <200710151115352659084@126.com>

keng_629 wrote:
>  
> i am proting linux2.63.23 to mpc860t board with uboot1.1.4 as bootloader.
> my bootargs is root=/dev/ram rw init=/linuxrc.
> i use debugger to see the regedits, find pc is run in the cpu_idle().
> what is wrong with my kernel, plese give me some advice.thank you .

Posting the same thing over and over again isn't going to change the 
response.  Try head-of-Linus's-git, make sure you're using arch/powerpc, 
and post the device tree you're using.  Without more information, we 
can't help you.

-Scott

^ permalink raw reply

* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-15 17:14 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071015165505.GA16040@lixom.net>

On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > Adding the Linux expected device tree bindings to
> > booting-without-of.txt seems to be getting a little unwieldy.  Plus
> > with more than one arch using the device tree (powerpc, sparc &
> > microblaze) the device tree bindings aren't necessarily powerpc only
> > (the Xilinx devices certainly fall in this category).
> >
> > Anyone have comments about splitting the expected device tree bindings
> > out of booting-without-of.txt into a separate directory?
>
> The flat device tree is, in spite of what some people would like it to be,
> not open firmware, nor is it the same as their bindings. So I think we'd
> be doing ourselves a disservice by continuing to associate them together.
> All it would take is a rename of the directory, unfortunately i don't
> have any suggestions on better names though.

I think I need to stick with the of prefix.  All the support API in
include/linux/of_* is prefixed with "of_" already, so convention is
established.

How about Documentation/of-device-tree?

>
> > Perhaps something like this; each file contains common bindings for
> > the type of device and device specific properties:
> >
> > Documentation/of/
> > Documentation/of/README - Description of the purpose and layout of
> > this directory
> > Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc)
> > Documentation/of/serial.txt - serial device bindings
> > Documentation/of/misc.txt - anything that doesn't fit anywhere else yet.
> > Documentation/of/soc/* - System on chip stuff that doesn't fit will
> > into established device types; possibly a separate file for each chip.
> > Documentation/of/usb.txt - usb blah blah blah
> > Documentation/of/whatever - you get the picture.
> >
> > Thoughts?
>
> Looks reasonable. The other way to cut it would be to slice along vendor
> boundaries, but I think I like the functional partitioning you suggested
> better.

I think vendor partitioning makes sense for non-common devices that
don't easily fit into a particular mold (soc glue nodes come to mind).
 Other than that, the functional partitioning
lets us start with defining common property usage for a given device
type and follow up with device specific properties.

Thanks for the feedback,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 16:57 UTC (permalink / raw)
  To: Eugene Surovegin; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20071015163216.GA8127@gate.ebshome.net>

On 10/15/07, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Oct 15, 2007 at 03:29:11PM +0200, Stefan Roese wrote:
>
> <snip>
>
> > +#ifdef CONFIG_PPC_MERGE
> > +static int device_idx = -1;
> > +#endif
> > +
>
> <snip>
>
> > +     dev->idx = ++device_idx;
> > +     adap->nr = dev->idx;
>
> Hmm, this doesn't look right. That mighty powerpc device everybody
> was so excited about for the last years doesn't provide a device
> instance number/index?
>
> I think this approach is wrong, because I want i2c bus numbers for the
> on-chip i2c to be fixed. This code makes it dependent on the order
> devices were described in the device tree; how do you handle a
> situation when only the second i2c adapter is connected? For OCP I
> would just remove ocp_def for the IIC0.

Segher is recommending that we use an aliases node as per the open
firmware example for this.  I think in this case it would look
something like this (but I'm not the expert):

aliases {
     IIC0 = "/path/to/bus/iic@0x2000";
     IIC1 = "/path/to/bus/iic@0x2000";
};

Which seems to make sense to me.  And it keeps it easy to have
multiple iic bus types sharing the same IIC bus number space (each
device does not try to maintain it's own little 'next index' value).

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* RE: Override timer interrupt
From: Rune Torgersen @ 2007-10-15 16:49 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <1192229894.22054.29.camel@pasglop>

> From: Benjamin Herrenschmidt
> In fact, I'm not sure what is your problem with the DEC=20
> proper as the TB
> will be used ultimately and thus it shouldn't drift more than the TB
> does. Can your part use an externally clocked TB ?
>=20
> If not, and you still have a drift despite calibration, you can always
> use NTP services to adjust timekeeping.

We use NTP, which is why I didn't see it until recently. (Happened to
have a board without NTP configured

The main couse is that our main bus frequency cannort be divided into
1kHz evently by the decrementer.
Main bus freq =3D 99532800 Hz.
Decrementer then becomes 24883, which gives us 999991.9624485600nsec per
jiffy.
That is not a number easilly converted into time without drift.

Changing HZ to 100 fixes it, but is for varous reasons not an option
right now.

What I did do is change the timer interrupt to be called by an ecxternal
1kHz interrupt source instead of the decrementer.

The TB register is only ued for offsets from the last jiffie, not as a
continous offset, so then it works out pretty good.
There is a discontinuity in the sub ms resolution of the clock that I
can live with. msec and up are dead accurate.

^ permalink raw reply

* Re: Refactor booting-without-of.txt
From: Olof Johansson @ 2007-10-15 16:55 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710150908o55d1f5d2t264cbb8ed800a12f@mail.gmail.com>

On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> Adding the Linux expected device tree bindings to
> booting-without-of.txt seems to be getting a little unwieldy.  Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
> 
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?

The flat device tree is, in spite of what some people would like it to be,
not open firmware, nor is it the same as their bindings. So I think we'd
be doing ourselves a disservice by continuing to associate them together.
All it would take is a rename of the directory, unfortunately i don't
have any suggestions on better names though.

> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
>
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
> 
> Thoughts?

Looks reasonable. The other way to cut it would be to slice along vendor
boundaries, but I think I like the functional partitioning you suggested
better.


-Olof

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox