* Re: OF devices and non OF devices
From: John Rigby @ 2007-07-03 16:31 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-embedded
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB020D3B9D@is-hdq-exchange.marel.net>
[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]
One place to find binding between OF devices and non OF devices is in
arch/powerpc/sysdev/fsl_soc.c
The typical pattern is:
if of_find_compatible_node "of-device-name"
platform_device_register_simple ""platform-device-name"
platform_device_add_data ...
On 7/3/07, Kári Davíðsson <kari.davidsson@marel.is> wrote:
>
> Hi,
>
> I am attempting to get some non OF devices working for an mpc 5200 board,
> in particular
> PCF8563 RTC.
>
> This device has an non OF device interface which I believe is correct.
> After all it should work
> on non OF platforms.
>
> I have managed to get the board to run the i2c initialization (and probe)
> for the fsl-mpc i2c driver by
> converting the fsl-mpc i2c driver to OF driver (I found some patch here
> that I based this work on).
fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need to
change anything to
make it work in the latest kernel. CONFIG_FSL_SOC was only added to
lite5200_defconfig recently so
that may explain why it's not on in your kernel.
Since the PCF8563 driver is not OF driver only its initaliziation code is
> run but the .probe function
> of the driver is never run. Basically (as far as I can understand) the
> .probe is never run because the
> driver is not an OF driver.
>
> I could convert the PCF8563 driver to OF driver and make it work for our
> puposes but I feel this is
> 1) Wrong
> 2) therefore wasted work.
Since the driver must run on non OF platforms then it should not be
converted. You just need to add a platform_device_register somewhere.
I don't think fsl_soc.c is the right place since it is not part of an
freescale SOC.
You could probably put it in a board specific startup routine.
What seems to elude me is some glue that glues together the OF part of the
> driver space to the non OF part
> of the driver space.
>
> Any hints or pointers on where to find this glue?
>
> Regards,
> kd
>
> P.S. Kernel is post 2.6.20.
>
> --
> Kári Davíðsson | kari.davidsson@marel.is
> Hugbúnaðargerð | www.marel.com
> Tel: 563-8156 Fax: +354 563 8001
> Iceland
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3482 bytes --]
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Ying Lin @ 2007-07-03 15:11 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <468A6441.105@freescale.com>
> Have you tried using a PCI UART card?
No, the hardware is fixed to use UCC4/5.
^ permalink raw reply
* OF devices and non OF devices
From: Kári Davíðsson @ 2007-07-03 14:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am attempting to get some non OF devices working for an mpc 5200 =
board, in particular=20
PCF8563 RTC.
This device has an non OF device interface which I believe is correct. =
After all it should work
on non OF platforms.
I have managed to get the board to run the i2c initialization (and =
probe) for the fsl-mpc i2c driver by
converting the fsl-mpc i2c driver to OF driver (I found some patch here =
that I based this work on).
Since the PCF8563 driver is not OF driver only its initaliziation code =
is run but the .probe function
of the driver is never run. Basically (as far as I can understand) the =
.probe is never run because the
driver is not an OF driver.
I could convert the PCF8563 driver to OF driver and make it work for our =
puposes but I feel this is
1) Wrong
2) therefore wasted work.
What seems to elude me is some glue that glues together the OF part of =
the driver space to the non OF part
of the driver space.
Any hints or pointers on where to find this glue?
Regards,
kd
P.S. Kernel is post 2.6.20.
--=20
K=E1ri Dav=ED=F0sson | kari.davidsson@marel.is
Hugb=FAna=F0arger=F0 | www.marel.com
Tel: 563-8156 Fax: +354 563 8001
Iceland
^ permalink raw reply
* Re: How to handle patches that cross maintainers?
From: Mauro Carvalho Chehab @ 2007-07-03 15:01 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Paul Mackerras,
Linux Kernel Development
In-Reply-To: <4BEFAFC6-3346-4F29-B1C5-377952E3FBBF@kernel.crashing.org>
Em Ter, 2007-07-03 às 04:01 -0500, Kumar Gala escreveu:
> Andrew,
>
> I was hoping to get your input on how to handle patches that cross
> maintainers. I've got a patch that is pretty PPC specific, but
> happens to touch some drivers as well.
>
> Here's the diffstat to get a rough idea:
>
> arch/powerpc/kernel/io.c | 12 ++++++------
> arch/powerpc/mm/hash_native_64.c | 2 +-
> arch/powerpc/mm/stab.c | 4 ++--
> drivers/ide/pci/scc_pata.c | 4 ++--
> drivers/media/dvb/bt8xx/bt878.h | 5 ++---
> drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
> include/asm-powerpc/system.h | 2 +-
> 7 files changed, 15 insertions(+), 16 deletions(-)
>
> Now, I've had this issue before w/o any good sense on how to handle it.
The better is to copy all of us and wait for some time to allow each
maintainer to ack or comment the changeset, if needed.
Please c/c me for any changes on /drivers/media stuff.
Cheers,
Mauro
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Josh Boyer @ 2007-07-03 15:00 UTC (permalink / raw)
To: tgall; +Cc: linuxppc-dev, paulus
In-Reply-To: <26d387970707030747u69ee8d2axb79452e5e1b7fa2d@mail.gmail.com>
On Tue, 2007-07-03 at 09:47 -0500, Tom Gall wrote:
> June 2008 is a long time away to let this linger. Why not say by End
> of the year 2007? That should give folks essentially two more 2.6
> releases.
A year seemed like the appropriate amount of time for an arch removal.
And Segher had made a suggestion that it could be officially killed
during the PowerPC BOF at OLS 2008 for fun. But honestly, it doesn't
matter to me. As others have said, things can always be resurrected
from old tags if needs be.
Essentially, I'm trying to be sneaky and get Paul to declare it dead
officially. When it actually dies, I don't care ;)
josh
^ permalink raw reply
* Re: Anyone using QE UART mode?
From: Timur Tabi @ 2007-07-03 14:59 UTC (permalink / raw)
To: Ying Lin; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A90D@airmail.wirelessworld.airvananet.com>
Ying Lin wrote:
>
>> Which chip are you using? There should be separate 16550 compatible
>> UART controller on MPC8360. The driver is already there and working
>> pretty well.
>
> We are using MPC8323E. We have 2 working serial ports from the DUART
> controller, but we need more than 2.
>
> We have about 4 weeks to make them working, any suggestion where to
> start? We plan to start with CW QE Utility generated codes.
Have you tried using a PCI UART card?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Tom Gall @ 2007-07-03 14:47 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183469146.3590.7.camel@weaponx.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
June 2008 is a long time away to let this linger. Why not say by End of the
year 2007? That should give folks essentially two more 2.6 releases.
Regards,
Tom
On 7/3/07, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> The arch/ppc tree has been in a semi-nebulous "bug fix only" state for a
> few kernel releases now. The patch below officially declares this as of
> the 2.6.22 kernel release and schedules arch/ppc for removal in June of
> 2008.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> ---
> Documentation/feature-removal-schedule.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> --- linux-2.6.orig/Documentation/feature-removal-schedule.txt
> +++ linux-2.6/Documentation/feature-removal-schedule.txt
> @@ -348,3 +348,15 @@ Who: Tejun Heo <htejun@gmail.com>
>
> ---------------------------
>
> +What: The arch/ppc and include/asm-ppc directories
> +When: Jun 2008
> +Why: The arch/powerpc tree is the merged architecture for ppc32 and
> ppc64
> + platforms. Currently there are efforts underway to port the
> remaining
> + arch/ppc platforms to the merged tree. New submissions to the
> arch/ppc
> + tree have been frozen with the 2.6.22 kernel release and that tree
> will
> + remain in bug-fix only mode until its scheduled removal. Platforms
> + that are not ported by June 2008 will be removed due to the lack of
> an
> + interested maintainer.
> +Who: linuxppc-dev@ozlabs.org
> +
> +---------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 2515 bytes --]
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Christoph Hellwig @ 2007-07-03 14:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, Jul 03, 2007 at 03:36:09PM +1000, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
What happened to Ben's and my signal and ptrace patches?
^ permalink raw reply
* Re: How to handle patches that cross maintainers?
From: Christoph Hellwig @ 2007-07-03 14:13 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Paul Mackerras,
Linux Kernel Development
In-Reply-To: <4BEFAFC6-3346-4F29-B1C5-377952E3FBBF@kernel.crashing.org>
On Tue, Jul 03, 2007 at 04:01:20AM -0500, Kumar Gala wrote:
> Andrew,
>
> I was hoping to get your input on how to handle patches that cross
> maintainers. I've got a patch that is pretty PPC specific, but
> happens to touch some drivers as well.
I think the real question is why the heck does it touch those drivers?
:)
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Christoph Hellwig @ 2007-07-03 14:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, Jul 03, 2007 at 03:36:09PM +1000, Paul Mackerras wrote:
> [POWERPC] spufs: Add stat file to spufs
> [POWERPC] spufs: Add spu stats in sysfs
These two should not go to Linus yet, they'll probably need quite a bit
of rework.
^ permalink raw reply
* [PATCH v2] Schedule removal of arch/ppc
From: Josh Boyer @ 2007-07-03 13:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The arch/ppc tree has been in a semi-nebulous "bug fix only" state for a
few kernel releases now. The patch below officially declares this as of
the 2.6.22 kernel release and schedules arch/ppc for removal in June of
2008.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
Documentation/feature-removal-schedule.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- linux-2.6.orig/Documentation/feature-removal-schedule.txt
+++ linux-2.6/Documentation/feature-removal-schedule.txt
@@ -348,3 +348,15 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
+What: The arch/ppc and include/asm-ppc directories
+When: Jun 2008
+Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
+ platforms. Currently there are efforts underway to port the remaining
+ arch/ppc platforms to the merged tree. New submissions to the arch/ppc
+ tree have been frozen with the 2.6.22 kernel release and that tree will
+ remain in bug-fix only mode until its scheduled removal. Platforms
+ that are not ported by June 2008 will be removed due to the lack of an
+ interested maintainer.
+Who: linuxppc-dev@ozlabs.org
+
+---------------------------
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Ying Lin @ 2007-07-03 13:15 UTC (permalink / raw)
To: Li Yang-r58472, Tabi Timur-B04825; +Cc: linuxppc-embedded
In-Reply-To: <989B956029373F45A0B8AF0297081890D83844@zch01exm26.fsl.freescale.net>
> Which chip are you using? There should be separate 16550 compatible
> UART controller on MPC8360. The driver is already there and working
> pretty well.
We are using MPC8323E. We have 2 working serial ports from the DUART
controller, but we need more than 2.
We have about 4 weeks to make them working, any suggestion where to
start? We plan to start with CW QE Utility generated codes.
Thanks,
Ying
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Josh Boyer @ 2007-07-03 13:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
On Tue, 2007-07-03 at 15:36 +1000, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
How about:
http://patchwork.ozlabs.org/linuxppc/patch?id=12014
and maybe:
http://patchwork.ozlabs.org/linuxppc/patch?id=11953
I can fix the apostrophe if you really want ;)
josh
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Segher Boessenkool @ 2007-07-03 12:49 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <20070703095114.GA31118@iram.es>
>>>> + external-control;
>>>>
>>>> Really?
>>>
>>> Well, is anybody actually using eciwx/ecowx?
>>
>> That's not the point -- the device tree should only
>> say "external-control" if the CPU actually supports
>> it; AFAIK, that's 601 only.
>
> I wonder whether you are mixing up external control
> and direct-store segments (the "T" bit in segment registers).
=93external-control=94 prop-encoded-array: <none>
This property, if present, indicates that the PowerPC
microprocessor defined by this CPU node implements the
External Control Facility as described in the =93Optional
Facilities and Instructions=94 appendix of Book II of [2].
The absence of his property indicates that the PowerPC
microprocessor defined by this CPU node does not support
the External Control Facility.
No, I don't think I'm mixing up anything. G2 CPUs don't
support this stuff, do they?
>> =46rom my docs, external control has been supported by many
> processors, up to many variants of the 750 and even 7440/7450.
Hrm I don't think so... </me looks>... erm yeah. It's just
that it isn't usable on any of those systems ;-)
> Now I've never seen any hardware which could make use of these
> instructions (you'd need a device on the processor bus that
> reacts to the special bus cycles generated by the ec[io]wx
> instructions, since no host bridge I've ever met handles them.
Yeah exactly.
> I've not seen support for external control in the Linux kernel
> either (you'd need to setup the EAR SPR and probablly to modify
> it on context switches).
>
> OTOH, the direct-store segments were only implemented in the
> original 601, 603 (not 603e) and 604 processors (can't remember
> about the 604e) and even then the 601 had special features
> in this area.
Yah.
>>>> + pci@80000000 {
>>>> + device_type =3D "pci";
>>>> + compatible =3D "prep";
>>>>
>>>> Is that specific enough?
>>>
>>> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
>>> space is smaller and at a higher address.
>>
>> Right, so it's not; "compatible" should specify the
>> model of PCI host bridge, instead.
>
> Well, the PCI host bridge is reprogrammable in a very flexible way
> and and I actually wrote a boot loader that reprograms it the
> way I wanted address space to look like.
"compatible" should just say what exactly the hardware is;
"prep" isn't good enough to describe a certain PCI host
bridge (it doesn't say it is a PHB, to start with!)
> I shall send it to
> you in a PM (it is quite big, it includes an x86 emulator
> which is able to initialize the VGA PMC modules I have by
> running the BIOS).
Hrm I'm not sure what I should do with that?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-03 12:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <1183423369.10386.49.camel@localhost.localdomain>
>>> + addr = of_get_property(node, "reg", &len);
>>> + if (!addr || len < sizeof(int) || *addr > 0xffff)
>>> + continue;
>>
>> Addresses aren't 16 bit AFAIK?
>
> Some i2c busses support 10 bits addressing...
All I2C busses. All I2C devices, too, it's just that
not all of them can decode 10-bit addresses (but they
are fine with seeing those on the bus, they'll just
never be addressed by it themselves).
Anyway, my point was that 10 isn't the same as 16.
Segher
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Li Yang-r58472 @ 2007-07-03 11:38 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <1183461586.20673.192.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Tuesday, July 03, 2007 7:20 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
>=20
> On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > > Sent: Tuesday, July 03, 2007 3:21 PM
> > > To: Li Yang-r58472
> > > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> > >
> > > On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > > > -----Original Message-----
> > > > > From: netdev-owner@vger.kernel.org
> > > > [mailto:netdev-owner@vger.kernel.org] On
> > > > > Behalf Of Joakim Tjernlund
> > > > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > > > >
> > > > > > This patch makes the PHY optional for ucc_geth.c ethernet
> > driver.
> > > > > > This is useful to support a direct mii to mii connection to,
for
> > > > example,
> > > > > > a onboard swicth.
> > > > > >
> > > > > > Signed-off-by: Joakim Tjernlund
<joakim.tjernlund@transmode.se>
> > > > > ----
> > > > Hi Joakim,
> > > >
> > > > I'm wondering if we really need to have the option to disable
> > phylib.
> > >
> > > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and
mii
> > > on UCC3 and UCC4.
> > >
> > > > Actually we have made phylib selected by default for ucc_geth.
Many
> > L2
> > > > switch chips have the capacity to be controlled. Therefore they
can
> > be
> > > > managed as a phy device.
> > >
> > > Yes, they can be but why force a PHY impl. when its is of no use?
The
> > > only thing the eth driver needs from the it is speed and duplex.
If
> > > these are fixed, you don't need to talk with a PHY.
> >
> > The driver needs to get and set the link speed/status on runtime
(such
> > as for ethtool interface). Currently this is implementation through
> > phydev interface. IMHO, it will be easier to maintain if we only
use
> > this standard interface, rather than use different interfaces for
> > different cases.
>=20
> hmm maybe, but there is no need to much around with speed/status
> from user space. The speed and duplex must be set before user space
> is up.
>=20
> >
> > >
> > > > For the MII interface which is not
> > > > configurable, shouldn't we use the fixed phy support from
Vitaly?
> > >
> > > Well, I think the the fixed phy is great when your eth driver
requires
> > a
> > > PHY, but it is a workaround with extra processing overhead. IMHO
the
> > > best impl. is to make the PHY optional in the eth driver and as
you
> > can
> > > see from the patch, that was really simple.
> >
> > I agree there is overhead. However, it will have the advantage of
> > abstracting all the PHY related stuff out of controller driver.
> >
> > >
> > > An useful extension would be to add a new propety in the DTS to
hold
> > > initial speed and duplex(perhaps extend phy-connection-type). This
> > > would be useful for the fixed driver too as one could derive speed
and
> > > duplex for the fixed phy from that property instead of creating a
> > fixed
> > > phy for each speed and duplex one want to support.
> >
> > I agree that there should be a device node to configure it. The
current
> > fixed phy driver is a little bit too complex to emulate the register
> > access. Maybe it's better to have a null phy driver which just
reads
> > PHY capacity and status from device node.
>=20
> A null phy driver is better than the current fixed phy, I agree.
> Where would you like to put initial speed and duplex? In a fake phy
node
> or in the ethernet node?
I think a fake phy node is better.
- Leo
^ permalink raw reply
* NFS mounting problem in mpc860 based board
From: Barisa kisku @ 2007-07-03 11:23 UTC (permalink / raw)
To: linuxppc-embedded
hi,
I have ported u-boot 1.1.6 in a custom board based on
mpc860.using "tftpboot" command Linux kernel uImage is
downloaded.And it was run with "bootm" command and
controls are transfered to linux properly.
While kernel is mounting root file system through nfs
it is not able to send the message properly.By
observing through "Ethereal" at server machine, no ARP
message is reaching.
Print coming in console of embedded system is:
portmap: "Unable to get port number for nfsd of
server"
But i am able to mount the file system in the given
server from other machine in the LAN.
Again by looking at the status of the BDs it seems
that the ethernet driver is sending message properly
to the LAN.
If anybody has come across this type of problem,
please help me in debugging.
Thanks in advance.
Regards,
Barisa Kisku
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-07-03 11:19 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <989B956029373F45A0B8AF0297081890D8383E@zch01exm26.fsl.freescale.net>
On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Tuesday, July 03, 2007 3:21 PM
> > To: Li Yang-r58472
> > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> >
> > On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org
> > > [mailto:netdev-owner@vger.kernel.org] On
> > > > Behalf Of Joakim Tjernlund
> > > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > > >
> > > > > This patch makes the PHY optional for ucc_geth.c ethernet
> driver.
> > > > > This is useful to support a direct mii to mii connection to, for
> > > example,
> > > > > a onboard swicth.
> > > > >
> > > > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > > > ----
> > > Hi Joakim,
> > >
> > > I'm wondering if we really need to have the option to disable
> phylib.
> >
> > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and mii
> > on UCC3 and UCC4.
> >
> > > Actually we have made phylib selected by default for ucc_geth. Many
> L2
> > > switch chips have the capacity to be controlled. Therefore they can
> be
> > > managed as a phy device.
> >
> > Yes, they can be but why force a PHY impl. when its is of no use? The
> > only thing the eth driver needs from the it is speed and duplex. If
> > these are fixed, you don't need to talk with a PHY.
>
> The driver needs to get and set the link speed/status on runtime (such
> as for ethtool interface). Currently this is implementation through
> phydev interface. IMHO, it will be easier to maintain if we only use
> this standard interface, rather than use different interfaces for
> different cases.
hmm maybe, but there is no need to much around with speed/status
from user space. The speed and duplex must be set before user space
is up.
>
> >
> > > For the MII interface which is not
> > > configurable, shouldn't we use the fixed phy support from Vitaly?
> >
> > Well, I think the the fixed phy is great when your eth driver requires
> a
> > PHY, but it is a workaround with extra processing overhead. IMHO the
> > best impl. is to make the PHY optional in the eth driver and as you
> can
> > see from the patch, that was really simple.
>
> I agree there is overhead. However, it will have the advantage of
> abstracting all the PHY related stuff out of controller driver.
>
> >
> > An useful extension would be to add a new propety in the DTS to hold
> > initial speed and duplex(perhaps extend phy-connection-type). This
> > would be useful for the fixed driver too as one could derive speed and
> > duplex for the fixed phy from that property instead of creating a
> fixed
> > phy for each speed and duplex one want to support.
>
> I agree that there should be a device node to configure it. The current
> fixed phy driver is a little bit too complex to emulate the register
> access. Maybe it's better to have a null phy driver which just reads
> PHY capacity and status from device node.
A null phy driver is better than the current fixed phy, I agree.
Where would you like to put initial speed and duplex? In a fake phy node
or in the ethernet node?
Perhaps this should live in BSP code instead?
Jocke
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-07-03 11:13 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <468A15D9.7010003@semihalf.com>
On Tue, 2007-07-03 at 11:24 +0200, Marian Balakowicz wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> >> I guess that with the above dropping of non-zero based PCI IO ranges
> >> this is not supposed to be working. But does anyone know why?
> >
> > We just fixed that for 64 bits but 32 bits still has the limitation.
> > Note that it's not a very good idea to have your IO range at !0 if
> > you're going to use anything ISA-like, such as a VGA video card or other
> > legacy devices behind a PCI southbridge or SuperIO.
>
> Agree with the zero-based IO range for ISA devices. But, knowing we don't
> have any ISA stuff on board it should be possible to change the IO base.
And you don't plan to ever have a VGA video card ?
> Are you planning on modifications for 32 bits as well?
Not right now, but you are welcome to send a patch :-) Though I fail to
see why you want to do it.
Ben
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Gabriel Paubert @ 2007-07-03 9:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <f778cbc9a05aafa7527bd14f9259aad2@kernel.crashing.org>
On Mon, Jul 02, 2007 at 01:51:42PM +0200, Segher Boessenkool wrote:
> >>+ external-control;
> >>
> >>Really?
> >
> >Well, is anybody actually using eciwx/ecowx?
>
> That's not the point -- the device tree should only
> say "external-control" if the CPU actually supports
> it; AFAIK, that's 601 only.
I wonder whether you are mixing up external control
and direct-store segments (the "T" bit in segment registers).
>From my docs, external control has been supported by many
processors, up to many variants of the 750 and even 7440/7450.
Now I've never seen any hardware which could make use of these
instructions (you'd need a device on the processor bus that
reacts to the special bus cycles generated by the ec[io]wx
instructions, since no host bridge I've ever met handles them.
I've not seen support for external control in the Linux kernel
either (you'd need to setup the EAR SPR and probablly to modify
it on context switches).
OTOH, the direct-store segments were only implemented in the
original 601, 603 (not 603e) and 604 processors (can't remember
about the 604e) and even then the 601 had special features
in this area.
>
> >>+ pci@80000000 {
> >>+ device_type = "pci";
> >>+ compatible = "prep";
> >>
> >>Is that specific enough?
> >
> >On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> >space is smaller and at a higher address.
>
> Right, so it's not; "compatible" should specify the
> model of PCI host bridge, instead.
Well, the PCI host bridge is reprogrammable in a very flexible way
and and I actually wrote a boot loader that reprograms it the
way I wanted address space to look like. I shall send it to
you in a PM (it is quite big, it includes an x86 emulator
which is able to initialize the VGA PMC modules I have by
running the BIOS).
Regards,
Gabriel
^ permalink raw reply
* Re: How to handle patches that cross maintainers?
From: Andrew Morton @ 2007-07-03 9:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: list, linuxppc-dev, Paul Mackerras, Linux Kernel Development
In-Reply-To: <4BEFAFC6-3346-4F29-B1C5-377952E3FBBF@kernel.crashing.org>
On Tue, 3 Jul 2007 04:01:20 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> Andrew,
>
> I was hoping to get your input on how to handle patches that cross
> maintainers. I've got a patch that is pretty PPC specific, but
> happens to touch some drivers as well.
>
> Here's the diffstat to get a rough idea:
>
> arch/powerpc/kernel/io.c | 12 ++++++------
> arch/powerpc/mm/hash_native_64.c | 2 +-
> arch/powerpc/mm/stab.c | 4 ++--
> drivers/ide/pci/scc_pata.c | 4 ++--
> drivers/media/dvb/bt8xx/bt878.h | 5 ++---
> drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
> include/asm-powerpc/system.h | 2 +-
> 7 files changed, 15 insertions(+), 16 deletions(-)
>
> Now, I've had this issue before w/o any good sense on how to handle it.
>
> Suggestions?
>
Well, assuming that all the changes are interdependent and cannot be split
up: send it to the relevant maintainers, gather the acks and merge it up
yourself.
^ permalink raw reply
* [PATCH 2.6.23] 83xx USB platform code rework
From: Li Yang @ 2007-07-03 9:43 UTC (permalink / raw)
To: paulus, galak; +Cc: linuxppc-dev, Li Yang
Add 831x USB platform setup code and rework 834x USB
platform setup code. Move USB platform code to usb.c
for different boards with CPU of the same series to share
the USB initialization code.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
Respin for 2.6.22-rc7. Remove USB_EHCI_FSL selects in Kconfig, as they
will be enabled in USB Kconfig.
arch/powerpc/platforms/83xx/Makefile | 2 +-
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc834x_mds.c | 49 +-------
arch/powerpc/platforms/83xx/mpc83xx.h | 28 ++++-
arch/powerpc/platforms/83xx/usb.c | 181 +++++++++++++++++++++++++++++
5 files changed, 213 insertions(+), 48 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/usb.c
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 31a91b5..5a98f88 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the PowerPC 83xx linux kernel.
#
-obj-y := misc.o
+obj-y := misc.o usb.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC8313_RDB) += mpc8313_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 96970ac..a404910 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -53,6 +53,7 @@ static void __init mpc8313_rdb_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
+ mpc831x_usb_cfg();
}
void __init mpc8313_rdb_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 10394b2..28b3840 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -44,55 +44,16 @@ unsigned long isa_mem_base = 0;
#endif
#define BCSR5_INT_USB 0x02
-/* Note: This is only for PB, not for PB+PIB
- * On PB only port0 is connected using ULPI */
-static int mpc834x_usb_cfg(void)
+static int mpc834xemds_usb_cfg(void)
{
- unsigned long sccr, sicrl;
- void __iomem *immap;
+ struct device_node *np;
void __iomem *bcsr_regs = NULL;
u8 bcsr5;
- struct device_node *np = NULL;
- int port0_is_dr = 0;
-
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr")) != NULL)
- port0_is_dr = 1;
- if ((np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph")) != NULL){
- if (port0_is_dr) {
- printk(KERN_WARNING
- "There is only one USB port on PB board! \n");
- return -1;
- } else if (!port0_is_dr)
- /* No usb port enabled */
- return -1;
- }
-
- immap = ioremap(get_immrbase(), 0x1000);
- if (!immap)
- return -1;
-
- /* Configure clock */
- sccr = in_be32(immap + MPC83XX_SCCR_OFFS);
- if (port0_is_dr)
- sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
- else
- sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
- out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
-
- /* Configure Pin */
- sicrl = in_be32(immap + MPC83XX_SICRL_OFFS);
- /* set port0 only */
- if (port0_is_dr)
- sicrl |= MPC83XX_SICRL_USB0;
- else
- sicrl &= ~(MPC83XX_SICRL_USB0);
- out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
-
- iounmap(immap);
+ mpc834x_usb_cfg();
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
- if (np != 0) {
+ if (np) {
struct resource res;
of_address_to_resource(np, 0, &res);
@@ -134,7 +95,7 @@ static void __init mpc834x_mds_setup_arch(void)
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
#endif
- mpc834x_usb_cfg();
+ mpc834xemds_usb_cfg();
}
static void __init mpc834x_mds_init_IRQ(void)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 9cd03b5..a44e5b1 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -6,6 +6,7 @@
/* System Clock Control Register */
#define MPC83XX_SCCR_OFFS 0xA08
+#define MPC83XX_SCCR_USB_MASK 0x00f00000
#define MPC83XX_SCCR_USB_MPHCM_11 0x00c00000
#define MPC83XX_SCCR_USB_MPHCM_01 0x00400000
#define MPC83XX_SCCR_USB_MPHCM_10 0x00800000
@@ -15,12 +16,31 @@
/* system i/o configuration register low */
#define MPC83XX_SICRL_OFFS 0x114
-#define MPC83XX_SICRL_USB0 0x40000000
-#define MPC83XX_SICRL_USB1 0x20000000
+#define MPC834X_SICRL_USB_MASK 0x60000000
+#define MPC834X_SICRL_USB0 0x40000000
+#define MPC834X_SICRL_USB1 0x20000000
+#define MPC831X_SICRL_USB_MASK 0x00000c00
+#define MPC831X_SICRL_USB_ULPI 0x00000800
/* system i/o configuration register high */
#define MPC83XX_SICRH_OFFS 0x118
-#define MPC83XX_SICRH_USB_UTMI 0x00020000
+#define MPC834X_SICRH_USB_UTMI 0x00020000
+#define MPC831X_SICRH_USB_MASK 0x000000e0
+#define MPC831X_SICRH_USB_ULPI 0x000000a0
+
+/* USB Control Register */
+#define FSL_USB2_CONTROL_OFFS 0x500
+#define CONTROL_UTMI_PHY_EN 0x00000200
+#define CONTROL_REFSEL_48MHZ 0x00000080
+#define CONTROL_PHY_CLK_SEL_ULPI 0x00000400
+#define CONTROL_OTG_PORT 0x00000020
+
+/* USB PORTSC Registers */
+#define FSL_USB2_PORTSC1_OFFS 0x184
+#define FSL_USB2_PORTSC2_OFFS 0x188
+#define PORTSCX_PTW_16BIT 0x10000000
+#define PORTSCX_PTS_UTMI 0x00000000
+#define PORTSCX_PTS_ULPI 0x80000000
/*
* Declaration for the various functions exported by the
@@ -31,5 +51,7 @@ extern int add_bridge(struct device_node *dev);
extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
+extern int mpc834x_usb_cfg(void);
+extern int mpc831x_usb_cfg(void);
#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
new file mode 100644
index 0000000..e7fdf01
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -0,0 +1,181 @@
+/*
+ * Freescale 83xx USB SOC setup code
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc.
+ * Author: Li Yang
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc83xx.h"
+
+
+#ifdef CONFIG_MPC834x
+int mpc834x_usb_cfg(void)
+{
+ unsigned long sccr, sicrl, sicrh;
+ void __iomem *immap;
+ struct device_node *np = NULL;
+ int port0_is_dr = 0, port1_is_dr = 0;
+ const void *prop, *dr_mode;
+
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap)
+ return -ENOMEM;
+
+ /* Read registers */
+ /* Note: DR and MPH must use the same clock setting in SCCR */
+ sccr = in_be32(immap + MPC83XX_SCCR_OFFS) & ~MPC83XX_SCCR_USB_MASK;
+ sicrl = in_be32(immap + MPC83XX_SICRL_OFFS) & ~MPC834X_SICRL_USB_MASK;
+ sicrh = in_be32(immap + MPC83XX_SICRH_OFFS) & ~MPC834X_SICRH_USB_UTMI;
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "phy_type", NULL);
+ if (prop && (!strcmp(prop, "utmi") ||
+ !strcmp(prop, "utmi_wide"))) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ sicrh |= MPC834X_SICRH_USB_UTMI;
+ port1_is_dr = 1;
+ } else if (prop && !strcmp(prop, "serial")) {
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg")) {
+ sicrl |= MPC834X_SICRL_USB0 | MPC834X_SICRL_USB1;
+ port1_is_dr = 1;
+ } else {
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ } else if (prop && !strcmp(prop, "ulpi")) {
+ sicrl |= MPC834X_SICRL_USB0;
+ } else {
+ printk(KERN_WARNING "834x USB PHY type not supported\n");
+ }
+ port0_is_dr = 1;
+ of_node_put(np);
+ }
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-mph");
+ if (np) {
+ sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
+
+ prop = of_get_property(np, "port0", NULL);
+ if (prop) {
+ if (port0_is_dr)
+ printk(KERN_WARNING
+ "834x USB port0 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB0;
+ }
+ prop = of_get_property(np, "port1", NULL);
+ if (prop) {
+ if (port1_is_dr)
+ printk(KERN_WARNING
+ "834x USB port1 can't be used by both DR and MPH!\n");
+ sicrl |= MPC834X_SICRL_USB1;
+ }
+ of_node_put(np);
+ }
+
+ /* Write back */
+ out_be32(immap + MPC83XX_SCCR_OFFS, sccr);
+ out_be32(immap + MPC83XX_SICRL_OFFS, sicrl);
+ out_be32(immap + MPC83XX_SICRH_OFFS, sicrh);
+
+ iounmap(immap);
+ return 0;
+}
+#endif /* CONFIG_MPC834x */
+
+#ifdef CONFIG_PPC_MPC831x
+int mpc831x_usb_cfg(void)
+{
+ u32 temp;
+ void __iomem *immap, *usb_regs;
+ struct device_node *np = NULL;
+ const void *prop;
+ struct resource res;
+ int ret = 0;
+#ifdef CONFIG_USB_OTG
+ const void *dr_mode;
+#endif
+
+ np = of_find_compatible_node(NULL, "usb", "fsl-usb2-dr");
+ if (!np)
+ return -ENODEV;
+ prop = of_get_property(np, "phy_type", NULL);
+
+ /* Map IMMR space for pin and clock settings */
+ immap = ioremap(get_immrbase(), 0x1000);
+ if (!immap) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ /* Configure clock */
+ temp = in_be32(immap + MPC83XX_SCCR_OFFS);
+ temp &= ~MPC83XX_SCCR_USB_MASK;
+ temp |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
+ out_be32(immap + MPC83XX_SCCR_OFFS, temp);
+
+ /* Configure pin mux for ULPI. There is no pin mux for UTMI */
+ if (!strcmp(prop, "ulpi")) {
+ temp = in_be32(immap + MPC83XX_SICRL_OFFS);
+ temp &= ~MPC831X_SICRL_USB_MASK;
+ temp |= MPC831X_SICRL_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRL_OFFS, temp);
+
+ temp = in_be32(immap + MPC83XX_SICRH_OFFS);
+ temp &= ~MPC831X_SICRH_USB_MASK;
+ temp |= MPC831X_SICRH_USB_ULPI;
+ out_be32(immap + MPC83XX_SICRH_OFFS, temp);
+ }
+
+ iounmap(immap);
+
+ /* Map USB SOC space */
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+ usb_regs = ioremap(res.start, res.end - res.start + 1);
+
+ /* Using on-chip PHY */
+ if (!strcmp(prop, "utmi_wide") ||
+ !strcmp(prop, "utmi")) {
+ /* Set UTMI_PHY_EN, REFSEL to 48MHZ */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS,
+ CONTROL_UTMI_PHY_EN | CONTROL_REFSEL_48MHZ);
+ /* Using external UPLI PHY */
+ } else if (!strcmp(prop, "ulpi")) {
+ /* Set PHY_CLK_SEL to ULPI */
+ temp = CONTROL_PHY_CLK_SEL_ULPI;
+#ifdef CONFIG_USB_OTG
+ /* Set OTG_PORT */
+ dr_mode = of_get_property(np, "dr_mode", NULL);
+ if (dr_mode && !strcmp(dr_mode, "otg"))
+ temp |= CONTROL_OTG_PORT;
+#endif /* CONFIG_USB_OTG */
+ out_be32(usb_regs + FSL_USB2_CONTROL_OFFS, temp);
+ } else {
+ printk(KERN_WARNING "831x USB PHY type not supported\n");
+ ret = -EINVAL;
+ }
+
+ iounmap(usb_regs);
+ of_node_put(np);
+ return ret;
+}
+#endif /* CONFIG_PPC_MPC831x */
--
1.5.2.GIT
^ permalink raw reply related
* Re: PCI IO range limitation
From: Marian Balakowicz @ 2007-07-03 9:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1183052634.5521.284.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>> I guess that with the above dropping of non-zero based PCI IO ranges
>> this is not supposed to be working. But does anyone know why?
>
> We just fixed that for 64 bits but 32 bits still has the limitation.
> Note that it's not a very good idea to have your IO range at !0 if
> you're going to use anything ISA-like, such as a VGA video card or other
> legacy devices behind a PCI southbridge or SuperIO.
Agree with the zero-based IO range for ISA devices. But, knowing we don't have any ISA stuff on board it should be possible to change the IO base. Are you planning on modifications for 32 bits as well?
Marian
^ permalink raw reply
* Patches added to for_paulus (queue'd for 2.6.23)
From: Kumar Gala @ 2007-07-03 9:17 UTC (permalink / raw)
To: linuxppc-dev list
I'm still working through the back log of patches related to ppc32/
fsl. If there are patches people want to make sure get into 2.6.23
let me know.
David Gibson (2):
[POWERPC] Split out asm-ppc/mmu.h portions for Freescale Book-E
[POWERPC] Split out asm-ppc/mmu.h portions for PowerPC 8xx
Jon Loeliger (1):
[POWERPC] Replace use of GET_64BIT(prop, i) with of_read_number
().
Kumar Gala (4):
[POWERPC] Reworked interrupt numbers for OpenPIC based
Freescale chips
[POWERPC] Kill pcibios_enable_resources()
[POWERPC] Fix up interrupt senses for MPC85xx boards
[POWERPC] Merge asm-ppc/mmu_context.h into asm-power/
mmu_context.h
Li Yang (1):
[POWERPC] qe_lib: export symbols for QE driver to compile as
module
Roy Zang (4):
[POWERPC] Document the global utilities node define and example
[POWERPC] Fix the node index confusion for SOC
[POWERPC] 85xx: Fix 8548CDS reset bug
[POWERPC] Remove redundant pci_read_irq_line() function for
85xx platform
Timur Tabi (1):
[POWERPC] Fix MAC address entries for 83xx, 85xx, and 86xx
device trees
These two patches are queue, but not in the tree (or will be after
some other depency):
* 83xx USB platform code rework
* bootwrapper: adds cuboot for MPC7448HPC2 platform
- k
^ permalink raw reply
* How to handle patches that cross maintainers?
From: Kumar Gala @ 2007-07-03 9:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel Development
Andrew,
I was hoping to get your input on how to handle patches that cross
maintainers. I've got a patch that is pretty PPC specific, but
happens to touch some drivers as well.
Here's the diffstat to get a rough idea:
arch/powerpc/kernel/io.c | 12 ++++++------
arch/powerpc/mm/hash_native_64.c | 2 +-
arch/powerpc/mm/stab.c | 4 ++--
drivers/ide/pci/scc_pata.c | 4 ++--
drivers/media/dvb/bt8xx/bt878.h | 5 ++---
drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
include/asm-powerpc/system.h | 2 +-
7 files changed, 15 insertions(+), 16 deletions(-)
Now, I've had this issue before w/o any good sense on how to handle it.
Suggestions?
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox