* Re: [Linux-fbdev-devel] vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Antonino A. Daplas @ 2007-10-16 21:31 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev list
In-Reply-To: <20071016191403.GA5962@nineveh.local>
On Tue, 2007-10-16 at 15:14 -0400, Joseph Fannin wrote:
> vga16fb is an available config option on powerpc, but it won't link
> with my .config:
>
> ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
>
>
> I'm guessing this is because include/asm-powerpc/vga.h declares
> vgacon_remap_base:
>
> extern unsigned long vgacon_remap_base;
>
>
> ...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
>
> #ifdef CONFIG_VGA_CONSOLE
Perhaps #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_FB_VGA16) ?
or
bool VGA_HARDWARE
#if CONFIG_VGA_HARDWARE
unsigned long vgacon_remap_base;
EXPORT_SYMBOL(vgacon_remap_base);
#endif
and for the Kconfig entry of vgacon and vga16fb
select VGA_HARDWARE if PPC32
(or depends on (VGA_HARDWARE && PPC32))
Tony
^ permalink raw reply
* [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: Grant Likely @ 2007-10-16 21:31 UTC (permalink / raw)
To: linuxppc-dev, paulus, David Gibson, Scott Wood
In-Reply-To: <20071016213101.14117.43657.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Add the 'set -e' command to the wrapper script so that if any command
fails then the script will automatically exit
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/wrapper | 27 ++++++++++-----------------
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 8323ea4..da5fcfa 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,9 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Stop execution if any command fails
+set -e
+
# Allow for verbose output
if [ "$V" == "1" ]; then
set -x
@@ -116,7 +119,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts"
fi
if [ -z "$kernel" ]; then
@@ -287,23 +290,13 @@ ps3)
rm -f "$object/otheros.bld"
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$overlay_dest seek=$system_reset_kernel \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 1
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$overlay_dest seek=$system_reset_kernel \
+ count=$overlay_size bs=1
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$system_reset_overlay seek=$overlay_dest \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 2
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$system_reset_overlay seek=$overlay_dest \
+ count=$overlay_size bs=1
gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
;;
^ permalink raw reply related
* [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely @ 2007-10-16 21:31 UTC (permalink / raw)
To: linuxppc-dev, paulus, David Gibson, Scott Wood
From: Grant Likely <grant.likely@secretlab.ca>
Allow wrapper script to print verbose progress when the V is set in the
environment.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/wrapper | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..8323ea4 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,11 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Allow for verbose output
+if [ "$V" == "1" ]; then
+ set -x
+fi
+
# defaults
kernel=
ofile=zImage
^ permalink raw reply related
* Re: Serial init / BRG
From: Alan Bennett @ 2007-10-16 21:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47152065.9070403@freescale.com>
The lockup is only the shell. I echo from ttyCPM0 console and it
"locks" then I echo from an ssh session and the kernel messages still
output from the ttyCPM0 console.
NOTE: I found a severe issue that seems to have unlocked ttyCPM2. BUT
ttyCPM1 still hangs. (a while back, we commented out the out_be in
cpm_setbrg - oops (console debug left over))
with address / value in cpm_setbrg
echo test > /dev/ttyCPM1 # * note still hang *
CPM uart[1]:startup - port->irq 00000028
CPM uart[1]:startup - port->irq 40
cpm_setbrg:107 - brg:0 baud:9600
cpm_setbrg:108 - addr:e00119f0 value:00010140
echo test > /dev/ttyCPM2 * note doesn't hang *
CPM uart[2]:startup - port->irq 0000002b
CPM uart[2]:startup - port->irq 43
cpm_setbrg:107 - brg:3 baud:9600
cpm_setbrg:108 - addr:e00119fc value:00010140
On 10/16/07, Scott Wood <scottwood@freescale.com> wrote:
> Alan Bennett wrote:
> > I also verified that when I attempt to echo to the ports that I reach
> > the appropriate driver
> > i.e.
> > echo "hello" > /dev/ttyCPM1
> > CPM uart[1]:startup - port->irq 40
> > echo "hello" > /dev/ttyCPM2
> > CPM uart[2]:startup - port->irq 43
> > but brg's stay 0x0 and my shell's lock up something fierce.
>
> Hmm... try putting a debugging printk in cpm_setbrg with the address
> and value it's writing.
>
> Is it just the shell that locks up, or the console (i.e. can you still
> get kernel messages)?
>
> > (note: my tree is still based off of one you provided a few weeks
> > back. have the 82xx / ep8248e changes we went through been pushed
> > into linus' git tree?)
>
> It should all be in Linus's tree except the actual ep8248e file, which
> didn't make it this time around due to interdependencies on netdev.
> Note that there are some small device tree changes from the tree you're
> currently using (in particular, muram is now in a node of its own).
>
> -Scott
>
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: David Miller @ 2007-10-16 22:24 UTC (permalink / raw)
To: arnd; +Cc: Geert.Uytterhoeven, linuxppc-dev, linux-kernel, jens.axboe
In-Reply-To: <200710162150.37636.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 16 Oct 2007 21:50:35 +0200
> The one point where it is expected to have changed now is when you
> try to do these ioctls on something that is not a block device. Are
> you sure that the files you tried them on were created correctly?
Many many many programs do this exact sort of thing.
It is one of the bad aspects of moving the compat handling
down into the file ops for a specific device.
^ permalink raw reply
* Re: [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Andreas Schwab @ 2007-10-16 22:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20071016213101.14117.43657.stgit@trillian.cg.shawcable.net>
Grant Likely <grant.likely@secretlab.ca> writes:
> +# Allow for verbose output
> +if [ "$V" == "1" ]; then
The correct syntax is [ a = b ] (and the quotes around 1 are not needed,
btw.).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely @ 2007-10-16 23:08 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <jeejfuae27.fsf@sykes.suse.de>
On 10/16/07, Andreas Schwab <schwab@suse.de> wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
>
> > +# Allow for verbose output
> > +if [ "$V" == "1" ]; then
>
> The correct syntax is [ a = b ] (and the quotes around 1 are not needed,
> btw.).
heh; I guess I'm not much of a shell programmer. :-)
I'll respin this patch.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2007-10-16 23:22 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Paul,
Here is the addition of the bestcomm driver. I think this is ready to go in.
There are remaining outstanding comments; but my opinion is that they
should be addressed in subsequent patches (performance optimization
for mp5200b boards and making the sram management code a generic
interface usable by other SoC support code).
If you agree; please pull into your tree.
The following changes since commit 65a6ec0d72a07f16719e9b7a96e1c4bae044b591:
Linus Torvalds (1):
Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24
Domen Puncer (1):
[POWERPC] mpc52xx: device tree changes for FEC and MDIO
Sylvain Munaut (7):
[POWERPC] exports rheap symbol to modules
[POWERPC] rheap: Changes config mechanism
[POWERPC] mpc52xx: Update mpc52xx_psc structure with B revision changes
[POWERPC] bestcomm: core bestcomm support for Freescale MPC5200
[POWERPC] bestcomm: ATA task support
[POWERPC] bestcomm: FEC task support
[POWERPC] bestcomm: GenBD task support
arch/powerpc/Kconfig | 4 +
arch/powerpc/boot/dts/lite5200b.dts | 18 +-
arch/powerpc/lib/Makefile | 5 +-
arch/powerpc/lib/rheap.c | 15 +
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/platforms/Kconfig.cputype | 1 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/bestcomm/Kconfig | 39 ++
arch/powerpc/sysdev/bestcomm/Makefile | 14 +
arch/powerpc/sysdev/bestcomm/ata.c | 154 ++++++
arch/powerpc/sysdev/bestcomm/ata.h | 37 ++
arch/powerpc/sysdev/bestcomm/bcom_ata_task.c | 67 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c | 78 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c | 91 ++++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c | 63 +++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c | 69 +++
arch/powerpc/sysdev/bestcomm/bestcomm.c | 528 ++++++++++++++++++++
arch/powerpc/sysdev/bestcomm/bestcomm.h | 190 +++++++
arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 334 +++++++++++++
arch/powerpc/sysdev/bestcomm/fec.c | 270 ++++++++++
arch/powerpc/sysdev/bestcomm/fec.h | 61 +++
arch/powerpc/sysdev/bestcomm/gen_bd.c | 260 ++++++++++
arch/powerpc/sysdev/bestcomm/gen_bd.h | 48 ++
arch/powerpc/sysdev/bestcomm/sram.c | 177 +++++++
arch/powerpc/sysdev/bestcomm/sram.h | 54 ++
arch/ppc/Kconfig | 6 +
include/asm-ppc/mpc52xx_psc.h | 10 +-
27 files changed, 2591 insertions(+), 7 deletions(-)
create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig
create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.c
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_ata_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.c
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.h
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.c
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.h
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-16 23:23 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Wolfgang Reissnegger, Leonid,
microblaze-uclinux
In-Reply-To: <20071015155223.7403.39615.stgit@trillian.cg.shawcable.net>
It occurs to me that the 'compatible' bindings should probably be the
name of the preferred driver for the device.=20
> + l) Xilinx ML300 Framebuffer
> + - compatible : Must include "xilinx,ml300-fb"
Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
all.
> + n) Xilinx EMAC and Xilinx TEMAC
> +
> + Xilinx Ethernet devices. Uses common properties from=20
> other Ethernet
> + devices with the following constraints:
> + =20
> + Required properties:
> + - compatible : Must include one of: "xilinx,plb-temac",
> + "xilinx,plb-emac", "xilinx-opb-emac"
Should probably be just 'emac' and 'temac'.
This should be possible to extract using Michel Simek's EDK-integrated
device tree generator. The compatibility information is stored in the
EDK driver's .mdd file (although this is somewhat backwards from what
one might expect).
Steve
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-17 0:21 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <fa686aa40710161236h4cc82edbqfee328bbcb21c752@mail.gmail.com>
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Tuesday, October 16, 2007 12:36 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;=20
> microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
>=20
> On 10/16/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > > + n) Xilinx EMAC and Xilinx TEMAC
> > > +
> > > + Xilinx Ethernet devices. Uses common properties from
> > > other Ethernet
> > > + devices with the following constraints:
> > > +
> > > + Required properties:
> > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > =3D=3D scatter gather)
> >
> > I think it's going to be a significant headache to remap=20
> things like the
> > dma-mode from the xilinx configurations to something else, and then
> > interpret them correctly in the drivers.
> >
> > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > something like:
> >
> > Ethernet_MAC {
> > xilinx,C_DMA_PRESENT =3D <1>;
> > ...
> > }
> >
> > (which happens to correspond to "none" above)
>=20
> Ugh. Can't say I'm thrilled about this....
>=20
> But in this case is might be a necessity. The IP core is already
> parameterized and the best way to describe the device is to use the
> existing parameter names.
I don't really like it either, expecially after thinking about it more.
The problem is that a single IP core might correspond to multiple
logical devices. The parameters actually need to be from the point of
view of the drivers. That is, they need to be names like in the
xparameters:
xilinx,DMA_PRESENT =3D <1>;
In this case, the translation looks simple, but it is currently
implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
future, this *could* be simple code, but in the short term, it won't be
any simpler than having pretty names. Furthermore, the best driver code
that I can come up with for using this essentially looks like:
static int __devinit xenet_of_probe(struct of_device *ofdev, const
struct of_device_id *match)
{
struct xemac_platform_data pdata_struct;
struct resource r_irq_struct;
struct resource r_mem_struct;
struct resource *r_irq =3D &r_irq_struct; /* Interrupt resources
*/
struct resource *r_mem =3D &r_mem_struct; /* IO mem resources */
struct xemac_platform_data *pdata =3D &pdata_struct;
int rc =3D 0;
printk(KERN_ERR "Device Tree Probing \'%s\'\n",
ofdev->node->name);
/* Get iospace for the device */
rc =3D of_address_to_resource(ofdev->node, 0, r_mem);
if(rc) {
dev_warn(&ofdev->dev, "invalid address\n");
return rc;
}
/* Get IRQ for the device */
rc =3D of_irq_to_resource(ofdev->node, 0, r_irq);
if(rc =3D=3D NO_IRQ) {
dev_warn(&ofdev->dev, "no IRQ found.\n");
return rc;
}
pdata_struct.dma_mode =3D get_u32(ofdev,
"C_DMA_PRESENT");
pdata_struct.has_mii =3D get_u32(ofdev, "C_MII_EXIST");
pdata_struct.has_cam =3D get_u32(ofdev, "C_CAM_EXIST");
pdata_struct.has_err_cnt =3D get_u32(ofdev,
"C_ERR_COUNT_EXIST");
pdata_struct.has_jumbo =3D get_u32(ofdev,
"C_JUMBO_EXIST");
pdata_struct.tx_dre =3D get_u32(ofdev,
"C_TX_DRE_TYPE");
pdata_struct.rx_dre =3D get_u32(ofdev,
"C_RX_DRE_TYPE");
pdata_struct.tx_hw_csum =3D get_u32(ofdev,
"C_TX_INCLUDE_CSUM");
pdata_struct.rx_hw_csum =3D get_u32(ofdev,
"C_RX_INCLUDE_CSUM");
memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
6);
return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
}
Where probe_initialization contains shares code with the platform_device
version of probe. This means that the string is still translated into
another name anyway. Anybody have any better ideas for doing this?
>=20
> I want to be careful though. Parameters can change from one version
> of an IP core to another. The driver needs to be able to determine
> what version of the IP core is used so that the parameters make sense.
> I'm also nervous about adding every possible C_ value to the device
> node for each xilinx IP-core; that could make the device tree quite
> large. (on the other hand; maybe that doesn't matter... It is
> probably a bigger deal for microblaze than powerpc too.).
Using the xparameters set of values could solve this problem, since only
things that make sense to the driver are actually set.
Steve
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>=20
>=20
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Andi Kleen @ 2007-10-17 0:25 UTC (permalink / raw)
To: David Miller
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-kernel, arnd, jens.axboe
In-Reply-To: <20071016.152404.35664335.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 16 Oct 2007 21:50:35 +0200
>
> > The one point where it is expected to have changed now is when you
> > try to do these ioctls on something that is not a block device. Are
> > you sure that the files you tried them on were created correctly?
>
> Many many many programs do this exact sort of thing.
>
> It is one of the bad aspects of moving the compat handling
> down into the file ops for a specific device.
When this happens one should add respective IGNORE_IOCTL()s to
compat_ioctl.c
-Andi
^ permalink raw reply
* Re: [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: David Gibson @ 2007-10-17 0:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071016213107.14117.3858.stgit@trillian.cg.shawcable.net>
On Tue, Oct 16, 2007 at 03:31:07PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Add the 'set -e' command to the wrapper script so that if any command
> fails then the script will automatically exit
Ah.. this will conflict with my patch to merge dtc (because that
touches the line invoking dtc to change the path to it).
--
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 Updates
From: David Gibson @ 2007-10-17 0:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IhmXN-0003CC-39@jdl.com>
On Tue, Oct 16, 2007 at 08:32:45AM -0500, Jon Loeliger wrote:
>
> Guys and Dolls,
>
> I pushed out all of David's recent DTC and libfdt patches.
> I also jammed the following patch into the mix as well.
>
> HTH,
> jdl
>
>
>
> commit 9e32930ebcacfcf7cb7c1c2b8e776eb3957cf6cb
> Author: Jon Loeliger <jdl@freescale.com>
> Date: Tue Oct 16 07:35:38 2007 -0500
>
> Restore warning message about bison expected output.
Heh, the removal was kind of deliberate, since I didn't think it was
actually all that much use. But I don't really care much one way or
the other.
I really wish bison would suppress these warnings in glr-parser mode.
>
> It was dropped in ad9593f229362782b953da4b805df713e8468df0.
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> diff --git a/Makefile b/Makefile
> index 84f0efe..d7d1af5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -207,6 +207,7 @@ clean: libfdt_clean tests_clean
>
> %.tab.c %.tab.h %.output: %.y
> @$(VECHO) BISON $@
> + @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
> $(BISON) -d $<
>
> FORCE:
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-10-17 0:37 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20071016211939.250c2da4@hyperion.delvare>
On Tue, Oct 16, 2007 at 09:19:39PM +0200, Jean Delvare wrote:
> On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > In fact I think it may be acceptle to do the idx++ thing in this
> > > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > > the horrible mess that is the Linux i2c subsystem. It means that bus
> > > numbers are theoretically unstable, but that's increasingly true of
> > > devices of all sorts - it's up to udev to assign meaningful labels at
> > > the user level.
>
> David, after such a rant against the Linux i2c subsystem, I sure hope
> that you're going to contribute patches to make it better (whatever you
> think needs to be improved, as you didn't say.)
I've frequently contemplated it. In the unlikely event that it ever
bubbles to the top of my priorities, I might well.
> > I think the real problem here comes into play when there are 2 types
> > of i2c busses in the system. If they both maintain their own idx++
> > values; then they will conflict. If an auto assigned bus number is
> > used; then it needs to be assigned by the i2c infrastructure; not by
> > the driver.
>
> Very true. If you aren't going to define the i2c bus numbers at
> platform data level, then you shouldn't be defining them _at all_.
> Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
> i2c-core choose an appropriate a bus number.
--
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: Fix new EMAC driver for NAPI changes
From: Jeff Garzik @ 2007-10-17 1:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, netdev, Roland Dreier, David S. Miller,
shemminger
In-Reply-To: <1192513250.19073.10.camel@pasglop>
Benjamin Herrenschmidt wrote:
> net: Fix new EMAC driver for NAPI changes
>
> This fixes the new EMAC driver for the NAPI updates. The previous patch
> by Roland Dreier (already applied) to do that doesn't actually work. This
> applies on top of it makes it work on my test Ebony machine.
>
> This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
> posted previously.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> The old EMAC driver does things a bit differently (doesn't do useful
> locking :-) and seems to work with Roland patch. So I'm not going to
> touch it unless somebody reports me that it has problems
applied
^ permalink raw reply
* dtc: Restore missing code for testcases
From: David Gibson @ 2007-10-17 1:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Recent commits 333542fabf8720b881e992a5abca32ef4bcb841a and
fd1bf3a5ae46962528ef89a824261a88830758a2 added new testcases to dtc.
However, although the testcases were added to the Makefile and
run_tests.sh, one of the .c files for the testcase was omitted from
the patch in each case.
This patch restores the missing testcase code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Oops, I suck. Screwed up my quilting, somehow. jdl, you should
really run a "make check" before committing my patches...
Index: dtc/tests/get_mem_rsv.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/get_mem_rsv.c 2007-10-17 11:19:06.000000000 +1000
@@ -0,0 +1,49 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_mem_rsv() and fdt_num_mem_rsv()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int rc;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ rc = fdt_num_mem_rsv(fdt);
+ if (rc < 0)
+ FAIL("fdt_num_mem_rsv(): %s", fdt_strerror(rc));
+ if (rc != 2)
+ FAIL("fdt_num_mem_rsv() returned %d instead of 2", rc);
+
+ check_mem_rsv(fdt, 0, TEST_ADDR_1, TEST_SIZE_1);
+ check_mem_rsv(fdt, 1, TEST_ADDR_2, TEST_SIZE_2);
+ PASS();
+}
Index: dtc/tests/node_check_compatible.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/node_check_compatible.c 2007-10-17 11:19:32.000000000 +1000
@@ -0,0 +1,62 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_node_check_compatible()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_compatible(const void *fdt, const char *path, const char *compat)
+{
+ int offset, err;
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0)
+ FAIL("fdt_path_offset(%s): %s", path, fdt_strerror(offset));
+
+ err = fdt_node_check_compatible(fdt, offset, compat);
+ if (err < 0)
+ FAIL("fdt_node_check_compatible(%s): %s", path,
+ fdt_strerror(err));
+ if (err != 0)
+ FAIL("%s is not compatible with \"%s\"", path, compat);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_compatible(fdt, "/", "test_tree1");
+ check_compatible(fdt, "/subnode@1/subsubnode", "subsubnode1");
+ check_compatible(fdt, "/subnode@1/subsubnode", "subsubnode");
+ check_compatible(fdt, "/subnode@2/subsubnode", "subsubnode2");
+ check_compatible(fdt, "/subnode@2/subsubnode", "subsubnode");
+
+ PASS();
+}
--
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: Fix new EMAC driver for NAPI changes
From: Benjamin Herrenschmidt @ 2007-10-17 1:46 UTC (permalink / raw)
To: Jeff Garzik
Cc: linuxppc-dev list, netdev, Roland Dreier, David S. Miller,
shemminger
In-Reply-To: <47156258.5010800@garzik.org>
On Tue, 2007-10-16 at 21:16 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > net: Fix new EMAC driver for NAPI changes
> >
> > This fixes the new EMAC driver for the NAPI updates. The previous patch
> > by Roland Dreier (already applied) to do that doesn't actually work. This
> > applies on top of it makes it work on my test Ebony machine.
> >
> > This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
> > posted previously.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > The old EMAC driver does things a bit differently (doesn't do useful
> > locking :-) and seems to work with Roland patch. So I'm not going to
> > touch it unless somebody reports me that it has problems
>
> applied
Beware that the depend patch for __napi_synchronize() is still being
discussed :-)
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Josh Boyer @ 2007-10-17 1:49 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016232404.5F4D51130091@mail133-blu.bigfish.com>
On Tue, 2007-10-16 at 16:23 -0700, Stephen Neuendorffer wrote:
> It occurs to me that the 'compatible' bindings should probably be the
> name of the preferred driver for the device.
>
> > + l) Xilinx ML300 Framebuffer
> > + - compatible : Must include "xilinx,ml300-fb"
> Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
> all.
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> Should probably be just 'emac' and 'temac'.
You mean xilinx,emac and xilinx,temac, right? emac and temac are too
generic by themselves.
josh
^ permalink raw reply
* Re: [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: Grant Likely @ 2007-10-17 2:10 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, paulus, Scott Wood
In-Reply-To: <20071017003331.GA28260@localhost.localdomain>
On 10/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Oct 16, 2007 at 03:31:07PM -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Add the 'set -e' command to the wrapper script so that if any command
> > fails then the script will automatically exit
>
> Ah.. this will conflict with my patch to merge dtc (because that
> touches the line invoking dtc to change the path to it).
No worries; I can respin this one easily after the dtc stuff is sorted out.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 2:31 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016232404.5F4D51130091@mail133-blu.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> It occurs to me that the 'compatible' bindings should probably be the
> name of the preferred driver for the device.
>
> > + l) Xilinx ML300 Framebuffer
> > + - compatible : Must include "xilinx,ml300-fb"
> Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
> all.
Actually, I don't think xilinx,ml300-fb is not specific enough (as
opposed to not general enough). Given that the device tree is
supposed to describe the hardware as uniquely as possible, compatible
should probably contain a value like "xilinx,plb-tft-cntlr-ref-1.00.c"
(<vendor>,<ip core>,<version>).
A design with a modified fb core might specify:
compatible = "acme,super-tft-1.3","xilinx,plb-tft-cntlr-ref-1.00.c";
Which indicates that it is a different part, but it provides the same
interface as the preexisting plb-tft-cntrl-ref ip core. Similarly, a
newer reference design which uses a new version of the tft core should
specifiy:
compatible =
"xilinx,plb-tft-cntrl-ref-1.00.d","xilinx,plb-tft-cntlr-ref-1.00.c";
That way the exact type of device is specified; but it is *compatible*
with the older device. If the newer device has a greater feature set,
then a driver that can match against the leftmost compatible value can
make use of the extra features.
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> Should probably be just 'emac' and 'temac'.
Actually; looking at the available ip cores; it should probably be:
"xilinx,opb-ethernet-1.02.a" for an emac driver
"xilinx,plb-temac-3.00.a" for a temac.
We should probably use the exact names of the ip core. Less ambiguity that way.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 2:35 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071017002156.289E2B58056@mail41-cpk.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
>
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > Behalf Of Grant Likely
> > Sent: Tuesday, October 16, 2007 12:36 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
> > microblaze-uclinux@itee.uq.edu.au
> > Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
> >
> > On 10/16/07, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> > > > + n) Xilinx EMAC and Xilinx TEMAC
> > > > +
> > > > + Xilinx Ethernet devices. Uses common properties from
> > > > other Ethernet
> > > > + devices with the following constraints:
> > > > +
> > > > + Required properties:
> > > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > > == scatter gather)
> > >
> > > I think it's going to be a significant headache to remap
> > things like the
> > > dma-mode from the xilinx configurations to something else, and then
> > > interpret them correctly in the drivers.
> > >
> > > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > > something like:
> > >
> > > Ethernet_MAC {
> > > xilinx,C_DMA_PRESENT = <1>;
> > > ...
> > > }
> > >
> > > (which happens to correspond to "none" above)
> >
> > Ugh. Can't say I'm thrilled about this....
> >
> > But in this case is might be a necessity. The IP core is already
> > parameterized and the best way to describe the device is to use the
> > existing parameter names.
>
> I don't really like it either, expecially after thinking about it more.
> The problem is that a single IP core might correspond to multiple
> logical devices. The parameters actually need to be from the point of
> view of the drivers. That is, they need to be names like in the
> xparameters:
>
> xilinx,DMA_PRESENT = <1>;
Hmm, not bad. It does still get a little harry when one IP core
implements multiple logical devices, but maybe the IP core should
create a node and the logical devices can be sub nodes with the
appropriate properties needed to describe which logical device it is.
>
> In this case, the translation looks simple, but it is currently
> implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
> future, this *could* be simple code, but in the short term, it won't be
> any simpler than having pretty names. Furthermore, the best driver code
> that I can come up with for using this essentially looks like:
>
> static int __devinit xenet_of_probe(struct of_device *ofdev, const
> struct of_device_id *match)
> {
> struct xemac_platform_data pdata_struct;
> struct resource r_irq_struct;
> struct resource r_mem_struct;
>
> struct resource *r_irq = &r_irq_struct; /* Interrupt resources
> */
> struct resource *r_mem = &r_mem_struct; /* IO mem resources */
> struct xemac_platform_data *pdata = &pdata_struct;
> int rc = 0;
>
> printk(KERN_ERR "Device Tree Probing \'%s\'\n",
> ofdev->node->name);
>
> /* Get iospace for the device */
> rc = of_address_to_resource(ofdev->node, 0, r_mem);
> if(rc) {
> dev_warn(&ofdev->dev, "invalid address\n");
> return rc;
> }
>
> /* Get IRQ for the device */
> rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> if(rc == NO_IRQ) {
> dev_warn(&ofdev->dev, "no IRQ found.\n");
> return rc;
> }
>
> pdata_struct.dma_mode = get_u32(ofdev,
> "C_DMA_PRESENT");
> pdata_struct.has_mii = get_u32(ofdev, "C_MII_EXIST");
> pdata_struct.has_cam = get_u32(ofdev, "C_CAM_EXIST");
> pdata_struct.has_err_cnt = get_u32(ofdev,
> "C_ERR_COUNT_EXIST");
> pdata_struct.has_jumbo = get_u32(ofdev,
> "C_JUMBO_EXIST");
> pdata_struct.tx_dre = get_u32(ofdev,
> "C_TX_DRE_TYPE");
> pdata_struct.rx_dre = get_u32(ofdev,
> "C_RX_DRE_TYPE");
> pdata_struct.tx_hw_csum = get_u32(ofdev,
> "C_TX_INCLUDE_CSUM");
> pdata_struct.rx_hw_csum = get_u32(ofdev,
> "C_RX_INCLUDE_CSUM");
> memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
> 6);
>
> return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
> }
>
> Where probe_initialization contains shares code with the platform_device
> version of probe. This means that the string is still translated into
> another name anyway. Anybody have any better ideas for doing this?
That's pretty close to what I've done on the sysace, uartlite and
xilinxfb drivers.
> > I want to be careful though. Parameters can change from one version
> > of an IP core to another. The driver needs to be able to determine
> > what version of the IP core is used so that the parameters make sense.
> > I'm also nervous about adding every possible C_ value to the device
> > node for each xilinx IP-core; that could make the device tree quite
> > large. (on the other hand; maybe that doesn't matter... It is
> > probably a bigger deal for microblaze than powerpc too.).
>
> Using the xparameters set of values could solve this problem, since only
> things that make sense to the driver are actually set.
I've thought about this more since I wrote the above paragraph. The
compatible property was designed to solve that exact problem. We'll
just embed the version in the compatible list.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* dtc: Improve -Odts output
From: David Gibson @ 2007-10-17 2:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch makes improvements to the way properties are printed when
in dtc is producing dts output.
- Characters which need escaping are now properly handled when
printing properties as strings
- The heuristics for what format to use for a property are
improved so that 'compatible' properties will be displayed as
expected.
- escapes.dts is altered to better demonstrate the changes,
and the string_escapes testcase is adjusted accordingly.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2007-10-17 10:27:35.000000000 +1000
+++ dtc/treesource.c 2007-10-17 11:43:18.000000000 +1000
@@ -56,22 +56,31 @@
PROP_BYTES,
};
+int isstring(char c)
+{
+ return (isprint(c)
+ || (c == '\0')
+ || strchr("\a\b\t\n\v\f\r", c));
+}
+
static enum proptype guess_type(struct property *prop)
{
int len = prop->val.len;
char *p = prop->val.val;
- int nnoprint = 0;
+ int nnotstring = 0, nnul = 0;
int i;
if (len == 0)
return PROP_EMPTY;
for (i = 0; i < len; i++) {
- if (! isprint(p[i]))
- nnoprint++;
+ if (! isstring(p[i]))
+ nnotstring++;
+ if (p[i] == '\0')
+ nnul++;
}
- if ((nnoprint == 1) && (p[len-1] == '\0'))
+ if ((p[len-1] == '\0') && (nnotstring == 0) && (nnul < (len-nnul)))
return PROP_STRING;
else if ((len % sizeof(cell_t)) == 0)
return PROP_CELLS;
@@ -79,6 +88,87 @@
return PROP_BYTES;
}
+static void write_propval_string(FILE *f, struct data val)
+{
+ char *str = val.val;
+ int i;
+
+ assert(str[val.len-1] == '\0');
+
+ fprintf(f, " = \"");
+ for (i = 0; i < (val.len-1); i++) {
+ char c = str[i];
+
+ switch (c) {
+ case '\a':
+ fprintf(f, "\\a");
+ break;
+ case '\b':
+ fprintf(f, "\\b");
+ break;
+ case '\t':
+ fprintf(f, "\\t");
+ break;
+ case '\n':
+ fprintf(f, "\\n");
+ break;
+ case '\v':
+ fprintf(f, "\\v");
+ break;
+ case '\f':
+ fprintf(f, "\\f");
+ break;
+ case '\r':
+ fprintf(f, "\\r");
+ break;
+ case '\\':
+ fprintf(f, "\\\\");
+ break;
+ case '\"':
+ fprintf(f, "\\\"");
+ break;
+ case '\0':
+ fprintf(f, "\", \"");
+ break;
+ default:
+ if (isprint(c))
+ fprintf(f, "%c", c);
+ else
+ fprintf(f, "\\x%02hhx", c);
+ }
+ }
+ fprintf(f, "\";\n");
+}
+
+static void write_propval_cells(FILE *f, struct data val)
+{
+ void *propend = val.val + val.len;
+ cell_t *cp = (cell_t *)val.val;
+
+ fprintf(f, " = <");
+ for (;;) {
+ fprintf(f, "%x", be32_to_cpu(*cp++));
+ if ((void *)cp >= propend)
+ break;
+ fprintf(f, " ");
+ }
+ fprintf(f, ">;\n");
+}
+
+static void write_propval_bytes(FILE *f, struct data val)
+{
+ void *propend = val.val + val.len;
+ char *bp = val.val;
+
+ fprintf(f, " = [");
+ for (;;) {
+ fprintf(f, "%02hhx", *bp++);
+ if ((void *)bp >= propend)
+ break;
+ fprintf(f, " ");
+ }
+ fprintf(f, "];\n");
+}
static void write_tree_source_node(FILE *f, struct node *tree, int level)
{
@@ -92,15 +182,11 @@
fprintf(f, "/ {\n");
for_each_property(tree, prop) {
- cell_t *cp;
- char *bp;
- void *propend;
enum proptype type;
write_prefix(f, level);
fprintf(f, "\t%s", prop->name);
type = guess_type(prop);
- propend = prop->val.val + prop->val.len;
switch (type) {
case PROP_EMPTY:
@@ -108,31 +194,15 @@
break;
case PROP_STRING:
- fprintf(f, " = \"%s\";\n", (char *)prop->val.val);
+ write_propval_string(f, prop->val);
break;
case PROP_CELLS:
- fprintf(f, " = <");
- cp = (cell_t *)prop->val.val;
- for (;;) {
- fprintf(f, "%x", be32_to_cpu(*cp++));
- if ((void *)cp >= propend)
- break;
- fprintf(f, " ");
- }
- fprintf(f, ">;\n");
+ write_propval_cells(f, prop->val);
break;
case PROP_BYTES:
- fprintf(f, " = [");
- bp = prop->val.val;
- for (;;) {
- fprintf(f, "%02hhx", *bp++);
- if ((void *)bp >= propend)
- break;
- fprintf(f, " ");
- }
- fprintf(f, "];\n");
+ write_propval_bytes(f, prop->val);
break;
}
}
Index: dtc/tests/escapes.dts
===================================================================
--- dtc.orig/tests/escapes.dts 2007-10-17 11:36:37.000000000 +1000
+++ dtc/tests/escapes.dts 2007-10-17 12:32:27.000000000 +1000
@@ -1,4 +1,5 @@
/ {
compatible = "test_string_escapes";
- escape-str = "nastystring: \a\b\t\n\v\f\r\\\"\xff";
+ escape-str = "nastystring: \a\b\t\n\v\f\r\\\"";
+ escape-str-2 = "\xde\xad\xbe\xef";
};
Index: dtc/tests/string_escapes.c
===================================================================
--- dtc.orig/tests/string_escapes.c 2007-10-17 12:31:56.000000000 +1000
+++ dtc/tests/string_escapes.c 2007-10-17 12:32:04.000000000 +1000
@@ -37,6 +37,8 @@
check_getprop(fdt, 0, "escape-str",
strlen(TEST_STRING_2)+1, TEST_STRING_2);
+ check_getprop(fdt, 0, "escape-str-2",
+ strlen(TEST_STRING_3)+1, TEST_STRING_3);
PASS();
}
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-10-17 12:28:50.000000000 +1000
+++ dtc/tests/testdata.h 2007-10-17 12:31:45.000000000 +1000
@@ -24,7 +24,8 @@
#define TEST_VALUE_2 cell_to_fdt(0xabcd1234)
#define TEST_STRING_1 "hello world"
-#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\"\xff"
+#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\""
+#define TEST_STRING_3 "\xde\xad\xbe\xef"
#ifndef __ASSEMBLY__
extern struct fdt_header _test_tree1;
--
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/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 2:50 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
napi: use non-interruptible sleep in napi_disable
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:16.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-17 12:45:00.000000000 +1000
@@ -390,7 +390,7 @@ static inline void napi_complete(struct
static inline void napi_disable(struct napi_struct *n)
{
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
- msleep_interruptible(1);
+ msleep(1);
}
/**
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 2:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
net: Add __napi_synchronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Switched to do a cpu_relax() spin instead and only on SMP. Not that
we have an smp_mb() in there which synchronize_irq() lacks. I believe
this is a bug in synchronize_irq() which I'll handle separately.
Note: unfortunately, Jeff already picked up the EMAC patch without
waiting for this to be sorted out (oops...). So if you agree with
this patch, it would be nice to have it go in quickly or maybe via
Jeff's tree to avoid breakage ? Not terribly important tho.
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:40.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-17 12:40:59.000000000 +1000
@@ -394,6 +394,23 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+#ifdef CONFIG_SMP
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ cpu_relax();
+#endif /* CONFIG_SMP */
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 3:03 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <fa686aa40710161935p2aef36efx6154071b0055698f@mail.gmail.com>
On 10/16/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > > Behalf Of Grant Likely
> > > Sent: Tuesday, October 16, 2007 12:36 PM
> > > To: Stephen Neuendorffer
> > > Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
> > > microblaze-uclinux@itee.uq.edu.au
> > > Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
> > >
> > > On 10/16/07, Stephen Neuendorffer
> > > <stephen.neuendorffer@xilinx.com> wrote:
> > > >
> > > > > + n) Xilinx EMAC and Xilinx TEMAC
> > > > > +
> > > > > + Xilinx Ethernet devices. Uses common properties from
> > > > > other Ethernet
> > > > > + devices with the following constraints:
> > > > > +
> > > > > + Required properties:
> > > > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > > > == scatter gather)
> > > >
> > > > I think it's going to be a significant headache to remap
> > > things like the
> > > > dma-mode from the xilinx configurations to something else, and then
> > > > interpret them correctly in the drivers.
> > > >
> > > > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > > > something like:
> > > >
> > > > Ethernet_MAC {
> > > > xilinx,C_DMA_PRESENT = <1>;
> > > > ...
> > > > }
> > > >
> > > > (which happens to correspond to "none" above)
> > >
> > > Ugh. Can't say I'm thrilled about this....
> > >
> > > But in this case is might be a necessity. The IP core is already
> > > parameterized and the best way to describe the device is to use the
> > > existing parameter names.
> >
> > I don't really like it either, expecially after thinking about it more.
> > The problem is that a single IP core might correspond to multiple
> > logical devices. The parameters actually need to be from the point of
> > view of the drivers. That is, they need to be names like in the
> > xparameters:
> >
> > xilinx,DMA_PRESENT = <1>;
>
> Hmm, not bad. It does still get a little harry when one IP core
> implements multiple logical devices, but maybe the IP core should
> create a node and the logical devices can be sub nodes with the
> appropriate properties needed to describe which logical device it is.
>
> >
> > In this case, the translation looks simple, but it is currently
> > implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
> > future, this *could* be simple code, but in the short term, it won't be
> > any simpler than having pretty names. Furthermore, the best driver code
> > that I can come up with for using this essentially looks like:
> >
> > static int __devinit xenet_of_probe(struct of_device *ofdev, const
> > struct of_device_id *match)
> > {
> > struct xemac_platform_data pdata_struct;
> > struct resource r_irq_struct;
> > struct resource r_mem_struct;
> >
> > struct resource *r_irq = &r_irq_struct; /* Interrupt resources
> > */
> > struct resource *r_mem = &r_mem_struct; /* IO mem resources */
> > struct xemac_platform_data *pdata = &pdata_struct;
> > int rc = 0;
> >
> > printk(KERN_ERR "Device Tree Probing \'%s\'\n",
> > ofdev->node->name);
> >
> > /* Get iospace for the device */
> > rc = of_address_to_resource(ofdev->node, 0, r_mem);
> > if(rc) {
> > dev_warn(&ofdev->dev, "invalid address\n");
> > return rc;
> > }
> >
> > /* Get IRQ for the device */
> > rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> > if(rc == NO_IRQ) {
> > dev_warn(&ofdev->dev, "no IRQ found.\n");
> > return rc;
> > }
> >
> > pdata_struct.dma_mode = get_u32(ofdev,
> > "C_DMA_PRESENT");
> > pdata_struct.has_mii = get_u32(ofdev, "C_MII_EXIST");
> > pdata_struct.has_cam = get_u32(ofdev, "C_CAM_EXIST");
> > pdata_struct.has_err_cnt = get_u32(ofdev,
> > "C_ERR_COUNT_EXIST");
> > pdata_struct.has_jumbo = get_u32(ofdev,
> > "C_JUMBO_EXIST");
> > pdata_struct.tx_dre = get_u32(ofdev,
> > "C_TX_DRE_TYPE");
> > pdata_struct.rx_dre = get_u32(ofdev,
> > "C_RX_DRE_TYPE");
> > pdata_struct.tx_hw_csum = get_u32(ofdev,
> > "C_TX_INCLUDE_CSUM");
> > pdata_struct.rx_hw_csum = get_u32(ofdev,
> > "C_RX_INCLUDE_CSUM");
> > memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
> > 6);
> >
> > return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
> > }
> >
> > Where probe_initialization contains shares code with the platform_device
> > version of probe. This means that the string is still translated into
> > another name anyway. Anybody have any better ideas for doing this?
>
> That's pretty close to what I've done on the sysace, uartlite and
> xilinxfb drivers.
>
> > > I want to be careful though. Parameters can change from one version
> > > of an IP core to another. The driver needs to be able to determine
> > > what version of the IP core is used so that the parameters make sense.
> > > I'm also nervous about adding every possible C_ value to the device
> > > node for each xilinx IP-core; that could make the device tree quite
> > > large. (on the other hand; maybe that doesn't matter... It is
> > > probably a bigger deal for microblaze than powerpc too.).
> >
> > Using the xparameters set of values could solve this problem, since only
> > things that make sense to the driver are actually set.
>
> I've thought about this more since I wrote the above paragraph. The
> compatible property was designed to solve that exact problem. We'll
> just embed the version in the compatible list.
And, yes, you're right. Using the xparams value set is probably the
place to start for choosing which properties to put in the device
tree. I'll document this stuff up and respin my patch.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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