* Re: [RFC] Xilinx SystemACE device driver
From: Grant Likely @ 2007-04-16 16:33 UTC (permalink / raw)
To: Andrei Konovalov
Cc: Peter Korsgaard, Stefan Roese, Rick Moleres, linuxppc-embedded
In-Reply-To: <4623A523.3040705@ru.mvista.com>
On 4/16/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Hi Grant,
>
> Grant Likely wrote:
> > Add support for block device access to the Xilinx SystemACE Compact
> > flash interface
>
> Does the driver support 8-bit bus_width?
>
> Just gave the driver a try on ML300, and my first attempt failed.
> Wonder if it's me having done something wrong, or something the driver doesn't
> handle yet.
Doesn't handle it yet, you'll need to add 8-bit access macros to the
top of the file.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Using Cypress EZ-Host on ML403/5
From: Grant Likely @ 2007-04-16 16:32 UTC (permalink / raw)
To: Peter Mendham; +Cc: linuxppc-embedded
In-Reply-To: <4623A197.6000104@computing.dundee.ac.uk>
On 4/16/07, Peter Mendham <petermendham@computing.dundee.ac.uk> wrote:
> Dear all,
>
> Has anyone had the Cypress EZ-Host chip working as a USB host under
> Linux? It's the one that comes fitted as standard to ML403 and ML405
> boards (probably other Xilinx boards too). If not, can anyone tell me
> where I should start? Any advice at all? Our own embedded device needs
> to have USB host support and we are using an ML40x for development so
> the EZ-Host is the preferred solution as we can prototype it.
>
> Thanks in advance,
> --Peter
It's on my task list to get working. I could certainly use some help.
Xilinx did distrubute some driver code for that host controller a
while back. I've got a copy of it somewhere. I'll try to dig it up
today and let you know where you can get it.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC] Xilinx SystemACE device driver
From: Andrei Konovalov @ 2007-04-16 16:32 UTC (permalink / raw)
To: Grant Likely
Cc: Peter Korsgaard, Stefan Roese, Rick Moleres, linuxppc-embedded
In-Reply-To: <1176600194262-git-send-email-grant.likely@secretlab.ca>
Hi Grant,
Grant Likely wrote:
> Add support for block device access to the Xilinx SystemACE Compact
> flash interface
Does the driver support 8-bit bus_width?
Just gave the driver a try on ML300, and my first attempt failed.
Wonder if it's me having done something wrong, or something the driver doesn't
handle yet.
Thanks,
Andrei
^ permalink raw reply
* Re: Mr Grant Likely's New Patches for 2.6 Kernel and Xilinx FPGA ( Virtex-4 & Virtex-2
From: Grant Likely @ 2007-04-16 16:26 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Linux PPC, Mohammad Sadegh Sadri
In-Reply-To: <4623A002.7080509@ru.mvista.com>
On 4/16/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Grant Likely wrote:
> > No, I did not include TEMAC support. However, I will publish my git
> > tree tomorrow which will include the TEMAC driver.
>
>
> Seems the TEMAC driver is not on your git server yet. Hence the questions.
> Guess this is PLB TEMAC version 3.00a as you wrote auto negotiation is supported.
yup
> Is your driver based on the one by Xilinx (the one from EDK 8.2.02 and the update posted by Rick Moleres)?
Yup, it's just the adapter.c file that Rick posted plus some fixups to
get it to compile in my tree. Nothing really exciting. I'm very
interested in the phylib work that you've done. I hope to take a look
at that in the next day or so. I'm only publishing my tree as a
convienient starting point for those who need it.
Ideally, I'd like to look at doing a full rewrite so it's in a
condition acceptable for mainline, but I don't have time for that at
the moment.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Using Cypress EZ-Host on ML403/5
From: Peter Mendham @ 2007-04-16 16:17 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Has anyone had the Cypress EZ-Host chip working as a USB host under
Linux? It's the one that comes fitted as standard to ML403 and ML405
boards (probably other Xilinx boards too). If not, can anyone tell me
where I should start? Any advice at all? Our own embedded device needs
to have USB host support and we are using an ML40x for development so
the EZ-Host is the preferred solution as we can prototype it.
Thanks in advance,
--Peter
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
^ permalink raw reply
* Re: Patchset to establish sanity in Xilinx Virtex support
From: Peter Mendham @ 2007-04-16 16:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0704160748o5c8ae604ma9ae70afcc649058@mail.gmail.com>
Grant Likely wrote:
> So, I assume that your rootfs is mounted from the CF card, correct?
It is indeed - no problems yet :)
-- Peter
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
^ permalink raw reply
* Re: Mr Grant Likely's New Patches for 2.6 Kernel and Xilinx FPGA ( Virtex-4 & Virtex-2
From: Andrei Konovalov @ 2007-04-16 16:10 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux PPC, Mohammad Sadegh Sadri
In-Reply-To: <528646bc0704150727p1583132ck5455a36782e4dbcc@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> On 4/15/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>> - Do we still new to apply the paulus patch to the main kernel so that we can have hard TEMAC support? Or you have a same program as sys ace for it?
>
> No, I did not include TEMAC support. However, I will publish my git
> tree tomorrow which will include the TEMAC driver.
Seems the TEMAC driver is not on your git server yet. Hence the questions.
What IP versions is your TEMAC driver for?
Guess this is PLB TEMAC version 3.00a as you wrote auto negotiation is supported.
Is your driver based on the one by Xilinx (the one from EDK 8.2.02 and the update posted by Rick Moleres)?
Or is it something written from scratch?
Does it use the "level 1" (OS independent) code from EDK?
Does it support SGDMA, or FIFO mode, or both?
Checksum offloading?
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Segher Boessenkool @ 2007-04-16 15:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C793D7D1-CA26-4DCB-B513-56E927BF6BA9@kernel.crashing.org>
>>>> Since ucc_geth is being migrated to use the phylib, the existing
>>>> (undocumented) 'interface' property is being deprecated in favour
>>>> of unconjoined variations 'max-speed' and 'interface-type'.
>>>
>>> Again, please explain why this information shouldn't
>>> be in the PHY node instead?
>>>
>>
>> Strictly speaking, it should be neither in the UCC node nor the PHY
>> node, as it describes the connection between the two, but..
Connections are never described with separate nodes in
the device tree.
>> the UCC driver utilizes the data itself; the UCC, unlike other network
>> controllers, does not provide interface data in its programming model.
I have no idea what this means?
>> the phy drivers are not of_ drivers. Porting phylib drivers to be of_
>> drivers would break phylib for non-OF arches, e.g. x86.
>
> Nothing stops the code in the UCC driver from grabbing the phy device
> node and pulling the information out if it.
Quite so. This isn't "bad style" either, it is a perfectly
normal thing to do.
> I believe the question is about where the information should truly
> live.
Yeah.
> It would seem to be more of a property of the phy than of the enet
> controller.
Yep. The whole reason why any property is wanted here is
to say what type the PHY is, as the enet controller can
be attached to several kinds. And what type the PHY is
belongs in the PHY node, obviously. In its "compatible"
property to be exact.
Segher
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Kumar Gala @ 2007-04-16 15:34 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070416102533.0f87396f.kim.phillips@freescale.com>
On Apr 16, 2007, at 10:25 AM, Kim Phillips wrote:
> On Fri, 13 Apr 2007 21:02:25 +0200
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
>>> Since ucc_geth is being migrated to use the phylib, the existing
>>> (undocumented) 'interface' property is being deprecated in favour
>>> of unconjoined variations 'max-speed' and 'interface-type'.
>>
>> Again, please explain why this information shouldn't
>> be in the PHY node instead?
>>
>
> Strictly speaking, it should be neither in the UCC node nor the PHY
> node, as it describes the connection between the two, but..
>
> the UCC driver utilizes the data itself; the UCC, unlike other network
> controllers, does not provide interface data in its programming model.
>
> the phy drivers are not of_ drivers. Porting phylib drivers to be of_
> drivers would break phylib for non-OF arches, e.g. x86.
Nothing stops the code in the UCC driver from grabbing the phy device
node and pulling the information out if it.
I believe the question is about where the information should truly
live. It would seem to be more of a property of the phy than of the
enet controller.
- k
^ permalink raw reply
* RE: Linux 2.6 and uboot
From: Clint Thomas @ 2007-04-16 15:27 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0704142053560.5114@poirot.grange>
I tried combining the root file system and kernel images so that I could
just load a single image in u-boot, and I disabled networking in the
kernel config. When I do this, the kernel boots and loads into the shell
no problem. The problem seems to be related to the Marvell PHY, so my
plan is to investigate the IRQs and make sure it isn't getting the same
as another device. Not sure what I'll look for after that, can KGDB step
through the enet drivers on boot?
Clint=20
-----Original Message-----
From: Guennadi Liakhovetski [mailto:g.liakhovetski@gmx.de]=20
Sent: Saturday, April 14, 2007 3:02 PM
To: Clint Thomas
Cc: Kumar Gala; linuxppc-embedded@ozlabs.org
Subject: RE: Linux 2.6 and uboot
On Fri, 13 Apr 2007, Clint Thomas wrote:
> mice: PS/2 mouse device common for all mice i2c /dev entries driver=20
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
>=20
> This is the point where it stops booting.
It might be just the point before root is mounted... That's what I'd
check anyway... I see it has 2 eth interfaces. Can it be that their
order has changed and it's trying the wrong one?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Kim Phillips @ 2007-04-16 15:25 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <95a9680c565aa196a4ef78964ef9dee1@kernel.crashing.org>
On Fri, 13 Apr 2007 21:02:25 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Since ucc_geth is being migrated to use the phylib, the existing
> > (undocumented) 'interface' property is being deprecated in favour
> > of unconjoined variations 'max-speed' and 'interface-type'.
>
> Again, please explain why this information shouldn't
> be in the PHY node instead?
>
Strictly speaking, it should be neither in the UCC node nor the PHY
node, as it describes the connection between the two, but..
the UCC driver utilizes the data itself; the UCC, unlike other network
controllers, does not provide interface data in its programming model.
the phy drivers are not of_ drivers. Porting phylib drivers to be of_
drivers would break phylib for non-OF arches, e.g. x86.
Kim
^ permalink raw reply
* Re: Patchset to establish sanity in Xilinx Virtex support
From: Grant Likely @ 2007-04-16 14:48 UTC (permalink / raw)
To: Peter Mendham; +Cc: linuxppc-embedded
In-Reply-To: <462337AB.5000507@computing.dundee.ac.uk>
On 4/16/07, Peter Mendham <petermendham@computing.dundee.ac.uk> wrote:
> I have applied your patches to a 2.6.20.4 kernel, along with your
> SystemACE driver. I am fully up and running on a simple ML405-based
> system setup with a Uartlite and a SystemACE. (I made the Kconfig
> changes suggested by Dale Farnsworth to my copy). So, thank you very
> much. I appreciate the neatness of your patches, the fact that I now
> have early boot text support on my uartlite port and the fact that
> (somehow) you've shaved a good couple of seconds of my boot time against
> the Xilinx SystemACE driver. Thanks!
Thanks for your feedback.
I'm glad to hear that the driver is faster; I was hoping that was the
case, but I haven't benchmarked it against the Xilinx driver yet.
Please,
please, PLEASE let me know if you have any problems with it. Any
information you can provide me on your usage would be fantastic.
So, I assume that your rootfs is mounted from the CF card, correct?
If so, very cool. I hadn't gotten to that point in my testing, so I
didn't know if that would work. :-)
> In your reply to Mohamed Sadegh Sadri you mentioned that you will be
> publishing your GIT tree with TEMAC support. Two very quick questions:
> where do I find this, and does it support auto-negotiation properly? I
> am having serious problems with auto-negotiation and the various
> flavours of driver out there. It seems like the best long term plan
> would be to use the PHYLIB support to handle the PHY side of things but
> I have only just started looking into this.
I'll be posting it on my git server at http://git.secretlab.ca, and
yes it does support autonegotiation, at least when using the Phy that
is on the ML403 board. I'm going to take a close look a the TEMAC
patch that Andrei recently posted on the list which makes use of phylib. It
looks interesting.
Cheers and thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] mpc5200: lite5200(b) dts fixes
From: Grant Likely @ 2007-04-16 14:06 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070416071010.GI18236@moe.telargo.com>
On 4/16/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> Three trivial DTS fixes:
> Mark Lite5200(b) boards as "mpc5200" compatible. On efika the
> firmware already does that.
> Fix mscan interrupt.
> Fix wakeup GPIO address.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> --- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
> @@ -49,6 +49,7 @@
>
> soc5200@f0000000 {
> model = "fsl,mpc5200b";
> + compatible = "mpc5200";
For completeness, this really should be "mpc5200b,mpc5200". (I should
have caught this earlier; sorry)
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] mpc5200: set efika's device_type to "soc"
From: Grant Likely @ 2007-04-16 13:53 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070416071203.GJ18236@moe.telargo.com>
On 4/16/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> Device type should be "soc" (as in lite5200.dts), compatible is
> already set to "mpc5200".
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/kernel/prom_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: grant.git/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- grant.git.orig/arch/powerpc/kernel/prom_init.c
> +++ grant.git/arch/powerpc/kernel/prom_init.c
> @@ -2142,7 +2142,7 @@ static void __init fixup_device_tree_efi
> 3,12,0, 3,13,0, 3,14,0, 3,15,0 };
> struct subst_entry efika_subst_table[] = {
> { "/", "device_type", prop_cstr("efika") },
> - { "/builtin", "compatible", prop_cstr("soc") },
> + { "/builtin", "device_type", prop_cstr("soc") },
> { "/builtin/ata", "compatible", prop_cstr("mpc5200b-ata\0mpc5200-ata"), },
> { "/builtin/bestcomm", "compatible", prop_cstr("mpc5200b-bestcomm\0mpc5200-bestcomm") },
> { "/builtin/bestcomm", "interrupts", prop_bcomm_irq, sizeof(prop_bcomm_irq) },
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* linux SPI driver for MPX8xxx
From: alfred ss @ 2007-04-16 8:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 674 bytes --]
^ permalink raw reply
* Re: Patchset to establish sanity in Xilinx Virtex support
From: Peter Mendham @ 2007-04-16 8:45 UTC (permalink / raw)
To: linuxppc-embedded
Grant Likely wrote:
> The Virtex support in Linus' tree is a mess. When I ported the common
> devices over to using the platform bus I tried the use the ppc_sys
> infrastructure. ppc_sys is intended for SoCs that have a fixed set of
> devices. It is the *wrong* approach for FPGA support, and I made a
> royal mess of things. This patch set fixes that problem and makes
> a number of other changes that make supporting Virtex boards easier.
>
> I do know that changes to arch/ppc are frowned upon at the moment. However,
> 4xx support in arch/powerpc is not merged yet, and Virtex support needs
> additional work beyond that. I suspect that arch/ppc support for the
> 4xx parts is going to need to stay alive for the next 2-3 kernel releases
> anyway while arch/powerpc support stablizes. Getting these patches in
> will make it easier to support the Virtex ports while I hack on getting
> arch/powerpc stuff figured out.
>
I have applied your patches to a 2.6.20.4 kernel, along with your
SystemACE driver. I am fully up and running on a simple ML405-based
system setup with a Uartlite and a SystemACE. (I made the Kconfig
changes suggested by Dale Farnsworth to my copy). So, thank you very
much. I appreciate the neatness of your patches, the fact that I now
have early boot text support on my uartlite port and the fact that
(somehow) you've shaved a good couple of seconds of my boot time against
the Xilinx SystemACE driver. Thanks!
In your reply to Mohamed Sadegh Sadri you mentioned that you will be
publishing your GIT tree with TEMAC support. Two very quick questions:
where do I find this, and does it support auto-negotiation properly? I
am having serious problems with auto-negotiation and the various
flavours of driver out there. It seems like the best long term plan
would be to use the PHYLIB support to handle the PHY side of things but
I have only just started looking into this.
Thanks again,
-- Peter
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
^ permalink raw reply
* linux SPI driver for MPC8xx-Please help
From: munro biswal @ 2007-04-16 8:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 670 bytes --]
^ permalink raw reply
* it8212F pci card problem in ppc405ep bubinga board
From: tony @ 2007-04-16 7:33 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Dear all
This days I came to a problem like this:
Environment:linux kernel 2.6.20, PPC 405EP bubinga demo board.
We have tested two PCI2IDE cards in this board,A)silicon Image's (cpu:cmd649);B)IT8212F's.The A card with a harddisk,which is well recognised by the demo board;but the same harddisk in B card, can't be recognised by the board,only recognised the PCI card.We trace the kernel,found something different in this funtion in the file linux-2.6.20/drivers/ide/ide-iops.c:
++++++++++++++++++++++++++++++++++++++++++
int ide_wait_not_busy(ide_hwif_t *hwif, unsigned long timeout)
{
u8 stat = 0;
u8 i = 0;
while(timeout--) {
/*
* Turn this into a schedule() sleep once I'm sure
* about locking issues (2.5 work ?).
* hwif->io_ports[IDE_STATUS_OFFSET] = 0xFFEF
*/
mdelay(1);
stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
printk(KERN_INFO "hwif->io_ports[IDE_STATUS_OFFSET] ==> %4x, 222222STAT ==> %4x\n",hwif->io_ports[IDE_STATUS_OFFSET],stat);
if ((stat & BUSY_STAT) == 0){
printk(KERN_INFO "BUSYING................\n");
return 0;
}
/*
* Assume a value of 0xff means nothing is connected to
* the interface and it doesn't implement the pull-down
* resistor on D7.n isa_io_base = e7fee000
*/
if (stat == 0xff){
printk(KERN_INFO "NODEV................ \n");
return -ENODEV;
}
touch_softlockup_watchdog();
touch_nmi_watchdog();
}
return -EBUSY;
}
+++++++++++++++++++++++++++++++++++++++++++++++++++
stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
printk(KERN_INFO "hwif->io_ports[IDE_STATUS_OFFSET] ==> %4x, 222222STAT ==> %4x\n",hwif->io_ports[IDE_STATUS_OFFSET],stat);
By printing this two parameters, we found that the former parameter is the same in two cards,but the value of "stat" varies between the two
cards.A card,stat equals to 0x50;B card,stat equals to 0xFF,and it keeps the same,won't change.
I'm puzzled about this.Is it about the driver of IT821x.c in the kernel?or something else?
Any advise is welcomed.Thank you.
Sincerely
Tony
[-- Attachment #2: Type: text/html, Size: 3446 bytes --]
^ permalink raw reply
* [PATCH] mpc5200: set efika's device_type to "soc"
From: Domen Puncer @ 2007-04-16 7:12 UTC (permalink / raw)
To: linuxppc-embedded
Device type should be "soc" (as in lite5200.dts), compatible is
already set to "mpc5200".
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: grant.git/arch/powerpc/kernel/prom_init.c
===================================================================
--- grant.git.orig/arch/powerpc/kernel/prom_init.c
+++ grant.git/arch/powerpc/kernel/prom_init.c
@@ -2142,7 +2142,7 @@ static void __init fixup_device_tree_efi
3,12,0, 3,13,0, 3,14,0, 3,15,0 };
struct subst_entry efika_subst_table[] = {
{ "/", "device_type", prop_cstr("efika") },
- { "/builtin", "compatible", prop_cstr("soc") },
+ { "/builtin", "device_type", prop_cstr("soc") },
{ "/builtin/ata", "compatible", prop_cstr("mpc5200b-ata\0mpc5200-ata"), },
{ "/builtin/bestcomm", "compatible", prop_cstr("mpc5200b-bestcomm\0mpc5200-bestcomm") },
{ "/builtin/bestcomm", "interrupts", prop_bcomm_irq, sizeof(prop_bcomm_irq) },
^ permalink raw reply
* [PATCH] mpc5200: lite5200(b) dts fixes
From: Domen Puncer @ 2007-04-16 7:10 UTC (permalink / raw)
To: linuxppc-embedded
Three trivial DTS fixes:
Mark Lite5200(b) boards as "mpc5200" compatible. On efika the
firmware already does that.
Fix mscan interrupt.
Fix wakeup GPIO address.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/boot/dts/lite5200.dts | 5 +++--
arch/powerpc/boot/dts/lite5200b.dts | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
Index: grant.git/arch/powerpc/boot/dts/lite5200.dts
===================================================================
--- grant.git.orig/arch/powerpc/boot/dts/lite5200.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200.dts
@@ -49,6 +49,7 @@
soc5200@f0000000 {
model = "fsl,mpc5200";
+ compatible = "mpc5200";
revision = "" // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
@@ -167,7 +168,7 @@
device_type = "mscan";
compatible = "mpc5200-mscan";
cell-index = <1>;
- interrupts = <1 12 0>;
+ interrupts = <2 12 0>;
interrupt-parent = <500>;
reg = <980 80>;
};
@@ -179,7 +180,7 @@
interrupt-parent = <500>;
};
- gpio-wkup@b00 {
+ gpio-wkup@c00 {
compatible = "mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
Index: grant.git/arch/powerpc/boot/dts/lite5200b.dts
===================================================================
--- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -49,6 +49,7 @@
soc5200@f0000000 {
model = "fsl,mpc5200b";
+ compatible = "mpc5200";
revision = ""; // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
@@ -167,7 +168,7 @@
device_type = "mscan";
compatible = "mpc5200b-mscan\0mpc5200-mscan";
cell-index = <1>;
- interrupts = <1 12 0>;
+ interrupts = <2 12 0>;
interrupt-parent = <500>;
reg = <980 80>;
};
@@ -179,7 +180,7 @@
interrupt-parent = <500>;
};
- gpio-wkup@b00 {
+ gpio-wkup@c00 {
compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
^ permalink raw reply
* Re: [PATCH] [0/4] pasemi_mac: fixes and enhancements
From: Olof Johansson @ 2007-04-16 7:05 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070416061654.GB19783@lixom.net>
On Mon, Apr 16, 2007 at 01:16:54AM -0500, Olof Johansson wrote:
> Hi,
>
> The four following patches contain a number of fixes and improvements
> of the pasemi_mac driver:
I just realized that these have been based on top of some OF API changes
that are in paulus' for-2.6.22 tree, and won't build on something based
on current mainline.
I'll fix this up when I respin based on first round of comments in the
next day or so. It should mostly be a matter of doing rename of_$foo()
-> $foo().
-Olof
^ permalink raw reply
* Re: [PATCH] [2/4] pasemi_mac: irq mapping changes
From: Michael Ellerman @ 2007-04-16 6:32 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070416061818.GD19783@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]
On Mon, 2007-04-16 at 01:18 -0500, Olof Johansson wrote:
> Fixes for ethernet IRQ mapping, to move it to the driver instead of in
> the platform setup code.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> Index: powerpc/arch/powerpc/platforms/pasemi/pci.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/platforms/pasemi/pci.c
> +++ powerpc/arch/powerpc/platforms/pasemi/pci.c
> @@ -163,19 +163,6 @@ static void __init pas_fixup_phb_resourc
> }
>
>
> -void __devinit pas_pci_irq_fixup(struct pci_dev *dev)
> -{
> - /* DMA is special, 84 interrupts (128 -> 211), all but 128
> - * need to be mapped by hand here.
> - */
> - if (dev->vendor == 0x1959 && dev->device == 0xa007) {
> - int i;
> - for (i = 129; i < 212; i++)
> - irq_create_mapping(NULL, i);
> - }
> -}
> -
> -
> void __init pas_pci_init(void)
> {
> struct device_node *np, *root;
> Index: powerpc/arch/powerpc/platforms/pasemi/setup.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c
> +++ powerpc/arch/powerpc/platforms/pasemi/setup.c
> @@ -240,5 +240,4 @@ define_machine(pas) {
> .check_legacy_ioport = pas_check_legacy_ioport,
> .progress = pas_progress,
> .machine_check_exception = pas_machine_check_handler,
> - .pci_irq_fixup = pas_pci_irq_fixup,
> };
> Index: powerpc/drivers/net/pasemi_mac.c
> ===================================================================
> --- powerpc.orig/drivers/net/pasemi_mac.c
> +++ powerpc/drivers/net/pasemi_mac.c
> @@ -537,6 +537,9 @@ static irqreturn_t pasemi_mac_tx_intr(in
> static int pasemi_mac_open(struct net_device *dev)
> {
> struct pasemi_mac *mac = netdev_priv(dev);
> + struct device_node *dma_dn = pci_device_to_OF_node(mac->dma_pdev);
> + const unsigned int *prop;
> + int base_irq;
> unsigned int flags;
> int ret;
>
> @@ -600,8 +603,24 @@ static int pasemi_mac_open(struct net_de
> netif_start_queue(dev);
> netif_poll_enable(dev);
>
> - ret = request_irq(mac->dma_pdev->irq + mac->dma_txch,
> - &pasemi_mac_tx_intr, IRQF_DISABLED,
> + /* Interrupts are a bit different for our DMA controller: While
> + * it's got one a regular PCI device header, the interrupt there
> + * is really the base of the range it's using. Each tx and rx
> + * channel has it's own interrupt source.
> + *
> + * The only way to get to the actual hardware interrupt is by
> + * getting it from the device tree, since the kernel has done
> + * virtual remapping of the sources by the time we can get them
> + * from the PCI device.
> + */
> +
> + prop = of_get_property(dma_dn, "interrupts", NULL);
> + base_irq = *prop;
The recently added virq_to_hw() makes it nice 'n easy to reverse map the
hw irq from the pci_dev:
base_irq = virq_to_hw(pdev->irq);
You should also probably check that irq_create_mapping() succeeds, just
to be pedantic.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH dtc take 2] Fix reserve map output for asm format.
From: David Gibson @ 2007-04-16 6:30 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <9979571f0828369de99700eb80c91bee@bga.com>
On Mon, Apr 16, 2007 at 12:08:37AM -0500, Milton Miller wrote:
> On Apr 15, 2007, at 11:16 PM, David Gibson wrote:
> > On Sun, Apr 15, 2007 at 10:49:57PM -0500, Milton Miller wrote:
> >> On Apr 15, 2007, at 7:51 PM, David Gibson wrote:
> >>> On Sun, Apr 15, 2007 at 08:24:06PM -0400, Jerry Van Baren wrote:
> >>>> Milton Miller wrote:
> >>>>> Sometime around Sun Apr 15 12:29:14 EST 2007, Jerry Van Baren
> >>>>> wrote:
> >>>>>> Add extra reserve map slots output for asm format (previously done
> >>>>>> for
> >>>>>> dtb
> >>>>>> output).
>
> >>>>>> and handle dtb (binary)
> >>>>>> input being shorter than the total blob length (result of
> >>>>>> putting
> >>>>>> extra space in the blob).
> >>
> >> That part is still in this patch.
> >>
> >> And I think it should be a separate patch. Its unrelated to filling
> >> in .long 0 for the memory reserve map.
> >
> > Yes.
>
>
> >> That said, one could use .space there I suppose. Its fine the way it
> >> is.
> >
> > I think .space would be the preferred method for adding the padding
> > space at the end in asm format.
>
> For the space at the end, I agree. Or use .org 99b+size with 99: at the
> begining of the struct. The .long 0 was more for memory reserve, where
> the entries might be replaced before assembly.
>
> >>>>> The total_size says how much data should be copied. Anything
> >>>>> less and there is data missing. Assuming zeros is wrong for
> >>>>> most sections (the exception being the memory reserve list
> >>>>> that had a terminating 0 entry within the read portion).
> >>>>>
> >>>>> milton
> >>>>
> >>>> The reason total_size is bigger than the actual size is because I
> >>>> created the blob with extra space using the -S parameter. It is
> >>>> intentionally bigger. The extra space is ignored by dtc when
> >>>> creating a
> >>>> dts/asm format output which is why cmalloc() is unnecessary.
> >>
> >> If this is a case of reading in the files it creates, then its wrong
> >> to have the size created less than total_size. The space needs to be
> >> in the output file. To have it not be in the output is wrong. For
> >> instance it will not be allocated by objcopy nor the linker when its
> >> inserted into the dtb section of the zImage wrapper, which would lead
> >> to
> >> scribbling on memory belonging to something else, or at least
> >> unallocated.
> >> Similar for a firmware that treats the dt_struct as binary data. It
> >> might be loaded just before the initrd for instance.
> >
> > Well, I can see specialized case uses for totalsize greater than
> > stored size: where you know the blob is going to be copied into
> > another staging area with more space, for example.
>
> That can either be done with your embedding script processing and
> noticing
> the zeros at the end or by a special option I guess.
Such a possible future special option was all I had in mind when I
said emitting the zeroes should be default rather than only behaviour.
> >>>> I suppose we could require a -f force but I'm not wild about
> >>>> creating
> >>>> a
> >>>> nanny program. There is nothing wrong with the blob - it parses
> >>>> just
> >>>> fine. If there were problems with the blob contents, other errors
> >>>> would
> >>>> be raised.
>
> You mean like not creating output for -I fs -O dts when there are
> expected properties (files) missing? :-) The kernel booted just
> fine, it was processing /proc/device-tree after all.
> Its probably wrong to check for expected properties when the output
> is dts. At least the checks should not be more than a warning (that
> you may have selected a subtree).
Yes, yes, I know. This all comes back to the need for a substantially
reworked warning/error system.
> >>> I think the warning is fine, but not for exactly the reasons you
> >>> state. Several points:
> >>>
> >>> - At least with v17 input, where it's possible, we probably *should*
> >>> check that an input blob isn't truncated in the middle of the strings
> >>> or structure sections. That should be more than a warning.
> >>
> >> Or check that (1) the memory reserve list is terminated before this
> >> point, (2) the dt_struct has matching node begin and end count and
> >> ends with tree end, and (3) all strings referenced by dt_struct are
> >> before the read size.
> >
> > I think just checking the header lengths of the sub-blocks should be
> > sufficient at this point. Checking that the begin/end count matches
> > in the structure block and that all the string references are valid
> > can, I think, be correctly delayed until we actually parse the
> > structure block.
>
> Checking the sublock lengths is sufficient, but actually more
> restrictive that what I said. And mine works on older formats
> without the size fields. But yes, yours is simpler when the fields
> exist.
>
> Or just leave it an error, fix the output, and make the user fix the
> input. If you took off the zeros, you can add padding from /dev/zero
> or /dev/random or /etc/motd, as you said the data should not be used.
>
> milton
--
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] icecube/lite5200b: wakeup from low-power support
From: Domen Puncer @ 2007-04-16 6:25 UTC (permalink / raw)
To: Grant Likely; +Cc: u-boot-users, Stefan Roese, linuxppc-embedded
In-Reply-To: <528646bc0704152145h44ff5f38wb6c4a1887261f6ed@mail.gmail.com>
On 15/04/07 22:45 -0600, Grant Likely wrote:
> On 4/3/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> >U-Boot part of Lite5200b low power mode support.
> >Puts SDRAM out of self-refresh and transfers control to
> >address saved at physical 0x0.
>
> Looks good; almost there. Only one thing missing... you need to add
> your "Signed-off-by" line. :-) See Documentation/SubmittingPatches
> in the Linux source tree. (You can just reply to this message, and
> whoever merges the patch will add the line to the commit message)
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Stefan; since there is no 5200 custodian, can you please pick up this
> patch once Domen sends a Signed-of-by replay?
I thought Signed-off-by's are Linux specific.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Thanks!
Domen
^ permalink raw reply
* [PATCH] [5/5] pasemi: GPIO MDIO of_platform driver
From: Olof Johansson @ 2007-04-16 6:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070416062634.GB20196@lixom.net>
MDIO driver for PHY's connected via GPIO as on the PA Semi Electra
eval board.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: powerpc/arch/powerpc/platforms/pasemi/gpio_mdio.c
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -0,0 +1,349 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Author: Olof Johansson, PA Semi
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on drivers/net/fs_enet/mii-bitbang.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/sched.h>
+#include <linux/errno.h>
+#include <linux/ioport.h>
+#include <linux/interrupt.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <asm/of_platform.h>
+
+#define DELAY 1
+
+static void __iomem *gpio_regs;
+
+struct gpio_priv {
+ int mdc_pin;
+ int mdio_pin;
+};
+
+#define MDC_PIN(bus) (((struct gpio_priv *)bus->priv)->mdc_pin)
+#define MDIO_PIN(bus) (((struct gpio_priv *)bus->priv)->mdio_pin)
+
+static inline void mdio_lo(struct mii_bus *bus)
+{
+ out_le32(gpio_regs+0x10, 1 << MDIO_PIN(bus));
+}
+
+static inline void mdio_hi(struct mii_bus *bus)
+{
+ out_le32(gpio_regs, 1 << MDIO_PIN(bus));
+}
+
+static inline void mdc_lo(struct mii_bus *bus)
+{
+ out_le32(gpio_regs+0x10, 1 << MDC_PIN(bus));
+}
+
+static inline void mdc_hi(struct mii_bus *bus)
+{
+ out_le32(gpio_regs, 1 << MDC_PIN(bus));
+}
+
+static inline void mdio_active(struct mii_bus *bus)
+{
+ out_le32(gpio_regs+0x20, (1 << MDC_PIN(bus)) | (1 << MDIO_PIN(bus)));
+}
+
+static inline void mdio_tristate(struct mii_bus *bus)
+{
+ out_le32(gpio_regs+0x30, (1 << MDIO_PIN(bus)));
+}
+
+static inline int mdio_read(struct mii_bus *bus)
+{
+ return !!(in_le32(gpio_regs+0x40) & (1 << MDIO_PIN(bus)));
+}
+
+static void clock_out(struct mii_bus *bus, int bit)
+{
+ if (bit)
+ mdio_hi(bus);
+ else
+ mdio_lo(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ mdc_lo(bus);
+}
+
+/* Utility to send the preamble, address, and register (common to read and write). */
+static void bitbang_pre(struct mii_bus *bus, int read, u8 addr, u8 reg)
+{
+ int i;
+
+ /* CFE uses a really long preamble (40 bits). We'll do the same. */
+ mdio_active(bus);
+ for (i = 0; i < 40; i++) {
+ clock_out(bus, 1);
+ }
+
+ /* send the start bit (01) and the read opcode (10) or write (10) */
+ clock_out(bus, 0);
+ clock_out(bus, 1);
+
+ clock_out(bus, read);
+ clock_out(bus, !read);
+
+ /* send the PHY address */
+ for (i = 0; i < 5; i++) {
+ clock_out(bus, (addr & 0x10) != 0);
+ addr <<= 1;
+ }
+
+ /* send the register address */
+ for (i = 0; i < 5; i++) {
+ clock_out(bus, (reg & 0x10) != 0);
+ reg <<= 1;
+ }
+}
+
+static int gpio_mdio_read(struct mii_bus *bus, int phy_id, int location)
+{
+ u16 rdreg;
+ int ret, i;
+ u8 addr = phy_id & 0xff;
+ u8 reg = location & 0xff;
+
+ bitbang_pre(bus, 1, addr, reg);
+
+ /* tri-state our MDIO I/O pin so we can read */
+ mdio_tristate(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ mdc_lo(bus);
+
+ /* read 16 bits of register data, MSB first */
+ rdreg = 0;
+ for (i = 0; i < 16; i++) {
+ mdc_lo(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ mdc_lo(bus);
+ udelay(DELAY);
+ rdreg <<= 1;
+ rdreg |= mdio_read(bus);
+ }
+
+ mdc_hi(bus);
+ udelay(DELAY);
+ mdc_lo(bus);
+ udelay(DELAY);
+
+ ret = rdreg;
+
+ return ret;
+}
+
+static int gpio_mdio_write(struct mii_bus *bus, int phy_id, int location, u16 val)
+{
+ int i;
+
+ u8 addr = phy_id & 0xff;
+ u8 reg = location & 0xff;
+ u16 value = val & 0xffff;
+
+ bitbang_pre(bus, 0, addr, reg);
+
+ /* send the turnaround (10) */
+ mdc_lo(bus);
+ mdio_hi(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ mdc_lo(bus);
+ mdio_lo(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+
+ /* write 16 bits of register data, MSB first */
+ for (i = 0; i < 16; i++) {
+ mdc_lo(bus);
+ if (value & 0x8000)
+ mdio_hi(bus);
+ else
+ mdio_lo(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ value <<= 1;
+ }
+
+ /*
+ * Tri-state the MDIO line.
+ */
+ mdio_tristate(bus);
+ mdc_lo(bus);
+ udelay(DELAY);
+ mdc_hi(bus);
+ udelay(DELAY);
+ return 0;
+}
+
+static int gpio_mdio_reset(struct mii_bus *bus)
+{
+ /*nothing here - dunno how to reset it*/
+ return 0;
+}
+
+
+static int __devinit gpio_mdio_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device *dev = &ofdev->dev;
+ struct device_node *np = ofdev->node;
+ struct device_node *gpio_np;
+ struct mii_bus *new_bus;
+ struct resource res;
+ struct gpio_priv *priv;
+ const unsigned int *prop;
+ int err = 0;
+ int i;
+
+ gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+
+ if (!gpio_np)
+ return -ENODEV;
+
+ err = of_address_to_resource(gpio_np, 0, &res);
+ of_node_put(gpio_np);
+
+ if (err)
+ return -EINVAL;
+
+ if (!gpio_regs)
+ gpio_regs = ioremap(res.start, 0x100);
+
+ if (!gpio_regs)
+ return -EPERM;
+
+ priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
+ if (priv == NULL)
+ return -ENOMEM;
+
+ new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
+
+ if (new_bus == NULL)
+ return -ENOMEM;
+
+ new_bus->name = "pasemi gpio mdio bus",
+ new_bus->read = &gpio_mdio_read,
+ new_bus->write = &gpio_mdio_write,
+ new_bus->reset = &gpio_mdio_reset,
+
+ prop = get_property(np, "reg", NULL);
+ new_bus->id = *prop;
+ new_bus->priv = priv;
+
+ new_bus->phy_mask = 0;
+
+ new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
+ for(i = 0; i < PHY_MAX_ADDR; ++i)
+ new_bus->irq[i] = irq_create_mapping(NULL, 10);
+
+
+ prop = get_property(np, "mdc-pin", NULL);
+ priv->mdc_pin = *prop;
+
+ prop = get_property(np, "mdio-pin", NULL);
+ priv->mdio_pin = *prop;
+
+ new_bus->dev = dev;
+ dev_set_drvdata(dev, new_bus);
+
+ err = mdiobus_register(new_bus);
+
+ if (0 != err) {
+ printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
+ new_bus->name, err);
+ goto bus_register_fail;
+ }
+
+ return 0;
+
+bus_register_fail:
+ kfree(new_bus);
+
+ return err;
+}
+
+
+static int gpio_mdio_remove(struct of_device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(&dev->dev);
+
+ mdiobus_unregister(bus);
+
+ dev_set_drvdata(&dev->dev, NULL);
+
+ kfree(bus->priv);
+ bus->priv = NULL;
+ kfree(bus);
+
+ return 0;
+}
+
+static struct of_device_id gpio_mdio_match[] =
+{
+ {
+ .compatible = "gpio-mdio",
+ },
+ {},
+};
+
+static struct of_platform_driver gpio_mdio_driver =
+{
+ .name = "gpio-mdio-bitbang",
+ .match_table = gpio_mdio_match,
+ .probe = gpio_mdio_probe,
+ .remove = gpio_mdio_remove,
+};
+
+int gpio_mdio_init(void)
+{
+ return of_register_platform_driver(&gpio_mdio_driver);
+}
+
+void gpio_mdio_exit(void)
+{
+ of_unregister_platform_driver(&gpio_mdio_driver);
+}
+
+device_initcall(gpio_mdio_init);
+
+static int __devinit hack_init(void)
+{
+ struct platform_device *pdev;
+
+ pdev = platform_device_register_simple("gpio-mdio-bitbang", 0, NULL, 0);
+
+ return 0;
+}
+late_initcall(hack_init);
Index: powerpc/arch/powerpc/platforms/pasemi/Makefile
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pasemi/Makefile
+++ powerpc/arch/powerpc/platforms/pasemi/Makefile
@@ -1,3 +1,3 @@
-obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o
+obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o gpio_mdio.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += cpufreq.o
^ 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