[PATCH] ppc: add support for new powerbooks

[PATCH] ppc: add support for new powerbooks

[Olof Johansson]

Hi,

This should be ready to go in now; we'll have to do with basic
enablement for now -- touchpad driver can come later.


Thanks,

Olof

---

Enablement patch for the new PowerBooks (late 2005 edition).

This enables the ATA controller, Gigabit ethernet and basic AGP setup.
Bluetooth works out-of-the box after running hid2hci.

Still remaining is to get the touchpad to work, the simple change of
just adding the new USB ids isn't enough.


Signed-off-by: Olof Johansson <olof@lixom.net>


Index: linux-2.6/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-2.6.orig/arch/ppc/platforms/pmac_feature.c	2005-11-08 22:06:20.000000000 -0800
+++ linux-2.6/arch/ppc/platforms/pmac_feature.c	2005-11-08 22:06:48.000000000 -0800
@@ -2317,6 +2317,14 @@ static struct pmac_mb_def pmac_mb_defs[]
 		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
 		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
 	},
+	{	"PowerBook5,8",			"PowerBook G4 15\"",
+		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
+		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+	},
+	{	"PowerBook5,9",			"PowerBook G4 17\"",
+		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
+		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+	},
 	{	"PowerBook6,1",			"PowerBook G4 12\"",
 		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
 		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
Index: linux-2.6/drivers/ide/ppc/pmac.c
===================================================================
--- linux-2.6.orig/drivers/ide/ppc/pmac.c	2005-11-08 22:06:22.000000000 -0800
+++ linux-2.6/drivers/ide/ppc/pmac.c	2005-11-08 22:06:48.000000000 -0800
@@ -1667,11 +1667,16 @@ static struct macio_driver pmac_ide_maci
 };
 
 static struct pci_device_id pmac_ide_pci_match[] = {
-	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_ATA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
-	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID_ATA100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
-	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_K2_ATA100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_ATA,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID_ATA100,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_K2_ATA100,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_SH_ATA,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID2_ATA,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 };
 
 static struct pci_driver pmac_ide_pci_driver = {
Index: linux-2.6/drivers/net/sungem.c
===================================================================
--- linux-2.6.orig/drivers/net/sungem.c	2005-10-27 17:02:08.000000000 -0700
+++ linux-2.6/drivers/net/sungem.c	2005-11-08 22:06:48.000000000 -0800
@@ -128,6 +128,8 @@ static struct pci_device_id gem_pci_tbl[
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_SH_SUNGEM,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
+	{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID2_GMAC,
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 	{0, }
 };
 
Index: linux-2.6/include/linux/pci_ids.h
===================================================================
--- linux-2.6.orig/include/linux/pci_ids.h	2005-11-08 22:06:25.000000000 -0800
+++ linux-2.6/include/linux/pci_ids.h	2005-11-08 22:06:48.000000000 -0800
@@ -801,6 +803,10 @@
 #define PCI_DEVICE_ID_APPLE_SH_SUNGEM   0x0051
 #define PCI_DEVICE_ID_APPLE_U3L_AGP	0x0058
 #define PCI_DEVICE_ID_APPLE_U3H_AGP	0x0059
+#define PCI_DEVICE_ID_APPLE_IPID2_AGP	0x0066
+#define PCI_DEVICE_ID_APPLE_IPID2_ATA	0x0069
+#define PCI_DEVICE_ID_APPLE_IPID2_FW	0x006a
+#define PCI_DEVICE_ID_APPLE_IPID2_GMAC	0x006b
 #define PCI_DEVICE_ID_APPLE_TIGON3	0x1645
 
 #define PCI_VENDOR_ID_YAMAHA		0x1073
Index: linux-2.6/drivers/char/agp/uninorth-agp.c
===================================================================
--- linux-2.6.orig/drivers/char/agp/uninorth-agp.c	2005-11-08 22:06:21.000000000 -0800
+++ linux-2.6/drivers/char/agp/uninorth-agp.c	2005-11-08 22:06:48.000000000 -0800
@@ -557,6 +557,10 @@ static struct agp_device_ids uninorth_ag
 		.device_id	= PCI_DEVICE_ID_APPLE_U3H_AGP,
 		.chipset_name	= "U3H",
 	},
+	{
+		.device_id	= PCI_DEVICE_ID_APPLE_IPID2_AGP,
+		.chipset_name	= "UniNorth/Intrepid2",
+	},
 };
 
 static int __devinit agp_uninorth_probe(struct pci_dev *pdev,

Re: [PATCH] ppc: add support for new powerbooks

[Benjamin Herrenschmidt]

> Enablement patch for the new PowerBooks (late 2005 edition).
> 
> This enables the ATA controller, Gigabit ethernet and basic AGP setup.
> Bluetooth works out-of-the box after running hid2hci.
> 
> Still remaining is to get the touchpad to work, the simple change of
> just adding the new USB ids isn't enough.
> 
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: [PATCH] ppc: add support for new powerbooks

[Andrew Morton]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

I don't think I'm adding much value handling ppc/ppc64 patches, really. 
I'd prefer to get out of that business.

It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.

And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.

I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.

Possible?

Re: [PATCH] ppc: add support for new powerbooks

[Benjamin Herrenschmidt]

> I don't think I'm adding much value handling ppc/ppc64 patches, really. 
> I'd prefer to get out of that business.
> 
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
> 
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
> 
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
> 
> Possible?

Well, I'm personally no fan of the git route as it causes us to have
less review on the list imho (too easy also for me to just bounce a
patch to paulus to shove in his git tree :) though that's what I've been
doing for the last few days at least. But if you prefer that way, yes,
it's certainly possible.

Ben.

Re: [PATCH] ppc: add support for new powerbooks

[Andrew Morton]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> 
> > I don't think I'm adding much value handling ppc/ppc64 patches, really. 
> > I'd prefer to get out of that business.
> > 
> > It would be better to have an arch maintainer who runs a git tree, same as
> > ia64, arm, etc.
> > 
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> > 
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> > 
> > Possible?
> 
> Well, I'm personally no fan of the git route as it causes us to have
> less review on the list imho

Well yes, that's a generic problem with subsystem trees.  I suppose one
could enforce processes which prevent it from happening.

> (too easy also for me to just bounce a
> patch to paulus to shove in his git tree :) though that's what I've been
> doing for the last few days at least. But if you prefer that way, yes,
> it's certainly possible.

OK, well please think about it.  It's not a ton of work at this end at
present, but a) you lazy bums don't ack most of the things I cc you on, so
it's rather open-loop and I don't know whether I'm merging wrong patches
and b) there's now increasing potential for patches in -mm to clash with
patches in Paul's git tree.

The latter can be solved easily enough: I add Paul's git tree to the -mm
lineup.   Gimme.

Re: [PATCH] ppc: add support for new powerbooks

[Benjamin Herrenschmidt]

> Well yes, that's a generic problem with subsystem trees.  I suppose one
> could enforce processes which prevent it from happening.

I think the right process is to go through the linuxppc[64]-dev list(s)
first, maybe CC lkml when it's not strictly arch gore, and then hop from
there to -git. We also have a nice patch tracking system scanning those
lists, I suppose I need to fix my own habits of bypassing all of that
stuff :)

> OK, well please think about it.  It's not a ton of work at this end at
> present, but a) you lazy bums don't ack most of the things I cc you on, so
> it's rather open-loop and I don't know whether I'm merging wrong patches
> and b) there's now increasing potential for patches in -mm to clash with
> patches in Paul's git tree.
> 
> The latter can be solved easily enough: I add Paul's git tree to the -mm
> lineup.

I think going through the -git tree always makes sense and I've doing
doing that for my own production, I'll route patches that I'm acking
that way too from now on.

I'm keeping the liberty of bombing you & linus directly when I think
it's an important bug fix late in the rc cycle though :)

Ben.

Re: [PATCH] ppc: add support for new powerbooks

[Paul Mackerras]

Andrew Morton writes:

> I don't think I'm adding much value handling ppc/ppc64 patches, really. 
> I'd prefer to get out of that business.
> 
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.

My powerpc-merge.git tree is sort-of de-facto that at the moment.

> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
> 
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
> 
> Possible?

Yes.  Good idea, in fact.  I'll create a powerpc.git tree once the
current merge window closes.

Do I need to grep the -mm releases for ppc patches or will you mail
them to me?

Regards,
Paul.

Re: [PATCH] ppc: add support for new powerbooks

[Andrew Morton]

Paul Mackerras <paulus@samba.org> wrote:
>
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> > 
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> > 
> > Possible?
> 
> Yes.  Good idea, in fact.  I'll create a powerpc.git tree once the
> current merge window closes.

OK.

> Do I need to grep the -mm releases for ppc patches or will you mail
> them to me?

If I see a ppc patch I will:

- merge it into -mm, add you guys to the cc on the mm-commits email.

- stage the patch after git-powerpc.patch in the -mm lineup.

- if I see the patch appear in git-powerpc.patch, I just drop it.  I sync
  with the git trees maybe twice per day.

- time passes

- if it still hasn't been merged into git-powerpc, I start spamming you
  with the patch.

So no, you don't need to grep -mm and I won't bypass the git-powerpc tree
and the patch won't get lost.  All you need to do is to either merge or
nack the patch at some stage.

Easy as pie ;)

Re: [PATCH] ppc: add support for new powerbooks

[Olof Johansson]

On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> I don't think I'm adding much value handling ppc/ppc64 patches, really. 
> I'd prefer to get out of that business.

Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.

> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
> 
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
> 
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
> 
> Possible?

I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).

If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.

Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)


Thanks,

-Olof

Re: [PATCH] ppc: add support for new powerbooks

[Kumar Gala]

On Nov 10, 2005, at 10:44 AM, Olof Johansson wrote:

> On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>
>>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>
>> I don't think I'm adding much value handling ppc/ppc64 patches,  
>> really.
>> I'd prefer to get out of that business.
>
> Main benefit for me, as a patch submitter, is that you consistently,
> always, ACK when you pick up or drop a patch. In other words, I don't
> have to go polling a tree to see if it made it in or not.
>
>> It would be better to have an arch maintainer who runs a git tree,  
>> same as
>> ia64, arm, etc.
>>
>> And, given the amount of shared infrastructure, I suspect it would  
>> have to
>> be a single git tree for both architectures.
>>
>> I'd still sweep up random ppc patches, but those will go into  
>> mainline via the
>> originator->mm->git-powerpc->linus route.
>>
>> Possible?
>
> I'm fine with all that; to be honest I haven't been certain where the
> smaller ppc/ppc64 patches should go during this whole merge  
> business (or
> after, for that matter).
>
> If Paulus wants to start an arch tree, that's fine with me. I do share
> Ben's opinion about less review though, I guess we'll just have to  
> deal
> with that.
>
> Also, Paul, I kindly request some sort of ACK mechanism similar to
> Andrew's when patches are picked up. :-)

I agree with Olof's comments.  Additionally, I think one reason we  
had been sending things to Andrew for PPC32 embedded was that the sub- 
arch maintainers (Matt, Marcelo, Tom, Dan, Sylvain, myself, etc..)  
needed a responsive path to get things to Linus which Andrew was  
providing.  If Paul's going to be able to handle accepting and  
dealing with all the embedded patches I'm fine with having a PPC git  
tree.  I'm even willing to setup some GIT tree's for sub-arch's I  
deal with for Paul to pull from if he wants.

Just my two cents.

- kumar