LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Implement pci_set_dma_mask() in terms of the dma_ops
From: Michael Ellerman @ 2007-12-17  6:35 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

Powerpc currently doesn't implement pci_set_dma_mask(), which means drivers
calling it will get the generic version in drivers/pci/pci.c.

The Powerpc dma mapping ops include a dma_set_mask() hook, which luckily is
not implemented by anyone - so there is no bug in the fact that the hook
is currently never called.

However in future we'll add implementation(s) of dma_set_mask(), and so we
need pci_set_dma_mask() to call the hook.

To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask()
simply calls the dma_set_mask() hook and then copies the new mask into
dev.coherenet_dma_mask.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/kernel/pci_64.c      |   16 ++++++++++++++++
 include/asm-powerpc/dma-mapping.h |    3 +++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index bf06926..f5c4628 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -69,6 +69,22 @@ struct dma_mapping_ops *get_pci_dma_ops(void)
 }
 EXPORT_SYMBOL(get_pci_dma_ops);
 
+
+int pci_set_dma_mask(struct pci_dev *dev, u64 mask)
+{
+	return dma_set_mask(&dev->dev, mask);
+}
+
+int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask)
+{
+	int rc;
+
+	rc = dma_set_mask(&dev->dev, mask);
+	dev->dev.coherent_dma_mask = dev->dma_mask;
+
+	return rc;
+}
+
 static void fixup_broken_pcnet32(struct pci_dev* dev)
 {
 	if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index ff52013..e974876 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -87,6 +87,9 @@ static inline int dma_supported(struct device *dev, u64 mask)
 	return dma_ops->dma_supported(dev, mask);
 }
 
+/* We have our own implementation of pci_set_dma_mask() */
+#define HAVE_ARCH_PCI_SET_DMA_MASK
+
 static inline int dma_set_mask(struct device *dev, u64 dma_mask)
 {
 	struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* RE: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17  6:04 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217052101.GC3477@localhost.localdomain>

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


Thanks, I've updated the generator to reflect this.

Steve

-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sun 12/16/2007 9:21 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Michal Simek; git
Subject: Re: Device Tree updates for xilinx.
 
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
> 
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference?  For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version.  So for the
> microblaze, I'd prefer something like:
> 
> xlnx,microblaze-6.00.b

Sounds reasonable.

> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.

Well, we could list both forms, but PowerPC,405 should be included
since it's an established name.  There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.

With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s).  In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files.  So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.

In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.

-- 
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



[-- Attachment #2: Type: text/html, Size: 3105 bytes --]

^ permalink raw reply

* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-17  6:00 UTC (permalink / raw)
  To: torvalds; +Cc: linuxppc-dev

Linus,

Please do

git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge

to get some bugfixes and defconfig updates for powerpc.

Thanks,
Paul.

 arch/powerpc/configs/mpc8272_ads_defconfig |    6 +++---
 arch/powerpc/configs/pq2fads_defconfig     |    6 +++---
 arch/powerpc/configs/ps3_defconfig         |    2 +-
 arch/powerpc/kernel/ppc_ksyms.c            |   12 ------------
 arch/powerpc/math-emu/op-2.h               |    3 ++-
 arch/powerpc/platforms/iseries/lpevents.c  |   17 +++++++++++++++--
 arch/powerpc/platforms/ps3/Kconfig         |    2 +-
 arch/powerpc/sysdev/cpm2_common.c          |    3 +--
 drivers/net/fs_enet/mac-scc.c              |    2 +-
 include/asm-powerpc/commproc.h             |    3 ---
 10 files changed, 27 insertions(+), 29 deletions(-)

Jochen Friedrich (2):
      [POWERPC] Fix typo #ifdef -> #ifndef
      [POWERPC] Kill non-existent symbols from ksyms and commproc.h

Liu Yu (1):
      [POWERPC] Fix rounding bug in emulation for double float operating

Michael Ellerman (1):
      [POWERPC] Make PS3_SYS_MANAGER default y, not m

Scott Wood (2):
      [POWRPC] CPM2: Eliminate section mismatch warning in cpm2_reset().
      [POWERPC] 82xx: mpc8272ads, pq2fads: Update defconfig with CONFIG_FS_ENET_MDIO_FCC

Stephen Rothwell (1):
      [POWERPC] iSeries: don't printk with HV spinlock held

^ permalink raw reply

* RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Aggrwal Poonam @ 2007-12-17  5:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Barkowski Michael, netdev, Gala Kumar, linux-kernel, rubini,
	linuxppc-dev, Kalra Ashish, Cutler Richard
In-Reply-To: <20071211111855.dc5276a2.sfr@canb.auug.org.au>

Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.

Sorry for late reply as I was on leave for the last week.=20


With Regards
Poonam=20
=20
=20

-----Original Message-----
From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: rubini@vision.unipv.it; linux-kernel@vger.kernel.org;
netdev@vger.kernel.org; Gala Kumar; linuxppc-dev@ozlabs.org; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.

On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<b10812@freescale.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
>   */
>  static unsigned int brg_clk =3D 0;
> =20
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
>  {
> -	struct device_node *qe;
> -	if (brg_clk)
> -		return brg_clk;
> +	struct device_node *qe, *brg, *clocks;
> +	enum qe_clock brg_src;
> +	u32 brg_input_freq =3D 0;
> +	u32 brg_num;
> +	const unsigned int *prop;
> =20
> -	qe =3D of_find_node_by_type(NULL, "qe");
> -	if (qe) {
> +	*brg_source =3D 0;
> +
> +	brg_num =3D brgclk - QE_BRG1;
> +	brg =3D of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> +	if (brg) {
>  		unsigned int size;
> -		const u32 *prop =3D of_get_property(qe, "brg-frequency",
&size);
> -		brg_clk =3D *prop;
> -		of_node_put(qe);
> -	};
> +		prop =3D of_get_property(brg,
> +					"fsl,brg-sources", &size);
> +
> +		brg_src =3D *(prop + brg_num);

You should probably sanity check that prop is not NULL and points to
something large enough.

You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later.  Also, currently there are
paths through the following code that do not do the of_node_put(brg).

> +		if (brg_src =3D=3D 0) {
> +			*brg_source =3D 0;
> +			if (brg_clk > 0) {
> +				of_node_put(brg);
> +				return brg_clk;
> +			}
> +			qe =3D of_find_node_by_type(NULL, "qe");
> +			if (qe) {
> +				unsigned int size;
> +				prop =3D of_get_property
> +						(qe, "brg-frequency",
&size);
> +				of_node_put(qe);
> +				of_node_put(brg);
> +				return *prop;

NULL check here (yes, I know that the old code didn't check).

> +			}
> +		} else {
> +			*brg_source =3D brg_src + QE_CLK1 - 1;
> +			clocks =3D of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> +			prop =3D of_get_property(clocks,
> +						"#clock-cells", &size);
> +			/*
> +			 * clock-cells =3D 1 only supported right now.
> +			 */
> +			if (*prop !=3D 1)

Again check for NULL (and possibly size).

> +				return 0;
> +			prop =3D of_get_property(clocks,
> +						"clock-frequency",
&size);
> +
> +			brg_input_freq =3D *(prop+(brg_src - 1));

And again.

> +			of_node_put(clocks);
> +			of_node_put(brg);
> +			return brg_input_freq;
> +		}
> +	}
>  	return brg_clk;
>  }
--
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply

* Re: [PATCH 2/2] wrapper: Treat NULL as root node in devp_offset; add devp_offset_find().
From: David Gibson @ 2007-12-17  5:43 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071211212305.GB3661@loki.buserror.net>

On Tue, Dec 11, 2007 at 03:23:05PM -0600, Scott Wood wrote:
> Many operations, as currently used in the wrapper, assume they can
> pass NULL and have it be treated as the root node.  However, libfdt-wrapper
> converts NULL to -1, which is only appropriate when searching for nodes,
> and will cause an error otherwise.

Hrm.  AFAICT "many" in this case, means three (being calls to
create_node() in devtree.c, main.c and planetcore.c).

Still I guess this patch is ok for now.  I futgure I'd like to shrink
the wrapper down and make the general interface be as close as
possible to the native libfdt interface.

> Signed-off-by: Scott Wood <scottwood@freescale.com>

Acked-by: David Gibson <david@gibson.dropbear.id.au>

-- 
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/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Poonam Aggrwal @ 2007-12-17  5:40 UTC (permalink / raw)
  To: Timur Tabi; +Cc: linuxppc-dev, Poonam_Aggrwal-b10812
In-Reply-To: <475D89E1.4040107@freescale.com>

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

Thanx Tabi for your comments.
Sorry I was on leave for the last week, so could not reply in time.

Shall make the changes you suggested and repost the patch.

Regards
Poonam



On 12/11/07, Timur Tabi <timur@freescale.com> wrote:
>
> Poonam_Aggrwal-b10812 wrote:
>
> > +                     qe = of_find_node_by_type(NULL, "qe");
> > +                     if (qe) {
> > +                             unsigned int size;
> > +                             prop = of_get_property
> > +                                             (qe, "brg-frequency",
> &size);
> > +                             of_node_put(qe);
> > +                             of_node_put(brg);
> > +                             return *prop;
> > +                     }
>
> Only very recent versions of U-Boot set the brg-frequency property, so you
> need
> to check for situations where "*prop" is 0.  If it is, then you need to
> take the
> QE's bus-frequency property and divide it by two.  See my ucc_uart driver
> for an
> example.
>
> And PowerPC-specific patches should not be cross-posted to linux-kernel.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

[-- Attachment #2: Type: text/html, Size: 3099 bytes --]

^ permalink raw reply

* dtc: Don't build tests as part of "all"
From: David Gibson @ 2007-12-17  5:39 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev

Currently "make all" for dtc will build (but not run) the testcase
binaries.  This is a problem for cross compiles, because building the
tests will attempt to run the dumptrees utility on the host system,
which won't work if it's cross-compiled of course.

Although it would be possible to separately build host binaries,
there's not a lot of value in doing so since we don't have a facility
for cross-executing the testsuite anyway.

Therefore, remove the tests from the "all" target.  It will still, of
course, be build as a prerequisite to "make check" which will run the
testsuite.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile	2007-12-17 16:34:48.000000000 +1100
+++ dtc/Makefile	2007-12-17 16:34:57.000000000 +1100
@@ -46,7 +46,7 @@ else
 DEPTARGETS = $(filter-out $(NODEPTARGETS),$(MAKECMDGOALS))
 endif
 
-all: dtc ftdump libfdt tests
+all: dtc ftdump libfdt
 
 install: all
 	@$(VECHO) INSTALL

-- 
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] Fix cross-compile building
From: David Gibson @ 2007-12-17  5:39 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger, stuarth
In-Reply-To: <A388C2C2-2452-4E70-A5DA-F61B0E3A2B22@kernel.crashing.org>

On Thu, Dec 13, 2007 at 11:57:48PM -0600, Kumar Gala wrote:
> 
> On Dec 7, 2007, at 6:36 PM, David Gibson wrote:
> 
> > On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> >> From: Stuart Hughes <stuarth@freescale.com>
> >>
> >> This patch allows you to build the DTC source without making the
> >> tests directory.  This is necessary when cross compiling as the
> >> dumptest (and other) files cannot be run/used on the host system.
> >> To use this use: 'make TESTS='
> >
> > I think this is a silly way of doing this.  Instead create a new
> > target which builds everything but the tests.
> >
> > Say,
> >
> > 	all: cross tests
> >
> > 	cross: dtc ftdump libfdt
> 
> shouldn't we do this the other way around, it seems odd to build the  
> tests always or at least as part of the all target.

Hrm.  Yeah, I guess so.

The idea was to encourage the tests to be used as much as possible,
but I guess there's not all that much value to building them without
running them.

Patch forthcoming.

-- 
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: USB configuration
From: Misbah khan @ 2007-12-17  5:34 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <BLU106-W35DC430E02A0A1798D8B95CA650@phx.gbl>


I have configured for mass storage device still i am not getting the debug
msg that the kernel has detected the pen drive (after i connect the pen
drive ).

  " Initializing USB Mass Storage driver...
     usbcore: registered new driver usb-storage
     USB Mass Storage support registered.=20
  "

----misbah=20


Pedro Luis D. L. wrote:
>=20
>=20
>> From: misbah_khan@engineer.com
>> To: linuxppc-embedded@ozlabs.org
>> Subject: RE: USB configuration
>>=20
>>=20
>> I have inserted a USB card reader, and the following dmesg it shows ....=
.
>>=20
>> ------------------------------------------------------------------------=
-------
>> mpc8272ads: Init
>> PCI: Probing PCI hardware
>> PCI: Cannot allocate resource region 0 of device 0000:00:00.0
>> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
>> SCSI subsystem initialized
>> Linux Kernel Card Services
>>   options:  [pci] [cardbus]
>> usbcore: registered new driver usbfs
>> usbcore: registered new driver hub
>> Serial: CPM driver $Revision: 0.01 $
>> ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
>> ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
>> io scheduler noop registered
>> io scheduler anticipatory registered
>> io scheduler deadline registered
>> io scheduler cfq registered
>> loop: loaded (max 8 devices)
>> fs_enet.c:v1.0 (Aug 8, 2005)
>> fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
>> fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>> idebus=3Dxx
>> st: Version 20041025, fixed bufsize 32768, s/g segs 256
>> osst :I: Tape driver with OnStream support version 0.99.1
>> osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
>> ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
>> ohci_hcd: block sizes: ed 64 td 64
>> drivers/usb/serial/usb-serial.c: USB Serial support registered for
>> Generic
>> usbcore: registered new driver usbserial_generic
>> usbcore: registered new driver usbserial
>> drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
>> NET: Registered protocol family 2
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> NET: Registered protocol family 1
>> NET: Registered protocol family 17
>> IP-Config: Complete:
>>       device=3Deth1, addr=3D192.168.33.136, mask=3D255.255.248.0,
>> gw=3D192.168.32.47,
>>      host=3Dcashel, domain=3D, nis-domain=3D(none),
>>      bootserver=3D192.168.33.96, rootserver=3D192.168.33.96, rootpath=3D
>> Looking up port of RPC 100003/2 on 192.168.33.96
>> Looking up port of RPC 100005/1 on 192.168.33.96
>> VFS: Mounted root (nfs filesystem).
>> Freeing unused kernel memory: 104k init
>> ------------------------------------------------------------------------=
--------------
>>=20
>=20
> It looks like it is well configured, because the usbfs and hub are loaded=
.
> You could check in your kernel configuration that you enabled USB Mass
> storage driver and attached a pen drive as I suggested before.
> Another possibility is to insert a card in the USB card reader. Then you
> should be able to see with dmesg if it is recognized.
>=20
> Pedro.
>=20
>> This doesent gives me the clear explaination of whether USB is working
>> properly....
>>=20
>> I would appreciate if you could share with me the basic steps to be
>> followed
>> to confirm that the USB support that i had configured is being tested in
>> all
>> aspects.
>>=20
>> Misbah
>>=20
>> Pedro Luis D. L. wrote:
>>>=20
>>>=20
>>>=20
>>>> Date: Thu, 6 Dec 2007 05:27:14 -0800
>>>> From: misbah_khan@engineer.com
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: USB configuration
>>>>=20
>>>>=20
>>>> HI all ...
>>>=20
>>> Hi,
>>>=20
>>>> I have configured the Montavista Kernel for USB support and for
>>>> PPC8272-ADS
>>>> board I need to know that how could i test that my USB is working ????
>>>>=20
>>>=20
>>> Try to attach an USB device, like a pendrive,  to an USB port. Then
>>> type:=20
>>> dmesg | tail
>>>=20
>>> If the USB support is working properly, you should see some output
>>> saying
>>> which device have you attached and where is it mapped.
>>> If you plug a memory stick, you can try to mount it and check that the
>>> filesystem is correct.
>>>=20
>>> Pedro.
>>>=20
>>>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>>>> file
>>>> under it ????
>>>>=20
>>>>=20
>>>> its also creating the directory :- /sys/bus/usb/   but doesent contain
>>>> any
>>>> file under it ????
>>>>=20
>>>>=20
>>>> Please let me know the procedure to test whether my USB configuration
>>>> is
>>>> all
>>>> right ????
>>>>=20
>>>> Thank u=20
>>>> Misbah <><
>>>> --=20
>>>> View this message in context:
>>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14192347
>>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>>=20
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>> _________________________________________________________________
>>> Tecnolog=C3=ADa, moda, motor, viajes,=E2=80=A6suscr=C3=ADbete a nuestro=
s boletines para
>>> estar a la =C3=BAltima
>>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWCM=
aintenance&Brand=3DWL&RU=3Dhttp%3a%2f%2fmail.live.com
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>>=20
>>=20
>> --=20
>> View this message in context:
>> http://www.nabble.com/USB-configuration-tf4956061.html#a14206951
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>=20
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
> _________________________________________________________________
> MSN Video.=20
> http://video.msn.com/?mkt=3Des-es
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

--=20
View this message in context: http://www.nabble.com/USB-configuration-tp141=
92347p14370084.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: Device Tree updates for xilinx.
From: David Gibson @ 2007-12-17  5:21 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217045726.DD1881298046@mail127-sin.bigfish.com>

On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
> 
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference?  For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version.  So for the
> microblaze, I'd prefer something like:
> 
> xlnx,microblaze-6.00.b

Sounds reasonable.

> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.

Well, we could list both forms, but PowerPC,405 should be included
since it's an established name.  There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.

With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s).  In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files.  So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.

In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.

-- 
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][RFC] MPC8360E-RDK: Device tree and board file
From: David Gibson @ 2007-12-17  5:14 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071215162331.GA24999@localhost.localdomain>

On Sat, Dec 15, 2007 at 07:23:31PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 12:42:18PM -0600, Kumar Gala wrote:
[snip]
> +	soc8360@e0000000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";
> +		ranges = <0 0xe0000000 0x00100000>;
> +		reg = <0xe0000000 0x00000200>;
> +		/* filled by u-boot */
> +		bus-frequency = <0>;
> +
> +		wdt@200 {
> +			device_type = "watchdog";

Drop this device_type.

> +			compatible = "mpc83xx_wdt";
> +			reg = <0x200 0x100>;
> +		};
> +
> +		i2c@3000 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			device_type = "i2c";

And this one.

[snip]
> +		crypto@30000 {
> +			device_type = "crypto";
> +			model = "SEC2";
> +			compatible = "talitos";

This device_type/compatible/model stuff is also crap, although I
suspect it needs to be fixed in the driver, as gianfar (finally) was.

[snip]
> +		ipic: pic@700 {
> +			#address-cells = <0>;
> +			#interrupt-cells = <2>;
> +			interrupt-controller;
> +			reg = <0x700 0x100>;
> +			device_type = "ipic";

And drop this device_type.

[snip]
> +	qe@e0100000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "qe";

And this one.

This node needs a "compatible" too.

> +		model = "QE";
> +		ranges = <0 0xe0100000 0x00100000>;
> +		reg = <0xe0100000 0x480>;
> +		/* filled by u-boot */
> +		brg-frequency = <0>;
> +		bus-frequency = <0>;

This should probably be clock-frequency, not bus-frequency.  After
all, it's a bus node, what other sort of frequency would it be.

> +		muram@10000 {
> +			device_type = "muram";

And this device_type needs to go, too.

> +			ranges = <0 0x00010000 0x0000c000>;
> +
> +			data-only@0 {
> +				reg = <0 0xc000>;
> +			};
> +		};
> +
> +		spi@4c0 {
> +			device_type = "spi";

And this one.

[snip]

> +		usb@6c0 {
> +			device_type = "usb";

And this one.

> +			compatible = "qe_udc";
> +			reg = <0x6c0 0x40 0x8b00 0x100>;
> +			interrupts = <11>;
> +			interrupt-parent = <&qeic>;
> +			mode = "slave";
> +		};

[snip]
> +		mdio@2120 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x2120 0x18>;
> +			device_type = "mdio";

And this one.

> +			compatible = "ucc_geth_phy";
> +
> +			phy1: ethernet-phy@1 {
> +				reg = <1>;
> +				device_type = "ethernet-phy";
> +			};

These phy nodes have basically no information in them.  PHY nodes are
optional - only include them if they actually have something useful to
say (which would mean at least a compatible property).

[snip]
> +		qeic: qeic@80 {
> +			#address-cells = <0>;
> +			#interrupt-cells = <1>;
> +			interrupt-controller;
> +			device_type = "qeic";

Drop this device_type, too.

And this node, too, needs a "compatible" property.  Oh, and the node
name should be "interrupt-controller@80" by the generic names
convention.

> +			reg = <0x80 0x80>;
> +			big-endian;
> +			interrupts = <32 8 33 8>;
> +			interrupt-parent = <&ipic>;
> +		};
> +	};
> +};

-- 
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: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17  4:58 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071216070404.GK21311@localhost.localdomain>

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


Since there don't seem to be any examples of this in the tree: do you have a format preference?  For the rest of the compatible lists, I'm using something like: xlnx,ipname-version.  So for the microblaze, I'd prefer something like:

xlnx,microblaze-6.00.b

For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be more in character than PowerPC,405.

Steve

-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sat 12/15/2007 11:04 PM
To: Stephen Neuendorffer
Cc: Grant Likely; Michal Simek; John Williams; linuxppc-dev@ozlabs.org; git
Subject: Re: Device Tree updates for xilinx.
 
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:

> 
> For reference, below is the device tree for a Virtex2Pro design.  Except
> for the changes noted above, this is entirely automatically generated.
> 
> Steve
> 
> / {
> 	mem_size_cells: #address-cells = <1>;
> 	#size-cells = <1>;
> 	compatible = "xlnx,virtex";
> 	model = "testing";
> 	DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> 		device_type = "memory";
> 		reg = < 0 memsize:10000000 >;
> 	} ;
> 	chosen {
> 		bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> 	} ;
> 	cpus {
> 		#address-cells = <1>;
> 		#cpus = <1>;
> 		#size-cells = <0>;
> 		PowerPC,405@0 {

I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere.  I think this will
make your generator simpler, too.

-- 
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



[-- Attachment #2: Type: text/html, Size: 3744 bytes --]

^ permalink raw reply

* RE: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Stephen Neuendorffer @ 2007-12-17  4:48 UTC (permalink / raw)
  To: Grant Likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <fa686aa40712162030q6f0e6d87j5e6e5379cbd0d54e@mail.gmail.com>

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



Compound devices that actually have their own shared registers should do something different.  Likely they'll need some sort of data synchronization anyway.  It seems that by far the common case here is to going to be to just have aggregation, and I don't see any reason that can't be handled by a common 'pseudo-bus'.


Steve

-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Sun 12/16/2007 8:30 PM
To: Stephen Neuendorffer; grant.likely@secretlab.ca; simekm2@fel.cvut.cz; jwilliams@itee.uq.edu.au; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
 
On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does.  In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works.  This requires having a valid compatible node, and all the other things that a bus normally has.  I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.

I'd prefer something like "xlnx,<ip-name>-group".  "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices.  What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

^ permalink raw reply

* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17  4:30 UTC (permalink / raw)
  To: Stephen Neuendorffer, grant.likely, simekm2, jwilliams,
	linuxppc-dev
In-Reply-To: <20071217041455.GA3477@localhost.localdomain>

On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does.  In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works.  This requires having a valid compatible node, and all the other things that a bus normally has.  I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.

I'd prefer something like "xlnx,<ip-name>-group".  "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices.  What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?

>
> > 3) Uartlite requires a port-number property for the console to work.
>
> Why?  In general we try to avoid magical sequence numbers - cell-index
> should *only* be used when it's needed to index or program some shared
> register.

Aliases is probably the correct construct for this.  port-number was a
bad idea and I never should have gone that direction.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: David Gibson @ 2007-12-17  4:14 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20071213234151.D0B3DE80061@mail20-sin.bigfish.com>

On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> This now better describes what the UBoot device tree generator actually does.  In particular:
> 
> 1) Nodes have a label derived from the device name, and a node name
> derived from the device type.
> 2) Usage of compound nodes (representing more than one device in the same IP) which actually works.  This requires having a valid compatible node, and all the other things that a bus normally has.  I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.

I'm not sure I like this xlnx,compound business, although maybe it's
the best you can do.

> 3) Uartlite requires a port-number property for the console to work.

Why?  In general we try to avoid magical sequence numbers - cell-index
should *only* be used when it's needed to index or program some shared
register.

-- 
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 v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: David Gibson @ 2007-12-17  3:59 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071212225429.GB19027@loki.buserror.net>

On Wed, Dec 12, 2007 at 04:54:29PM -0600, Scott Wood wrote:
> This board is also resold by Freescale under the names
> "QUICCStart MPC8248 Evaluation System" and "CWH-PPC-8248N-VE".

[snip]
> +	localbus {

Should be localbus@f0010100.

> +		compatible = "fsl,ep8248e-localbus",
> +		             "fsl,mpc8248-localbus",
> +		             "fsl,pq2-localbus";
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		reg = <f0010100 40>;
> +
> +		ranges = <0 0 fc000000 04000000
> +		          1 0 fa000000 00008000>;
> +
> +		flash@0,3800000 {
> +			compatible = "cfi-flash";
> +			reg = <0 3800000 800000>;
> +			bank-width = <4>;
> +			device-width = <2>;
> +		};
> +
> +		bcsr@1,0 {
> +			#address-cells = <2>;
> +			#size-cells = <1>;
> +			reg = <1 0 10>;
> +			compatible = "fsl,ep8248e-bcsr";
> +			ranges;
> +
> +			mdio {

As I think I said about another tree, this mdio-under-bcsr arrangement
is pretty strange.  What's going on here.


> +				device_type = "mdio";
> +				compatible = "fsl,ep8248e-mdio-bitbang";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <1 8 1>;
> +
> +				PHY0: ethernet-phy@0 {
> +					interrupt-parent = <&PIC>;
> +					reg = <0>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				PHY1: ethernet-phy@1 {
> +					interrupt-parent = <&PIC>;
> +					reg = <1>;
> +					device_type = "ethernet-phy";
> +				};
> +			};
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0 0>;
> +	};
> +
> +	soc@f0000000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";

Ditch the device_type.

-- 
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 v2 1/3] 8xx: Analogue & Micro Adder875 board support.
From: David Gibson @ 2007-12-17  3:57 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071212225427.GA19027@loki.buserror.net>

On Wed, Dec 12, 2007 at 04:54:27PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts b/arch/powerpc/boot/dts/adder875-redboot.dts
> new file mode 100644
> index 0000000..4d28220
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/adder875-redboot.dts
[snip]
> diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts b/arch/powerpc/boot/dts/adder875-uboot.dts
> new file mode 100644
> index 0000000..33d198c
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/adder875-uboot.dts

Having two different device trees for the different firmwares is
pretty yucky, and could be a pain in the bum for synchronization of
fixes.  Can't you have a common tree, and just poke the places that
are differently configured by the two firmwares from the bootwrapper.

A helper function that adjusts soc, localbus, pci and whatever else is
necessary based on the immrbase could be useful for other fsl
platforms, too.

-- 
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

* libfdt: Add more documentation (patch the seventh)
From: David Gibson @ 2007-12-17  3:42 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev

This patch adds more documenting comments to libfdt.h.  Specifically,
these document the read/write functions (not including fdt_open_into()
and fdt_pack(), for now).

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h	2007-12-12 09:20:48.000000000 +1100
+++ dtc/libfdt/libfdt.h	2007-12-12 23:31:39.000000000 +1100
@@ -797,23 +797,242 @@ int fdt_finish(void *fdt);
 int fdt_open_into(const void *fdt, void *buf, int bufsize);
 int fdt_pack(void *fdt);
 
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @addres, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therfore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therfore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_del_mem_rsv(void *fdt, int n);
 
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creeating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_setprop(void *fdt, int nodeoffset, const char *name,
 		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
 				   uint32_t val)
 {
 	val = cpu_to_fdt32(val);
 	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
 }
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 #define fdt_setprop_string(fdt, nodeoffset, name, str) \
 	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
 int fdt_add_subnode_namelen(void *fdt, int parentoffset,
 			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
 int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_del_node(void *fdt, int nodeoffset);
 
 /**********************************************************************/

-- 
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

* libfdt: Add more documentation (patch the sixth)
From: David Gibson @ 2007-12-17  3:41 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev

This patch adds some more documenting comments to libfdt.h.
Specifically this documents all the write-in-place functions.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h	2007-12-11 14:23:09.000000000 +1100
+++ dtc/libfdt/libfdt.h	2007-12-11 14:40:11.000000000 +1100
@@ -655,8 +655,65 @@ int fdt_node_offset_by_compatible(const 
 /* Write-in-place functions                                           */
 /**********************************************************************/
 
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
 			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
 					   const char *name, uint32_t val)
 {
@@ -664,7 +721,54 @@ static inline int fdt_setprop_inplace_ce
 	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
 }
 
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
 int fdt_nop_node(void *fdt, int nodeoffset);
 
 /**********************************************************************/

-- 
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 1/2] wrapper: rename offset in offset_devp().
From: David Gibson @ 2007-12-17  0:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071212154528.7aaaa829.sfr@canb.auug.org.au>

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

On Wed, Dec 12, 2007 at 03:45:28PM +1100, Stephen Rothwell wrote:
> On Tue, 11 Dec 2007 15:23:04 -0600 Scott Wood <scottwood@freescale.com> wrote:
> >
> >  #define offset_devp(off)	\
> >  	({ \
> > -		int offset = (off); \
> > -		check_err(offset) ? NULL : (void *)(offset+1); \
> > +		int _offset = (off); \
> > +		check_err(_offset) ? NULL : (void *)(_offset+1); \
> >  	})
> 
> Just wondering if this could be a static inline function?

Alas, not really.  If we did that, then the __FUNCTION__ and __LINE__
we use in the error message inside check_err() would always refer to
the offset_devp() function, which would be substantially less useful
than referring to the function which invoked the offset_devp() macro.

-- 
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

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

^ permalink raw reply

* Re: [PATCH 1/2] wrapper: rename offset in offset_devp().
From: David Gibson @ 2007-12-17  0:40 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071211212303.GA3661@loki.buserror.net>

On Tue, Dec 11, 2007 at 03:23:04PM -0600, Scott Wood wrote:
> fdt_wrapper_create_node passes a variable called offset to offset_devp(),
> which uses said parameter to initialize a local variable called offset.
> 
> Due to one of the odder aspects of the C language, the result is an
> undefined variable, with no error or warning.

Ouch, nasty!  Good catch.

> Signed-off-by: Scott Wood <scottwood@freescale.com>

Acked-by: David Gibson <david@gibson.dropbear.id.au>

-- 
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] Fix sleep on powerbook 3400
From: Paul Mackerras @ 2007-12-17  0:30 UTC (permalink / raw)
  To: linuxppc-dev

Sleep on the powerbook 3400 has been broken since the change that made
powerbook_sleep_3400 call pmac_suspend_devices(), which disables
interrupts.  There are a couple of loops in powerbook_sleep_3400 that
depend on interrupts being enabled, and in fact it has to have
interrupts enabled at the point of going to sleep since it is an
interrupt from the PMU that wakes it up.

This fixes it by using pmu_wait_complete() instead of a spinloop, and
by explicitly enabling interrupts before putting the CPU into sleep
mode (which is OK since all interrupts except the PMU interrupt have
been disabled at the interrupt controller by this stage).

This also changes the logic to keep putting the CPU into sleep mode
until the completion of the interrupt transaction from the PMU that
signals the end of sleep.  Also, we now call pmu_unlock() before sleep
so that the via_pmu_interrupt() code can process the interrupt event
from the PMU properly.

Signed-off-by: Paul Mackerras <paulus@samba.org>
---

diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 35e1f22..6f91723 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2276,7 +2276,7 @@ powerbook_sleep_3400(void)
 {
 	int ret, i, x;
 	unsigned int hid0;
-	unsigned long p;
+	unsigned long p, msr;
 	struct adb_request sleep_req;
 	void __iomem *mem_ctrl;
 	unsigned int __iomem *mem_ctrl_sleep;
@@ -2315,10 +2315,10 @@ powerbook_sleep_3400(void)
 
 	/* Ask the PMU to put us to sleep */
 	pmu_request(&sleep_req, NULL, 5, PMU_SLEEP, 'M', 'A', 'T', 'T');
-	while (!sleep_req.complete)
-		mb();
+	pmu_wait_complete(&sleep_req);
+	pmu_unlock();
 
-	pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,1);
+	pmac_call_feature(PMAC_FTR_SLEEP_STATE, NULL, 0, 1);
 
 	/* displacement-flush the L2 cache - necessary? */
 	for (p = KERNELBASE; p < KERNELBASE + 0x100000; p += 0x1000)
@@ -2329,18 +2329,19 @@ powerbook_sleep_3400(void)
 	hid0 = mfspr(SPRN_HID0);
 	hid0 = (hid0 & ~(HID0_NAP | HID0_DOZE)) | HID0_SLEEP;
 	mtspr(SPRN_HID0, hid0);
-	mtmsr(mfmsr() | MSR_POW | MSR_EE);
-	udelay(10);
+	local_irq_enable();
+	msr = mfmsr() | MSR_POW;
+	while (asleep) {
+		mb();
+		mtmsr(msr);
+		isync();
+	}
+	local_irq_disable();
 
 	/* OK, we're awake again, start restoring things */
 	out_be32(mem_ctrl_sleep, 0x3f);
-	pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,0);
+	pmac_call_feature(PMAC_FTR_SLEEP_STATE, NULL, 0, 0);
 	pbook_pci_restore();
-	pmu_unlock();
-
-	/* wait for the PMU interrupt sequence to complete */
-	while (asleep)
-		mb();
 
 	pmac_wakeup_devices();
 	pbook_free_pci_save();

^ permalink raw reply related

* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-17  0:00 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <9618c94dbc228065db8bd99fbf6b7ba6@kernel.crashing.org>

On Sun, Dec 16, 2007 at 11:44:50PM +0100, Segher Boessenkool wrote:
> >> Hopefully some version that stores path strings in the properties
> >> in /aliases, and not phandles.  Or does that current version of DTC
> >> do that correctly already, and just has an inconvenient source
> >> syntax?
> >
> > I don't think anyone's actually gone and generated phandles in
> > /aliases, although it was suggested early on.  The syntax is
> > 	foo = < &bar >;
> > to generate a phandle and
> > 	foo = &bar;
> > to generate a path.
> 
> Ah, I see.
> 
> > I was a bit worried about confusion between these forms, but at least
> > Kumar and myself came up with this syntax independently, which
> > suggests it's not too surprising to most people, and no-one had any
> > other suggestions.
> 
> I think I suggested it before, but anyway:
> 
> how about you write
> 
> 	aliases {
> 		foo = "/the/path/to/foo";
> 	};
> 
> and then you can use  &foo  in the rest of the DTS to refer to the
> phandle (or path string, as it turns out :-) ) of the node?  I.e.,
> use the aliases node to _generate_ aliases.
> 
> Seems simpler than the current thing to me.

No.  First, it's much nicer to have the label definition local to the
node it's labelling, rather than having to keep looking over at the
aliases node.  Second, this syntax can only generate labels to nodes,
whereas the current syntax can label properties, their contents and
reserve entries as well.  Third, we absolutely don't want to ditch the
current well-established and widely used syntax.

What I do want to add is a way of making aliases from labels without
having to explicitly fill in the aliases node.  Perhaps something like
	EMAC0[ethernet0]: ethernet@... { ... };
which would be equivalent to 
	EMAC0: ethernet@... { ... };
	...
	aliases { ethernet0 = &EMAC0; };

-- 
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] 4xx: Add aliases node to 4xx dts files
From: Segher Boessenkool @ 2007-12-16 22:44 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216223342.GD26307@localhost.localdomain>

>> Hopefully some version that stores path strings in the properties
>> in /aliases, and not phandles.  Or does that current version of DTC
>> do that correctly already, and just has an inconvenient source
>> syntax?
>
> I don't think anyone's actually gone and generated phandles in
> /aliases, although it was suggested early on.  The syntax is
> 	foo = < &bar >;
> to generate a phandle and
> 	foo = &bar;
> to generate a path.

Ah, I see.

> I was a bit worried about confusion between these forms, but at least
> Kumar and myself came up with this syntax independently, which
> suggests it's not too surprising to most people, and no-one had any
> other suggestions.

I think I suggested it before, but anyway:

how about you write

	aliases {
		foo = "/the/path/to/foo";
	};

and then you can use  &foo  in the rest of the DTS to refer to the
phandle (or path string, as it turns out :-) ) of the node?  I.e.,
use the aliases node to _generate_ aliases.

Seems simpler than the current thing to me.


Segher

^ permalink raw reply

* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 22:33 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <f3ddb435a7a71cea8362ed73eb154200@kernel.crashing.org>

On Sun, Dec 16, 2007 at 07:10:02PM +0100, Segher Boessenkool wrote:
> > Applied to my candidates tree.  Though I'd really like dtc to be merged
> > so that we can figure out what the in-kernel version will support.
> 
> Hopefully some version that stores path strings in the properties
> in /aliases, and not phandles.  Or does that current version of DTC
> do that correctly already, and just has an inconvenient source
> syntax?

I don't think anyone's actually gone and generated phandles in
/aliases, although it was suggested early on.  The syntax is
	foo = < &bar >;
to generate a phandle and
	foo = &bar;
to generate a path.

I was a bit worried about confusion between these forms, but at least
Kumar and myself came up with this syntax independently, which
suggests it's not too surprising to most people, and no-one had any
other suggestions.

-- 
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox