Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc

2007-08-30 Thread Pete/Piet Delaney
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Wessel wrote:
 Andrew Morton wrote:
 On Wed, 22 Aug 2007 17:44:12 -0500
 Jason Wessel [EMAIL PROTECTED] wrote:

  
 +while (!atomic_read(debugger_active));
 

 eek.  We're in the process of hunting down and eliminating exactly this
 construct.  There have been cases where the compiler cached the
 atomic_read() result in a register, turning the above into an infinite
 loop.

 Plus we should never add power-burners like that into the kernel
 anyway. That loop should have a cpu_relax() in it.  Which will also
 fix the
 compiler problem described above.

   
 Agreed, and fixed with a cpu_relax.
 
 Thirdly, please always add a newline when coding statements like that:

 while (expr())
 ;
   
 
 The other instances I found of the same problem in the kgdb core are
 fixed too.
 
 I merged all the changes into the for_mm branch in the kgdb git tree.

Where is the kgdb git tree?

- -piet

 
 Thanks,
 Jason.
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1gS/JICwm/rv3hoRAhfRAJ42F3QlzGwG4aQbs9hHVMI4kJ9SWQCfXrku
UGo97ByKsB9yhyIu5c+2Jh0=
=welB
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc

2007-08-30 Thread Pete/Piet Delaney
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pete/Piet Delaney wrote:
 Jason Wessel wrote:
 Andrew Morton wrote:
 On Wed, 22 Aug 2007 17:44:12 -0500
 Jason Wessel [EMAIL PROTECTED] wrote:

  
 +while (!atomic_read(debugger_active));
 
 eek.  We're in the process of hunting down and eliminating exactly this
 construct.  There have been cases where the compiler cached the
 atomic_read() result in a register, turning the above into an infinite
 loop.

 Plus we should never add power-burners like that into the kernel
 anyway. That loop should have a cpu_relax() in it.  Which will also
 fix the
 compiler problem described above.

   
 Agreed, and fixed with a cpu_relax.
 
 Thirdly, please always add a newline when coding statements like that:

 while (expr())
 ;
   
 The other instances I found of the same problem in the kgdb core are
 fixed too.
 
 I merged all the changes into the for_mm branch in the kgdb git tree.
 
 Where is the kgdb git tree?

Trying:

git clone
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git

- -piet

 
 -piet
 
 Thanks,
 Jason.
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
 
- -
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1gnFJICwm/rv3hoRApOoAJ9BHXLsIuxDiOCaAFRfAZGwrDXATQCeLL3O
bxtr3qz0soPRghPmtSZgOqc=
=kQd1
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Please pull powerpc.git merge branch

2007-08-30 Thread Paul Mackerras
Linus,

Please do

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

There are a couple more bug fixes for Cell plus one from Kumar, and
defconfig updates.

Paul.

 arch/powerpc/configs/celleb_defconfig   |  196 +
 arch/powerpc/configs/chrp32_defconfig   |  220 ++
 arch/powerpc/configs/ebony_defconfig|  190 +
 arch/powerpc/configs/g5_defconfig   |  208 ++---
 arch/powerpc/configs/holly_defconfig|  203 ++---
 arch/powerpc/configs/iseries_defconfig  |  210 +
 arch/powerpc/configs/linkstation_defconfig  |  219 ++
 arch/powerpc/configs/lite5200_defconfig |  191 +
 arch/powerpc/configs/maple_defconfig|  189 +
 arch/powerpc/configs/mpc7448_hpc2_defconfig |  202 +
 arch/powerpc/configs/mpc8272_ads_defconfig  |  193 ++---
 arch/powerpc/configs/mpc8313_rdb_defconfig  |  224 ++
 arch/powerpc/configs/mpc832x_mds_defconfig  |  209 ++---
 arch/powerpc/configs/mpc832x_rdb_defconfig  |  211 ++
 arch/powerpc/configs/mpc834x_itx_defconfig  |  206 ++---
 arch/powerpc/configs/mpc834x_itxgp_defconfig|  203 ++---
 arch/powerpc/configs/mpc834x_mds_defconfig  |  205 ++---
 arch/powerpc/configs/mpc836x_mds_defconfig  |  209 ++---
 arch/powerpc/configs/mpc8540_ads_defconfig  |  183 +
 arch/powerpc/configs/mpc8544_ds_defconfig   |  459 +++-
 arch/powerpc/configs/mpc8560_ads_defconfig  |  196 +
 arch/powerpc/configs/mpc8568mds_defconfig   |   43 -
 arch/powerpc/configs/mpc85xx_cds_defconfig  |  198 ++---
 arch/powerpc/configs/mpc8641_hpcn_defconfig |  880 ++-
 arch/powerpc/configs/mpc866_ads_defconfig   |  174 +
 arch/powerpc/configs/mpc885_ads_defconfig   |  174 +
 arch/powerpc/configs/pasemi_defconfig   |  225 ++
 arch/powerpc/configs/pmac32_defconfig   |  237 ++
 arch/powerpc/configs/ppc64_defconfig|  220 ++
 arch/powerpc/configs/prpmc2800_defconfig|  213 ++
 arch/powerpc/configs/pseries_defconfig  |  205 ++---
 arch/powerpc/kernel/process.c   |6 
 arch/powerpc/platforms/cell/spu_manage.c|8 
 arch/powerpc/platforms/cell/spufs/backing_ops.c |3 
 arch/powerpc/platforms/cell/spufs/run.c |6 
 arch/powerpc/platforms/ps3/setup.c  |3 
 36 files changed, 2846 insertions(+), 4275 deletions(-)

commit fc43dca9e75b87d24a16d5be7b497e83837d9d31
Author: Masakazu Mokuno [EMAIL PROTECTED]
Date:   Wed Aug 29 20:30:25 2007 +0900

[POWERPC] PS3: Fix bug where the major version part is not compared

Fix the bug that the major version part of the firmware version number
is ignored in the comparison done by ps3_compare_firmware_version
because the difference of two 64-bit quantities is returned as an int.

Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
Acked-by: Geoff Levand [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

commit 13a6976afdb10d54ac5ad344aa0c588bc0bd8b0a
Author: Paul Mackerras [EMAIL PROTECTED]
Date:   Thu Aug 30 16:51:51 2007 +1000

[POWERPC] Update defconfigs

Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

commit ada83daab31c3ec35845785482124373a62f430c
Author: Andre Detsch [EMAIL PROTECTED]
Date:   Tue Aug 21 10:06:22 2007 +0800

[POWERPC] spufs: Don't call spu_run_init from spu_reacquire_runnable

This fixes a major bug which was happening when a SPU thread advances
its execution right after being restored to a SPU.  A potentially
outdated NPC value was being (re)written to the SPU.

So, spu_run_init, in this case, was either not doing anything relevant,
or breaking the execution of the SPU thread.

This fixes a common problem of losing a mailbox write when it was done
to a saved context.

Signed-off-by: Andre Detsch [EMAIL PROTECTED]
Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

commit 62ee68e3bcb0d056aae5b36dea0388ca25572cdf
Author: Arnd Bergmann [EMAIL PROTECTED]
Date:   Tue Aug 21 10:06:22 2007 +0800

[POWERPC] spufs: Fix update of mailbox status register during backed wbox 
write

When a process writes into the inbound spu mailbox (wbox) while the
context is saved, we accidentally break the contents of the mb_stat_R
register by clearing other entries of the mailbox status register. This
can cause the user side to hang.

This change fixes the problem by only altering the appropriate bits
of the mailbox status register during a backing-store write.

Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

commit aac2e68481681a362ab6f44fc515034e2a4c7f2c
Author: Christian Krafft [EMAIL PROTECTED]
Date:   Thu Aug 30 01:33:53 2007 +0200

 

Re: [PATCH 0/4] PowerPC 440EPx: Initial Sequoia support

2007-08-30 Thread Valentine Barshak
Josh Boyer wrote:
 On Wed, 2007-08-29 at 17:35 +0400, Valentine Barshak wrote:
 The following patches add initial PowerPC 440EPx Sequoia board support.
 The code is based mainly on the Bamboo board support by Josh Boyer.
 These patches have been modified according the comments for the previous
 440EPx Sequoia patch series.
 
 I see David has beaten me to reviewing the individual patches, which of
 course is always welcome.  I just wanted add that I also think these
 look good.  Thanks!
 
 josh
 

Thanks guys :)

Valentine
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: dtc: Fix summary calculation in testsuite

2007-08-30 Thread Jon Loeliger
So, like, the other day David Gibson mumbled:
 The bookkeeping for producing the testsuite summary (total number of
 tests passed, failed and so forth) is broken.  It uses $? across
 several tests, but for checks after the first, the value of $? will no
 longer contain the original return code, but just that from the
 previous test.  This patch fixes the problem.
 
 Signed-off-by: David Gibson [EMAIL PROTECTED]

Applied.

Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: libfdt: Fix handling of trailing / in fdt_path_offset()

2007-08-30 Thread Jon Loeliger
So, like, the other day David Gibson mumbled:
 Currently, fdt_path_offset() returns FDL_ERR_BADOFFSET if given a path
 with a trailing '/'.  In particular this means that
 fdt_path_offset(/) returns FDT_ERR_BADOFFSET rather than 0 as one
 would expect.
 
 This patch fixes the function to accept and ignore trailing '/'
 characters.  As well as allowing fdt_path_offset(/) this means that
 fdt_path_offset(/foo/) will return the same as
 fdt_path_offset(/foo) which seems in keeping with the principle of
 least surprise.
 
 This also adds a testcase to ensure that fdt_path_offset(/) returns
 0 as it should.
 
 Signed-off-by: David Gibson [EMAIL PROTECTED]

Applied.

Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: libfdt: Several new functions

2007-08-30 Thread Jon Loeliger
So, like, the other day David Gibson mumbled:
 This series of patches adds several new functions to libfdt.  These
 are all read-only functions related to determining a given nodes node
 and ancestry.

All three pplied.

Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

2007-08-30 Thread Joachim Fenkes
Nathan Lynch [EMAIL PROTECTED] wrote on 29.08.2007 20:12:32:

  Previously, ibmebus derived a device's bus_id from its location code. 
The
  location code is not guaranteed to be unique, so we might get bus_id
  collisions if two devices share the same location code. The OFDT 
full_name,
  however, is unique, so we use that instead.
 
 This is a userspace-visible change, but I guess it's unavoidable.
 Will anything break?

Nope. Userspace programs should not depend on ibmebus' way of naming the 
devices; especially since some overly long loc_codes tended to be 
truncated and thus rendered useless. I have tested IBM's DLPAR tools 
against the changed kernel, and they didn't break.
 
 Also, I dislike this approach of duplicating the firmware device tree
 path in sysfs.

Why? Any specific reasons for your dislike?

 Are GX/ibmebus devices guaranteed to be children of
 the same node in the OF device tree?  If so, their unit addresses will
 be unique, and therefore suitable values for bus_id.  I believe this
 is what the powerpc vio bus code does.

While there's no such guarantee (as in officially signed document), yes, 
I expect future GX devices to also appear beneath the OFDT root node. For 
the existing devices, the unit addresses are already part of the device 
name, so I save the need to use sprintf() again. Plus, I rather like using 
the full_name since it also contains a descriptive name as opposed to 
being just nondescript numbers, helping the layman (ie user) to make sense 
out of a dev_id.

jschopp [EMAIL PROTECTED] wrote on 29.08.2007 20:33:30:

  +   len = strlen(dn-full_name + 1);
  +   bus_len = min(len, BUS_ID_SIZE - 1);
  +   memcpy(dev-ofdev.dev.bus_id, dn-full_name + 1
  +  + (len - bus_len), bus_len);
  +   for (i = 0; i  bus_len; i++)
  +  if (dev-ofdev.dev.bus_id[i] == '/')
  + dev-ofdev.dev.bus_id[i] = '_';
  
  /* Register with generic device framework. */
  if (ibmebus_register_device_common(dev, dn-name) != 0) {
 
 What happens when the full name is  31 characters?  It looks to me that 
it 
 will be truncated, which takes away the uniqueness guarantee.

There are currently two GX devices, eHCA and eHEA, which both reside 
beneath the root node - this is required by architecture for those 
devices. Unless they invent a device called 
supercalifragilisticexpialidocious, devices in the root note will have a 
full_name of less than 31 chars. Even in that case, the truncation occurs 
at the beginning, so the @xxx part that makes the nodes unique will stay 
in place.

If any more GX devices appear on the scene, I expect them to appear in the 
root node as well. The substitution of / by _ is a safeguard so 
possible weird OFDT setups don't break the kernel.
 
 There must be an individual property that is guaranteed to be unique and 

 less than 32 characters.  How about ibm,my-drc-index?  That looks like 
a 
 good candidate.

On first glance, it does, however the attribute might not be present in 
all cases. Architecture states it only needs to be present on systems with 
dynamic reconfiguration enabled.

All things considered, I still like the idea of using the full_name most. 
No offense.

Regards,
  Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 6/9] bootwrapper: Add a zImage.bin.platform target.

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 10:34:09AM +1000, David Gibson wrote:
 Hrm.. I think the --binary option at least should be removed, and
 subsumed into the platform id - all other binary formats are selected
 by the platform name at present.
 
 And I think it's probably best to do that for --fixed-entry as well,
 although it's a bit less clear there.

I'm not particularly fond of having huge platform switch blocks in the
wrapper script -- if it can be reasonably parameterized, why not do so?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Please pull powerpc.git merge branch

2007-08-30 Thread Kumar Gala

On Aug 30, 2007, at 6:49 AM, Paul Mackerras wrote:

 Linus,

 Please do

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

 There are a couple more bug fixes for Cell plus one from Kumar, and
 defconfig updates.

 Paul.

any reason you didn't pull this into your master branch as well, or  
will just wait to do that after linus pulls?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 09:56:16AM -0500, Kumar Gala wrote:
 It don't feel its a mishmash of crap its just how things are  
 defined.  Maybe the SOC node was a mistake, but I think we are past  
 the point of return on that.

The node itself wasn't a mistake -- the IMMR is relocatable, so it should
be under a bus node.  The mistake was assuming the PCI ranges went
straight to the CPU space, rather than getting translated through the
parent bus's ranges.  We got away with that mistake because of a similar
bug in the 32-bit PCI code.

In the past few months, this issue began to be addressed in a handful of
device trees.  In the device trees I prepared, I used separate bus and
control nodes.  In the 8544, 8548, and 8641 device trees, extra ranges
were hacked into the soc node.  All other PCI-bearing Freescale device
tree files are still broken.

I don't think a few months is an unrecoverable legacy.

 Having one platform's device tree be different just creates confusion  
 to our customers.

The intent isn't for 82xx to be different from everything else -- it's
simply the first one to get fixed in this way.  Incremental changes, and
what not.

Note that it would be quite easy to make the code accept either type of
device tree.

 While there isn't anything technically wrong with what your proposing
 it will cause support issues down the line which I want to avoid.

Such as?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/9] bootwrapper: Add strtoull().

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 10:52:22AM -0500, Milton Miller wrote:
 On Thu Aug 30 02:46:38 EST 2007, Scott Wood wrote:
 
 +   if (*ptr = '0'  *ptr = '9'  *ptr  '0' + base)
 +   digit = *ptr - '0';
 +   else if (*ptr = 'A'  *ptr  'A' + base - 10)
 +   digit = *ptr - 'A' + 10;
 +   else if (*ptr = 'a'  *ptr  'z' + base - 10)
 +   digit = *ptr - 'a' + 10;
 +   else
 +   break;
 
 'z' should also be 'a' like the 'A' case.

Oops.

 Should we add = 'Z' like we do '9', or do we not care about bases  
 36?  (It really breaks above base 42).

I personally don't care about bases  16; I only supported up to 36
because it was easy to do so.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Document and implement an improved flash device binding for powerpc (v4)

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 11:21:18AM +1000, David Gibson wrote:
 +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).

Are these required, or recommended?

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

Hmm...  I'm not thrilled with using the node name for this.  For one, the
node name usually functions more as a node type than a label.  It also
means that spaces can't be used in the name, which is fairly common for
existing partition maps.

This might be a good time to introduce a standard label property.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

2007-08-30 Thread Nathan Lynch
Hi Joachim-

Joachim Fenkes wrote:
 Nathan Lynch [EMAIL PROTECTED] wrote on 29.08.2007 20:12:32:
  Will anything break?
 
 Nope. Userspace programs should not depend on ibmebus' way of naming the 
 devices; especially since some overly long loc_codes tended to be 
 truncated and thus rendered useless. I have tested IBM's DLPAR tools 
 against the changed kernel, and they didn't break.

Okay.


  Also, I dislike this approach of duplicating the firmware device tree
  path in sysfs.
 
 Why? Any specific reasons for your dislike?

struct device's bus_id field is but 20 bytes in size.  Too close for
comfort?


  Are GX/ibmebus devices guaranteed to be children of
  the same node in the OF device tree?  If so, their unit addresses will
  be unique, and therefore suitable values for bus_id.  I believe this
  is what the powerpc vio bus code does.
 
 While there's no such guarantee (as in officially signed document), yes, 
 I expect future GX devices to also appear beneath the OFDT root node. For 
 the existing devices, the unit addresses are already part of the device 
 name, so I save the need to use sprintf() again. Plus, I rather like using 
 the full_name since it also contains a descriptive name as opposed to 
 being just nondescript numbers, helping the layman (ie user) to make sense 
 out of a dev_id.

Okay, but your layman isn't supposed to be relying on any
user-friendly properties of the name :) Hope he doesn't work on a
distro installer.

Anyway, if you're still confident in this approach, I relent.  :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Document and implement an improved flash device binding for powerpc (v4)

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 12:59:52PM -0500, Josh Boyer wrote:
 On Thu, 30 Aug 2007 12:29:33 -0500
 Scott Wood [EMAIL PROTECTED] wrote:
 
  On Thu, Aug 30, 2007 at 11:21:18AM +1000, David Gibson wrote:
   +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).
  
  Are these required, or recommended?
 
 For JEDEC, I believe those are required.

It can be probed, though...

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

2007-08-30 Thread Arnd Bergmann
On Wednesday 29 August 2007, Joachim Fenkes wrote:
 Previously, ibmebus derived a device's bus_id from its location code. The
 location code is not guaranteed to be unique, so we might get bus_id
 collisions if two devices share the same location code. The OFDT full_name,
 however, is unique, so we use that instead.
 
 Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]

Actually, I think it would be much better to convert the code to be more
like of_platform_device, or to even replace all of ibmebus with that.

The whole logic of dynamically adding and removing device is rather bogus,
and it prevents autoloading of device drivers. of_platform_make_bus_id
is the function that is responsible for creating unique names over there.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Document and implement an improved flash device binding for powerpc (v4)

2007-08-30 Thread Josh Boyer
On Thu, 30 Aug 2007 13:04:50 -0500
Scott Wood [EMAIL PROTECTED] wrote:

 On Thu, Aug 30, 2007 at 12:59:52PM -0500, Josh Boyer wrote:
  On Thu, 30 Aug 2007 12:29:33 -0500
  Scott Wood [EMAIL PROTECTED] wrote:
  
   On Thu, Aug 30, 2007 at 11:21:18AM +1000, David Gibson wrote:
+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).
   
   Are these required, or recommended?
  
  For JEDEC, I believe those are required.
 
 It can be probed, though...

Yes, ignore me.  And looking at the updated ebony.dts in David's patch,
it would seem they are optional.  Apparently I didn't drink enough
coffee this morning.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/9] cpm2: Fix off-by-one error in setbrg().

2007-08-30 Thread Vitaly Bordug
On Tue, 28 Aug 2007 15:19:21 -0500
Scott Wood wrote:

 The hardware adds one to the BRG value to get the divider, so it must
 be subtracted by software.

Prolly a note why it used to work, or what exactly this is resulting in the 
code. IIRC this was
just fw-ported so arch/ppc should have this as well.
 
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
 ---
  arch/powerpc/sysdev/cpm2_common.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/cpm2_common.c
 b/arch/powerpc/sysdev/cpm2_common.c index dbef50c..99ad1ed 100644
 --- a/arch/powerpc/sysdev/cpm2_common.c
 +++ b/arch/powerpc/sysdev/cpm2_common.c
 @@ -102,7 +102,7 @@ cpm_setbrg(uint brg, uint rate)
   brg -= 4;
   }
   bp += brg;
 - out_be32(bp, ((BRG_UART_CLK / rate)  1) | CPM_BRG_EN);
 + out_be32(bp, (((BRG_UART_CLK / rate) - 1)  1) |
 CPM_BRG_EN); 
   cpm2_unmap(bp);
  }


-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/9] cpm2: Add SCCs to cpm2_clk_setup(), and cpm2_smc_clk_setup().

2007-08-30 Thread Vitaly Bordug
On Tue, 28 Aug 2007 15:19:22 -0500
Scott Wood wrote:

I would have it in the same patch, that adds clocking stuff to 8xx. And
maybe in the same, segregate source rather then having it in the foo_common.c, 
to ease fix/update/rework.

Just imho, not pressing for that.
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
 ---
  arch/powerpc/sysdev/cpm2_common.c |  100
 +++--
 include/asm-powerpc/cpm2.h|5 ++- 2 files changed, 99
 insertions(+), 6 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/cpm2_common.c
 b/arch/powerpc/sysdev/cpm2_common.c index 99ad1ed..549da4b 100644
 --- a/arch/powerpc/sysdev/cpm2_common.c
 +++ b/arch/powerpc/sysdev/cpm2_common.c
 @@ -140,7 +140,8 @@ int cpm2_clk_setup(enum cpm_clk_target target,
 int clock, int mode) cpmux_t __iomem *im_cpmux;
   u32 __iomem *reg;
   u32 mask = 7;
 - u8 clk_map [24][3] = {
 +
 + u8 clk_map[][3] = {
   {CPM_CLK_FCC1, CPM_BRG5, 0},
   {CPM_CLK_FCC1, CPM_BRG6, 1},
   {CPM_CLK_FCC1, CPM_BRG7, 2},
 @@ -164,8 +165,40 @@ int cpm2_clk_setup(enum cpm_clk_target target,
 int clock, int mode) {CPM_CLK_FCC3, CPM_CLK13, 4},
   {CPM_CLK_FCC3, CPM_CLK14, 5},
   {CPM_CLK_FCC3, CPM_CLK15, 6},
 - {CPM_CLK_FCC3, CPM_CLK16, 7}
 - };
 + {CPM_CLK_FCC3, CPM_CLK16, 7},
 + {CPM_CLK_SCC1, CPM_BRG1, 0},
 + {CPM_CLK_SCC1, CPM_BRG2, 1},
 + {CPM_CLK_SCC1, CPM_BRG3, 2},
 + {CPM_CLK_SCC1, CPM_BRG4, 3},
 + {CPM_CLK_SCC1, CPM_CLK11, 4},
 + {CPM_CLK_SCC1, CPM_CLK12, 5},
 + {CPM_CLK_SCC1, CPM_CLK3, 6},
 + {CPM_CLK_SCC1, CPM_CLK4, 7},
 + {CPM_CLK_SCC2, CPM_BRG1, 0},
 + {CPM_CLK_SCC2, CPM_BRG2, 1},
 + {CPM_CLK_SCC2, CPM_BRG3, 2},
 + {CPM_CLK_SCC2, CPM_BRG4, 3},
 + {CPM_CLK_SCC2, CPM_CLK11, 4},
 + {CPM_CLK_SCC2, CPM_CLK12, 5},
 + {CPM_CLK_SCC2, CPM_CLK3, 6},
 + {CPM_CLK_SCC2, CPM_CLK4, 7},
 + {CPM_CLK_SCC3, CPM_BRG1, 0},
 + {CPM_CLK_SCC3, CPM_BRG2, 1},
 + {CPM_CLK_SCC3, CPM_BRG3, 2},
 + {CPM_CLK_SCC3, CPM_BRG4, 3},
 + {CPM_CLK_SCC3, CPM_CLK5, 4},
 + {CPM_CLK_SCC3, CPM_CLK6, 5},
 + {CPM_CLK_SCC3, CPM_CLK7, 6},
 + {CPM_CLK_SCC3, CPM_CLK8, 7},
 + {CPM_CLK_SCC4, CPM_BRG1, 0},
 + {CPM_CLK_SCC4, CPM_BRG2, 1},
 + {CPM_CLK_SCC4, CPM_BRG3, 2},
 + {CPM_CLK_SCC4, CPM_BRG4, 3},
 + {CPM_CLK_SCC4, CPM_CLK5, 4},
 + {CPM_CLK_SCC4, CPM_CLK6, 5},
 + {CPM_CLK_SCC4, CPM_CLK7, 6},
 + {CPM_CLK_SCC4, CPM_CLK8, 7},
 + };
  
   im_cpmux = cpm2_map(im_cpmux);
  
 @@ -205,23 +238,80 @@ int cpm2_clk_setup(enum cpm_clk_target target,
 int clock, int mode) if (mode == CPM_CLK_RX)
   shift += 3;
  
 - for (i=0; i24; i++) {
 + for (i = 0; i  ARRAY_SIZE(clk_map); i++) {
   if (clk_map[i][0] == target  clk_map[i][1] ==
 clock) { bits = clk_map[i][2];
   break;
   }
   }
 - if (i == sizeof(clk_map)/3)
 + if (i == ARRAY_SIZE(clk_map))
   ret = -EINVAL;
  
   bits = shift;
   mask = shift;
 +
   out_be32(reg, (in_be32(reg)  ~mask) | bits);
  
   cpm2_unmap(im_cpmux);
   return ret;
  }
  
 +int cpm2_smc_clk_setup(enum cpm_clk_target target, int clock)
 +{
 + int ret = 0;
 + int shift;
 + int i, bits = 0;
 + cpmux_t __iomem *im_cpmux;
 + u8 __iomem *reg;
 + u8 mask = 3;
 +
 + u8 clk_map[][3] = {
 + {CPM_CLK_SMC1, CPM_BRG1, 0},
 + {CPM_CLK_SMC1, CPM_BRG7, 1},
 + {CPM_CLK_SMC1, CPM_CLK7, 2},
 + {CPM_CLK_SMC1, CPM_CLK9, 3},
 + {CPM_CLK_SMC2, CPM_BRG2, 0},
 + {CPM_CLK_SMC2, CPM_BRG8, 1},
 + {CPM_CLK_SMC2, CPM_CLK4, 2},
 + {CPM_CLK_SMC2, CPM_CLK15, 3},
 + };
 +
 + im_cpmux = cpm2_map(im_cpmux);
 +
 + switch (target) {
 + case CPM_CLK_SMC1:
 + reg = im_cpmux-cmx_smr;
 + mask = 3;
 + shift = 4;
 + break;
 + case CPM_CLK_SMC2:
 + reg = im_cpmux-cmx_smr;
 + mask = 3;
 + shift = 0;
 + break;
 + default:
 + printk(KERN_ERR cpm2_smc_clock_setup: invalid clock
 target\n);
 + return -EINVAL;
 + }
 +
 + for (i = 0; i  ARRAY_SIZE(clk_map); i++) {
 + if (clk_map[i][0] == target  clk_map[i][1] ==
 clock) {
 + bits = clk_map[i][2];
 + break;
 + }
 + }
 + if (i == ARRAY_SIZE(clk_map))
 + ret = -EINVAL;
 +
 + bits = shift;
 + mask = shift;
 +
 + out_8(reg, (in_8(reg)  ~mask) | bits);
 +
 + cpm2_unmap(im_cpmux);
 + return ret;
 +}
 +
  /*
   * 

Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.

2007-08-30 Thread Vitaly Bordug
On Tue, 28 Aug 2007 15:17:16 -0500
Scott Wood wrote:

 1. Only map 512K of the IMMR, rather than 8M, to avoid conflicting
 with the default ioremap region.
 2. The wrong register was being loaded into SPRN_MD_RPN.
 
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
Acked-by: Vitaly Bordug [EMAIL PROTECTED]

 ---
  arch/powerpc/kernel/head_8xx.S |   10 +-
  1 files changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/arch/powerpc/kernel/head_8xx.S
 b/arch/powerpc/kernel/head_8xx.S index 901be47..e40e122 100644
 --- a/arch/powerpc/kernel/head_8xx.S
 +++ b/arch/powerpc/kernel/head_8xx.S
 @@ -695,7 +695,7 @@ initial_mmu:
   mtspr   SPRN_MI_AP, r8
   mtspr   SPRN_MD_AP, r8
  
 - /* Map another 8 MByte at the IMMR to get the processor
 + /* Map another 512 KByte at the IMMR to get the processor
* internal registers (among other things).
*/
  #ifdef CONFIG_PIN_TLB
 @@ -703,12 +703,12 @@ initial_mmu:
   mtspr   SPRN_MD_CTR, r10
  #endif
   mfspr   r9, 638 /* Get current
 IMMR */
 - andis.  r9, r9, 0xff80  /* Get 8Mbyte
 boundary */
 + andis.  r9, r9, 0xfff8  /* Get 512K
 boundary */ 
   mr  r8, r9  /* Create vaddr for
 TLB */ orir8, r8, MD_EVALID   /* Mark it valid */
   mtspr   SPRN_MD_EPN, r8
 - li  r8, MD_PS8MEG   /* Set 8M byte page */
 + li  r8, MD_PS512K   /* Set 512K byte page
 */ orir8, r8, MD_SVALID   /* Make it valid */
   mtspr   SPRN_MD_TWC, r8
   mr  r8, r9  /* Create paddr for
 TLB */ @@ -730,13 +730,13 @@ initial_mmu:
   mtspr   SPRN_MD_TWC, r9
   li  r11, MI_BOOTINIT/* Create RPN for address
 0 */ addisr11, r11, 0x0080/* Add 8M */
 - mtspr   SPRN_MD_RPN, r8
 + mtspr   SPRN_MD_RPN, r11
  
   addis   r8, r8, 0x0080  /* Add 8M */
   mtspr   SPRN_MD_EPN, r8
   mtspr   SPRN_MD_TWC, r9
   addis   r11, r11, 0x0080/* Add 8M */
 - mtspr   SPRN_MD_RPN, r8
 + mtspr   SPRN_MD_RPN, r11
  #endif
  
   /* Since the cache is enabled according to the information we


-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/9] 8xx: Add pin and clock setting functions.

2007-08-30 Thread Vitaly Bordug
On Tue, 28 Aug 2007 15:17:19 -0500
Scott Wood wrote:

 These let board code set up pins and clocks without having to
 put magic numbers directly into the registers.
 
I personally is not fond of such idea, but it would make this more 
understandable eases transfer to feature_call
or qe pin setting stuff (though the latter should be reworked at some point too 
imho).

 Signed-off-by: Scott Wood [EMAIL PROTECTED]
 ---
  arch/powerpc/sysdev/commproc.c |  201
 
 include/asm-powerpc/commproc.h |   41  2 files changed, 242
 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/commproc.c
 b/arch/powerpc/sysdev/commproc.c index af26659..a21a292 100644
 --- a/arch/powerpc/sysdev/commproc.c
 +++ b/arch/powerpc/sysdev/commproc.c
 @@ -405,3 +405,204 @@ uint cpm_dpram_phys(u8 *addr)
   return (dpram_pbase + (uint)(addr - (u8 __force
 *)dpram_vbase)); }
  EXPORT_SYMBOL(cpm_dpram_addr);
 +
 +struct cpm_ioport16 {
 + __be16 dir, par, sor, dat, intr;
 + __be16 res[3];
 +};
 +
Hmm. If we are using such a non-standard types, it worths at least explanation 
why...


 +struct cpm_ioport32 {
 + __be32 dir, par, sor;
 +};
 +
 +static void cpm1_set_pin32(int port, int pin, int flags)
 +{
 + struct cpm_ioport32 __iomem *iop;
 + pin = 1  (31 - pin);
 +
 + if (port == 1)
Probably put here define or alike so that we wouldn't have confusion what 
1/whatever port number does mean.
Or some comment explaining for PQ newcomer what's going on here. ditto below.

 + iop = (struct cpm_ioport32 __iomem *)
 +   mpc8xx_immr-im_cpm.cp_pbdir;
 + else
 + iop = (struct cpm_ioport32 __iomem *)
 +   mpc8xx_immr-im_cpm.cp_pedir;
 +
 + if (flags  CPM_PIN_OUTPUT)
 + setbits32(iop-dir, pin);
 + else
 + clrbits32(iop-dir, pin);
 +
 + if (!(flags  CPM_PIN_GPIO))
 + setbits32(iop-par, pin);
 + else
 + clrbits32(iop-par, pin);
 +
 + if (port == 4) {
 + if (flags  CPM_PIN_SECONDARY)
 + setbits32(iop-sor, pin);
 + else
 + clrbits32(iop-sor, pin);
 +
 + if (flags  CPM_PIN_OPENDRAIN)
 + setbits32(mpc8xx_immr-im_cpm.cp_peodr,
 pin);
 + else
 + clrbits32(mpc8xx_immr-im_cpm.cp_peodr,
 pin);
 + }
 +}
 +
 +static void cpm1_set_pin16(int port, int pin, int flags)
 +{
 + struct cpm_ioport16 __iomem *iop =
 + (struct cpm_ioport16 __iomem
 *)mpc8xx_immr-im_ioport; +
 + pin = 1  (15 - pin);
 +
 + if (port != 0)
 + iop += port - 1;
 +
 + if (flags  CPM_PIN_OUTPUT)
 + setbits16(iop-dir, pin);
 + else
 + clrbits16(iop-dir, pin);
 +
 + if (!(flags  CPM_PIN_GPIO))
 + setbits16(iop-par, pin);
 + else
 + clrbits16(iop-par, pin);
 +
 + if (port == 2) {
 + if (flags  CPM_PIN_SECONDARY)
 + setbits16(iop-sor, pin);
 + else
 + clrbits16(iop-sor, pin);
 + }
 +}
 +
 +void cpm1_set_pin(int port, int pin, int flags)
 +{
 + if (port == 1 || port == 4)
 + cpm1_set_pin32(port, pin, flags);
 + else
 + cpm1_set_pin16(port, pin, flags);
 +}
 +
 +int cpm1_clk_setup(enum cpm_clk_target target, int clock, int mode)
 +{
 + int shift;
 + int i, bits = 0;
 + u32 __iomem *reg;
 + u32 mask = 7;
 +
gotta at least briefly explain the clue here, too. We're adding helper 
functions and should be ready that something somewhere
won't work as expected.

 + u8 clk_map[][3] = {
 + {CPM_CLK_SCC1, CPM_BRG1, 0},
 + {CPM_CLK_SCC1, CPM_BRG2, 1},
 + {CPM_CLK_SCC1, CPM_BRG3, 2},
 + {CPM_CLK_SCC1, CPM_BRG4, 3},
 + {CPM_CLK_SCC1, CPM_CLK1, 4},
 + {CPM_CLK_SCC1, CPM_CLK2, 5},
 + {CPM_CLK_SCC1, CPM_CLK3, 6},
 + {CPM_CLK_SCC1, CPM_CLK4, 7},
 +
 + {CPM_CLK_SCC2, CPM_BRG1, 0},
 + {CPM_CLK_SCC2, CPM_BRG2, 1},
 + {CPM_CLK_SCC2, CPM_BRG3, 2},
 + {CPM_CLK_SCC2, CPM_BRG4, 3},
 + {CPM_CLK_SCC2, CPM_CLK1, 4},
 + {CPM_CLK_SCC2, CPM_CLK2, 5},
 + {CPM_CLK_SCC2, CPM_CLK3, 6},
 + {CPM_CLK_SCC2, CPM_CLK4, 7},
 +
 + {CPM_CLK_SCC3, CPM_BRG1, 0},
 + {CPM_CLK_SCC3, CPM_BRG2, 1},
 + {CPM_CLK_SCC3, CPM_BRG3, 2},
 + {CPM_CLK_SCC3, CPM_BRG4, 3},
 + {CPM_CLK_SCC3, CPM_CLK5, 4},
 + {CPM_CLK_SCC3, CPM_CLK6, 5},
 + {CPM_CLK_SCC3, CPM_CLK7, 6},
 + {CPM_CLK_SCC3, CPM_CLK8, 7},
 +
 + {CPM_CLK_SCC4, CPM_BRG1, 0},
 + {CPM_CLK_SCC4, CPM_BRG2, 1},
 + {CPM_CLK_SCC4, CPM_BRG3, 2},
 + {CPM_CLK_SCC4, CPM_BRG4, 3},
 + {CPM_CLK_SCC4, CPM_CLK5, 4},
 +

Re: [PATCH 7/9] 8xx: mpc885ads cleanup

2007-08-30 Thread Vitaly Bordug
On Tue, 28 Aug 2007 15:19:09 -0500
Scott Wood wrote:

 It now uses the new CPM binding and the generic pin/clock functions,
 and has assorted fixes and cleanup.
 
good work, thanks.
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
Acked-by: Vitaly Bordug [EMAIL PROTECTED]

 ---
  arch/powerpc/boot/dts/mpc885ads.dts  |  192 ++-
  arch/powerpc/configs/mpc885_ads_defconfig|  445
 +++---
 arch/powerpc/platforms/8xx/Kconfig   |1 +
 arch/powerpc/platforms/8xx/mpc885ads.h   |   38 ---
 arch/powerpc/platforms/8xx/mpc885ads_setup.c |  455
 +- 5 files changed, 455 insertions(+), 676
 deletions(-)
 
 diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
 b/arch/powerpc/boot/dts/mpc885ads.dts index dc7ab9c..76c0a06 100644
 --- a/arch/powerpc/boot/dts/mpc885ads.dts
 +++ b/arch/powerpc/boot/dts/mpc885ads.dts
 @@ -2,6 +2,7 @@
   * MPC885 ADS Device Tree Source
   *
   * Copyright 2006 MontaVista Software, Inc.
 + * Copyright 2007 Freescale Semiconductor, Inc.
   *
   * This program is free software; you can redistribute  it and/or
 modify it
   * under  the terms of  the GNU General  Public License as published
 by the @@ -12,7 +13,7 @@
  
  / {
   model = MPC885ADS;
 - compatible = mpc8xx;
 + compatible = fsl,mpc885ads;
   #address-cells = 1;
   #size-cells = 1;
  
 @@ -23,161 +24,180 @@
   PowerPC,[EMAIL PROTECTED] {
   device_type = cpu;
   reg = 0;
 - d-cache-line-size = 20;   // 32 bytes
 - i-cache-line-size = 20;   // 32 bytes
 - d-cache-size = 2000;  // L1,
 8K
 - i-cache-size = 2000;  // L1,
 8K
 + d-cache-line-size = d#16;
 + i-cache-line-size = d#16;
 + d-cache-size = d#8192;
 + i-cache-size = d#8192;
   timebase-frequency = 0;
   bus-frequency = 0;
   clock-frequency = 0;
 - 32-bit;
   interrupts = f 2; // decrementer
 interrupt
 - interrupt-parent = Mpc8xx_pic;
 + interrupt-parent = PIC;
   };
   };
  
   memory {
   device_type = memory;
 - reg =  80;
 + reg = 0 0;
   };
  
 - [EMAIL PROTECTED] {
 + chipselect {
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + [EMAIL PROTECTED] {
 + device_type = rom;
 + compatible = direct-mapped;
 + reg = fe00 80;
 + probe-type = JEDEC;
 + bank-width = 4;
 + };
 +
 + [EMAIL PROTECTED] {
 + reg = ff08 20 ff0a0300 4;
 + compatible = fsl,mpc885ads-bcsr;
 + };
 + };
 +
 + [EMAIL PROTECTED] {
 + compatible = fsl,mpc885, fsl,pq1-soc;
   #address-cells = 1;
   #size-cells = 1;
 - #interrupt-cells = 2;
   device_type = soc;
 - ranges = 0 ff00 0010;
 - reg = ff00 0200;
 + ranges = 0 ff00 4000;
   bus-frequency = 0;
 - [EMAIL PROTECTED] {
 - device_type = mdio;
 - compatible = fs_enet;
 - reg = e80 8;
 +
 + [EMAIL PROTECTED] {
 + compatible = fsl,mpc885-fec-mdio,
 fsl,pq1-fec-mdio;
 + reg = e00 188;
   #address-cells = 1;
   #size-cells = 0;
 - Phy0: [EMAIL PROTECTED] {
 +
 + PHY0: [EMAIL PROTECTED] {
   reg = 0;
   device_type = ethernet-phy;
   };
 - Phy1: [EMAIL PROTECTED] {
 +
 + PHY1: [EMAIL PROTECTED] {
   reg = 1;
   device_type = ethernet-phy;
   };
 - Phy2: [EMAIL PROTECTED] {
 +
 + PHY2: [EMAIL PROTECTED] {
   reg = 2;
   device_type = ethernet-phy;
   };
   };
  
 - [EMAIL PROTECTED] {
 + [EMAIL PROTECTED] {
   device_type = network;
 - compatible = fs_enet;
 - model = FEC;
 - device-id = 1;
 + compatible = fsl,mpc885-fec-enet,
 +  fsl,pq1-fec-enet;
   reg = e00 188;
 - mac-address = [ 00 00 0C 00 01 FD ];
 + 

Re: [PATCH 3/9] cpm2: Add SCCs to cpm2_clk_setup(), and cpm2_smc_clk_setup().

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 02:25:48AM +0400, Vitaly Bordug wrote:
 I would have it in the same patch, that adds clocking stuff to 8xx.

I was trying to keep the 8xx and 82xx patchsets reasonably separate.

 And maybe in the same, segregate source rather then having it in the
 foo_common.c, to ease fix/update/rework.

I'm not sure I understand what you mean -- where do you want the code to
go?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 3/3] mpc8349emitx(gp): update defconfigs for 2.6.23

2007-08-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
CC: Scott Wood [EMAIL PROTECTED]
CC: Kumar Gala [EMAIL PROTECTED]
CC: Timur Tabi [EMAIL PROTECTED]
---

 arch/powerpc/configs/mpc834x_itx_defconfig   |  292 +
 arch/powerpc/configs/mpc834x_itxgp_defconfig |  364 --
 2 files changed, 353 insertions(+), 303 deletions(-)

diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig 
b/arch/powerpc/configs/mpc834x_itx_defconfig
index 85470b8..20bfc1f 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -1,9 +1,25 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.22-rc7
-# Sun Jul  1 23:56:56 2007
+# Linux kernel version: 2.6.23-rc4
+# Thu Aug 30 08:47:23 2007
 #
 # CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+CONFIG_6xx=y
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_83xx=y
+CONFIG_PPC_FPU=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_32=y
+# CONFIG_PPC_MM_SLICES is not set
+# CONFIG_SMP is not set
 CONFIG_PPC32=y
 CONFIG_PPC_MERGE=y
 CONFIG_MMU=y
@@ -14,61 +30,38 @@ CONFIG_ARCH_HAS_ILOG2_U32=y
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
 CONFIG_PPC=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_GENERIC_NVRAM=y
 CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
 CONFIG_ARCH_MAY_HAVE_PC_FDC=y
 CONFIG_PPC_OF=y
+CONFIG_OF=y
 CONFIG_PPC_UDBG_16550=y
 # CONFIG_GENERIC_TBSYNC is not set
 CONFIG_AUDIT_ARCH=y
 CONFIG_GENERIC_BUG=y
 CONFIG_DEFAULT_UIMAGE=y
-
-#
-# Processor support
-#
-# CONFIG_CLASSIC32 is not set
-# CONFIG_PPC_82xx is not set
-CONFIG_PPC_83xx=y
-# CONFIG_PPC_85xx is not set
-# CONFIG_PPC_86xx is not set
-# CONFIG_PPC_8xx is not set
-# CONFIG_40x is not set
-# CONFIG_44x is not set
-# CONFIG_E200 is not set
-CONFIG_6xx=y
-CONFIG_83xx=y
-CONFIG_PPC_FPU=y
 # CONFIG_PPC_DCR_NATIVE is not set
 # CONFIG_PPC_DCR_MMIO is not set
-CONFIG_PPC_STD_MMU=y
-CONFIG_PPC_STD_MMU_32=y
-# CONFIG_PPC_MM_SLICES is not set
-# CONFIG_SMP is not set
 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
 
 #
-# Code maturity level options
+# General setup
 #
 CONFIG_EXPERIMENTAL=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
-
-#
-# General setup
-#
 CONFIG_LOCALVERSION=
 CONFIG_LOCALVERSION_AUTO=y
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
-# CONFIG_IPC_NS is not set
 CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_POSIX_MQUEUE is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
-# CONFIG_UTS_NS is not set
+# CONFIG_USER_NS is not set
 # CONFIG_AUDIT is not set
 # CONFIG_IKCONFIG is not set
 CONFIG_LOG_BUF_SHIFT=14
@@ -94,30 +87,24 @@ CONFIG_TIMERFD=y
 CONFIG_EVENTFD=y
 CONFIG_SHMEM=y
 CONFIG_VM_EVENT_COUNTERS=y
-CONFIG_SLAB=y
-# CONFIG_SLUB is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
 # CONFIG_SLOB is not set
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-
-#
-# Loadable module support
-#
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_MODULE_FORCE_UNLOAD is not set
 # CONFIG_MODVERSIONS is not set
 # CONFIG_MODULE_SRCVERSION_ALL is not set
 # CONFIG_KMOD is not set
-
-#
-# Block layer
-#
 CONFIG_BLOCK=y
 # CONFIG_LBD is not set
 # CONFIG_BLK_DEV_IO_TRACE is not set
 # CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
 
 #
 # IO Schedulers
@@ -135,6 +122,11 @@ CONFIG_DEFAULT_IOSCHED=anticipatory
 #
 # Platform support
 #
+# CONFIG_PPC_MULTIPLATFORM is not set
+# CONFIG_EMBEDDED6xx is not set
+# CONFIG_PPC_82xx is not set
+CONFIG_PPC_83xx=y
+# CONFIG_PPC_86xx is not set
 # CONFIG_PPC_MPC52xx is not set
 # CONFIG_PPC_MPC5200 is not set
 # CONFIG_PPC_CELL is not set
@@ -158,6 +150,7 @@ CONFIG_MPC834x=y
 # CONFIG_GENERIC_IOMAP is not set
 # CONFIG_CPU_FREQ is not set
 # CONFIG_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
 
 #
 # Kernel options
@@ -186,12 +179,14 @@ CONFIG_FLAT_NODE_MEM_MAP=y
 CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_RESOURCES_64BIT is not set
 CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
 CONFIG_PROC_DEVICETREE=y
 # CONFIG_CMDLINE_BOOL is not set
 # CONFIG_PM is not set
 CONFIG_SECCOMP=y
 CONFIG_WANT_DEVICE_TREE=y
-CONFIG_DEVICE_TREE=
+CONFIG_DEVICE_TREE=mpc8349emitx.dts
 CONFIG_ISA_DMA_API=y
 
 #
@@ -200,13 +195,14 @@ CONFIG_ISA_DMA_API=y
 CONFIG_ZONE_DMA=y
 CONFIG_GENERIC_ISA_DMA=y
 CONFIG_PPC_INDIRECT_PCI=y
-# CONFIG_PPC_INDIRECT_PCI_BE is not set
 CONFIG_FSL_SOC=y
 CONFIG_PCI=y
 CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
 # CONFIG_PCIEPORTBUS is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
 # CONFIG_PCI_MSI is not set
+# CONFIG_PCI_DEBUG is not set
 
 #
 # PCCARD (PCMCIA/CardBus) support
@@ -313,6 +309,7 @@ CONFIG_DEFAULT_TCP_CONG=cubic
 # CONFIG_MAC80211 is not set
 # CONFIG_IEEE80211 is not set
 # CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
 
 #
 # Device Drivers
@@ 

[PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree

2007-08-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
CC: Scott Wood [EMAIL PROTECTED]
CC: Kumar Gala [EMAIL PROTECTED]
CC: David Gibson [EMAIL PROTECTED]
---

 arch/powerpc/boot/devtree.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
index e1b8122..8451a1c 100644
--- a/arch/powerpc/boot/devtree.c
+++ b/arch/powerpc/boot/devtree.c
@@ -99,14 +99,14 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
while ((addr = va_arg(ap, const u8 *))) {
devp = find_node_by_prop_value(NULL, linux,network-index,
   (void*)index, sizeof(index));
-
-   printf(ENET%d: local-mac-address -
-   %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
-  addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
-
-   if (devp)
+   if (devp) {
+   printf(ENET%d: local-mac-address -
+   %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
+  addr[0], addr[1], addr[2], addr[3], addr[4], 
addr[5]);
setprop(devp, local-mac-address, addr, 6);
-
+   } else {
+   printf(ENET%d: no device in tree\n\r, index);
+   }
index++;
}
va_end(ap);

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 2/3] mpc8349: Add linux, network-index to ethernet nodes in device tree

2007-08-30 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED]

cuImage need to know the logical index of the ethernet devices in order
to assign mac addresses.  This patch adds the needed properties

Signed-off-by: Grant Likely [EMAIL PROTECTED]
CC: Scott Wood [EMAIL PROTECTED]
CC: Kumar Gala [EMAIL PROTECTED]
CC: Timur Tabi [EMAIL PROTECTED]
---

 arch/powerpc/boot/dts/mpc8349emitx.dts   |2 ++
 arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 +
 arch/powerpc/boot/dts/mpc834x_mds.dts|2 ++
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts 
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 502f47c..a4e2284 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -141,6 +141,7 @@
interrupts = 20 8 21 8 22 8;
interrupt-parent =  ipic ;
phy-handle =  phy1c ;
+   linux,network-index = 0;
};
 
[EMAIL PROTECTED] {
@@ -160,6 +161,7 @@
interrupts = 23 8 24 8 25 8;
interrupt-parent =  ipic ;
phy-handle =  phy1f ;
+   linux,network-index = 1;
};
 
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts 
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index 0b83871..004b737 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -116,6 +116,7 @@
interrupts = 20 8 21 8 22 8;
interrupt-parent =  ipic ;
phy-handle =  phy1c ;
+   linux,network-index = 0;
};
 
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts 
b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 4810997..251c233 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -146,6 +146,7 @@
interrupts = 20 8 21 8 22 8;
interrupt-parent =  ipic ;
phy-handle =  phy0 ;
+   linux,network-index = 0;
};
 
[EMAIL PROTECTED] {
@@ -165,6 +166,7 @@
interrupts = 23 8 24 8 25 8;
interrupt-parent =  ipic ;
phy-handle =  phy1 ;
+   linux,network-index = 1;
};
 
[EMAIL PROTECTED] {

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] mpc5200: add cuimage support for mpc5200 boards

2007-08-30 Thread Scott Wood
On Thu, Aug 30, 2007 at 02:57:40PM -0600, Grant Likely wrote:
 diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
 new file mode 100644
 index 000..46eecf0
 --- /dev/null
 +++ b/arch/powerpc/boot/mpc52xx-psc.c
 @@ -0,0 +1,89 @@
 +/*
 + * CPM serial console support.
 + *
 + * Copyright 2007 Freescale Semiconductor, Inc.
 + * Author: Scott Wood [EMAIL PROTECTED]
 + *
 + * It is assumed that the firmware (or the platform file) has already set
 + * up the port.

Might want to update that comment block... :-)

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub

2007-08-30 Thread Timur Tabi
Anton Vorontsov wrote:

 +static int __init mpc832x_spi_init(void)
 +{
 + if (!machine_is(mpc832x_rdb))
 + return 0;
 +
 + par_io_config_pin(3,  0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
 + par_io_config_pin(3,  1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
 + par_io_config_pin(3,  2, 3, 0, 1, 0); /* SPI1 CLK,  I/O */
 + par_io_config_pin(3,  3, 2, 0, 1, 0); /* SPI1 SEL,  I   */
 +
 + par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */
 + par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
 + par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */

Why are you doing this here, and not in the device tree?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] mpc5200: add cuimage support for mpc5200 boards

2007-08-30 Thread Grant Likely
On 8/30/07, Scott Wood [EMAIL PROTECTED] wrote:
 On Thu, Aug 30, 2007 at 02:57:40PM -0600, Grant Likely wrote:
  diff --git a/arch/powerpc/boot/mpc52xx-psc.c 
  b/arch/powerpc/boot/mpc52xx-psc.c
  new file mode 100644
  index 000..46eecf0
  --- /dev/null
  +++ b/arch/powerpc/boot/mpc52xx-psc.c
  @@ -0,0 +1,89 @@
  +/*
  + * CPM serial console support.
  + *
  + * Copyright 2007 Freescale Semiconductor, Inc.
  + * Author: Scott Wood [EMAIL PROTECTED]
  + *
  + * It is assumed that the firmware (or the platform file) has already set
  + * up the port.

 Might want to update that comment block... :-)

HAHAHAHAHAHAHA!  Yeah, I'll fix that.  :-)

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions

2007-08-30 Thread Linas Vepstas
On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote:
 
 Plus, I rather like using 
 the full_name since it also contains a descriptive name as opposed to 
 being just nondescript numbers, helping the layman (ie user) to make sense 
 out of a dev_id.

Yes, well, but no. The location code is useful as a geographical
location: slots and devices are physically labelled with stickers 
so you can tell which is which.  Handy when you have to unplug stuff. 
By contrast, the device-tree full_name is mostly just gobldy-gook, 
with some crazy phb numbering in there that, after four years of 
staring at them, I still can't reliably do anything useful with.  
Location codes are nice. 

--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/9] cpm2: Fix off-by-one error in setbrg().

2007-08-30 Thread Vitaly Bordug
On Thu, 30 Aug 2007 15:13:12 -0500
Scott Wood wrote:

 On Thu, Aug 30, 2007 at 02:09:07AM +0400, Vitaly Bordug wrote:
  On Tue, 28 Aug 2007 15:19:21 -0500
  Scott Wood wrote:
  
   The hardware adds one to the BRG value to get the divider, so it
   must be subtracted by software.
  
  Prolly a note why it used to work, or what exactly this is
  resulting in the code. IIRC this was just fw-ported so arch/ppc
  should have this as well.
 
 It *didn't* work before -- hence the fix.
 
It used to work at least at the time I did initial port, but I am not going to 
argue.

 The failure mode from being off by just one isn't total
 nonfunctionality, but rather a corrupted character now and then,
 which could explain why it wasn't fixed before.
Can this be added to description please? Someone may be grepping for such a 
weirdness in some custom code forked off
some kernel.org revision, and will be happy to know it is addressed.

 
 As for arch/ppc, I'm just trying to not break it more than it already
 is.
I mean, when powerpc/ was nearly empty, same issue in ppc/ went unnoticed for 
years...

-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] mpc5200: add cuimage support for mpc5200 boards

2007-08-30 Thread Matt Sealey

+/*
+ * Old U-boot compatibility for 8200
+ *

And this one?

-- 
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations

Grant Likely wrote:
 On 8/30/07, Scott Wood [EMAIL PROTECTED] wrote:
 On Thu, Aug 30, 2007 at 02:57:40PM -0600, Grant Likely wrote:
 diff --git a/arch/powerpc/boot/mpc52xx-psc.c 
 b/arch/powerpc/boot/mpc52xx-psc.c
 new file mode 100644
 index 000..46eecf0
 --- /dev/null
 +++ b/arch/powerpc/boot/mpc52xx-psc.c
 @@ -0,0 +1,89 @@
 +/*
 + * CPM serial console support.
 + *
 + * Copyright 2007 Freescale Semiconductor, Inc.
 + * Author: Scott Wood [EMAIL PROTECTED]
 + *
 + * It is assumed that the firmware (or the platform file) has already set
 + * up the port.
 Might want to update that comment block... :-)
 
 HAHAHAHAHAHAHA!  Yeah, I'll fix that.  :-)
 
 g.
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree

2007-08-30 Thread David Gibson
On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
 From: Grant Likely [EMAIL PROTECTED]
 
 Signed-off-by: Grant Likely [EMAIL PROTECTED]
 CC: Scott Wood [EMAIL PROTECTED]
 CC: Kumar Gala [EMAIL PROTECTED]
 CC: David Gibson [EMAIL PROTECTED]

Hrm... I thought Scott had deliberately removed that message in his
patch set, to work with the way PlanetCore generates Ethernet
addresses.

 ---
 
  arch/powerpc/boot/devtree.c |   14 +++---
  1 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
 index e1b8122..8451a1c 100644
 --- a/arch/powerpc/boot/devtree.c
 +++ b/arch/powerpc/boot/devtree.c
 @@ -99,14 +99,14 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
   while ((addr = va_arg(ap, const u8 *))) {
   devp = find_node_by_prop_value(NULL, linux,network-index,
  (void*)index, sizeof(index));
 -
 - printf(ENET%d: local-mac-address -
 - %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
 -addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
 -
 - if (devp)
 + if (devp) {
 + printf(ENET%d: local-mac-address -
 + %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
 +addr[0], addr[1], addr[2], addr[3], addr[4], 
 addr[5]);
   setprop(devp, local-mac-address, addr, 6);
 -
 + } else {
 + printf(ENET%d: no device in tree\n\r, index);
 + }
   index++;
   }
   va_end(ap);
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/3] Introduce new CPM device bindings.

2007-08-30 Thread David Gibson
On Thu, Aug 30, 2007 at 09:10:46AM -0500, Scott Wood wrote:
 On Thu, Aug 30, 2007 at 03:58:12PM +1000, David Gibson wrote:
  On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
   On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
Am I correct in thinking that it's basically an arch/ppc versus
arch/powerpc thing.  In which case couldn't you use CONFIG_PPC_MERGE
instead?
   
   The idea was to allow boards to be converted incrementally, as I don't
   have access to test 100% of the boards that use the CPM code.
  
  Hrm.  Right.  This is still problematical, because what happens if you
  have both old-binding and new-binding boards configured simultaneously?
 
 Multiplatform will not be supported for old-binding boards.

Hmm, ok.  Well, let's try to kill the old binding off as fast as we
can, at least the portions that still infect arch/powerpc.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH -mm] pcmcia: Updates to electra_cf driver

2007-08-30 Thread Olof Johansson
Fix build of electra_cf, since the IO space setup interfaces were
changed when BenH rewrote it.

Also clean it up a bit, add 5V support, make it unloadable, remove some
dead variables, etc.


Signed-off-by: Olof Johansson [EMAIL PROTECTED]

---

Andrew,

I did this as an incremental patch that you can just merge into the base
one that's already in -mm, but I could merge and resubmit the base patch
instead if you prefer.

(The base patch is
pcmcia-compactflash-driver-for-pa-semi-electra-boards.patch)


-Olof

Index: linux-2.6/drivers/pcmcia/electra_cf.c
===
--- linux-2.6.orig/drivers/pcmcia/electra_cf.c
+++ linux-2.6/drivers/pcmcia/electra_cf.c
@@ -28,6 +28,7 @@
 #include linux/init.h
 #include linux/delay.h
 #include linux/interrupt.h
+#include linux/vmalloc.h
 
 #include pcmcia/ss.h
 #include asm/of_platform.h
@@ -105,10 +106,8 @@ static int electra_cf_get_status(struct 
 
/* NOTE CF is always 3VCARD */
if (electra_cf_present(cf)) {
-   struct electra_cf_socket *cf;
-
*sp = SS_READY | SS_DETECT | SS_POWERON | SS_3VCARD;
-   cf = container_of(s, struct electra_cf_socket, socket);
+
s-pci_irq = cf-irq;
} else
*sp = 0;
@@ -134,8 +133,10 @@ static int electra_cf_set_socket(struct 
case 33:
gpio = (1  cf-gpio_3v);
break;
+   case 5:
+   gpio = (1  cf-gpio_5v);
+   break;
default:
-   /* CF is 3.3V only */
return -EINVAL;
}
 
@@ -188,6 +189,7 @@ static int __devinit electra_cf_probe(st
int status;
const unsigned int *prop;
int err;
+   struct vm_struct *area;
 
err = of_address_to_resource(np, 0, mem);
if (err)
@@ -206,22 +208,27 @@ static int __devinit electra_cf_probe(st
 
cf-ofdev = ofdev;
cf-mem_phys = mem.start;
-   cf-mem_base = ioremap(mem.start, mem.end - mem.start);
+   cf-mem_size = PAGE_ALIGN(mem.end - mem.start);
+   cf-mem_base = ioremap(cf-mem_phys, cf-mem_size);
cf-io_size = PAGE_ALIGN(io.end - io.start);
 
-   cf-io_virt = reserve_phb_iospace(cf-io_size);
+   area = __get_vm_area(cf-io_size, 0, PHB_IO_BASE, PHB_IO_END);
+   if (area == NULL)
+   return -ENOMEM;
+
+   cf-io_virt = (void __iomem *)(area-addr);
 
cf-gpio_base = ioremap(0xfc103000, 0x1000);
dev_set_drvdata(device, cf);
 
-   if (!cf-mem_base || !cf-io_virt || !cf-gpio_base) {
+   if (!cf-mem_base || !cf-io_virt || !cf-gpio_base ||
+   (__ioremap_at(io.start, cf-io_virt, cf-io_size,
+   _PAGE_NO_CACHE | _PAGE_GUARDED) == NULL)) {
dev_err(device, can't ioremap ranges\n);
status = -ENOMEM;
goto fail1;
}
 
-   __ioremap_explicit(io.start, (unsigned long)cf-io_virt, cf-io_size,
-  _PAGE_NO_CACHE | _PAGE_GUARDED);
 
cf-io_base = (unsigned long)cf-io_virt - VMALLOC_END;
 
@@ -263,8 +270,7 @@ static int __devinit electra_cf_probe(st
cf-socket.io_offset = cf-io_base;
 
/* reserve chip-select regions */
-   if (!request_mem_region(mem.start, mem.end + 1 - mem.start,
-   driver_name)) {
+   if (!request_mem_region(cf-mem_phys, cf-mem_size, driver_name)) {
status = -ENXIO;
dev_err(device, Can't claim memory region\n);
goto fail1;
@@ -291,21 +297,22 @@ static int __devinit electra_cf_probe(st
}
 
dev_info(device, at mem 0x%lx io 0x%lx irq %d\n,
-mem.start, io.start, cf-irq);
+cf-mem_phys, io.start, cf-irq);
 
cf-active = 1;
electra_cf_timer((unsigned long)cf);
return 0;
 
 fail3:
-   release_mem_region(io.start, io.end + 1 - io.start);
+   release_region(cf-io_base, cf-io_size);
 fail2:
-   release_mem_region(mem.start, mem.end + 1 - mem.start);
+   release_mem_region(cf-mem_phys, cf-mem_size);
 fail1:
if (cf-irq != NO_IRQ)
free_irq(cf-irq, cf);
 
-   /* XXX No way to undo the ioremap_explicit at this time */
+   if (cf-io_virt)
+   __iounmap_at(cf-io_virt, cf-io_size);
if (cf-mem_base)
iounmap(cf-mem_base);
if (cf-gpio_base)
@@ -328,6 +335,7 @@ static int __devexit electra_cf_remove(s
free_irq(cf-irq, cf);
del_timer_sync(cf-timer);
 
+   __iounmap_at(cf-io_virt, cf-io_size);
iounmap(cf-mem_base);
iounmap(cf-gpio_base);
release_mem_region(cf-mem_phys, cf-mem_size);
Index: linux-2.6/drivers/pcmcia/Kconfig
===
--- linux-2.6.orig/drivers/pcmcia/Kconfig
+++ linux-2.6/drivers/pcmcia/Kconfig
@@ -272,8 +272,8 @@ config AT91_CF
  Or choose M to compile the driver as a 

[PATCH] Remove unused variables in driver/ide/ppc/pmac.c

2007-08-30 Thread Tony Breeds
Fixes:
  CC [M]  drivers/ide/ppc/pmac.o
/scratch/tony/tmp/drivers/ide/ppc/pmac.c: In function 'pmac_ide_dma_check':
/scratch/tony/tmp/drivers/ide/ppc/pmac.c:1815: warning: unused variable 'map'
/scratch/tony/tmp/drivers/ide/ppc/pmac.c:1813: warning: unused variable 'pmif'

Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
 drivers/ide/ppc/pmac.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index 33630ad..0f5a6b4 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1810,9 +1810,7 @@ pmac_ide_dma_check(ide_drive_t *drive)
 {
struct hd_driveid *id = drive-id;
ide_hwif_t *hwif = HWIF(drive);
-   pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)hwif-hwif_data;
int enable = 1;
-   int map;
drive-using_dma = 0;

if (drive-media == ide_floppy)
-- 
1.5.2.5

Yours Tony

  linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
  Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree

2007-08-30 Thread Grant Likely
On 8/30/07, David Gibson [EMAIL PROTECTED] wrote:
 On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
  From: Grant Likely [EMAIL PROTECTED]
 
  Signed-off-by: Grant Likely [EMAIL PROTECTED]
  CC: Scott Wood [EMAIL PROTECTED]
  CC: Kumar Gala [EMAIL PROTECTED]
  CC: David Gibson [EMAIL PROTECTED]

 Hrm... I thought Scott had deliberately removed that message in his
 patch set, to work with the way PlanetCore generates Ethernet
 addresses.

I'm confused then.  The code either sets the property or it doesn't.
From what I can see, the message doesn't make any sense in the context
of *not* calling setprop().  How does PlanetCore work?  Scott?

g.


  ---
 
   arch/powerpc/boot/devtree.c |   14 +++---
   1 files changed, 7 insertions(+), 7 deletions(-)
 
  diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
  index e1b8122..8451a1c 100644
  --- a/arch/powerpc/boot/devtree.c
  +++ b/arch/powerpc/boot/devtree.c
  @@ -99,14 +99,14 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
while ((addr = va_arg(ap, const u8 *))) {
devp = find_node_by_prop_value(NULL, linux,network-index,
   (void*)index, sizeof(index));
  -
  - printf(ENET%d: local-mac-address -
  - %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
  -addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
  -
  - if (devp)
  + if (devp) {
  + printf(ENET%d: local-mac-address -
  + %02x:%02x:%02x:%02x:%02x:%02x\n\r, index,
  +addr[0], addr[1], addr[2], addr[3], addr[4], 
  addr[5]);
setprop(devp, local-mac-address, addr, 6);
  -
  + } else {
  + printf(ENET%d: no device in tree\n\r, index);
  + }
index++;
}
va_end(ap);
 
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@ozlabs.org
  https://ozlabs.org/mailman/listinfo/linuxppc-dev
 

 --
 David Gibson| I'll have my music baroque, and my code
 david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
 | _way_ _around_!
 http://www.ozlabs.org/~dgibson



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree

2007-08-30 Thread David Gibson
On Thu, Aug 30, 2007 at 10:14:41PM -0600, Grant Likely wrote:
 On 8/30/07, David Gibson [EMAIL PROTECTED] wrote:
  On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
   From: Grant Likely [EMAIL PROTECTED]
  
   Signed-off-by: Grant Likely [EMAIL PROTECTED]
   CC: Scott Wood [EMAIL PROTECTED]
   CC: Kumar Gala [EMAIL PROTECTED]
   CC: David Gibson [EMAIL PROTECTED]
 
  Hrm... I thought Scott had deliberately removed that message in his
  patch set, to work with the way PlanetCore generates Ethernet
  addresses.
 
 I'm confused then.  The code either sets the property or it doesn't.
 From what I can see, the message doesn't make any sense in the context
 of *not* calling setprop().  How does PlanetCore work?  Scott?

Sorry, I was misleading.  Scott moved the printf() into the if (devp)
as you do, but *didn't* add the alternative warning message in the
else.

The reason for this is that Planetcore only supplies the first MAC
address, and the bootwrapper must derive the addresses for all the
ENETs from that.  That in turn means it is much more convenient to
call fixup_mac_addresses() with more addresses than there are
ethernets, so we don't want a warning message when that happens.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


libfdt: Fix use of uninitialized variable in fdt_get_path()

2007-08-30 Thread David Gibson
My recent implemenetation of fdt_get_path() had a bug - the while loop
tested offset which was unitialized on the first iteration.  Depending
on code surrounding the call, this could cause fdt_get_path() to
return incorrect results.

This patch corrects the problem by applying some more correct thinking
to the loop condition.

Signed-off-by: David Gibson [EMAIL PROTECTED]

Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2007-08-31 14:26:26.0 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-31 14:26:31.0 +1000
@@ -302,7 +302,7 @@
buf[0] = '/';
p = 1;
 
-   while (offset  nodeoffset) {
+   while (nextoffset = nodeoffset) {
offset = nextoffset;
tag = _fdt_next_tag(fdt, offset, nextoffset);
switch (tag) {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev