* RE: Driver - HDLC 83xx QUICC Engine??
From: Russell McGuire @ 2008-01-16 0:30 UTC (permalink / raw)
To: 'Joakim Tjernlund'; +Cc: linuxppc-embedded
In-Reply-To: <000001c857d5$6154b110$23fe1330$@tjernlund@transmode.se>
Jocke,
I'll let you know if I find any. For a starting point, I have an QE ATM
driver, that is more than likely similar in design <though no Ethernet
interface>, as it supports the QE engine, and just turns the UCC into =
ATM
mode, as opposed to HDLC mode. Would imagine the buffering, IO, =
interrupts
are similar. I am still in process of porting it up from the 82xx CPU.=20
Although HDLC how it registers itself into the kernel is a mystery to =
me, I
am having trouble finding any HDLC drivers to model this after. Know of =
any
specs? API? Etc...
-Russ
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Tuesday, January 15, 2008 4:19 PM
> To: rmcguire@videopresence.com; linuxppc-embedded@ozlabs.org
> Subject: SV: Driver - HDLC 83xx QUICC Engine??
>=20
> > -----Ursprungligt meddelande-----
> > Fr=E5n: =
linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.org] F=F6r Russell =
McGuire
> > Skickat: den 15 januari 2008 20:52
> > Till: linuxppc-embedded@ozlabs.org
> > =C4mne: Driver - HDLC 83xx QUICC Engine??
> >
> > All,
> >
> > Does anyone know of a project or existing driver for supporting HDLC =
for
> the
> >
> > MPC83xx or MPC82XX Freescale CPUs?
> >
> > Looking to run raw HDLC over various Ethernet or T1 links.
> >
> > -Russ
>=20
> Me too. Perhaps not, I will be looking at presenting a Ethernet i/f to =
the
> kernel but
> sending out HDLC frames containing the Ethernet packet. If you =
find/have
> anything
> that helps me do that, send it my way please.
>=20
> Jocke
^ permalink raw reply
* SV: Driver - HDLC 83xx QUICC Engine??
From: Joakim Tjernlund @ 2008-01-16 0:18 UTC (permalink / raw)
To: rmcguire, linuxppc-embedded
In-Reply-To: <000301c857b0$09f01a10$6405a8c0@absolut>
> -----Ursprungligt meddelande-----
> Fr=E5n: =
linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.org =
[mailto:linuxppc-embedded-
> bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.org] F=F6r Russell =
McGuire
> Skickat: den 15 januari 2008 20:52
> Till: linuxppc-embedded@ozlabs.org
> =C4mne: Driver - HDLC 83xx QUICC Engine??
>=20
> All,
>=20
> Does anyone know of a project or existing driver for supporting HDLC =
for the
>=20
> MPC83xx or MPC82XX Freescale CPUs?
>=20
> Looking to run raw HDLC over various Ethernet or T1 links.
>=20
> -Russ
Me too. Perhaps not, I will be looking at presenting a Ethernet i/f to =
the kernel but
sending out HDLC frames containing the Ethernet packet. If you find/have =
anything
that helps me do that, send it my way please.
Jocke
^ permalink raw reply
* Re: Driver - HDLC 83xx QUICC Engine??
From: Joakim Tjernlund @ 2008-01-16 0:34 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000301c857d7$0195f890$6405a8c0@absolut>
> -----Ursprungligt meddelande-----
> Fr=E5n: Russell McGuire [mailto:rmcguire@videopresence.com]
> Skickat: den 16 januari 2008 01:31
> Till: 'Joakim Tjernlund'
> Kopia: linuxppc-embedded@ozlabs.org
> =C4mne: RE: Driver - HDLC 83xx QUICC Engine??
>=20
> Jocke,
>=20
> I'll let you know if I find any. For a starting point, I have an QE =
ATM
> driver, that is more than likely similar in design <though no Ethernet
> interface>, as it supports the QE engine, and just turns the UCC into =
ATM
> mode, as opposed to HDLC mode. Would imagine the buffering, IO, =
interrupts
> are similar. I am still in process of porting it up from the 82xx CPU.
>=20
> Although HDLC how it registers itself into the kernel is a mystery to =
me, I
> am having trouble finding any HDLC drivers to model this after. Know =
of any
> specs? API? Etc...
Sorry but I don't know. Luckily for me I don't have too either.
Jocke
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: David Gibson @ 2008-01-16 0:46 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200380965-10245-1-git-send-email-sr@denx.de>
On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
> The patch adds the Haleakala dts. The Haleakala is a stripped down
> version of the Kilauea (405EX) with only one EMAC and only one PCIe
> interface.
[snip]
> + IIC0: i2c@ef600400 {
> + device_type = "i2c";
No device_type here.
> + compatible = "ibm,iic-405exr", "ibm,iic";
> + reg = <ef600400 14>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <2 4>;
> + };
> +
> + IIC1: i2c@ef600500 {
> + device_type = "i2c";
Or here.
> + compatible = "ibm,iic-405exr", "ibm,iic";
> + reg = <ef600500 14>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <7 4>;
> + };
> +
> +
> + RGMII0: emac-rgmii@ef600b00 {
> + device_type = "rgmii-interface";
And especially not here.
> + compatible = "ibm,rgmii-405exr", "ibm,rgmii";
> + reg = <ef600b00 104>;
> + has-mdio;
> + };
[snip]
> + PCIE0: pciex@0a0000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
> + primary;
> + port = <0>; /* port number */
> + reg = <a0000000 20000000 /* Config space access */
> + ef000000 00001000>; /* Registers */
> + dcr-reg = <040 020>;
> + sdr-base = <400>;
Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
registers. *facepalm*
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-16 3:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080115165230.GB10812@ld0162-tx32.am.freescale.net>
On Tue, Jan 15, 2008 at 10:52:30AM -0600, Scott Wood wrote:
> On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> > On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
> > > ft_get_next_node() enumerates children of a given node.
> > > ft_get_next_prop() enumerates propreties of a given node.
> > >
> > > ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
> > > than a node offset and property name; it is primarily intended for use
> > > with ft_get_next_prop().
> >
> > Urg... this kind of serves me right for not getting my act together on
> > iterator functions yet. I really don't like this approach much. I'll
> > see if I can come up with something I prefer this afternoon.
>
> OK.
>
> > The biggest thing I dislike is that I've deliberately avoided having
> > any offsets-to-properties exposed to the library user. That's because
> > the whole offsets change when you write the tree problem is worse for
> > properties than nodes (in that likely idiomatic uses will be bitten by
> > changes in property offsets).
>
> We can drop the property iteration for now; I wrote it for an attempt at
> node merging which I postponed.
Heh.. and I spent most of yesterday working on a counter-proposal for
property iteration. Oh well, let's leave this for now and look at the
node iteration first.
> > > + if (depth != 0)
> > > + return -FDT_ERR_BADSTRUCTURE;
> >
> > I think this should be FDT_ERR_TRUNCATED.
>
> I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
> we hit FDT_END in an inappropriate context.
Well, TRUNCATED is valid for either situation, and fdt_next_tag() also
returns FDT_END if it reaches totalsize.
> > > + return -FDT_ERR_NOTFOUND;
> >
> > In fact, so should this. This function should never actually reach
> > the FDT_END tag.
>
> No, it's valid if you're iterating over all nodes (node -1, depth
> -1).
Uh.. yeah, I guess so.
> > > +#define FDT_ERR_BADDEPTH 8
> > > + /* FDT_ERR_BADDEPTH: Function was passed a negative
> > > + * (or otherwise invalid) depth. */
> >
> > You've added this error code, but you don't actually return it
> > anywhere...
>
> Oops, it must have been from the aforementioned node merging code, and I
> thought it was from fdt_get_next_node when splitting things up.
Ok.
> > This description is incorrect - you've copied the fdt_getprop()
> > description and forgotten to update it.
>
> /me hides in shame
:)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
From: Kumar Gala @ 2008-01-16 4:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080116000915.GA4283@localhost.localdomain>
On Jan 15, 2008, at 6:09 PM, David Gibson wrote:
> On Tue, Jan 15, 2008 at 09:35:20AM -0600, Kumar Gala wrote:
>> Add the ability to set the mac address given the alias for the
>> device.
>> Removes the need for having a linux,network-index property.
>>
>> ---
>>
>> in my git tree.
>
> Missing a Signed-off-by. Otherwise looks good.
I'm not putting signed-off-by's on patches posted the list just for
review.. thus they will not get picked up by anyone :)
- k
^ permalink raw reply
* RE: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
From: Aggrwal Poonam @ 2008-01-16 4:20 UTC (permalink / raw)
To: Andrew Morton
Cc: kumar.gala, Phillips Kim, Barkowski Michael, netdev, linux-kernel,
rubini, linuxppc-dev, Kalra Ashish, Cutler Richard
In-Reply-To: <20080114131441.878979d2.akpm@linux-foundation.org>
Thanks Morton for your comments,
I shall incorporate them and reesnd the patch.
With Regards
Poonam=20
=20
=20
-----Original Message-----
From: Andrew Morton [mailto:akpm@linux-foundation.org]=20
Sent: Tuesday, January 15, 2008 2:45 AM
To: Aggrwal Poonam
Cc: rubini@vision.unipv.it; linux-kernel@vger.kernel.org;
linuxppc-dev@ozlabs.org; netdev@vger.kernel.org;
kumar.gala@freescale.co; Barkowski Michael; Phillips Kim; Kalra Ashish;
Cutler Richard
Subject: Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx
platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <b10812@freescale.com> wrote:
> From: Poonam Aggrwal <b10812@freescale.com>
>=20
> The UCC TDM driver basically multiplexes and demultiplexes data from=20
> different channels. It can interface with for example SLIC kind of=20
> devices to receive TDM data demultiplex it and send to upper=20
> applications. At the transmit end it receives data for different=20
> channels multiplexes it and sends them on the TDM channel. It=20
> internally uses TSA( Time Slot Assigner) which does multiplexing and=20
> demultiplexing, UCC to perform SDMA between host buffers and the TSA,
CMX to connect TSA to UCC.
>=20
> This driver will run on MPC8323E-RDB platforms.
>=20
> ...
>
> +#define PREV_PHASE(x) ((x =3D=3D 0) ? MAX_PHASE : (x - 1)) #define=20
> +NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info =3D {
> + .uf_info =3D {
> + .tsa =3D 1,
> + .cdp =3D 1,
> + .cds =3D 1,
> + .ctsp =3D 1,
> + .ctss =3D 1,
> + .revd =3D 1,
> + .urfs =3D 0x128,
> + .utfs =3D 0x128,
> + .utfet =3D 0,
> + .utftt =3D 0x128,
> + .ufpt =3D 256,
> + .ttx_trx =3D
UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc =3D UCC_FAST_TX_ENCODING_NRZ,
> + .renc =3D UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc =3D UCC_FAST_16_BIT_CRC,
> + .synl =3D UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy =3D 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c) { #if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts =3D tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i =3D 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i =3D 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log) {
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp =3D log ^ 0xFF;
> + sign =3D (temp & 0x80) >> 7;
> + segment =3D (temp & 0x70) >> 4;
> + quant =3D temp & 0x0F;
> + quant <<=3D 1;
> + quant +=3D 33;
> + quant <<=3D segment;
> + if (sign)
> + val =3D 33 - quant;
> + else
> + val =3D quant - 33;
> +
> + val *=3D 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear) {
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret =3D 0;
> + if (linear >=3D 0)
> + linear =3D (linear >> 2);
> + else
> + linear =3D (0xc000 | (linear >> 2));
> +
> + absol =3D abs(linear) + 33;
> + temp =3D absol;
> + sign =3D (linear >=3D 0) ? 1 : 0;
> + for (i =3D 0; i < 16; i++) {
> + output =3D temp & 0x8000;
> + if (output)
> + break;
> + temp <<=3D 1;
> + }
> + segment =3D 11 - i;
> + quant =3D (absol >> segment) & 0x0F;
> + segment--;
> + segment <<=3D 4;
> + output =3D segment + quant;
> + if (absol > 8191)
> + output =3D 0x7F;
> + if (sign)
> + ret ^=3D 0xFF;
> + else
> + ret ^=3D 0x7F;
> + return ret;
> +}
hrm, how many copies of ulaw/alaw conversion functions do we need in the
tree before someone writes a library function for it?
> + out_be16(&rx_bd->status, bd_status);
> + out_be32(&rx_bd->buf,
> + tdm_c->dma_input_addr + i * SAMPLE_DEPTH * act_num_ts);
> +
> + bd_status =3D (u16) ((T_R | T_CM | T_W) >> 16);
> + bd_len =3D SAMPLE_DEPTH * act_num_ts;
> + out_be16(&tx_bd->length, bd_len);
> + out_be16(&tx_bd->status, bd_status);
> + out_be32(&tx_bd->buf,
> + tdm_c->dma_output_addr + i * SAMPLE_DEPTH *
act_num_ts);
> +
> + config_si(tdm_c);
> +
> + setbits32(&qe_immr->ic.qimr, (0x80000000 >> ucc));
The compiler treats 0xNNN constants as unsigned so this works OK. I'd
have put a UL on the end of the constant to be sure ;)
> +static int tdm_start(struct tdm_ctrl *tdm_c) {
> + if (request_irq(tdm_c->ut_info->uf_info.irq, tdm_isr,
> + 0, "tdm", tdm_c)) {
> + printk(KERN_ERR "%s: request_irq for tdm_isr failed\n",
> + __FUNCTION__);
> + return -ENODEV;
> + }
> +
> + ucc_fast_enable(tdm_c->uf_private, COMM_DIR_RX | COMM_DIR_TX);
> +
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pr_info("%s 8-bit u-law compressed mode active\n",
__FUNCTION__);=20
> +#else
> + pr_info("%s 16-bit linear pcm mode active with"
> + " slots 0 & 2\n", __FUNCTION__);
> +#endif
Is this the sort of thing which should be controlled at compile-time?
I'd have thought that a runtime control would be more appropriate (a
sysfs knob or a module parameter). Or just work it out automagically?
> + dump_siram(tdm_c);
> + dump_ucc(tdm_c);
> +
> + setbits8(&(qe_immr->si1.siglmr1_h), (0x1 << tdm_c->tdm_port));
> + pr_info("%s UCC based TDM enabled\n", __FUNCTION__);
> +
> + return 0;
> +}
>
> ...
>
> +static void tdm_read(u32 driver_handle, short chn_id, short
*pcm_buffer,
> + short
len)
> +{
> + int i;
> + u32 phase_rx;
> + /* point to where to start for the current phase data processing
*/
> + u32 temp_rx;
> +
> + struct tdm_ctrl *tdm_c =3D (struct tdm_ctrl *)(driver_handle);
eek. What are we doing here, casting a 32-bit quantity to a kernel
pointer?
a) Seems to rule out ever using this driver on a 64-bit system
b) It's generally suspicious and indicates that some rethinking is
needed.
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + u8 *input_tdm_buffer =3D tdm_c->tdm_input_data;
> +
> +#else
> + u16 *input_tdm_buffer =3D
> + (u16 *)tdm_c->tdm_input_data;
> +
> +#endif
> + phase_rx =3D tdm_c->phase_rx;
> + phase_rx =3D PREV_PHASE(phase_rx);
> +
> + temp_rx =3D phase_rx * SAMPLE_DEPTH * EFF_ACTIVE_CH;
> +
> +#if defined(UCC_CACHE_SNOOPING_DISABLED)
> + flush_dcache_range((size_t) &input_tdm_buffer[temp_rx],
> + (size_t) &input_tdm_buffer[temp_rx +
> + SAMPLE_DEPTH *
ACTIVE_CH]);
> +#endif
Again, is it appropriate that this behaviour be determined at
compile-time?
This is very user- and packager- and distributor-unfriendly.
> + for (i =3D 0; i < len; i++) {
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pcm_buffer[i] =3D
> + ulaw2int(input_tdm_buffer[i * EFF_ACTIVE_CH +
> + temp_rx + chn_id]);
> +#else
> + pcm_buffer[i] =3D
> + input_tdm_buffer[i * EFF_ACTIVE_CH + temp_rx +
chn_id]; #endif
> +
> + }
> +
> +}
> +
> +static int ucc_tdm_probe(struct of_device *ofdev,
> + const struct of_device_id *match) {
> + struct device_node *np =3D ofdev->node;
> + struct resource res;
> + const unsigned int *prop;
> + u32 ucc_num, device_num, err, ret =3D 0;
> + struct device_node *np_tmp =3D NULL;
> + dma_addr_t physaddr;
> + void *tdm_buff;
> + struct ucc_tdm_info *ut_info;
> +
> + prop =3D of_get_property(np, "device-id", NULL);
> + ucc_num =3D *prop - 1;
> + if ((ucc_num < 0) || (ucc_num > 7))
> + return -ENODEV;
> +
> + ut_info =3D &utdm_info[ucc_num];
> + if (ut_info =3D=3D NULL) {
> + printk(KERN_ERR "additional data missing\n");
> + return -ENODEV;
> + }
> + if (ut_info->ucc_busy) {
> + printk(KERN_ERR "UCC in use by another TDM driver
instance\n");
> + return -EBUSY;
> + }
> +
> + ut_info->ucc_busy =3D 1;
> + tdm_ctrl[num_tdm_devices++] =3D
> + kzalloc(sizeof(struct tdm_ctrl), GFP_KERNEL);
Shouldn't this check for (num_tdm_devices > MAX_NUM_TDM_DEVICES))?
> + if (!tdm_ctrl[num_tdm_devices - 1]) {
> + printk(KERN_ERR "%s: no memory to allocate for"
> + " tdm control structure\n", __FUNCTION__);
> + num_tdm_devices--;
> + return -ENOMEM;
> + }
> + device_num =3D num_tdm_devices - 1;
> +
> + tdm_ctrl[device_num]->device =3D &ofdev->dev;
> + tdm_ctrl[device_num]->ut_info =3D ut_info;
> +
> + tdm_ctrl[device_num]->ut_info->uf_info.ucc_num =3D ucc_num;
> +
> + prop =3D of_get_property(np, "fsl,tdm-num", NULL);
> + if (prop =3D=3D NULL) {
> + ret =3D -EINVAL;
> + goto get_property_error;
> + }
>
> ...
>
> +
> +#define SET_RX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.rx[(n)*2], (u16)(val))
> +
> +#define SET_TX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.tx[(n)*2], (u16)(val))
I don't think there's anything which requires that these be imlemented
in the preprocessor?
> +struct tdm_cfg {
> + u8 com_pin; /* Common receive and transmit pins
> + * 0 =3D separate pins
> + * 1 =3D common pins
> + */
> +
> + u8 fr_sync_level; /* SLx bit Frame Sync Polarity
> + * 0 =3D L1R/TSYNC active logic "1"
> + * 1 =3D L1R/TSYNC active logic "0"
> + */
> +
> + u8 clk_edge; /* CEx bit Tx Rx Clock Edge
> + * 0 =3D TX data on rising edge of clock
> + * RX data on falling edge
> + * 1 =3D TX data on falling edge of clock
> + * RX data on rising edge
> + */
> +
> + u8 fr_sync_edge; /* FEx bit Frame sync edge
> + * Determine when the sync pulses are
sampled
> + * 0 =3D Falling edge
> + * 1 =3D Rising edge
> + */
> +
> + u8 rx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 =3D no bit delay
> + * 01 =3D 1 bit delay
> + * 10 =3D 2 bit delay
> + * 11 =3D 3 bit delay
> + */
> +
> + u8 tx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 =3D no bit delay
> + * 01 =3D 1 bit delay
> + * 10 =3D 2 bit delay
> + * 11 =3D 3 bit delay
> + */
> +
> + u8 active_num_ts; /* Number of active time slots in TDM
> + * assume same active Rx/Tx time slots
> + */
> +};
Nice commenting.
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Paul Mackerras @ 2008-01-16 4:21 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C2FB.7020105@austin.ibm.com>
Manish Ahuja writes:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
The main problem I see here is that if this option is turned on, the
kernel now has only 256MB of memory from early boot until
subsys_initcalls are done -- on any machine, and whether or not there
is actually a dump. That means, for instance, that a machine running
bare-metal (such as a G5) might not be able to allocate the hash table
for the MMU. Also, any allocations made during that time won't be
able to be node-local.
So it will be necessary to read the flattened device tree early on to
see whether or not there is a dump, so that we don't reserve most of
memory in the cases where there isn't a dump.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] 8xx: Analogue & Micro Adder875 board support.
From: Stephen Rothwell @ 2008-01-16 4:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080115233045.GA21002@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
Hi Scott,
On Tue, 15 Jan 2008 17:30:45 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> +static __initdata const struct cpm_pin adder875_pins[] = {
Sorry, but you can't have both const and __inittdata. The section
attributes that each use conflict. So just make it __initdata.
> +static __initdata const struct of_device_id __initdata of_bus_ids[] = {
Same here.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mpc82xx: Embedded Planet EP8248E support
From: Stephen Rothwell @ 2008-01-16 4:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080115233047.GB21002@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
Hi Scott,
On Tue, 15 Jan 2008 17:30:47 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/82xx/ep8248e.c
> +static __initdata const struct cpm_pin ep8248e_pins[] = {
Again, const doesn't mix with __initdata so just use __initdata.
> +static __initdata const struct of_device_id of_bus_ids[] = {
Here as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-16 4:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <478D450A.8060802@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
On Tue, 15 Jan 2008 17:43:06 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> Stephen Rothwell wrote:
> >> + nr_parts = 0;
> >> + for (pp = node->child; pp; pp = pp->sibling)
> >
> > for_each_child_of_node(node, pp)
>
> "for_each_child_of_node" is only in Paul's tree, but this has to go via mtd.
>
> Plus, I'm just moving the code; it's not new.
OK, we can change it later.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add of_find_matching_node() helper function
From: Stephen Rothwell @ 2008-01-16 4:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18317.19252.530009.495865@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Wed, 16 Jan 2008 11:09:24 +1100 Paul Mackerras <paulus@samba.org> wrote:
>
> Grant Likely writes:
>
> > Any comments/concerns on this patch?
>
> I'm about to throw it into my tree.
Fine by me.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 5:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080116004642.GD4283@localhost.localdomain>
On Wednesday 16 January 2008, David Gibson wrote:
> On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
> > The patch adds the Haleakala dts. The Haleakala is a stripped down
> > version of the Kilauea (405EX) with only one EMAC and only one PCIe
> > interface.
>
> [snip]
>
> > + IIC0: i2c@ef600400 {
> > + device_type = "i2c";
>
> No device_type here.
Ok.
> > + compatible = "ibm,iic-405exr", "ibm,iic";
> > + reg = <ef600400 14>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <2 4>;
> > + };
> > +
> > + IIC1: i2c@ef600500 {
> > + device_type = "i2c";
>
> Or here.
Ok.
> > + compatible = "ibm,iic-405exr", "ibm,iic";
> > + reg = <ef600500 14>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <7 4>;
> > + };
> > +
> > +
> > + RGMII0: emac-rgmii@ef600b00 {
> > + device_type = "rgmii-interface";
>
> And especially not here.
Ok.
Your comments are valid for some of the other 4xx dts files too. Should I
create a patch that removes these device-types there too?
> > + compatible = "ibm,rgmii-405exr", "ibm,rgmii";
> > + reg = <ef600b00 104>;
> > + has-mdio;
> > + };
>
> [snip]
>
> > + PCIE0: pciex@0a0000000 {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
> > + reg = <a0000000 20000000 /* Config space access */
> > + ef000000 00001000>; /* Registers */
> > + dcr-reg = <040 020>;
> > + sdr-base = <400>;
>
> Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
> registers. *facepalm*
Yep. PCIe on 4xx has DCR, SDR *and* MMIO registers.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH v4 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2008-01-16 5:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <20080115164022.GA24590@lixom.net>
On Tue, Jan 15, 2008 at 10:40:22AM -0600, Olof Johansson wrote:
> Hi,
>
> I've applied 1/3 and 2/3 together with my electra_ide move to pasemi.git
> for-2.6.25, and will ask Paul to pull that. Kumar said he'd take 3/3.
>
> I also added the const to the match table as spotted by Stephen.
Great news, thank you!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 5:34 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080115200019.GA2598@gate.ebshome.net>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
> change MTU you cannot get big frames.
Ahhh, I must have been blind. Thanks for pointing out.
I'll send new patches for ibm_emac and ibm_newemac in a short while.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: David Gibson @ 2008-01-16 5:52 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801160604.56766.sr@denx.de>
On Wed, Jan 16, 2008 at 06:04:56AM +0100, Stefan Roese wrote:
> On Wednesday 16 January 2008, David Gibson wrote:
> > On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
[snip]
> > > + RGMII0: emac-rgmii@ef600b00 {
> > > + device_type = "rgmii-interface";
> >
> > And especially not here.
>
> Ok.
>
> Your comments are valid for some of the other 4xx dts files too. Should I
> create a patch that removes these device-types there too?
Yes please :).
[snip]
> > Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
> > registers. *facepalm*
>
> Yep. PCIe on 4xx has DCR, SDR *and* MMIO registers.
Ungh.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* MPIC ISU
From: vb @ 2008-01-16 6:03 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
I am trying to write a BSP for an 8245 based device. One thing which
really gets me puzzled is the 'ISU' facility in
arch/powerpc/sysdev/mpic.c, there is also a notion of ISU-less
platforms, etc. I looked through the chip's programmer's reference,
even read the original AMD/Cypress OpenPIC specification - not a clue.
What is it, at the very least - what does ISU stand for?
I would really appreciate any hints,
thank you in advance,
/vb
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Vitaly Bordug @ 2008-01-16 6:16 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1200439502.3618.26.camel@neuromancer.mindspace>
On Tue, 15 Jan 2008 23:25:02 +0000
Bryan O'Donoghue wrote:
> Greetings Scott.
>
> I've tried both of the procedures you've outlined on the Adder875 with
> the patches supplied against the paulus git tree to no avail.
>
> Pass #1 :
>
> Doing it safe with cuImage.8xx
>
[...]
> => bootm 0x400000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1032266 Bytes = 1008.1 kB
> Load Address: 00400000
> Entry Point: 00400554
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> I haven't as yet tried to single step through the bootup process -
> but, just to say that assuming the above procedure isn't _too_ far
> wrong - the stuff posted to the list agains the tree you've
> recommended doesn't seem to work..
>
yes the sequence seems correct, so I'd check cmdline params, contents of chosen node in dts, etc to make sure stuff is being written to the proper UART with proper settings.
> If you can point out a flaw in my usage of it - that'd help alot. I
> have some code I'd love to be able to use with the Adder875+powerpc
> layer - which is why I'm interested in this patchset...
>
>
> Pass #2 :
>
> Replace step 9 with.
>
> 9. make uImage
> 10 dtc -o ../adder875-uboot.dtb -O dtb
> arch/powerpc/boot/dts/adder875-uboot.dts
>
>
> cp arch/powerpc/boot/uImage /tftpboot
> cp ../adder875-uboot.dtb /tftpboot
>
> Finally in u-boot
> => tftpboot 0x400000 uImage
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'uImage'.
> Load address: 0x400000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ###
> done
> Bytes transferred = 1009496 (f6758 hex)
> => tftpboot 0x500000 adder875-uboot.dtb
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'adder875-uboot.dtb'.
> Load address: 0x500000
> Loading: #
> done
> Bytes transferred = 3147 (c4b hex)
> => bootm 0x400000 - 0x500000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1009432 Bytes = 985.8 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x500000
>
>
> Aside from the u-boot modification of including
>
> #define CONFIG_OF_LIBFDT 1
>
> The rest is a pristine version of Yuli Barchoen's original U-Boot
> Adder stuff.
>
> The uImage + dtb seems to get a good bit further in that it seems to
> get stuck somewhere inside of some trampoline code in time.c
>
>
> (gdb) bt
> #0 0xc000ee30 in __div64_32 ()
> #1 0xc01d71f4 in time_init () at arch/powerpc/kernel/time.c:940
>
>
> I might have a go at some proper debugging tomorrow after work.
>
> If you have any suggestions as to what's going wrong or what I've not
> done right I'd appreciate the help.
>
following the u-boot way (which is more correct imo) you'll need to add some code that fixes up frequencies and stuff inside dtb, or you may try to hardcode those values inside dts(if you know exactly what should be there). Just adding CONFIG_*LIBFDT is not going to work.
--
Sincerely, Vitaly
^ permalink raw reply
* [libfdt] RFC: Node iterators
From: David Gibson @ 2008-01-16 6:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
Here's my counter-attempt at node iterators for libfdt. It's based on
an internal function very similar to Scott's fdt_next_node(), but the
exported interfaces are altered to be (IMO) safer and simpler.
So far, it only handles iterating across immediate children of a node,
not traversing an entire subtree. I'm still working on extending the
internals to cover that case. No property iteration as yet, either.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2008-01-16 15:06:49.000000000 +1100
+++ dtc/libfdt/fdt_ro.c 2008-01-16 16:27:55.000000000 +1100
@@ -65,7 +65,7 @@
static int nodename_eq(const void *fdt, int offset,
const char *s, int len)
{
- const char *p = fdt_offset_ptr(fdt, offset, len+1);
+ const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
if (! p)
/* short match */
@@ -104,50 +104,16 @@ int fdt_num_mem_rsv(const void *fdt)
return i;
}
-int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
const char *name, int namelen)
{
- int level = 0;
- uint32_t tag;
- int offset, nextoffset;
-
CHECK_HEADER(fdt);
- tag = fdt_next_tag(fdt, parentoffset, &nextoffset);
- if (tag != FDT_BEGIN_NODE)
- return -FDT_ERR_BADOFFSET;
-
- do {
- offset = nextoffset;
- tag = fdt_next_tag(fdt, offset, &nextoffset);
-
- switch (tag) {
- case FDT_END:
- return -FDT_ERR_TRUNCATED;
-
- case FDT_BEGIN_NODE:
- level++;
- if (level != 1)
- continue;
- if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
- /* Found it! */
- return offset;
- break;
-
- case FDT_END_NODE:
- level--;
- break;
-
- case FDT_PROP:
- case FDT_NOP:
- break;
-
- default:
- return -FDT_ERR_BADSTRUCTURE;
- }
- } while (level >= 0);
+ for_each_subnode(fdt, offset)
+ if (nodename_eq(fdt, offset, name, namelen))
+ return offset;
- return -FDT_ERR_NOTFOUND;
+ return offset;
}
int fdt_subnode_offset(const void *fdt, int parentoffset,
Index: dtc/libfdt/fdt.c
===================================================================
--- dtc.orig/libfdt/fdt.c 2008-01-16 16:26:48.000000000 +1100
+++ dtc/libfdt/fdt.c 2008-01-16 17:03:09.000000000 +1100
@@ -129,6 +129,58 @@ uint32_t fdt_next_tag(const void *fdt, i
return tag;
}
+static int _fdt_next_node(const void *fdt, int offset, int *depth)
+{
+ uint32_t tag;
+ int nextoffset;
+
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_PROP:
+ case FDT_NOP:
+ break;
+
+ case FDT_BEGIN_NODE:
+ (*depth)++;
+ if (*depth == 1)
+ return offset;
+ break;
+
+ case FDT_END_NODE:
+ (*depth)--;
+ break;
+
+ case FDT_END:
+ return -FDT_ERR_TRUNCATED;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (*depth >= 0);
+
+ return -FDT_ERR_NOTFOUND;
+}
+
+int _fdt_first_subnode(const void *fdt, int offset)
+{
+ int depth = 0;
+
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
+int _fdt_next_subnode(const void *fdt, int offset)
+{
+ int depth = 1;
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
{
int len = strlen(s) + 1;
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2008-01-16 16:27:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2008-01-16 17:06:31.000000000 +1100
@@ -131,6 +131,18 @@ static inline void *fdt_offset_ptr_w(voi
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
/**********************************************************************/
+/* Traversal functions */
+/**********************************************************************/
+
+int _fdt_first_subnode(const void *fdt, int offset);
+int _fdt_next_subnode(const void *fdt, int offset);
+
+#define for_each_subnode(fdt, offset) \
+ for ((offset) = _fdt_first_subnode((fdt), (offset)); \
+ (offset) >= 0; \
+ (offset) = _fdt_next_subnode((fdt), (offset)))
+
+/**********************************************************************/
/* General functions */
/**********************************************************************/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:10 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_emac/ibm_emac_core.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..8d1901e 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,8 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2175,8 +2168,11 @@ static int __init emac_probe(struct ocp_device *ocpdev)
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(emacdata->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:11 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280..b24bd2d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
static inline int emac_xmit_split(struct emac_instance *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2(dev, "stopped TX queue" NL);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
/* Tx lock BHs */
static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
@@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
/* Fill in the driver function table */
ndev->open = &emac_open;
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
-#endif
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(dev->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-16 7:15 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080116034939.GB5016@localhost.localdomain>
On Wed, Jan 16, 2008 at 02:49:39PM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 10:52:30AM -0600, Scott Wood wrote:
> > On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
[snip]
> > > > + if (depth != 0)
> > > > + return -FDT_ERR_BADSTRUCTURE;
> > >
> > > I think this should be FDT_ERR_TRUNCATED.
> >
> > I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
> > we hit FDT_END in an inappropriate context.
>
> Well, TRUNCATED is valid for either situation, and fdt_next_tag() also
> returns FDT_END if it reaches totalsize.
Thought I should elaborate on this a bit - I'm not sure that the
current handling of FDT_ERR_TRUNCATED is entirely correct. The
description says only when the FDT_END tag is missing, but the way
fdt_next_tag() works means we will also (for some functions, at least)
give this error when FDT_END appears without a suitable number of
FDT_END_NODE tags preceding it.
The rationale behind FDT_ERR_TRUNCATED - why it exists as a separate
code from FDT_ERR_BADSTRUCTURE - is that the read-only functions
should work more-or-less sanely on incomplete trees created by the
sequential-write functions (fdt_sw.c). FDT_ERR_TRUNCATED is supposed
to indicate that the function couldn't complete properly because the
tree is malformed, but that suitable calls to the fdt_sw functions
could complete the tree so that it's no longer malformed.
I'm not sure that either the comment describing TRUNCATED, or the code
entirely matches that rationale...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Benjamin Herrenschmidt @ 2008-01-16 7:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200467475-1663-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 08:11 +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> GigE platforms and not only the TAH equipped ones (440GX). This enables
> an MTU of 9000 instead 4080.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Jeff, please pick up for .25.
Ben.
> drivers/net/ibm_newemac/core.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..b24bd2d 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return emac_xmit_finish(dev, len);
> }
>
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> static inline int emac_xmit_split(struct emac_instance *dev, int slot,
> u32 pd, int len, int last, u16 base_ctrl)
> {
> @@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
> DBG2(dev, "stopped TX queue" NL);
> return 1;
> }
> -#else
> -# define emac_start_xmit_sg emac_start_xmit
> -#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
>
> /* Tx lock BHs */
> static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
> @@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
>
> /* Fill in the driver function table */
> ndev->open = &emac_open;
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> - if (dev->tah_dev) {
> - ndev->hard_start_xmit = &emac_start_xmit_sg;
> + if (dev->tah_dev)
> ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
> - } else
> -#endif
> - ndev->hard_start_xmit = &emac_start_xmit;
> ndev->tx_timeout = &emac_tx_timeout;
> ndev->watchdog_timeo = 5 * HZ;
> ndev->stop = &emac_close;
> @@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
> ndev->set_multicast_list = &emac_set_multicast_list;
> ndev->do_ioctl = &emac_ioctl;
> if (emac_phy_supports_gige(dev->phy_mode)) {
> + ndev->hard_start_xmit = &emac_start_xmit_sg;
> ndev->change_mtu = &emac_change_mtu;
> dev->commac.ops = &emac_commac_sg_ops;
> + } else {
> + ndev->hard_start_xmit = &emac_start_xmit;
> }
> SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
>
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 7:24 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 274 +++++++++++++++++++++++++++++++++++
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..5dd3d15
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,274 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 9:00 UTC (permalink / raw)
To: linuxppc-dev
Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
from the 4xx dts files.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/bamboo.dts | 3 ---
arch/powerpc/boot/dts/ebony.dts | 2 --
arch/powerpc/boot/dts/katmai.dts | 2 --
arch/powerpc/boot/dts/kilauea.dts | 3 ---
arch/powerpc/boot/dts/makalu.dts | 3 ---
arch/powerpc/boot/dts/rainier.dts | 4 ----
arch/powerpc/boot/dts/sequoia.dts | 4 ----
arch/powerpc/boot/dts/taishan.dts | 4 ----
8 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index 29f1a6f..7dc37c9 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -185,7 +185,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -193,7 +192,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -201,7 +199,6 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
diff --git a/arch/powerpc/boot/dts/ebony.dts b/arch/powerpc/boot/dts/ebony.dts
index f8790c4..106ef37 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -215,7 +215,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -223,7 +222,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 9bdfc0f..bc32ac7 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -187,7 +187,6 @@
};
IIC0: i2c@10000400 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000400 14>;
interrupt-parent = <&UIC0>;
@@ -195,7 +194,6 @@
};
IIC1: i2c@10000500 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 67c7ea1..8baef61 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index bdd70e4..710c011 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index d3c2ac3..f947c75 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -229,7 +229,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -237,7 +236,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -245,13 +243,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440grx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440grx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index d9046c1..276f596 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -236,7 +236,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -244,7 +243,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -252,13 +250,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440epx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 0706a4a..8278068 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -203,7 +203,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -211,7 +210,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
@@ -225,13 +223,11 @@
};
ZMII0: emac-zmii@40000780 {
- device_type = "zgmii-interface";
compatible = "ibm,zmii-440gx", "ibm,zmii";
reg = <40000780 c>;
};
RGMII0: emac-rgmii@40000790 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii";
reg = <40000790 8>;
};
--
1.5.4.rc3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox