LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 4/4] Convert pfc8563 i2c driver from old style to new style
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
  To: i2c, linuxppc-dev
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>

Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
---

 drivers/rtc/rtc-pcf8563.c |  114 +++++++++++++--------------------------------
 1 files changed, 32 insertions(+), 82 deletions(-)


diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..20b1acf 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
  * located at 0x51 will pass the validation routine due to
  * the way the registers are implemented.
  */
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
 
 #define PCF8563_REG_ST1		0x00 /* status */
 #define PCF8563_REG_ST2		0x01
@@ -72,9 +68,6 @@ struct pcf8563 {
 	int c_polarity;	/* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
 };
 
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
 /*
  * In the routines that deal directly with the pcf8563 hardware, we use
  * rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,55 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
 	.set_time	= pcf8563_rtc_set_time,
 };
 
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
 {
-	return i2c_probe(adapter, &addr_data, pcf8563_probe);
+	struct rtc_device *rtc = i2c_get_clientdata(client);
+
+	if (rtc)
+		rtc_device_unregister(rtc);
+	
+	return 0;
 }
 
+static struct i2c_device_id pcf8563_id[] = {
+	{"rtc-pcf8563", 0},
+	{"pcf8563", 0},
+	{"philips,pcf8563", 0},
+	{"rtc8564", 0},
+	{"epson,rtc8564", 0},
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id);
+
 static struct i2c_driver pcf8563_driver = {
 	.driver		= {
-		.name	= "pcf8563",
+		.name	= "rtc-pcf8563",
 	},
 	.id		= I2C_DRIVERID_PCF8563,
-	.attach_adapter = &pcf8563_attach,
-	.detach_client	= &pcf8563_detach,
+	.probe = &pcf8563_probe,
+	.remove = &pcf8563_remove,
+	.id_table	= pcf8563_id,
 };
 
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id)
 {
-	struct pcf8563 *pcf8563;
-	struct i2c_client *client;
+	int result;
 	struct rtc_device *rtc;
-
-	int err = 0;
-
-	dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
-	if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
-		err = -ENODEV;
-		goto exit;
-	}
-
-	if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
-		err = -ENOMEM;
-		goto exit;
-	}
-
-	client = &pcf8563->client;
-	client->addr = address;
-	client->driver = &pcf8563_driver;
-	client->adapter	= adapter;
-
-	strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
-	/* Verify the chip is really an PCF8563 */
-	if (kind < 0) {
-		if (pcf8563_validate_client(client) < 0) {
-			err = -ENODEV;
-			goto exit_kfree;
-		}
-	}
-
-	/* Inform the i2c layer */
-	if ((err = i2c_attach_client(client)))
-		goto exit_kfree;
-
-	dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
-
+	
+	result = pcf8563_validate_client(client);
+	if (result)
+		return result;
+	
 	rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
 				&pcf8563_rtc_ops, THIS_MODULE);
-
-	if (IS_ERR(rtc)) {
-		err = PTR_ERR(rtc);
-		goto exit_detach;
-	}
+	if (IS_ERR(rtc))
+		return PTR_ERR(rtc);
 
 	i2c_set_clientdata(client, rtc);
 
 	return 0;
-
-exit_detach:
-	i2c_detach_client(client);
-
-exit_kfree:
-	kfree(pcf8563);
-
-exit:
-	return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
-	struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
-	int err;
-	struct rtc_device *rtc = i2c_get_clientdata(client);
-
-	if (rtc)
-		rtc_device_unregister(rtc);
-
-	if ((err = i2c_detach_client(client)))
-		return err;
-
-	kfree(pcf8563);
-
-	return 0;
 }
 
 static int __init pcf8563_init(void)

^ permalink raw reply related

* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: Benjamin Herrenschmidt @ 2007-12-03 22:36 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1196715974.13978.176.camel@pmac.infradead.org>


On Mon, 2007-12-03 at 21:06 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2007-12-03 at 17:04 +0000, David Woodhouse wrote:
> > > It would be good to migrate the platform code to register RTC devices
> > > directly, but for now this will make them functional enough for most
> > > purposes...
> > 
> > Wouldn't it be best to do the other way around at some stage ?
> 
> Yes, definitely. We can migrate them one at a time to the RTC class.
> 
> > We need to solve the problem of ppc_md. stuff being called by the core
> > in atomic contexts first though.
> 
> Where from?

Worst one is time_init :-) Way too early to do any i2c babbling. Then
there used to be something with the NTP writeback, dunno if it's
changed.

Ben.

^ permalink raw reply

* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: David Woodhouse @ 2007-12-03 22:44 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196721397.13230.236.camel@pasglop>

On Tue, 2007-12-04 at 09:36 +1100, Benjamin Herrenschmidt wrote:
> Worst one is time_init :-) Way too early to do any i2c babbling. Then
> there used to be something with the NTP writeback, dunno if it's
> changed.

Setting the system time seems to be done in the new RTC class by a
late_initcall() in drivers/rtc/hctosys.c. In fact, it could even be done
in userspace.

NTP uses update_persistent_clock() and doesn't seem to have been
'solved' yet for the new RTC class. I don't think there's any particular
reason for it to do i2c stuff in that context though.

-- 
dwmw2

^ permalink raw reply

* Re: SMP on linux with Microblaze?
From: John Williams @ 2007-12-03 21:18 UTC (permalink / raw)
  To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <14137760.post@talk.nabble.com>

Hi,

khollan wrote:

>Now that Full Linux can run on Microblaze with the addition of the MMU, are
>there plans to enable Symmetric Multi-Processing of two or more Microblaze
>cores running Linux?
>  
>
This isn't really the right list for direct microblaze discussion, but
since you asked..  The challenge with SMP is not an MMU, but cache
coherency.  This is why native SMP on dual PPC on V4/V5 is also a
non-starter.  It is possible to build software driven snoop/invalidate
mechanisms that might allow a crippled SMP on MicroBlaze, but I think
the performance would be pretty nasty. 

The Blackfin Linux team have done some interesting things towards SMP on
non cache-coherent dual CPUs.  Basically they do a local cache
invalidation upon acquiring any kernel lock, on the theory that if you
are accessing a shared data structure you will grab a lock first.  Thus,
the cache flush will make sure you get the "true" value, not some stale
locally cached result.  But, it's still pretty inefficient, and cannot
do things like processor affinity and process migration.  Google the
bfin lists for details and patches.

Regards,

John

^ permalink raw reply

* Re: [PATCH 09/28] blk_end_request: changing ps3disk (take 3)
From: Kiyoshi Ueda @ 2007-12-03 22:55 UTC (permalink / raw)
  To: Geert.Uytterhoeven
  Cc: k-ueda, linux-scsi, linuxppc-dev, jens.axboe, linux-kernel,
	linux-ide, dm-devel, bharrosh, j-nomura
In-Reply-To: <Pine.LNX.4.64.0712021032490.29349@anakin>

Hi Geert,

On Sun, 2 Dec 2007 10:34:56 +0100 (CET), Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Fri, 30 Nov 2007, Kiyoshi Ueda wrote:
> > This patch converts ps3disk to use blk_end_request().
>                                      ^^^^^^^^^^^^^^^
> Patch subject and description are inconsistent with actual change.
> 
> > Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
> > Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
> > ---
> >  drivers/block/ps3disk.c |    6 +-----
> >  1 files changed, 1 insertion(+), 5 deletions(-)
> > 
> > Index: 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > ===================================================================
> > --- 2.6.24-rc3-mm2.orig/drivers/block/ps3disk.c
> > +++ 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > @@ -280,11 +280,7 @@ static irqreturn_t ps3disk_interrupt(int
> >  	}
> >  
> >  	spin_lock(&priv->lock);
> > -	if (!end_that_request_first(req, uptodate, num_sectors)) {
> > -		add_disk_randomness(req->rq_disk);
> > -		blkdev_dequeue_request(req);
> > -		end_that_request_last(req, uptodate);
> > -	}
> > +	__blk_end_request(req, uptodate, num_sectors << 9);
>       ^^^^^^^^^^^^^^^^^

Thank you for the comment.
The description meant the blk_end_request family, not actual function,
blk_end_request().  But as you pointed out, it is misleading.
I'll change the description of all related patches.

Thanks,
Kiyoshi Ueda

^ permalink raw reply

* Re: Problem compiling sequoia using DENX kernel. Xenomai-patch required?
From: Wolfgang Denk @ 2007-12-03 23:08 UTC (permalink / raw)
  To: niklaus.giger; +Cc: linuxppc-embedded
In-Reply-To: <200712022141.36467.niklaus.giger@member.fsf.org>

In message <200712022141.36467.niklaus.giger@member.fsf.org> you wrote:
> 
> I tried with (tags DENX-v2.6.23.9, DENX-v.2.6.23, master) to build a kernel 
> for the sequoia board.
> I am using ELDK 4.1. I did a 
> git checkout -b copy-master master
> make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g sequoia_defconfig 
> make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g zImage 

The ARCH=powerpc is the "interesting" part here.

> First I stumbled about problem compiling arch/powerpc/platforms/44x/ppc4xx*.c
> file with errors like
> arch/powerpc/platforms/44x/ppc4xx-pci.c: In function 'ppc4xx_setup_pci':
> arch/powerpc/platforms/44x/ppc4xx-pci.c:62: sorry, unimplemented: inlining 
> failed in call to 'pci_cfg_out': function body not available
> arch/powerpc/platforms/44x/ppc4xx-pci.c:98: sorry, unimplemented: called from 
> here

There are many moving targets in the ARCH=powerpc hemisphere for 4xx
systems...

> I thought that denx compiled images for the sequoia using 2.6.23. 

Yes, we do. But stable support is only available  with  the  arch/ppc
tree yet.

> Do they only work after having applied the Xenomai patch? Because if I apply 

No.

> the Xenomai patch, the kernel compiles cleanly. In this case  I think it 

That's just lucky coincidence...

> would be nice to get somewhere a hint (or did I missed it somewhere) that 
> this is a requirement. I lost quite a few hours as I wanted to first compile 
> a "normal" kernel and afterwars apply the xenomai patch.

I'm afraid "normal" here still means arch/ppc  -  hopefully  for  not
long any more. Note: a matching Xenomai patch for arch/ppc will be in
Xenomai 2.4 when it comes out in a few days.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Good manners are the settled  medium  of  social,  as  specie  is  of
commercial, life; returns are equally expected for both.
           - Lord Chesterfield _Letters to his Son_, 25 December 1753

^ permalink raw reply

* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-03 23:37 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>

On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl wrote:
> The following series implements standard linux module aliasing for i2c modules
> It then converts the mpc i2c driver from being a platform driver to an open
> firmware one. I2C device names are picked up from the device tree. Module
> aliasing is used to translate from device tree names into to linux kernel
> names. Several i2c drivers are updated to use the new aliasing. 

May I ask why you want to modify the i2c layer instead of keeping the
OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
PPC-specific code, since otherwise you might end up with confused i2c
driver writers that make up their own OF names without knowing for sure
that's what will be used. No?

I recently posted (and asked Paulus to pull) a patch where I consolidate
the fsl_soc mapping code so I can also use that on pasemi, and modified
the pasemi platform code to setup the board_info from the device tree
accordingly.

Finally, whitespace is broken in several of your patches.


-Olof

^ permalink raw reply

* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-03 23:52 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203233752.GA7041@lixom.net>

On 12/3/07, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl wrote:
> > The following series implements standard linux module aliasing for i2c modules
> > It then converts the mpc i2c driver from being a platform driver to an open
> > firmware one. I2C device names are picked up from the device tree. Module
> > aliasing is used to translate from device tree names into to linux kernel
> > names. Several i2c drivers are updated to use the new aliasing.
>
> May I ask why you want to modify the i2c layer instead of keeping the
> OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
> PPC-specific code, since otherwise you might end up with confused i2c
> driver writers that make up their own OF names without knowing for sure
> that's what will be used. No?

Audio codecs have the same problem. That table is could end up with
hundreds of entries. The right place to store the mappings is in the
device driver for the device.

A side effect of moving the mappings into the device drivers is that
the correct i2c drivers can be automatically loaded by the kernel.
This lets you make distro CDs with all of the i2c drivers on disk and
the device tree will cause insmod of the correct ones.

I'm working on a parallel patch for Alsa SOC but it isn't ready yet.

>
> I recently posted (and asked Paulus to pull) a patch where I consolidate
> the fsl_soc mapping code so I can also use that on pasemi, and modified
> the pasemi platform code to setup the board_info from the device tree
> accordingly.
>
> Finally, whitespace is broken in several of your patches.
>
>
> -Olof
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Scott Wood @ 2007-12-03 23:51 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203233752.GA7041@lixom.net>

Olof Johansson wrote:
> On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl wrote:
>> The following series implements standard linux module aliasing for i2c modules
>> It then converts the mpc i2c driver from being a platform driver to an open
>> firmware one. I2C device names are picked up from the device tree. Module
>> aliasing is used to translate from device tree names into to linux kernel
>> names. Several i2c drivers are updated to use the new aliasing. 
> 
> May I ask why you want to modify the i2c layer instead of keeping the
> OF->i2c driver mapping in PPC code?

Because it doesn't belong there -- at the least, it should be in 
drivers/of.  But putting it in the driver is better, IMHO.

> It seems simpler to keep it in the
> PPC-specific code, since otherwise you might end up with confused i2c
> driver writers that make up their own OF names without knowing for sure
> that's what will be used. No?

How is this different from drivers that have of_platform bindings?

That said, there should probably be some sort of tag to indicate the 
namespace being matched against (OF, Linux, etc), to avoid matching an 
OF device with a non-OF name (or vice versa).

> I recently posted (and asked Paulus to pull) a patch where I consolidate
> the fsl_soc mapping code so I can also use that on pasemi, and modified
> the pasemi platform code to setup the board_info from the device tree
> accordingly.

Having just one bit i2c glue code for arch/powerpc is certainly an 
improvement over the current situation, but it's not really powerpc 
specific.  Just because other architectures don't use it now doesn't 
mean they won't in the future -- and I don't like the "we'll move it 
when they do" argument because I want to make it easy for other 
architectures to decide to use it. :-)

-Scott

^ permalink raw reply

* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-04  0:04 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, paulus, i2c
In-Reply-To: <9e4733910712031552j36efd4b2u933f0f4e9832a003@mail.gmail.com>

On Mon, Dec 03, 2007 at 06:52:06PM -0500, Jon Smirl wrote:
> On 12/3/07, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl wrote:
> > > The following series implements standard linux module aliasing for i2c modules
> > > It then converts the mpc i2c driver from being a platform driver to an open
> > > firmware one. I2C device names are picked up from the device tree. Module
> > > aliasing is used to translate from device tree names into to linux kernel
> > > names. Several i2c drivers are updated to use the new aliasing.
> >
> > May I ask why you want to modify the i2c layer instead of keeping the
> > OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
> > PPC-specific code, since otherwise you might end up with confused i2c
> > driver writers that make up their own OF names without knowing for sure
> > that's what will be used. No?
> 
> Audio codecs have the same problem. That table is could end up with
> hundreds of entries. The right place to store the mappings is in the
> device driver for the device.
> 
> A side effect of moving the mappings into the device drivers is that
> the correct i2c drivers can be automatically loaded by the kernel.
> This lets you make distro CDs with all of the i2c drivers on disk and
> the device tree will cause insmod of the correct ones.

Ok, good enough reasons. I'll back out my i2c commits and wait for yours
to settle, then add the pasemi stuff in the same way.

(Whitespace comments still apply).


-Olof

^ permalink raw reply

* Re: Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2007-12-04  0:07 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071203050446.GC24492@lixom.net>

On Sun, Dec 02, 2007 at 11:04:47PM -0600, Olof Johansson wrote:
> Paul,
> 
> Please do:
> 
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
> 
> For the following patches queued up for 2.6.25. All but one are PA
> Semi-specific (the i2c boardinfo consolidation that's a pre-req for the
> platform-specific one).

Sorry for the churn here, I hope you haven't pulled yet.

Based on today's i2c patches from Jon Smirl, it makes more sense for me
to hold off on my i2c changes and make them on top of his work once that
has been merged.

I've backed out and rebased the patch set, new shortlog and diffstat:

 arch/powerpc/platforms/pasemi/Kconfig     |    2 
 arch/powerpc/platforms/pasemi/cpufreq.c   |   19 +++++-
 arch/powerpc/platforms/pasemi/gpio_mdio.c |   94 ++++++++++++++++++------------
 arch/powerpc/platforms/pasemi/pasemi.h    |    6 +
 arch/powerpc/platforms/pasemi/powersave.S |   11 +++
 arch/powerpc/platforms/pasemi/setup.c     |   16 ++++-
 drivers/char/hw_random/Kconfig            |    2 
 drivers/char/hw_random/pasemi-rng.c       |    7 --
 drivers/edac/pasemi_edac.c                |    4 -
 9 files changed, 111 insertions(+), 50 deletions(-)

Olof Johansson (5):
      [POWERPC] pasemi: clean up mdio_gpio a bit
      [POWERPC] pasemi: Broaden specific references to 1682M
      [POWERPC] pasemi: Don't enter powersaving states from elevated astates
      [POWERPC] pasemi: Move cpus to hold loop before restart
      [POWERPC] pasemi: Fix module information for gpio-mdio


-Olof

^ permalink raw reply

* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-04  0:33 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196709993.7735.3.camel@ld0161-tx32>

On Mon, Dec 03, 2007 at 01:26:34PM -0600, Jon Loeliger wrote:
> On Sun, 2007-12-02 at 19:50, David Gibson wrote:
> 
> > > +		clock-frequency = <7f28155>;		/* 133.333333 MHz */
> > You can use <d# 133333333> to avoid the ugly hex.
> 
> Better still, blaze a new trail, convert it to /dts-v1/ and
> use clock-frequency = <133333333> straight up!

Hrm.. probably best to wait for dtc to go into the kernel for that.

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

^ permalink raw reply

* dtc: Fix uninitialized use of structure_ok
From: David Gibson @ 2007-12-04  0:49 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev

My rework of the tree checking code introduced a potentially nasty bug
- it uses the structure_ok variable uninitialized.  This patch fixes
the problem.  It's a fairly ugly bandaid approach, but the ugly will
disappear once future patches have folded the semantic checks into the
new framework.

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

Index: dtc/checks.c
===================================================================
--- dtc.orig/checks.c	2007-12-03 17:14:27.000000000 +1100
+++ dtc/checks.c	2007-12-03 17:14:39.000000000 +1100
@@ -270,8 +270,12 @@ static struct check *check_table[] = {
 	&phandle_references,
 };
 
-void process_checks(int force, struct node *dt)
+int check_semantics(struct node *dt, int outversion, int boot_cpuid_phys);
+
+void process_checks(int force, struct boot_info *bi,
+		    int checkflag, int outversion, int boot_cpuid_phys)
 {
+	struct node *dt = bi->dt;
 	int i;
 	int error = 0;
 
@@ -292,6 +296,16 @@ void process_checks(int force, struct no
 				"output forced\n");
 		}
 	}
+
+	if (checkflag) {
+		if (error) {
+			fprintf(stderr, "Warning: Skipping semantic checks due to structural errors\n");
+		} else {
+			if (!check_semantics(bi->dt, outversion,
+					     boot_cpuid_phys))
+				fprintf(stderr, "Warning: Input tree has semantic errors\n");
+		}
+	}
 }
 
 /*
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c	2007-12-03 17:14:27.000000000 +1100
+++ dtc/dtc.c	2007-12-03 17:14:39.000000000 +1100
@@ -119,7 +119,6 @@ int main(int argc, char *argv[])
 	FILE *outf = NULL;
 	int outversion = DEFAULT_FDT_VERSION;
 	int boot_cpuid_phys = 0xfeedbeef;
-	int structure_ok;
 
 	quiet      = 0;
 	reservenum = 0;
@@ -193,17 +192,7 @@ int main(int argc, char *argv[])
 	if (! bi || ! bi->dt)
 		die("Couldn't read input tree\n");
 
-	process_checks(force, bi->dt);
-
-	if (check) {
-		if (!structure_ok) {
-			fprintf(stderr, "Warning: Skipping semantic checks due to structural errors\n");
-		} else {
-			if (!check_semantics(bi->dt, outversion,
-					     boot_cpuid_phys))
-				fprintf(stderr, "Warning: Input tree has semantic errors\n");
-		}
-	}
+	process_checks(force, bi, check, outversion, boot_cpuid_phys);
 
 	if (streq(outname, "-")) {
 		outf = stdout;
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h	2007-12-03 17:15:04.000000000 +1100
+++ dtc/dtc.h	2007-12-03 17:15:14.000000000 +1100
@@ -236,8 +236,8 @@ struct boot_info *build_boot_info(struct
 
 /* Checks */
 
-void process_checks(int force, struct node *dt);
-int check_semantics(struct node *dt, int outversion, int boot_cpuid_phys);
+void process_checks(int force, struct boot_info *bi,
+		    int checkflag, int outversion, int boot_cpuid_phys);
 
 /* Flattened trees */
 

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

^ permalink raw reply

* RE: current ARCH=powerpc for v2pro.
From: Stephen Neuendorffer @ 2007-12-04  0:48 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711302239u56a264ddyaaad454bc00bb4dd@mail.gmail.com>

I tried that, which essentially differed from what I was trying in that
interrupts were turned off.
It fails in the same way as before.

I've booted ARCH=3Dppc from your tree on the exact same hardware design,
and as near as I can tell, the code that runs in the kernel proper up to
the point where I see the machine check is almost identical.

The machine check (a trap into the Machine Check handler at 0x200)
occurs at a nondeterministic point during the execution of memset_io in
early_init.

In the kernel I have, _bss_start is c02c8000, and these are the
registers in the trap handler on two different runs of the kernel:

    r3: c02c80cc r5: 00022874
    r3: c02c8248 r5: 000226f4

r3 is the current point being initialized, and r5 is the count remaining
in the .bss.

So, what would cause a machine check in the middle of a loop, in the
middle of the almost the simplest code absolutely possible, and not on
an obvious memory boundary?

Steve

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Friday, November 30, 2007 10:40 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: current ARCH=3Dpowerpc for v2pro.
>=20
> On 11/30/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Grant,
> >
> > I'm trying to bring up your arch/powerpc work, using a compiled in
> > device tree.  I added this:
> >
> <snip>
> >
> > Which seems bizarre, because that code is very simple.  I'm guessing
> > that something in the memory configuration is wierd (or maybe
> > zImage.virtex is not the right way to do this?) but I'm a=20
> little lost
> > where to look from here.  I also tried it with both=20
> paulus_master and
> > your virtex-for-2.6.24 branch.
>=20
>=20
> I've got a patch that adds 'raw' image support (originally written by
> Scott Wood) which somewhat works for booting (but not entirely; I
> haven't had time to dig into it properly yet).  It's not suitable to
> go into mainline yet.  I'll try to get the patch out to my tree this
> evening... actually I've been trying to get my tree pushed out all
> today, but other things keep coming up.  :-)
>=20
> <several hours after I wrote the above>
>=20
> Okay, I pushed my current patch set out to the master branch of my
> linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> should be usable for booting.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>=20
>=20

^ permalink raw reply

* Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: David Gibson @ 2007-12-04  0:28 UTC (permalink / raw)
  To: Chris Snook; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <47547A79.2060206@redhat.com>

On Mon, Dec 03, 2007 at 04:51:53PM -0500, Chris Snook wrote:
> David Gibson wrote:
> > On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
> >> This patch adds reliability to the 64K huge page option by making use of 
> >> the PMD for 64K huge pages when base pages are 4k.  So instead of a 12 
> >> bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets 
> >> would continue as 9 bits and 7 bits respectively.  This will allow the 
> >> pgtable to fit in one base page.  This patch would have to be applied 
> >> after part 1.
> > 
> > Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size
> > setup?  There's not a whole lot of point to it, after all...
> > 
> 
> Actually, it sounds to me like an ideal way to benchmark the
> efficiency of the hugepage implementation and VM effects, without
> the TLB performance obscuring the results.

Well.. maybe.  The pagetable format, and therefore the hugepage size,
will affect the size of that overhead so even with this its not clear
how meaningful test results would be.

> I agree that it's not something people will want to do very often,
> but the same can be said about quite a lot of strange things that we
> allow just because there's no fundamental reason why they cannot be.

Hrm, yeah I guess, since this was a fairly simple fix.  I still don't
think it's worth jumping through too many hoops to make this possible,
though.

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

^ permalink raw reply

* Re: [PATCH] [POWERPC] Improved documentation of device tree 'ranges'.
From: David Gibson @ 2007-12-04  0:52 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20071203174403.C740719B0073@mail119-sin.bigfish.com>

On Mon, Dec 03, 2007 at 09:45:03AM -0800, Stephen Neuendorffer wrote:
> I was misled by the prior language.  I've attempted to clarify how
> 'ranges' are used, in particular, how to get a 1:1 mapping.

Sounds good, except for one detail.  I think we should avoid using
the "1:1" terminology: to a mathematician, at least, "1:1" is much
weaker than "identity mapping" which is what an empty ranges actually
implies.

So, I think we should explicitly say that an empty ranges implies that
parent bus address space is identical to child bus address space.

> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> ---
>  Documentation/powerpc/booting-without-of.txt |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..aad8bf5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
>  like address space bits, you'll have to add a bus translator to the
>  prom_parse.c file of the recent kernels for your bus type.
>  
> -The "reg" property only defines addresses and sizes (if #size-cells
> -is non-0) within a given bus. In order to translate addresses upward
> +The "reg" property only defines addresses and sizes (if #size-cells is
> +non-0) within a given bus. In order to translate addresses upward
>  (that is into parent bus addresses, and possibly into CPU physical
>  addresses), all busses must contain a "ranges" property. If the
>  "ranges" property is missing at a given level, it's assumed that
> -translation isn't possible. The format of the "ranges" property for a
> -bus is a list of:
> +translation isn't possible, i.e., the registers are not visible on the
> +parent bus.  The format of the "ranges" property for a bus is a list
> +of:
>  
>  	bus address, parent bus address, size
>  
> @@ -735,6 +736,8 @@ fit in a single 32-bit word.   New 32-bit powerpc boards should use a
>  1/1 format, unless the processor supports physical addresses greater
>  than 32-bits, in which case a 2/1 format is recommended.
>  
> +Alternatively, the "ranges" property may be empty, indicating that the
> +registers are visible on the parent bus, with 1:1 address translation.
>  
>  2) Note about "compatible" properties
>  -------------------------------------

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

^ permalink raw reply

* [PATCH] [POWERPC] [v2] Improved documentation of device tree 'ranges'.
From: Stephen Neuendorffer @ 2007-12-04  1:08 UTC (permalink / raw)
  To: grant.likely, david, linuxppc-dev

I was misled by the prior language.  I've attempted to clarify how
'ranges' are used, in particular, how to get an identity mapping.

Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 Documentation/powerpc/booting-without-of.txt |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..7327f37 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
 like address space bits, you'll have to add a bus translator to the
 prom_parse.c file of the recent kernels for your bus type.
 
-The "reg" property only defines addresses and sizes (if #size-cells
-is non-0) within a given bus. In order to translate addresses upward
+The "reg" property only defines addresses and sizes (if #size-cells is
+non-0) within a given bus. In order to translate addresses upward
 (that is into parent bus addresses, and possibly into CPU physical
 addresses), all busses must contain a "ranges" property. If the
 "ranges" property is missing at a given level, it's assumed that
-translation isn't possible. The format of the "ranges" property for a
-bus is a list of:
+translation isn't possible, i.e., the registers are not visible on the
+parent bus.  The format of the "ranges" property for a bus is a list
+of:
 
 	bus address, parent bus address, size
 
@@ -735,6 +736,10 @@ fit in a single 32-bit word.   New 32-bit powerpc boards should use a
 1/1 format, unless the processor supports physical addresses greater
 than 32-bits, in which case a 2/1 format is recommended.
 
+Alternatively, the "ranges" property may be empty, indicating that the
+registers are visible on the parent bus using an identity mapping
+translation.  In other words, the parent bus address space is the same
+as the child bus address space.
 
 2) Note about "compatible" properties
 -------------------------------------
-- 
1.5.3.4-dirty

^ permalink raw reply related

* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Mark A. Greer @ 2007-12-04  1:23 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196715170.13230.228.camel@pasglop>

On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote:
> > 	#address-cells = <1>;
> > +	#size-cells = <1>;
> > +	model = "Katana-Qp"; /* Default */
> > +	compatible = "emerson,Katana-Qp";
> > +	coherency-off;
> > +
> 
> What do that mean (coherency-off) ?
> 
> Somebody is trying again to use a 74xx with non cache coherent DMA ?

Hi Ben.

I suspect Andrei got that from the prpmc2800 dts which I made so I'll
jump in.  (BTW, this is the same debate we have every year or two. :)

By looking at the dts, that board has an mv64460 which has a couple
issues when it comes to coherency (depending on the rev of the chip).

One is about not being able to use DCBST instructions with coherency on
and the other is about limiting the length of one of the traces (which
at least one board manufacturer that I know of refuses to implement).
The first one is supposed to be fixed by rev A1 of the part and the second
is supposed to be fixed by rev B0 of the part.  I don't know what rev(s)
are on the board(s) Andrei is using.  If its B0 or later, in theory, the
part should work with coherency on.

Andrei, have you tested with coherency on?

--

As far as the prpmc2800 (mv64360)...

[I don't know what an NDA let's me say or not so I'll just give
summaries of the errata.  If you or another reader has signed the NDA
you/they can look them up.]

I don't recall all of the details anymore but these are the errata I saw
by quickly scanning the 64360's list.

- "FEr CPU-#1":

Basically the CPU could read a stale cache line.  Supposed to be fixed
in rev A2 & B0 but I haven't verified.

- "FEr MPSC-#1":

The MPSC can't access a coherent memory region.
This is pretty much a show stopper for the prpmc2800.

There are no plans to fix that erratum.

- "FEr PCI-#4" (Detailed by Application Note AN-84):

[This isn't strictly a coherency issue but having coherency enabled
exacerbates the problem.]  Basically, the bridge can let the cpu read
a pci device's registers before all of the data the PCI devices has
written has actually made it to memory.  This and the fact that the
device's write data may be stuck in the PCI Slave Write Buffer
(which isn't checked for coherency), the cpu can get stale data.

There are no plans to fix that erratum.

- "FEr PCI-#5" (Detailed by Application Note AN-85):

With certain PCI devices and with coherency enabled, some combinations
of PCI transactions can cause a deadlock.  There is a workaround
documented but I've tried it and it didn't work for me (but I can't be
sure that was the erratum I was bumping into).

There are no plans to fix that erratum.
--

So, the answer depends on what part & what rev of the part you have
(e.g., the pegasos doesn't use the MPSC and apparently has the other
issues worked around so it can turn on coherency but the prpmc2800
doesn't so it needs coherency off).

BTW, I haven't forgotten the inherent bug you described when coherency
is off (/me too lazy to find link to the email) but AFAIK I've never run
into it.  However, if I turn on coherency and stress the PCI bus, it
hangs (I can't even look at memory thru a bdi).

Mark

^ permalink raw reply

* RE: current ARCH=powerpc for v2pro.
From: Stephen Neuendorffer @ 2007-12-04  1:28 UTC (permalink / raw)
  To: Stephen Neuendorffer, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20071204004843.8B5FB1C20046@mail6-sin.bigfish.com>

Hmm...  This code (from arch/ppc/boot/simple/embed_config.c) appears to
help:

	static const unsigned long line_size =3D 32;
	static const unsigned long congruence_classes =3D 256;
	unsigned long addr;
	unsigned long dccr;

	/*
	 * Invalidate the data cache if the data cache is turned off.
	 * - The 405 core does not invalidate the data cache on power-up
	 *   or reset but does turn off the data cache. We cannot assume
	 *   that the cache contents are valid.
	 * - If the data cache is turned on this must have been done by
	 *   a bootloader and we assume that the cache contents are
	 *   valid.
	 */
	__asm__("mfdccr %0": "=3Dr" (dccr));
	if (dccr =3D=3D 0) {
		for (addr =3D 0;
		     addr < (congruence_classes * line_size);
		     addr +=3D line_size) {
			__asm__("dccci 0,%0": :"b"(addr));
		}
	}

Although, I'm not sure why that should be virtex specific.

Steve=20

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
> labs.org] On Behalf Of Stephen Neuendorffer
> Sent: Monday, December 03, 2007 4:49 PM
> To: Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: current ARCH=3Dpowerpc for v2pro.
>=20
> I tried that, which essentially differed from what I was=20
> trying in that
> interrupts were turned off.
> It fails in the same way as before.
>=20
> I've booted ARCH=3Dppc from your tree on the exact same hardware =
design,
> and as near as I can tell, the code that runs in the kernel=20
> proper up to
> the point where I see the machine check is almost identical.
>=20
> The machine check (a trap into the Machine Check handler at 0x200)
> occurs at a nondeterministic point during the execution of=20
> memset_io in
> early_init.
>=20
> In the kernel I have, _bss_start is c02c8000, and these are the
> registers in the trap handler on two different runs of the kernel:
>=20
>     r3: c02c80cc r5: 00022874
>     r3: c02c8248 r5: 000226f4
>=20
> r3 is the current point being initialized, and r5 is the=20
> count remaining
> in the .bss.
>=20
> So, what would cause a machine check in the middle of a loop, in the
> middle of the almost the simplest code absolutely possible, and not on
> an obvious memory boundary?
>=20
> Steve
>=20
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> > Behalf Of Grant Likely
> > Sent: Friday, November 30, 2007 10:40 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-embedded
> > Subject: Re: current ARCH=3Dpowerpc for v2pro.
> >=20
> > On 11/30/07, Stephen Neuendorffer=20
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> > > Grant,
> > >
> > > I'm trying to bring up your arch/powerpc work, using a compiled in
> > > device tree.  I added this:
> > >
> > <snip>
> > >
> > > Which seems bizarre, because that code is very simple. =20
> I'm guessing
> > > that something in the memory configuration is wierd (or maybe
> > > zImage.virtex is not the right way to do this?) but I'm a=20
> > little lost
> > > where to look from here.  I also tried it with both=20
> > paulus_master and
> > > your virtex-for-2.6.24 branch.
> >=20
> >=20
> > I've got a patch that adds 'raw' image support (originally=20
> written by
> > Scott Wood) which somewhat works for booting (but not entirely; I
> > haven't had time to dig into it properly yet).  It's not suitable to
> > go into mainline yet.  I'll try to get the patch out to my tree this
> > evening... actually I've been trying to get my tree pushed out all
> > today, but other things keep coming up.  :-)
> >=20
> > <several hours after I wrote the above>
> >=20
> > Okay, I pushed my current patch set out to the master branch of my
> > linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> > should be usable for booting.
> >=20
> > Cheers,
> > g.
> >=20
> > --=20
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab.ca
> > (403) 399-0195
> >=20
> >=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

^ permalink raw reply

* Re: [PATCH] Add IPIC MSI interrupt support
From: Li Li @ 2007-12-04  1:41 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Gala Kumar, Li Tony
In-Reply-To: <1196715812.13230.234.camel@pasglop>

On Tue, 2007-12-04 at 05:03 +0800, Benjamin Herrenschmidt wrote:
> 
> On Mon, 2007-12-03 at 17:07 +0800, Li Li wrote: 
> > 
> > In IPIC, the 8 MSI interrupts is handled as level intrrupt. 
> > I just provide a versatile in case it is changed.
> 
> Level ? Are you sure ? MSIs are by definition edge interrupts... Or
> do 
> you have some weird logic that asserts a level input until you go ack 
> something ? Sounds weird...
> 

The second one.
The MSI is edge interrupt. The 256 MSI interrupts are divided into 8
groups. Each group can generate a interrupt to core. This interrupts are
level and asserted untile ack MSI interrupt. A little weird.

> Ben.
> 
> 

- Tony

^ permalink raw reply

* Re: Merge dtc
From: David Woodhouse @ 2007-12-04  1:59 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071016050217.GA9052@localhost.localdomain>


On Tue, 2007-10-16 at 15:02 +1000, David Gibson wrote:
> This very large patch incorporates a copy of dtc into the kernel
> source, in arch/powerpc/boot/dtc-src.  This means that dtc is no
> longer an external dependency to build kernels with configurations
> which need a dtb file.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Too big for the list, full patch at
> http://ozlabs.org/~dgibson/home/merge-dtc.patch

I think this is a bad idea -- it's hardly a difficult for those people
who _do_ need dts to obtain it separately.

It's bad enough that I have to separate out the bootwrapper code, which
probably ought to live outside the kernel. We shouldn't be merging
_more_ stuff in.

-- 
dwmw2

^ permalink raw reply

* RE: [PATCH] ipic: change ack operation that register is accessedonly when needed
From: Li Yang @ 2007-12-04  2:06 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196715747.13230.233.camel@pasglop>

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
> Sent: Tuesday, December 04, 2007 5:02 AM
> To: Li Yang
> Cc: galak@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] ipic: change ack operation that register=20
> is accessedonly when needed
>=20
>=20
> >  static void ipic_ack_irq(unsigned int virq)  {
> > -	struct ipic *ipic =3D ipic_from_irq(virq);
> >  	unsigned int src =3D ipic_irq_to_hw(virq);
> > -	unsigned long flags;
> > -	u32 temp;
> > =20
> > -	spin_lock_irqsave(&ipic_lock, flags);
> > +	/* Only external interrupts in edge mode support ACK */
> > +	if (unlikely(ipic_info[src].ack &&
> > +			((get_irq_desc(virq)->status &=20
> IRQ_TYPE_SENSE_MASK) =3D=3D
> > +			IRQ_TYPE_EDGE_FALLING))) {
> > +		struct ipic *ipic =3D ipic_from_irq(virq);
> > +		unsigned long flags;
> > +		u32 temp;
> > =20
> > -	temp =3D ipic_read(ipic->regs, ipic_info[src].pend);
> > -	temp |=3D (1 << (31 - ipic_info[src].bit));
> > -	ipic_write(ipic->regs, ipic_info[src].pend, temp);
> > +		spin_lock_irqsave(&ipic_lock, flags);
> > =20
> > -	spin_unlock_irqrestore(&ipic_lock, flags);
> > +		temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
> > +		temp |=3D (1 << (31 - ipic_info[src].bit));
> > +		ipic_write(ipic->regs, ipic_info[src].ack, temp);
> > +
> > +		spin_unlock_irqrestore(&ipic_lock, flags);
> > +	}
> >  }
>=20
> That doesn't look right...=20
>=20
> That should be handled by the higher level flow handler. The=20
> generic edge one calls ack and the level one mask_and_ack.=20
> Just make them do the right thing, no need to test for the=20
> flow type in the low level function.

But actually ack is called by edge and per cpu handlers.  Mask_and_ack
is also called by edge handler when the same interrupt is already in
progress.  So I don't think that ack/mask_and_ack implicates flow type
by design.

- Leo

^ permalink raw reply

* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Mark A. Greer @ 2007-12-04  2:10 UTC (permalink / raw)
  To: Andrei Dolnikov, linuxppc-dev
In-Reply-To: <20071203015018.GC26919@localhost.localdomain>

On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote:
> On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > Device tree source file for the Emerson Katana Qp board
> > 
> > Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com>
> > 
> > ---
> >  katanaqp.dts |  360 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 360 insertions(+)
> > 
> > diff --git a/arch/powerpc/boot/dts/katanaqp.dts b/arch/powerpc/boot/dts/katanaqp.dts
> > new file mode 100644
> > index 0000000..98257a2
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/katanaqp.dts
> > @@ -0,0 +1,360 @@
> > +/* Device Tree Source for Emerson Katana Qp
> > + *
> > + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com>
> > + *	    Andrei Dolnikov <adolnikov@ru.mvista.com>
> > + * 
> > + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com>
> > + *
> > + * 2007 (c) MontaVista, Software, 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 kind, whether express
> > + * or implied.
> > + *
> > + */
> > +
> > +/ {
> > +	#address-cells = <1>;
> > +	#size-cells = <1>;
> > +	model = "Katana-Qp"; /* Default */
> > +	compatible = "emerson,Katana-Qp";
> > +	coherency-off;
> 
> What is this property for?

Its needed to tell the bootwrapper that the platform does not have
coherency enabled (since our policy is that you can't use a CONFIG_ option).
The bootwrapper needs to know that if/when it sets up the windows for
its I/O devices (e.g., enet, mpsc) to system memory.  I needed to do
this on the prpmc2800 because the firmware didn't set up those windows
correctly.  I don't know if the Katana Qp's firmware sets the up
correctly or not.

> > +	mv64x60@f8100000 { /* Marvell Discovery */
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		model = "mv64460";			/* Default */
> > +		compatible = "marvell,mv64x60";
> 
> Compatible properties should not have "x" asn in 64x60 here.  If
> there's a suitable name for the general register interface use that,
> otherwise use the specific model number of the earliest device to
> implement this register interface.  Later models should have a
> compatible property which lists their specific model, followed by the
> earlier model number with which they're compatible.

This came from the prpmc2800's dts which has become out-of-date.
Both dts files need to be updated.

> > +		ethernet@2000 {
> > +			reg = <2000 2000>;
> 
> Are the registers for the 3 ethernets really all together?  This bank
> can't be subdivided into seperate register blocks for each MAC?

Unfortunately there are some registers that are shared so you can't
divide them up nicely.

> > +			eth0 {
> > +				device_type = "network";
> > +				compatible = "marvell,mv64x60-eth";
> > +				block-index = <0>;
> 
> This block-index thing is crap.  If you really need to subindex nodes
> like this, use "reg", with an appropriate #address-cells in the
> parent, then the nodes will also get sensible unit addresses.

So how would that work for the "PHY Address Register 0x2000", say,
where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device
addr for PHY 1; bts 10-14 set the devce addr for PHY 2?

> > +				interrupts = <20>;
> > +				interrupt-parent = <&/mv64x60/pic>;
> 
> You should use a label for the PIC to make things more readable.

More that needs to be updated in prpmc2800.  :(

> > +		sdma@4000 {
> > +			compatible = "marvell,mv64x60-sdma";
> > +			reg = <4000 c18>;
> > +			virtual-reg = <f8104000>;
> 
> Why does this node have virtual-reg?

"virtual-reg" is a special property that doesn't get translated thru
the parent mappings.  It should never be used in the kernel.  Its
purpose is to give code in the bootwrapper the exact address that it
should use to access a register or block of registers or ...
Its needed here because the MPSC (serial) driver uses the SDMA unit
to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's).

Yes, this needs to be documented.

> > +		mpsc@8000 {
> > +			device_type = "serial";
> > +			compatible = "marvell,mpsc";
> > +			reg = <8000 38>;
> > +			virtual-reg = <f8108000>;
> > +			sdma = <&/mv64x60/sdma@4000>;
> > +			brg = <&/mv64x60/brg@b200>;
> > +			cunit = <&/mv64x60/cunit@f200>;
> > +			mpscrouting = <&/mv64x60/mpscrouting@b400>;
> > +			mpscintr = <&/mv64x60/mpscintr@b800>;
> > +			block-index = <0>;
> 
> What is this block-index thing about here?  Since the devices are
> disambiguated by their register address, why do you need it?

This particular one is needed to access the correct MPSC interrupt reg.
Maybe it would be better to make a new property for this but it was only
one reg and block-index was already there and basically served that
purpose so I used it.  I'd be happy to use an alternative if you have
something you think is better.

> > +		pic {
> 
> Needs a unit address.

Okay.

> > +		cpu-error@0070 {
> 
> The unit address should notr include leading zeroes.

Okay.

Mark

^ permalink raw reply

* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
From: Mark A. Greer @ 2007-12-04  2:12 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196715299.13230.230.camel@pasglop>

On Tue, Dec 04, 2007 at 07:54:59AM +1100, Benjamin Herrenschmidt wrote:
> 
> On Thu, 2007-11-29 at 18:42 +0300, Andrei Dolnikov wrote:
> > +config PPC_KATANAQP
> > +       bool "Emerson-Katana Qp"
> > +       depends on EMBEDDED6xx
> > +       select MV64X60
> > +       select NOT_COHERENT_CACHE
>                  ^^^^^^^^^^^^^^^^^^
> 
> Just one word: ARGHHHHHHHH !
> 
> Oh and another one: WHY ?

I responded to your other email regarding this.

Mark

^ permalink raw reply

* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Benjamin Herrenschmidt @ 2007-12-04  2:14 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071204012329.GA18903@mag.az.mvista.com>


 .../... (snip scary bunch of errata)

> - "FEr PCI-#4" (Detailed by Application Note AN-84):
> 
> [This isn't strictly a coherency issue but having coherency enabled
> exacerbates the problem.]  Basically, the bridge can let the cpu read
> a pci device's registers before all of the data the PCI devices has
> written has actually made it to memory.  This and the fact that the
> device's write data may be stuck in the PCI Slave Write Buffer
> (which isn't checked for coherency), the cpu can get stale data.
> 
> There are no plans to fix that erratum.

So if I understand correctly, there's no plan to fix a major PCI spec
violation which prevent any kind of reliable implementation whatsoever ?

Or rather... the part just doesn't work, period. Don't use it. If you
do, you're on your own.

> - "FEr PCI-#5" (Detailed by Application Note AN-85):
> 
> With certain PCI devices and with coherency enabled, some combinations
> of PCI transactions can cause a deadlock.  There is a workaround
> documented but I've tried it and it didn't work for me (but I can't be
> sure that was the erratum I was bumping into).
> 
> There are no plans to fix that erratum.

Yeah... great. Oh well, Paul, what about we just don't support people
using that chip ?

> So, the answer depends on what part & what rev of the part you have
> (e.g., the pegasos doesn't use the MPSC and apparently has the other
> issues worked around so it can turn on coherency but the prpmc2800
> doesn't so it needs coherency off).
> 
> BTW, I haven't forgotten the inherent bug you described when coherency
> is off (/me too lazy to find link to the email) but AFAIK I've never run
> into it.  However, if I turn on coherency and stress the PCI bus, it
> hangs (I can't even look at memory thru a bdi).

Well, as it is today, the "classic" MMU code cannot deal with !coherent.
The entire linear mapping is always mapped cacheable with BATs, so stuff
may be brought into the cache at any time, potentially polluting DMA
data.

Dealing with that would be hard. It might be possible by using G on the
entire linear mapping like we do on 4xx (yuck), and/or by not using
D-BATs (the kernel will blow up in various areas without I-BATs).

Ben.

^ permalink raw reply


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