* Re: [PATCH] [POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
From: David Gibson @ 2008-01-16 0:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801150934390.29314@blarg.am.freescale.net>
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.
--
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] Add of_find_matching_node() helper function
From: Paul Mackerras @ 2008-01-16 0:09 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <fa686aa40801150709s31a1fc6eg751ecdc209a113d6@mail.gmail.com>
Grant Likely writes:
> Any comments/concerns on this patch?
I'm about to throw it into my tree.
Paul.
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
From: David Gibson @ 2008-01-16 0:22 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20080115190806.GD26853@mag.az.mvista.com>
On Tue, Jan 15, 2008 at 12:08:06PM -0700, Mark A. Greer wrote:
> On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> > On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > > From: Mark A. Greer <mgreer@mvista.com>
>
> Hi David. Thanks for the review.
>
> > > Add DTS file for the Emerson Katana 750i & 752i platforms.
> >
> > [snip]
> > > +/dts-v1/;
> > > +
> > > +/ {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "Katana-75xi"; /* Default */
> > > + compatible = "emerson,katana-750i";
> > > + coherency-off;
> >
> > Where is this flag used from?
>
> Its used in the bootwrapper if & when you use the mv64x60 code to setup
> some of the windows to the I/O ctlrs. This port does use that code
> (because firmware doesn't do it properly) so I need the flag.
Hrm.. ok. I'm just wondering if a new flag is really the right
approach for this, or whether you should be basing the setup off the
compatible property, either for the board or for the main bridge.
> > > + mv64x60@f8100000 { /* Marvell Discovery */
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "mv64360"; /* Default */
> > > + compatible = "marvell,mv64360";
> > > + clock-frequency = <133333333>;
> > > + hs_reg_valid;
> > > + reg = <0xf8100000 0x00010000>;
> > > + virtual-reg = <0xf8100000>;
> >
> > You seem to have virtual-reg properties on a *lot* of nodes, are they
> > really necessary?
>
> Actually, not all of them for this board. I copied them from prpmc2800
> which does need all the ones that are there. I'l remove the ones that
> aren't used.
Ok, good.
> > virtual-reg should be used *only* for things which
> > you need to access very early in the bootwrapper. Usually that's only
> > the serial port for the console. Come to that, the CPU is a 750 which
> > has a real mode, so it seems dubious that you would need any
> > virtual-reg values at all.
>
> Well, this came from a discussion about a year ago when we agreed that
> this is how it should be done. Just because MSR[IR,DR] can be cleared
> doesn't mean that they are cleared when the firmware jumps to the
> bootwraper (for all possible firmwares that are out there).
>
> To be able to eliminate virtual-reg, we'd have to add "mmu_off" code to
> the bootwrapper which isn't hard but its already in the kernel (for
> 32-bit anyway). So why duplicate?
Ok, that's a good enough reason for me.
> I'm not that attached to virtual-reg. In fact, I'd be happy to get rid
> of it but only if we can be sure it doesn't cause more mess down the
> road.
>
> > [snip]
> > > + flash@e8000000 {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + compatible = "cfi-flash";
> > > + bank-width = <4>;
> > > + device-width = <2>;
> > > + reg = <0xe8000000 0x04000000>;
> > > + monitor@0 {
> > > + label = "Monitor";
> >
> > If you're using the "label" property, it would be normal to name the
> > nodes simply "partition@address".
>
> I'm using the partition names that were used in the equivalent code
> under arch/ppc. I'm trying to keep things looking the same as they used
> to as much as possible. Besides, I don't see any others doing it that
> way.
My point is that the partition code uses either "label" (if present)
or the node name for the partition name. If label properties are
present, the node name is redundant information, so it seems more
sensible to leave something generic there.
[snip]
> > > + CUNIT: cunit@f200 {
> >
> > What is this device? It needs some sort of "compatible" value.
>
> Does it? Its a separate block of regs but its only used in the mpsc
> node--its never looked up on its own by kernel code. Do all nodes need
> "compatible" even when it'll never be used? (Just want to know.)
Hrm.. if it's really just extra mpsc registers, should it be a
seperate device, or just another range in the mpsc's "reg" property?
[snip]
> > > + mpp@f000 {
> > > + compatible = "marvell,mv64360-mpp";
> > > + reg = <0xf000 0x10>;
> > > + };
> > > +
> > > + gpp@f100 {
> > > + compatible = "marvell,mv64360-gpp";
> > > + reg = <0xf100 0x20>;
> > > + };
> >
> > What are these two devices?
>
> mpp == multi-purpose pins
> gpp == general purpose pins
>
> They're really 2 separate reg blocks and are used for any number of
> things including incoming PCI interrupts. I'm not accessing them
> currently so I can eliminate them in this dts.
Hrm. The device tree should generally describe the hardware, even if
Linux doesn't use it yet. Are these basically some sort of GPIO
interface? If so you should look at the new GPIO binding which has
been proposed.
[snip]
> > > + chosen {
> > > + bootargs = "ip=on";
> >
> > The dts file should not include a "bootargs" value. The wrapper will
> > fill that in from the kernel config.
>
> Actually, the kernel .config CONFIG_CMDLINE is only used by the kernel
> when nothing is passed in from the bootwrapper. The bootwrapper gets
> the cmdline from either bootargs or from the __builtin_cmdline section.
>
> I prefer to not rely on CONFIG_CMDLINE because it doesn't afford the
> user a chance to edit or add to the cmdline when booting. You can always
> type in the whole thing at the "Linux/PowerPC load: " prompt but I'd rather
> see what is going to be used and then edit it if I want to. With
> CONFIG_CMDLINE, it just gets used if nothing was passed in from the
> bootwrapper.
>
> That raises an issue that I've for time time (I've tried to get rid of
> __builtin_cmdline before but was unsuccessful).
>
> We currently have 3 possible sources for a default cmdline--seems like
> at least one too many.
Yes :(. I've looked at this before, though obviously I never got to
figuring out what to do about it.
> IMHO we need a way to change the default cmdline in the field so
> sysadmins can change it per board and not have to type it in every time
> they boot. /chosen/bootargs and __builtin_cmdline can both do that.
> We don't need both, though. And, since bootargs is specified by OF
> and documented in booting-without-of.txt, can we finally get rid of
> __builtin_cmdline? I'd sure like to.
>
> We can probably get rid of CONFIG_CMDLINE too since everyone uses DTs
> now and they can have a /chosen/bootargs. Anyone have a reason to keep
> CONFIG_CMDLINE around?
>
> Would you mind elaborating on why you are opposed to /chosen/bootargs?
Just because it's nasty for people to have to go in and change the dts
just to change their default command line - which they might well want
to do for things as simple as setting a default root device.
--
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: 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
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