LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3 v3] mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
From: Stefan Roese @ 2009-04-16 12:10 UTC (permalink / raw)
  To: linuxppc-dev, linux-mtd; +Cc: devicetree-discuss

It's easier to find bindings descriptions in separate files. So let's factor out
the MTD physmap bindings into Documentation/powerpc/dts-bindings/mtd-physmap.txt
to not clutter booting-without-of.txt more.

Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Changes in ver3:
- Added short patch desciption to commit message.

 Documentation/powerpc/booting-without-of.txt       |   89 +++-----------------
 Documentation/powerpc/dts-bindings/mtd-physmap.txt |   63 ++++++++++++++
 2 files changed, 75 insertions(+), 77 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 0ab0230..d16b7a1 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -43,12 +43,11 @@ Table of Contents
     2) Representing devices without a current OF specification
       a) PHY nodes
       b) Interrupt controllers
-      c) CFI or JEDEC memory-mapped NOR flash
-      d) 4xx/Axon EMAC ethernet nodes
-      e) Xilinx IP cores
-      f) USB EHCI controllers
-      g) MDIO on GPIOs
-      h) SPI busses
+      c) 4xx/Axon EMAC ethernet nodes
+      d) Xilinx IP cores
+      e) USB EHCI controllers
+      f) MDIO on GPIOs
+      g) SPI busses
 
   VII - Marvell Discovery mv64[345]6x System Controller chips
     1) The /system-controller node
@@ -999,7 +998,7 @@ compatibility.
       translation of SOC addresses for memory mapped SOC registers.
     - bus-frequency: Contains the bus frequency for the SOC node.
       Typically, the value of this field is filled in by the boot
-      loader. 
+      loader.
 
 
   Recommended properties:
@@ -1287,71 +1286,7 @@ platforms are moved over to use the flattened-device-tree model.
 		device_type = "open-pic";
 	};
 
-   c) CFI or JEDEC memory-mapped NOR flash
-
-    Flash chips (Memory Technology Devices) are often used for solid state
-    file systems on embedded devices.
-
-     - compatible : should contain the specific model of flash chip(s)
-       used, if known, followed by either "cfi-flash" or "jedec-flash"
-     - reg : Address range of the flash chip
-     - bank-width : Width (in bytes) of the flash bank.  Equal to the
-       device width times the number of interleaved chips.
-     - device-width : (optional) Width of a single flash chip.  If
-       omitted, assumed to be equal to 'bank-width'.
-     - #address-cells, #size-cells : Must be present if the flash has
-       sub-nodes representing partitions (see below).  In this case
-       both #address-cells and #size-cells must be equal to 1.
-
-    For JEDEC compatible devices, the following additional properties
-    are defined:
-
-     - vendor-id : Contains the flash chip's vendor id (1 byte).
-     - device-id : Contains the flash chip's device id (1 byte).
-
-    In addition to the information on the flash bank itself, the
-    device tree may optionally contain additional information
-    describing partitions of the flash address space.  This can be
-    used on platforms which have strong conventions about which
-    portions of the flash are used for what purposes, but which don't
-    use an on-flash partition table such as RedBoot.
-
-    Each partition is represented as a sub-node of the flash device.
-    Each node's name represents the name of the corresponding
-    partition of the flash device.
-
-    Flash partitions
-     - reg : The partition's offset and size within the flash bank.
-     - label : (optional) The label / name for this flash partition.
-       If omitted, the label is taken from the node name (excluding
-       the unit address).
-     - read-only : (optional) This parameter, if present, is a hint to
-       Linux that this flash partition should only be mounted
-       read-only.  This is usually used for flash partitions
-       containing early-boot firmware images or data which should not
-       be clobbered.
-
-    Example:
-
-	flash@ff000000 {
-		compatible = "amd,am29lv128ml", "cfi-flash";
-		reg = <ff000000 01000000>;
-		bank-width = <4>;
-		device-width = <1>;
-		#address-cells = <1>;
-		#size-cells = <1>;
-		fs@0 {
-			label = "fs";
-			reg = <0 f80000>;
-		};
-		firmware@f80000 {
-			label ="firmware";
-			reg = <f80000 80000>;
-			read-only;
-		};
-	};
-
-    d) 4xx/Axon EMAC ethernet nodes
+    c) 4xx/Axon EMAC ethernet nodes
 
     The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
     the Axon bridge.  To operate this needs to interact with a ths
@@ -1499,7 +1434,7 @@ platforms are moved over to use the flattened-device-tree model.
 			   available.
 			   For Axon: 0x0000012a
 
-   e) Xilinx IP cores
+   d) Xilinx IP cores
 
    The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
    in Xilinx Spartan and Virtex FPGAs.  The devices cover the whole range
@@ -1761,7 +1696,7 @@ platforms are moved over to use the flattened-device-tree model.
       listed above, nodes for these devices should include a phy-handle
       property, and may include other common network device properties
       like local-mac-address.
-      
+
       iv) Xilinx Uartlite
 
       Xilinx uartlite devices are simple fixed speed serial ports.
@@ -1793,7 +1728,7 @@ platforms are moved over to use the flattened-device-tree model.
        - reg-offset : A value of 3 is required
        - reg-shift : A value of 2 is required
 
-    f) USB EHCI controllers
+    e) USB EHCI controllers
 
     Required properties:
       - compatible : should be "usb-ehci".
@@ -1819,7 +1754,7 @@ platforms are moved over to use the flattened-device-tree model.
 		   big-endian;
 	   };
 
-   g) MDIO on GPIOs
+   f) MDIO on GPIOs
 
    Currently defined compatibles:
    - virtual,gpio-mdio
@@ -1839,7 +1774,7 @@ platforms are moved over to use the flattened-device-tree model.
 			 &qe_pio_c 6>;
 	};
 
-    h) SPI (Serial Peripheral Interface) busses
+    g) SPI (Serial Peripheral Interface) busses
 
     SPI busses can be described with a node for the SPI master device
     and a set of child nodes for each SPI slave on the bus.  For this
diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
new file mode 100644
index 0000000..cd474f9
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
@@ -0,0 +1,63 @@
+CFI or JEDEC memory-mapped NOR flash
+
+Flash chips (Memory Technology Devices) are often used for solid state
+file systems on embedded devices.
+
+ - compatible : should contain the specific model of flash chip(s)
+   used, if known, followed by either "cfi-flash" or "jedec-flash"
+ - reg : Address range of the flash chip
+ - bank-width : Width (in bytes) of the flash bank.  Equal to the
+   device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single flash chip.  If
+   omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the flash has
+   sub-nodes representing partitions (see below).  In this case
+   both #address-cells and #size-cells must be equal to 1.
+
+For JEDEC compatible devices, the following additional properties
+are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+In addition to the information on the flash bank itself, the
+device tree may optionally contain additional information
+describing partitions of the flash address space.  This can be
+used on platforms which have strong conventions about which
+portions of the flash are used for what purposes, but which don't
+use an on-flash partition table such as RedBoot.
+
+Each partition is represented as a sub-node of the flash device.
+Each node's name represents the name of the corresponding
+partition of the flash device.
+
+Flash partitions
+ - reg : The partition's offset and size within the flash bank.
+ - label : (optional) The label / name for this flash partition.
+   If omitted, the label is taken from the node name (excluding
+   the unit address).
+ - read-only : (optional) This parameter, if present, is a hint to
+   Linux that this flash partition should only be mounted
+   read-only.  This is usually used for flash partitions
+   containing early-boot firmware images or data which should not
+   be clobbered.
+
+Example:
+
+	flash@ff000000 {
+		compatible = "amd,am29lv128ml", "cfi-flash";
+		reg = <ff000000 01000000>;
+		bank-width = <4>;
+		device-width = <1>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		fs@0 {
+			label = "fs";
+			reg = <0 f80000>;
+		};
+		firmware@f80000 {
+			label ="firmware";
+			reg = <f80000 80000>;
+			read-only;
+		};
+	};
-- 
1.6.2.3

^ permalink raw reply related

* [PATCH 3/3 v3] mtd/powerpc: Describe multiple "reg" tuples usage
From: Stefan Roese @ 2009-04-16 12:11 UTC (permalink / raw)
  To: linuxppc-dev, linux-mtd; +Cc: devicetree-discuss

Signed-off-by: Stefan Roese <sr@denx.de>
CC: Grant Likely <grant.likely@secretlab.ca>
---
Changes in ver3:
- Removed reference to Intel P30 parts
- Added exact chip compatible property for best practice.

 Documentation/powerpc/dts-bindings/mtd-physmap.txt |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
index cd474f9..667c9bd 100644
--- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
+++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
@@ -5,7 +5,9 @@ file systems on embedded devices.
 
  - compatible : should contain the specific model of flash chip(s)
    used, if known, followed by either "cfi-flash" or "jedec-flash"
- - reg : Address range of the flash chip
+ - reg : Address range(s) of the flash chip(s)
+   It's possible to (optionally) define multiple "reg" tuples so that
+   non-identical NOR chips can be described in one flash node.
  - bank-width : Width (in bytes) of the flash bank.  Equal to the
    device width times the number of interleaved chips.
  - device-width : (optional) Width of a single flash chip.  If
@@ -61,3 +63,18 @@ Example:
 			read-only;
 		};
 	};
+
+Here an example with multiple "reg" tuples:
+
+	flash@f0000000,0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "intel,PC48F4400P0VB", "cfi-flash";
+		reg = <0 0x00000000 0x02000000
+		       0 0x02000000 0x02000000>;
+		bank-width = <2>;
+		partition@0 {
+			label = "test-part1";
+			reg = <0 0x04000000>;
+		};
+	};
-- 
1.6.2.3

^ permalink raw reply related

* Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Artem Bityutskiy @ 2009-04-16 12:19 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <200904161405.04100.sr@denx.de>

On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote:
> This patchset adds support to handle multiple non-identical chips in one
> flash device tree node. It also adds concat support to physmap_of. This
> makes it possible to support e.g. the Intel P30 48F4400 chip which
> internally consists of 2 non-identical NOR chips on one die. Additionally
> partitions now can span over multiple chips:
> 
>     mtd: physmap_of: Add multiple regions and concatenation support
>     mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
>     mtd/powerpc: Describe multiple "reg" tuples usage
> 
> v2 addresses all comments from Grant Likely, including factoring out the
> MTD dts bindings documentation into a separate file.
> 
> v3 addresses all comments (again from Grant).

Sorry for my ignorance, but could you please explain why regions
exists as an MTD concept? Why different regions could not be
represented as different MTD devices? The benefit is - simplicity.

Thanks.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

^ permalink raw reply

* Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-16 12:52 UTC (permalink / raw)
  To: dedekind; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <1239884344.3390.213.camel@localhost.localdomain>

On Thursday 16 April 2009, Artem Bityutskiy wrote:
> On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote:
> > This patchset adds support to handle multiple non-identical chips in one
> > flash device tree node. It also adds concat support to physmap_of. This
> > makes it possible to support e.g. the Intel P30 48F4400 chip which
> > internally consists of 2 non-identical NOR chips on one die. Additionally
> > partitions now can span over multiple chips:
> >
> >     mtd: physmap_of: Add multiple regions and concatenation support
> >     mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
> >     mtd/powerpc: Describe multiple "reg" tuples usage
> >
> > v2 addresses all comments from Grant Likely, including factoring out the
> > MTD dts bindings documentation into a separate file.
> >
> > v3 addresses all comments (again from Grant).
>
> Sorry for my ignorance, but could you please explain why regions
> exists as an MTD concept? Why different regions could not be
> represented as different MTD devices? The benefit is - simplicity.

The result of these multiple "reg" tuples *is* multiple MTD devices. Not sure 
if this explains your comment/question. Please let me know if you still have 
some comments.

Thanks.

Best regards,
Stefan

^ permalink raw reply

* Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Grant Likely @ 2009-04-16 12:58 UTC (permalink / raw)
  To: dedekind; +Cc: linuxppc-dev, Stefan Roese, linux-mtd, devicetree-discuss
In-Reply-To: <1239884344.3390.213.camel@localhost.localdomain>

On Thu, Apr 16, 2009 at 6:19 AM, Artem Bityutskiy
<dedekind@infradead.org> wrote:
> On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote:
>> This patchset adds support to handle multiple non-identical chips in one
>> flash device tree node. It also adds concat support to physmap_of. This
>> makes it possible to support e.g. the Intel P30 48F4400 chip which
>> internally consists of 2 non-identical NOR chips on one die. Additionall=
y
>> partitions now can span over multiple chips:
>>
>> =9A =9A mtd: physmap_of: Add multiple regions and concatenation support
>> =9A =9A mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.tx=
t
>> =9A =9A mtd/powerpc: Describe multiple "reg" tuples usage
>>
>> v2 addresses all comments from Grant Likely, including factoring out the
>> MTD dts bindings documentation into a separate file.
>>
>> v3 addresses all comments (again from Grant).
>
> Sorry for my ignorance, but could you please explain why regions
> exists as an MTD concept? Why different regions could not be
> represented as different MTD devices? The benefit is - simplicity.

Trying to describe MTD partitions that span device boundaries in the
device tree is far simpler if a single node is used.  It is also a
common case for hardware designers to drop down multiple NOR devices
to be used as a single flash region, so it makes sense to describe it
as a single device.

g.

>
> Thanks.
>
> --
> Best regards,
> Artem Bityutskiy (=E2=C9=D4=C0=C3=CB=C9=CA =E1=D2=D4=A3=CD)
>
>



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

^ permalink raw reply

* Re: [PATCH 2/3 v3] mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
From: Grant Likely @ 2009-04-16 13:01 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <1239883857-17860-1-git-send-email-sr@denx.de>

Looks good, I'll pick this up

g.

On Thu, Apr 16, 2009 at 6:10 AM, Stefan Roese <sr@denx.de> wrote:
> It's easier to find bindings descriptions in separate files. So let's fac=
tor out
> the MTD physmap bindings into Documentation/powerpc/dts-bindings/mtd-phys=
map.txt
> to not clutter booting-without-of.txt more.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Changes in ver3:
> - Added short patch desciption to commit message.
>
> =A0Documentation/powerpc/booting-without-of.txt =A0 =A0 =A0 | =A0 89 +++-=
----------------
> =A0Documentation/powerpc/dts-bindings/mtd-physmap.txt | =A0 63 ++++++++++=
++++
> =A02 files changed, 75 insertions(+), 77 deletions(-)
> =A0create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation=
/powerpc/booting-without-of.txt
> index 0ab0230..d16b7a1 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -43,12 +43,11 @@ Table of Contents
> =A0 =A0 2) Representing devices without a current OF specification
> =A0 =A0 =A0 a) PHY nodes
> =A0 =A0 =A0 b) Interrupt controllers
> - =A0 =A0 =A0c) CFI or JEDEC memory-mapped NOR flash
> - =A0 =A0 =A0d) 4xx/Axon EMAC ethernet nodes
> - =A0 =A0 =A0e) Xilinx IP cores
> - =A0 =A0 =A0f) USB EHCI controllers
> - =A0 =A0 =A0g) MDIO on GPIOs
> - =A0 =A0 =A0h) SPI busses
> + =A0 =A0 =A0c) 4xx/Axon EMAC ethernet nodes
> + =A0 =A0 =A0d) Xilinx IP cores
> + =A0 =A0 =A0e) USB EHCI controllers
> + =A0 =A0 =A0f) MDIO on GPIOs
> + =A0 =A0 =A0g) SPI busses
>
> =A0 VII - Marvell Discovery mv64[345]6x System Controller chips
> =A0 =A0 1) The /system-controller node
> @@ -999,7 +998,7 @@ compatibility.
> =A0 =A0 =A0 translation of SOC addresses for memory mapped SOC registers.
> =A0 =A0 - bus-frequency: Contains the bus frequency for the SOC node.
> =A0 =A0 =A0 Typically, the value of this field is filled in by the boot
> - =A0 =A0 =A0loader.
> + =A0 =A0 =A0loader.
>
>
> =A0 Recommended properties:
> @@ -1287,71 +1286,7 @@ platforms are moved over to use the flattened-devi=
ce-tree model.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_type =3D "open-pic";
> =A0 =A0 =A0 =A0};
>
> - =A0 c) CFI or JEDEC memory-mapped NOR flash
> -
> - =A0 =A0Flash chips (Memory Technology Devices) are often used for solid=
 state
> - =A0 =A0file systems on embedded devices.
> -
> - =A0 =A0 - compatible : should contain the specific model of flash chip(=
s)
> - =A0 =A0 =A0 used, if known, followed by either "cfi-flash" or "jedec-fl=
ash"
> - =A0 =A0 - reg : Address range of the flash chip
> - =A0 =A0 - bank-width : Width (in bytes) of the flash bank. =A0Equal to =
the
> - =A0 =A0 =A0 device width times the number of interleaved chips.
> - =A0 =A0 - device-width : (optional) Width of a single flash chip. =A0If
> - =A0 =A0 =A0 omitted, assumed to be equal to 'bank-width'.
> - =A0 =A0 - #address-cells, #size-cells : Must be present if the flash ha=
s
> - =A0 =A0 =A0 sub-nodes representing partitions (see below). =A0In this c=
ase
> - =A0 =A0 =A0 both #address-cells and #size-cells must be equal to 1.
> -
> - =A0 =A0For JEDEC compatible devices, the following additional propertie=
s
> - =A0 =A0are defined:
> -
> - =A0 =A0 - vendor-id : Contains the flash chip's vendor id (1 byte).
> - =A0 =A0 - device-id : Contains the flash chip's device id (1 byte).
> -
> - =A0 =A0In addition to the information on the flash bank itself, the
> - =A0 =A0device tree may optionally contain additional information
> - =A0 =A0describing partitions of the flash address space. =A0This can be
> - =A0 =A0used on platforms which have strong conventions about which
> - =A0 =A0portions of the flash are used for what purposes, but which don'=
t
> - =A0 =A0use an on-flash partition table such as RedBoot.
> -
> - =A0 =A0Each partition is represented as a sub-node of the flash device.
> - =A0 =A0Each node's name represents the name of the corresponding
> - =A0 =A0partition of the flash device.
> -
> - =A0 =A0Flash partitions
> - =A0 =A0 - reg : The partition's offset and size within the flash bank.
> - =A0 =A0 - label : (optional) The label / name for this flash partition.
> - =A0 =A0 =A0 If omitted, the label is taken from the node name (excludin=
g
> - =A0 =A0 =A0 the unit address).
> - =A0 =A0 - read-only : (optional) This parameter, if present, is a hint =
to
> - =A0 =A0 =A0 Linux that this flash partition should only be mounted
> - =A0 =A0 =A0 read-only. =A0This is usually used for flash partitions
> - =A0 =A0 =A0 containing early-boot firmware images or data which should =
not
> - =A0 =A0 =A0 be clobbered.
> -
> - =A0 =A0Example:
> -
> - =A0 =A0 =A0 flash@ff000000 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "amd,am29lv128ml", "cfi-flas=
h";
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <ff000000 01000000>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bank-width =3D <4>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 device-width =3D <1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 fs@0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D "fs";
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0 f80000>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 firmware@f80000 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D"firmware";
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <f80000 80000>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read-only;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> - =A0 =A0 =A0 };
> -
> - =A0 =A0d) 4xx/Axon EMAC ethernet nodes
> + =A0 =A0c) 4xx/Axon EMAC ethernet nodes
>
> =A0 =A0 The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
> =A0 =A0 the Axon bridge. =A0To operate this needs to interact with a ths
> @@ -1499,7 +1434,7 @@ platforms are moved over to use the flattened-devic=
e-tree model.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 available.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For Axon: 0x0000012a
>
> - =A0 e) Xilinx IP cores
> + =A0 d) Xilinx IP cores
>
> =A0 =A0The Xilinx EDK toolchain ships with a set of IP cores (devices) fo=
r use
> =A0 =A0in Xilinx Spartan and Virtex FPGAs. =A0The devices cover the whole=
 range
> @@ -1761,7 +1696,7 @@ platforms are moved over to use the flattened-devic=
e-tree model.
> =A0 =A0 =A0 listed above, nodes for these devices should include a phy-ha=
ndle
> =A0 =A0 =A0 property, and may include other common network device propert=
ies
> =A0 =A0 =A0 like local-mac-address.
> -
> +
> =A0 =A0 =A0 iv) Xilinx Uartlite
>
> =A0 =A0 =A0 Xilinx uartlite devices are simple fixed speed serial ports.
> @@ -1793,7 +1728,7 @@ platforms are moved over to use the flattened-devic=
e-tree model.
> =A0 =A0 =A0 =A0- reg-offset : A value of 3 is required
> =A0 =A0 =A0 =A0- reg-shift : A value of 2 is required
>
> - =A0 =A0f) USB EHCI controllers
> + =A0 =A0e) USB EHCI controllers
>
> =A0 =A0 Required properties:
> =A0 =A0 =A0 - compatible : should be "usb-ehci".
> @@ -1819,7 +1754,7 @@ platforms are moved over to use the flattened-devic=
e-tree model.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 big-endian;
> =A0 =A0 =A0 =A0 =A0 };
>
> - =A0 g) MDIO on GPIOs
> + =A0 f) MDIO on GPIOs
>
> =A0 =A0Currently defined compatibles:
> =A0 =A0- virtual,gpio-mdio
> @@ -1839,7 +1774,7 @@ platforms are moved over to use the flattened-devic=
e-tree model.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &qe_pio_c 6>;
> =A0 =A0 =A0 =A0};
>
> - =A0 =A0h) SPI (Serial Peripheral Interface) busses
> + =A0 =A0g) SPI (Serial Peripheral Interface) busses
>
> =A0 =A0 SPI busses can be described with a node for the SPI master device
> =A0 =A0 and a set of child nodes for each SPI slave on the bus. =A0For th=
is
> diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documen=
tation/powerpc/dts-bindings/mtd-physmap.txt
> new file mode 100644
> index 0000000..cd474f9
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
> @@ -0,0 +1,63 @@
> +CFI or JEDEC memory-mapped NOR flash
> +
> +Flash chips (Memory Technology Devices) are often used for solid state
> +file systems on embedded devices.
> +
> + - compatible : should contain the specific model of flash chip(s)
> + =A0 used, if known, followed by either "cfi-flash" or "jedec-flash"
> + - reg : Address range of the flash chip
> + - bank-width : Width (in bytes) of the flash bank. =A0Equal to the
> + =A0 device width times the number of interleaved chips.
> + - device-width : (optional) Width of a single flash chip. =A0If
> + =A0 omitted, assumed to be equal to 'bank-width'.
> + - #address-cells, #size-cells : Must be present if the flash has
> + =A0 sub-nodes representing partitions (see below). =A0In this case
> + =A0 both #address-cells and #size-cells must be equal to 1.
> +
> +For JEDEC compatible devices, the following additional properties
> +are defined:
> +
> + - vendor-id : Contains the flash chip's vendor id (1 byte).
> + - device-id : Contains the flash chip's device id (1 byte).
> +
> +In addition to the information on the flash bank itself, the
> +device tree may optionally contain additional information
> +describing partitions of the flash address space. =A0This can be
> +used on platforms which have strong conventions about which
> +portions of the flash are used for what purposes, but which don't
> +use an on-flash partition table such as RedBoot.
> +
> +Each partition is represented as a sub-node of the flash device.
> +Each node's name represents the name of the corresponding
> +partition of the flash device.
> +
> +Flash partitions
> + - reg : The partition's offset and size within the flash bank.
> + - label : (optional) The label / name for this flash partition.
> + =A0 If omitted, the label is taken from the node name (excluding
> + =A0 the unit address).
> + - read-only : (optional) This parameter, if present, is a hint to
> + =A0 Linux that this flash partition should only be mounted
> + =A0 read-only. =A0This is usually used for flash partitions
> + =A0 containing early-boot firmware images or data which should not
> + =A0 be clobbered.
> +
> +Example:
> +
> + =A0 =A0 =A0 flash@ff000000 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "amd,am29lv128ml", "cfi-flas=
h";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <ff000000 01000000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bank-width =3D <4>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device-width =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fs@0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D "fs";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0 f80000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 firmware@f80000 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D"firmware";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <f80000 80000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read-only;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 };
> --
> 1.6.2.3
>
>



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

^ permalink raw reply

* Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Artem Bityutskiy @ 2009-04-16 13:09 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <200904161452.25393.sr@denx.de>

On Thu, 2009-04-16 at 14:52 +0200, Stefan Roese wrote:
> On Thursday 16 April 2009, Artem Bityutskiy wrote:
> > On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote:
> > > This patchset adds support to handle multiple non-identical chips in one
> > > flash device tree node. It also adds concat support to physmap_of. This
> > > makes it possible to support e.g. the Intel P30 48F4400 chip which
> > > internally consists of 2 non-identical NOR chips on one die. Additionally
> > > partitions now can span over multiple chips:
> > >
> > >     mtd: physmap_of: Add multiple regions and concatenation support
> > >     mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
> > >     mtd/powerpc: Describe multiple "reg" tuples usage
> > >
> > > v2 addresses all comments from Grant Likely, including factoring out the
> > > MTD dts bindings documentation into a separate file.
> > >
> > > v3 addresses all comments (again from Grant).
> >
> > Sorry for my ignorance, but could you please explain why regions
> > exists as an MTD concept? Why different regions could not be
> > represented as different MTD devices? The benefit is - simplicity.
> 
> The result of these multiple "reg" tuples *is* multiple MTD devices. Not sure 
> if this explains your comment/question. Please let me know if you still have 
> some comments.

OK, I was confused. In MTD there is a weird notion of "region".
See 'struct mtd_info':

        /* Data for variable erase regions. If numeraseregions is zero,
         * it means that the whole device has erasesize as given above.
         */
        int numeraseregions;
        struct mtd_erase_region_info *eraseregions;

in include/linux/mtd/mtd.h

I thought you use that, and wanted to realize why is that "region"
notion needed.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

^ permalink raw reply

* Re: [PATCH 3/3 v3] mtd/powerpc: Describe multiple "reg" tuples usage
From: Grant Likely @ 2009-04-16 13:23 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <1239883865-17915-1-git-send-email-sr@denx.de>

On Thu, Apr 16, 2009 at 6:11 AM, Stefan Roese <sr@denx.de> wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
> CC: Grant Likely <grant.likely@secretlab.ca>

Acked-by: Grant Likely <grant.likely@secretlab.ca>

I'll pick this one up too.

> ---
> Changes in ver3:
> - Removed reference to Intel P30 parts
> - Added exact chip compatible property for best practice.
>
> =A0Documentation/powerpc/dts-bindings/mtd-physmap.txt | =A0 19 ++++++++++=
++++++++-
> =A01 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documen=
tation/powerpc/dts-bindings/mtd-physmap.txt
> index cd474f9..667c9bd 100644
> --- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
> +++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
> @@ -5,7 +5,9 @@ file systems on embedded devices.
>
> =A0- compatible : should contain the specific model of flash chip(s)
> =A0 =A0used, if known, followed by either "cfi-flash" or "jedec-flash"
> - - reg : Address range of the flash chip
> + - reg : Address range(s) of the flash chip(s)
> + =A0 It's possible to (optionally) define multiple "reg" tuples so that
> + =A0 non-identical NOR chips can be described in one flash node.
> =A0- bank-width : Width (in bytes) of the flash bank. =A0Equal to the
> =A0 =A0device width times the number of interleaved chips.
> =A0- device-width : (optional) Width of a single flash chip. =A0If
> @@ -61,3 +63,18 @@ Example:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0read-only;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0};
> +
> +Here an example with multiple "reg" tuples:
> +
> + =A0 =A0 =A0 flash@f0000000,0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "intel,PC48F4400P0VB", "cfi-=
flash";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0 0x00000000 0x02000000
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 0x02000000 0x02000000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bank-width =3D <2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 partition@0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label =3D "test-part1";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0 0x04000000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 };
> --
> 1.6.2.3
>
>



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

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Grant Likely @ 2009-04-16 13:26 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <1239883845-17804-1-git-send-email-sr@denx.de>

On Thu, Apr 16, 2009 at 6:10 AM, Stefan Roese <sr@denx.de> wrote:
> This patch adds support to handle multiple non-identical chips in one
> flash device tree node. It also adds concat support to physmap_of. This
> makes it possible to support e.g. the Intel P30 48F4400 chips which
> internally consists of 2 non-identical NOR chips on one die. Additionally
> partitions now can span over multiple chips.
>
> To describe such a chip's, multiple "reg" tuples are now supported in one
> flash device tree node. Here an dts example:
>
> =A0 =A0 =A0 =A0flash@f0000000,0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "cfi-flash";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x00000000 0x02000000
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 0x02000000 0x02000000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bank-width =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0partition@0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0label =3D "test-part1";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x04000000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0};
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Reviewd-by: Grant Likely <grant.likely@secretlab.ca>

Yup, still looks good to me.  What boards has this been tested on?

g.

> ---
> Changes in ver3:
> - s/4/sizeof(u32)
>
> Changes in ver2 (as suggested by Grant Likely):
> - Removed MAX_RESOURCES introduced in ver1. Now we don't have a hard limi=
t
> =A0for "reg" tuples anymore.
> - Used of_n_addr_cells() and of_n_size_cells() to determine size of each =
tuple.
>
> =A0drivers/mtd/maps/physmap_of.c | =A0199 +++++++++++++++++++++++++++++--=
----------
> =A01 files changed, 143 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.=
c
> index c83a60f..39d357b 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -20,16 +20,23 @@
> =A0#include <linux/mtd/mtd.h>
> =A0#include <linux/mtd/map.h>
> =A0#include <linux/mtd/partitions.h>
> +#include <linux/mtd/concat.h>
> =A0#include <linux/of.h>
> =A0#include <linux/of_platform.h>
>
> +struct of_flash_list {
> + =A0 =A0 =A0 struct mtd_info *mtd;
> + =A0 =A0 =A0 struct map_info map;
> + =A0 =A0 =A0 struct resource *res;
> +};
> +
> =A0struct of_flash {
> - =A0 =A0 =A0 struct mtd_info =A0 =A0 =A0 =A0 *mtd;
> - =A0 =A0 =A0 struct map_info =A0 =A0 =A0 =A0 map;
> - =A0 =A0 =A0 struct resource =A0 =A0 =A0 =A0 *res;
> + =A0 =A0 =A0 struct mtd_info =A0 =A0 =A0 =A0 *cmtd;
> =A0#ifdef CONFIG_MTD_PARTITIONS
> =A0 =A0 =A0 =A0struct mtd_partition =A0 =A0*parts;
> =A0#endif
> + =A0 =A0 =A0 int list_size; /* number of elements in of_flash_list */
> + =A0 =A0 =A0 struct of_flash_list =A0 =A0list[0];
> =A0};
>
> =A0#ifdef CONFIG_MTD_PARTITIONS
> @@ -88,30 +95,44 @@ static int parse_obsolete_partitions(struct of_device=
 *dev,
> =A0static int of_flash_remove(struct of_device *dev)
> =A0{
> =A0 =A0 =A0 =A0struct of_flash *info;
> + =A0 =A0 =A0 int i;
>
> =A0 =A0 =A0 =A0info =3D dev_get_drvdata(&dev->dev);
> =A0 =A0 =A0 =A0if (!info)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
> =A0 =A0 =A0 =A0dev_set_drvdata(&dev->dev, NULL);
>
> - =A0 =A0 =A0 if (info->mtd) {
> +#ifdef CONFIG_MTD_CONCAT
> + =A0 =A0 =A0 if (info->cmtd !=3D info->list[0].mtd) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->cmtd);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtd_concat_destroy(info->cmtd);
> + =A0 =A0 =A0 }
> +#endif
> +
> + =A0 =A0 =A0 if (info->cmtd) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (OF_FLASH_PARTS(info)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_partitions(info->mt=
d);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_partitions(info->cm=
td);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kfree(OF_FLASH_PARTS(info)=
);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->mtd);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 del_mtd_device(info->cmtd);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 map_destroy(info->mtd);
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 if (info->map.virt)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 iounmap(info->map.virt);
> + =A0 =A0 =A0 for (i =3D 0; i < info->list_size; i++) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->list[i].mtd)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 map_destroy(info->list[i].m=
td);
>
> - =A0 =A0 =A0 if (info->res) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 release_resource(info->res);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(info->res);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->list[i].map.virt)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iounmap(info->list[i].map.v=
irt);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->list[i].res) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 release_resource(info->list=
[i].res);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(info->list[i].res);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0}
>
> + =A0 =A0 =A0 kfree(info);
> +
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> @@ -164,68 +185,130 @@ static int __devinit of_flash_probe(struct of_devi=
ce *dev,
> =A0 =A0 =A0 =A0const char *probe_type =3D match->data;
> =A0 =A0 =A0 =A0const u32 *width;
> =A0 =A0 =A0 =A0int err;
> -
> - =A0 =A0 =A0 err =3D -ENXIO;
> - =A0 =A0 =A0 if (of_address_to_resource(dp, 0, &res)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Can't get IO address fr=
om device tree\n");
> + =A0 =A0 =A0 int i;
> + =A0 =A0 =A0 int count;
> + =A0 =A0 =A0 const u32 *p;
> + =A0 =A0 =A0 int reg_tuple_size;
> + =A0 =A0 =A0 struct mtd_info **mtd_list =3D NULL;
> +
> + =A0 =A0 =A0 reg_tuple_size =3D (of_n_addr_cells(dp) + of_n_size_cells(d=
p)) * sizeof(u32);
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Get number of "reg" tuples. Scan for MTD devices on ar=
ea's
> + =A0 =A0 =A0 =A0* described by each "reg" region. This makes it possible=
 (including
> + =A0 =A0 =A0 =A0* the concat support) to support the Intel P30 48F4400 c=
hips which
> + =A0 =A0 =A0 =A0* consists internally of 2 non-identical NOR chips on on=
e die.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 p =3D of_get_property(dp, "reg", &count);
> + =A0 =A0 =A0 if (count % reg_tuple_size !=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Malformed reg property =
on %s\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev->node->=
full_name);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -EINVAL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto err_out;
> =A0 =A0 =A0 =A0}
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&dev->dev, "of_flash device: %.8llx=
-%.8llx\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res.start, (unsigned lo=
ng long)res.end);
> + =A0 =A0 =A0 count /=3D reg_tuple_size;
>
> =A0 =A0 =A0 =A0err =3D -ENOMEM;
> - =A0 =A0 =A0 info =3D kzalloc(sizeof(*info), GFP_KERNEL);
> + =A0 =A0 =A0 info =3D kzalloc(sizeof(struct of_flash) +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct of_flash_list)=
 * count, GFP_KERNEL);
> + =A0 =A0 =A0 if (!info)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> +
> + =A0 =A0 =A0 mtd_list =3D kzalloc(sizeof(struct mtd_info) * count, GFP_K=
ERNEL);
> =A0 =A0 =A0 =A0if (!info)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto err_out;
>
> =A0 =A0 =A0 =A0dev_set_drvdata(&dev->dev, info);
>
> - =A0 =A0 =A0 err =3D -EBUSY;
> - =A0 =A0 =A0 info->res =3D request_mem_region(res.start, res.end - res.s=
tart + 1,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0dev_name(&dev->dev));
> - =A0 =A0 =A0 if (!info->res)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 for (i =3D 0; i < count; i++) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENXIO;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_address_to_resource(dp, i, &res)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Can't g=
et IO address from device"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " tree\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 err =3D -ENXIO;
> - =A0 =A0 =A0 width =3D of_get_property(dp, "bank-width", NULL);
> - =A0 =A0 =A0 if (!width) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Can't get bank width fr=
om device tree\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&dev->dev, "of_flash device: %.8llx=
-%.8llx\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res.sta=
rt,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res.end=
);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -EBUSY;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].res =3D request_mem_region(re=
s.start, res.end -
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res.start + 1,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_name(&dev->dev));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!info->list[i].res)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENXIO;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 width =3D of_get_property(dp, "bank-width",=
 NULL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!width) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Can't g=
et bank width from device"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " tree\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 info->map.name =3D dev_name(&dev->dev);
> - =A0 =A0 =A0 info->map.phys =3D res.start;
> - =A0 =A0 =A0 info->map.size =3D res.end - res.start + 1;
> - =A0 =A0 =A0 info->map.bankwidth =3D *width;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].map.name =3D dev_name(&dev->d=
ev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].map.phys =3D res.start;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].map.size =3D res.end - res.st=
art + 1;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].map.bankwidth =3D *width;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOMEM;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].map.virt =3D ioremap(info->li=
st[i].map.phys,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0info->list[i].map.size);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!info->list[i].map.virt) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Failed =
to ioremap() flash"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " region\n"=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 err =3D -ENOMEM;
> - =A0 =A0 =A0 info->map.virt =3D ioremap(info->map.phys, info->map.size);
> - =A0 =A0 =A0 if (!info->map.virt) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "Failed to ioremap() fla=
sh region\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 simple_map_init(&info->list[i].map);
>
> - =A0 =A0 =A0 simple_map_init(&info->map);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (probe_type) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].mtd =3D do_ma=
p_probe(probe_type,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&info->list[i].map);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].mtd =3D obsol=
ete_probe(dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&info->list[i].map);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtd_list[i] =3D info->list[i].mtd;
>
> - =A0 =A0 =A0 if (probe_type)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->mtd =3D do_map_probe(probe_type, &inf=
o->map);
> - =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->mtd =3D obsolete_probe(dev, &info->ma=
p);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENXIO;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!info->list[i].mtd) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "do_map_=
probe() failed\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list_size++;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].mtd->owner =3D THIS_MODULE;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->list[i].mtd->dev.parent =3D &dev->dev=
;
> + =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 err =3D -ENXIO;
> - =A0 =A0 =A0 if (!info->mtd) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "do_map_probe() failed\n=
");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> + =A0 =A0 =A0 err =3D 0;
> + =A0 =A0 =A0 if (info->list_size =3D=3D 1) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->cmtd =3D info->list[0].mtd;
> + =A0 =A0 =A0 } else if (info->list_size > 1) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We detected multiple devices. Concaten=
ate them together.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> +#ifdef CONFIG_MTD_CONCAT
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 info->cmtd =3D mtd_concat_create(mtd_list, =
info->list_size,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0dev_name(&dev->dev));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (info->cmtd =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENXIO;
> +#else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "physmap_of: multiple devic=
es "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"found but MTD concat suppor=
t disabled.\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENXIO;
> +#endif
> =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 info->mtd->owner =3D THIS_MODULE;
> - =A0 =A0 =A0 info->mtd->dev.parent =3D &dev->dev;
> + =A0 =A0 =A0 if (err)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
>
> =A0#ifdef CONFIG_MTD_PARTITIONS
> =A0 =A0 =A0 =A0/* First look for RedBoot table or partitions on the comma=
nd
> =A0 =A0 =A0 =A0 * line, these take precedence over device tree informatio=
n */
> - =A0 =A0 =A0 err =3D parse_mtd_partitions(info->mtd, part_probe_types,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&inf=
o->parts, 0);
> + =A0 =A0 =A0 err =3D parse_mtd_partitions(info->cmtd, part_probe_types,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&inf=
o->parts, 0);
> =A0 =A0 =A0 =A0if (err < 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return err;
>
> @@ -244,15 +327,19 @@ static int __devinit of_flash_probe(struct of_devic=
e *dev,
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0if (err > 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_mtd_partitions(info->mtd, info->parts, =
err);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_mtd_partitions(info->cmtd, info->parts,=
 err);
> =A0 =A0 =A0 =A0else
> =A0#endif
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_mtd_device(info->mtd);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_mtd_device(info->cmtd);
> +
> + =A0 =A0 =A0 kfree(mtd_list);
>
> =A0 =A0 =A0 =A0return 0;
>
> =A0err_out:
> + =A0 =A0 =A0 kfree(mtd_list);
> =A0 =A0 =A0 =A0of_flash_remove(dev);
> +
> =A0 =A0 =A0 =A0return err;
> =A0}
>
> --
> 1.6.2.3
>
>



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

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-16 13:37 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <fa686aa40904160626k118cea3cvc0db38a2277e45b8@mail.gmail.com>

On Thursday 16 April 2009, Grant Likely wrote:
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
>
> Yup, still looks good to me.  What boards has this been tested on?

I tested this version on PPC405EX Kilauea equipped only one "standard" 
Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360 
board (kmeter1) which is equipped with the Intel P30 part mentioned in the 
bindings description. Slightly modified since this board support is not yet 
pushed upstream and currently using v2.6.28 (physmap_of.c has received minor 
modifications after 2.6.28 release).

Thanks.

Best regards,
Stefan

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Grant Likely @ 2009-04-16 13:46 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd, David Woodhouse
In-Reply-To: <200904161537.59048.sr@denx.de>

On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese <sr@denx.de> wrote:
> On Thursday 16 April 2009, Grant Likely wrote:
>> > Signed-off-by: Stefan Roese <sr@denx.de>
>> > Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
>>
>> Yup, still looks good to me. =A0What boards has this been tested on?
>
> I tested this version on PPC405EX Kilauea equipped only one "standard"
> Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360
> board (kmeter1) which is equipped with the Intel P30 part mentioned in th=
e
> bindings description. Slightly modified since this board support is not y=
et
> pushed upstream and currently using v2.6.28 (physmap_of.c has received mi=
nor
> modifications after 2.6.28 release).

Okay.  It will be good to get this one into -next for some testing
exposure.  Unless he asks me to do otherwise, I'll leave this one to
David to pick up.

g.

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

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-16 13:49 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd, David Woodhouse
In-Reply-To: <fa686aa40904160646v75a98e02s446fd89c08cfebae@mail.gmail.com>

On Thursday 16 April 2009, Grant Likely wrote:
> >> Yup, still looks good to me. =A0What boards has this been tested on?
> >
> > I tested this version on PPC405EX Kilauea equipped only one "standard"
> > Spansion S29GL512 NOR chip. And a slightly modified version on an MPC83=
60
> > board (kmeter1) which is equipped with the Intel P30 part mentioned in
> > the bindings description. Slightly modified since this board support is
> > not yet pushed upstream and currently using v2.6.28 (physmap_of.c has
> > received minor modifications after 2.6.28 release).
>
> Okay.  It will be good to get this one into -next for some testing
> exposure.  Unless he asks me to do otherwise, I'll leave this one to
> David to pick up.

Understood. Thanks Grant.

Best regards,
Stefan

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Artem Bityutskiy @ 2009-04-16 13:51 UTC (permalink / raw)
  To: Grant Likely
  Cc: linuxppc-dev, Stefan Roese, linux-mtd, David Woodhouse,
	devicetree-discuss
In-Reply-To: <fa686aa40904160646v75a98e02s446fd89c08cfebae@mail.gmail.com>

On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese <sr@denx.de> wrote:
> > On Thursday 16 April 2009, Grant Likely wrote:
> >> > Signed-off-by: Stefan Roese <sr@denx.de>
> >> > Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
> >>
> >> Yup, still looks good to me.  What boards has this been tested on?
> >
> > I tested this version on PPC405EX Kilauea equipped only one "standard"
> > Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360
> > board (kmeter1) which is equipped with the Intel P30 part mentioned in the
> > bindings description. Slightly modified since this board support is not yet
> > pushed upstream and currently using v2.6.28 (physmap_of.c has received minor
> > modifications after 2.6.28 release).
> 
> Okay.  It will be good to get this one into -next for some testing
> exposure.  Unless he asks me to do otherwise, I'll leave this one to
> David to pick up.

David usually picks up stuff just before or during merge window,
so if you want linux-next exposure, you need to have some extra
care.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Grant Likely @ 2009-04-16 14:05 UTC (permalink / raw)
  To: dedekind
  Cc: linuxppc-dev, Stefan Roese, linux-mtd, David Woodhouse,
	devicetree-discuss
In-Reply-To: <1239889899.3390.216.camel@localhost.localdomain>

On Thu, Apr 16, 2009 at 7:51 AM, Artem Bityutskiy
<dedekind@infradead.org> wrote:
> On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
>> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese <sr@denx.de> wrote:
>> > On Thursday 16 April 2009, Grant Likely wrote:
>> >> > Signed-off-by: Stefan Roese <sr@denx.de>
>> >> > Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
>> >>
>> >> Yup, still looks good to me. =A0What boards has this been tested on?
>> >
>> > I tested this version on PPC405EX Kilauea equipped only one "standard"
>> > Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8=
360
>> > board (kmeter1) which is equipped with the Intel P30 part mentioned in=
 the
>> > bindings description. Slightly modified since this board support is no=
t yet
>> > pushed upstream and currently using v2.6.28 (physmap_of.c has received=
 minor
>> > modifications after 2.6.28 release).
>>
>> Okay. =A0It will be good to get this one into -next for some testing
>> exposure. =A0Unless he asks me to do otherwise, I'll leave this one to
>> David to pick up.
>
> David usually picks up stuff just before or during merge window,
> so if you want linux-next exposure, you need to have some extra
> care.

Okay, thanks.

David, I'd like to get this into a -next tree.  Are you okay with it
going in via the powerpc tree?

g.

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

^ permalink raw reply

* [PATCH] powerpc: Fix crash on CPU hotplug
From: Michael Ellerman @ 2009-04-16 14:47 UTC (permalink / raw)
  To: linuxppc-dev

early_init_mmu_secondary() is called at CPU hotplug time, so it
must be marked as __cpuinit, not __init.

Caused by 757c74d2 (Introduce early_init_mmu() on 64-bit).

Tested-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/mm/hash_utils_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index db556d2..1ade7eb 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -753,7 +753,7 @@ void __init early_init_mmu(void)
 }
 
 #ifdef CONFIG_SMP
-void __init early_init_mmu_secondary(void)
+void __cpuinit early_init_mmu_secondary(void)
 {
 	/* Initialize hash table for that CPU */
 	if (!firmware_has_feature(FW_FEATURE_LPAR))
-- 
1.6.2.1

^ permalink raw reply related

* ppc32: Don't clobber personality flags on exec
From: Andreas Schwab @ 2009-04-16 16:22 UTC (permalink / raw)
  To: linuxppc-dev

Now that ppc32 implements address randomization it also wants to inherit
personality flags like ADDR_NO_RANDOMIZE across exec, for things like
`setarch ppc -R' to work.  But the ppc32 version of SET_PERSONALITY
forcefully sets PER_LINUX, clearing all personality flags.  So be
careful about preserving the flags.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>

---
 arch/powerpc/include/asm/elf.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6.30-rc1/arch/powerpc/include/asm/elf.h
===================================================================
--- linux-2.6.30-rc1.orig/arch/powerpc/include/asm/elf.h	2009-04-08 12:45:56.000000000 +0200
+++ linux-2.6.30-rc1/arch/powerpc/include/asm/elf.h	2009-04-12 14:24:06.000000000 +0200
@@ -258,7 +258,8 @@ do {								\
 # define elf_read_implies_exec(ex, exec_stk) (test_thread_flag(TIF_32BIT) ? \
 		(exec_stk != EXSTACK_DISABLE_X) : 0)
 #else 
-# define SET_PERSONALITY(ex) set_personality(PER_LINUX)
+# define SET_PERSONALITY(ex) \
+  set_personality(PER_LINUX | (current->personality & (~PER_MASK)))
 #endif /* __powerpc64__ */
 
 extern int dcache_bsize;

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply

* [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: John Linn @ 2009-04-16 16:26 UTC (permalink / raw)
  To: grant.likely, linuxppc-dev, linux-fbdev-devel, akonovalov,
	adaplas, jwboyer
  Cc: Suneel, John Linn

Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.

Removed platform device support as both MicroBlaze and PowerPC
use device tree.

Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.

Added compatibility for ml507 dvi core.

Signed-off-by: Suneel <suneelg@xilinx.com>
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---

V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for the
 confusion with this, update the name of the patch slightly to be more accurate
V4 - update based on Grant's comments to simplify it, the binding wasn't changed
 as the conversation seemed to verify it's acceptable

 drivers/video/xilinxfb.c |  282 +++++++++++++++++++++++-----------------------
 1 files changed, 142 insertions(+), 140 deletions(-)

diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 40a3a2a..ebb9d1c 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
 /*
- * xilinxfb.c
  *
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
  *
  * Author: MontaVista Software, Inc.
  *         source@mvista.com
  *
  * 2002-2007 (c) MontaVista Software, Inc.
  * 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -24,33 +24,38 @@
 #include <linux/device.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
+#include <linux/version.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/mm.h>
 #include <linux/fb.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#if defined(CONFIG_OF)
 #include <linux/of_device.h>
 #include <linux/of_platform.h>
-#endif
-#include <asm/io.h>
+#include <linux/io.h>
 #include <linux/xilinxfb.h>
+#include <asm/dcr.h>
 
 #define DRIVER_NAME		"xilinxfb"
-#define DRIVER_DESCRIPTION	"Xilinx TFT LCD frame buffer driver"
+
 
 /*
  * Xilinx calls it "PLB TFT LCD Controller" though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a TFT or VGA screen.
  *
  * The interface to the framebuffer is nice and simple.  There are two
  * control registers.  The first tells the LCD interface where in memory
  * the frame buffer is (only the 11 most significant bits are used, so
  * don't start thinking about scrolling).  The second allows the LCD to
  * be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
  */
 #define NUM_REGS	2
 #define REG_FB_ADDR	0
@@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var = {
 	.activate =	FB_ACTIVATE_NOW
 };
 
+
+#define PLB_ACCESS_FLAG	0x1		/* 1 = PLB, 0 = DCR */
+
 struct xilinxfb_drvdata {
 
 	struct fb_info	info;		/* FB driver info record */
 
-	u32		regs_phys;	/* phys. address of the control registers */
-	u32 __iomem	*regs;		/* virt. address of the control registers */
+	phys_addr_t	regs_phys;	/* phys. address of the control
+						registers */
+	void __iomem	*regs;		/* virt. address of the control
+						registers */
+
+	dcr_host_t      dcr_host;
+	unsigned int    dcr_start;
+	unsigned int    dcr_len;
 
 	void		*fb_virt;	/* virt. address of the frame buffer */
 	dma_addr_t	fb_phys;	/* phys. address of the frame buffer */
@@ -128,14 +142,18 @@ struct xilinxfb_drvdata {
 	container_of(_info, struct xilinxfb_drvdata, info)
 
 /*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
  */
-#define xilinx_fb_out_be32(driverdata, offset, val) \
-	out_be32(driverdata->regs + offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+				u32 val)
+{
+	if (drvdata->regs)
+		out_be32(drvdata->regs + (offset << 2), val);
+	else
+		dcr_write(drvdata->dcr_host, offset, val);
+}
 
 static int
 xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
@@ -173,7 +191,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
 	switch (blank_mode) {
 	case FB_BLANK_UNBLANK:
 		/* turn on panel */
-		xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+		xilinx_fb_out_be32(drvdata, REG_CTRL,
+					drvdata->reg_ctrl_default);
 		break;
 
 	case FB_BLANK_NORMAL:
@@ -189,8 +208,7 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
 	return 0; /* success */
 }
 
-static struct fb_ops xilinxfb_ops =
-{
+static struct fb_ops xilinxfb_ops = {
 	.owner			= THIS_MODULE,
 	.fb_setcolreg		= xilinx_fb_setcolreg,
 	.fb_blank		= xilinx_fb_blank,
@@ -203,35 +221,34 @@ static struct fb_ops xilinxfb_ops =
  * Bus independent setup/teardown
  */
 
-static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
+static int xilinxfb_assign(struct device *dev,
+			   struct xilinxfb_drvdata *drvdata,
+			   unsigned long physaddr,
 			   struct xilinxfb_platform_data *pdata)
 {
-	struct xilinxfb_drvdata *drvdata;
 	int rc;
 	int fbsize = pdata->xvirt * pdata->yvirt * BYTES_PER_PIXEL;
 
-	/* Allocate the driver data region */
-	drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
-	if (!drvdata) {
-		dev_err(dev, "Couldn't allocate device private record\n");
-		return -ENOMEM;
-	}
-	dev_set_drvdata(dev, drvdata);
-
-	/* Map the control registers in */
-	if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
-		dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
-			physaddr);
-		rc = -ENODEV;
-		goto err_region;
-	}
-	drvdata->regs_phys = physaddr;
-	drvdata->regs = ioremap(physaddr, 8);
-	if (!drvdata->regs) {
-		dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
-			physaddr);
-		rc = -ENODEV;
-		goto err_map;
+	if (physaddr) {
+		/*
+		 * Map the control registers in if the controller
+		 * is on direct PLB interface.
+		 */
+		if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
+			dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+				physaddr);
+			rc = -ENODEV;
+			goto err_region;
+		}
+
+		drvdata->regs_phys = physaddr;
+		drvdata->regs = ioremap(physaddr, 8);
+		if (!drvdata->regs) {
+			dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+				physaddr);
+			rc = -ENODEV;
+			goto err_map;
+		}
 	}
 
 	/* Allocate the framebuffer memory */
@@ -260,7 +277,8 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
 	drvdata->reg_ctrl_default = REG_CTRL_ENABLE;
 	if (pdata->rotate_screen)
 		drvdata->reg_ctrl_default |= REG_CTRL_ROTATE;
-	xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+	xilinx_fb_out_be32(drvdata, REG_CTRL,
+					drvdata->reg_ctrl_default);
 
 	/* Fill struct fb_info */
 	drvdata->info.device = dev;
@@ -296,11 +314,14 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
 		goto err_regfb;
 	}
 
+	if (drvdata->regs) {
+		/* Put a banner in the log (for DEBUG) */
+		dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr,
+					drvdata->regs);
+	}
 	/* Put a banner in the log (for DEBUG) */
-	dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr, drvdata->regs);
-	dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
-		(unsigned long long) drvdata->fb_phys, drvdata->fb_virt,
-		fbsize);
+	dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
+		(void *)drvdata->fb_phys, drvdata->fb_virt, fbsize);
 
 	return 0;	/* success */
 
@@ -311,14 +332,19 @@ err_cmap:
 	if (drvdata->fb_alloced)
 		dma_free_coherent(dev, PAGE_ALIGN(fbsize), drvdata->fb_virt,
 			drvdata->fb_phys);
+	else
+		iounmap(drvdata->fb_virt);
+
 	/* Turn off the display */
 	xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
 
 err_fbmem:
-	iounmap(drvdata->regs);
+	if (drvdata->regs)
+		iounmap(drvdata->regs);
 
 err_map:
-	release_mem_region(physaddr, 8);
+	if (physaddr)
+		release_mem_region(physaddr, 8);
 
 err_region:
 	kfree(drvdata);
@@ -342,12 +368,18 @@ static int xilinxfb_release(struct device *dev)
 	if (drvdata->fb_alloced)
 		dma_free_coherent(dev, PAGE_ALIGN(drvdata->info.fix.smem_len),
 				  drvdata->fb_virt, drvdata->fb_phys);
+	else
+		iounmap(drvdata->fb_virt);
 
 	/* Turn off the display */
 	xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
-	iounmap(drvdata->regs);
 
-	release_mem_region(drvdata->regs_phys, 8);
+	/* Release the resources, as allocated based on interface */
+	if (drvdata->regs) {
+		iounmap(drvdata->regs);
+		release_mem_region(drvdata->regs_phys, 8);
+	} else
+		dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
 
 	kfree(drvdata);
 	dev_set_drvdata(dev, NULL);
@@ -356,77 +388,55 @@ static int xilinxfb_release(struct device *dev)
 }
 
 /* ---------------------------------------------------------------------
- * Platform bus binding
- */
-
-static int
-xilinxfb_platform_probe(struct platform_device *pdev)
-{
-	struct xilinxfb_platform_data *pdata;
-	struct resource *res;
-
-	/* Find the registers address */
-	res = platform_get_resource(pdev, IORESOURCE_IO, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "Couldn't get registers resource\n");
-		return -ENODEV;
-	}
-
-	/* If a pdata structure is provided, then extract the parameters */
-	pdata = &xilinx_fb_default_pdata;
-	if (pdev->dev.platform_data) {
-		pdata = pdev->dev.platform_data;
-		if (!pdata->xres)
-			pdata->xres = xilinx_fb_default_pdata.xres;
-		if (!pdata->yres)
-			pdata->yres = xilinx_fb_default_pdata.yres;
-		if (!pdata->xvirt)
-			pdata->xvirt = xilinx_fb_default_pdata.xvirt;
-		if (!pdata->yvirt)
-			pdata->yvirt = xilinx_fb_default_pdata.yvirt;
-	}
-
-	return xilinxfb_assign(&pdev->dev, res->start, pdata);
-}
-
-static int
-xilinxfb_platform_remove(struct platform_device *pdev)
-{
-	return xilinxfb_release(&pdev->dev);
-}
-
-
-static struct platform_driver xilinxfb_platform_driver = {
-	.probe		= xilinxfb_platform_probe,
-	.remove		= xilinxfb_platform_remove,
-	.driver = {
-		.owner = THIS_MODULE,
-		.name = DRIVER_NAME,
-	},
-};
-
-/* ---------------------------------------------------------------------
  * OF bus binding
  */
 
-#if defined(CONFIG_OF)
 static int __devinit
 xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
 {
-	struct resource res;
 	const u32 *prop;
+	u32 *p;
+	u32 tft_access;
 	struct xilinxfb_platform_data pdata;
+	struct resource res;
 	int size, rc;
+	int start = 0, len = 0;
+	dcr_host_t dcr_host;
+	struct xilinxfb_drvdata *drvdata;
 
 	/* Copy with the default pdata (not a ptr reference!) */
 	pdata = xilinx_fb_default_pdata;
 
 	dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
 
-	rc = of_address_to_resource(op->node, 0, &res);
-	if (rc) {
-		dev_err(&op->dev, "invalid address\n");
-		return rc;
+	/*
+	 * Determine if the core is connected directly to DCR or PLB
+	 * interface and initialize the tft_access accordingly keeping
+	 * backward compatibility with DCR access.
+	 */
+	p = (u32 *)of_get_property(op->node, "xlnx,dcr-splb-slave-if", NULL);
+
+	tft_access = p ? *p : 0;
+
+	/*
+	 * Fill the resource structure if its direct PLB interface
+	 * otherwise fill the dcr_host structure.
+	 */
+	if (tft_access) {
+		rc = of_address_to_resource(op->node, 0, &res);
+		if (rc) {
+			dev_err(&op->dev, "invalid address\n");
+			return -ENODEV;
+		}
+
+	} else {
+		start = dcr_resource_start(op->node, 0);
+		len = dcr_resource_len(op->node, 0);
+		dcr_host = dcr_map(op->node, start, len);
+		if (!DCR_MAP_OK(dcr_host)) {
+			dev_err(&op->dev, "invalid address\n");
+			return -ENODEV;
+		}
 	}
 
 	prop = of_get_property(op->node, "phys-size", &size);
@@ -450,7 +460,23 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
 	if (of_find_property(op->node, "rotate-display", NULL))
 		pdata.rotate_screen = 1;
 
-	return xilinxfb_assign(&op->dev, res.start, &pdata);
+	/* Allocate the driver data region */
+	drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata) {
+		dev_err(&op->dev, "Couldn't allocate device private record\n");
+		return -ENOMEM;
+	}
+	dev_set_drvdata(&op->dev, drvdata);
+
+	/* Arguments are passed based on the interface */
+	if (tft_access) {
+		return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
+	} else {
+		drvdata->dcr_start = start;
+		drvdata->dcr_len = len;
+		drvdata->dcr_host = dcr_host;
+		return xilinxfb_assign(&op->dev, drvdata, 0, &pdata);
+	}
 }
 
 static int __devexit xilinxfb_of_remove(struct of_device *op)
@@ -460,7 +486,9 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
 
 /* Match table for of_platform binding */
 static struct of_device_id xilinxfb_of_match[] __devinitdata = {
+	{ .compatible = "xlnx,xps-tft-1.00.a", },
 	{ .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
+	{ .compatible = "xlnx,plb-dvi-cntlr-ref-1.00.c", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, xilinxfb_of_match);
@@ -476,22 +504,6 @@ static struct of_platform_driver xilinxfb_of_driver = {
 	},
 };
 
-/* Registration helpers to keep the number of #ifdefs to a minimum */
-static inline int __init xilinxfb_of_register(void)
-{
-	pr_debug("xilinxfb: calling of_register_platform_driver()\n");
-	return of_register_platform_driver(&xilinxfb_of_driver);
-}
-
-static inline void __exit xilinxfb_of_unregister(void)
-{
-	of_unregister_platform_driver(&xilinxfb_of_driver);
-}
-#else /* CONFIG_OF */
-/* CONFIG_OF not enabled; do nothing helpers */
-static inline int __init xilinxfb_of_register(void) { return 0; }
-static inline void __exit xilinxfb_of_unregister(void) { }
-#endif /* CONFIG_OF */
 
 /* ---------------------------------------------------------------------
  * Module setup and teardown
@@ -500,28 +512,18 @@ static inline void __exit xilinxfb_of_unregister(void) { }
 static int __init
 xilinxfb_init(void)
 {
-	int rc;
-	rc = xilinxfb_of_register();
-	if (rc)
-		return rc;
-
-	rc = platform_driver_register(&xilinxfb_platform_driver);
-	if (rc)
-		xilinxfb_of_unregister();
-
-	return rc;
+	return of_register_platform_driver(&xilinxfb_of_driver);
 }
 
 static void __exit
 xilinxfb_cleanup(void)
 {
-	platform_driver_unregister(&xilinxfb_platform_driver);
-	xilinxfb_of_unregister();
+	of_unregister_platform_driver(&xilinxfb_of_driver);
 }
 
 module_init(xilinxfb_init);
 module_exit(xilinxfb_cleanup);
 
 MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
-MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_DESCRIPTION("Xilinx TFT frame buffer driver");
 MODULE_LICENSE("GPL");
-- 
1.6.2.1


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

^ permalink raw reply related

* [PATCH] windfarm: Convert to a new-style i2c drivers
From: Jean Delvare @ 2009-04-16 16:56 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Paul Mackerras

The legacy i2c binding model is going away soon, so convert the
macintosh windfarm drivers to the new model or they will break.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
Can someone please test this patch for me? I could only build-test it.

Remember that you need this patch applied:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0

Thanks.

 drivers/macintosh/windfarm_lm75_sensor.c    |  131 +++++++++++++++------------
 drivers/macintosh/windfarm_max6690_sensor.c |  103 ++++++++++++---------
 drivers/macintosh/windfarm_smu_sat.c        |  109 ++++++++++++----------
 3 files changed, 198 insertions(+), 145 deletions(-)

--- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_lm75_sensor.c	2009-04-16 11:15:00.000000000 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/windfarm_lm75_sensor.c	2009-04-16 11:23:17.000000000 +0200
@@ -37,34 +37,22 @@
 struct wf_lm75_sensor {
 	int			ds1775 : 1;
 	int			inited : 1;
-	struct 	i2c_client	i2c;
+	struct 	i2c_client	*i2c;
 	struct 	wf_sensor	sens;
 };
 #define wf_to_lm75(c) container_of(c, struct wf_lm75_sensor, sens)
-#define i2c_to_lm75(c) container_of(c, struct wf_lm75_sensor, i2c)
-
-static int wf_lm75_attach(struct i2c_adapter *adapter);
-static int wf_lm75_detach(struct i2c_client *client);
-
-static struct i2c_driver wf_lm75_driver = {
-	.driver = {
-		.name	= "wf_lm75",
-	},
-	.attach_adapter	= wf_lm75_attach,
-	.detach_client	= wf_lm75_detach,
-};
 
 static int wf_lm75_get(struct wf_sensor *sr, s32 *value)
 {
 	struct wf_lm75_sensor *lm = wf_to_lm75(sr);
 	s32 data;
 
-	if (lm->i2c.adapter == NULL)
+	if (lm->i2c == NULL)
 		return -ENODEV;
 
 	/* Init chip if necessary */
 	if (!lm->inited) {
-		u8 cfg_new, cfg = (u8)i2c_smbus_read_byte_data(&lm->i2c, 1);
+		u8 cfg_new, cfg = (u8)i2c_smbus_read_byte_data(lm->i2c, 1);
 
 		DBG("wf_lm75: Initializing %s, cfg was: %02x\n",
 		    sr->name, cfg);
@@ -73,7 +61,7 @@ static int wf_lm75_get(struct wf_sensor
 		 * the firmware for now
 		 */
 		cfg_new = cfg & ~0x01;
-		i2c_smbus_write_byte_data(&lm->i2c, 1, cfg_new);
+		i2c_smbus_write_byte_data(lm->i2c, 1, cfg_new);
 		lm->inited = 1;
 
 		/* If we just powered it up, let's wait 200 ms */
@@ -81,7 +69,7 @@ static int wf_lm75_get(struct wf_sensor
 	}
 
 	/* Read temperature register */
-	data = (s32)le16_to_cpu(i2c_smbus_read_word_data(&lm->i2c, 0));
+	data = (s32)le16_to_cpu(i2c_smbus_read_word_data(lm->i2c, 0));
 	data <<= 8;
 	*value = data;
 
@@ -92,12 +80,6 @@ static void wf_lm75_release(struct wf_se
 {
 	struct wf_lm75_sensor *lm = wf_to_lm75(sr);
 
-	/* check if client is registered and detach from i2c */
-	if (lm->i2c.adapter) {
-		i2c_detach_client(&lm->i2c);
-		lm->i2c.adapter = NULL;
-	}
-
 	kfree(lm);
 }
 
@@ -107,59 +89,77 @@ static struct wf_sensor_ops wf_lm75_ops
 	.owner		= THIS_MODULE,
 };
 
-static struct wf_lm75_sensor *wf_lm75_create(struct i2c_adapter *adapter,
-					     u8 addr, int ds1775,
-					     const char *loc)
+static int wf_lm75_probe(struct i2c_client *client,
+			 const struct i2c_device_id *id)
 {
 	struct wf_lm75_sensor *lm;
 	int rc;
 
-	DBG("wf_lm75: creating  %s device at address 0x%02x\n",
-	    ds1775 ? "ds1775" : "lm75", addr);
-
 	lm = kzalloc(sizeof(struct wf_lm75_sensor), GFP_KERNEL);
 	if (lm == NULL)
-		return NULL;
+		return -ENODEV;
+
+	lm->inited = 0;
+	lm->ds1775 = id->driver_data;
+	lm->i2c = client;
+	lm->sens.name = client->dev.platform_data;
+	lm->sens.ops = &wf_lm75_ops;
+	i2c_set_clientdata(client, lm);
+
+	rc = wf_register_sensor(&lm->sens);
+	if (rc) {
+		i2c_set_clientdata(client, NULL);
+		kfree(lm);
+	}
+
+	return rc;
+}
+
+static struct i2c_client *wf_lm75_create(struct i2c_adapter *adapter,
+					     u8 addr, int ds1775,
+					     const char *loc)
+{
+	struct i2c_board_info info;
+	struct i2c_client *client;
+	char *name;
+
+	DBG("wf_lm75: creating  %s device at address 0x%02x\n",
+	    ds1775 ? "ds1775" : "lm75", addr);
 
 	/* Usual rant about sensor names not beeing very consistent in
 	 * the device-tree, oh well ...
 	 * Add more entries below as you deal with more setups
 	 */
 	if (!strcmp(loc, "Hard drive") || !strcmp(loc, "DRIVE BAY"))
-		lm->sens.name = "hd-temp";
+		name = "hd-temp";
 	else if (!strcmp(loc, "Incoming Air Temp"))
-		lm->sens.name = "incoming-air-temp";
+		name = "incoming-air-temp";
 	else if (!strcmp(loc, "ODD Temp"))
-		lm->sens.name = "optical-drive-temp";
+		name = "optical-drive-temp";
 	else if (!strcmp(loc, "HD Temp"))
-		lm->sens.name = "hard-drive-temp";
+		name = "hard-drive-temp";
 	else
 		goto fail;
 
-	lm->inited = 0;
-	lm->sens.ops = &wf_lm75_ops;
-	lm->ds1775 = ds1775;
-	lm->i2c.addr = (addr >> 1) & 0x7f;
-	lm->i2c.adapter = adapter;
-	lm->i2c.driver = &wf_lm75_driver;
-	strncpy(lm->i2c.name, lm->sens.name, I2C_NAME_SIZE-1);
-
-	rc = i2c_attach_client(&lm->i2c);
-	if (rc) {
-		printk(KERN_ERR "windfarm: failed to attach %s %s to i2c,"
-		       " err %d\n", ds1775 ? "ds1775" : "lm75",
-		       lm->i2c.name, rc);
-		goto fail;
-	}
-
-	if (wf_register_sensor(&lm->sens)) {
-		i2c_detach_client(&lm->i2c);
+	memset(&info, 0, sizeof(struct i2c_board_info));
+	info.addr = (addr >> 1) & 0x7f;
+	info.platform_data = name;
+	strlcpy(info.type, ds1775 ? "wf_ds1775" : "wf_lm75", I2C_NAME_SIZE);
+
+	client = i2c_new_device(adapter, &info);
+	if (client == NULL) {
+		printk(KERN_ERR "windfarm: failed to attach %s %s to i2c\n",
+		       ds1775 ? "ds1775" : "lm75", name);
 		goto fail;
 	}
 
-	return lm;
+	/*
+	 * Let i2c-core delete that device on driver removal.
+	 * This is safe because i2c-core holds the core_lock mutex for us.
+	 */
+	list_add_tail(&client->detected, &client->driver->clients);
+	return client;
  fail:
-	kfree(lm);
 	return NULL;
 }
 
@@ -202,21 +202,38 @@ static int wf_lm75_attach(struct i2c_ada
 	return 0;
 }
 
-static int wf_lm75_detach(struct i2c_client *client)
+static int wf_lm75_remove(struct i2c_client *client)
 {
-	struct wf_lm75_sensor *lm = i2c_to_lm75(client);
+	struct wf_lm75_sensor *lm = i2c_get_clientdata(client);
 
 	DBG("wf_lm75: i2c detatch called for %s\n", lm->sens.name);
 
 	/* Mark client detached */
-	lm->i2c.adapter = NULL;
+	lm->i2c = NULL;
 
 	/* release sensor */
 	wf_unregister_sensor(&lm->sens);
 
+	i2c_set_clientdata(client, NULL);
 	return 0;
 }
 
+static const struct i2c_device_id wf_lm75_id[] = {
+	{ "wf_lm75", 0 },
+	{ "wf_ds1775", 1 },
+	{ }
+};
+
+static struct i2c_driver wf_lm75_driver = {
+	.driver = {
+		.name	= "wf_lm75",
+	},
+	.attach_adapter	= wf_lm75_attach,
+	.probe		= wf_lm75_probe,
+	.remove		= wf_lm75_remove,
+	.id_table	= wf_lm75_id,
+};
+
 static int __init wf_lm75_sensor_init(void)
 {
 	/* Don't register on old machines that use therm_pm72 for now */
--- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_max6690_sensor.c	2009-04-16 17:45:07.000000000 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/windfarm_max6690_sensor.c	2009-04-16 17:45:13.000000000 +0200
@@ -26,34 +26,22 @@
 #define MAX6690_EXTERNAL_TEMP	1
 
 struct wf_6690_sensor {
-	struct i2c_client	i2c;
+	struct i2c_client	*i2c;
 	struct wf_sensor	sens;
 };
 
 #define wf_to_6690(x)	container_of((x), struct wf_6690_sensor, sens)
-#define i2c_to_6690(x)	container_of((x), struct wf_6690_sensor, i2c)
-
-static int wf_max6690_attach(struct i2c_adapter *adapter);
-static int wf_max6690_detach(struct i2c_client *client);
-
-static struct i2c_driver wf_max6690_driver = {
-	.driver = {
-		.name		= "wf_max6690",
-	},
-	.attach_adapter	= wf_max6690_attach,
-	.detach_client	= wf_max6690_detach,
-};
 
 static int wf_max6690_get(struct wf_sensor *sr, s32 *value)
 {
 	struct wf_6690_sensor *max = wf_to_6690(sr);
 	s32 data;
 
-	if (max->i2c.adapter == NULL)
+	if (max->i2c == NULL)
 		return -ENODEV;
 
 	/* chip gets initialized by firmware */
-	data = i2c_smbus_read_byte_data(&max->i2c, MAX6690_EXTERNAL_TEMP);
+	data = i2c_smbus_read_byte_data(max->i2c, MAX6690_EXTERNAL_TEMP);
 	if (data < 0)
 		return data;
 	*value = data << 16;
@@ -64,10 +52,6 @@ static void wf_max6690_release(struct wf
 {
 	struct wf_6690_sensor *max = wf_to_6690(sr);
 
-	if (max->i2c.adapter) {
-		i2c_detach_client(&max->i2c);
-		max->i2c.adapter = NULL;
-	}
 	kfree(max);
 }
 
@@ -77,19 +61,40 @@ static struct wf_sensor_ops wf_max6690_o
 	.owner		= THIS_MODULE,
 };
 
-static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
-			      const char *loc)
+static int wf_max6690_probe(struct i2c_client *client,
+			    const struct i2c_device_id *id)
 {
 	struct wf_6690_sensor *max;
-	char *name;
+	int rc;
 
 	max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
 	if (max == NULL) {
-		printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: "
-		       "no memory\n", loc);
-		return;
+		printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor: "
+		       "no memory\n");
+		return -ENOMEM;
+	}
+
+	max->i2c = client;
+	max->sens.name = client->dev.platform_data;
+	max->sens.ops = &wf_max6690_ops;
+	i2c_set_clientdata(client, max);
+
+	rc = wf_register_sensor(&max->sens);
+	if (rc) {
+		i2c_set_clientdata(client, NULL);
+		kfree(max);
 	}
 
+	return rc;
+}
+
+static struct i2c_client *wf_max6690_create(struct i2c_adapter *adapter,
+					    u8 addr, const char *loc)
+{
+	struct i2c_board_info info;
+	struct i2c_client *client;
+	char *name;
+
 	if (!strcmp(loc, "BACKSIDE"))
 		name = "backside-temp";
 	else if (!strcmp(loc, "NB Ambient"))
@@ -99,27 +104,26 @@ static void wf_max6690_create(struct i2c
 	else
 		goto fail;
 
-	max->sens.ops = &wf_max6690_ops;
-	max->sens.name = name;
-	max->i2c.addr = addr >> 1;
-	max->i2c.adapter = adapter;
-	max->i2c.driver = &wf_max6690_driver;
-	strncpy(max->i2c.name, name, I2C_NAME_SIZE-1);
+	memset(&info, 0, sizeof(struct i2c_board_info));
+	info.addr = addr >> 1;
+	info.platform_data = name;
+	strlcpy(info.type, "wf_max6690", I2C_NAME_SIZE);
 
-	if (i2c_attach_client(&max->i2c)) {
+	client = i2c_new_device(adapter, &info);
+	if (client == NULL) {
 		printk(KERN_ERR "windfarm: failed to attach MAX6690 sensor\n");
 		goto fail;
 	}
 
-	if (wf_register_sensor(&max->sens)) {
-		i2c_detach_client(&max->i2c);
-		goto fail;
-	}
-
-	return;
+	/*
+	 * Let i2c-core delete that device on driver removal.
+	 * This is safe because i2c-core holds the core_lock mutex for us.
+	 */
+	list_add_tail(&client->detected, &client->driver->clients);
+	return client;
 
  fail:
-	kfree(max);
+	return NULL;
 }
 
 static int wf_max6690_attach(struct i2c_adapter *adapter)
@@ -154,16 +158,31 @@ static int wf_max6690_attach(struct i2c_
 	return 0;
 }
 
-static int wf_max6690_detach(struct i2c_client *client)
+static int wf_max6690_remove(struct i2c_client *client)
 {
-	struct wf_6690_sensor *max = i2c_to_6690(client);
+	struct wf_6690_sensor *max = i2c_get_clientdata(client);
 
-	max->i2c.adapter = NULL;
+	max->i2c = NULL;
 	wf_unregister_sensor(&max->sens);
 
 	return 0;
 }
 
+static const struct i2c_device_id wf_max6690_id[] = {
+	{ "wf_max6690", 0 },
+	{ }
+};
+
+static struct i2c_driver wf_max6690_driver = {
+	.driver = {
+		.name		= "wf_max6690",
+	},
+	.attach_adapter	= wf_max6690_attach,
+	.probe		= wf_max6690_probe,
+	.remove		= wf_max6690_remove,
+	.id_table	= wf_max6690_id,
+};
+
 static int __init wf_max6690_sensor_init(void)
 {
 	/* Don't register on old machines that use therm_pm72 for now */
--- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_smu_sat.c	2009-04-16 17:45:06.000000000 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/windfarm_smu_sat.c	2009-04-16 18:13:07.000000000 +0200
@@ -39,7 +39,7 @@ struct wf_sat {
 	struct mutex		mutex;
 	unsigned long		last_read; /* jiffies when cache last updated */
 	u8			cache[16];
-	struct i2c_client	i2c;
+	struct i2c_client	*i2c;
 	struct device_node	*node;
 };
 
@@ -54,18 +54,6 @@ struct wf_sat_sensor {
 };
 
 #define wf_to_sat(c)	container_of(c, struct wf_sat_sensor, sens)
-#define i2c_to_sat(c)	container_of(c, struct wf_sat, i2c)
-
-static int wf_sat_attach(struct i2c_adapter *adapter);
-static int wf_sat_detach(struct i2c_client *client);
-
-static struct i2c_driver wf_sat_driver = {
-	.driver = {
-		.name		= "wf_smu_sat",
-	},
-	.attach_adapter	= wf_sat_attach,
-	.detach_client	= wf_sat_detach,
-};
 
 struct smu_sdbp_header *smu_sat_get_sdb_partition(unsigned int sat_id, int id,
 						  unsigned int *size)
@@ -81,13 +69,13 @@ struct smu_sdbp_header *smu_sat_get_sdb_
 	if (sat_id > 1 || (sat = sats[sat_id]) == NULL)
 		return NULL;
 
-	err = i2c_smbus_write_word_data(&sat->i2c, 8, id << 8);
+	err = i2c_smbus_write_word_data(sat->i2c, 8, id << 8);
 	if (err) {
 		printk(KERN_ERR "smu_sat_get_sdb_part wr error %d\n", err);
 		return NULL;
 	}
 
-	err = i2c_smbus_read_word_data(&sat->i2c, 9);
+	err = i2c_smbus_read_word_data(sat->i2c, 9);
 	if (err < 0) {
 		printk(KERN_ERR "smu_sat_get_sdb_part rd len error\n");
 		return NULL;
@@ -105,7 +93,7 @@ struct smu_sdbp_header *smu_sat_get_sdb_
 		return NULL;
 
 	for (i = 0; i < len; i += 4) {
-		err = i2c_smbus_read_i2c_block_data(&sat->i2c, 0xa, 4, data);
+		err = i2c_smbus_read_i2c_block_data(sat->i2c, 0xa, 4, data);
 		if (err < 0) {
 			printk(KERN_ERR "smu_sat_get_sdb_part rd err %d\n",
 			       err);
@@ -138,7 +126,7 @@ static int wf_sat_read_cache(struct wf_s
 {
 	int err;
 
-	err = i2c_smbus_read_i2c_block_data(&sat->i2c, 0x3f, 16, sat->cache);
+	err = i2c_smbus_read_i2c_block_data(sat->i2c, 0x3f, 16, sat->cache);
 	if (err < 0)
 		return err;
 	sat->last_read = jiffies;
@@ -161,7 +149,7 @@ static int wf_sat_get(struct wf_sensor *
 	int i, err;
 	s32 val;
 
-	if (sat->i2c.adapter == NULL)
+	if (sat->i2c == NULL)
 		return -ENODEV;
 
 	mutex_lock(&sat->mutex);
@@ -193,10 +181,6 @@ static void wf_sat_release(struct wf_sen
 	struct wf_sat *sat = sens->sat;
 
 	if (atomic_dec_and_test(&sat->refcnt)) {
-		if (sat->i2c.adapter) {
-			i2c_detach_client(&sat->i2c);
-			sat->i2c.adapter = NULL;
-		}
 		if (sat->nr >= 0)
 			sats[sat->nr] = NULL;
 		kfree(sat);
@@ -212,38 +196,58 @@ static struct wf_sensor_ops wf_sat_ops =
 
 static void wf_sat_create(struct i2c_adapter *adapter, struct device_node *dev)
 {
+	struct i2c_board_info info;
+	struct i2c_client *client;
+	const u32 *reg;
+	u8 addr;
+
+	reg = of_get_property(dev, "reg", NULL);
+	if (reg == NULL)
+		return;
+	addr = *reg;
+	DBG(KERN_DEBUG "wf_sat: creating sat at address %x\n", addr);
+
+	memset(&info, 0, sizeof(struct i2c_board_info));
+	info.addr = (addr >> 1) & 0x7f;
+	info.platform_data = dev;
+	strlcpy(info.type, "wf_sat", I2C_NAME_SIZE);
+
+	client = i2c_new_device(adapter, &info);
+	if (client == NULL) {
+		printk(KERN_ERR "windfarm: failed to attach smu-sat to i2c\n");
+		return;
+	}
+
+	/*
+	 * Let i2c-core delete that device on driver removal.
+	 * This is safe because i2c-core holds the core_lock mutex for us.
+	 */
+	list_add_tail(&client->detected, &client->driver->clients);
+}
+
+static int wf_sat_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct device_node *dev = client->dev.platform_data;
 	struct wf_sat *sat;
 	struct wf_sat_sensor *sens;
 	const u32 *reg;
 	const char *loc, *type;
-	u8 addr, chip, core;
+	u8 chip, core;
 	struct device_node *child;
 	int shift, cpu, index;
 	char *name;
 	int vsens[2], isens[2];
 
-	reg = of_get_property(dev, "reg", NULL);
-	if (reg == NULL)
-		return;
-	addr = *reg;
-	DBG(KERN_DEBUG "wf_sat: creating sat at address %x\n", addr);
-
 	sat = kzalloc(sizeof(struct wf_sat), GFP_KERNEL);
 	if (sat == NULL)
-		return;
+		return -ENOMEM;
 	sat->nr = -1;
 	sat->node = of_node_get(dev);
 	atomic_set(&sat->refcnt, 0);
 	mutex_init(&sat->mutex);
-	sat->i2c.addr = (addr >> 1) & 0x7f;
-	sat->i2c.adapter = adapter;
-	sat->i2c.driver = &wf_sat_driver;
-	strncpy(sat->i2c.name, "smu-sat", I2C_NAME_SIZE-1);
-
-	if (i2c_attach_client(&sat->i2c)) {
-		printk(KERN_ERR "windfarm: failed to attach smu-sat to i2c\n");
-		goto fail;
-	}
+	sat->i2c = client;
+	i2c_set_clientdata(client, sat);
 
 	vsens[0] = vsens[1] = -1;
 	isens[0] = isens[1] = -1;
@@ -344,10 +348,7 @@ static void wf_sat_create(struct i2c_ada
 	if (sat->nr >= 0)
 		sats[sat->nr] = sat;
 
-	return;
-
- fail:
-	kfree(sat);
+	return 0;
 }
 
 static int wf_sat_attach(struct i2c_adapter *adapter)
@@ -366,16 +367,32 @@ static int wf_sat_attach(struct i2c_adap
 	return 0;
 }
 
-static int wf_sat_detach(struct i2c_client *client)
+static int wf_sat_remove(struct i2c_client *client)
 {
-	struct wf_sat *sat = i2c_to_sat(client);
+	struct wf_sat *sat = i2c_get_clientdata(client);
 
 	/* XXX TODO */
 
-	sat->i2c.adapter = NULL;
+	sat->i2c = NULL;
+	i2c_set_clientdata(client, NULL);
 	return 0;
 }
 
+static const struct i2c_device_id wf_sat_id[] = {
+	{ "wf_sat", 0 },
+	{ }
+};
+
+static struct i2c_driver wf_sat_driver = {
+	.driver = {
+		.name		= "wf_smu_sat",
+	},
+	.attach_adapter	= wf_sat_attach,
+	.probe		= wf_sat_probe,
+	.remove		= wf_sat_remove,
+	.id_table	= wf_sat_id,
+};
+
 static int __init sat_sensors_init(void)
 {
 	return i2c_add_driver(&wf_sat_driver);


-- 
Jean Delvare

^ permalink raw reply

* Re: OF PCI howto?
From: Scott Wood @ 2009-04-16 17:03 UTC (permalink / raw)
  To: Roderick Colenbrander; +Cc: linuxppc-dev, Joakim Tjernlund
In-Reply-To: <c8485d470904160203y66d456f7xd73692b177587822@mail.gmail.com>

On Thu, Apr 16, 2009 at 11:03:56AM +0200, Roderick Colenbrander wrote:
> The ipic driver code and various dts files are evil and store the
> linux kernel value inside the DTS file, so they don't do any
> conversion whis is EVIL
> in my opinion. Watch out for that. (The corresponding DTS files and
> drivers should be updated).

We should have made up some *other* arbitrary encoding instead?

Or perhaps reused the MPIC's screwy encoding that doesn't separate bits
for level and sense?

-Scott

^ permalink raw reply

* Re: [PATCH 3/3] powerpc: allow 256kB pages with SHMEM
From: Ilya Yanok @ 2009-04-16 16:50 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, prodyuth
In-Reply-To: <Pine.LNX.4.64.0904062156290.21044@blonde.anvils>

Hi Hugh,

Hugh Dickins wrote:
> Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
> let powerpc 256kB pages coexist with CONFIG_SHMEM again.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
>   

Acked-by: Ilya Yanok <yanok@emcraft.com>

> ---
> Added linuxppc-dev and some other Cc's for this 3/3: sorry
> if you didn't see 1/3 and 2/3, they were just in mm/shmem.c.
>
>  arch/powerpc/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.29-git13/arch/powerpc/Kconfig	2009-04-06 11:47:57.000000000 +0100
> +++ linux/arch/powerpc/Kconfig	2009-04-06 18:18:47.000000000 +0100
> @@ -462,7 +462,7 @@ config PPC_64K_PAGES
>  
>  config PPC_256K_PAGES
>  	bool "256k page size" if 44x
> -	depends on !STDBINUTILS && (!SHMEM || BROKEN)
> +	depends on !STDBINUTILS
>  	help
>  	  Make the page size 256k.
>  
>   

Regards, Ilya.

^ permalink raw reply

* issues w/init
From: Kumar Gala @ 2009-04-16 18:21 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development

Ben,

The following patch is causing me issues w/init SEGV on boot.  This is  
a pretty old version of init and I'm wondering what the commit you had  
related to old ABI breakage:

commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Feb 10 16:02:37 2009 +0000

     powerpc/mm: Rework I$/D$ coherency (v3)

     This patch reworks the way we do I and D cache coherency on  
PowerPC.


---
                 /*
                  * Allow execution from readable areas if the MMU  
does not
                  * provide separate controls over reading and  
executing.
+                *
+                * Note: That code used to not be enabled for 4xx/BookE.
+                * It is now as I/D cache coherency for these is done at
+                * set_pte_at() time and I see no reason why the test
+                * below wouldn't be valid on those processors. This - 
may-
+                * break programs compiled with a really old ABI though.
                  */

- k

^ permalink raw reply

* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: David Woodhouse @ 2009-04-16 18:38 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: linuxppc-dev, Stefan Roese, linux-mtd, devicetree-discuss
In-Reply-To: <1239889899.3390.216.camel@localhost.localdomain>

On Thu, 16 Apr 2009, Artem Bityutskiy wrote:

> On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
>> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese <sr@denx.de> wrote:
>>> On Thursday 16 April 2009, Grant Likely wrote:
>>>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>>>> Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
>>>>
>>>> Yup, still looks good to me.  What boards has this been tested on?
>>>
>>> I tested this version on PPC405EX Kilauea equipped only one "standard"
>>> Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360
>>> board (kmeter1) which is equipped with the Intel P30 part mentioned in the
>>> bindings description. Slightly modified since this board support is not yet
>>> pushed upstream and currently using v2.6.28 (physmap_of.c has received minor
>>> modifications after 2.6.28 release).
>>
>> Okay.  It will be good to get this one into -next for some testing
>> exposure.  Unless he asks me to do otherwise, I'll leave this one to
>> David to pick up.
>
> David usually picks up stuff just before or during merge window,
> so if you want linux-next exposure, you need to have some extra
> care.

I don't necessarily do that on purpose; it just works out that way when 
I'm busy.

-- 
dwmw2

^ permalink raw reply

* Re: issues w/init
From: Kumar Gala @ 2009-04-16 18:53 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development
In-Reply-To: <680ABFDC-A67F-48BB-B46C-564CB5373FEB@kernel.crashing.org>


On Apr 16, 2009, at 1:21 PM, Kumar Gala wrote:

> Ben,
>
> The following patch is causing me issues w/init SEGV on boot.  This  
> is a pretty old version of init and I'm wondering what the commit  
> you had related to old ABI breakage:
>
> commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Tue Feb 10 16:02:37 2009 +0000
>
>    powerpc/mm: Rework I$/D$ coherency (v3)
>
>    This patch reworks the way we do I and D cache coherency on  
> PowerPC.
>
>
> ---
>                /*
>                 * Allow execution from readable areas if the MMU  
> does not
>                 * provide separate controls over reading and  
> executing.
> +                *
> +                * Note: That code used to not be enabled for 4xx/ 
> BookE.
> +                * It is now as I/D cache coherency for these is  
> done at
> +                * set_pte_at() time and I see no reason why the test
> +                * below wouldn't be valid on those processors. This  
> -may-
> +                * break programs compiled with a really old ABI  
> though.
>                 */
>
> - k

A bit more debug info that might be helpful, I'm hitting this bad_area  
fault :

                 if (!(vma->vm_flags & VM_EXEC) &&
                     (cpu_has_feature(CPU_FTR_NOEXECUTE) ||
                      !(vma->vm_flags & (VM_READ | VM_WRITE))))
                         goto bad_area;

bad_area 7 = 48024bf4 vm_flags:0810 0873
SEGV 3 address:48024bf4 trap:400 error_code:0

[root:~] cat /proc/1/maps
00100000-00103000 r-xp 00100000 00:00 0          [vdso]
0feab000-0ffbe000 r-xp 00000000 00:0d 7127086    /lib/libc-2.2.5.so
0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086    /lib/libc-2.2.5.so
0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086    /lib/libc-2.2.5.so
0ffeb000-0fff0000 rw-p 0ffeb000 00:00 0
10000000-10008000 r-xp 00000000 00:0d 9093222    /sbin/init
10017000-10018000 rw-p 00007000 00:0d 9093222    /sbin/init
10018000-1001c000 rwxp 10018000 00:00 0          [heap]
48000000-48013000 r-xp 00000000 00:0d 7127082    /lib/ld-2.2.5.so
48022000-48026000 rw-p 00012000 00:0d 7127082    /lib/ld-2.2.5.so
bfd0e000-bfd23000 rwxp bffeb000 00:00 0          [stack]

^ permalink raw reply

* Re: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: Grant Likely @ 2009-04-16 19:01 UTC (permalink / raw)
  To: John Linn; +Cc: linux-fbdev-devel, adaplas, Suneel, linuxppc-dev, akonovalov
In-Reply-To: <20090416163021.023DC770050@mail77-va3.bigfish.com>

On Thu, Apr 16, 2009 at 10:26 AM, John Linn <john.linn@xilinx.com> wrote:
> Added support for the new xps tft controller. The new core
> has PLB interface support in addition to existing DCR interface.
>
> Removed platform device support as both MicroBlaze and PowerPC
> use device tree.
>
> Previously, the dcr interface was assumed to be used in mmio mode,
> and the register space of the dcr interface was precomputed and stuffed
> into the device tree. This driver now makes use of the new dcr
> infrastructure to represent the dcr interface. This enables the dcr
> interface to be connected directly to a native dcr interface in a clean
> way.
>
> Added compatibility for ml507 dvi core.
>
> Signed-off-by: Suneel <suneelg@xilinx.com>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
>
> V2 - cleanup based on review
> V3 - update to be based on top of tree rather than Xilinx tree, sorry for=
 the
> =A0confusion with this, update the name of the patch slightly to be more =
accurate
> V4 - update based on Grant's comments to simplify it, the binding wasn't =
changed
> =A0as the conversation seemed to verify it's acceptable

Actually Stephen and I agreed that the driver should *not* go looking
for the xlnx,dcr-splb-slave-if property.  reg and dcr-reg are
sufficient.  If a driver has both properties, then either method of
access will work.


> @@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var =3D {
> =A0 =A0 =A0 =A0.activate =3D =A0 =A0 FB_ACTIVATE_NOW
> =A0};
>
> +
> +#define PLB_ACCESS_FLAG =A0 =A0 =A0 =A00x1 =A0 =A0 =A0 =A0 =A0 =A0 /* 1 =
=3D PLB, 0 =3D DCR */
> +

Also, this define is no longer required.

g.

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

^ permalink raw reply

* Re: OF PCI howto?
From: Grant Likely @ 2009-04-16 19:21 UTC (permalink / raw)
  To: Roderick Colenbrander; +Cc: linuxppc-dev, Joakim Tjernlund
In-Reply-To: <c8485d470904160203y66d456f7xd73692b177587822@mail.gmail.com>

On Thu, Apr 16, 2009 at 3:03 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund
> <Joakim.Tjernlund@transmode.se> wrote:
>> Kumar Gala <galak@kernel.crashing.org> wrote on 15/04/2009 17:20:21:
>>> On Apr 15, 2009, at 8:08 AM, Wolfram Sang wrote:
>>>
>>> > On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
>>> >
>>> >> dts fragment correct for my setup? If not, is there a better
>>> >> example I can
>>> >> look at?
>>> >
>>> > Maybe this message/thread can help you:
>>> >
>>> > http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html
>>>
>>> You may also want to take a look at ePAPR on the power.org site
>>
>> Thanks guys
>>
>> Looking in ePAPR I see I should read the IDSEL like this:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* IDSEL 0x11 AD17 */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD *=
/
>>
>> grouping the first line into:
>> "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */
>>
>> "0x8800 0x0 0x0" =3D child unit address
>> "0x1" =3D child interrupt specifier =3D INTA
>> "&ipic" =3D interrupt parent
>> "20 0x8" =3D parent interrupt specifier
>>
>> Questions:
>> =A0MPC832x appears to only have INTA so why are the INTB,INTC
>> =A0and INTD lines there?
>>
>> =A0I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18
>> randomly
>> =A0selected or are they fixed for MPC832x?
>
> The idsel values depend on how the pci slots are wired on your board.
> The 0x8800 value is
> in general a function of bus, device and function number. ( bus << 16
> | devfn << 8)
>
> Further I would also watch out with the parent interrupt specifier
> e.g. '20 0x8'. The openfirmware spec
> normally suggests to use a value of '2' for interrupts which are
> active low. During parsing of the interrupt-map
> this value is normally translated using 'xlate' to linux kernel values
> (active low is defined as IRQ_TYPE_LEVEL_LOW =A0 =A0 =A00x00000008 in the
> kernel).
> The ipic driver code and various dts files are evil and store the
> linux kernel value inside the DTS file, so they don't do any
> conversion whis is EVIL
> in my opinion. Watch out for that.

They're just numbers and they are intended to by interrupt controller
specific values.  Some IRQ controllers don't even have a 'flags' field
for instance.  The binding author is free to choose values he or she
deems suitable for the purpose as long as it is documented and
reviewed.

> (The corresponding DTS files and
> drivers should be updated).

No.  The binding is set.  We've made a commitment to not change
bindings after they are defined and deployed.  In some cases it is not
easy to update the device tree blob in deployed systems.


>
> Regards,
> Roderick Colenbrander
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



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

^ 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