MPC5200 PCI interrupt routing

MPC5200 PCI interrupt routing

[Juergen Beisert]

Hi,

my MPC5200 based platform has one PCI slot, with the following interrupt
routing:

PCI slot  MPC5200
 INT A     IRQ0
 INT B     IRQ1
 INT C     IRQ2
 INT D     IRQ3

In my oftree I'm using these lines to describe this routing (slot's IDSEL is
0x18)

[...]
       pci@f0000d00 {
               #interrupt-cells =3D <1>;
               #size-cells =3D <2>;
               #address-cells =3D <3>;
               device_type =3D "pci";
               compatible =3D "fsl,mpc5200b-pci","fsl,mpc5200-pci";
               reg =3D <0xf0000d00 0x100>;
               interrupt-map-mask =3D <0xf800 0x0 0x0 0x7>;
               interrupt-map =3D <0xc000 0x0 0x0 0x1 &mpc5200_pic 0x0 0x0 0=
x3
                                0xc000 0x0 0x0 0x2 &mpc5200_pic 0x1 0x1 0x3
                                0xc000 0x0 0x0 0x3 &mpc5200_pic 0x1 0x2 0x3
                                0xc000 0x0 0x0 0x4 &mpc5200_pic 0x1 0x3 0x3
                               >;
               clock-frequency =3D <0>; // From boot loader
               interrupts =3D <0x2 0x8 0x0 0x2 0x9 0x0 0x2 0xa 0x0>;
               interrupt-parent =3D <&mpc5200_pic>;
               bus-range =3D <0 0>;
               ranges =3D <0x42000000 0x0 0x80000000 0x80000000 0x0 0x20000=
000
                         0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
                         0x01000000 0x0 0x00000000 0xb0000000 0x0 0x0100000=
0>;
       };
[...]

=46irst: But /proc/interrupts states "Edge" type. From the documentation "0=
x3"
(the last number per interrupt-map-line) should be "low level", not "edge".

$ cat /proc/interrupts
           CPU0
 16:          0   MPC52xx IRQ[0-3]  Edge      uhci_hcd:usb3
 65:          0   MPC52xx IRQ[0-3]  Edge      uhci_hcd:usb4
 66:          5   MPC52xx IRQ[0-3]  Edge      ehci_hcd:usb2
131:      58585  MPC52xx Peripherals Edge      mpc52xx_psc_uart
133:          0  MPC52xx Peripherals Edge      mpc52xx-fec_ctrl
134:         34  MPC52xx Peripherals Edge      ohci_hcd:usb1
135:          0  MPC52xx Peripherals Edge      mpc52xx_ata
143:          0  MPC52xx Peripherals Edge      i2c-mpc
144:         36  MPC52xx Peripherals Edge      i2c-mpc
192:       5815  MPC52xx SDMA Edge      mpc52xx-fec_rx
193:       4512  MPC52xx SDMA Edge      mpc52xx-fec_tx
BAD:          0

Second: When I load the drivers for the uhci/ehci PCI card I get:

[...]
usb 1-1: new high speed USB device using ehci_hcd and address 2
usb 1-1: device not accepting address 2, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 5
usb 1-1: device not accepting address 5, error -110
hub 1-0:1.0: unable to enumerate USB device on port 1
usb 1-2: new high speed USB device using ehci_hcd and address 6
usb 1-2: device descriptor read/64, error -110
[...]
uhci_hcd 0000:00:18.0: Unlink after no-IRQ?  Controller is probably using t=
he wrong IRQ.
[...]

$ lspci
00:18.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Contr=
oller (rev 61)
00:18.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Contr=
oller (rev 61)
00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)

USB driver (endianess???) or oftee or hardware problem?

Anyone experience with VIA USB hardware on PowerPc?

Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: MPC5200 PCI interrupt routing

[Juergen Beisert]

On Montag, 22. September 2008, Juergen Beisert wrote:
> $ lspci
> 00:18.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc.
> VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA
> Technologies, Inc. USB 2.0 (rev 63)
>
> USB driver (endianess???) or oftee or hardware problem?

Seems more a kernel problem. With a 2.6.23.1 at least MPC5200's internal OH=
CI=20
still works (EHCI and UHCI unchecked yet). With a 2.6.26.3 also this OHCI=20
fails.

Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: MPC5200 PCI interrupt routing

[Matt Sealey]

Juergen Beisert wrote:
> Hi,
> $ lspci
> 00:18.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
> 00:18.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
> 00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
> 
> USB driver (endianess???) or oftee or hardware problem?
 >
 > Anyone experience with VIA USB hardware on PowerPc?

The USB driver should work fine, I have an Efika (MPC5200B) with that
exact USB controller and revision and it's just fine and dandy. We also
used to ship Via-based USB cards in the Pegasos Open Desktop Workstation
(using Marvell Discovery II northbridge).

The major difference here would be that PCI tree entries were created
by a real OF implementation so may have reflected some hardware better;
it is dynamically created on boot to a certain point, rather than a fixed
device tree which may contain some "errors". There seems to be a lot less
data in our tree...

I can't vouch for the correctness of your tree, though, or tell you
what might be wrong (looks fine as far as I am concerned, but what
do I know? :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: MPC5200 PCI interrupt routing

[Juergen Beisert]

Matt,

On Montag, 22. September 2008, Matt Sealey wrote:
> Juergen Beisert wrote:
> > Hi,
> > $ lspci
> > 00:18.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc.
> > VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA
> > Technologies, Inc. USB 2.0 (rev 63)
> >
> > USB driver (endianess???) or oftee or hardware problem?
> >
>  > Anyone experience with VIA USB hardware on PowerPc?
>
> The USB driver should work fine, I have an Efika (MPC5200B) with that
> exact USB controller and revision and it's just fine and dandy. We also
> used to ship Via-based USB cards in the Pegasos Open Desktop Workstation
> (using Marvell Discovery II northbridge).
>
> The major difference here would be that PCI tree entries were created
> by a real OF implementation so may have reflected some hardware better;
> it is dynamically created on boot to a certain point, rather than a fixed
> device tree which may contain some "errors". There seems to be a lot less
> data in our tree...

What Kernel do you run on your target? On my hardware a 2.6.23 still work a=
s=20
expected, but a 2.6.26 fails all the time.

Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: MPC5200 PCI interrupt routing

[Juergen Beisert]

On Dienstag, 23. September 2008, Juergen Beisert wrote:
> Matt,
>
> On Montag, 22. September 2008, Matt Sealey wrote:
> > Juergen Beisert wrote:
> > > Hi,
> > > $ lspci
> > > 00:18.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > > Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc.
> > > VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA
> > > Technologies, Inc. USB 2.0 (rev 63)
> > >
> > > USB driver (endianess???) or oftee or hardware problem?
> > >
> >  > Anyone experience with VIA USB hardware on PowerPc?
> >
> > The USB driver should work fine, I have an Efika (MPC5200B) with that
> > exact USB controller and revision and it's just fine and dandy. We also
> > used to ship Via-based USB cards in the Pegasos Open Desktop Workstation
> > (using Marvell Discovery II northbridge).
> >
> > The major difference here would be that PCI tree entries were created
> > by a real OF implementation so may have reflected some hardware better;
> > it is dynamically created on boot to a certain point, rather than a fix=
ed
> > device tree which may contain some "errors". There seems to be a lot le=
ss
> > data in our tree...
>
> What Kernel do you run on your target? On my hardware a 2.6.23 still work
> as expected, but a 2.6.26 fails all the time.

One should enable the internal USB clock. If done, it works... In 2.6.23 is=
=20
was done in mpc52xx_common.c. It was removed in 2.6.24.

Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: MPC5200 PCI interrupt routing

[Grant Likely]

On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > What Kernel do you run on your target? On my hardware a 2.6.23 still work
> > as expected, but a 2.6.26 fails all the time.
> 
> One should enable the internal USB clock. If done, it works... In 2.6.23 is 
> was done in mpc52xx_common.c. It was removed in 2.6.24.

It was removed because some 5200 platform do not use USB and should not
enable the internal clock.  In general, it is not the kernel's job to configure
clocking and pin usage on the chip.  Instead, it should be set correctly
at power up by U-Boot.

However, if firmware *cannot* be changed, there is a workaround.
You can create a new platform specific board support file in
arch/powerpc/platforms/52xx/ that matches against your specific board
and performs the needed fixups.  An example of this is lite5200.c.  Many
lite5200 boards have older versions of U-Boot installed which does not
correctly configure clocks or port-config.  So, lite5200.c matches to
the board instead of mpc5200_simple.c so that the board specific fixups
can be performed easily.  You should do the same for your board.

g.

Re: MPC5200 PCI interrupt routing

[Benjamin Herrenschmidt]

On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > What Kernel do you run on your target? On my hardware a 2.6.23 still work
> > > as expected, but a 2.6.26 fails all the time.
> > 
> > One should enable the internal USB clock. If done, it works... In 2.6.23 is 
> > was done in mpc52xx_common.c. It was removed in 2.6.24.
> 
> It was removed because some 5200 platform do not use USB and should not
> enable the internal clock.  In general, it is not the kernel's job to configure
> clocking and pin usage on the chip.  Instead, it should be set correctly
> at power up by U-Boot.

Or by the USB host driver :-)

> However, if firmware *cannot* be changed, there is a workaround.
> You can create a new platform specific board support file in
> arch/powerpc/platforms/52xx/ that matches against your specific board
> and performs the needed fixups.  An example of this is lite5200.c.  Many
> lite5200 boards have older versions of U-Boot installed which does not
> correctly configure clocks or port-config.  So, lite5200.c matches to
> the board instead of mpc5200_simple.c so that the board specific fixups
> can be performed easily.  You should do the same for your board.

I tend to thing that drivers should deal with their own clocks. In fact
it would be nice if one could stop the clocks while the host port is in
suspend no ?

Ben.

Re: MPC5200 PCI interrupt routing

[Jon Smirl]

On Wed, Sep 24, 2008 at 5:22 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
>> On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
>> > On Dienstag, 23. September 2008, Juergen Beisert wrote:
>> > > What Kernel do you run on your target? On my hardware a 2.6.23 still work
>> > > as expected, but a 2.6.26 fails all the time.
>> >
>> > One should enable the internal USB clock. If done, it works... In 2.6.23 is
>> > was done in mpc52xx_common.c. It was removed in 2.6.24.
>>
>> It was removed because some 5200 platform do not use USB and should not
>> enable the internal clock.  In general, it is not the kernel's job to configure
>> clocking and pin usage on the chip.  Instead, it should be set correctly
>> at power up by U-Boot.
>
> Or by the USB host driver :-)
>
>> However, if firmware *cannot* be changed, there is a workaround.
>> You can create a new platform specific board support file in
>> arch/powerpc/platforms/52xx/ that matches against your specific board
>> and performs the needed fixups.  An example of this is lite5200.c.  Many
>> lite5200 boards have older versions of U-Boot installed which does not
>> correctly configure clocks or port-config.  So, lite5200.c matches to
>> the board instead of mpc5200_simple.c so that the board specific fixups
>> can be performed easily.  You should do the same for your board.
>
> I tend to thing that drivers should deal with their own clocks. In fact
> it would be nice if one could stop the clocks while the host port is in
> suspend no ?

There's a nice skeleton in arch/powerpc/kernel/clock.c for tracking
who is using a clock and disabling it when not in use. Nobody is using
it on PowerPC. It is used all over the place on ARM.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: MPC5200 PCI interrupt routing

[Juergen Beisert]

Benjamin,

On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > > What Kernel do you run on your target? On my hardware a 2.6.23 still
> > > > work as expected, but a 2.6.26 fails all the time.
> > >
> > > One should enable the internal USB clock. If done, it works... In
> > > 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24.
> >
> > It was removed because some 5200 platform do not use USB and should not
> > enable the internal clock.  In general, it is not the kernel's job to
> > configure clocking and pin usage on the chip.  Instead, it should be set
> > correctly at power up by U-Boot.
>
> Or by the USB host driver :-)

But how to deal with platform specific things like (in this case) unknown=20
external clock or usage of the internal clock generator (=3D how to setup t=
he=20
frequency divider)?

> > However, if firmware *cannot* be changed, there is a workaround.
> > You can create a new platform specific board support file in
> > arch/powerpc/platforms/52xx/ that matches against your specific board
> > and performs the needed fixups.  An example of this is lite5200.c.  Many
> > lite5200 boards have older versions of U-Boot installed which does not
> > correctly configure clocks or port-config.  So, lite5200.c matches to
> > the board instead of mpc5200_simple.c so that the board specific fixups
> > can be performed easily.  You should do the same for your board.
>
> I tend to thing that drivers should deal with their own clocks.

ACK. But only to switch them on and off. Not to configure them.

> In fact it would be nice if one could stop the clocks while the host port=
 is
> in suspend no ?

ACK.

Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: MPC5200 PCI interrupt routing

[Benjamin Herrenschmidt]

> But how to deal with platform specific things like (in this case) unknown 
> external clock or usage of the internal clock generator (= how to setup the 
> frequency divider)?

You can always use the platform feature hacks like I do on powermac but
we should definitely find something better. Maybe some hook in the OF
wrapper ?

Ben.

Re: MPC5200 PCI interrupt routing

[Grant Likely]

On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote:
> Benjamin,
> 
> On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > > > What Kernel do you run on your target? On my hardware a 2.6.23 still
> > > > > work as expected, but a 2.6.26 fails all the time.
> > > >
> > > > One should enable the internal USB clock. If done, it works... In
> > > > 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24.
> > >
> > > It was removed because some 5200 platform do not use USB and should not
> > > enable the internal clock.  In general, it is not the kernel's job to
> > > configure clocking and pin usage on the chip.  Instead, it should be set
> > > correctly at power up by U-Boot.
> >
> > Or by the USB host driver :-)
> 
> But how to deal with platform specific things like (in this case) unknown 
> external clock or usage of the internal clock generator (= how to setup the 
> frequency divider)?

The external clock would need to be encoded in the device tree.

Internal clock would need to read/detect the CDM config and make a
decision based on that.  Certainly possible, but I just don't think that
it is really important.  (And even if it is, I think it should be done
in common platform setup code, not the driver, because it is very
MPC5200 SoC specific).

g.

Re: MPC5200 PCI interrupt routing

[Jon Smirl]

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

On Thu, Sep 25, 2008 at 12:57 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote:
>> Benjamin,
>>
>> On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
>> > On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
>> > > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
>> > > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
>> > > > > What Kernel do you run on your target? On my hardware a 2.6.23 still
>> > > > > work as expected, but a 2.6.26 fails all the time.
>> > > >
>> > > > One should enable the internal USB clock. If done, it works... In
>> > > > 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24.
>> > >
>> > > It was removed because some 5200 platform do not use USB and should not
>> > > enable the internal clock.  In general, it is not the kernel's job to
>> > > configure clocking and pin usage on the chip.  Instead, it should be set
>> > > correctly at power up by U-Boot.

I got the attached diagram from Freescale on how to program the
divider. It's not in the user manual.

Freescale is recommending a 33.333Mhz crystal for the mpc5200 now. If
you use 33.3333Mhz you won't be able to set a 48Mhz internal clock.
Closest you can get is 48.4848Mhz.  Sticking with a 33Mhz crystal
allow an accurate 48Mhz clock. Clocking USB at the wrong clock rate
will make some devices not function or get errors.

The new mpc5200 datasheet has removed the option of using a 16x
multiplier on a 33Mhz crystal and running the core at 528Mhz. The new
datasheet only allows up to 400Mhz for the core. Anyone know what is
going on?

-- 
Jon Smirl
jonsmirl@gmail.com

[-- Attachment #2: fractinal_div.pdf --]
[-- Type: application/pdf, Size: 8383 bytes --]

Re: MPC5200 PCI interrupt routing

[Grant Likely]

On Thu, Sep 25, 2008 at 12:02 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> The new mpc5200 datasheet has removed the option of using a 16x
> multiplier on a 33Mhz crystal and running the core at 528Mhz. The new
> datasheet only allows up to 400Mhz for the core. Anyone know what is
> going on?

You mean other than the 5200b being a slighly dodgy chip to work with?

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: MPC5200 PCI interrupt routing

[Grant Likely]

On Thu, Sep 25, 2008 at 07:22:25AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > > What Kernel do you run on your target? On my hardware a 2.6.23 still work
> > > > as expected, but a 2.6.26 fails all the time.
> > > 
> > > One should enable the internal USB clock. If done, it works... In 2.6.23 is 
> > > was done in mpc52xx_common.c. It was removed in 2.6.24.
> > 
> > It was removed because some 5200 platform do not use USB and should not
> > enable the internal clock.  In general, it is not the kernel's job to configure
> > clocking and pin usage on the chip.  Instead, it should be set correctly
> > at power up by U-Boot.
> 
> Or by the USB host driver :-)

I hadn't really wanted to go down this route because the calculation of
the clock, or the decision to use an external clock or calculate an
internal clock is very board specific.  I'll need to take another look
to decide if it is reasonable to encode it into the device tree.

> I tend to thing that drivers should deal with their own clocks. In fact
> it would be nice if one could stop the clocks while the host port is in
> suspend no ?

Yeah, but in this case the clock can't actually be turned off.  It's
just a select bit between internal or external clock and a calculation
value on the divider.  Since it's a one-time board level setup
config in a big block of shared chip level registers I'd rather just
leave it in the domain of firmware.

g.

Re: MPC5200 PCI interrupt routing

[Benjamin Herrenschmidt]

> I hadn't really wanted to go down this route because the calculation of
> the clock, or the decision to use an external clock or calculate an
> internal clock is very board specific.  I'll need to take another look
> to decide if it is reasonable to encode it into the device tree.

Could be done using the feature call mechanism that I have for
powermac... though using a proper clock framework might be better in the
long run.

> > I tend to thing that drivers should deal with their own clocks. In fact
> > it would be nice if one could stop the clocks while the host port is in
> > suspend no ?
> 
> Yeah, but in this case the clock can't actually be turned off.  It's
> just a select bit between internal or external clock and a calculation
> value on the divider.  Since it's a one-time board level setup
> config in a big block of shared chip level registers I'd rather just
> leave it in the domain of firmware.

Ah ok, makes more sense to keep it there then, or in platform init.

Ben.