* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: Eric Dumazet @ 2009-03-25 14:04 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Netdev, leoli, 'linuxppc-dev Development'
In-Reply-To: <1237987849.2194.9.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund a =E9crit :
>>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI weight somewhat.
> This will make the system alot more responsive while
> ping flooding the ucc_geth ethernet interaface.
>=20
>=20
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ucc_geth.c | 30 +++++++++++-------------------
> drivers/net/ucc_geth.h | 2 +-
> 2 files changed, 12 insertions(+), 20 deletions(-)
>=20
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 097aed8..7d5d110 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3214,7 +3214,7 @@ static int ucc_geth_tx(struct net_device *dev, u8=
txQ)
> dev->stats.tx_packets++;
> =20
> /* Free the sk buffer associated with this TxBD */
> - dev_kfree_skb_irq(ugeth->
> + dev_kfree_skb(ugeth->
> tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
> ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] =3D NULL;
> ugeth->skb_dirtytx[txQ] =3D
> @@ -3248,9 +3248,16 @@ static int ucc_geth_poll(struct napi_struct *nap=
i, int budget)
> for (i =3D 0; i < ug_info->numQueuesRx; i++)
> howmany +=3D ucc_geth_rx(ugeth, i, budget - howmany);
> =20
Cant you test (ucce & UCCE_TX_EVENTS) or something here to avoid
taking lock and checking queues if not necessary ?
> + /* Tx event processing */
> + spin_lock(&ugeth->lock);
> + for (i =3D 0; i < ug_info->numQueuesTx; i++) {
> + ucc_geth_tx(ugeth->dev, i);
> + }
> + spin_unlock(&ugeth->lock);
> +
Why tx completions dont change "howmany" ?
It seems strange you changed UCC_GETH_DEV_WEIGHT if not taking into accou=
nt tx event above...
> if (howmany < budget) {
> netif_rx_complete(napi);
> - setbits32(ugeth->uccf->p_uccm, UCCE_RX_EVENTS);
> + setbits32(ugeth->uccf->p_uccm, UCCE_RX_EVENTS | UCCE_TX_EVENTS);
> }
> =20
> return howmany;
> @@ -3264,8 +3271,6 @@ static irqreturn_t ucc_geth_irq_handler(int irq, =
void *info)
> struct ucc_geth_info *ug_info;
> register u32 ucce;
> register u32 uccm;
> - register u32 tx_mask;
> - u8 i;
> =20
> ugeth_vdbg("%s: IN", __func__);
> =20
> @@ -3279,27 +3284,14 @@ static irqreturn_t ucc_geth_irq_handler(int irq=
, void *info)
> out_be32(uccf->p_ucce, ucce);
> =20
> /* check for receive events that require processing */
> - if (ucce & UCCE_RX_EVENTS) {
> + if (ucce & (UCCE_RX_EVENTS | UCCE_TX_EVENTS)) {
> if (netif_rx_schedule_prep(&ugeth->napi)) {
> - uccm &=3D ~UCCE_RX_EVENTS;
> + uccm &=3D ~(UCCE_RX_EVENTS | UCCE_TX_EVENTS);
> out_be32(uccf->p_uccm, uccm);
> __netif_rx_schedule(&ugeth->napi);
> }
> }
> =20
> - /* Tx event processing */
> - if (ucce & UCCE_TX_EVENTS) {
> - spin_lock(&ugeth->lock);
> - tx_mask =3D UCC_GETH_UCCE_TXB0;
> - for (i =3D 0; i < ug_info->numQueuesTx; i++) {
> - if (ucce & tx_mask)
> - ucc_geth_tx(dev, i);
> - ucce &=3D ~tx_mask;
> - tx_mask <<=3D 1;
> - }
> - spin_unlock(&ugeth->lock);
> - }
> -
> /* Errors and other events */
> if (ucce & UCCE_OTHER) {
> if (ucce & UCC_GETH_UCCE_BSY)
> diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
> index 44218b8..ea30aa7 100644
> --- a/drivers/net/ucc_geth.h
> +++ b/drivers/net/ucc_geth.h
> @@ -843,7 +843,7 @@ struct ucc_geth_hardware_statistics {
> /* Driver definitions */
> #define TX_BD_RING_LEN 0x10
> #define RX_BD_RING_LEN 0x10
> -#define UCC_GETH_DEV_WEIGHT TX_BD_RING_LEN
> +#define UCC_GETH_DEV_WEIGHT (RX_BD_RING_LEN+TX_BD_=
RING_LEN/2)
> =20
> #define TX_RING_MOD_MASK(size) (size-1)
> #define RX_RING_MOD_MASK(size) (size-1)
^ permalink raw reply
* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: Anton Vorontsov @ 2009-03-25 14:25 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Netdev, leoli, 'linuxppc-dev Development'
In-Reply-To: <1237987849.2194.9.camel@gentoo-jocke.transmode.se>
On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI weight somewhat.
> This will make the system alot more responsive while
> ping flooding the ucc_geth ethernet interaface.
Some time ago I've tried a similar thing for this driver, but during
tcp (or udp I don't quite remember) netperf tests I was getting tx
watchdog timeouts after ~2-5 minutes of work. I was testing with a
gigabit and 100 Mbit link, with 100 Mbit link the issue was not
reproducible.
Though, I recalling I was doing a bit more than your patch: I was
also clearing the TX events in the ucce register before calling
ucc_geth_tx, that way I was trying to avoid stale interrupts. That
helped to increase an overall performance (not only responsiveness),
but as I said my approach didn't pass the tests.
I don't really think that your patch may cause this, but can you
try netperf w/ this patch applied anyway? And see if it really
doesn't cause any issues under stress?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: of_serial and device trees
From: Simon Kagstrom @ 2009-03-25 14:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090324155545.GA24778@ld0162-tx32.am.freescale.net>
Hi Scott!
Thanks a lot for all your help with the device tree! As you suspected,
I'm writing for a fairly old kernel (2.6.21, WindRiver). I know, I know.
On Tue, 24 Mar 2009 10:55:45 -0500
Scott Wood <scottwood@freescale.com> wrote:
> Add compatible = "simple-bus". This lets children of this node be probed
> by of_platform drivers (make sure you list simple-bus when calling
> of_platform_bus_probe), and in a few other places (like legacy_serial.c).
Right, thanks. I've added this of_platform_bus_probe as an initcall,
and it now tries to configure the serial ports as expected (and with
some other issues).
> Compatible should be of the form "vendor,device" -- and does "isf"
> uniquely identify the specific FPGA logic, or are there other versions
> out there (or likely to exist in the future)? Note that there are some
> bad examples in existing device trees that have yet to be fixed.
There are no other versions yet, but I suppose there will be (it's
implemented in a FPGA after all!). So what is the general handling of
versions, should it be something like
compatible = "ericsson,isf-pic", "ericsson,isf-pic-v2"
etc if we'd make new revisions of the device?
> I'm guessing that your FPGA PIC driver isn't getting its register address
> from the device tree, given that it works without the ranges property?
It is, but I didn't check it for correctness yet, so I suppose I might
have mapped the wrong thing. The code looks like this:
struct resource phys_addr;
if (of_address_to_resource(np, 0, &phys_addr) != 0) {
printk(KERN_ERR": Could not get ISF PIC memory resource\n");
return NULL;
}
spin_lock_init(&isf->lock);
isf->ioaddr = ioremap(phys_addr.start,
phys_addr.end - phys_addr.start);
So I should use the reg property and platform_get_resource() instead?
// Simon
^ permalink raw reply
* Re: [PATCH v3 1/4] NAND: FSL-UPM: add multi chip support
From: Anton Vorontsov @ 2009-03-25 14:57 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1237975701-23201-2-git-send-email-wg@grandegger.com>
Hi Wolfgang,
On Wed, Mar 25, 2009 at 11:08:18AM +0100, Wolfgang Grandegger wrote:
> This patch adds support for multi-chip NAND devices to the FSL-UPM
> driver. This requires support for multiple GPIOs for the RNB pins.
> The NAND chips are selected through address lines defined by the
> FDT property "chip-offset".
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
Some cosmetic issues are still there...
> arch/powerpc/sysdev/fsl_lbc.c | 2 +-
> drivers/mtd/nand/fsl_upm.c | 95 +++++++++++++++++++++++++++++++---------
> 2 files changed, 74 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
> index 0494ee5..dceb8d1 100644
> --- a/arch/powerpc/sysdev/fsl_lbc.c
> +++ b/arch/powerpc/sysdev/fsl_lbc.c
> @@ -150,7 +150,7 @@ int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
>
> spin_lock_irqsave(&fsl_lbc_lock, flags);
>
> - out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
> + out_be32(&fsl_lbc_regs->mar, mar);
>
> switch (upm->width) {
> case 8:
> diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
> index 7815a40..9b314ce 100644
> --- a/drivers/mtd/nand/fsl_upm.c
> +++ b/drivers/mtd/nand/fsl_upm.c
> @@ -36,8 +36,11 @@ struct fsl_upm_nand {
> uint8_t upm_addr_offset;
> uint8_t upm_cmd_offset;
> void __iomem *io_base;
> - int rnb_gpio;
> + int rnb_gpio[NAND_MAX_CHIPS];
> int chip_delay;
> + uint32_t num_chips;
> + uint32_t chip_number;
> + uint32_t chip_offset;
> };
>
> #define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
> @@ -46,7 +49,7 @@ static int fun_chip_ready(struct mtd_info *mtd)
> {
> struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
>
> - if (gpio_get_value(fun->rnb_gpio))
> + if (gpio_get_value(fun->rnb_gpio[fun->chip_number]))
> return 1;
>
> dev_vdbg(fun->dev, "busy\n");
> @@ -55,9 +58,9 @@ static int fun_chip_ready(struct mtd_info *mtd)
>
> static void fun_wait_rnb(struct fsl_upm_nand *fun)
> {
> - int cnt = 1000000;
>
This empty line can be removed.
> - if (fun->rnb_gpio >= 0) {
> + if (fun->rnb_gpio[fun->chip_number] >= 0) {
> + int cnt = 1000000;
Add an empty line here.
> while (--cnt && !fun_chip_ready(&fun->mtd))
> cpu_relax();
> if (!cnt)
> @@ -69,7 +72,9 @@ static void fun_wait_rnb(struct fsl_upm_nand *fun)
>
> static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
> {
> + struct nand_chip *chip = mtd->priv;
> struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
> + u32 mar;
>
> if (!(ctrl & fun->last_ctrl)) {
> fsl_upm_end_pattern(&fun->upm);
> @@ -87,11 +92,30 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
> fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
> }
>
> - fsl_upm_run_pattern(&fun->upm, fun->io_base, cmd);
> + mar = cmd << (32 - fun->upm.width);
> + if (fun->chip_offset && fun->chip_number > 0)
> + mar |= fun->chip_number * fun->chip_offset;
> + fsl_upm_run_pattern(&fun->upm, chip->IO_ADDR_R, mar);
>
> fun_wait_rnb(fun);
> }
>
> +static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
> +
> + if (chip_nr == -1) {
> + chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 | NAND_CTRL_CHANGE);
> + } else if (chip_nr >= 0) {
> + fun->chip_number = chip_nr;
> + chip->IO_ADDR_R = chip->IO_ADDR_W =
> + fun->io_base + chip_nr * fun->chip_offset;
Please avoid = = constructions.
chip->IO_ADDR_R = fun->io_base + chip_nr * fun->chip_offset;
chip->IO_ADDR_W = chip->IO_ADDR_R;
^^ looks much better.
> +
> + } else {
> + BUG();
> + }
> +}
> +
> static uint8_t fun_read_byte(struct mtd_info *mtd)
> {
> struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
> @@ -137,8 +161,10 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
> fun->chip.read_buf = fun_read_buf;
> fun->chip.write_buf = fun_write_buf;
> fun->chip.ecc.mode = NAND_ECC_SOFT;
> + if (fun->num_chips > 1)
> + fun->chip.select_chip = fun_select_chip;
>
> - if (fun->rnb_gpio >= 0)
> + if (fun->rnb_gpio[0] >= 0)
> fun->chip.dev_ready = fun_chip_ready;
>
> fun->mtd.priv = &fun->chip;
> @@ -155,7 +181,7 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
> goto err;
> }
>
> - ret = nand_scan(&fun->mtd, 1);
> + ret = nand_scan(&fun->mtd, fun->num_chips);
> if (ret)
> goto err;
>
> @@ -187,6 +213,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
> const uint32_t *prop;
> int ret;
> int size;
> + int i;
>
> fun = kzalloc(sizeof(*fun), GFP_KERNEL);
> if (!fun)
> @@ -208,7 +235,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
> if (!prop || size != sizeof(uint32_t)) {
> dev_err(&ofdev->dev, "can't get UPM address offset\n");
> ret = -EINVAL;
> - goto err2;
> + goto err1;
> }
> fun->upm_addr_offset = *prop;
>
> @@ -216,21 +243,36 @@ static int __devinit fun_probe(struct of_device *ofdev,
> if (!prop || size != sizeof(uint32_t)) {
> dev_err(&ofdev->dev, "can't get UPM command offset\n");
> ret = -EINVAL;
> - goto err2;
> + goto err1;
> }
> fun->upm_cmd_offset = *prop;
>
> - fun->rnb_gpio = of_get_gpio(ofdev->node, 0);
> - if (fun->rnb_gpio >= 0) {
> - ret = gpio_request(fun->rnb_gpio, dev_name(&ofdev->dev));
> - if (ret) {
> - dev_err(&ofdev->dev, "can't request RNB gpio\n");
> + prop = of_get_property(ofdev->node, "num-chips", &size);
> + if (prop && size == sizeof(uint32_t)) {
> + fun->num_chips = *prop;
> + if (fun->num_chips >= NAND_MAX_CHIPS) {
> + dev_err(&ofdev->dev, "too much chips");
\n is missing in dev_err().
> + ret = -EINVAL;
> + goto err1;
> + }
> + } else {
> + fun->num_chips = 1;
> + }
> +
> + for (i = 0; i < fun->num_chips; i++) {
> + fun->rnb_gpio[i] = of_get_gpio(ofdev->node, i);
> + if (fun->rnb_gpio[i] >= 0) {
> + ret = gpio_request(fun->rnb_gpio[i],
trailing whitespace on that line.
> + dev_name(&ofdev->dev));
> + if (ret) {
> + dev_err(&ofdev->dev, "can't request RNB gpio\n");
line is over 80 chars.
> + goto err2;
> + }
> + gpio_direction_input(fun->rnb_gpio[i]);
> + } else if (fun->rnb_gpio[i] == -EINVAL) {
stray whitespace in " ==".
> + dev_err(&ofdev->dev, "specified RNB gpio is invalid\n");
> goto err2;
> }
> - gpio_direction_input(fun->rnb_gpio);
> - } else if (fun->rnb_gpio == -EINVAL) {
> - dev_err(&ofdev->dev, "specified RNB gpio is invalid\n");
> - goto err2;
> }
>
> prop = of_get_property(ofdev->node, "chip-delay", NULL);
> @@ -239,6 +281,10 @@ static int __devinit fun_probe(struct of_device *ofdev,
> else
> fun->chip_delay = 50;
>
> + prop = of_get_property(ofdev->node, "chip-offset", &size);
> + if (prop && size == sizeof(uint32_t))
> + fun->chip_offset = *prop;
> +
> fun->io_base = devm_ioremap_nocache(&ofdev->dev, io_res.start,
> io_res.end - io_res.start + 1);
> if (!fun->io_base) {
> @@ -257,8 +303,10 @@ static int __devinit fun_probe(struct of_device *ofdev,
>
> return 0;
> err2:
> - if (fun->rnb_gpio >= 0)
> - gpio_free(fun->rnb_gpio);
> + for (i = 0; i < fun->num_chips; i++) {
> + if (fun->rnb_gpio[i] >= 0)
> + gpio_free(fun->rnb_gpio[i]);
> + }
> err1:
> kfree(fun);
>
> @@ -268,12 +316,15 @@ err1:
> static int __devexit fun_remove(struct of_device *ofdev)
> {
> struct fsl_upm_nand *fun = dev_get_drvdata(&ofdev->dev);
> + int i;
>
> nand_release(&fun->mtd);
> kfree(fun->mtd.name);
>
> - if (fun->rnb_gpio >= 0)
> - gpio_free(fun->rnb_gpio);
> + for (i = 0; i < fun->num_chips; i++) {
> + if (fun->rnb_gpio[i] >= 0)
> + gpio_free(fun->rnb_gpio[i]);
> + }
code indent should use tabs where possible (not white spaces).
When the cosmetic issues are fixed, I'll readily ack this patch.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 2/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays
From: Anton Vorontsov @ 2009-03-25 15:01 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1237975701-23201-3-git-send-email-wg@grandegger.com>
On Wed, Mar 25, 2009 at 11:08:19AM +0100, Wolfgang Grandegger wrote:
> The NAND flash on the TQM8548_BE modules requires a short delay after
> running the UPM pattern. The TQM8548_BE requires a further short delay
> after writing out a buffer. Normally the R/B pin should be checked, but
> it's not connected on the TQM8548_BE. The existing driver uses similar
> fixed delay points. To manage these extra delays in a more general way,
> I introduced the "wait-flags" property allowing the board-specific driver
> to specify various types of extra delay.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
[...]
> + prop = of_get_property(ofdev->node, "fsl,upm-wait-flags", &size);
> + if (prop && size == sizeof(uint32_t))
> + fun->wait_flags = *prop;
> + else
> + fun->wait_flags =
> + FSL_UPM_WAIT_RUN_PATTERN | FSL_UPM_WAIT_WRITE_BYTE;
I'd write it as
fun->wait_flags = FSL_UPM_WAIT_RUN_PATTERN |
FSL_UPM_WAIT_WRITE_BYTE;
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Anton Vorontsov @ 2009-03-25 15:11 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <1237975701-23201-4-git-send-email-wg@grandegger.com>
On Wed, Mar 25, 2009 at 11:08:20AM +0100, Wolfgang Grandegger wrote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
> NAND: FSL-UPM: add multi chip support
> NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
To me it looks good.
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> .../powerpc/dts-bindings/fsl/upm-nand.txt | 39 +++++++++++++++++++-
> 1 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> index 84a04d5..0272e70 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> @@ -5,9 +5,22 @@ Required properties:
> - reg : should specify localbus chip select and size used for the chip.
> - fsl,upm-addr-offset : UPM pattern offset for the address latch.
> - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
> -- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
>
> -Example:
> +Optional properties:
> +- fsl,upm-wait-flags : add chip-dependent short delays after running the
> + UPM pattern (0x1), after writing a data byte (0x2)
> + or after writing out a buffer (0x4).
> +- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
> + (R/B#). For multi-chip devices, "num-chips" GPIO definitions are
> + required.
> +- chip-delay : chip dependent delay for transfering data from array to
> + read registers (tR). Required if property "gpios" is not
> + used (R/B# pins not connected).
> +- num-chips : number of chips per device for multi-chip support.
> +- chip-offset : address offset between chips for multi-chip support. The
> + corresponding address lines are used to select the chip.
> +
> +Examples:
>
> upm@1,0 {
> compatible = "fsl,upm-nand";
> @@ -26,3 +39,25 @@ upm@1,0 {
> };
> };
> };
> +
> +upm@3,0 {
> + compatible = "fsl,upm-nand";
> + reg = <3 0x0 0x800>;
> + fsl,upm-addr-offset = <0x10>;
> + fsl,upm-cmd-offset = <0x08>;
> + fsl,upm-wait-flags = <0x5>;
> + /* Multi-chip device */
> + num-chips = <2>;
> + chip-offset = <0x200>;
> + chip-delay = <25>; // in micro-seconds
> +
> + nand@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "fs";
> + reg = <0x00000000 0x10000000>;
> + };
> + };
> +};
> --
> 1.6.0.6
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: Joakim Tjernlund @ 2009-03-25 15:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: 'linuxppc-dev Development', leoli, Netdev
In-Reply-To: <49CA39EA.6020208@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> wrote on 25/03/2009 15:04:26:
> Joakim Tjernlund a =E9crit :
> >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc=5Fgeth: Move freeing of TX packets to NAPI context.
> > Also increase NAPI weight somewhat.
> > This will make the system alot more responsive while
> > ping flooding the ucc=5Fgeth ethernet interaface.
> >=20
> >=20
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> > drivers/net/ucc=5Fgeth.c | 30 +++++++++++-------------------
> > drivers/net/ucc=5Fgeth.h | 2 +-
> > 2 files changed, 12 insertions(+), 20 deletions(-)
> >=20
> > diff --git a/drivers/net/ucc=5Fgeth.c b/drivers/net/ucc=5Fgeth.c
> > index 097aed8..7d5d110 100644
> > --- a/drivers/net/ucc=5Fgeth.c
> > +++ b/drivers/net/ucc=5Fgeth.c
> > @@ -3214,7 +3214,7 @@ static int ucc=5Fgeth=5Ftx(struct net=5Fdevice *d=
ev,=20
u8 txQ)
> > dev->stats.tx=5Fpackets++;
> >=20
> > /* Free the sk buffer associated with this TxBD */
> > - dev=5Fkfree=5Fskb=5Firq(ugeth->
> > + dev=5Fkfree=5Fskb(ugeth->
> > tx=5Fskbuff[txQ][ugeth->skb=5Fdirtytx[txQ]]);
> > ugeth->tx=5Fskbuff[txQ][ugeth->skb=5Fdirtytx[txQ]] =3D NULL;
> > ugeth->skb=5Fdirtytx[txQ] =3D
> > @@ -3248,9 +3248,16 @@ static int ucc=5Fgeth=5Fpoll(struct napi=5Fstruc=
t=20
*napi, int budget)
> > for (i =3D 0; i < ug=5Finfo->numQueuesRx; i++)
> > howmany +=3D ucc=5Fgeth=5Frx(ugeth, i, budget - howmany);
> >=20
>=20
> Cant you test (ucce & UCCE=5FTX=5FEVENTS) or something here to avoid
> taking lock and checking queues if not necessary ?
Probably, but I want this patch as simple as possible. There
are lots of optimizations left to do in this driver.
>=20
> > + /* Tx event processing */
> > + spin=5Flock(&ugeth->lock);
> > + for (i =3D 0; i < ug=5Finfo->numQueuesTx; i++) {
> > + ucc=5Fgeth=5Ftx(ugeth->dev, i);
> > + }
> > + spin=5Funlock(&ugeth->lock);
> > +
>=20
> Why tx completions dont change "howmany" ?
> It seems strange you changed UCC=5FGETH=5FDEV=5FWEIGHT if not taking into=
=20
account tx event above...
This is unclear and last I checked not very common amongst other drivers=20
in the
tree.
UCC=5FGETH=5FDEV=5FWEIGHT needs to be a bit bigger than the number of RX HW=
=20
buffers avaliable,
otherwise one won't be able to drain the whole queue in one go. Changing
weight to something bigger made a big difference.
Jocke
^ permalink raw reply
* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: Joakim Tjernlund @ 2009-03-25 15:21 UTC (permalink / raw)
To: avorontsov; +Cc: 'linuxppc-dev Development', leoli, Netdev
In-Reply-To: <20090325142540.GA20944@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 25/03/2009 15:25:40:
>
> On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> > >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00
2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> > Also increase NAPI weight somewhat.
> > This will make the system alot more responsive while
> > ping flooding the ucc_geth ethernet interaface.
>
> Some time ago I've tried a similar thing for this driver, but during
> tcp (or udp I don't quite remember) netperf tests I was getting tx
> watchdog timeouts after ~2-5 minutes of work. I was testing with a
> gigabit and 100 Mbit link, with 100 Mbit link the issue was not
> reproducible.
>
> Though, I recalling I was doing a bit more than your patch: I was
> also clearing the TX events in the ucce register before calling
> ucc_geth_tx, that way I was trying to avoid stale interrupts. That
Sure, but that is another patch I think.
> helped to increase an overall performance (not only responsiveness),
> but as I said my approach didn't pass the tests.
>
> I don't really think that your patch may cause this, but can you
> try netperf w/ this patch applied anyway? And see if it really
> doesn't cause any issues under stress?
Ran this on my host against my target board:
netperf -t UDP_RR -H 192.168.1.16
netperf -t UDP_STREAM -H 192.168.1.16
netperf -t TCP_STREAM -H 192.168.1.16
netperf -t TCP_SENDFILE -H 192.168.1.16
netperf -t TCP_MAERTS -H 192.168.1.16
netperf -t TCP_RR -H 192.168.1.16
netperf -t TCP_CRR -H 192.168.1.16
Didn't notice any timeouts, but I only have 100Mbit interfaces.
^ permalink raw reply
* Re: [PATCH v3 1/4] NAND: FSL-UPM: add multi chip support
From: Wolfgang Grandegger @ 2009-03-25 15:25 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20090325145719.GA32313@oksana.dev.rtsoft.ru>
Hi Anton,
Anton Vorontsov wrote:
> Hi Wolfgang,
>
> On Wed, Mar 25, 2009 at 11:08:18AM +0100, Wolfgang Grandegger wrote:
>> This patch adds support for multi-chip NAND devices to the FSL-UPM
>> driver. This requires support for multiple GPIOs for the RNB pins.
>> The NAND chips are selected through address lines defined by the
>> FDT property "chip-offset".
>>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> ---
>
> Some cosmetic issues are still there...
Normally I use checkpatch.pl to validate my patches, but ... grrr,
sorry. It finds all the obvious issues you reported.
[snip]
> When the cosmetic issues are fixed, I'll readily ack this patch.
Thanks, will resend a.s.a.p.
Wolfgang.
^ permalink raw reply
* FSL driver for powerpc linux2.6 (xilinx ML403)
From: Guangye Tian @ 2009-03-25 16:01 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am working with the xilinx ML403 evaluation board which has a
Virtex4 FPGA and one powerpc405 processor is integrated.
I am trying to develop a linux driver for FSL link for powerpc405. I
developed one first version (with the referce of the microblaze fsl
driver developped by Mr. John Williams for uClinux) as a loadable
module, and loaded it after Linux is booted. But when I run some
testing function like "cat /dev/fslfifo", it crashes the kernel.
I suppose that it is because FSL operations (like nget, nput, etc. )
are not part of the ppc instruction set and are realized by APU
instruction extension. For the processor to execute the extended
instructions correctly, the MSR register should be set accordingly to
enable APU. (XREG_MSR_APU_AVAILABLE + XREG_MSR_APU_ENABLE). Before I
worked with ppc without os, and the management of special purpose
registers are rather straight forward and it concerns only some
assembly language at the beginning of the main() function. But with
os, I have no experience dealing explicitely with special purpose
registers. So I tried the following:
I set the MSR at the initialisation phase by
mtmsr(XREG_MSR_APU_AVAILABLE | XREG_MSR_APU_ENABLE | mfmsr())
However, when I set the MSR at the initialization function, and test
afterwards, the MSR value is set back to some default value. I don't
know where it happened neighter do I know if I am using the correct
measure to change the MSR value.
Does anybody have any suggestions?
Thank you,
Guangye
^ permalink raw reply
* [PATCH] powerpc: Sanitize stack pointer in signal handling code
From: Josh Boyer @ 2009-03-25 16:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
stack pointer passed into the kernel. Most places handle this correctly, but
the signal handling code uses the passed value directly for allocating signal
stack frames.
This fixes the issue by introducing a get_clean_sp function that returns a
sanitized stack pointer. For 32-bit tasks on a 64-bit kernel, the stack
pointer is masked correctly. In all other cases, the stack pointer is simply
returned.
Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
get the properly sanitized stack. The callers are know to be 32 or 64-bit
statically.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/processor.h | 19 +++++++++++++++++++
arch/powerpc/kernel/signal.c | 4 ++--
arch/powerpc/kernel/signal.h | 2 +-
arch/powerpc/kernel/signal_32.c | 4 ++--
arch/powerpc/kernel/signal_64.c | 2 +-
5 files changed, 25 insertions(+), 6 deletions(-)
--- linux-2.6.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6/arch/powerpc/kernel/signal_32.c
@@ -836,7 +836,7 @@ int handle_rt_signal32(unsigned long sig
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
- rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf), 1);
addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -1182,7 +1182,7 @@ int handle_signal32(unsigned long sig, s
unsigned long newsp = 0;
/* Set up Signal Frame */
- frame = get_sigframe(ka, regs, sizeof(*frame));
+ frame = get_sigframe(ka, regs, sizeof(*frame), 1);
if (unlikely(frame == NULL))
goto badframe;
sc = (struct sigcontext __user *) &frame->sctx;
--- linux-2.6.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6/arch/powerpc/include/asm/processor.h
@@ -313,6 +313,25 @@ static inline void prefetchw(const void
#define HAVE_ARCH_PICK_MMAP_LAYOUT
#endif
+#ifdef CONFIG_PPC64
+static inline unsigned long get_clean_sp(struct pt_regs *regs, int is_32)
+{
+ unsigned long sp;
+
+ if (is_32)
+ sp = regs->gpr[1] & 0x0ffffffffUL;
+ else
+ sp = regs->gpr[1];
+
+ return sp;
+}
+#else
+static inline unsigned long get_clean_sp(struct pt_regs *regs, int is_32)
+{
+ return regs->gpr[1];
+}
+#endif
+
#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PROCESSOR_H */
--- linux-2.6.orig/arch/powerpc/kernel/signal.c
+++ linux-2.6/arch/powerpc/kernel/signal.c
@@ -26,12 +26,12 @@ int show_unhandled_signals = 0;
* Allocate space for the signal frame
*/
void __user * get_sigframe(struct k_sigaction *ka, struct pt_regs *regs,
- size_t frame_size)
+ size_t frame_size, int is_32)
{
unsigned long oldsp, newsp;
/* Default to using normal stack */
- oldsp = regs->gpr[1];
+ oldsp = get_clean_sp(regs, is_32);
/* Check for alt stack */
if ((ka->sa.sa_flags & SA_ONSTACK) &&
--- linux-2.6.orig/arch/powerpc/kernel/signal.h
+++ linux-2.6/arch/powerpc/kernel/signal.h
@@ -15,7 +15,7 @@
extern void do_signal(struct pt_regs *regs, unsigned long thread_info_flags);
extern void __user * get_sigframe(struct k_sigaction *ka, struct pt_regs *regs,
- size_t frame_size);
+ size_t frame_size, int is_32);
extern void restore_sigmask(sigset_t *set);
extern int handle_signal32(unsigned long sig, struct k_sigaction *ka,
--- linux-2.6.orig/arch/powerpc/kernel/signal_64.c
+++ linux-2.6/arch/powerpc/kernel/signal_64.c
@@ -402,7 +402,7 @@ int handle_rt_signal64(int signr, struct
unsigned long newsp = 0;
long err = 0;
- frame = get_sigframe(ka, regs, sizeof(*frame));
+ frame = get_sigframe(ka, regs, sizeof(*frame), 0);
if (unlikely(frame == NULL))
goto badframe;
^ permalink raw reply
* Re: [PATCH] powerpc: Sanitize stack pointer in signal handling code
From: Josh Boyer @ 2009-03-25 16:27 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20090325162359.GA2367@yoda.jdub.homelinux.org>
On Wed, Mar 25, 2009 at 12:23:59PM -0400, Josh Boyer wrote:
>On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
>stack pointer passed into the kernel. Most places handle this correctly, but
>the signal handling code uses the passed value directly for allocating signal
>stack frames.
>
>This fixes the issue by introducing a get_clean_sp function that returns a
>sanitized stack pointer. For 32-bit tasks on a 64-bit kernel, the stack
>pointer is masked correctly. In all other cases, the stack pointer is simply
>returned.
>
>Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
>get the properly sanitized stack. The callers are know to be 32 or 64-bit
>statically.
>
>Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Ben, this should look familiar. It's based on your current -next branch.
If you agree, I can send it to the -stable team for .27, .28 and .29.
josh
^ permalink raw reply
* Re: suspend-to-mem on the mpc8349e-mitx-gp?
From: Scott Wood @ 2009-03-25 16:31 UTC (permalink / raw)
To: Pavel Machek; +Cc: linuxppc-dev, Li Yang, Soohyung Cho
In-Reply-To: <20090325111113.GG24172@elf.ucw.cz>
Pavel Machek wrote:
>> Pavel, what's the preferred way for current PM sub-system?
>
> If you have single sleep state, use "mem" > /sys/power/state.
>
> If you have two, use mem and standby. Do you have more?
Some of our chips have two, and some have one. However, the sleep state
of the chips that have only one is the same as the "standby" state of
the chips that have two, not the "mem" state. Accepting "mem" and only
"mem" for the one-state chip seems like the most confusing of the
options discussed. There would be no consistent way for userspace to
request the milder suspend state.
-Scott
^ permalink raw reply
* Re: of_serial and device trees
From: Scott Wood @ 2009-03-25 16:39 UTC (permalink / raw)
To: Simon Kagstrom; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090325155113.52048fe0@seasc0532.dyn.rnd.as.sw.ericsson.se>
Simon Kagstrom wrote:
> There are no other versions yet, but I suppose there will be (it's
> implemented in a FPGA after all!). So what is the general handling of
> versions, should it be something like
>
> compatible = "ericsson,isf-pic", "ericsson,isf-pic-v2"
>
> etc if we'd make new revisions of the device?
Looks good.
>> I'm guessing that your FPGA PIC driver isn't getting its register address
>> from the device tree, given that it works without the ranges property?
>
> It is, but I didn't check it for correctness yet, so I suppose I might
> have mapped the wrong thing. The code looks like this:
>
> struct resource phys_addr;
>
> if (of_address_to_resource(np, 0, &phys_addr) != 0) {
> printk(KERN_ERR": Could not get ISF PIC memory resource\n");
> return NULL;
> }
>
> spin_lock_init(&isf->lock);
> isf->ioaddr = ioremap(phys_addr.start,
> phys_addr.end - phys_addr.start);
That looks good -- I'd have expected of_address_to_resource to fail,
though, when the ranges property was missing. The kernel's device tree
parsing code can sometimes be overly tolerant of broken device trees,
which is probably what happened.
-Scott
^ permalink raw reply
* ELDK with Xenomai for PPC
From: Goldberger, Yigal @ 2009-03-25 17:06 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]
Hi All,
I'll try to be as accurate as I can.
Yesterday I downloaded ELDK 4.2 from DENX site and Installed it.
I want to build a Xenomai enabled kernel.
I saw that my kernel is 2.6.24-xenomai and that's what I'm trying to build.
My target is freescale quicc II (MPC8248) and I want to start by building a Xenomai enabled kernel for a target board as close as possible to my custom board.
I know from the old build we had that the defconfig that was used to build the kernel was ads8272_defconfig ( I hope some research was done before choosing it... )
It probebly was sufficiently close since it worked fine with some configuraions and changes .
My board has 2 flash chips AMD29LV256ML (from which one is the boot memory) , 4SDRAM chips 48LC32M16A2 an FPGA from Xilinx with some logic as a peripheral device and that's about it.
It should comunicate with a host PC via Ethernet or via RS-232 serial com.
I'd like to get the following assistance :
A) help in building the kernel as is for this target board without changes .
B) hints as to how and where should modifications and changes be made to port to a custom board .
BTW :
Currently I did :
> make ads8272_defconfig
> make uImage
and I'm failing on :
CC drivers/net/fs_enet/mac-fcc.o
drivers/net/fs_enet/mac-fcc.c: In function 'fcc_cr_cmd':
drivers/net/fs_enet/mac-fcc.c:85: error: implicit declaration of function 'cpm_command'
make[3]: *** [drivers/net/fs_enet/mac-fcc.o] Error 1
make[2]: *** [drivers/net/fs_enet] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
Best Regards,
Yigal Goldberger.
________________________________
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.
To protect the environment please do not print this e-mail unless necessary.
NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
[-- Attachment #2: Type: text/html, Size: 5918 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/4] NAND: FSL-UPM: add multi chip support
From: Grant Likely @ 2009-03-25 17:26 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <49CA3503.5040006@grandegger.com>
On Wed, Mar 25, 2009 at 7:43 AM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> Grant Likely wrote:
>> On Wed, Mar 25, 2009 at 7:31 AM, Grant Likely <grant.likely@secretlab.ca=
> wrote:
>>> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger <wg@grandegger.com=
> wrote:
>>>> This patch adds support for multi-chip NAND devices to the FSL-UPM
>>>> driver. This requires support for multiple GPIOs for the RNB pins.
>>>> The NAND chips are selected through address lines defined by the
>>>> FDT property "chip-offset".
>>>>
>>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>>> Hi Wolfgang,
>>>
>>> Can you please send a sample device tree snippit for this and add
>>> documentation updates to your patch for the extended binding?
>>
>> Oh, and cc: devicetree-discuss@ozlabs.org in your next posting.
>
> OK, does patch 3/4 not already contain what you are looking for? See:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069787.html
Oops, sorry. Missed that.
> I separated it from the NAND patches because they go through the MTD
> maintainer(s).
>
> BTW: did you have a chance to look into the following RFC on I2C bus
> speed setting?
>
> =A0http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069489.html
No. Looking at it now.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Grant Likely @ 2009-03-25 17:48 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <1237975701-23201-4-git-send-email-wg@grandegger.com>
(cc'ing devicetree-discuss)
On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
> =A0NAND: FSL-UPM: add multi chip support
> =A0NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Mostly looks good to me; but some comments below.
> ---
> =A0.../powerpc/dts-bindings/fsl/upm-nand.txt =A0 =A0 =A0 =A0 =A0| =A0 39 =
+++++++++++++++++++-
> =A01 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Docume=
ntation/powerpc/dts-bindings/fsl/upm-nand.txt
> index 84a04d5..0272e70 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> @@ -5,9 +5,22 @@ Required properties:
> =A0- reg : should specify localbus chip select and size used for the chip=
.
> =A0- fsl,upm-addr-offset : UPM pattern offset for the address latch.
> =A0- fsl,upm-cmd-offset : UPM pattern offset for the command latch.
> -- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
>
> -Example:
> +Optional properties:
> +- fsl,upm-wait-flags : add chip-dependent short delays after running the
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UPM pattern (0x1), after wri=
ting a data byte (0x2)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or after writing out a buffe=
r (0x4).
> +- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pin=
s
> + =A0 =A0 =A0 =A0 (R/B#). For multi-chip devices, "num-chips" GPIO defini=
tions are
> + =A0 =A0 =A0 =A0 required.
> +- chip-delay : chip dependent delay for transfering data from array to
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0read registers (tR). Required if property "g=
pios" is not
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0used (R/B# pins not connected).
> +- num-chips : number of chips per device for multi-chip support.
> +- chip-offset : address offset between chips for multi-chip support. The
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 corresponding address lines are used to sel=
ect the chip.
Since these properties (chip-delay, num-chips and chip-offset) are
currently controller specific, it would probably be a good idea to
prefix 'fsl,' onto them. That way when common NAND controller
properties start getting defined then there won't be any concern about
conflicting with existing meanings. If you do see these as properties
that other NAND controllers will use, then maybe a 'nand-' prefix is
appropriate (like the SPI binding in booting-without-of).
For the chip offset, it's not clear what the meaning is. First, does
the UPM controller support access of multiple chips simultaneously?
If so, then can you elaborate in the description on how board design
translates to a chip-offset value. If it cannot, then it might be
better to have multiple tuples in the 'reg' property for each discrete
chip. Multiple reg tuples would also remove the need for the
num-chips property.
Cheers,
g.
> +
> +Examples:
>
> =A0upm@1,0 {
> =A0 =A0 =A0 =A0compatible =3D "fsl,upm-nand";
> @@ -26,3 +39,25 @@ upm@1,0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0};
> =A0};
> +
> +upm@3,0 {
> + =A0 =A0 =A0 compatible =3D "fsl,upm-nand";
> + =A0 =A0 =A0 reg =3D <3 0x0 0x800>;
> + =A0 =A0 =A0 fsl,upm-addr-offset =3D <0x10>;
> + =A0 =A0 =A0 fsl,upm-cmd-offset =3D <0x08>;
> + =A0 =A0 =A0 fsl,upm-wait-flags =3D <0x5>;
> + =A0 =A0 =A0 /* Multi-chip device */
> + =A0 =A0 =A0 num-chips =3D <2>;
> + =A0 =A0 =A0 chip-offset =3D <0x200>;
> + =A0 =A0 =A0 chip-delay =3D <25>; // in micro-seconds
> +
> + =A0 =A0 =A0 nand@0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 partition@0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D "fs";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x00000000=
0x10000000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 };
> +};
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: Joakim Tjernlund @ 2009-03-25 17:51 UTC (permalink / raw)
To: avorontsov; +Cc: 'linuxppc-dev Development', leoli, Netdev
In-Reply-To: <20090325142540.GA20944@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 25/03/2009 15:25:40:
> On Wed, Mar 25, 2009 at 02:30:49PM +0100, Joakim Tjernlund wrote:
> > >>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00
2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 24 Mar 2009 10:19:27 +0100
> > Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> > Also increase NAPI weight somewhat.
> > This will make the system alot more responsive while
> > ping flooding the ucc_geth ethernet interaface.
>
> Some time ago I've tried a similar thing for this driver, but during
> tcp (or udp I don't quite remember) netperf tests I was getting tx
> watchdog timeouts after ~2-5 minutes of work. I was testing with a
> gigabit and 100 Mbit link, with 100 Mbit link the issue was not
> reproducible.
>
> Though, I recalling I was doing a bit more than your patch: I was
> also clearing the TX events in the ucce register before calling
> ucc_geth_tx, that way I was trying to avoid stale interrupts. That
> helped to increase an overall performance (not only responsiveness),
> but as I said my approach didn't pass the tests.
>
> I don't really think that your patch may cause this, but can you
> try netperf w/ this patch applied anyway? And see if it really
> doesn't cause any issues under stress?
Does the line(in ucc_geth_tx()) look OK to you:
if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
break;
Sure does look fishy to me.
^ permalink raw reply
* Re: [RFC] powerpc: i2c-mpc: make I2C bus speed configurable
From: Grant Likely @ 2009-03-25 18:16 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <49C151FF.1080604@grandegger.com>
(cc'ing the devicetree-discuss mailing list)
On Wed, Mar 18, 2009 at 1:56 PM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> The I2C driver for the MPC still uses a fixed clock divider hard-coded
> into the driver. This issue has already been discussed twice:
>
> =A0http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21933.html
> =A0http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg26923.html
>
> Let's code speak ;-). The attached RFC patch used the following approach:
>
> - the SOC property "i2c-clock-frequency" defines the frequency of the
> =A0I2C source clock, which could be filled in by U-Boot. This avoids all
> =A0the fiddling with getting the proper source clock frequency for the
> =A0processor or board. I will provide a patch for U-Boot if this proposal
> =A0gets accepted.
I'm not thrilled with this since it depends on u-boot being upgraded
to work. Actually, since this is an i2c only property, I don't think
it belongs in the parent node at all. The 'clock-frequency' property
below is sufficient. Having both seems to be two properties
describing the exact same thing.
> - the I2C node uses the property "clock-frequency" to define the desired
> =A0I2C bus frequency. If 0, the FDR/DFSRR register already set by the
> =A0bootloader will not be touched.
I like the property, but I don't like overloading the definition. A
value of 0 should be undefined and another property used
("fsl,preserve-clocking" perhaps?) to say that the FDR/DFSRR is
already configured.
> - I use Timur's divider table approach from U-Boot as it's more
> =A0efficient than an appropriate algorithm (less code).
As I commented in the previous thread, I don't like the table approach
and I'd rather see it done programmaticaly. However, I'm not going to
oppose the patch over this issue. If it works and it doesn't mess up
the dts binding then I'm happy.
But, it is cleaner and less complex if you use the of_match table
.data element to select the correct setclock function. Also makes it
easier to handle setclock special cases as needed.
> - If none of the above new properties are defined, the old hard-coded
> =A0FDR/DFSRR register settings are used for backward compatibility.
good
> What do you think? I'm still not happy that the tables and lookup
> function are common code. But for the 82xx/85xx/86xx it's not obvious
> to me where to put it.
I think it is just fine where it is.
Cheers,
g.
>
> Note: I'm aware that this patch is not yet perfect, e.g. the documentatio=
n
> of the new bindings are missing and debug messages need to be removed.
>
> Wolfgang.
>
> ---
> =A0drivers/i2c/busses/i2c-mpc.c | =A0140 ++++++++++++++++++++++++++++++++=
+++++++----
> =A01 file changed, 128 insertions(+), 12 deletions(-)
>
> Index: linux-2.6.29-rc7/drivers/i2c/busses/i2c-mpc.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6.29-rc7.orig/drivers/i2c/busses/i2c-mpc.c
> +++ linux-2.6.29-rc7/drivers/i2c/busses/i2c-mpc.c
> @@ -58,6 +58,11 @@ struct mpc_i2c {
> =A0 =A0 =A0 =A0u32 flags;
> =A0};
>
> +struct mpc_i2c_div {
> + =A0 =A0 =A0 u16 divider;
> + =A0 =A0 =A0 u16 fdr; =A0 =A0 =A0 =A0/* including dfsrr */
> +};
> +
> =A0static __inline__ void writeccr(struct mpc_i2c *i2c, u32 x)
> =A0{
> =A0 =A0 =A0 =A0writeb(x, i2c->base + MPC_I2C_CR);
> @@ -153,16 +158,107 @@ static int i2c_wait(struct mpc_i2c *i2c,
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> -static void mpc_i2c_setclock(struct mpc_i2c *i2c)
> +static const struct mpc_i2c_div mpc_i2c_8xxx_divs[] =3D {
> + =A0 =A0 =A0 {160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
> + =A0 =A0 =A0 {288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
> + =A0 =A0 =A0 {416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
> + =A0 =A0 =A0 {544, 0x0b03}, {576, 0x0104}, {608, 0x1603}, {640, 0x0105},
> + =A0 =A0 =A0 {672, 0x2003}, {704, 0x0b05}, {736, 0x2b03}, {768, 0x0106},
> + =A0 =A0 =A0 {800, 0x3603}, {832, 0x0b06}, {896, 0x012a}, {960, 0x0107},
> + =A0 =A0 =A0 {1024, 0x012b}, {1088, 0x1607}, {1152, 0x0108}, {1216, 0x2b=
07},
> + =A0 =A0 =A0 {1280, 0x0109}, {1408, 0x1609}, {1536, 0x010a}, {1664, 0x16=
0a},
> + =A0 =A0 =A0 {1792, 0x012e}, {1920, 0x010b}, {2048, 0x012f}, {2176, 0x2b=
0b},
> + =A0 =A0 =A0 {2304, 0x010c}, {2560, 0x010d}, {2816, 0x2b0d}, {3072, 0x01=
0e},
> + =A0 =A0 =A0 {3328, 0x2b0e}, {3584, 0x0132}, {3840, 0x010f}, {4096, 0x01=
33},
> + =A0 =A0 =A0 {4608, 0x0110}, {5120, 0x0111}, {6144, 0x0112}, {7168, 0x01=
36},
> + =A0 =A0 =A0 {7680, 0x0113}, {8192, 0x0137}, {9216, 0x0114}, {10240, 0x0=
115},
> + =A0 =A0 =A0 {12288, 0x0116}, {14336, 0x013a}, {15360, 0x0117}, {16384, =
0x013b},
> + =A0 =A0 =A0 {18432, 0x0118}, {20480, 0x0119}, {24576, 0x011a}, {28672, =
0x013e},
> + =A0 =A0 =A0 {30720, 0x011b}, {32768, 0x013f}, {36864, 0x011c}, {40960, =
0x011d},
> + =A0 =A0 =A0 {49152, 0x011e}, {61440, 0x011f}
> +};
> +
> +/*
> + * Works for both, MPC5200 rev A and rev B processors. The rev B
> + * processors have 2 more bits, which are not used in the table below.
> + */
> +static const struct mpc_i2c_div mpc_i2c_52xx_divs[] =3D {
> + =A0 =A0 =A0 {20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
> + =A0 =A0 =A0 {28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
> + =A0 =A0 =A0 {36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
> + =A0 =A0 =A0 {56, 0x29}, {64, 0x2a}, {68, 0x07}, {72, 0x2b},
> + =A0 =A0 =A0 {80, 0x2c}, {88, 0x09}, {96, 0x2d}, {104, 0x0a},
> + =A0 =A0 =A0 {112, 0x2e}, {128, 0x2f}, {144, 0x0c}, {160, 0x30},
> + =A0 =A0 =A0 {192, 0x31}, {224, 0x32}, {240, 0x0f}, {256, 0x33},
> + =A0 =A0 =A0 {288, 0x10}, {320, 0x34}, {384, 0x35}, {448, 0x36},
> + =A0 =A0 =A0 {480, 0x13}, {512, 0x37}, {576, 0x14}, {640, 0x38},
> + =A0 =A0 =A0 {768, 0x39}, {896, 0x3a}, {960, 0x17}, {1024, 0x3b},
> + =A0 =A0 =A0 {1152, 0x18}, {1280, 0x3c}, {1536, 0x3d}, {1792, 0x3e},
> + =A0 =A0 =A0 {1920, 0x1b}, {2048, 0x3f}, {2304, 0x1c}, {2560, 0x1d},
> + =A0 =A0 =A0 {3072, 0x1e}, {3840, 0x1f}
> +};
> +
> +static u16 mpc_i2c_get_fdr(const struct mpc_i2c_div *divs, int count,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0u32 divider)
> =A0{
> - =A0 =A0 =A0 /* Set clock and filters */
> - =A0 =A0 =A0 if (i2c->flags & FSL_I2C_DEV_SEPARATE_DFSRR) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(0x31, i2c->base + MPC_I2C_FDR);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(0x10, i2c->base + MPC_I2C_DFSRR);
> - =A0 =A0 =A0 } else if (i2c->flags & FSL_I2C_DEV_CLOCK_5200)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(0x3f, i2c->base + MPC_I2C_FDR);
> - =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 writel(0x1031, i2c->base + MPC_I2C_FDR);
> + =A0 =A0 =A0 const struct mpc_i2c_div *div =3D NULL;
> + =A0 =A0 =A0 int i;
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* We want to choose an FDR/DFSR that generates an I2C bu=
s speed that
> + =A0 =A0 =A0 =A0* is equal to or lower than the requested speed.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 for (i =3D 0; i < count; i++) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 div =3D &divs[i];
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (div->divider >=3D divider)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return div ? div->fdr : 0;
> +}
> +
> +static void mpc_i2c_setclock(struct mpc_i2c *i2c, u32 src_clock, u32 clo=
ck)
> +{
> + =A0 =A0 =A0 u32 divider;
> + =A0 =A0 =A0 u16 fdr;
> +
> + =A0 =A0 =A0 if (src_clock && !clock)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return; /* clock already configured by boot=
loader */
> +
> + =A0 =A0 =A0 divider =3D (src_clock && clock) ? src_clock / clock : 0;
> +
> + =A0 =A0 =A0 if (i2c->flags & FSL_I2C_DEV_CLOCK_5200) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: old fdr=3D%d\n", readb(i2c->ba=
se + MPC_I2C_FDR));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (divider)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdr =3D mpc_i2c_get_fdr(mpc=
_i2c_52xx_divs,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 ARRAY_SIZE(mpc_i2c_52xx_divs),
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 divider);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdr =3D 0x3f; /* backward c=
ompatibility */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(fdr, i2c->base + MPC_I2C_FDR);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: clock %d Hz (fdr=3D%d)\n", clo=
ck, fdr);
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (divider)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdr =3D mpc_i2c_get_fdr(mpc=
_i2c_8xxx_divs,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 ARRAY_SIZE(mpc_i2c_8xxx_divs),
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 divider);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdr =3D 0x1031; /* backward=
compatibility */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (i2c->flags & FSL_I2C_DEV_SEPARATE_DFSRR=
) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: old dfsrr=3D%d=
fdr=3D%d\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0readb(i2c->b=
ase + MPC_I2C_DFSRR),
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0readb(i2c->b=
ase + MPC_I2C_FDR));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(fdr & 0xff, i2c->bas=
e + MPC_I2C_FDR);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeb(fdr >> 8, i2c->base =
+ MPC_I2C_DFSRR);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: clock %d Hz (d=
fsrr=3D%d fdr=3D%d)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock, fdr >=
> 8, fdr & 0xff);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: old fdr=3D%d\n=
",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0readl(i2c->b=
ase + MPC_I2C_FDR));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writel(fdr, i2c->base + MPC=
_I2C_FDR);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("I2C: clock %d Hz (f=
dr=3D%d)\n", clock, fdr);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 }
> =A0}
>
> =A0static void mpc_i2c_start(struct mpc_i2c *i2c)
> @@ -316,13 +412,33 @@ static struct i2c_adapter mpc_ops =3D {
>
> =A0static int __devinit fsl_i2c_probe(struct of_device *op, const struct =
of_device_id *match)
> =A0{
> - =A0 =A0 =A0 int result =3D 0;
> + =A0 =A0 =A0 struct device_node *parent;
> =A0 =A0 =A0 =A0struct mpc_i2c *i2c;
> + =A0 =A0 =A0 const u32 *prop;
> + =A0 =A0 =A0 u32 src_clock, clock;
> + =A0 =A0 =A0 int result =3D 0;
> + =A0 =A0 =A0 int plen;
> +
> + =A0 =A0 =A0 parent =3D of_get_parent(op->node);
> + =A0 =A0 =A0 if (!parent)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>
> =A0 =A0 =A0 =A0i2c =3D kzalloc(sizeof(*i2c), GFP_KERNEL);
> =A0 =A0 =A0 =A0if (!i2c)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
>
> + =A0 =A0 =A0 prop =3D of_get_property(parent, "i2c-clock-frequency", &pl=
en);
> + =A0 =A0 =A0 if (prop && plen =3D=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 src_clock =3D *prop;
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 src_clock =3D 0;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(op->node, "clock-frequency", &plen=
);
> + =A0 =A0 =A0 if (prop && plen =3D=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D *prop;
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock =3D 0;
> +
> =A0 =A0 =A0 =A0if (of_get_property(op->node, "dfsrr", NULL))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i2c->flags |=3D FSL_I2C_DEV_SEPARATE_DFSRR=
;
>
> @@ -348,8 +464,8 @@ static int __devinit fsl_i2c_probe(struc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail_request;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0}
> -
> - =A0 =A0 =A0 mpc_i2c_setclock(i2c);
> +
> + =A0 =A0 =A0 mpc_i2c_setclock(i2c, src_clock, clock);
>
> =A0 =A0 =A0 =A0dev_set_drvdata(&op->dev, i2c);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: suspend-to-mem on the mpc8349e-mitx-gp?
From: Pavel Machek @ 2009-03-25 18:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Li Yang, Soohyung Cho
In-Reply-To: <49CA5C7D.1050904@freescale.com>
On Wed 2009-03-25 11:31:57, Scott Wood wrote:
> Pavel Machek wrote:
>>> Pavel, what's the preferred way for current PM sub-system?
>>
>> If you have single sleep state, use "mem" > /sys/power/state.
>>
>> If you have two, use mem and standby. Do you have more?
>
> Some of our chips have two, and some have one. However, the sleep state
> of the chips that have only one is the same as the "standby" state of
> the chips that have two, not the "mem" state. Accepting "mem" and
> only
Ok, I guess it makes sense to use "standby" for the single sleep
state, then... It is not really a big deal, anyway.
> "mem" for the one-state chip seems like the most confusing of the
> options discussed. There would be no consistent way for userspace to
> request the milder suspend state.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: PATCH improve worst case module load times
From: Jianhua Ding @ 2009-03-25 19:14 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 687 bytes --]
Dear Mr. Brian Behlendorf,
I have read your post about improving module load time in the following
site and
Found it very helpful.
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
I have the similar issue with Linux 2.6.14 for PPC platform. Since I
cannot find
the original patch for 2.6.14 so I just manually merge some deltas from
2.6.27.
After patch the loading time is reduced dramatically however it traps
(DSI).
I wonder if you have heard any other related issues which I missed
patch.
Thanks and best regards,
Jianhua Ding
SW engineer at Nortel
PS: Attached please find the modified module.c file for your reference.
<<module.c>>
[-- Attachment #1.2: Type: text/html, Size: 1687 bytes --]
[-- Attachment #2: module.c --]
[-- Type: application/octet-stream, Size: 10403 bytes --]
/* Kernel module help for PPC.
Copyright (C) 2001 Rusty Russell.
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
*/
#include <linux/module.h>
#include <linux/moduleloader.h>
#include <linux/elf.h>
#include <linux/vmalloc.h>
#include <linux/fs.h>
#include <linux/string.h>
#include <linux/kernel.h>
#include <linux/cache.h>
#include <linux/sort.h>
#if 1
#define DEBUGP printk
#else
#define DEBUGP(fmt , ...)
#endif
LIST_HEAD(module_bug_list);
void *module_alloc(unsigned long size)
{
if (size == 0)
return NULL;
return vmalloc(size);
}
/* Free memory returned from module_alloc */
void module_free(struct module *mod, void *module_region)
{
vfree(module_region);
/* FIXME: If module_region == mod->init_region, trim exception
table entries. */
}
/* Count how many different relocations (different symbol, different
addend) */
static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
{
unsigned int i, r_info, r_addend, _count_relocs;
_count_relocs = 0;
r_info = 0;
r_addend = 0;
for (i = 0; i < num; i++)
/* Only count 24-bit relocs, others don't need stubs */
if (ELF32_R_TYPE(rela[i].r_info) == R_PPC_REL24 &&
(r_info != ELF32_R_SYM(rela[i].r_info) ||
r_addend != rela[i].r_addend)) {
_count_relocs++;
r_info = ELF32_R_SYM(rela[i].r_info);
r_addend = rela[i].r_addend;
}
return _count_relocs;
}
static int relacmp(const void *_x, const void *_y)
{
const Elf32_Rela *x, *y;
y = (Elf32_Rela *)_x;
x = (Elf32_Rela *)_y;
/* Compare the entire r_info (as opposed to ELF32_R_SYM(r_info) only) to
* make the comparison cheaper/faster. It won't affect the sorting or
* the counting algorithms' performance
*/
if (x->r_info < y->r_info)
return -1;
else if (x->r_info > y->r_info)
return 1;
else if (x->r_addend < y->r_addend)
return -1;
else if (x->r_addend > y->r_addend)
return 1;
else
return 0;
}
static void relaswap(void *_x, void *_y, int size)
{
uint32_t *x, *y, tmp;
int i;
y = (uint32_t *)_x;
x = (uint32_t *)_y;
for (i = 0; i < sizeof(Elf32_Rela) / sizeof(uint32_t); i++) {
tmp = x[i];
x[i] = y[i];
y[i] = tmp;
}
}
/* Get the potential trampolines size required of the init and
non-init sections */
static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
const Elf32_Shdr *sechdrs,
const char *secstrings,
int is_init)
{
unsigned long ret = 0;
unsigned i;
/* Everything marked ALLOC (this includes the exported
symbols) */
for (i = 1; i < hdr->e_shnum; i++) {
/* If it's called *.init*, and we're not init, we're
not interested */
if ((strstr(secstrings + sechdrs[i].sh_name, ".init") != 0)
!= is_init)
continue;
/* We don't want to look at debug sections. */
if (strstr(secstrings + sechdrs[i].sh_name, ".debug") != 0)
continue;
if (sechdrs[i].sh_type == SHT_RELA) {
DEBUGP("Found relocations in section %u\n", i);
DEBUGP("Ptr: %p. Number: %u\n",
(void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela));
/* Sort the relocation information based on a symbol and
* addend key. This is a stable O(n*log n) complexity
* alogrithm but it will reduce the complexity of
* count_relocs() to linear complexity O(n)
*/
sort((void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela),
sizeof(Elf32_Rela), relacmp, relaswap);
ret += count_relocs((void *)hdr
+ sechdrs[i].sh_offset,
sechdrs[i].sh_size
/ sizeof(Elf32_Rela))
* sizeof(struct ppc_plt_entry);
}
}
return ret;
}
int module_frob_arch_sections(Elf32_Ehdr *hdr,
Elf32_Shdr *sechdrs,
char *secstrings,
struct module *me)
{
unsigned int i;
/* Find .plt and .init.plt sections */
for (i = 0; i < hdr->e_shnum; i++) {
if (strcmp(secstrings + sechdrs[i].sh_name, ".init.plt") == 0)
me->arch.init_plt_section = i;
else if (strcmp(secstrings + sechdrs[i].sh_name, ".plt") == 0)
me->arch.core_plt_section = i;
}
if (!me->arch.core_plt_section || !me->arch.init_plt_section) {
printk("Module doesn't contain .plt or .init.plt sections.\n");
return -ENOEXEC;
}
/* Override their sizes */
sechdrs[me->arch.core_plt_section].sh_size
= get_plt_size(hdr, sechdrs, secstrings, 0);
sechdrs[me->arch.init_plt_section].sh_size
= get_plt_size(hdr, sechdrs, secstrings, 1);
return 0;
}
int apply_relocate(Elf32_Shdr *sechdrs,
const char *strtab,
unsigned int symindex,
unsigned int relsec,
struct module *module)
{
printk(KERN_ERR "%s: Non-ADD RELOCATION unsupported\n",
module->name);
return -ENOEXEC;
}
static inline int entry_matches(struct ppc_plt_entry *entry, Elf32_Addr val)
{
if (entry->jump[0] == 0x3d600000 + ((val + 0x8000) >> 16)
&& entry->jump[1] == 0x396b0000 + (val & 0xffff))
return 1;
return 0;
}
/* Set up a trampoline in the PLT to bounce us to the distant function */
static uint32_t do_plt_call(void *location,
Elf32_Addr val,
Elf32_Shdr *sechdrs,
struct module *mod)
{
struct ppc_plt_entry *entry;
DEBUGP("Doing plt for call to 0x%x at 0x%x\n", val, (unsigned int)location);
/* Init, or core PLT? */
if (location >= mod->module_core
&& location < mod->module_core + mod->core_size)
entry = (void *)sechdrs[mod->arch.core_plt_section].sh_addr;
else
entry = (void *)sechdrs[mod->arch.init_plt_section].sh_addr;
/* Find this entry, or if that fails, the next avail. entry */
while (entry->jump[0]) {
if (entry_matches(entry, val)) return (uint32_t)entry;
entry++;
}
/* Stolen from Paul Mackerras as well... */
entry->jump[0] = 0x3d600000+((val+0x8000)>>16); /* lis r11,sym@ha */
entry->jump[1] = 0x396b0000 + (val&0xffff); /* addi r11,r11,sym@l*/
entry->jump[2] = 0x7d6903a6; /* mtctr r11 */
entry->jump[3] = 0x4e800420; /* bctr */
DEBUGP("Initialized plt for 0x%x at %p\n", val, entry);
return (uint32_t)entry;
}
int apply_relocate_add(Elf32_Shdr *sechdrs,
const char *strtab,
unsigned int symindex,
unsigned int relsec,
struct module *module)
{
unsigned int i;
Elf32_Rela *rela = (void *)sechdrs[relsec].sh_addr;
Elf32_Sym *sym;
uint32_t *location;
uint32_t value;
DEBUGP("Applying ADD relocate section %u to %u\n", relsec,
sechdrs[relsec].sh_info);
for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
/* This is where to make the change */
location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
+ rela[i].r_offset;
/* This is the symbol it is referring to. Note that all
undefined symbols have been resolved. */
sym = (Elf32_Sym *)sechdrs[symindex].sh_addr
+ ELF32_R_SYM(rela[i].r_info);
/* `Everything is relative'. */
value = sym->st_value + rela[i].r_addend;
switch (ELF32_R_TYPE(rela[i].r_info)) {
case R_PPC_ADDR32:
/* Simply set it */
*(uint32_t *)location = value;
break;
case R_PPC_ADDR16_LO:
/* Low half of the symbol */
*(uint16_t *)location = value;
break;
case R_PPC_ADDR16_HI:
/* Higher half of the symbol */
*(uint16_t *)location = (value >> 16);
break;
case R_PPC_ADDR16_HA:
/* Sign-adjusted lower 16 bits: PPC ELF ABI says:
(((x >> 16) + ((x & 0x8000) ? 1 : 0))) & 0xFFFF.
This is the same, only sane.
*/
*(uint16_t *)location = (value + 0x8000) >> 16;
break;
case R_PPC_REL24:
if ((int)(value - (uint32_t)location) < -0x02000000
|| (int)(value - (uint32_t)location) >= 0x02000000)
value = do_plt_call(location, value,
sechdrs, module);
/* Only replace bits 2 through 26 */
DEBUGP("REL24 value = %08X. location = %08X\n",
value, (uint32_t)location);
DEBUGP("Location before: %08X.\n",
*(uint32_t *)location);
*(uint32_t *)location
= (*(uint32_t *)location & ~0x03fffffc)
| ((value - (uint32_t)location)
& 0x03fffffc);
DEBUGP("Location after: %08X.\n",
*(uint32_t *)location);
DEBUGP("ie. jump to %08X+%08X = %08X\n",
*(uint32_t *)location & 0x03fffffc,
(uint32_t)location,
(*(uint32_t *)location & 0x03fffffc)
+ (uint32_t)location);
break;
case R_PPC_REL32:
/* 32-bit relative jump. */
*(uint32_t *)location = value - (uint32_t)location;
break;
default:
printk("%s: unknown ADD relocation: %u\n",
module->name,
ELF32_R_TYPE(rela[i].r_info));
return -ENOEXEC;
}
}
return 0;
}
int module_finalize(const Elf_Ehdr *hdr,
const Elf_Shdr *sechdrs,
struct module *me)
{
char *secstrings;
unsigned int i;
me->arch.bug_table = NULL;
me->arch.num_bugs = 0;
/* Find the __bug_table section, if present */
secstrings = (char *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
for (i = 1; i < hdr->e_shnum; i++) {
if (strcmp(secstrings+sechdrs[i].sh_name, "__bug_table"))
continue;
me->arch.bug_table = (void *) sechdrs[i].sh_addr;
me->arch.num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
break;
}
/*
* Strictly speaking this should have a spinlock to protect against
* traversals, but since we only traverse on BUG()s, a spinlock
* could potentially lead to deadlock and thus be counter-productive.
*/
list_add(&me->arch.bug_list, &module_bug_list);
return 0;
}
void module_arch_cleanup(struct module *mod)
{
list_del(&mod->arch.bug_list);
}
struct bug_entry *module_find_bug(unsigned long bugaddr)
{
struct mod_arch_specific *mod;
unsigned int i;
struct bug_entry *bug;
list_for_each_entry(mod, &module_bug_list, bug_list) {
bug = mod->bug_table;
for (i = 0; i < mod->num_bugs; ++i, ++bug)
if (bugaddr == bug->bug_addr)
return bug;
}
return NULL;
}
^ permalink raw reply
* Re: [RFC] powerpc: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-03-25 19:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <fa686aa40903251116n2b7e8326r6c7cb9de8e101c76@mail.gmail.com>
Grant Likely wrote:
> (cc'ing the devicetree-discuss mailing list)
>
> On Wed, Mar 18, 2009 at 1:56 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> The I2C driver for the MPC still uses a fixed clock divider hard-coded
>> into the driver. This issue has already been discussed twice:
>>
>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21933.html
>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg26923.html
>>
>> Let's code speak ;-). The attached RFC patch used the following approach:
>>
>> - the SOC property "i2c-clock-frequency" defines the frequency of the
>> I2C source clock, which could be filled in by U-Boot. This avoids all
>> the fiddling with getting the proper source clock frequency for the
>> processor or board. I will provide a patch for U-Boot if this proposal
>> gets accepted.
>
> I'm not thrilled with this since it depends on u-boot being upgraded
> to work. Actually, since this is an i2c only property, I don't think
> it belongs in the parent node at all. The 'clock-frequency' property
> below is sufficient. Having both seems to be two properties
> describing the exact same thing.
But it's not the same thing. The "i2c-clock-frequency" is the frequency
of the source clock distributed to the I2C devices and pends on the
processor type or even board. Deriving that frequency is tricky and
awkwards, e.g. have a look to u-boot/cpu/mpc85xx/speed.c to understand
what I mean. Maybe "i2c-source-clock-frequency" would be a more
appropriate name, though. As an alternative, we also discussed using a
divider property instead, e.g. "i2c-clock-divider" , which would not
depend on an up-to-date U-Boot version.
>> - the I2C node uses the property "clock-frequency" to define the desired
>> I2C bus frequency. If 0, the FDR/DFSRR register already set by the
>> bootloader will not be touched.
>
> I like the property, but I don't like overloading the definition. A
> value of 0 should be undefined and another property used
> ("fsl,preserve-clocking" perhaps?) to say that the FDR/DFSRR is
> already configured.
Fine for me. In fact, that's what we actually need ;-).
>> - I use Timur's divider table approach from U-Boot as it's more
>> efficient than an appropriate algorithm (less code).
>
> As I commented in the previous thread, I don't like the table approach
> and I'd rather see it done programmaticaly. However, I'm not going to
> oppose the patch over this issue. If it works and it doesn't mess up
> the dts binding then I'm happy.
Why should it mess up the dts binding? It's just the more efficient way
to implement it (less code). The result is the same. I will send some
figures tomorrow.
> But, it is cleaner and less complex if you use the of_match table
> .data element to select the correct setclock function. Also makes it
> easier to handle setclock special cases as needed.
As you wrote in the a previous thread:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg22368.html
This will work for most processors. Unfortunately for a few of them some
register setting must be checked as well, e.g. for the mpc8544 and the
table needs to be updated for each new MPC processor showing up. A SOC
property "i2c-clock-divider" would be more transparent and less
confusing. I'm personally not a friend of this magic fsl,mpcNNNN-deivce
compatibility property. It gets often added to the FDT nodes, but it's
rarely used by the Linux code.
>> - If none of the above new properties are defined, the old hard-coded
>> FDR/DFSRR register settings are used for backward compatibility.
>
> good
>
>> What do you think? I'm still not happy that the tables and lookup
>> function are common code. But for the 82xx/85xx/86xx it's not obvious
>> to me where to put it.
>
> I think it is just fine where it is.
OK.
Already the previous discussions showed that there are different
opinions :-(.
Wolfgang.
^ permalink raw reply
* /proc/<pid>/maps offset output broken
From: Chris Friesen @ 2009-03-25 19:24 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel-owner
I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
was surprised when it failed. It turns out that at least on my ppc64 G5
machine the offset value for the last entry is strange--it shows up as a
64-bit value even though the process itself is only 32-bit.
This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
haven't yet tested anything else in between.
[cfriesen@localhost cfriesen]$ cat /proc/self/maps
00100000-00103000 r-xp 00100000 00:00 0 [vdso]
0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
10015000-10036000 rwxp 10015000 00:00 0 [heap]
f7deb000-f7feb000 r--p 00000000 08:03 2560322
/usr/lib/locale/locale-archive
f7feb000-f7fec000 rw-p f7feb000 00:00 0
ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
I'm at a loss to explain what's going on here. Anyone got any ideas?
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Wolfgang Grandegger @ 2009-03-25 20:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <fa686aa40903251048g479d63f8i5a715defdbfc33d4@mail.gmail.com>
Grant Likely wrote:
> (cc'ing devicetree-discuss)
>
> On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> This patch adds documentation for the new NAND FSL UPM bindings for:
>>
>> NAND: FSL-UPM: add multi chip support
>> NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>
> Mostly looks good to me; but some comments below.
>
>> ---
>> .../powerpc/dts-bindings/fsl/upm-nand.txt | 39 +++++++++++++++++++-
>> 1 files changed, 37 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
>> index 84a04d5..0272e70 100644
>> --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
>> +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
>> @@ -5,9 +5,22 @@ Required properties:
>> - reg : should specify localbus chip select and size used for the chip.
>> - fsl,upm-addr-offset : UPM pattern offset for the address latch.
>> - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
>> -- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
>>
>> -Example:
>> +Optional properties:
>> +- fsl,upm-wait-flags : add chip-dependent short delays after running the
>> + UPM pattern (0x1), after writing a data byte (0x2)
>> + or after writing out a buffer (0x4).
>> +- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
>> + (R/B#). For multi-chip devices, "num-chips" GPIO definitions are
>> + required.
>> +- chip-delay : chip dependent delay for transfering data from array to
>> + read registers (tR). Required if property "gpios" is not
>> + used (R/B# pins not connected).
>> +- num-chips : number of chips per device for multi-chip support.
>> +- chip-offset : address offset between chips for multi-chip support. The
>> + corresponding address lines are used to select the chip.
>
> Since these properties (chip-delay, num-chips and chip-offset) are
> currently controller specific, it would probably be a good idea to
> prefix 'fsl,' onto them. That way when common NAND controller
> properties start getting defined then there won't be any concern about
> conflicting with existing meanings. If you do see these as properties
> that other NAND controllers will use, then maybe a 'nand-' prefix is
> appropriate (like the SPI binding in booting-without-of).
The chip-delay is NAND device specific. The proper value can be find in
the data sheet. num-chip is also quite generic. A prefix 'nand-' would
be fine for me. But fsl,upm-chip-offset would be more appropriate than
just chip-offset, indeed.
> For the chip offset, it's not clear what the meaning is. First, does
> the UPM controller support access of multiple chips simultaneously?
The offset drives the corresponding address lines, which are used to
select the chip. That's how it's done on the TQM8548 board. In
principle, the chips could also be selected through dedicated GPIO pins.
Well, I'm not a hardware guy.
> If so, then can you elaborate in the description on how board design
> translates to a chip-offset value. If it cannot, then it might be
> better to have multiple tuples in the 'reg' property for each discrete
> chip. Multiple reg tuples would also remove the need for the
> num-chips property.
The node still describes one device mapping all relevant control
registers. How about using fsl,upm-chip-offsets = <0x200 0x400>. It
would be more generic and makes num-chips obsolete as well. And the
property would be reserved for that way of implementing the chip select
in hardware.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
From: David Miller @ 2009-03-25 21:39 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: netdev, leoli, linuxppc-dev
In-Reply-To: <1237987849.2194.9.camel@gentoo-jocke.transmode.se>
From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date: Wed, 25 Mar 2009 14:30:49 +0100
> >From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI weight somewhat.
> This will make the system alot more responsive while
> ping flooding the ucc_geth ethernet interaface.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
The weight is not for the sake of your device, it's for
the sake of fairness with others.
Please just use 64, like every other driver does.
I'm not applying this.
^ 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