Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
On Tue, 14 Apr 2009 16:45:38 +0200, Takashi Iwai wrote: > Johannes, please let me know if the patch works. Then I'll merge them. Note if it matters: the new I2C binding model my patch uses is only available since kernel 2.6.26. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
At Thu, 16 Apr 2009 09:53:39 +0200, Jean Delvare wrote: > > On Tue, 14 Apr 2009 16:45:38 +0200, Takashi Iwai wrote: > > Johannes, please let me know if the patch works. Then I'll merge them. > > Note if it matters: the new I2C binding model my patch uses is only > available since kernel 2.6.26. Yep, I'll add some backward compatible stuff to alsa-driver external tree so that it can be built for older kernels. thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF PCI howto?
Kumar Gala 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: /* IDSEL 0x11 AD17 */ 0x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA */ 0x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB */ 0x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC */ 0x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD */ grouping the first line into: "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */ "0x8800 0x0 0x0" = child unit address "0x1" = child interrupt specifier = INTA "&ipic" = interrupt parent "20 0x8" = parent interrupt specifier Questions: MPC832x appears to only have INTA so why are the INTB,INTC and INTD lines there? I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18 randomly selected or are they fixed for MPC832x? What I really trying to understand is what fields I might need to change and what to change them to. So far the "interrupt-map" and the "ranges" items looks like they might need some tweaking, but I really don't know at this point. Any pointers in this area is much appreciated. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
On Thu, 2009-04-16 at 11:06 +0530, Sachin Sant wrote:
> Sachin Sant wrote:
> > Sachin Sant wrote:
> >> Benjamin Herrenschmidt wrote:
> >>> On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote:
> >>>
> While executing CPU HotPlug[1] tests i observed that during
> every cpu offline process an exception is thrown.
>
> >>>
> >>> Looks like a BUG_ON() to me... can you look at what other
> >>> messages just before that ?
> >>
> > Ben, seems like the following patch is causing the cpu hotplug
> > test failure.
> > [PATCH 6/6] powerpc/mm: Introduce early_init_mmu() on 64-bit
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069613.html
> >
> > If i back out this patch, i am able to offline/online cpu's
> > without any issue.
> I can recreate this problem with 2.6.30-rc2-git1 as well. Same BUG_ON while
> running cpu hotplug tests.
>
> Let me know if there is any thing i can help to find a fix for this.
Hi Sachin,
Does this patch, on top of Ben's patch, fix it?
cheers
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))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Question about windfarm drivers
Hi Ben, hi Paul, As I am converting the windfarm drivers to the new i2c device binding model, I need to understand how these drivers work currently. There's one thing I do not understand so I'd appreciate if you could explain it to me. I am looking at function wf_lm75_detach() in windfarm_lm75_sensor.c. This function is called by i2c-core if either i2c-powermac or windfarm_lm75_sensor is unloaded. It sets lm->i2c.adapter to NULL and then calls wf_unregister_sensor(), which in turn calls wf_put_sensor(), which calls wf_sensor_release() is the reference count drops to 0, which in turns call the driver's .release() method, that is, wf_lm75_release() in our case. In wf_lm75_release(), i2c_detach_client() is called if and only if lm->i2c.adapter is set, which is not the case, and then the data structure, including the i2c client, is freed from memory. This means that the freed i2c client is still registered with i2c-core, this looks wrong. Am I missing something? Or is this clean-up path broken and nobody ever noticed? I am also curious why wf_unregister_sensor() calls wf_put_sensor() while wf_register_sensor() doesn't call wf_get_sensor(). Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Looking for good supported South bridge for mpc6841d
On Wednesday 15 April 2009 14:17:47 you wrote: > On Wed, Apr 15, 2009 at 1:23 PM, Zhivko Yordanov wrote: > > Hello, > > > > I'm on designing of a new embedded board, based on mpc6841d and South > > Bridge ULi M1575. As а reference design, I use Freescale HPCN board. > > However after consult with chip's distributor, it became clear that the > > M1575 is already discounted. Now I'm in looking of an another solution. > > Can somebody recommend me an alternative, good supported from u-boot and > > have SATA, USB, Audio on it? The chip must be connected with mpc6841d > > over PCI-Express. > > > > Best regarsds, > > > > Yordanov > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > I think the only alternatives you have are chips from Via and perhaps > Sis. It looks like Via has some nice south bridges which do what you > want, see: > http://www.via.com.tw/en/products/chipsets/south-bridges.jsp > > Roderick Thank you for the anser! Unfortunately VIA and SIS uses own connection bus between North and Sout bridges - V-map and MuTiol. I found AMD's SB600 and SB7x0 bridges, that seems to connect through PCI-Express. Are they from u-boot spupported? Best regards ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
Michael Ellerman wrote:
Does this patch, on top of Ben's patch, fix it?
cheers
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))
Yes, this patch fixed the issue. Now i can offline/online cpus without
any problem.
Thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF PCI howto?
On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund wrote: > Kumar Gala 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: > /* IDSEL 0x11 AD17 */ > 0x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA */ > 0x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB */ > 0x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC */ > 0x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD */ > > grouping the first line into: > "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */ > > "0x8800 0x0 0x0" = child unit address > "0x1" = child interrupt specifier = INTA > "&ipic" = interrupt parent > "20 0x8" = parent interrupt specifier > > Questions: > MPC832x appears to only have INTA so why are the INTB,INTC > and INTD lines there? > > I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18 > randomly > selected 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 0x0008 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. (The corresponding DTS files and drivers should be updated). Regards, Roderick Colenbrander ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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). Thanks, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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:
fl...@f000,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0 0x 0x0200
0 0x0200 0x0200>;
bank-width = <2>;
partit...@0 {
label = "test-part1";
reg = <0 0x0400>;
};
};
Signed-off-by: Stefan Roese
Reviewd-by: Grant Likely
---
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 limit
for "reg" tuples anymore.
- Used of_n_addr_cells() and of_n_size_cells() to determine size of each tuple.
drivers/mtd/maps/physmap_of.c | 199 +
1 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 @@
#include
#include
#include
+#include
#include
#include
+struct of_flash_list {
+ struct mtd_info *mtd;
+ struct map_info map;
+ struct resource *res;
+};
+
struct of_flash {
- struct mtd_info *mtd;
- struct map_info map;
- struct resource *res;
+ struct mtd_info *cmtd;
#ifdef CONFIG_MTD_PARTITIONS
struct mtd_partition*parts;
#endif
+ int list_size; /* number of elements in of_flash_list */
+ struct of_flash_listlist[0];
};
#ifdef CONFIG_MTD_PARTITIONS
@@ -88,30 +95,44 @@ static int parse_obsolete_partitions(struct of_device *dev,
static int of_flash_remove(struct of_device *dev)
{
struct of_flash *info;
+ int i;
info = dev_get_drvdata(&dev->dev);
if (!info)
return 0;
dev_set_drvdata(&dev->dev, NULL);
- if (info->mtd) {
+#ifdef CONFIG_MTD_CONCAT
+ if (info->cmtd != info->list[0].mtd) {
+ del_mtd_device(info->cmtd);
+ mtd_concat_destroy(info->cmtd);
+ }
+#endif
+
+ if (info->cmtd) {
if (OF_FLASH_PARTS(info)) {
- del_mtd_partitions(info->mtd);
+ del_mtd_partitions(info->cmtd);
kfree(OF_FLASH_PARTS(info));
} else {
- del_mtd_device(info->mtd);
+ del_mtd_device(info->cmtd);
}
- map_destroy(info->mtd);
}
- if (info->map.virt)
- iounmap(info->map.virt);
+ for (i = 0; i < info->list_size; i++) {
+ if (info->list[i].mtd)
+ map_destroy(info->list[i].mtd);
- if (info->res) {
- release_resource(info->res);
- kfree(info->res);
+ if (info->list[i].map.virt)
+ iounmap(info->list[i].map.virt);
+
+ if (info->list[i].res) {
+ release_resource(info->list[i].res);
+ kfree(info->list[i].res);
+ }
}
+ kfree(info);
+
return 0;
}
@@ -164,68 +185,130 @@ static int __devinit of_flash_probe(struct of_device
*dev,
const char *probe_type = match->data;
const u32 *width;
int err;
-
- err = -ENXIO;
- if (of_address_to_resource(dp, 0, &res)) {
- dev_err(&dev->dev, "Can't get IO address from device tree\n");
+ int i;
+ int count;
+ const u32 *p;
+ int reg_tuple_size;
+ struct mtd_info **mtd_list = NULL;
+
+ reg_tuple_size = (of_n_addr_cells(dp) + of_n_size_cells(dp)) *
sizeof(u32);
+
+ /*
+* Get number of "reg" tuples. Scan for MTD devices on area's
+* described by each "reg" region. This makes it possible (including
+* the concat support) to support the Intel P30 48F4400 chips which
+* consists internally of 2 non-identical NOR chips on one die.
+*/
+ p = of_get_property(dp, "reg", &count);
+ if (count % reg_tuple_size != 0) {
+ dev_err(&dev->dev, "Malformed reg property on %s\n",
+ dev->node->full_name);
+ err = -EINVAL;
goto err_out;
}
-
- dev_dbg(&dev->dev, "of_flash device: %.8llx-%.8llx\n",
- (unsigned long long)res.start, (unsigned long lo
[PATCH 2/3 v3] mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
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
Acked-by: Grant Likely
---
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:
-
- fl...@ff00 {
- compatible = "amd,am29lv128ml", "cfi-flash";
- reg = ;
- bank-width = <4>;
- device-width = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- f...@0 {
- label = "fs";
- reg = <0 f8>;
- };
- firmw...@f8 {
- label ="firmware";
- reg = ;
- 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: 0x012a
- e) Xilinx IP c
[PATCH 3/3 v3] mtd/powerpc: Describe multiple "reg" tuples usage
Signed-off-by: Stefan Roese
CC: Grant Likely
---
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:
+
+ fl...@f000,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "intel,PC48F4400P0VB", "cfi-flash";
+ reg = <0 0x 0x0200
+ 0 0x0200 0x0200>;
+ bank-width = <2>;
+ partit...@0 {
+ label = "test-part1";
+ reg = <0 0x0400>;
+ };
+ };
--
1.6.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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 (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, Apr 16, 2009 at 6:19 AM, 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. 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 (Битюцкий Артём) > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt
Looks good, I'll pick this up
g.
On Thu, Apr 16, 2009 at 6:10 AM, Stefan Roese wrote:
> 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
> Acked-by: Grant Likely
> ---
> 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:
> -
> - fl...@ff00 {
> - compatible = "amd,am29lv128ml", "cfi-flash";
> - reg = ;
> - bank-width = <4>;
> - device-width = <1>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - f...@0 {
> - label = "fs";
> - reg = <0 f8>;
> - };
> - firmw...@f8 {
> - label ="firmware";
> - reg = ;
> - read-only;
> - };
> - };
> -
> - d) 4xx/Axon EMAC ethernet nodes
> + c) 4xx/Axon EMAC ethernet nodes
>
> The EMAC ethern
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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 (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3 v3] mtd/powerpc: Describe multiple "reg" tuples usage
On Thu, Apr 16, 2009 at 6:11 AM, Stefan Roese wrote:
> Signed-off-by: Stefan Roese
> CC: Grant Likely
Acked-by: Grant Likely
I'll pick this one up too.
> ---
> 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:
> +
> + fl...@f000,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "intel,PC48F4400P0VB", "cfi-flash";
> + reg = <0 0x 0x0200
> + 0 0x0200 0x0200>;
> + bank-width = <2>;
> + partit...@0 {
> + label = "test-part1";
> + reg = <0 0x0400>;
> + };
> + };
> --
> 1.6.2.3
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, Apr 16, 2009 at 6:10 AM, Stefan Roese 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:
>
> fl...@f000,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "cfi-flash";
> reg = <0 0x 0x0200
> 0 0x0200 0x0200>;
> bank-width = <2>;
> partit...@0 {
> label = "test-part1";
> reg = <0 0x0400>;
> };
> };
>
> Signed-off-by: Stefan Roese
> Reviewd-by: Grant Likely
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 limit
> for "reg" tuples anymore.
> - Used of_n_addr_cells() and of_n_size_cells() to determine size of each
> tuple.
>
> drivers/mtd/maps/physmap_of.c | 199
> +
> 1 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 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> +struct of_flash_list {
> + struct mtd_info *mtd;
> + struct map_info map;
> + struct resource *res;
> +};
> +
> struct of_flash {
> - struct mtd_info *mtd;
> - struct map_info map;
> - struct resource *res;
> + struct mtd_info *cmtd;
> #ifdef CONFIG_MTD_PARTITIONS
> struct mtd_partition *parts;
> #endif
> + int list_size; /* number of elements in of_flash_list */
> + struct of_flash_list list[0];
> };
>
> #ifdef CONFIG_MTD_PARTITIONS
> @@ -88,30 +95,44 @@ static int parse_obsolete_partitions(struct of_device
> *dev,
> static int of_flash_remove(struct of_device *dev)
> {
> struct of_flash *info;
> + int i;
>
> info = dev_get_drvdata(&dev->dev);
> if (!info)
> return 0;
> dev_set_drvdata(&dev->dev, NULL);
>
> - if (info->mtd) {
> +#ifdef CONFIG_MTD_CONCAT
> + if (info->cmtd != info->list[0].mtd) {
> + del_mtd_device(info->cmtd);
> + mtd_concat_destroy(info->cmtd);
> + }
> +#endif
> +
> + if (info->cmtd) {
> if (OF_FLASH_PARTS(info)) {
> - del_mtd_partitions(info->mtd);
> + del_mtd_partitions(info->cmtd);
> kfree(OF_FLASH_PARTS(info));
> } else {
> - del_mtd_device(info->mtd);
> + del_mtd_device(info->cmtd);
> }
> - map_destroy(info->mtd);
> }
>
> - if (info->map.virt)
> - iounmap(info->map.virt);
> + for (i = 0; i < info->list_size; i++) {
> + if (info->list[i].mtd)
> + map_destroy(info->list[i].mtd);
>
> - if (info->res) {
> - release_resource(info->res);
> - kfree(info->res);
> + if (info->list[i].map.virt)
> + iounmap(info->list[i].map.virt);
> +
> + if (info->list[i].res) {
> + release_resource(info->list[i].res);
> + kfree(info->list[i].res);
> + }
> }
>
> + kfree(info);
> +
> return 0;
> }
>
> @@ -164,68 +185,130 @@ static int __devinit of_flash_probe(struct of_device
> *dev,
> const char *probe_type = match->data;
> const u32 *width;
> int err;
> -
> - err = -ENXIO;
> - if (of_address_to_resource(dp, 0, &res)) {
> - dev_err(&dev->dev, "Can't get IO address from device tree\n");
> + int i;
> + int count;
> + const u32 *p;
> + int reg_tuple_size;
> + struct mtd_info **mtd_list = NULL;
> +
> + reg_tuple_size = (of_n_addr_cells(dp) + of_n_size_cells(dp)) *
> sizeof(u32);
> +
> + /*
> + * Get number of "reg" tuples. Scan for MTD devices on area's
> + * described by each "reg" region. This makes it possible (including
> + * the concat support) to support the Intel P30 48F4400 chips which
> + * consists internally of 2 non-identical NOR chips on one die.
> + */
> + p = of_get_property(dp, "reg", &count)
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thursday 16 April 2009, Grant Likely wrote: > > Signed-off-by: Stefan Roese > > Reviewd-by: Grant Likely > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese wrote: > On Thursday 16 April 2009, Grant Likely wrote: >> > Signed-off-by: Stefan Roese >> > Reviewd-by: Grant Likely >> >> 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. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thursday 16 April 2009, Grant Likely wrote: > >> 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. Understood. Thanks Grant. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote: > On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese wrote: > > On Thursday 16 April 2009, Grant Likely wrote: > >> > Signed-off-by: Stefan Roese > >> > Reviewd-by: Grant Likely > >> > >> 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 (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, Apr 16, 2009 at 7:51 AM, 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 wrote: >> > On Thursday 16 April 2009, Grant Likely wrote: >> >> > Signed-off-by: Stefan Roese >> >> > Reviewd-by: Grant Likely >> >> >> >> 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. 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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix crash on CPU hotplug
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
Signed-off-by: Michael Ellerman
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ppc32: Don't clobber personality flags on exec
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
---
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.h2009-04-08
12:45:56.0 +0200
+++ linux-2.6.30-rc1/arch/powerpc/include/asm/elf.h 2009-04-12
14:24:06.0 +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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
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
Signed-off-by: Stephen Neuendorffer
Signed-off-by: John Linn
---
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.
* sou...@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
#include
#include
+#include
#include
#include
#include
#include
#include
#include
-#include
-#if defined(CONFIG_OF)
#include
#include
-#endif
-#include
+#include
#include
+#include
#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_ADDR0
@@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG0x1 /* 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 intdcr_start;
+ unsigned intdcr_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 (drvdat
[PATCH] windfarm: Convert to a new-style i2c drivers
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
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
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.0 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/windfarm_lm75_sensor.c 2009-04-16
11:23:17.0 +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(l
Re: OF PCI howto?
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: allow 256kB pages with SHMEM
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 > Acked-by: Ilya Yanok > --- > 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.0 +0100 > +++ linux/arch/powerpc/Kconfig2009-04-06 18:18:47.0 +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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
issues w/init
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 Date: Tue Feb 10 16:02:37 2009 + 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
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 wrote: On Thursday 16 April 2009, Grant Likely wrote: Signed-off-by: Stefan Roese Reviewd-by: Grant Likely 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issues w/init
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 Date: Tue Feb 10 16:02:37 2009 + 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 0010-00103000 r-xp 0010 00:00 0 [vdso] 0feab000-0ffbe000 r-xp 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 0011 00:0d 7127086/lib/libc-2.2.5.so 0ffeb000-0fff rw-p 0ffeb000 00:00 0 1000-10008000 r-xp 00:0d 9093222/sbin/init 10017000-10018000 rw-p 7000 00:0d 9093222/sbin/init 10018000-1001c000 rwxp 10018000 00:00 0 [heap] 4800-48013000 r-xp 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] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
On Thu, Apr 16, 2009 at 10:26 AM, John Linn 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
> Signed-off-by: Stephen Neuendorffer
> Signed-off-by: John Linn
> ---
>
> 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
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 = {
> .activate = FB_ACTIVATE_NOW
> };
>
> +
> +#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
> +
Also, this define is no longer required.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF PCI howto?
On Thu, Apr 16, 2009 at 3:03 AM, Roderick Colenbrander wrote: > On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund > wrote: >> Kumar Gala 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: >> /* IDSEL 0x11 AD17 */ >> 0x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA */ >> 0x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB */ >> 0x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC */ >> 0x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD */ >> >> grouping the first line into: >> "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */ >> >> "0x8800 0x0 0x0" = child unit address >> "0x1" = child interrupt specifier = INTA >> "&ipic" = interrupt parent >> "20 0x8" = parent interrupt specifier >> >> Questions: >> MPC832x appears to only have INTA so why are the INTB,INTC >> and INTD lines there? >> >> I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18 >> randomly >> selected 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 0x0008 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 > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issues w/init
Kumar Gala wrote: [root:~] cat /proc/1/maps 0010-00103000 r-xp 0010 00:00 0 [vdso] 0feab000-0ffbe000 r-xp 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 0011 00:0d 7127086/lib/libc-2.2.5.so IIRC, this libc is old enough to execute out of non-exec memory in some cases. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/4] powerpc/ps3: Fix no flash build warning
Fix build warnings like these when CONFIG_PS3_FLASH=n:
arch/powerpc/platforms/ps3/os-area.c: warning: 'update_flash_db' defined but
not used
Signed-off-by: Geoff Levand
---
arch/powerpc/platforms/ps3/os-area.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -578,7 +578,7 @@ static void os_area_db_init(struct os_ar
*
*/
-static void update_flash_db(void)
+static void __maybe_unused update_flash_db(void)
{
int result;
int file;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/4] PS3 2.6.30 patches
Hi Paul, This is a small set of patches for 2.6.30. (1) and (2) are simple build fixes. (3) is a patch by Milton submitted back in October that seems to have beed missed. Could you consider it for 2.6.30? (4) is an update to the MAINTAINERS file. Can you take it? [patch 1/4] powerpc/ps3: Fix no SMP build error [patch 2/4] powerpc/ps3: Fix no flash build warning [patch 3/4] powerpc ps3: use smp_request_message_ipi [patch 4/4] maintainers: Fix PS3 patterns -Geoff -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/4] powerpc/ps3: Fix no SMP build error
A non-SMP version of smp_send_stop() is now included in smp.h.
Remove the unneeded def in the PS3 smp.c.
Fixes build errors like these when CONFIG_SMP=n:
arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of 'smp_send_stop'
include/linux/smp.h:125: error: previous definition of 'smp_send_stop' was
here
Reported-by: Subrata Modak
Signed-off-by: Geoff Levand
---
arch/powerpc/platforms/ps3/setup.c |4
1 file changed, 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -45,10 +45,6 @@
DEFINE_MUTEX(ps3_gpu_mutex);
EXPORT_SYMBOL_GPL(ps3_gpu_mutex);
-#if !defined(CONFIG_SMP)
-static void smp_send_stop(void) {}
-#endif
-
static union ps3_firmware_version ps3_firmware_version;
void ps3_get_firmware_version(union ps3_firmware_version *v)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/4] maintainers: Fix PS3 patterns
Correct the MAINTAINERS file patterns for PS3. Removes some PS3 patterns that were under 'CELL BROADBAND ENGINE ARCHITECTURE', and adds missing PS3 sound and RTC driver patterns. CC: Arnd Bergmann Signed-off-by: Geoff Levand --- MAINTAINERS |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1280,12 +1280,9 @@ L: cbe-oss-...@ozlabs.org W: http://www.ibm.com/developerworks/power/cell/ S: Supported F: arch/powerpc/include/asm/cell*.h -F: arch/powerpc/include/asm/lv1call.h -F: arch/powerpc/include/asm/ps3*.h F: arch/powerpc/include/asm/spu*.h F: arch/powerpc/oprofile/*cell* F: arch/powerpc/platforms/cell/ -F: arch/powerpc/platforms/ps3/ CERTIFIED WIRELESS USB (WUSB) SUBSYSTEM: P: David Vrabel @@ -4434,7 +4431,9 @@ F:arch/powerpc/include/asm/ps3*.h F: arch/powerpc/platforms/ps3/ F: drivers/*/ps3* F: drivers/ps3/ +F: drivers/rtc/rtc-ps3.c F: drivers/usb/host/*ps3.c +F: sound/ppc/snd_ps3* PS3VRAM DRIVER P: Jim Paris -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/4] powerpc ps3: use smp_request_message_ipi
ps3 has 4 ipis per cpu and can use the new smp_request_message_ipi to
reduce path length when receiving an ipi.
This has the side effect of setting IRQF_PERCPU.
Signed-off-by: Milton Miller
Acked-by: Geoff Levand
Index: next.git/arch/powerpc/platforms/ps3/smp.c
===
--- next.git.orig/arch/powerpc/platforms/ps3/smp.c 2008-10-05
00:20:41.0 -0500
+++ next.git/arch/powerpc/platforms/ps3/smp.c 2008-10-05 00:22:50.0
-0500
@@ -32,12 +32,6 @@
#define DBG pr_debug
#endif
-static irqreturn_t ipi_function_handler(int irq, void *msg)
-{
- smp_message_recv((int)(long)msg);
- return IRQ_HANDLED;
-}
-
/**
* ps3_ipi_virqs - a per cpu array of virqs for ipi use
*/
@@ -45,13 +39,6 @@ static irqreturn_t ipi_function_handler(
#define MSG_COUNT 4
static DEFINE_PER_CPU(unsigned int, ps3_ipi_virqs[MSG_COUNT]);
-static const char *names[MSG_COUNT] = {
- "ipi call",
- "ipi reschedule",
- "ipi migrate",
- "ipi debug brk"
-};
-
static void do_message_pass(int target, int msg)
{
int result;
@@ -119,8 +106,7 @@ static void __init ps3_smp_setup_cpu(int
DBG("%s:%d: (%d, %d) => virq %u\n",
__func__, __LINE__, cpu, i, virqs[i]);
- result = request_irq(virqs[i], ipi_function_handler,
- IRQF_DISABLED, names[i], (void*)(long)i);
+ result = smp_request_message_ipi(virqs[i], i);
if (result)
virqs[i] = NO_IRQ;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issues w/init
On Apr 16, 2009, at 2:25 PM, Scott Wood wrote: Kumar Gala wrote: [root:~] cat /proc/1/maps 0010-00103000 r-xp 0010 00:00 0 [vdso] 0feab000-0ffbe000 r-xp 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 0011 00:0d 7127086/lib/libc-2.2.5.so IIRC, this libc is old enough to execute out of non-exec memory in some cases. Yeah, I'm going to that realization. The question is are we ok with breaking older versions of libc like this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 03/12] Next April 14 : PPC64 randconfig [arch/powerpc/platforms/ps3/setup.c]
On 04/14/2009 11:28 AM, Subrata Modak wrote: > Observed the following build error: > --- > arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of > ‘smp_send_stop’ > include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’ > was here Hi Subrata, Thanks for the report. I submitted a fix to the powerpc ML: http://patchwork.ozlabs.org/patch/26084/ -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
Sounds good, I'll spin it again with those changes.
-- John
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> Sent: Thursday, April 16, 2009 1:02 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org; linux-fbdev-de...@lists.sourceforge.net;
> akonova...@ru.mvista.com;
> adap...@gmail.com; jwbo...@linux.vnet.ibm.com; Suneel Garapati; Stephen
> Neuendorffer
> Subject: Re: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and
> cleanup DCR
>
> On Thu, Apr 16, 2009 at 10:26 AM, John Linn 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
> > Signed-off-by: Stephen Neuendorffer
> > Signed-off-by: John Linn
> > ---
> >
> > 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
>
> 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 = {
> > .activate = FB_ACTIVATE_NOW
> > };
> >
> > +
> > +#define PLB_ACCESS_FLAG 0x1 /* 1 = PLB, 0 = DCR */
> > +
>
> Also, this define is no longer required.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
Hi, On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: > Hi, > > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge > for IDE, USB and Audio. I did a lot of work to get the pci bus working > on this board and it works correctly but the default init code > of the alim15x3 driver doesn't work for me. The driver explicitly > disabled some initialization code for powerpc after uncommenting this > code it works properly. Benjamin Herrenschmidt and I think this > !CONFIG_PPC check should be removed because the system behaves > like a real 'x86' system (also the i8259 interrupt controller is used). Ben, I guess you are OK with the change and there are no longer other platforms requiring CONFIG_PPC check below? [I don't see your ACK here] > Regards, > Roderick Colenbrander > > > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001 > From: Roderick Colenbrander > Date: Wed, 15 Apr 2009 10:45:17 +0200 > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for > x86-like PowerPC boards like Xilinx ML310/410/510. Roderick, please add your "Signed-off-by:" line (per Documentation/SubmittingPatches). Thanks. > --- > drivers/ide/alim15x3.c |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c > index 537da1c..9176c0f 100644 > --- a/drivers/ide/alim15x3.c > +++ b/drivers/ide/alim15x3.c > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif) > return cbl; > } > > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) > +#if !defined(CONFIG_SPARC64) > /** > *init_hwif_ali15x3-Initialize the ALI IDE x86 stuff > *@hwif: interface to configure > * > *Obtain the IRQ tables for an ALi based IDE solution on the PC > - *class platforms. This part of the code isn't applicable to the > - *Sparc and PowerPC systems. > + *class platforms. This part of the code isn't applicable to > + *Sparc systems. It is usable on 'x86-like' PowerPC systems > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510. > */ > > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) > } > #else > #define init_hwif_ali15x3 NULL > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */ > +#endif /* !defined(CONFIG_SPARC64) */ > > /** > *init_dma_ali15x3-set up DMA on ALi15x3 > -- > 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
Hi Roderick, Since this patch is Xilinx virtex related, it is a good idea to cc: both the linuxppc-dev mailing list and me when posting. That way I'd have the opportunity to reply with an 'acked-by' or 'reviewed-by' line. g. On Thu, Apr 16, 2009 at 1:30 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: >> Hi, >> >> I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a >> Virtex-5 FPGA. The board also contains a ALI M1533 south bridge >> for IDE, USB and Audio. I did a lot of work to get the pci bus working >> on this board and it works correctly but the default init code >> of the alim15x3 driver doesn't work for me. The driver explicitly >> disabled some initialization code for powerpc after uncommenting this >> code it works properly. Benjamin Herrenschmidt and I think this >> !CONFIG_PPC check should be removed because the system behaves >> like a real 'x86' system (also the i8259 interrupt controller is used). > > Ben, I guess you are OK with the change and there are no longer other > platforms requiring CONFIG_PPC check below? [I don't see your ACK here] > >> Regards, >> Roderick Colenbrander >> >> >> From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001 >> From: Roderick Colenbrander >> Date: Wed, 15 Apr 2009 10:45:17 +0200 >> Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for >> x86-like PowerPC boards like Xilinx ML310/410/510. > > Roderick, please add your "Signed-off-by:" line > (per Documentation/SubmittingPatches). > > Thanks. > >> --- >> drivers/ide/alim15x3.c | 9 + >> 1 files changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c >> index 537da1c..9176c0f 100644 >> --- a/drivers/ide/alim15x3.c >> +++ b/drivers/ide/alim15x3.c >> @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif) >> return cbl; >> } >> >> -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) >> +#if !defined(CONFIG_SPARC64) >> /** >> * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff >> * �...@hwif: interface to configure >> * >> * Obtain the IRQ tables for an ALi based IDE solution on the PC >> - * class platforms. This part of the code isn't applicable to the >> - * Sparc and PowerPC systems. >> + * class platforms. This part of the code isn't applicable to >> + * Sparc systems. It is usable on 'x86-like' PowerPC systems >> + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510. >> */ >> >> static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) >> @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t >> *hwif) >> } >> #else >> #define init_hwif_ali15x3 NULL >> -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */ >> +#endif /* !defined(CONFIG_SPARC64) */ >> >> /** >> * init_dma_ali15x3 - set up DMA on ALi15x3 >> -- >> 1.5.6.3 > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: > > Hi, > > > > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a > > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge > > for IDE, USB and Audio. I did a lot of work to get the pci bus working > > on this board and it works correctly but the default init code > > of the alim15x3 driver doesn't work for me. The driver explicitly > > disabled some initialization code for powerpc after uncommenting this > > code it works properly. Benjamin Herrenschmidt and I think this > > !CONFIG_PPC check should be removed because the system behaves > > like a real 'x86' system (also the i8259 interrupt controller is used). > > Ben, I guess you are OK with the change and there are no longer other > platforms requiring CONFIG_PPC check below? [I don't see your ACK here] I'd like to nak this patch. It'll break MPC8610HPCD boards. See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3 I'm not sure how should we handle this for Xilinx PPC, MPC8610 PPC and Sparc all at the same time, but it's obvious that #ifdef isn't enough any longer... > > Regards, > > Roderick Colenbrander > > > > > > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001 > > From: Roderick Colenbrander > > Date: Wed, 15 Apr 2009 10:45:17 +0200 > > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for > > x86-like PowerPC boards like Xilinx ML310/410/510. > > Roderick, please add your "Signed-off-by:" line > (per Documentation/SubmittingPatches). > > Thanks. > > > --- > > drivers/ide/alim15x3.c |9 + > > 1 files changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c > > index 537da1c..9176c0f 100644 > > --- a/drivers/ide/alim15x3.c > > +++ b/drivers/ide/alim15x3.c > > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif) > > return cbl; > > } > > > > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) > > +#if !defined(CONFIG_SPARC64) > > /** > > *init_hwif_ali15x3-Initialize the ALI IDE x86 stuff > > *@hwif: interface to configure > > * > > *Obtain the IRQ tables for an ALi based IDE solution on the PC > > - *class platforms. This part of the code isn't applicable to the > > - *Sparc and PowerPC systems. > > + *class platforms. This part of the code isn't applicable to > > + *Sparc systems. It is usable on 'x86-like' PowerPC systems > > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510. > > */ > > > > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) > > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t > > *hwif) > > } > > #else > > #define init_hwif_ali15x3 NULL > > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */ > > +#endif /* !defined(CONFIG_SPARC64) */ > > > > /** > > *init_dma_ali15x3-set up DMA on ALi15x3 > > -- > > 1.5.6.3 -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] therm_adt746x: Convert to a new-style i2c driver
The legacy i2c binding model is going away soon, so convert the ppc
therm_adt746x driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
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/therm_adt746x.c | 84 ++---
1 file changed, 42 insertions(+), 42 deletions(-)
--- linux-2.6.30-rc2.orig/drivers/macintosh/therm_adt746x.c 2009-04-16
21:06:31.0 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/therm_adt746x.c 2009-04-16
21:37:05.0 +0200
@@ -71,7 +71,7 @@ MODULE_PARM_DESC(verbose,"Verbose log op
"(default 0)");
struct thermostat {
- struct i2c_client clt;
+ struct i2c_client *clt;
u8 temps[3];
u8 cached_temp[3];
u8 initial_limits[3];
@@ -86,9 +86,6 @@ static struct of_device * of_dev;
static struct thermostat* thermostat;
static struct task_struct *thread_therm = NULL;
-static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
-int busno);
-
static void write_both_fan_speed(struct thermostat *th, int speed);
static void write_fan_speed(struct thermostat *th, int speed, int fan);
@@ -100,7 +97,7 @@ write_reg(struct thermostat* th, int reg
tmp[0] = reg;
tmp[1] = data;
- rc = i2c_master_send(&th->clt, (const char *)tmp, 2);
+ rc = i2c_master_send(th->clt, (const char *)tmp, 2);
if (rc < 0)
return rc;
if (rc != 2)
@@ -115,12 +112,12 @@ read_reg(struct thermostat* th, int reg)
int rc;
reg_addr = (u8)reg;
- rc = i2c_master_send(&th->clt, ®_addr, 1);
+ rc = i2c_master_send(th->clt, ®_addr, 1);
if (rc < 0)
return rc;
if (rc != 1)
return -ENODEV;
- rc = i2c_master_recv(&th->clt, (char *)&data, 1);
+ rc = i2c_master_recv(th->clt, (char *)&data, 1);
if (rc < 0)
return rc;
return data;
@@ -130,26 +127,36 @@ static int
attach_thermostat(struct i2c_adapter *adapter)
{
unsigned long bus_no;
+ struct i2c_board_info info;
+ struct i2c_client *client;
if (strncmp(adapter->name, "uni-n", 5))
return -ENODEV;
bus_no = simple_strtoul(adapter->name + 6, NULL, 10);
if (bus_no != therm_bus)
return -ENODEV;
- return attach_one_thermostat(adapter, therm_address, bus_no);
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "therm_adt746x", I2C_NAME_SIZE);
+ info.addr = therm_address;
+ client = i2c_new_device(adapter, &info);
+ if (!client)
+ return -ENODEV;
+
+ /*
+* 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 0;
}
static int
-detach_thermostat(struct i2c_adapter *adapter)
+remove_thermostat(struct i2c_client *client)
{
- struct thermostat* th;
+ struct thermostat *th = i2c_get_clientdata(client);
int i;
- if (thermostat == NULL)
- return 0;
-
- th = thermostat;
-
if (thread_therm != NULL) {
kthread_stop(thread_therm);
}
@@ -165,8 +172,6 @@ detach_thermostat(struct i2c_adapter *ad
write_both_fan_speed(th, -1);
- i2c_detach_client(&th->clt);
-
thermostat = NULL;
kfree(th);
@@ -174,14 +179,6 @@ detach_thermostat(struct i2c_adapter *ad
return 0;
}
-static struct i2c_driver thermostat_driver = {
- .driver = {
- .name = "therm_adt746x",
- },
- .attach_adapter = attach_thermostat,
- .detach_adapter = detach_thermostat,
-};
-
static int read_fan_speed(struct thermostat *th, u8 addr)
{
u8 tmp[2];
@@ -369,8 +366,8 @@ static void set_limit(struct thermostat
th->limits[i] = default_limits_local[i] + limit_adjust;
}
-static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
-int busno)
+static int probe_thermostat(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
struct thermostat* th;
int rc;
@@ -383,16 +380,12 @@ static int attach_one_thermostat(struct
if (!th)
return -ENOMEM;
- th->clt.addr = addr;
- th->clt.adapter = adapter;
- th->clt.driver = &thermostat_driver;
- strcpy(th->clt.name, "thermostat");
+ i2c_set_clientdata(client, th);
+ th->cl
[PATCH] therm_windtunnel: Convert to a new-style i2c driver
The legacy i2c binding model is going away soon, so convert the ppc
therm_windtunnel driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
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/therm_windtunnel.c | 126 --
1 file changed, 60 insertions(+), 66 deletions(-)
--- linux-2.6.30-rc2.orig/drivers/macintosh/therm_windtunnel.c 2009-03-24
13:40:47.0 +0100
+++ linux-2.6.30-rc2/drivers/macintosh/therm_windtunnel.c 2009-04-16
22:56:39.0 +0200
@@ -48,16 +48,6 @@
#define LOG_TEMP 0 /* continously log
temperature */
-static int do_probe( struct i2c_adapter *adapter, int
addr, int kind);
-
-/* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
-static const unsigned shortnormal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
-0x4c, 0x4d, 0x4e, 0x4f,
-0x2c, 0x2d, 0x2e, 0x2f,
-I2C_CLIENT_END };
-
-I2C_CLIENT_INSMOD;
-
static struct {
volatile intrunning;
struct task_struct *poll_task;
@@ -315,53 +305,54 @@ static int control_loop(void *dummy)
static int
do_attach( struct i2c_adapter *adapter )
{
- int ret = 0;
+ /* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
+ static const unsigned short scan_ds1775[] = {
+ 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
+ I2C_CLIENT_END
+ };
+ static const unsigned short scan_adm1030[] = {
+ 0x2c, 0x2d, 0x2e, 0x2f,
+ I2C_CLIENT_END
+ };
if( strncmp(adapter->name, "uni-n", 5) )
return 0;
if( !x.running ) {
- ret = i2c_probe( adapter, &addr_data, &do_probe );
+ struct i2c_board_info info;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "therm_ds1775", I2C_NAME_SIZE);
+ i2c_new_probed_device(adapter, &info, scan_ds1775);
+
+ strlcpy(info.type, "therm_adm1030", I2C_NAME_SIZE);
+ i2c_new_probed_device(adapter, &info, scan_adm1030);
+
if( x.thermostat && x.fan ) {
x.running = 1;
x.poll_task = kthread_run(control_loop, NULL, "g4fand");
}
}
- return ret;
+ return 0;
}
static int
-do_detach( struct i2c_client *client )
+do_remove(struct i2c_client *client)
{
- int err;
-
- if( (err=i2c_detach_client(client)) )
- printk(KERN_ERR "failed to detach thermostat client\n");
- else {
- if( x.running ) {
- x.running = 0;
- kthread_stop(x.poll_task);
- x.poll_task = NULL;
- }
- if( client == x.thermostat )
- x.thermostat = NULL;
- else if( client == x.fan )
- x.fan = NULL;
- else {
- printk(KERN_ERR "g4fan: bad client\n");
- }
- kfree( client );
+ if (x.running) {
+ x.running = 0;
+ kthread_stop(x.poll_task);
+ x.poll_task = NULL;
}
- return err;
-}
+ if (client == x.thermostat)
+ x.thermostat = NULL;
+ else if (client == x.fan)
+ x.fan = NULL;
+ else
+ printk(KERN_ERR "g4fan: bad client\n");
-static struct i2c_driver g4fan_driver = {
- .driver = {
- .name = "therm_windtunnel",
- },
- .attach_adapter = do_attach,
- .detach_client = do_detach,
-};
+ return 0;
+}
static int
attach_fan( struct i2c_client *cl )
@@ -374,13 +365,8 @@ attach_fan( struct i2c_client *cl )
goto out;
printk("ADM1030 fan controller [...@%02x]\n", cl->addr );
- strlcpy( cl->name, "ADM1030 fan controller", sizeof(cl->name) );
-
- if( !i2c_attach_client(cl) )
- x.fan = cl;
+ x.fan = cl;
out:
- if( cl != x.fan )
- kfree( cl );
return 0;
}
@@ -412,39 +398,47 @@ attach_thermostat( struct i2c_client *cl
x.temp = temp;
x.overheat_temp = os_temp;
x.overheat_hyst = hyst_temp;
-
- strlcpy( cl->name, "DS1775 thermostat", sizeof(cl->name) );
-
- if( !i2c_attach_client(cl) )
- x.thermostat = cl;
+ x.thermostat = cl;
out:
- if( cl != x.thermostat )
- kfree( cl );
return 0;
}
+enum chip { ds1775, adm1030 };
+
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov wrote: > On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote: >> >> Hi, >> >> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: >> > Hi, >> > >> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a >> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge >> > for IDE, USB and Audio. I did a lot of work to get the pci bus working >> > on this board and it works correctly but the default init code >> > of the alim15x3 driver doesn't work for me. The driver explicitly >> > disabled some initialization code for powerpc after uncommenting this >> > code it works properly. Benjamin Herrenschmidt and I think this >> > !CONFIG_PPC check should be removed because the system behaves >> > like a real 'x86' system (also the i8259 interrupt controller is used). >> >> Ben, I guess you are OK with the change and there are no longer other >> platforms requiring CONFIG_PPC check below? [I don't see your ACK here] > > I'd like to nak this patch. It'll break MPC8610HPCD boards. > > See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3 > > I'm not sure how should we handle this for Xilinx PPC, MPC8610 > PPC and Sparc all at the same time, but it's obvious that #ifdef > isn't enough any longer... > > > If it is really a board specific issue (in case of powerpc it appears to be one) we could also use the default_irq override in ppc_md. What do you think? Roderick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik wrote: > 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presumably > this means that BOTH of the following conditions are true > > a) INTX is disabled > b) MSI is not available > > Today I am thinking we should either revert the libata commit > (a5bfc4714b3f01365aef89a92673f2ceb1ccf246), or poke PCI to twiddle INTX for > us at pci_enable_device() time, perhaps. We (Freescale) have discussed and debugged this issue, and I'm 99% certain that we have a board-specific fix, so there's no need to revert the patch. According to the original developer, he had to disable the INTX on the board if SATA were disabled, otherwise some other problem occurred. He noticed that the interrupt was re-enabled (presumably by the pre-patch code in ahci.c), so he thought it would be okay to disable it. I've run some tests, and so far it appears that the problem does not occur with the latest kernel (or the latest revision of the hardware). I need to run some more tests to be absolutely certain. If those tests pass, then I will post a patch that modifies hpcd_quirk_uli5288(). So please, don't revert any patches. And thanks to everyone for helping me resolve this issue. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
On Thu, Apr 16, 2009 at 11:27:34PM +0200, Roderick Colenbrander wrote: > On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov > wrote: > > On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote: > >> > >> Hi, > >> > >> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: > >> > Hi, > >> > > >> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a > >> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge > >> > for IDE, USB and Audio. I did a lot of work to get the pci bus working > >> > on this board and it works correctly but the default init code > >> > of the alim15x3 driver doesn't work for me. The driver explicitly > >> > disabled some initialization code for powerpc after uncommenting this > >> > code it works properly. Benjamin Herrenschmidt and I think this > >> > !CONFIG_PPC check should be removed because the system behaves > >> > like a real 'x86' system (also the i8259 interrupt controller is used). > >> > >> Ben, I guess you are OK with the change and there are no longer other > >> platforms requiring CONFIG_PPC check below? [I don't see your ACK here] > > > > I'd like to nak this patch. It'll break MPC8610HPCD boards. > > > > See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3 > > > > I'm not sure how should we handle this for Xilinx PPC, MPC8610 > > PPC and Sparc all at the same time, but it's obvious that #ifdef > > isn't enough any longer... > > > > > > > > If it is really a board specific issue (in case of powerpc it appears > to be one) we could also use the default_irq override in ppc_md. What > do you think? Um, I don't see "default_irq" in the ppc_md. Do you want to add one? I wonder if DECLARE_PCI_FIXUP_*() mechanism will work... see arch/powerpc/platforms/fsl_uli1575.c as an example for board-specific PCI fixups. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Don't clobber personality flags on exec
From: Andreas Schwab Date: Thu, 16 Apr 2009 18:22:01 +0200 > 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 Grumble, sparc has the same bugs... thanks for finding this. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc-linux-gcc vs ppx_8xx-gcc and ppc_6xx-gcc
Hello, All, I use ELDK 4.2 to work on platforms, one with MPC860 and the other with MPC8248. In installation, I see links: ppc_8xx-gcc -> ppc-linux-gcc ppc_6xx-gcc -> ppc-linux-gcc ppc-linux-gcc -> powerpc-linux-gcc I understand ppc_8xx-gcc needs to be used for MPC860 and ppc_6xx-gcc needs to be used for MPC8248. But both point to the same "powerpc-linux-gcc". What are the differences between powerpc-linux-gcc, ppx_8xx-gcc and ppc_6xx-gcc? What's the default target processorr of powerpc-linux-gcc? Thanks. Lixin Yao Harris Strate Networks Inc. RTP, North Carolina ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards
> "Peter" == Peter Korsgaard writes:
Anyone? I've locally reverted the commit, but most likely I'm not the
only one using the spi_mpc83xx driver without direct gpio controlled
chip select handling.
Anton> The advantages of this:
Anton> - Don't encourage legacy support;
Anton> - Less external symbols, less code to compile-in for !MPC832x_RDB
Anton> platforms.
Peter> It's nice with your cleanups, but I wonder how to handle more
Peter> complicated chip select handling than simply toggling a single gpio.
Peter> I have a board (or 2 actually, but they are similar in this regard)
Peter> with a mpc8347 using SPI to a number of addon boards. For signal
Peter> integrity reasons the SPI signals are routed to a MUX, so the chip
Peter> select logic has to set the MUX in addition to controlling the CS line
Peter> of the device.
Peter> I've been using code like this since late 2007, but this patch
Peter> ofcourse breaks it:
Peter> static void thinx_spi_activate_cs(u8 cs, u8 polarity)
Peter> {
Peter> static u8 old_cs = 255;
Peter> if (cs != old_cs) {
Peter> /* mux setup (cs 2:1)*/
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 1);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL0, cs&2);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL1, cs&4);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 0);
Peter> old_cs = cs;
Peter> }
Peter> switch (cs) {
Peter> case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, polarity);
break;
Peter> case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, polarity);
break;
Peter> case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, polarity);
break;
Peter> case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, polarity);
break;
Peter> }
Peter> }
Peter> static void thinx_spi_deactivate_cs(u8 cs, u8 polarity)
Peter> {
Peter> switch (cs) {
Peter> case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, !polarity);
break;
Peter> case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, !polarity);
break;
Peter> case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, !polarity);
break;
Peter> case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, !polarity);
break;
Peter> }
Peter> }
Peter> static __init int thinx_spi_init(void)
Peter> {
Peter> struct device_node *np;
Peter> struct of_gpio_chip *gc;
Peter> static const int gpios[] = {
Peter> GPIO_SPI_CS_BKL1,
Peter> GPIO_SPI_CS_BKL2,
Peter> GPIO_SPI_CS_OPT1,
Peter> GPIO_SPI_CS_OPT2,
Peter> GPIO_SPI_MUX_NOE,
Peter> GPIO_SPI_MUX_SEL0,
Peter> GPIO_SPI_MUX_SEL1
Peter> };
Peter> int i;
Peter> np = of_find_node_by_name(NULL, "gpio-controller");
Peter> if (!np || !np->data) {
Peter> printk(KERN_ERR
Peter>"gpio1 node not found or controller not
registerred\n");
Peter> return -ENODEV;
Peter> }
Peter> gc = np->data;
Peter> gpio1 = gc->gc.base;
Peter> for (i=0; i gpio_request(gpio1 + gpios[i], "spi");
Peter> gpio_direction_output(gpio1 + gpios[i], 1);
Peter> }
Peter> fsl_spi_init(thinx_spi_boardinfo,
ARRAY_SIZE(thinx_spi_boardinfo),
Peter> thinx_spi_activate_cs, thinx_spi_deactivate_cs);
Peter> return 0;
Peter> }
Peter> Now, I don't quite see how to handle this with the new OF bindings -
Peter> Any ideas?
--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 03/12] Next April 14 : PPC64 randconfig [arch/powerpc/platforms/ps3/setup.c]
On Thu, 2009-04-16 at 12:32 -0700, Geoff Levand wrote: > On 04/14/2009 11:28 AM, Subrata Modak wrote: > > Observed the following build error: > > --- > > arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of > > ‘smp_send_stop’ > > include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’ > > was here > > Hi Subrata, > > Thanks for the report. I submitted a fix to the powerpc ML: > > http://patchwork.ozlabs.org/patch/26084/ Thanks Geoff. Regards-- Subrata > > -Geoff > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull merge branch from git.secretlab.ca
Hi Ben/Paul, Here are some fixups and documentation updates for 2.6.30 The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb: Linus Torvalds (1): Linux 2.6.30-rc2 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 merge Anton Vorontsov (1): powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back Grant Likely (1): powerpc/5200: Add FLASH nodes to lite5200 device tree Stefan Roese (2): powerpc/of-device-tree: Factor MTD physmap bindings out of booting-without-of powerpc/device-tree: Document MTD nodes with multiple "reg" tuples Documentation/powerpc/booting-without-of.txt | 89 +++- Documentation/powerpc/dts-bindings/mtd-physmap.txt | 80 ++ arch/powerpc/boot/dts/lite5200b.dts| 39 + include/linux/fsl_devices.h|4 + 4 files changed, 135 insertions(+), 77 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Proposed prom parse fix + moving.
Hi All,
I have got email from Ilpo about prom_parse file.
I take this file from powerpc. Who did write prom_parse file and take care
about?
BTW: What about to move prom_parse file to any generic location as we discussed
in past?
Any volunteer?
Thanks,
Michal
Original Message
Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
From: Ilpo Järvinen
To: mon...@monstr.eu
CC: microblaze-ucli...@itee.uq.edu.au
While some version of the patches were on the lkml I read
some part of the code briefly through but my feedback got
stuck into postponed emails, so here's one correctness
related issue I might have found (the rest were just
cosmetic things).
I'm not sure if the latter return needs the of_node_put or not
but it seems more likely than not.
Not even compile tested.
Signed-off-by: Ilpo Järvinen
---
arch/microblaze/kernel/prom_parse.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/microblaze/kernel/prom_parse.c
b/arch/microblaze/kernel/prom_parse.c
index ae0352e..d1174bc 100644
--- a/arch/microblaze/kernel/prom_parse.c
+++ b/arch/microblaze/kernel/prom_parse.c
@@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
/* Get size of interrupt specifier */
tmp = of_get_property(p, "#interrupt-cells", NULL);
if (tmp == NULL) {
- of_node_put(p);
- return -EINVAL;
+ res = -EINVAL;
+ goto out;
}
intsize = *tmp;
pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
/* Check index */
- if ((index + 1) * intsize > intlen)
- return -EINVAL;
+ if ((index + 1) * intsize > intlen) {
+ res = -EINVAL;
+ goto out;
+ }
/* Get new specifier and map it */
res = of_irq_map_raw(p, intspec + index * intsize, intsize,
addr, out_irq);
+out:
of_node_put(p);
return res;
}
--
1.5.6.5
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Proposed prom parse fix + moving.
On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek wrote:
> Hi All,
>
> I have got email from Ilpo about prom_parse file.
> I take this file from powerpc. Who did write prom_parse file and take care
> about?
Posting to the linuxppc-dev list is sufficient to start. There are
several people who may be interested.
> BTW: What about to move prom_parse file to any generic location as we
> discussed in past?
> Any volunteer?
I'm kind of working on it. More specifically, I'm looking at
factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
haven't made a whole lot of progress yet.
> Original Message
> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
> From: Ilpo Järvinen
> To: mon...@monstr.eu
> CC: microblaze-ucli...@itee.uq.edu.au
>
> While some version of the patches were on the lkml I read
> some part of the code briefly through but my feedback got
> stuck into postponed emails, so here's one correctness
> related issue I might have found (the rest were just
> cosmetic things).
>
> I'm not sure if the latter return needs the of_node_put or not
> but it seems more likely than not.
Yes, it does. This change is applicable to
arch/powerpc/kernel/prom_parse.c too.
>
> Not even compile tested.
>
> Signed-off-by: Ilpo Järvinen
> ---
> arch/microblaze/kernel/prom_parse.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/kernel/prom_parse.c
> b/arch/microblaze/kernel/prom_parse.c
> index ae0352e..d1174bc 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
> /* Get size of interrupt specifier */
> tmp = of_get_property(p, "#interrupt-cells", NULL);
> if (tmp == NULL) {
> - of_node_put(p);
> - return -EINVAL;
> + res = -EINVAL;
> + goto out;
> }
> intsize = *tmp;
>
> pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
>
> /* Check index */
> - if ((index + 1) * intsize > intlen)
> - return -EINVAL;
> + if ((index + 1) * intsize > intlen) {
> + res = -EINVAL;
> + goto out;
> + }
>
> /* Get new specifier and map it */
> res = of_irq_map_raw(p, intspec + index * intsize, intsize,
> addr, out_irq);
> +out:
> of_node_put(p);
> return res;
> }
> --
> 1.5.6.5
>
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
