83xx GPIO/EXT int in arch/powerpc/

83xx GPIO/EXT int in arch/powerpc/

[Marc Leeman]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]


I am moving my boards from arch/ppc/ to arch/powerpc/ and am trying to
use the MPC83xx_IRQ_EXT? pins.

The device (hardcoded to use 23 as with the arch/ppc/ config, EXT7)
does not signal the ints to the CPU.

The only reference I find to this usage in arch/powerpc/ is in
arch/powerpc/platforms/83xx/mpc834x_itx.h, which is most likely
something left over while moving from arch/ppc/

Probably, I need to enable them in the dts tree (?) but since it's a PCI
device that uses a GPIO pin for signalling interrupts, I'm trying to
find out where and how to configure this.

Is there some example for e.g. an 83xx board how to configure one of
those external interrupt pins?

-- 
  greetz, marc
It's like Disney on acid! Ten years of really great sex all at the
same moment.
	Crichton - Rhapsody in Blue
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 83xx GPIO/EXT int in arch/powerpc/

[Andy Fleming]

On Jun 4, 2007, at 04:56, Marc Leeman wrote:

>
> I am moving my boards from arch/ppc/ to arch/powerpc/ and am trying to
> use the MPC83xx_IRQ_EXT? pins.
>
> The device (hardcoded to use 23 as with the arch/ppc/ config, EXT7)
> does not signal the ints to the CPU.
>
> The only reference I find to this usage in arch/powerpc/ is in
> arch/powerpc/platforms/83xx/mpc834x_itx.h, which is most likely
> something left over while moving from arch/ppc/
>
> Probably, I need to enable them in the dts tree (?) but since it's  
> a PCI
> device that uses a GPIO pin for signalling interrupts, I'm trying to
> find out where and how to configure this.


Wow.  Hardware designers sure like to make things easy, don't they?

I'm assuming it's a PCI device on the board (and not in a slot).

I believe you're ok if you explicitly define the node, and point it  
at the IPIC for its interrupt.  Something like this:

pci1: pci@8000 {
	...
	my_pci_device@0 {
		...
		interrupts = <irq#, sense>;
		interrupt-parent = <&ipic>;
	}
}

Re: 83xx GPIO/EXT int in arch/powerpc/

[Segher Boessenkool]

>> Probably, I need to enable them in the dts tree (?) but since it's
>> a PCI
>> device that uses a GPIO pin for signalling interrupts, I'm trying to
>> find out where and how to configure this.
>
> Wow.  Hardware designers sure like to make things easy, don't they?
>
> I'm assuming it's a PCI device on the board (and not in a slot).
>
> I believe you're ok if you explicitly define the node, and point it
> at the IPIC for its interrupt.

That's the simplest way to do it, yes (and sometimes
the only way).  I believe for Linux you can get away
with not defining any of the standard PCI properties
in that new PCI node (well you need "reg" and very very
basic stuff like that, of course).

> Something like this:
>
> pci1: pci@8000 {
> 	...
> 	my_pci_device@0 {
> 		...
> 		interrupts = <irq#, sense>;
> 		interrupt-parent = <&ipic>;
> 	}
> }

Exactly.  Please remember that "interrupts" here
is in the ipic domain and not in the PCI domain,
so get the # interrupt cells and the sense value
from the ipic.


Segher

Re: 83xx GPIO/EXT int in arch/powerpc/

[Marc Leeman]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

> Wow.  Hardware designers sure like to make things easy, don't they?

<rant>
The reason that I am switching to powerpc is that dts seems a cleaner
way to handle the I-didn't-know-what-a-reference-design-is-for decisions
from our hardware designers and just connect up the devices like a large
box of lego :-/.

Even getting the gianfar eth devices up can become a challenge (not
again) because someone thought 'it makes more sense like this'. On
the bright side, I always have a reason in digging into the mpc834x
processor manual.
</rant>

> I'm assuming it's a PCI device on the board (and not in a slot).

yep, it's an FPGA device using PCI and GPIOs for interrupts (depending
on the board, it's for a MAC core in FPGA or custom logic).

> I believe you're ok if you explicitly define the node, and point it  
> at the IPIC for its interrupt.  Something like this:
> 
> pci1: pci@8000 {
> 	...
> 	my_pci_device@0 {
> 		...
> 		interrupts = <irq#, sense>;
> 		interrupt-parent = <&ipic>;
> 	}
> }

So I don't have to define the GPIO pins in pio-map in "vi) Pin
configuration nodes" and already set in the U-Boot bootloader? Using the
GPIOs for interrupts or IO would just work "out of the box" after the
U-boot initialisation (used for TI's HPI in with the UPMB).

Hang, and I finally thought the documentation made sense to me :-)

I already tried hardcoding the EXT7 pin as assigned in the ppc arch
(int 23); this would mean that, in the powerpc arch, the assignments of
interrupts is different wrt to ppc?

-- 
  greetz, marc
You'll be happy to know I have a plan.
	Crichton - Through the Looking Glass
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 83xx GPIO/EXT int in arch/powerpc/

[Andy Fleming]

On Jun 4, 2007, at 16:17, Marc Leeman wrote:

>
> So I don't have to define the GPIO pins in pio-map in "vi) Pin
> configuration nodes" and already set in the U-Boot bootloader?  
> Using the
> GPIOs for interrupts or IO would just work "out of the box" after the
> U-boot initialisation (used for TI's HPI in with the UPMB).

I meant external interrupts, not GPIOs.  I just had a brain fart.

>
> Hang, and I finally thought the documentation made sense to me :-)
>
> I already tried hardcoding the EXT7 pin as assigned in the ppc arch
> (int 23); this would mean that, in the powerpc arch, the  
> assignments of
> interrupts is different wrt to ppc?


In the intervening versions between the introduction of arch/powerpc,  
and now, the interrupt mapping has also changed.  The interrupts are  
now all virtualized, and therefore all the interrupts start at 1 for  
each interrupt controller.  The numbers therefore change depending on  
how things are initialized.  You can't use hard-coded numbers  
anymore.  You need to map them into virtual numbers.  The easiest way  
is to set up an of node for the device, and invoke the necessary  
translation functions from your board code (Take a look at the CDS  
code for an example with a fairly complicated tree.  Or any other fsl  
board code for an almost-reasonable topology.  :) )

Andy

Re: 83xx GPIO/EXT int in arch/powerpc/

[Segher Boessenkool]

>> pci1: pci@8000 {
>> 	...
>> 	my_pci_device@0 {
>> 		...
>> 		interrupts = <irq#, sense>;
>> 		interrupt-parent = <&ipic>;
>> 	}
>> }
>
> So I don't have to define the GPIO pins in pio-map in "vi) Pin
> configuration nodes" and already set in the U-Boot bootloader?

No, something in the firmware (or bootwrapper, bootloader)
obviously has to set up the GPIO as an external interrupt
source.

> I already tried hardcoding the EXT7 pin as assigned in the ppc arch
> (int 23); this would mean that, in the powerpc arch, the assignments of
> interrupts is different wrt to ppc?

I would hope the kernel isn't messing around with this
at all, and leave such low-level hardware configuration
to the firmware!


Segher

Re: 83xx GPIO/EXT int in arch/powerpc/

[Segher Boessenkool]

> You can't use hard-coded numbers
> anymore.  You need to map them into virtual numbers.  The easiest way
> is to set up an of node for the device, and invoke the necessary
> translation functions from your board code

As long as the interrupt graph in your device tree is
correct, all this should work just like magic ;-)


Segher

Re: 83xx GPIO/EXT int in arch/powerpc/

[Benjamin Herrenschmidt]

I'm a bit afraid that our various messages on the subject have been a
tad confusing :-) Especially your blurb on virtual number is a bit scary
Andy :-)

So I'm in a good mood, I'll attempt to explain what's going on.

The powerpc kernel nowadays separate linux IRQ numbers (what you see in
pci_device->irq, or what devices do a request_irq() on) from HW numbers.

The former are what we call "virtual" IRQ numbers, and are just indices
in a giant array (has always been), and can now be arbitrarily mapped to
HW numbers. In addition, linux always reserve numbers 0...15. 0 is
always illegal and 1..15 can only be mapped to a 8259 type legacy ISA
controller. This is to avoid problem with stupid drivers from the x86
world.

HW numbers are local to a given interrupt controller and they should be
all you care about in the device-tree.

If a device has interrupt source 2 on the IPIC, it should have an
interrupts property encoding a 2 (along with whatever the IPIC uses to
encode polarity). This will ultimately be turned into some other number
by linux for a virtual irq, but that's not the business of the dts.

Now, there is no automagic way of setting up GPIOs. You have to manually
(from your firmware that is, or maybe from your platform code),
configure the appropriate GPIO to the appropriate HW irq source on the
IPIC that matches what you put in your DTS.

The way those HW numbers are then parsed and turned into virtual IRQ
numbers depends on the type of device. Basically, you can always do it
manually with the irq_* functions, either by providing directly the low
level values (I wouldn't recommand that in general) or by letting the
linux device-tree parser do it for you.

However, if your device is a PCI device, it might be a simple as letting
the linux PCI code do it for you :-) the linux PCI code uses the parser
to attempt to resolve interrupts for every PCI device in the system.

Thus, you have multiple options here:

 - The easy/hack/bad one: You can have a ppc_md.pci_irq_fixup hook in
your platform code that maps it manually to a hard coded number. That's
ugly, but it will work. Though expect complaints if you ever try to
merge your code upstream.

 - You can create a device-node for the PCI device. PCI devices
normally, in linux, don't need to have device-nodes in the DTS, at least
it's not mandatory, but you -can- do it. If your node has the correct
"reg" property, it should be matches by the linux parser, and thus you
have the ability to put an interrupts property in there. It would
normally be a PCI interrupt specification, but you can specify
explicitely an interrupt parent that points to the IPIC and thus have an
interrupt pointing directly there. That's the example that, I think,
Andy gave you

 - You can do it in your interrupt-map. That's probably the cleanest way
to do it. Basically, you don't need a node for your device (or if you
have one, you let it do the standard "interrupts" for PCI which contains
an interrupt in number). However, in the interrupt-map of the bridge,
you'll notice that there's an entry for every possible dev/fn. Each of
them has an explicit parent PIC specification. Just make sure you have
an entry there for your device pin A dev/fn whose specification points
to the IPIC with the appropriate IRQ number and that should work fine.
If your device emits interrupts on multiple pins, you can always have
multiple entries, etc...

Now, that's assuming GPIOs, when used as external interrupts, are
directly routed to the IPIC. I don't know the 83xx so I just assumed
it :-) If that's not the case, you may need some intermediary cascaded
interrupt controller or something around those lines.

Ben.

Re: 83xx GPIO/EXT int in arch/powerpc/

[Segher Boessenkool]

> In addition, linux always reserve numbers 0...15. 0 is
> always illegal and 1..15 can only be mapped to a 8259 type legacy ISA
> controller. This is to avoid problem with stupid drivers from the x86
> world.

Of course, it doesn't help if you have an i8259 but have
non-legacy-PC devices on it.  Oh the horror!

> Now, there is no automagic way of setting up GPIOs. You have to 
> manually
> (from your firmware that is, or maybe from your platform code),
> configure the appropriate GPIO to the appropriate HW irq source on the
> IPIC that matches what you put in your DTS.

It *really* shouldn't be Linux platform code, if you can
avoid it at all.  It's just more trouble than it's worth.

>  - You can create a device-node for the PCI device. PCI devices
> normally, in linux, don't need to have device-nodes in the DTS, at 
> least
> it's not mandatory, but you -can- do it. If your node has the correct
> "reg" property,

What is "correct" in this case?  We probably should describe
what properties are required in a (non-phb) pci node for
platforms that don't use the device tree for probing PCI.
In this specific case, do you only need the configuration
address in the "reg"?

> it should be matches by the linux parser, and thus you
> have the ability to put an interrupts property in there. It would
> normally be a PCI interrupt specification, but you can specify
> explicitely an interrupt parent that points to the IPIC and thus have 
> an
> interrupt pointing directly there. That's the example that, I think,
> Andy gave you

Yeah.

>  - You can do it in your interrupt-map. That's probably the cleanest 
> way
> to do it.

Not really.  If the device interrupt is physically connected
directly to a GPIO or a PIC or whatever, if it doesn't go
through the PCI bus; then it shouldn't be represented in
the device tree as if it did.  The higher-up bridge has
nothing whatsoever to do with this device's interrupt.

It's a simple hack of course, it can be useful sometimes.
It's not "clean" at all however.

> Just make sure you have
> an entry there for your device pin A dev/fn whose specification points
> to the IPIC with the appropriate IRQ number and that should work fine.

Depending on the rest of the tree, this would often mean
you have to do a much bigger interrupt-map-mask than
without this hack, and the corresponding explosion in
interrupt-map size.

> Now, that's assuming GPIOs, when used as external interrupts, are
> directly routed to the IPIC. I don't know the 83xx so I just assumed
> it :-)

Almost always that's how it works yeah.  And the "GPIO"
stage isn't normally represented in the device tree, GPIO
settings are considered a part of the PCB layout ;-) (one
more reason why Linux shouldn't have to touch it).

> If that's not the case, you may need some intermediary cascaded
> interrupt controller or something around those lines.

Yeah, but that's just the more general case of the
general case :-)


Segher

Re: 83xx GPIO/EXT int in arch/powerpc/

[Benjamin Herrenschmidt]

On Wed, 2007-06-06 at 11:47 +0200, Segher Boessenkool wrote:
>   - You can do it in your interrupt-map. That's probably the cleanest 
> > way
> > to do it.
> 
> Not really.  If the device interrupt is physically connected
> directly to a GPIO or a PIC or whatever, if it doesn't go
> through the PCI bus; then it shouldn't be represented in
> the device tree as if it did.  The higher-up bridge has
> nothing whatsoever to do with this device's interrupt.
> 
> It's a simple hack of course, it can be useful sometimes.
> It's not "clean" at all however.

I disagree :-)

The "PCI bus" in that sense is just the INT lines. They are connected
wherever you want, doesn't matter. Look at Apple for example, they are
all connected to GPIOs too.

The interrupt-map simply provides for each slot where the interrupt
goes. It's perfectly fine and clean to use it when those interrupts are
hooked to GPIOs and has been a common practice. I really don't see a
problem with that.

> Depending on the rest of the tree, this would often mean
> you have to do a much bigger interrupt-map-mask than
> without this hack, and the corresponding explosion in
> interrupt-map size.

Not really again. Besides, devices normally use only int#A, only bridges
use more.

> Almost always that's how it works yeah.  And the "GPIO"
> stage isn't normally represented in the device tree, GPIO
> settings are considered a part of the PCB layout ;-) (one
> more reason why Linux shouldn't have to touch it).
> 
> > If that's not the case, you may need some intermediary cascaded
> > interrupt controller or something around those lines.
> 
> Yeah, but that's just the more general case of the
> general case :-)

Segher, I feel here that your inability to resist arguing about
everything in that case is confusing what is a fairly simple issue in
the first place :-) Poor guy trying to figure out the right way to do
his stuff will run away screaming and go back hard coding his number in
his platform code before we are finished :-)

So I would say, taking a dicator hat, that the right way to fix his
problem is also the simplest, which is to make sure the interrupt-map
entry for that slot points to the right GPIO interrupt :-)

Easy isn't it ?

Cheers,
Ben.

Re: 83xx GPIO/EXT int in arch/powerpc/

[Segher Boessenkool]

>>   - You can do it in your interrupt-map. That's probably the cleanest
>>> way
>>> to do it.
>>
>> Not really.  If the device interrupt is physically connected
>> directly to a GPIO or a PIC or whatever, if it doesn't go
>> through the PCI bus; then it shouldn't be represented in
>> the device tree as if it did.  The higher-up bridge has
>> nothing whatsoever to do with this device's interrupt.
>>
>> It's a simple hack of course, it can be useful sometimes.
>> It's not "clean" at all however.
>
> I disagree :-)

I think you didn't notice that I was talking about
pretending the IRQ signal of a device on PCI bus #1
being routed through PCI bus #0, the grandparent bus
of the device instead of the parent bus.  If it were
about the direct parent bus than anything could be
handled with an interrupt-map just fine, in the current
situation it is just ugly and wrong and it cannot work
in slightly more general situations, either.

> The interrupt-map simply provides for each slot where the interrupt
> goes. It's perfectly fine and clean to use it when those interrupts are
> hooked to GPIOs and has been a common practice. I really don't see a
> problem with that.

You shouldn't map interrupts from devices on your
children's busses, that's the problem.

>> Depending on the rest of the tree, this would often mean
>> you have to do a much bigger interrupt-map-mask than
>> without this hack, and the corresponding explosion in
>> interrupt-map size.
>
> Not really again. Besides, devices normally use only int#A, only 
> bridges
> use more.

Again, in the case under discussion, PCI bus# needs to
be part of the map-mask, and you can't do swizzling (or
a simple direct translation, whatever is appropriate)
for the bus-bus connection -- you have to spell out every
source deep down the domain.

> Segher, I feel here that your inability to resist arguing about
> everything in that case is confusing what is a fairly simple issue in
> the first place :-)

It isn't simple.  It is also wrong.  If a bus does
not deliver interrupts from its children to its
parent, than the device tree should not pretend it
does.

> Poor guy trying to figure out the right way to do
> his stuff will run away screaming and go back hard coding his number in
> his platform code before we are finished :-)

Heh I hope not.

> So I would say, taking a dicator hat, that the right way to fix his
> problem is also the simplest, which is to make sure the interrupt-map
> entry for that slot points to the right GPIO interrupt :-)

It's wrong and not simple.  Let me show you with some
pictures.  A device X on PCI bus P1, interrupt goes
straight to interrupt controller I.

Here's what you say is right:

P0      interrupt-map < ...reg 19000 irq IRQ -> I... >
|
P1
|
X@12    reg <19000>
         interrupt-parent <P0>
         interrupt <IRQ>

And here is my version:

P0
|
P1      interrupt-map < ... reg 9000 irq IRQ -> I ... >
|
X@12    reg <19000>
         interrupt-parent <P0>
         interrupt <IRQ>

> Easy isn't it ?

Yes, it's only hard if you're trying to avoid doing
mapping properties where they are necessary, including
stand-alone interrupt nexus nodes (not needed in this
case btw, not needed most simple cases).


Segher

Re: 83xx GPIO/EXT int in arch/powerpc/

[Marc Leeman]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

> > Poor guy trying to figure out the right way to do
> > his stuff will run away screaming and go back hard coding his number in
> > his platform code before we are finished :-)
> 
> Heh I hope not.

Hm, I guess I took the dirty way suggested by Benjamin and having a look
at the CDS Freescale platform by copying the following in my platform
file:

static void __init mpc83xx_svc2_pcibios_fixup(void)
{
	struct pci_dev *dev;

	if ((dev = pci_get_device(VENDOR_ID_ALTERA,
					DEVICE_ID_FPGA834XG1, NULL))) {
		dev->irq = 23;
		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 23);
		pci_dev_put(dev);
	}

	/* Now map all the PCI irqs */
	dev = NULL;
	for_each_pci_dev(dev)
		pci_read_irq_line(dev);

}

I am planning to have another look at the proper (tm) way to fix it, by
experimenting with my dts file; but since I need to get a number of
boards released, it's a bit pushed backwards.


What is more disturbing though, is that a number of operations on the
powerpc arch seems significantly slower wrt the ppc arch.

ioremap and iounmap being the most important one: we are using a small
driver that uses one of the UPMs in combination with GPIOs for HPI (Host
Port Interface) for TI DSPs.

Where the loading of a DSP took only 3 seconds, it went up to over a
minute on powerpc (same driver code).

Changing the driver to ioremap and unmap 0xe2400000 only once at driver
initialisation and unloading (not really relevant on this embedded
system, shame on me) instead twice for every word greatly improves the
time (around one second). However, this optimisation has the same effect
on ppc too :-/

Running the same application with the same modules on ppc and powerpc
(transferring data from the network to an FPGA) has a 50% higher load on
powerpc. The transfer is done with mapping user pages into the kernel
and DMA'ing them over PCI. What all driver have in common is that there
are quite some writes/reads to the IMMR configuration.

Decreasing the read and writes to the LBC for HPI (0xe2400000) seems to
improve the overall load.

So my question would be if I need to specify a special section in the
dts file for some reason; next to the U-Boot configuration that sends
writes to this address through the UPMB?

If not, is there any other reason that might account for these
significant performance drops?

-- 
  greetz, marc
Aeryn, did I say or do anything to piss you off? I mean other than
caving in the side of your head?
	Crichton - Die Me, Dichotomy
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 83xx GPIO/EXT int in arch/powerpc/

[Kumar Gala]

> What is more disturbing though, is that a number of operations on the
> powerpc arch seems significantly slower wrt the ppc arch.
>
> ioremap and iounmap being the most important one: we are using a small
> driver that uses one of the UPMs in combination with GPIOs for HPI  
> (Host
> Port Interface) for TI DSPs.
>
> Where the loading of a DSP took only 3 seconds, it went up to over a
> minute on powerpc (same driver code).

I'm confused what you are comparing here, 3 seconds on arch=ppc vs  
over a minute on arch=powerpc?

> Changing the driver to ioremap and unmap 0xe2400000 only once at  
> driver
> initialisation and unloading (not really relevant on this embedded
> system, shame on me) instead twice for every word greatly improves the
> time (around one second). However, this optimisation has the same  
> effect
> on ppc too :-/
>
> Running the same application with the same modules on ppc and powerpc
> (transferring data from the network to an FPGA) has a 50% higher  
> load on
> powerpc. The transfer is done with mapping user pages into the kernel
> and DMA'ing them over PCI. What all driver have in common is that  
> there
> are quite some writes/reads to the IMMR configuration.

I'd expect the driver to be exactly the same (or close to it) for  
arch=ppc vs arch=powerpc.

> Decreasing the read and writes to the LBC for HPI (0xe2400000)  
> seems to
> improve the overall load.
>
> So my question would be if I need to specify a special section in the
> dts file for some reason; next to the U-Boot configuration that sends
> writes to this address through the UPMB?
>
> If not, is there any other reason that might account for these
> significant performance drops?

There shouldn't be, but if you are seeing this we really should  
figure out what's going on.

What kernel is this on?  What processor are you using?

- k

Re: 83xx GPIO/EXT int in arch/powerpc/

[Marc Leeman]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

> I'm confused what you are comparing here, 3 seconds on arch=ppc vs  
> over a minute on arch=powerpc?

Loading of a TI DSP over HPI. HPI is implemented in UPMB (programmed by
U-Boot); all that the kernel has to do is write to the in U-Boot
programmed location (0xe2400000) to trigger the UPMB HPI protocol.

> I'd expect the driver to be exactly the same (or close to it) for  
> arch=ppc vs arch=powerpc.

Same here: there are a number of performance issues wrt to an older 8245
based implementation (network seems slower too) and this was not one I
expected while switching to powerpc.

> There shouldn't be, but if you are seeing this we really should  
> figure out what's going on.
> 
> What kernel is this on?  What processor are you using?

$ cat /proc/cpuinfo
processor       : 0
cpu             : e300c1
clock           : 396.000000MHz
revision        : 1.1 (pvr 8083 0011)
bogomips        : 131.28
timebase        : 66000000
platform        : BARCO834x SVC2

$ uname -a
Linux barco 2.6.21.1-barco1 #1 PREEMPT Tue Jun 12 09:48:12 CEST 2007 ppc unknown

The board is based on the FreeScale SYS/EMDS reference design.

Most of the HPI operations are stuff like this:

static inline int8_t _hpi_set_hhwil(uint8_t b)
{
        volatile immap_t* im;

        if(!(im = ioremap((immrbar),sizeof(struct immap)))){
                return -EINVAL;
        }
        (b)?(im->gpio[0].dat |= HHWIL):(im->gpio[0].dat &= ~HHWIL);
        iounmap(im);

        return 0;
}

static inline uint32_t __hpi_read_hpid(void)
{
        uint32_t returnval;

        /* Program HPID */
        _hpi_set_hcntl1(1);
        _hpi_set_hcntl0(1);

        /* first halfword */
        _hpi_set_hhwil(0);
        /* dummy read */
        returnval = (((uint32_t)(*hpi_dsp))<<16);

        /* delay */
        udelay(1);

        /* second halfword */
        _hpi_set_hhwil(1);
        /* dummy read */
        returnval |= *hpi_dsp;

        /* delay */
        udelay(1);

        return returnval;
}

The ioremap was certainly a bottleneck; and moving it to initialisation
with a global pointer got us from 60 secs back to around 1 sec, but the
a similar effect was obtained on the ppc arch with this change (this was
just making a bad situation to be hidden).

Even after this change; the load of a streaming application was
something of 40% on ppc and 60% on powerpc.

-- 
  greetz, marc
I'm having sex with 3 hynerian donkeys. What does it look like i'm
doing?
	Chiana - Crackers Don't Matter
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 83xx GPIO/EXT int in arch/powerpc/

[Kumar Gala]

On Jun 12, 2007, at 11:06 AM, Marc Leeman wrote:

>> I'm confused what you are comparing here, 3 seconds on arch=ppc vs
>> over a minute on arch=powerpc?
>
> Loading of a TI DSP over HPI. HPI is implemented in UPMB  
> (programmed by
> U-Boot); all that the kernel has to do is write to the in U-Boot
> programmed location (0xe2400000) to trigger the UPMB HPI protocol.
>
>> I'd expect the driver to be exactly the same (or close to it) for
>> arch=ppc vs arch=powerpc.
>
> Same here: there are a number of performance issues wrt to an older  
> 8245
> based implementation (network seems slower too) and this was not one I
> expected while switching to powerpc.

Are you comparing 8245 on arch=ppc to 83xx on arch=powerpc or 83xx in  
both cases?

>> There shouldn't be, but if you are seeing this we really should
>> figure out what's going on.
>>
>> What kernel is this on?  What processor are you using?
>
> $ cat /proc/cpuinfo
> processor       : 0
> cpu             : e300c1
> clock           : 396.000000MHz
> revision        : 1.1 (pvr 8083 0011)
> bogomips        : 131.28
> timebase        : 66000000
> platform        : BARCO834x SVC2

Hmm, we really need to put SVR in there as well (add that to the todo  
list).  Which 83xx is this?

> $ uname -a
> Linux barco 2.6.21.1-barco1 #1 PREEMPT Tue Jun 12 09:48:12 CEST  
> 2007 ppc unknown
>
> The board is based on the FreeScale SYS/EMDS reference design.
>
> Most of the HPI operations are stuff like this:
>
> static inline int8_t _hpi_set_hhwil(uint8_t b)
> {
>         volatile immap_t* im;
>
>         if(!(im = ioremap((immrbar),sizeof(struct immap)))){
>                 return -EINVAL;
>         }
>         (b)?(im->gpio[0].dat |= HHWIL):(im->gpio[0].dat &= ~HHWIL);
>         iounmap(im);
>
>         return 0;
> }
>
> static inline uint32_t __hpi_read_hpid(void)
> {
>         uint32_t returnval;
>
>         /* Program HPID */
>         _hpi_set_hcntl1(1);
>         _hpi_set_hcntl0(1);
>
>         /* first halfword */
>         _hpi_set_hhwil(0);
>         /* dummy read */
>         returnval = (((uint32_t)(*hpi_dsp))<<16);
>
>         /* delay */
>         udelay(1);
>
>         /* second halfword */
>         _hpi_set_hhwil(1);
>         /* dummy read */
>         returnval |= *hpi_dsp;
>
>         /* delay */
>         udelay(1);
>
>         return returnval;
> }
>
> The ioremap was certainly a bottleneck; and moving it to  
> initialisation
> with a global pointer got us from 60 secs back to around 1 sec, but  
> the
> a similar effect was obtained on the ppc arch with this change  
> (this was
> just making a bad situation to be hidden).

Do you sense of how many calls you make to _hpi_set_hhwil &  
__hpi_read_hpid?

I think I know why the ppc case was more efficient.

> Even after this change; the load of a streaming application was
> something of 40% on ppc and 60% on powerpc.

What's going on during the streaming?

- k

Re: 83xx GPIO/EXT int in arch/powerpc/

[Marc Leeman]

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

> Are you comparing 8245 on arch=ppc to 83xx on arch=powerpc or 83xx in  
> both cases?

No, I'm comparing ARCH=ppc and ARCH=powerpc, both on 8347E. The
comparison with a 8245 is due to the fact that this 83xx platform is a
follow up of the 8245 design.

With the 8245, we got almost a doubling of the effective processing of
data through the network by replacing the eepro100 driver with the e100
driver from intel. Since data transfer rate from the network on a 83xx
seems to be slower than the 8245/e100 combination, there might be some
driver work to do too to get the same improvement; but that's currently
just speculation on my part; I hope to have a look into that after the
summer.

> Hmm, we really need to put SVR in there as well (add that to the todo  
> list).  Which 83xx is this?

MPC8347E

> Do you sense of how many calls you make to _hpi_set_hhwil &  
> __hpi_read_hpid?

We're using a couple of GPIOs to toggle the first halfword and the
second halfword (running HPI 16-bit). Since we only have implemented
single beat accesses in the UPM, we also need to toggle between address
and data.

For every word, there are 4 similar calls; a DSP binary that is loaded
over HPI is around 400 kB, so in 500,000 order of magnitude per DSP
binary load.

During operation, HPI is used to get info from the DSPs @100-120 times per
second; just a couple of bytes though.

> I think I know why the ppc case was more efficient.

Wheee.

probably the ioremap and iounmap have something to do with it; in the
debugging version of the code, this was done for every GPIO access (cf.
supra) and there the slow down was from 3-4 secs to 1-2 mins.

> >Even after this change; the load of a streaming application was
> >something of 40% on ppc and 60% on powerpc.
> 
> What's going on during the streaming?

Data is retreived from the network (UDP, TCP, mostly UDP/multicast
though) and partially decoded (converted to elementary stream). Data is
then transferred through an FPGA (over PCI) to a DSP with DMA (pushed
from the 83xx processor). The data is mapped from userspace into kernel
in blocks of 4096kB to avoid copying.

The transfer of data is pretty straighforward:
  1. map user page into kernel
  2. grab dma channel
  3. init dma channel
  4. dma data out
  5. wait for interrupt

-- 
  greetz, marc
You'll be happy to know I have a plan.
	Crichton - Through the Looking Glass
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]