Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Geert Uytterhoeven]

On Thu, 5 Mar 2009, Olaf Hering wrote:
> Am 04.03.2009 um 14:57 schrieb Geert Uytterhoeven:
> >Ideally, we think it would be best if the existing MTD-based ps3vram driver
> >would be replaced by the new block-based ps3vram driver before 2.6.29 is
> >released. This would relieve the burden of supporting two different swap
> >space
> >schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro
> >maintainer's shoulders, as in that case there would never have been a stable
> >kernel version containing the MTD-based ps3vram driver.
> 
> openSuSE already ships with the ps3vram driver since a two releases.
> A simple name based udev rule could symlink ps3vram to mtdblock0, so an
> upgrade
> will not break existing setups.

OK.

> >+obj-$(CONFIG_PS3_VRAM)  += ps3vram_ng.o
> 
> Please give the driver the obvious name "ps3vram", that way upgrading will be
> smooth.

Sure, as I said:

| I'll submit a patch to remove the MTD
| ps3vram and add the new driver as ps3vram (instead of ps3vram-ng).

> I see our old mtddriver does not have modalias support for autoloading.

You forgot to backport commit 0a2d15b928e0b1673d4ed5f48d95af211b6fcc06
("mtd/ps3vram: Add modalias support to the ps3vram driver") to the openSuSE
tree?

> Hopefully the new driver has this feature.

Yes, it has.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Jens Axboe]

On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
>   Hi,
> 
> Below is the rewrite of the PS3 Video RAM Storage Driver as a plain block
> device, as requested by Arnd Bergmann.
> 
> The MTD-based PS3 Video RAM Storage Driver was integrated into the mainline
> kernel in 2.6.29-rc1.
> 
> Ideally, we think it would be best if the existing MTD-based ps3vram driver
> would be replaced by the new block-based ps3vram driver before 2.6.29 is
> released. This would relieve the burden of supporting two different swap space
> schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro
> maintainer's shoulders, as in that case there would never have been a stable
> kernel version containing the MTD-based ps3vram driver.
> 
> What do you think? If this is accepted, I'll submit a patch to remove the MTD
> ps3vram and add the new driver as ps3vram (instead of ps3vram-ng).
> 
> Thanks for your (review and other) comments!

I'd rewrite this as a ->make_request_fn handler instead. Then you can
get rid of the kernel thread. IOW, change

queue = blk_init_queue(ps3vram_request, &priv->lock);

to

queue = blk_alloc_queue(GFP_KERNEL);
blk_queue_make_request(queue, ps3vram_make_request);

Add error handling of course, and call blk_queue_max_*() to set your
limits for this device. Then add a ps3vram_make_request() ala:

static void ps3vram_do_request(struct request_queue *q, struct bio *bio)
{
struct ps3_system_bus_device *dev = q->queuedata;
struct ps3vram_priv *priv = dev->core.driver_data;
int write, res, err = -EIO;
struct bio_vec *bv;
sector_t sector;
loff_t offset;
size_t len, retlen;
int i;

write = bio_data_dir(bio) == WRITE;

sector = bio->bi_sector;
bio_for_each_segment(bv, bio, i) {
char *ptr = page_address(bv->bv_page) + bv->bv_offset;

len = bv->bv_len;
offset = sector << 9;

if (write)
res = ps3vram_write(dev, offset, len, &retlen, ptr);
else
res = ps3vram_read(dev, offset, len, &retlen, ptr);

if (res) {
dev_err(&dev->core, "%s failed\n", op);
goto out;
}

if (retlen != len) {
dev_err(&dev->core, "Short %s\n", op);
goto out;
}
sector += (len >> 9);
}

dev_dbg(&dev->core, "%s completed\n", op);
err = 0;
out:
bio_endio(bio, err);
}

I just typed it here, so if it doesn't compile you get to keep the
pieces :-)

Since ps3 is very RAM limited, I didn't bother with any highmem mapping
for the bio, since I gather that isn't an issue on that platform. You
may want to detail that in a comment above the page_addres() thing at
the top of the loop, though.

-- 
Jens Axboe

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Cbe-oss-dev] [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Marcus G. Daniels]

Geert Uytterhoeven wrote:

Ideally, we think it would be best if the existing MTD-based ps3vram driver
would be replaced by the new block-based ps3vram driver before 2.6.29 is
released. This would relieve the burden of supporting two different swap space
schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro
maintainer's shoulders, as in that case there would never have been a stable
kernel version containing the MTD-based ps3vram driver.
[..]
  - ps3vram-ng is faster than ps3vram:
  o 1 MiB blocks: +50% (read), +5% (write)
  o 4 KiB blocks: +50% (read), +5% (write)
  o 512 B blocks: +10% (read), +10% (write)
  
Fwiw, it's a useful swap device, since space is so limited -- the 
performance improvements are certainly appealing too.


Marcus
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

On LINUX FOR POWERPC EMBEDDED PPC4XX git tree

[Cheng Renquan]

Hello Josh,
  Today I want to check if there are new changes from your git tree,
I read it from the MAINTAINERS file, but git told it can't find that
tree, then I go to the web,
http://www.kernel.org/pub/scm/linux/kernel/git/jwboyer/
and found your tree's name has changed,

However, please remember also change the MAINTAINERS file,

Thanks,

diff --git a/MAINTAINERS b/MAINTAINERS
index 59fd2d1..db268cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2716,7 +2716,7 @@ P:Matt Porter
 M: mpor...@kernel.crashing.org
 W: http://www.penguinppc.org/
 L: linuxppc-dev@ozlabs.org
-T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git
+T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
 S: Maintained

 LINUX FOR POWERPC EMBEDDED XILINX VIRTEX

-- 
Cheng Renquan (程任全), from Shenzhen, China
Joe DiMaggio  - "Pair up in threes."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Geert Uytterhoeven]

On Thu, 5 Mar 2009, Geert Uytterhoeven wrote:
> On Thu, 5 Mar 2009, Olaf Hering wrote:
> > I see our old mtddriver does not have modalias support for autoloading.
> 
> You forgot to backport commit 0a2d15b928e0b1673d4ed5f48d95af211b6fcc06
> ("mtd/ps3vram: Add modalias support to the ps3vram driver") to the openSuSE
> tree?

Or do you mean that udev doesn't load mtdblock automatically?

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Geert Uytterhoeven]

Hi Jens,

On Thu, 5 Mar 2009, Jens Axboe wrote:
> On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain block
> > device, as requested by Arnd Bergmann.
> > 
> > The MTD-based PS3 Video RAM Storage Driver was integrated into the mainline
> > kernel in 2.6.29-rc1.
> > 
> > Ideally, we think it would be best if the existing MTD-based ps3vram driver
> > would be replaced by the new block-based ps3vram driver before 2.6.29 is
> > released. This would relieve the burden of supporting two different swap 
> > space
> > schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro
> > maintainer's shoulders, as in that case there would never have been a stable
> > kernel version containing the MTD-based ps3vram driver.
> > 
> > What do you think? If this is accepted, I'll submit a patch to remove the 
> > MTD
> > ps3vram and add the new driver as ps3vram (instead of ps3vram-ng).
> > 
> > Thanks for your (review and other) comments!
> 
> I'd rewrite this as a ->make_request_fn handler instead. Then you can
> get rid of the kernel thread. IOW, change
> 
> queue = blk_init_queue(ps3vram_request, &priv->lock);
> 
> to
> 
> queue = blk_alloc_queue(GFP_KERNEL);
> blk_queue_make_request(queue, ps3vram_make_request);

Thanks, I didn't know that part...

> Add error handling of course, and call blk_queue_max_*() to set your
> limits for this device.

I took out the blk_queue_max_*() calls (compared to ps3disk.c), as none of the
limits apply, and the defaults are fine.

Is that OK, or is it better to make it explicit?

> Then add a ps3vram_make_request() ala:

> static void ps3vram_do_request(struct request_queue *q, struct bio *bio)
> {
>   struct ps3_system_bus_device *dev = q->queuedata;
>   struct ps3vram_priv *priv = dev->core.driver_data;
>   int write, res, err = -EIO;
> struct bio_vec *bv;
>   sector_t sector;
>   loff_t offset;
>   size_t len, retlen;
> int i;
> 
>   write = bio_data_dir(bio) == WRITE;
> 
>   sector = bio->bi_sector;
> bio_for_each_segment(bv, bio, i) {
> char *ptr = page_address(bv->bv_page) + bv->bv_offset;
> 
> len = bv->bv_len;
>   offset = sector << 9;
> 
>   if (write)
>   res = ps3vram_write(dev, offset, len, &retlen, ptr);
>   else
>   res = ps3vram_read(dev, offset, len, &retlen, ptr);
> 
>   if (res) {
>   dev_err(&dev->core, "%s failed\n", op);
>   goto out;
>   }
> 
>   if (retlen != len) {
>   dev_err(&dev->core, "Short %s\n", op);
>   goto out;
>   }
> sector += (len >> 9);
> }
> 
>   dev_dbg(&dev->core, "%s completed\n", op);
> err = 0;
> out:
> bio_endio(bio, err);
> }
> 
> I just typed it here, so if it doesn't compile you get to keep the
> pieces :-)

OK, I'll give it a try...

BTW, does this mean the `simple' way, which I used based on LDD3, is
deprecated?

> Since ps3 is very RAM limited, I didn't bother with any highmem mapping
> for the bio, since I gather that isn't an issue on that platform. You
> may want to detail that in a comment above the page_addres() thing at
> the top of the loop, though.

PS3 is ppc64, so no highmem. But I guess I best add the code for that anyway,
in case people will copy the driver in the future (I remember receiving a
similar comment for ps3disk).

Thanks for your comments!

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Jens Axboe]

On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
>   Hi Jens,
> 
> On Thu, 5 Mar 2009, Jens Axboe wrote:
> > On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain block
> > > device, as requested by Arnd Bergmann.
> > >
> > > The MTD-based PS3 Video RAM Storage Driver was integrated into the 
> > > mainline
> > > kernel in 2.6.29-rc1.
> > >
> > > Ideally, we think it would be best if the existing MTD-based ps3vram 
> > > driver
> > > would be replaced by the new block-based ps3vram driver before 2.6.29 is
> > > released. This would relieve the burden of supporting two different swap 
> > > space
> > > schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro
> > > maintainer's shoulders, as in that case there would never have been a 
> > > stable
> > > kernel version containing the MTD-based ps3vram driver.
> > >
> > > What do you think? If this is accepted, I'll submit a patch to remove the 
> > > MTD
> > > ps3vram and add the new driver as ps3vram (instead of ps3vram-ng).
> > >
> > > Thanks for your (review and other) comments!
> >
> > I'd rewrite this as a ->make_request_fn handler instead. Then you can
> > get rid of the kernel thread. IOW, change
> >
> > queue = blk_init_queue(ps3vram_request, &priv->lock);
> >
> > to
> >
> > queue = blk_alloc_queue(GFP_KERNEL);
> > blk_queue_make_request(queue, ps3vram_make_request);
> 
> Thanks, I didn't know that part...
> 
> > Add error handling of course, and call blk_queue_max_*() to set your
> > limits for this device.
> 
> I took out the blk_queue_max_*() calls (compared to ps3disk.c), as
> none of the limits apply, and the defaults are fine.
> 
> Is that OK, or is it better to make it explicit?

I think it's always good to make it explicit. Plus for this case you
definitely need it, as blk_init_queue() wont do it for you anymore.

> > Then add a ps3vram_make_request() ala:
> 
> > static void ps3vram_do_request(struct request_queue *q, struct bio *bio)
> > {
> > struct ps3_system_bus_device *dev = q->queuedata;
> > struct ps3vram_priv *priv = dev->core.driver_data;
> > int write, res, err = -EIO;
> > struct bio_vec *bv;
> > sector_t sector;
> > loff_t offset;
> > size_t len, retlen;
> > int i;
> >
> > write = bio_data_dir(bio) == WRITE;
> >
> > sector = bio->bi_sector;
> > bio_for_each_segment(bv, bio, i) {
> > char *ptr = page_address(bv->bv_page) + bv->bv_offset;
> >
> > len = bv->bv_len;
> > offset = sector << 9;
> >
> > if (write)
> > res = ps3vram_write(dev, offset, len, &retlen, ptr);
> > else
> > res = ps3vram_read(dev, offset, len, &retlen, ptr);
> >
> > if (res) {
> > dev_err(&dev->core, "%s failed\n", op);
> > goto out;
> > }
> >
> > if (retlen != len) {
> > dev_err(&dev->core, "Short %s\n", op);
> > goto out;
> > }
> > sector += (len >> 9);
> > }
> >
> > dev_dbg(&dev->core, "%s completed\n", op);
> > err = 0;
> > out:
> > bio_endio(bio, err);
> > }
> >
> > I just typed it here, so if it doesn't compile you get to keep the
> > pieces :-)
> 
> OK, I'll give it a try...
> 
> BTW, does this mean the `simple' way, which I used based on LDD3, is
> deprecated?

Depends.. It's obviously not a very effective approach, since you punt
to a thread for each request. But if you need the IO scheduler helping
you with merging and sorting (for a rotational device), it still has
some merit. For this particular case, the ->make_request_fn approach is
much better.

> > Since ps3 is very RAM limited, I didn't bother with any highmem mapping
> > for the bio, since I gather that isn't an issue on that platform. You
> > may want to detail that in a comment above the page_addres() thing at
> > the top of the loop, though.
> 
> PS3 is ppc64, so no highmem. But I guess I best add the code for that anyway,
> in case people will copy the driver in the future (I remember receiving a
> similar comment for ps3disk).

I'd prefer just the comment, since you have to be able to handle
disabled interrupts on return from bvec_kmap_irq() if you use that. And
that would just complicate your driver, for something that you don't
need. So I'd put the comment in there stating why it's OK to just use
page_address() instead. If people copy-paste the code to some other
driver, then they will get the comment as well.

-- 
Jens Axboe

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: support IRQ from GPIO trough OF and GPIOLIB

[Henk Stegeman]

I forgot to include my  changes in arch/powerpc/include/asm/gpio.h:

diff --git a/arch/powerpc/include/asm/gpio.h b/arch/powerpc/include/asm/gpio.h
index ea04632..38762ed 100644
--- a/arch/powerpc/include/asm/gpio.h
+++ b/arch/powerpc/include/asm/gpio.h
@@ -38,12 +38,9 @@ static inline int gpio_cansleep(unsigned int gpio)
return __gpio_cansleep(gpio);
 }

-/*
- * Not implemented, yet.
- */
 static inline int gpio_to_irq(unsigned int gpio)
 {
-   return -ENOSYS;
+   return __gpio_to_irq(gpio);
 }

 static inline int irq_to_gpio(unsigned int irq)


On Thu, Mar 5, 2009 at 12:15 PM, Henk Stegeman  wrote:
> Hello,
>
> I have an SPI device that sends an IRQ to the CPU (MPC5200) via GPIO (GPT6):
>
> gpt6: ti...@660 {       // General Purpose Timer GPT6 in GPIO mode for
> SMC4000IO sample irq.
>        compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
>        cell-index = <6>;
>        reg = <0x660 0x10>;
>        interrupts = <1 15 0>;
>        interrupt-parent = <&mpc5200_pic>;
>        gpio-controller;
>        #gpio-cells = <2>;
> };
>
> s...@f00 {
>        #address-cells = <1>;
>        #size-cells = <0>;
>        compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
>        reg = <0xf00 0x20>;
>        interrupts = <2 13 0 2 14 0>;
>        interrupt-parent = <&mpc5200_pic>;
>        gpios = <&gpt4 0 0>;
>
>        io-control...@0 {
>                compatible = "microkey,smc4000io";
>                linux,modalias = "of_smc4000io";
>                spi-max-frequency = <100>;
>                spi-cpha;
>                reg = <0>;
>                // gpios: first is IRQ to cpu
>                gpios = <&gpt6 0 0>;
>                word-delay-us = <0>;
>        };
> };
>
> I've got it working for a mm_gpio, but it's probably not the right
> approach, I have the following questions to get to the right solution:
> - Should gpiolib's gpio_to_irq function indeed return the IRQ that was
> specified at the GPIO by the DTS (interrupts = <1 15 0>)?
>  The effect is that if the IRQ is not specified in the DTS the
> gpio_to_irq returns NO_IRQ.
>  (On the MPC5200 the IRQ is fixed for GPT6, so instead the cell-index
> could also be used to return a gpio's IRQ)
> - If a GPIO controller supports several GPIOs but one IRQ, is it
> defined what gpio_to_irq should return?
> - Is it okay for gpio_to_irq to return NO_IRQ?  (returned by
> irq_of_parse_and_map) if irq is not defined?
>
>
> Henk.
>
> diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
> index 6eea601..81927d7 100644
> --- a/drivers/of/gpio.c
> +++ b/drivers/of/gpio.c
> @@ -150,6 +150,17 @@ int of_gpio_simple_xlate(struct of_gpio_chip
> *of_gc, struct device_node *np,
>  }
>  EXPORT_SYMBOL(of_gpio_simple_xlate);
>
> +static int of_mm_gpio_to_irq(struct gpio_chip *gc, unsigned int gpio)
> +{
> +       struct of_mm_gpio_chip *mm_gc;
> +       struct of_gpio_chip *of_gc;
> +
> +       of_gc = container_of(gc, struct of_gpio_chip, gc);
> +       mm_gc = container_of(of_gc, struct of_mm_gpio_chip, of_gc);
> +       return mm_gc->irq;
> +
> +}
> +
>  /**
>  * of_mm_gpiochip_add - Add memory mapped GPIO chip (bank)
>  * @np:                device node of the GPIO chip
> @@ -188,6 +199,9 @@ int of_mm_gpiochip_add(struct device_node *np,
>
>        gc->base = -1;
>
> +       mm_gc->irq = irq_of_parse_and_map(np, 0);
> +       gc->to_irq = of_mm_gpio_to_irq;
> +
>        if (!of_gc->xlate)
>                of_gc->xlate = of_gpio_simple_xlate;
>
> diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
> index fc2472c..17fe9ed 100644
> --- a/include/linux/of_gpio.h
> +++ b/include/linux/of_gpio.h
> @@ -54,6 +54,7 @@ struct of_mm_gpio_chip {
>        struct of_gpio_chip of_gc;
>        void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
>        void __iomem *regs;
> +       int irq;
>  };
>
>  static inline struct of_mm_gpio_chip *to_of_mm_gpio_chip(struct gpio_chip 
> *gc)
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

support IRQ from GPIO trough OF and GPIOLIB

[Henk Stegeman]

Hello,

I have an SPI device that sends an IRQ to the CPU (MPC5200) via GPIO (GPT6):

gpt6: ti...@660 {   // General Purpose Timer GPT6 in GPIO mode for
SMC4000IO sample irq.
compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
cell-index = <6>;
reg = <0x660 0x10>;
interrupts = <1 15 0>;
interrupt-parent = <&mpc5200_pic>;
gpio-controller;
#gpio-cells = <2>;
};

s...@f00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <0xf00 0x20>;
interrupts = <2 13 0 2 14 0>;
interrupt-parent = <&mpc5200_pic>;
gpios = <&gpt4 0 0>;

io-control...@0 {
compatible = "microkey,smc4000io";
linux,modalias = "of_smc4000io";
spi-max-frequency = <100>;
spi-cpha;
reg = <0>;
// gpios: first is IRQ to cpu
gpios = <&gpt6 0 0>;
word-delay-us = <0>;
};
};

I've got it working for a mm_gpio, but it's probably not the right
approach, I have the following questions to get to the right solution:
- Should gpiolib's gpio_to_irq function indeed return the IRQ that was
specified at the GPIO by the DTS (interrupts = <1 15 0>)?
 The effect is that if the IRQ is not specified in the DTS the
gpio_to_irq returns NO_IRQ.
 (On the MPC5200 the IRQ is fixed for GPT6, so instead the cell-index
could also be used to return a gpio's IRQ)
- If a GPIO controller supports several GPIOs but one IRQ, is it
defined what gpio_to_irq should return?
- Is it okay for gpio_to_irq to return NO_IRQ?  (returned by
irq_of_parse_and_map) if irq is not defined?


Henk.

diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 6eea601..81927d7 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -150,6 +150,17 @@ int of_gpio_simple_xlate(struct of_gpio_chip
*of_gc, struct device_node *np,
 }
 EXPORT_SYMBOL(of_gpio_simple_xlate);

+static int of_mm_gpio_to_irq(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc;
+   struct of_gpio_chip *of_gc;
+
+   of_gc = container_of(gc, struct of_gpio_chip, gc);  
+   mm_gc = container_of(of_gc, struct of_mm_gpio_chip, of_gc); 
+   return mm_gc->irq;  
+   
+}
+
 /**
  * of_mm_gpiochip_add - Add memory mapped GPIO chip (bank)
  * @np:device node of the GPIO chip
@@ -188,6 +199,9 @@ int of_mm_gpiochip_add(struct device_node *np,

gc->base = -1;

+   mm_gc->irq = irq_of_parse_and_map(np, 0);
+   gc->to_irq = of_mm_gpio_to_irq;
+
if (!of_gc->xlate)
of_gc->xlate = of_gpio_simple_xlate;

diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index fc2472c..17fe9ed 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -54,6 +54,7 @@ struct of_mm_gpio_chip {
struct of_gpio_chip of_gc;
void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
void __iomem *regs;
+   int irq;
 };

 static inline struct of_mm_gpio_chip *to_of_mm_gpio_chip(struct gpio_chip *gc)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Powerpc] Next March 5 build failure: platform/pseries/msi.o

[Michael Ellerman]

On Thu, 2009-03-05 at 17:06 +0530, Sachin P. Sant wrote:
> Next March 5th randconfig build fails with
> 
> arch/powerpc/platforms/pseries/msi.c: In function find_pe_dn:
> arch/powerpc/platforms/pseries/msi.c:210: error: implicit declaration of 
> function find_device_pe
> 
> CONFIG_EEH is not set in the config.
> 
> Attached here is the .config.

Dang it, that's my fault. Thanks for catching it Sachin.

I assumed pseries always enabled EEH, but I see now you can disable it
if you have EMBEDDED set (which your config does).

It's a bit yucky making the MSI code depend on EEH, but the only other
option would be to pull half the EEH code out - so I guess that's what
I'll do.

Does this patch fix it?

cheers


diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pse
index ddc2a30..dbb5109 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -25,6 +25,11 @@ config EEH
depends on PPC_PSERIES && PCI
default y if !EMBEDDED
 
+config PSERIES_MSI
+   bool
+   depends on PCI_MSI && EEH
+   default y
+
 config SCANLOG
tristate "Scanlog dump interface"
depends on RTAS_PROC && PPC_PSERIES
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/ps
index dfe574a..0ce691d 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_SCANLOG) += scanlog.o
 obj-$(CONFIG_EEH)  += eeh.o eeh_cache.o eeh_driver.o eeh_event.o eeh_sysfs.
 obj-$(CONFIG_KEXEC)+= kexec.o
 obj-$(CONFIG_PCI)  += pci.o pci_dlpar.o
-obj-$(CONFIG_PCI_MSI)  += msi.o
+obj-$(CONFIG_PSERIES_MSI)  += msi.o
 
 obj-$(CONFIG_HOTPLUG_CPU)  += hotplug-cpu.o
 obj-$(CONFIG_MEMORY_HOTPLUG)   += hotplug-memory.o



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc/cell: Only build Axon MSI driver for IBM Cell Blades

[Michael Ellerman]

On Thu, 2009-03-05 at 01:13 -0600, Olof Johansson wrote:
> On Thu, Mar 05, 2009 at 03:41:41PM +1100, Michael Ellerman wrote:
> > The hardware is only present on those machines, and the driver
> > depends on infrastructure which is selected by the Kconfig for
> > cell blades.
> 
> Wouldn't it make more sense to make a separate (AXON_MSI) config option
> depend on PPC_IBM_CELL_BLADE?

Maybe, it would make the makefile cleaner, at the expense of a bit more
Kconfig. I'm not sure what people prefer, I guess I'm neutral and you're
voting for the latter, so I'll respin it that way :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

On Thu, Mar 5, 2009 at 12:41 AM, Michael Guntsche  wrote:
> On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely 
> wrote:
>> You might be able to use of_attach_node() & prom_add_property() to
>> modify the tree, but I've never done it myself.  Give it a try and
>> tell me if it works.  :-)
>>
>
> Hello Grant,
>
> I made some progress in this area, but I have now hit a problem I do not
> know how to solve.
> Taking code from the iseries/vio.c files I am able to add properties with
> add_string_property and add_raw_property.
> The problem I have is adding properties like
>
>    reg = <0x2520 0x20>
>
> I know how to add a property
>
>   reg = <0x2520>
>
> but I do not know what data structure to pass to add_raw_property to add
> two numbers there.

Device tree properties are just "bags of bytes".  'cells' in device
tree nomenclature are big endian u32 values.  So, for specifying a
property with one cell (ie: reg = <0x2520>;), the data length is 4
bytes and the data is an array of 4 bytes: 0x00 0x00 0x25 0x20.  To
add a property with two cells (ie: reg = <0x2520 0x20>;), the data
length is 8 bytes and the data is and array of 8 bytes: 0x00 0x00 0x25
0x20 0x00 0x00 0x00 0x20.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Geert Uytterhoeven]

On Thu, 5 Mar 2009, Jens Axboe wrote:
> On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > On Thu, 5 Mar 2009, Jens Axboe wrote:
> > > On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > > > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain 
> > > > block
> > > > device, as requested by Arnd Bergmann.

> > > I'd rewrite this as a ->make_request_fn handler instead. Then you can
> > > get rid of the kernel thread. IOW, change
> > >
> > > queue = blk_init_queue(ps3vram_request, &priv->lock);
> > >
> > > to
> > >
> > > queue = blk_alloc_queue(GFP_KERNEL);
> > > blk_queue_make_request(queue, ps3vram_make_request);
> > 
> > Thanks, I didn't know that part...
> > 
> > > Add error handling of course, and call blk_queue_max_*() to set your
> > > limits for this device.
> > 
> > I took out the blk_queue_max_*() calls (compared to ps3disk.c), as
> > none of the limits apply, and the defaults are fine.
> > 
> > Is that OK, or is it better to make it explicit?
> 
> I think it's always good to make it explicit. Plus for this case you
> definitely need it, as blk_init_queue() wont do it for you anymore.

blk_queue_make_request() does it for me, too:

void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn)
{
...
blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
...
blk_queue_max_segment_size(q, MAX_SEGMENT_SIZE);
...
blk_queue_max_sectors(q, SAFE_MAX_SECTORS);
...
}

struct request_queue *
blk_init_queue_node(request_fn_proc *rfn, spinlock_t *lock, int node_id)
{
...
blk_queue_max_segment_size(q, MAX_SEGMENT_SIZE);

blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
...
}

> > > Then add a ps3vram_make_request() ala:
> > 
> > > static void ps3vram_do_request(struct request_queue *q, struct bio *bio)
> > > {

> > > }
> > >
> > > I just typed it here, so if it doesn't compile you get to keep the
> > > pieces :-)
> > 
> > OK, I'll give it a try...
> > 
> > BTW, does this mean the `simple' way, which I used based on LDD3, is
> > deprecated?
> 
> Depends.. It's obviously not a very effective approach, since you punt
> to a thread for each request. But if you need the IO scheduler helping
> you with merging and sorting (for a rotational device), it still has
> some merit. For this particular case, the ->make_request_fn approach is
> much better.

Without the thread, performance indeed increased.

But then I noticed ps3vram_make_request() may be called concurrently, so I had
to add a mutex to avoid data corruption. This slows the driver down, and in the
end, the version with a thread turns out to be ca. 1% faster. The version
without a thread is about 50 lines less code, though.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Powerpc] Next March 5 build failure: platform/pseries/msi.o

[Sachin P. Sant]

Michael Ellerman wrote:

Dang it, that's my fault. Thanks for catching it Sachin.

I assumed pseries always enabled EEH, but I see now you can disable it
if you have EMBEDDED set (which your config does).

It's a bit yucky making the MSI code depend on EEH, but the only other
option would be to pull half the EEH code out - so I guess that's what
I'll do.

Does this patch fix it?

Thanks for the patch Michael. It fixes the build break.

Regards
-Sachin

--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Olaf Hering]

On Thu, Mar 05, Geert Uytterhoeven wrote:

> On Thu, 5 Mar 2009, Geert Uytterhoeven wrote:
> > On Thu, 5 Mar 2009, Olaf Hering wrote:
> > > I see our old mtddriver does not have modalias support for autoloading.
> > 
> > You forgot to backport commit 0a2d15b928e0b1673d4ed5f48d95af211b6fcc06
> > ("mtd/ps3vram: Add modalias support to the ps3vram driver") to the openSuSE
> > tree?
> 
> Or do you mean that udev doesn't load mtdblock automatically?

I have not tried current kernels.
Our older versions of mtd based ps3vram do not have the autoloading feature.

So, please merge the block based ps3vram.ko.

Thanks for pushing it into mainline.

Olaf
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc/pseries failed reconfig notifier chain call cleanup

[Nathan Fontenot]

The return code from invoking the notifier chain when updating the
ibm,dynamic-memory property is not handled properly. In failure
cases (rc == NOTIFY_BAD) we should be restoring the original value
of the property.  In success (rc == NOTIFY_OK) we should be returning
zero from the calling routine.

Signed-off-by: Nathan Fontenot 
---
arch/powerpc/platforms/pseries/reconfig.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/powerpc/platforms/pseries/reconfig.c
===
--- linux-2.6.orig/arch/powerpc/platforms/pseries/reconfig.c2008-10-23 
22:29:24.0 -0500
+++ linux-2.6/arch/powerpc/platforms/pseries/reconfig.c 2009-03-05 
13:20:00.0 -0600
@@ -468,9 +468,13 @@

rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
  action, value);
+   if (rc == NOTIFY_BAD) {
+   rc = prom_update_property(np, oldprop, newprop);
+   return -ENOMEM;
+   }
}

-   return rc;
+   return 0;
}

/**
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc/cell: Only build Axon MSI driver for IBM Cell Blades

[Olof Johansson]

On Fri, Mar 06, 2009 at 01:07:05AM +1100, Michael Ellerman wrote:
> On Thu, 2009-03-05 at 01:13 -0600, Olof Johansson wrote:
> > On Thu, Mar 05, 2009 at 03:41:41PM +1100, Michael Ellerman wrote:
> > > The hardware is only present on those machines, and the driver
> > > depends on infrastructure which is selected by the Kconfig for
> > > cell blades.
> > 
> > Wouldn't it make more sense to make a separate (AXON_MSI) config option
> > depend on PPC_IBM_CELL_BLADE?
> 
> Maybe, it would make the makefile cleaner, at the expense of a bit more
> Kconfig. I'm not sure what people prefer, I guess I'm neutral and you're
> voting for the latter, so I'll respin it that way :)

Yeah, I'm not really that picky either, it just set off a red flag
w.r.t. setting a bad precedence on ifdef:ing in the makefile instead of
Kconfig engineering. Slippery slope and all that.


-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2 0/11] FSL eSDHC support

[Anton Vorontsov]

Hi all,

Much thanks for the previous comments. Here comes v2.

Changes since v1:
- "Add support for bus-specific IO memory accessors" patch no longer
  touches sdhci-pci. The changes were no longer needed since I dropped
  "Add type checking ..." patch back in RFCv2;
- Patch "Add support for hosts with strict 32 bit addressing" dropped.
  Now we handle the 32 bit magic in eSDHC's writew() accessor;
- Patch "Add quirk for controllers with max. block size up to 4096 bytes"
  replaced by "Add quirk for forcing maximum block size to 2048 bytes";
- SDHCI_INT_ALL_MASK changed to (unsigned int)-1;
- Addressed Pierre's comments in "Add support for card-detection polling"
  patch.

Changes since the third RFC:
- Use uninitialized_var() (suggested by Laurent Pinchart);
- Fixed a bug in eSDHC SDCLK prescaler calculations because of which
  we were over-clocking the SDCLK, and that caused CRC errors using some
  SD cards;
- Not a change, but some status: SDHS (50 MHz) cards were tested to
  NOT work (at least on MPC837x boards) -- this is to be investigated
  further. SDHC (> 4 GB) cards were not tested, yet.

Changes since the second RFC:
- Addressed all comments that were raised by Pierre Ossman.
  There were too many to mention them all, so here is the link:
  http://lkml.org/lkml/2009/2/6/320

Changes since the first RFC:
- Use of_iomap() in sdhci-of.c (suggested by Arnd Bergmann). Also added
  Arnd's Acked-by: line for the sdhci-of patch.
- Kconfig help text improved (thanks to Matt Sealey and M. Warner Losh).
- In "sdhci: Add quirk to suppress PIO interrupts during DMA transfers"
  patch: sdhci_init() now clears SDHCI_PIO_DISABLED flag, otherwise we
  won't disable PIO interrupts after suspend.
- New patch: "sdhci: Add type checking for IO memory accessors"

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 01/11] sdhci: Add support for bus-specific IO memory accessors

[Anton Vorontsov]

Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).

With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.

For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endian addressing. That is, readb(0x2f) should turn
into readb(0x2c), and readw(0x2c) should be translated to
le16_to_cpu(readw(0x2e)).

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |  214 -
 drivers/mmc/host/sdhci.h |   14 +++
 2 files changed, 147 insertions(+), 81 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index accb592..9887820 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -48,35 +49,35 @@ static void sdhci_dumpregs(struct sdhci_host *host)
printk(KERN_DEBUG DRIVER_NAME ": == REGISTER DUMP 
==\n");
 
printk(KERN_DEBUG DRIVER_NAME ": Sys addr: 0x%08x | Version:  0x%08x\n",
-   readl(host->ioaddr + SDHCI_DMA_ADDRESS),
-   readw(host->ioaddr + SDHCI_HOST_VERSION));
+   sdhci_readl(host, SDHCI_DMA_ADDRESS),
+   sdhci_readw(host, SDHCI_HOST_VERSION));
printk(KERN_DEBUG DRIVER_NAME ": Blk size: 0x%08x | Blk cnt:  0x%08x\n",
-   readw(host->ioaddr + SDHCI_BLOCK_SIZE),
-   readw(host->ioaddr + SDHCI_BLOCK_COUNT));
+   sdhci_readw(host, SDHCI_BLOCK_SIZE),
+   sdhci_readw(host, SDHCI_BLOCK_COUNT));
printk(KERN_DEBUG DRIVER_NAME ": Argument: 0x%08x | Trn mode: 0x%08x\n",
-   readl(host->ioaddr + SDHCI_ARGUMENT),
-   readw(host->ioaddr + SDHCI_TRANSFER_MODE));
+   sdhci_readl(host, SDHCI_ARGUMENT),
+   sdhci_readw(host, SDHCI_TRANSFER_MODE));
printk(KERN_DEBUG DRIVER_NAME ": Present:  0x%08x | Host ctl: 0x%08x\n",
-   readl(host->ioaddr + SDHCI_PRESENT_STATE),
-   readb(host->ioaddr + SDHCI_HOST_CONTROL));
+   sdhci_readl(host, SDHCI_PRESENT_STATE),
+   sdhci_readb(host, SDHCI_HOST_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Power:0x%08x | Blk gap:  0x%08x\n",
-   readb(host->ioaddr + SDHCI_POWER_CONTROL),
-   readb(host->ioaddr + SDHCI_BLOCK_GAP_CONTROL));
+   sdhci_readb(host, SDHCI_POWER_CONTROL),
+   sdhci_readb(host, SDHCI_BLOCK_GAP_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Wake-up:  0x%08x | Clock:0x%08x\n",
-   readb(host->ioaddr + SDHCI_WAKE_UP_CONTROL),
-   readw(host->ioaddr + SDHCI_CLOCK_CONTROL));
+   sdhci_readb(host, SDHCI_WAKE_UP_CONTROL),
+   sdhci_readw(host, SDHCI_CLOCK_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Timeout:  0x%08x | Int stat: 0x%08x\n",
-   readb(host->ioaddr + SDHCI_TIMEOUT_CONTROL),
-   readl(host->ioaddr + SDHCI_INT_STATUS));
+   sdhci_readb(host, SDHCI_TIMEOUT_CONTROL),
+   sdhci_readl(host, SDHCI_INT_STATUS));
printk(KERN_DEBUG DRIVER_NAME ": Int enab: 0x%08x | Sig enab: 0x%08x\n",
-   readl(host->ioaddr + SDHCI_INT_ENABLE),
-   readl(host->ioaddr + SDHCI_SIGNAL_ENABLE));
+   sdhci_readl(host, SDHCI_INT_ENABLE),
+   sdhci_readl(host, SDHCI_SIGNAL_ENABLE));
printk(KERN_DEBUG DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
-   readw(host->ioaddr + SDHCI_ACMD12_ERR),
-   readw(host->ioaddr + SDHCI_SLOT_INT_STATUS));
+   sdhci_readw(host, SDHCI_ACMD12_ERR),
+   sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
printk(KERN_DEBUG DRIVER_NAME ": Caps: 0x%08x | Max curr: 0x%08x\n",
-   readl(host->ioaddr + SDHCI_CAPABILITIES),
-   readl(host->ioaddr + SDHCI_MAX_CURRENT));
+   sdhci_readl(host, SDHCI_CAPABILITIES),
+   sdhci_readl(host, SDHCI_MAX_CURRENT));
 
printk(KERN_DEBUG DRIVER_NAME ": 
===\n");
 }
@@ -87,17 +88,71 @@ static void sdhci_dumpregs(struct sdhci_host *host)
  *   *
 \*/
 
+void sdhci_writel(struct sdhci_host *host, u32 val, int reg)
+{
+   if (unlikely(host->ops->writel))
+   host->ops->writel(host, val, reg);
+   else
+   writel(val, host->ioaddr + reg);
+}
+EXPORT_SYMBOL_GPL(sdhci_writel);
+
+void sdhci_writew(struct sdhci_host *host, u16 val, int reg)
+{
+   if (unlikely(host->ops->writew))
+   host->ops->writew(host, val, reg);
+   else
+   writew(val, host->ioaddr + reg);
+}
+EXPORT_SYMBOL_GPL(sdhci_writew);
+
+void sdhci_write

[PATCH 02/11] sdhci: Split card-detection IRQs management from sdhci_init()

[Anton Vorontsov]

Card detection interrupts should be handled separately as they should
not be enabled before mmc_add_host() returns and should be disabled
before calling mmc_remove_host(). The same is for suspend and resume
routines.

sdhci_init() no longer enables card-detection irqs. Instead, two new
functions implemented: sdhci_enable_card_detection() and
sdhci_disable_card_detection().

New sdhci_reinit() call implemented to behave the same way as the old
sdhci_init().

Also, this patch implements and uses few new helpers to manage IRQs in
a more conveinient way, that is:

- sdhci_clear_set_irqs()
- sdhci_unmask_irqs()
- sdhci_mask_irqs()
- SDHCI_INT_ALL_MASK constant

sdhci_enable_sdio_irq() converted to these new helpers, plus the
helpers will be used by the subsequent patches.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |   78 --
 drivers/mmc/host/sdhci.h |1 +
 2 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9887820..ba9f95f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -142,6 +142,47 @@ u8 sdhci_readb(struct sdhci_host *host, int reg)
 }
 EXPORT_SYMBOL_GPL(sdhci_readb);
 
+static void sdhci_clear_set_irqs(struct sdhci_host *host, u32 clear, u32 set)
+{
+   u32 ier;
+
+   ier = sdhci_readl(host, SDHCI_INT_ENABLE);
+   ier &= ~clear;
+   ier |= set;
+   sdhci_writel(host, ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_unmask_irqs(struct sdhci_host *host, u32 irqs)
+{
+   sdhci_clear_set_irqs(host, 0, irqs);
+}
+
+static void sdhci_mask_irqs(struct sdhci_host *host, u32 irqs)
+{
+   sdhci_clear_set_irqs(host, irqs, 0);
+}
+
+static void sdhci_set_card_detection(struct sdhci_host *host, bool enable)
+{
+   u32 irqs = SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT;
+
+   if (enable)
+   sdhci_unmask_irqs(host, irqs);
+   else
+   sdhci_mask_irqs(host, irqs);
+}
+
+static void sdhci_enable_card_detection(struct sdhci_host *host)
+{
+   sdhci_set_card_detection(host, true);
+}
+
+static void sdhci_disable_card_detection(struct sdhci_host *host)
+{
+   sdhci_set_card_detection(host, false);
+}
+
 static void sdhci_reset(struct sdhci_host *host, u8 mask)
 {
unsigned long timeout;
@@ -175,20 +216,21 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
 
 static void sdhci_init(struct sdhci_host *host)
 {
-   u32 intmask;
-
sdhci_reset(host, SDHCI_RESET_ALL);
 
-   intmask = SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
+   sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK,
+   SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_INDEX |
SDHCI_INT_END_BIT | SDHCI_INT_CRC | SDHCI_INT_TIMEOUT |
-   SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT |
SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL |
SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE |
-   SDHCI_INT_ADMA_ERROR;
+   SDHCI_INT_ADMA_ERROR);
+}
 
-   sdhci_writel(host, intmask, SDHCI_INT_ENABLE);
-   sdhci_writel(host, intmask, SDHCI_SIGNAL_ENABLE);
+static void sdhci_reinit(struct sdhci_host *host)
+{
+   sdhci_init(host);
+   sdhci_enable_card_detection(host);
 }
 
 static void sdhci_activate_led(struct sdhci_host *host)
@@ -1087,7 +1129,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
 */
if (ios->power_mode == MMC_POWER_OFF) {
sdhci_writel(host, 0, SDHCI_SIGNAL_ENABLE);
-   sdhci_init(host);
+   sdhci_reinit(host);
}
 
sdhci_set_clock(host, ios->clock);
@@ -1148,7 +1190,6 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 {
struct sdhci_host *host;
unsigned long flags;
-   u32 ier;
 
host = mmc_priv(mmc);
 
@@ -1157,15 +1198,10 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
if (host->flags & SDHCI_DEVICE_DEAD)
goto out;
 
-   ier = sdhci_readl(host, SDHCI_INT_ENABLE);
-
-   ier &= ~SDHCI_INT_CARD_INT;
if (enable)
-   ier |= SDHCI_INT_CARD_INT;
-
-   sdhci_writel(host, ier, SDHCI_INT_ENABLE);
-   sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
-
+   sdhci_unmask_irqs(host, SDHCI_INT_CARD_INT);
+   else
+   sdhci_mask_irqs(host, SDHCI_INT_CARD_INT);
 out:
mmiowb();
 
@@ -1507,6 +1543,8 @@ int sdhci_suspend_host(struct sdhci_host *host, 
pm_message_t state)
 {
int ret;
 
+   sdhci_disable_card_detection(host);
+
ret = mmc_suspend_host(host->mmc, state);
if (ret)
return ret;
@@ -1539,6 +1577,8 @@ int sdhci_resume_host(struct sdhci_host *host)
if (ret)
 

[PATCH 03/11] sdhci: Enable only relevant (DMA/PIO) interrupts during transfers

[Anton Vorontsov]

Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.

This patch modifies the driver so that now we only enable relevant
(DMA or PIO) interrupts during transfers.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |   17 ++---
 1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ba9f95f..0cbde8e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -222,9 +222,7 @@ static void sdhci_init(struct sdhci_host *host)
SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_INDEX |
SDHCI_INT_END_BIT | SDHCI_INT_CRC | SDHCI_INT_TIMEOUT |
-   SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL |
-   SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE |
-   SDHCI_INT_ADMA_ERROR);
+   SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE);
 }
 
 static void sdhci_reinit(struct sdhci_host *host)
@@ -658,6 +656,17 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, 
struct mmc_data *data)
return count;
 }
 
+static void sdhci_set_transfer_irqs(struct sdhci_host *host)
+{
+   u32 pio_irqs = SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL;
+   u32 dma_irqs = SDHCI_INT_DMA_END | SDHCI_INT_ADMA_ERROR;
+
+   if (host->flags & SDHCI_REQ_USE_DMA)
+   sdhci_clear_set_irqs(host, pio_irqs, dma_irqs);
+   else
+   sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
+}
+
 static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
 {
u8 count;
@@ -806,6 +815,8 @@ static void sdhci_prepare_data(struct sdhci_host *host, 
struct mmc_data *data)
host->blocks = data->blocks;
}
 
+   sdhci_set_transfer_irqs(host);
+
/* We do not handle DMA boundaries, so set it to max (512 KiB) */
sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data->blksz), SDHCI_BLOCK_SIZE);
sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 04/11] sdhci: Add support for card-detection polling

[Anton Vorontsov]

This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.

This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to "debounce" card-detection
IRQs by reading present state and disabling particular interrupts. But
with this debouncing scheme I noticed that sometimes we miss card
insertion/removal events.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |   17 +++--
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0cbde8e..d71c877 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -167,6 +167,9 @@ static void sdhci_set_card_detection(struct sdhci_host 
*host, bool enable)
 {
u32 irqs = SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT;
 
+   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+   return;
+
if (enable)
sdhci_unmask_irqs(host, irqs);
else
@@ -1096,6 +1099,7 @@ out:
 static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
struct sdhci_host *host;
+   bool present;
unsigned long flags;
 
host = mmc_priv(mmc);
@@ -1110,8 +1114,14 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
host->mrq = mrq;
 
-   if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT)
-   || (host->flags & SDHCI_DEVICE_DEAD)) {
+   /* If polling, assume that the card is always present. */
+   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+   present = true;
+   else
+   present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
+   SDHCI_CARD_PRESENT;
+
+   if (!present || host->flags & SDHCI_DEVICE_DEAD) {
host->mrq->cmd->error = -ENOMEDIUM;
tasklet_schedule(&host->finish_tasklet);
} else
@@ -1745,6 +1755,9 @@ int sdhci_add_host(struct sdhci_host *host)
if (caps & SDHCI_CAN_DO_HISPD)
mmc->caps |= MMC_CAP_SD_HIGHSPEED;
 
+   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+   mmc->caps |= MMC_CAP_NEEDS_POLL;
+
mmc->ocr_avail = 0;
if (caps & SDHCI_CAN_VDD_330)
mmc->ocr_avail |= MMC_VDD_32_33|MMC_VDD_33_34;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 1c29895..09a4363 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -212,6 +212,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_BROKEN_SMALL_PIO   (1<<13)
 /* Controller does not provide transfer-complete interrupt when not busy */
 #define SDHCI_QUIRK_NO_BUSY_IRQ(1<<14)
+/* Controller has unreliable card detection */
+#define SDHCI_QUIRK_BROKEN_CARD_DETECTION  (1<<15)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 05/11] sdhci: Add support for hosts reporting inverted write-protect state

[Anton Vorontsov]

This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.

p.s. Actually, the quirk is more board-specific than
 controller-specific.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |2 ++
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d71c877..8aaf3a5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1204,6 +1204,8 @@ static int sdhci_get_ro(struct mmc_host *mmc)
 
spin_unlock_irqrestore(&host->lock, flags);
 
+   if (host->quirks & SDHCI_QUIRK_INVERTED_WRITE_PROTECT)
+   return !!(present & SDHCI_WRITE_PROTECT);
return !(present & SDHCI_WRITE_PROTECT);
 }
 
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 09a4363..d0d812e 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -214,6 +214,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_NO_BUSY_IRQ(1<<14)
 /* Controller has unreliable card detection */
 #define SDHCI_QUIRK_BROKEN_CARD_DETECTION  (1<<15)
+/* Controller reports inverted write-protect state */
+#define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<16)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 06/11] sdhci: Add get_{max,timeout}_clock callbacks

[Anton Vorontsov]

From: Ben Dooks 

Some controllers do not provide clock information in their capabilities
(in the Samsung case, it is because there are multiple clock sources
available to the controller). Add hooks to allow the system to supply
clock information.

p.s.
In the original Ben's patch there was a bug that makes sdhci_add_host()
return -ENODEV even if callbacks were specified. This is fixed now.

Signed-off-by: Ben Dooks 
Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |   22 +++---
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8aaf3a5..cca80d3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1729,19 +1729,27 @@ int sdhci_add_host(struct sdhci_host *host)
 
host->max_clk =
(caps & SDHCI_CLOCK_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
+   host->max_clk *= 100;
if (host->max_clk == 0) {
-   printk(KERN_ERR "%s: Hardware doesn't specify base clock "
-   "frequency.\n", mmc_hostname(mmc));
-   return -ENODEV;
+   if (!host->ops->get_max_clock) {
+   printk(KERN_ERR
+  "%s: Hardware doesn't specify base clock "
+  "frequency.\n", mmc_hostname(mmc));
+   return -ENODEV;
+   }
+   host->max_clk = host->ops->get_max_clock(host);
}
-   host->max_clk *= 100;
 
host->timeout_clk =
(caps & SDHCI_TIMEOUT_CLK_MASK) >> SDHCI_TIMEOUT_CLK_SHIFT;
if (host->timeout_clk == 0) {
-   printk(KERN_ERR "%s: Hardware doesn't specify timeout clock "
-   "frequency.\n", mmc_hostname(mmc));
-   return -ENODEV;
+   if (!host->ops->get_timeout_clock) {
+   printk(KERN_ERR
+  "%s: Hardware doesn't specify timeout clock "
+  "frequency.\n", mmc_hostname(mmc));
+   return -ENODEV;
+   }
+   host->timeout_clk = host->ops->get_timeout_clock(host);
}
if (caps & SDHCI_TIMEOUT_CLK_UNIT)
host->timeout_clk *= 1000;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d0d812e..34f1849 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -281,6 +281,8 @@ struct sdhci_ops {
void(*writeb)(struct sdhci_host *host, u8 val, int reg);
 
int (*enable_dma)(struct sdhci_host *host);
+   unsigned int(*get_max_clock)(struct sdhci_host *host);
+   unsigned int(*get_timeout_clock)(struct sdhci_host *host);
 };
 
 extern void sdhci_writel(struct sdhci_host *host, u32 val, int reg);
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 07/11] sdhci: Add set_clock callback and a quirk for nonstandard clocks

[Anton Vorontsov]

FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.

Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
that makes the patch difficult to reuse.

[1] http://lkml.org/lkml/2008/12/2/160

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |6 ++
 drivers/mmc/host/sdhci.h |4 
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index cca80d3..a476616 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1004,6 +1004,12 @@ static void sdhci_set_clock(struct sdhci_host *host, 
unsigned int clock)
if (clock == host->clock)
return;
 
+   if (host->ops->set_clock) {
+   host->ops->set_clock(host, clock);
+   if (host->quirks & SDHCI_QUIRK_NONSTANDARD_CLOCK)
+   return;
+   }
+
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
 
if (clock == 0)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 34f1849..18a334a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -216,6 +216,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_BROKEN_CARD_DETECTION  (1<<15)
 /* Controller reports inverted write-protect state */
 #define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<16)
+/* Controller has nonstandard clock management */
+#define SDHCI_QUIRK_NONSTANDARD_CLOCK  (1<<17)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
@@ -280,6 +282,8 @@ struct sdhci_ops {
void(*writew)(struct sdhci_host *host, u16 val, int reg);
void(*writeb)(struct sdhci_host *host, u8 val, int reg);
 
+   void(*set_clock)(struct sdhci_host *host, unsigned int clock);
+
int (*enable_dma)(struct sdhci_host *host);
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 08/11] sdhci: Add quirk for controllers that need small delays for PIO

[Anton Vorontsov]

Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |3 +++
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a476616..4382f53 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -391,6 +391,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host)
mask = ~0;
 
while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
+   if (host->quirks & SDHCI_QUIRK_PIO_NEEDS_DELAY)
+   udelay(100);
+
if (host->data->flags & MMC_DATA_READ)
sdhci_read_block_pio(host);
else
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 18a334a..8c41667 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -218,6 +218,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<16)
 /* Controller has nonstandard clock management */
 #define SDHCI_QUIRK_NONSTANDARD_CLOCK  (1<<17)
+/* Controller does not like fast PIO transfers */
+#define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<18)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 09/11] sdhci: Add quirk for controllers that need IRQ re-init after reset

[Anton Vorontsov]

FSL eSDHC controllers losing signal/interrupt enable states after
reset, so we should re-enable them.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |7 +++
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4382f53..f012e7e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -189,6 +189,7 @@ static void sdhci_disable_card_detection(struct sdhci_host 
*host)
 static void sdhci_reset(struct sdhci_host *host, u8 mask)
 {
unsigned long timeout;
+   u32 uninitialized_var(ier);
 
if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
@@ -196,6 +197,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
return;
}
 
+   if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
+   ier = sdhci_readl(host, SDHCI_INT_ENABLE);
+
sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
 
if (mask & SDHCI_RESET_ALL)
@@ -215,6 +219,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
timeout--;
mdelay(1);
}
+
+   if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
+   sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
 }
 
 static void sdhci_init(struct sdhci_host *host)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 8c41667..35c78bc 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -220,6 +220,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_NONSTANDARD_CLOCK  (1<<17)
 /* Controller does not like fast PIO transfers */
 #define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<18)
+/* Controller losing signal/interrupt enable states after reset */
+#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET   (1<<19)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 10/11] sdhci: Add quirk for forcing maximum block size to 2048 bytes

[Anton Vorontsov]

FSL eSDHC controllers can support maximum block size up to 4096 bytes,
the MBL (Maximum Block Length) field in the capabilities register
extended by one bit, and is set to 0x3.

But the SDHCI core doesn't support blocks of 4096 bytes, and thus
forces blksz to the lowest value -- 512 bytes. With this patch we can
pin up the blksz to the maximum supported block size, i.e. 2048 bytes.

Signed-off-by: Anton Vorontsov 
---
 drivers/mmc/host/sdhci.c |   20 +---
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f012e7e..284bc5d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1832,13 +1832,19 @@ int sdhci_add_host(struct sdhci_host *host)
 * Maximum block size. This varies from controller to controller and
 * is specified in the capabilities register.
 */
-   mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >> 
SDHCI_MAX_BLOCK_SHIFT;
-   if (mmc->max_blk_size >= 3) {
-   printk(KERN_WARNING "%s: Invalid maximum block size, "
-   "assuming 512 bytes\n", mmc_hostname(mmc));
-   mmc->max_blk_size = 512;
-   } else
-   mmc->max_blk_size = 512 << mmc->max_blk_size;
+   if (host->quirks & SDHCI_QUIRK_FORCE_BLK_SZ_2048) {
+   mmc->max_blk_size = 2;
+   } else {
+   mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >>
+   SDHCI_MAX_BLOCK_SHIFT;
+   if (mmc->max_blk_size >= 3) {
+   printk(KERN_WARNING "%s: Invalid maximum block size, "
+   "assuming 512 bytes\n", mmc_hostname(mmc));
+   mmc->max_blk_size = 0;
+   }
+   }
+
+   mmc->max_blk_size = 512 << mmc->max_blk_size;
 
/*
 * Maximum block count.
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 35c78bc..1697e01 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -222,6 +222,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<18)
 /* Controller losing signal/interrupt enable states after reset */
 #define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET   (1<<19)
+/* Controller has to be forced to use block size of 2048 bytes */
+#define SDHCI_QUIRK_FORCE_BLK_SZ_2048  (1<<20)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver

[Anton Vorontsov]

This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.

So far there are only Freescale eSDHC ops and quirks.

Signed-off-by: Anton Vorontsov 
Acked-by: Arnd Bergmann 
---
 drivers/mmc/host/Kconfig|   10 ++
 drivers/mmc/host/Makefile   |1 +
 drivers/mmc/host/sdhci-of.c |  309 +++
 3 files changed, 320 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-of.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 99d4b28..73b79e1 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -65,6 +65,16 @@ config MMC_RICOH_MMC
 
  If unsure, say Y.
 
+config MMC_SDHCI_OF
+   tristate "SDHCI support on OpenFirmware platforms"
+   depends on MMC_SDHCI && PPC_OF
+   help
+ This selects the OF support for Secure Digital Host Controller
+ Interfaces. So far, only the Freescale eSDHC controller is known
+ to exist on OF platforms.
+
+ If unsure, say N.
+
 config MMC_OMAP
tristate "TI OMAP Multimedia Card Interface support"
depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index dedec55..dd512d9 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
 obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o
 obj-$(CONFIG_MMC_RICOH_MMC)+= ricoh_mmc.o
+obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
 obj-$(CONFIG_MMC_WBSD) += wbsd.o
 obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
 obj-$(CONFIG_MMC_OMAP) += omap.o
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
new file mode 100644
index 000..3ff4ac3
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of.c
@@ -0,0 +1,309 @@
+/*
+ * OpenFirmware bindings for Secure Digital Host Controller Interface.
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ *
+ * Authors: Xiaobo Xie 
+ * Anton Vorontsov 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sdhci.h"
+
+struct sdhci_of_data {
+   unsigned int quirks;
+   struct sdhci_ops ops;
+};
+
+struct sdhci_of_host {
+   unsigned int clock;
+   u16 xfer_mode_shadow;
+};
+
+/*
+ * Ops and quirks for the Freescale eSDHC controller.
+ */
+
+#define ESDHC_DMA_SYSCTL   0x40c
+#define ESDHC_DMA_SNOOP0x0040
+
+#define ESDHC_SYSTEM_CONTROL   0x2c
+#define ESDHC_CLOCK_MASK   0xfff0
+#define ESDHC_PREDIV_SHIFT 8
+#define ESDHC_DIVIDER_SHIFT4
+#define ESDHC_CLOCK_PEREN  0x0004
+#define ESDHC_CLOCK_HCKEN  0x0002
+#define ESDHC_CLOCK_IPGEN  0x0001
+
+static u32 esdhc_readl(struct sdhci_host *host, int reg)
+{
+   return in_be32(host->ioaddr + reg);
+}
+
+static u16 esdhc_readw(struct sdhci_host *host, int reg)
+{
+   return in_be16(host->ioaddr + (reg ^ 0x2));
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+   return in_8(host->ioaddr + (reg ^ 0x3));
+}
+
+static void esdhc_writel(struct sdhci_host *host, u32 val, int reg)
+{
+   out_be32(host->ioaddr + reg, val);
+}
+
+static void esdhc_writew(struct sdhci_host *host, u16 val, int reg)
+{
+   struct sdhci_of_host *of_host = sdhci_priv(host);
+   int base = reg & ~0x3;
+   int shift = (reg & 0x2) * 8;
+
+   switch (reg) {
+   case SDHCI_TRANSFER_MODE:
+   /*
+* Postpone this write, we must do it together with a
+* command write that is down below.
+*/
+   of_host->xfer_mode_shadow = val;
+   return;
+   case SDHCI_COMMAND:
+   esdhc_writel(host, val << 16 | of_host->xfer_mode_shadow,
+SDHCI_TRANSFER_MODE);
+   return;
+   case SDHCI_BLOCK_SIZE:
+   /*
+* Two last DMA bits are reserved, and first one is used for
+* non-standard blksz of 4096 bytes that we don't support
+* yet. So clear the DMA boundary bits.
+*/
+   val &= ~SDHCI_MAKE_BLKSZ(0x7, 0);
+   /* fall through */
+   }
+   clrsetbits_be32(host->ioaddr + base, 0x << shift, val << shift);
+}
+
+static void esdhc_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+   int base = reg & ~0x3;
+   int shift = (reg & 0x3) * 8;
+
+   clrsetbits_be32(host->ioaddr + base , 0xff << shift, val << shift);
+}
+
+static void esdhc_set_clock(s

[PATCH] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous

[Timur Tabi]

Add the definition of the fsl,ssi-asynchronous property to ssi.txt 
(documentation
of the device tree bindings for the Freescale SSI device).

Also tidy up the layout of ssi.txt.

Signed-off-by: Timur Tabi 
---
 Documentation/powerpc/dts-bindings/fsl/ssi.txt |   64 +--
 1 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt 
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index a2d9639..b8a5e12 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -4,44 +4,52 @@ The SSI is a serial device that communicates with audio 
codecs.  It can
 be programmed in AC97, I2S, left-justified, or right-justified modes.
 
 Required properties:
-- compatible : compatible list, containing "fsl,ssi"
-- cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
-- reg: offset and length of the register set for the device
-- interrupts :  where a is the interrupt number and b is a
- field that represents an encoding of the sense and
-   level information for the interrupt.  This should be
-   encoded based on the information in section 2)
-   depending on the type of interrupt controller you
-   have.
-- interrupt-parent : the phandle for the interrupt controller that
- services interrupts for this device.
-- fsl,mode   : the operating mode for the SSI interface
-   "i2s-slave" - I2S mode, SSI is clock slave
-   "i2s-master" - I2S mode, SSI is clock master
-   "lj-slave" - left-justified mode, SSI is clock slave
-   "lj-master" - l.j. mode, SSI is clock master
-   "rj-slave" - right-justified mode, SSI is clock slave
-   "rj-master" - r.j., SSI is clock master
-   "ac97-slave" - AC97 mode, SSI is clock slave
-   "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: phandle to a node for the DMA channel to use for
+- compatible:   Compatible list, contains "fsl,ssi".
+- cell-index:   The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg:  Offset and length of the register set for the device.
+- interrupts:where a is the interrupt number and b is a
+field that represents an encoding of the sense and
+level information for the interrupt.  This should be
+encoded based on the information in section 2)
+depending on the type of interrupt controller you
+have.
+- interrupt-parent: The phandle for the interrupt controller that
+services interrupts for this device.
+- fsl,mode: The operating mode for the SSI interface.
+"i2s-slave" - I2S mode, SSI is clock slave
+"i2s-master" - I2S mode, SSI is clock master
+"lj-slave" - left-justified mode, SSI is clock slave
+"lj-master" - l.j. mode, SSI is clock master
+"rj-slave" - right-justified mode, SSI is clock slave
+"rj-master" - r.j., SSI is clock master
+"ac97-slave" - AC97 mode, SSI is clock slave
+"ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
 playback of audio.  This is typically dictated by SOC
 design.  See the notes below.
-- fsl,capture-dma:  phandle to a node for the DMA channel to use for
+- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
 capture (recording) of audio.  This is typically dictated
 by SOC design.  See the notes below.
+- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
+This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+If specific, the SSI is to be programmed in asynchronous
+mode.  In this mode, SRCK and STCK must be connected to the
+same clock, and SRFS and STFS must also be connected to the
+same clock.  This allows playback and capture to use
+different sample sizes.
 
 Optional properties:
-- codec-handle   : phandle to a 'codec' node that defines an audio
-   codec connected to this SSI.  This node is typically
-   a child of an I2C or other control node.
+- codec-handle: Phandle to a 'codec' node that defines an audio
+codec connected to this SSI.  This node is typically
+a child of an I2C or other control node.
 
 Child 'codec' node required properties:
-- compatible : compatible list, contains the name of the codec
+- com

Re: [PATCH] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous

[Scott Wood]

Timur Tabi wrote:

+- fsl,ssi-asynchronous:
+If specific, the SSI is to be programmed in asynchronous
+mode.  In this mode, SRCK and STCK must be connected to the
+same clock, and SRFS and STFS must also be connected to the
+same clock.  This allows playback and capture to use
+different sample sizes.


s/specific/specified/

Does the above mean "SRCK, STCK, SRFS, and STFS must all be connected to 
the same clock", or does it mean "SRCK must be connected to the same 
clock as STCK, and SRFS must be connected to the same clock as STFS"?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc/pseries: Reject discontiguous/non-zero based MSI-X requests

[Michael Ellerman]

There's no way for us to express to firmware that we want a
discontiguous, or non-zero based, range of MSI-X entries. So we
must reject such requests.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/pseries/msi.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/msi.c 
b/arch/powerpc/platforms/pseries/msi.c
index 3e0d6ef..bf2e1ac 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -356,6 +356,27 @@ static int rtas_msi_check_device(struct pci_dev *pdev, int 
nvec, int type)
return 0;
 }
 
+static int check_msix_entries(struct pci_dev *pdev)
+{
+   struct msi_desc *entry;
+   int expected;
+
+   /* There's no way for us to express to firmware that we want
+* a discontiguous, or non-zero based, range of MSI-X entries.
+* So we must reject such requests. */
+
+   expected = 0;
+   list_for_each_entry(entry, &pdev->msi_list, list) {
+   if (entry->msi_attrib.entry_nr != expected) {
+   pr_debug("rtas_msi: bad MSI-X entries.\n");
+   return -EINVAL;
+   }
+   expected++;
+   }
+
+   return 0;
+}
+
 static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
 {
struct pci_dn *pdn;
@@ -367,6 +388,9 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int 
nvec, int type)
if (!pdn)
return -ENODEV;
 
+   if (type == PCI_CAP_ID_MSIX && check_msix_entries(pdev))
+   return -EINVAL;
+
/*
 * Try the new more explicit firmware interface, if that fails fall
 * back to the old interface. The old interface is known to never
-- 
1.6.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous

[Timur Tabi]

On Thu, Mar 5, 2009 at 5:34 PM, Scott Wood  wrote:

> Does the above mean "SRCK, STCK, SRFS, and STFS must all be connected to the
> same clock", or does it mean "SRCK must be connected to the same clock as
> STCK, and SRFS must be connected to the same clock as STFS"?

The latter.  I'll reword it.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] cpm_uart: fix non-console port startup bug

[Xiaotian Feng]

  After UART interrupt handler is installed and rx is enabled, if an rx
interrupt comes before hardware init, rx->cur will be updated. Then the
hardware init will reset BD and make rx->cur out of sync, move the hardware
init code before request_irq.

  Signed-off-by: Xiaotian Feng 
---
 drivers/serial/cpm_uart/cpm_uart_core.c |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c 
b/drivers/serial/cpm_uart/cpm_uart_core.c
index bde4b4b..5c6ef51 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -406,6 +406,18 @@ static int cpm_uart_startup(struct uart_port *port)
 
pr_debug("CPM uart[%d]:startup\n", port->line);
 
+   /* If the port is not the console, make sure rx is disabled. */
+   if (!(pinfo->flags & FLAG_CONSOLE)) {
+   /* Disable UART rx */
+   if (IS_SMC(pinfo)) {
+   clrbits16(&pinfo->smcp->smc_smcmr, SMCMR_REN);
+   clrbits8(&pinfo->smcp->smc_smcm, SMCM_RX);
+   } else {
+   clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR);
+   clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
+   }
+   cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
+   }
/* Install interrupt handler. */
retval = request_irq(port->irq, cpm_uart_int, 0, "cpm_uart", port);
if (retval)
@@ -420,8 +432,6 @@ static int cpm_uart_startup(struct uart_port *port)
setbits32(&pinfo->sccp->scc_gsmrl, (SCC_GSMRL_ENR | 
SCC_GSMRL_ENT));
}
 
-   if (!(pinfo->flags & FLAG_CONSOLE))
-   cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
return 0;
 }
 
-- 
1.5.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc/pseries: The pseries MSI code depends on EEH

[Michael Ellerman]

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/pseries/Kconfig  |5 +
 arch/powerpc/platforms/pseries/Makefile |2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/Kconfig 
b/arch/powerpc/platforms/pseries/Kconfig
index ddc2a30..095ff6f 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -25,6 +25,11 @@ config EEH
depends on PPC_PSERIES && PCI
default y if !EMBEDDED
 
+config PSERIES_MSI
+   bool
+   depends on PCI_MSI && EEH
+   default y
+
 config SCANLOG
tristate "Scanlog dump interface"
depends on RTAS_PROC && PPC_PSERIES
diff --git a/arch/powerpc/platforms/pseries/Makefile 
b/arch/powerpc/platforms/pseries/Makefile
index dfe574a..0ce691d 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_SCANLOG) += scanlog.o
 obj-$(CONFIG_EEH)  += eeh.o eeh_cache.o eeh_driver.o eeh_event.o 
eeh_sysfs.o
 obj-$(CONFIG_KEXEC)+= kexec.o
 obj-$(CONFIG_PCI)  += pci.o pci_dlpar.o
-obj-$(CONFIG_PCI_MSI)  += msi.o
+obj-$(CONFIG_PSERIES_MSI)  += msi.o
 
 obj-$(CONFIG_HOTPLUG_CPU)  += hotplug-cpu.o
 obj-$(CONFIG_MEMORY_HOTPLUG)   += hotplug-memory.o
-- 
1.6.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc/cell: Fix Axon MSI driver dependencies

[Michael Ellerman]

The Axon MSI driver depends on more than just PCI_MSI, so add a
Kconfig fragment for it. Fixes randconfig build failures.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/cell/Kconfig  |5 +
 arch/powerpc/platforms/cell/Makefile |2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/cell/Kconfig 
b/arch/powerpc/platforms/cell/Kconfig
index 037f59a..17b9b19 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -43,6 +43,11 @@ config PPC_CELL_QPACE
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL_COMMON
 
+config AXON_MSI
+   bool
+   depends on PPC_IBM_CELL_BLADE && PCI_MSI
+   default y
+
 menu "Cell Broadband Engine options"
depends on PPC_CELL
 
diff --git a/arch/powerpc/platforms/cell/Makefile 
b/arch/powerpc/platforms/cell/Makefile
index 43eccb2..83fafe9 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_SPU_BASE)+= 
spu_callbacks.o spu_base.o \
   $(spu-manage-y) \
   spufs/
 
-obj-$(CONFIG_PCI_MSI)  += axon_msi.o
+obj-$(CONFIG_AXON_MSI) += axon_msi.o
 
 # qpace setup
 obj-$(CONFIG_PPC_CELL_QPACE)   += qpace_setup.o
-- 
1.6.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc/pseries: The RPA PCI hotplug driver depends on EEH

[Michael Ellerman]

The RPA PCI hotplug driver calls EEH routines, so should depend on
EEH. Also PPC_PSERIES implies PPC64, so remove that.

Signed-off-by: Michael Ellerman 
---
 drivers/pci/hotplug/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/hotplug/Kconfig b/drivers/pci/hotplug/Kconfig
index eacfb13..9aa4fe1 100644
--- a/drivers/pci/hotplug/Kconfig
+++ b/drivers/pci/hotplug/Kconfig
@@ -143,7 +143,7 @@ config HOTPLUG_PCI_SHPC
 
 config HOTPLUG_PCI_RPA
tristate "RPA PCI Hotplug driver"
-   depends on PPC_PSERIES && PPC64 && !HOTPLUG_PCI_FAKE
+   depends on PPC_PSERIES && EEH && !HOTPLUG_PCI_FAKE
help
  Say Y here if you have a RPA system that supports PCI Hotplug.
 
-- 
1.6.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

83xx: Marking or Allocating Pages as Cache-Inhibited

[Ben Menchaca]

I am working on a Freescale 8314e design, and the embedded device is
configured as a PCI-e endpoint running a 2.6.27-5 kernel.  For context, we
have written a kernel module which, among other things, uses the RDMA/WDMA
engine in the PCI-e IP block.  On the host side, these DMAs are coherent.
However, on the embedded side, things are quite a bit less rosy; we must
manually flush/invalidate cache lines for WDMA/RDMAs to occur successfully.
After speaking with (several) FAEs at Freescale, we believe there is a
configuration issue that is the cause, but we have yet to have anyone
successfully point to it.

Disabling the data cache altogether resolves the issue entirely, but of
course, also completely tanks performance.  As a temporary workaround, I
would like to simply mark the pages (obtained currently via
dma_alloc_coherent) involved as cache-inhibited.  I have attempted to do
this via some snippets remaining in fec.c (va_to_pte, uncache_pte to set
_PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is almost
certainly braindead; va_to_pte is not a part of the 83xx source, as far as I
can tell; 8xx only.

A quick pointer in the correct direction for marking pages as
cache-inhibited on a 2.6.27-5 kernel would be appreciated, or if my approach
to a workaround is flawed, a pointer to the correct way would be great.

Ben Menchaca
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP]
and PEX_RDMA_CTRL[SNOOP]?

What is the freq settings? CORE/CSB bus.

Thanks, Dave



From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org] On Behalf
Of Ben Menchaca
Sent: Friday, March 06, 2009 12:33 PM
To: linuxppc-dev@ozlabs.org
Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited


I am working on a Freescale 8314e design, and the embedded
device is configured as a PCI-e endpoint running a 2.6.27-5 kernel.  For
context, we have written a kernel module which, among other things, uses
the RDMA/WDMA engine in the PCI-e IP block.  On the host side, these
DMAs are coherent.  However, on the embedded side, things are quite a
bit less rosy; we must manually flush/invalidate cache lines for
WDMA/RDMAs to occur successfully.  After speaking with (several) FAEs at
Freescale, we believe there is a configuration issue that is the cause,
but we have yet to have anyone successfully point to it.  

Disabling the data cache altogether resolves the issue entirely,
but of course, also completely tanks performance.  As a temporary
workaround, I would like to simply mark the pages (obtained currently
via dma_alloc_coherent) involved as cache-inhibited.  I have attempted
to do this via some snippets remaining in fec.c (va_to_pte, uncache_pte
to set _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is
almost certainly braindead; va_to_pte is not a part of the 83xx source,
as far as I can tell; 8xx only.

A quick pointer in the correct direction for marking pages as
cache-inhibited on a 2.6.27-5 kernel would be appreciated, or if my
approach to a workaround is flawed, a pointer to the correct way would
be great.

Ben Menchaca


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

and what settings  is DMA description bit 3?

> -Original Message-
> From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org 
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
> 
> Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and 
> PEX_RDMA_CTRL[SNOOP]?
> 
> What is the freq settings? CORE/CSB bus.
> 
> Thanks, Dave
> 
> 
> 
>   From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited
>   
>   
>   I am working on a Freescale 8314e design, and the 
> embedded device is configured as a PCI-e endpoint running a 
> 2.6.27-5 kernel.  For context, we have written a kernel 
> module which, among other things, uses the RDMA/WDMA engine 
> in the PCI-e IP block.  On the host side, these DMAs are 
> coherent.  However, on the embedded side, things are quite a 
> bit less rosy; we must manually flush/invalidate cache lines 
> for WDMA/RDMAs to occur successfully.  After speaking with 
> (several) FAEs at Freescale, we believe there is a 
> configuration issue that is the cause, but we have yet to 
> have anyone successfully point to it.  
>   
>   Disabling the data cache altogether resolves the issue 
> entirely, but of course, also completely tanks performance.  
> As a temporary workaround, I would like to simply mark the 
> pages (obtained currently via dma_alloc_coherent) involved as 
> cache-inhibited.  I have attempted to do this via some 
> snippets remaining in fec.c (va_to_pte, uncache_pte to set 
> _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is 
> almost certainly braindead; va_to_pte is not a part of the 
> 83xx source, as far as I can tell; 8xx only.
>   
>   A quick pointer in the correct direction for marking 
> pages as cache-inhibited on a 2.6.27-5 kernel would be 
> appreciated, or if my approach to a workaround is flawed, a 
> pointer to the correct way would be great.
>   
>   Ben Menchaca
>   
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Ben Menchaca]

1.  BAT2 in linux is set to WIMG=0010, and covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I hit a trigger...just ignore
the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared.

Core is 400MHz, and CSB is 133MHz.

- Ben

On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 wrote:

> and what settings  is DMA description bit 3?
>
> > -Original Message-
> > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> > [mailto:linuxppc-dev-bounces+daveliu =
> freescale@ozlabs.org]
> >  On Behalf Of Liu Dave-R63238
> > Sent: Friday, March 06, 2009 1:22 PM
> > To: Ben Menchaca; linuxppc-dev@ozlabs.org
> > Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
> >
> > Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and
> > PEX_RDMA_CTRL[SNOOP]?
> >
> > What is the freq settings? CORE/CSB bus.
> >
> > Thanks, Dave
> >
> > 
> >
> >   From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> > [mailto:linuxppc-dev-bounces+daveliu =
> freescale@ozlabs.org]
> >  On Behalf Of Ben Menchaca
> >   Sent: Friday, March 06, 2009 12:33 PM
> >   To: linuxppc-dev@ozlabs.org
> >   Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited
> >
> >
> >   I am working on a Freescale 8314e design, and the
> > embedded device is configured as a PCI-e endpoint running a
> > 2.6.27-5 kernel.  For context, we have written a kernel
> > module which, among other things, uses the RDMA/WDMA engine
> > in the PCI-e IP block.  On the host side, these DMAs are
> > coherent.  However, on the embedded side, things are quite a
> > bit less rosy; we must manually flush/invalidate cache lines
> > for WDMA/RDMAs to occur successfully.  After speaking with
> > (several) FAEs at Freescale, we believe there is a
> > configuration issue that is the cause, but we have yet to
> > have anyone successfully point to it.
> >
> >   Disabling the data cache altogether resolves the issue
> > entirely, but of course, also completely tanks performance.
> > As a temporary workaround, I would like to simply mark the
> > pages (obtained currently via dma_alloc_coherent) involved as
> > cache-inhibited.  I have attempted to do this via some
> > snippets remaining in fec.c (va_to_pte, uncache_pte to set
> > _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is
> > almost certainly braindead; va_to_pte is not a part of the
> > 83xx source, as far as I can tell; 8xx only.
> >
> >   A quick pointer in the correct direction for marking
> > pages as cache-inhibited on a 2.6.27-5 kernel would be
> > appreciated, or if my approach to a workaround is flawed, a
> > pointer to the correct way would be great.
> >
> >   Ben Menchaca
> >
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

what is the value of ACR register?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation of the
DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I hit a
trigger...just ignore the size...) contains 0002AFF3 at offset 0, so
nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]

>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages as
Cache-Inhibited
>
> Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP]
and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating Pages as
Cache-Inhibited
>
>
>   I am working on a Freescale 8314e design, and
the
> embedded device is configured as a PCI-e endpoint
running a
> 2.6.27-5 kernel.  For context, we have written a
kernel
> module which, among other things, uses the RDMA/WDMA
engine
> in the PCI-e IP block.  On the host side, these DMAs
are
> coherent.  However, on the embedded side, things are
quite a
> bit less rosy; we must manually flush/invalidate cache
lines
> for WDMA/RDMAs to occur successfully.  After speaking
with
> (several) FAEs at Freescale, we believe there is a
> configuration issue that is the cause, but we have yet
to
> have anyone successfully point to it.
>
>   Disabling the data cache altogether resolves the
issue
> entirely, but of course, also completely tanks
performance.
> As a temporary workaround, I would like to simply mark
the
> pages (obtained currently via dma_alloc_coherent)
involved as
> cache-inhibited.  I have attempted to do this via some
> snippets remaining in fec.c (va_to_pte, uncache_pte to
set
> _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but
this is
> almost certainly braindead; va_to_pte is not a part of
the
> 83xx source, as far as I can tell; 8xx only.
>
>   A quick pointer in the correct direction for
marking
> pages as cache-inhibited on a 2.6.27-5 kernel would be
> appreciated, or if my approach to a workaround is
flawed, a
> pointer to the correct way would be great.
>
>   Ben Menchaca
>
>

> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

could you try to set '1' to DMA description bit3?




From: Liu Dave-R63238 
Sent: Friday, March 06, 2009 1:41 PM
To: 'Ben Menchaca'
Cc: linuxppc-dev@ozlabs.org
Subject: RE: 83xx: Marking or Allocating Pages as
Cache-Inhibited


what is the value of ACR register?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and covers all
64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54):
0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation
of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I hit a
trigger...just ignore the size...) contains 0002AFF3 at offset 0, so
nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]

>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages
as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating
Pages as Cache-Inhibited
>
>
>   I am working on a Freescale 8314e
design, and the
> embedded device is configured as a PCI-e
endpoint running a
> 2.6.27-5 kernel.  For context, we have written
a kernel
> module which, among other things, uses the
RDMA/WDMA engine
> in the PCI-e IP block.  On the host side,
these DMAs are
> coherent.  However, on the embedded side,
things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.  After
speaking with
> (several) FAEs at Freescale, we believe there
is a
> configuration issue that is the cause, but we
have yet to
> have anyone successfully point to it.
>
>   Disabling the data cache altogether
resolves the issue
> entirely, but of course, also completely tanks
performance.
> As a temporary workaround, I would like to
simply mark the
> pages (obtained currently via
dma_alloc_coherent) involved as
> cache-inhibited.  I have attempted to do this
via some
> snippets remaining in fec.c (va_to_pte,
uncache_pte to set
> _PAGE_NO_CACHE, flush_tlb_page, then
unmap_pte), but this is
> almost certainly braindead; va_to_pte is not a
part of the
> 83xx source, as far as I can tell; 8xx only.
>
>   A quick pointer in the correct direction
for marking
> pages as cache-inhibited on a 2.6.27-5 kernel
would be
> appreciated, or if my approach to a workaround
i

Re: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Ben Menchaca]

I can look at ACR morning...although I can say with a fair amount of
certainty that I have not changed it from the POR value.

I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this
seems a bit counterintuitive to me.

What is the hope regarding these two?  Some combination I am not seeing?


On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 wrote:

>  what is the value of ACR register?
>
>  --
> *From:* Ben Menchaca [mailto:ben.mench...@gmail.com]
> *Sent:* Friday, March 06, 2009 1:38 PM
> *To:* Liu Dave-R63238
> *Cc:* linuxppc-dev@ozlabs.org
> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>
> 1.  BAT2 in linux is set to WIMG=0010, and covers all 64M
> 2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020
> 3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA.
> 4.  OWAR0 is set to 0xF005, so NSNP is 0.
> 5.  The DMA descriptor (randomly chosen when I hit a trigger...just ignore
> the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared.
>
> Core is 400MHz, and CSB is 133MHz.
>
> - Ben
>
> On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 wrote:
>
>> and what settings  is DMA description bit 3?
>>
>> > -Original Message-
>> > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
>> > [mailto:linuxppc-dev-bounces+daveliu =
>> freescale@ozlabs.org]
>>   >  On Behalf Of Liu Dave-R63238
>> > Sent: Friday, March 06, 2009 1:22 PM
>> > To: Ben Menchaca; linuxppc-dev@ozlabs.org
>> > Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
>> >
>> > Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and
>> > PEX_RDMA_CTRL[SNOOP]?
>> >
>> > What is the freq settings? CORE/CSB bus.
>> >
>> > Thanks, Dave
>> >
>> > 
>> >
>> >   From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
>> > [mailto:linuxppc-dev-bounces+daveliu =
>> freescale@ozlabs.org]
>> >  On Behalf Of Ben Menchaca
>> >   Sent: Friday, March 06, 2009 12:33 PM
>> >   To: linuxppc-dev@ozlabs.org
>> >   Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited
>> >
>> >
>> >   I am working on a Freescale 8314e design, and the
>> > embedded device is configured as a PCI-e endpoint running a
>> > 2.6.27-5 kernel.  For context, we have written a kernel
>> > module which, among other things, uses the RDMA/WDMA engine
>> > in the PCI-e IP block.  On the host side, these DMAs are
>> > coherent.  However, on the embedded side, things are quite a
>> > bit less rosy; we must manually flush/invalidate cache lines
>> > for WDMA/RDMAs to occur successfully.  After speaking with
>> > (several) FAEs at Freescale, we believe there is a
>> > configuration issue that is the cause, but we have yet to
>> > have anyone successfully point to it.
>> >
>> >   Disabling the data cache altogether resolves the issue
>> > entirely, but of course, also completely tanks performance.
>> > As a temporary workaround, I would like to simply mark the
>> > pages (obtained currently via dma_alloc_coherent) involved as
>> > cache-inhibited.  I have attempted to do this via some
>> > snippets remaining in fec.c (va_to_pte, uncache_pte to set
>> > _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is
>> > almost certainly braindead; va_to_pte is not a part of the
>> > 83xx source, as far as I can tell; 8xx only.
>> >
>> >   A quick pointer in the correct direction for marking
>> > pages as cache-inhibited on a 2.6.27-5 kernel would be
>> > appreciated, or if my approach to a workaround is flawed, a
>> > pointer to the correct way would be great.
>> >
>> >   Ben Menchaca
>> >
>> >
>> > ___
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@ozlabs.org
>> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >
>> >
>>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Did you enable the descriptor bit 3 to have a try?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 2:10 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


I can look at ACR morning...although I can say with a fair
amount of certainty that I have not changed it from the POR value.

I will try enabling No Snoop for CSB in the descriptor (bit 3,
yes?)...this seems a bit counterintuitive to me.

What is the hope regarding these two?  Some combination I am not
seeing?



On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238
 wrote:


what is the value of ACR register?




From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages
as Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and
covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space
(0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the
initiation of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I
hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0,
so nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description
bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]

>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca;
linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB
bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
 =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009
12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
>
>   I am working on a Freescale
8314e design, and the
> embedded device is configured as a
PCI-e endpoint running a
> 2.6.27-5 kernel.  For context, we have
written a kernel
> module which, among other things, uses
the RDMA/WDMA engine
> in the PCI-e IP block.  On the host
side, these DMAs are
> coherent.  However, on the embedded
side, things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.
After speaking with
> (several) FAEs at Freescale, we
believe there is a
> configuration issue that is the cause,
but we have yet to
> have anyone successfully point to it.
>
>   Disablin

[RFC] More compatibles or more quirk properties

[Li Yang-R58472]

Hi,

I'm running into a dilemma choosing between two approaches of defining device 
tree binding.  Let's say if we have several chips with a similar SoC block, but 
each of them have different quirks.  If I define different compatibles for each 
of the chips, the driver will have a longer match table and thus bloat the 
device matching process.  Or we can use a same compatible for all of them and  
define properties for each of the quirks.  But it somewhat bloats the device 
tree.  I'm more prone to the second solution, but I do want to hear what you 
guys think about it.

- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] More compatibles or more quirk properties

[Mitch Bradley]

I'm running into a dilemma choosing between two approaches of defining device 
tree binding.  Let's say if we have several chips with a similar SoC block, but 
each of them have different quirks.  If I define different compatibles for each 
of the chips, the driver will have a longer match table and thus bloat the 
device matching process.  Or we can use a same compatible for all of them and  
define properties for each of the quirks.  But it somewha
Properties to describe quirks precisely are definitely better.  In fact, 
that's fundamental principle - describe the situation, don't infer a 
bunch of details from a name.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device

[Jens Axboe]

On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> On Thu, 5 Mar 2009, Jens Axboe wrote:
> > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > On Thu, 5 Mar 2009, Jens Axboe wrote:
> > > > On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > > > > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain 
> > > > > block
> > > > > device, as requested by Arnd Bergmann.
> 
> > > > I'd rewrite this as a ->make_request_fn handler instead. Then you can
> > > > get rid of the kernel thread. IOW, change
> > > >
> > > > queue = blk_init_queue(ps3vram_request, &priv->lock);
> > > >
> > > > to
> > > >
> > > > queue = blk_alloc_queue(GFP_KERNEL);
> > > > blk_queue_make_request(queue, ps3vram_make_request);
> > >
> > > Thanks, I didn't know that part...
> > >
> > > > Add error handling of course, and call blk_queue_max_*() to set your
> > > > limits for this device.
> > >
> > > I took out the blk_queue_max_*() calls (compared to ps3disk.c), as
> > > none of the limits apply, and the defaults are fine.
> > >
> > > Is that OK, or is it better to make it explicit?
> >
> > I think it's always good to make it explicit. Plus for this case you
> > definitely need it, as blk_init_queue() wont do it for you anymore.
> 
> blk_queue_make_request() does it for me, too:
> 
> void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn)
> {
>   ...
>   blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
>   blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
>   ...
>   blk_queue_max_segment_size(q, MAX_SEGMENT_SIZE);
>   ...
>   blk_queue_max_sectors(q, SAFE_MAX_SECTORS);
>   ...
> }
> 
> struct request_queue *
> blk_init_queue_node(request_fn_proc *rfn, spinlock_t *lock, int node_id)
> {
>   ...
>   blk_queue_max_segment_size(q, MAX_SEGMENT_SIZE);
> 
>   blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
>   blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
>   ...
> }

Indeed, there's some duplicated code in blk_init_queue_node(), I'll make
sure to get rid of that!

> > > > Then add a ps3vram_make_request() ala:
> > >
> > > > static void ps3vram_do_request(struct request_queue *q, struct bio *bio)
> > > > {
> 
> > > > }
> > > >
> > > > I just typed it here, so if it doesn't compile you get to keep the
> > > > pieces :-)
> > >
> > > OK, I'll give it a try...
> > >
> > > BTW, does this mean the `simple' way, which I used based on LDD3, is
> > > deprecated?
> >
> > Depends.. It's obviously not a very effective approach, since you punt
> > to a thread for each request. But if you need the IO scheduler helping
> > you with merging and sorting (for a rotational device), it still has
> > some merit. For this particular case, the ->make_request_fn approach is
> > much better.
> 
> Without the thread, performance indeed increased.
> 
> But then I noticed ps3vram_make_request() may be called concurrently,
> so I had to add a mutex to avoid data corruption. This slows the
> driver down, and in the end, the version with a thread turns out to be
> ca. 1% faster. The version without a thread is about 50 lines less
> code, though.

That is correct, ->make_request_fn may get reentered. I'm not surprised
that performance dropped if you just shoved everything under a mutex.
You could be a little more smart and queue concurrent bio's for
processing when the current one is complete though, there are several
approaches there that be a lot faster than going all the way through the
IO stack and scheduler just to avoid concurrency.

-- 
Jens Axboe

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev