* [PATCH] [POWERPC] Remove unused variabls from drivers/ide/ppc/pmac.c
From: Stephen Rothwell @ 2007-09-17 4:06 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, linux-ide
Removes these warnings:
/home/sfr/kernels/linus/drivers/ide/ppc/pmac.c: In function 'pmac_ide_dma_check':
/home/sfr/kernels/linus/drivers/ide/ppc/pmac.c:1807: warning: unused variable 'map'
/home/sfr/kernels/linus/drivers/ide/ppc/pmac.c:1805: warning: unused variable 'pmif'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/ide/ppc/pmac.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index 4b13cd9..f19eb6d 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1802,9 +1802,7 @@ pmac_ide_dma_check(ide_drive_t *drive)
{
struct hd_driveid *id = drive->id;
ide_hwif_t *hwif = HWIF(drive);
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
int enable = 1;
- int map;
drive->using_dma = 0;
if (drive->media == ide_floppy)
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] fix xmon input on 440
From: Olof Johansson @ 2007-09-17 3:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard, David Gibson
In-Reply-To: <1189999598.17593.18.camel@localhost.localdomain>
On Sun, Sep 16, 2007 at 10:26:37PM -0500, Josh Boyer wrote:
> On Mon, 2007-09-17 at 12:52 +1000, David Gibson wrote:
> > On Fri, Sep 14, 2007 at 03:44:47PM -0500, Hollis Blanchard wrote:
> > > Implement udbg_getc() for 440, which fixes xmon input.
> > > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> > Acked-by: David Gibson <david@gibson.dropbear.id.au>
> >
>
> I fixed up the whitespace issues and applied it to my tree. Oh, and
> comments don't need semi-colons ;)
Well, there's a big difference between:
while (foo)
/* moof */;
return bar;
and:
while (foo)
/* moof */
return bar;
:-)
^ permalink raw reply
* Re: [PATCH] fix xmon input on 440
From: Josh Boyer @ 2007-09-17 3:26 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070917025223.GG32725@localhost.localdomain>
On Mon, 2007-09-17 at 12:52 +1000, David Gibson wrote:
> On Fri, Sep 14, 2007 at 03:44:47PM -0500, Hollis Blanchard wrote:
> > Implement udbg_getc() for 440, which fixes xmon input.
> > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
I fixed up the whitespace issues and applied it to my tree. Oh, and
comments don't need semi-colons ;)
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: David Gibson @ 2007-09-17 3:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <44C67E7D-CF8F-4B14-A883-4632CCE99D1A@kernel.crashing.org>
On Fri, Sep 14, 2007 at 01:11:07PM -0500, Kumar Gala wrote:
>
> On Sep 14, 2007, at 11:28 AM, Jon Loeliger wrote:
>
> > Kumar Gala wrote:
> >
> >> Someone really needs to add some macro/preprocessor magic into DTC
> >> so this is made a lot simpler.
> >> - k
> >
> > Kumar,
> >
> > I am seriously contemplating this problem.
> > The trick is, I need to quit with the whole
> > Power Point Programmer job title for a bit...
>
> I'm all for both of these things. You working on getting DTC to have
> some macro/include ability and you not being a powerpoint
> programmer.
Maybe we should make some time for all of us to get on IRC together to
discuss this?
I had some thoughts on what I think is a reasonably sane variable /
expression system for dtc. Not quite the same thing as a macro
system, but a good start on one.
Although I also think we should still consider if using m4 as a
preprocessor (with some preloaded macros) could be sufficient. Adding
expression and macro functions to dtc itself would be rather a lot of
work.
--
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] fix xmon input on 440
From: David Gibson @ 2007-09-17 2:52 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1189802687.20625.74.camel@basalt>
On Fri, Sep 14, 2007 at 03:44:47PM -0500, Hollis Blanchard wrote:
> Implement udbg_getc() for 440, which fixes xmon input.
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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 3/4] 4xx: Convert Walnut flash mappings to new binding
From: David Gibson @ 2007-09-17 2:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <addcdbe0ab5b83aa58fc4e7df37b0925@kernel.crashing.org>
On Sat, Sep 15, 2007 at 09:20:10PM +0200, Segher Boessenkool wrote:
> >> Maybe we can have U-Boot add the partition information if it's
> >> missing in the device tree, and extend the mtdparts command in U-Boot
> >> to add / adjust settings so they match what is defined in U-Boot.
> >
> > That would be great for newer U-Boots. For existing older ones, it
> > doesn't really solve the problem. But then again, there's no way to
> > possibly define all the partitioning schemes people may have adopted to
> > their needs on their boards. And I believe that is why David has
> > RedBoot and command line partitioning override what is in the DTS
> > today.
>
> Yeah, partitioning information really doesn't belong in the device
> tree -- with the possible exception of the partitions that the
> firmware (uboot in this case) needs to know about anyway.
Indeed - but we had just the same problem, only worse, with the old
approach of hardcoded, configured-in flash maps.
> You *can* put all partitioning info in the device tree, but that
> doesn't mean you *should* :-)
--
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 3/4] 4xx: Convert Walnut flash mappings to new binding
From: David Gibson @ 2007-09-17 2:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070915150901.AC712247CE@gemini.denx.de>
On Sat, Sep 15, 2007 at 05:09:01PM +0200, Wolfgang Denk wrote:
> In message <1189866379.17593.2.camel@localhost.localdomain> Josh Boyer wrote:
> > On Sat, 2007-09-15 at 05:23 +0200, Stefan Roese wrote:
> ...
> > > There are not only Bamboo board running PIBS, but running U-Boot too. How
> > > should we handle this different FLASH partitioning? Same goes for Ebony too
> > > btw.
> >
> > That's a good question. I'm working on making the NOR flash show up for
> > Bamboo right now, and I had intended to just leave the partition
> > subnodes missing.
>
> Maybe we can have U-Boot add the partition information if it's
> missing in the device tree, and extend the mtdparts command in U-Boot
> to add / adjust settings so they match what is defined in U-Boot.
>
> Stefan, what do you think?
If U-Boot is supplying a device tree, it should certainly make the
partition information match its own idea of the partitions.
For older non-device-tree away u-boot, I guess we'll have to make the
cuboot and treeboot wrappers mangle the device tree differently to
correct the partition information.
I suspect the easiest way to do this will be for the dts to contain
both treeboot and u-boot partition info, and have the wrapper delete
or nop the nodes for the other firmware.
--
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] i2c: devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-09-17 1:32 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916162747.GV23573@pengutronix.de>
On Sun, Sep 16, 2007 at 06:27:47PM +0200, Robert Schwebel wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
>
> Can we agree on one nomenclature - either i2c or iic?
The dual nomenclature comes because linux uses i2c throughout the
subsystem, but all the hardware documentation refers to the controller
ASIC in question as 'IIC'. So I think the convention is that 'i2c' is
used to refer to the type of bus in general, 'iic' is used to refer to
this particular type of bus controller.
--
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] i2c: devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-09-17 1:31 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916185330.GA32314@gate.ebshome.net>
On Sun, Sep 16, 2007 at 11:53:30AM -0700, Eugene Surovegin wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > This patch reworks existing ibm-iic driver to an of_platform_device
> > and enables it to talk to device tree directly. The ocp quirks are
> > completely removed by this patch.
> >
> > This is done to enable I2C support for the PPC4xx platforms now
> > being moved from arch/ppc (OCP) to arch/powerpc (of). The first board
> > using this driver will be the AMCC Sequoia (PPC440EPx).
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> > 2nd try with some cleanups. Please let me know if there still are some
> > problems.
> >
> > Thanks.
> >
> > commit 5748f81ff53277fa5c16de815b7d6b172ca284e9
> > tree 8284b3f1c836eb6eb06ee6882ee13b9e8f6cbb6b
> > parent d0174640eedc1cd756754f03afe2dbb3d56de74e
> > author Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> > committer Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> >
> > drivers/i2c/busses/Kconfig | 12 -
> > drivers/i2c/busses/Makefile | 1
> > drivers/i2c/busses/i2c-ibm_iic.h | 3
> > drivers/i2c/busses/i2c-ibm_of.c | 858 ++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 873 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called i2c-ibm_iic.
> > +
> > +config I2C_IBM_OF
> > + tristate "IBM PPC 4xx on-chip I2C interface"
> > + depends on PPC_MERGE
> > help
> > Say Y here if you want to use IIC peripheral found on
> > embedded IBM PPC 4xx based systems.
> > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> > index 5b752e4..0cd0bac 100644
> > --- a/drivers/i2c/busses/Makefile
> > +++ b/drivers/i2c/busses/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> > obj-$(CONFIG_I2C_I801) += i2c-i801.o
> > obj-$(CONFIG_I2C_I810) += i2c-i810.o
> > obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
> > +obj-$(CONFIG_I2C_IBM_OF) += i2c-ibm_of.o
> > obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
> > obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o
> > obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
>
> Hmm, I just noticed that you basically added a copy of existing
> driver with small changes to support OF while keeping OCP one.
>
> Why not just add OF support to the existing code (under some ifdef),
> and then remove OCP support as soon as ppc -> powerpc transition is
> finished? Why have two almost identical code in the tree?
>
> I also personally don't like this _iic -> _of name change (you
> removed peripheral name and added something which has nothing to do
> with iic, I never heard of OF peripheral in 4xx chips). Whether you
> use OCP or OF to pass a little information is quite irrelevant to the
> iic driver operation.
I concur on this point. Especially since on 4xx the device tree will
generally be a flattened device tree which is vaguely OF-like, but not
from an actual Open Firmware.
> If you insist on this approach, please add yourself as a maintainer of
> this code, because I'm not going to support two identical copies of my
> code in the kernel tree.
>
--
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: FDT for Microblaze and PPC405
From: Michal Simek @ 2007-09-14 19:35 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
In-Reply-To: <fa686aa40709111009j64925edag511078d88ff904c@mail.gmail.com>
Hi,
I made EDK tcl script for generation DTS test scructure for FDT. Script
support Microblaze and PowerPC 405.
Script was primary built for generation U-BOOT configs files for Microblaze.
For Microblaze can you generate both files (FDT and U-BOOT).
For PowerPC can you generate only DTS file. Generation U-BOOT configs files
aren't supported yet. Script ends after generation DTS.
Script has 2.00.a mark.
It is available at www.monstr.eu.
Cheers,
Michal Simek
> On 9/11/07, Michal Simek <Monstr@seznam.cz> wrote:
>> Hi Grant,
>
> (Adding linuxppc-dev mailing list to CC list because we're discussing
> FDT issues)
>
>> I made EDK repository file for generation dts file from Xilinx design. I
>> sent it to Wolfgang and Steve this week.
>> It is in the same config file as I use for configuration Microblaze for
>> U-BOOT. If you want I can send you this repository files.
>
> Yes, please do.
>
>> And I start with redesigning Linux kernel for Microblaze. I ported some
>> peripherals as timer and intc etc.
>> But for some peripherals I need better configuration.
>>
>> I have no time to read information about fdt. Can you tell me what labels
>> I can use?
>
> Steve has already done a bunch of work in this direction on
> microblaze, I would converse with him.
>
>>
>> For example emaclite driver needs information about turning on/off ping
>> pong buffer...
>>
>> I would like to make this properly.
>
> FDT design is just as much art as it is science. It takes taste and
> judgement to desgin a nice set of bindings. Your best option is to
> draft something and post it to the linuxppc-embedded mailing list for
> review.
>
>>
>> And second question is on early console logs and timers setting. I read
>> about aliases in FDT. I think that aliases can cover this setting.
>> For example my design contain 4 serial line and I would like to know
>> which serial line is set on early console.
>
> You use the chosen node for this. In the chosen node, you add a
> property called "linux,stdout-path" which holds the path to your
> console. You can look at examples under arch/powerpc/boot/dts/*
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.15/1002 - Release Date:
> 11.9.2007 05:46
>
>
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jeff Mock @ 2007-09-16 18:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161125u15dcd02cj300c0e3a7fda4c0a@mail.gmail.com>
Jon Smirl wrote:
> On 9/16/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> Another problem...
>>
>> Ifconfig eth0 down
>>
>> hangs the system.
>> I'll try debugging it.
>
> The hang is something to do with lockd in NFS, it doesn't appear to
> have anything to do with fec. I think I need to build more of NFS into
> my kernel.
>
I think the NFS hang has something to do with not having a copy of
portmap running. I've had this happen with other embedded systems, and
can usually work around it by using the "-o nolock" option when doing
the NFS mount.
jeff
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 19:05 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709150855k6ba6dc8fye9762817566208b4@mail.gmail.com>
This adjustment to the error counting is in the Efika patches and not
in yours, should it be in yours too?
--- a/drivers/net/fec_mpc52xx/fec.c 2007-05-30 16:04:50.000000000 +0200
+++ b/drivers/net/fec_mpc52xx/fec.c 2007-05-30 16:09:02.000000000 +0200
@@ -411,7 +411,9 @@
stats->rx_bytes = in_be32(&fec->rmon_r_octets);
stats->rx_packets = in_be32(&fec->rmon_r_packets);
- stats->rx_errors = stats->rx_packets - in_be32(&fec->ieee_r_frame_ok);
+ stats->rx_errors = stats->rx_packets - (
+ in_be32(&fec->ieee_r_frame_ok) +
+ in_be32(&fec->rmon_r_mc_pkt));
stats->tx_bytes = in_be32(&fec->rmon_t_octets);
stats->tx_packets = in_be32(&fec->rmon_t_packets);
stats->tx_errors = stats->tx_packets - (
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-09-16 18:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <200709161107.23309.sr@denx.de>
On Sun, Sep 16, 2007 at 11:07:23AM +0200, Stefan Roese wrote:
> On Saturday 15 September 2007, Vitaly Bordug wrote:
> > > Where is dev->clkdiv initialized?
> > >
> > > My original version used iic_clkdiv() to calculate correct devider
> > > based on OPB frequency. Did you even test this code?
>
> Yes, I tested it successfully on the Sequoia eval board.
I meant with the scope attached to i2c lines to verify correct i2c
speed.
--
Eugene
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:54 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <20070916185041.GY23573@pengutronix.de>
On 9/16/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 02:38:55PM -0400, Jon Smirl wrote:
> > Any idea why my DNS servers are getting set up from DHCP?
>
> Well, check your DHCP server config :-)
My x86/arm boxes are getting it ok from same server.
>
> Robert
> --
> Pengutronix - Linux Solutions for Science and Industry
> Entwicklungszentrum Nord http://www.pengutronix.de
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-09-16 18:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200709161352.03459.sr@denx.de>
On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> This patch reworks existing ibm-iic driver to an of_platform_device
> and enables it to talk to device tree directly. The ocp quirks are
> completely removed by this patch.
>
> This is done to enable I2C support for the PPC4xx platforms now
> being moved from arch/ppc (OCP) to arch/powerpc (of). The first board
> using this driver will be the AMCC Sequoia (PPC440EPx).
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
> 2nd try with some cleanups. Please let me know if there still are some
> problems.
>
> Thanks.
>
> commit 5748f81ff53277fa5c16de815b7d6b172ca284e9
> tree 8284b3f1c836eb6eb06ee6882ee13b9e8f6cbb6b
> parent d0174640eedc1cd756754f03afe2dbb3d56de74e
> author Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> committer Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
>
> drivers/i2c/busses/Kconfig | 12 -
> drivers/i2c/busses/Makefile | 1
> drivers/i2c/busses/i2c-ibm_iic.h | 3
> drivers/i2c/busses/i2c-ibm_of.c | 858 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 873 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 9f3a4cd..12453e2 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -220,7 +220,17 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on !PPC_MERGE
> + help
> + Say Y here if you want to use IIC peripheral found on
> + embedded IBM PPC 4xx based systems.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-ibm_iic.
> +
> +config I2C_IBM_OF
> + tristate "IBM PPC 4xx on-chip I2C interface"
> + depends on PPC_MERGE
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 5b752e4..0cd0bac 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> obj-$(CONFIG_I2C_I801) += i2c-i801.o
> obj-$(CONFIG_I2C_I810) += i2c-i810.o
> obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
> +obj-$(CONFIG_I2C_IBM_OF) += i2c-ibm_of.o
> obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
> obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o
> obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
Hmm, I just noticed that you basically added a copy of existing
driver with small changes to support OF while keeping OCP one.
Why not just add OF support to the existing code (under some ifdef),
and then remove OCP support as soon as ppc -> powerpc transition is
finished? Why have two almost identical code in the tree?
I also personally don't like this _iic -> _of name change (you
removed peripheral name and added something which has nothing to do
with iic, I never heard of OF peripheral in 4xx chips). Whether you
use OCP or OF to pass a little information is quite irrelevant to the
iic driver operation.
If you insist on this approach, please add yourself as a maintainer of
this code, because I'm not going to support two identical copies of my
code in the kernel tree.
--
Eugene
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Robert Schwebel @ 2007-09-16 18:50 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161138m177edb1k99e5df120e9ca9df@mail.gmail.com>
On Sun, Sep 16, 2007 at 02:38:55PM -0400, Jon Smirl wrote:
> Any idea why my DNS servers are getting set up from DHCP?
Well, check your DHCP server config :-)
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:38 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <20070916183446.GX23573@pengutronix.de>
On 9/16/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 02:25:09PM -0400, Jon Smirl wrote:
> > Next I'll look at how the pcm030 supplies an Ethernet address. It has
> > an EEPROM on the board that holds it. Is this something that can be
> > read from of?
>
> If you use our u-boot port, the mac addresses are being written by
> u-boot and should already be present when linux comes in.
Your right, it is already there.
Any idea why my DNS servers are getting set up from DHCP?
>
> Robert
> --
> Pengutronix - Linux Solutions for Science and Industry
> Entwicklungszentrum Nord http://www.pengutronix.de
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Robert Schwebel @ 2007-09-16 18:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161125u15dcd02cj300c0e3a7fda4c0a@mail.gmail.com>
On Sun, Sep 16, 2007 at 02:25:09PM -0400, Jon Smirl wrote:
> Next I'll look at how the pcm030 supplies an Ethernet address. It has
> an EEPROM on the board that holds it. Is this something that can be
> read from of?
If you use our u-boot port, the mac addresses are being written by
u-boot and should already be present when linux comes in.
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:25 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161100i456c176ay664d89ac638c9958@mail.gmail.com>
On 9/16/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Another problem...
>
> Ifconfig eth0 down
>
> hangs the system.
> I'll try debugging it.
The hang is something to do with lockd in NFS, it doesn't appear to
have anything to do with fec. I think I need to build more of NFS into
my kernel.
My DNS servers are not getting set up, but that's probably an issue
with the distro I'm using.
I did some big copy commands and fec seems to working ok.
Next I'll look at how the pcm030 supplies an Ethernet address. It has
an EEPROM on the board that holds it. Is this something that can be
read from of?
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:00 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161005u4f400ab7wb1bf55dac1b45193@mail.gmail.com>
Another problem...
Ifconfig eth0 down
hangs the system.
I'll try debugging it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 17:05 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161000i64622520i77caa00e56abc7a8@mail.gmail.com>
[ 1.309662] net eth0: attached phy 0 to driver Generic PHY
[ 2.316013] Sending DHCP requests .<6>PHY: f0003000:00 - Link is Up
- 100/Full
[ 4.392000] ., OK
[ 7.100005] IP-Config: Got DHCP answer from 192.168.1.200, my
address is 192.168.1.5
[ 7.108154] IP-Config: Complete:
[ 7.111247] device=eth0, addr=192.168.1.5,
mask=255.255.255.0, gw=192.168.1.200,
[ 7.119249] host=MPC, domain=home, nis-domain=(none),
[ 7.124811] bootserver=192.168.1.200, rootserver=192.168.1.4, rootpath=
DHCP wants to print "Sending DHCP requests .., OK"
But the interrupt from the link coming up printed "<6>PHY: f0003000:00
- Link is Up - 100/Full"
The <6> is visible since it wasn't on the beginning of a line.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 17:00 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709150855k6ba6dc8fye9762817566208b4@mail.gmail.com>
On 9/15/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/15/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 15/09/07 00:28 -0400, Jon Smirl wrote:
> > > On 9/14/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > This patch doesn't seem to working quite right on my hardware (Phytec
> > > > pcm030). At boot I get a long pause.
> > >
> > > It also doesn't compile if CONFIG_FEC_MPC52xx_MDIO is undefined.
> >
> > Right, darn.
> > Try this one: http://coderock.org/tmp/fec-v3rc1/
>
> 0.776407] 0x00f40000-0x00f80000 : "oftree"
> [ 0.782101] 0x00f80000-0x01000000 : "space"
> [ 0.788100] TCP cubic registered
> [ 0.791427] NET: Registered protocol family 1
> [ 0.795904] NET: Registered protocol family 17
> [ 1.305579] f0003000:00 not found
> [ 1.308985] net eth0: phy_connect failed
> [ 1.312961] net eth0: fec_init_phy failed
> [ 1.317188] IP-Config: Failed to open eth0
> [ 1.321362] IP-Config: No network devices available.
> [ 1.326973] Looking up port of RPC 100003/3 on 192.168.1.4
This fixes the problem....
diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c
index 922e9a8..c4442e0 100644
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -1087,11 +1087,13 @@ static struct of_platform_driver mpc52xx_fec_driver = {
/* ======================================================================== */
/* Module */
/* ======================================================================== */
+extern int fec_mdio_init(void);
+void fec_mdio_exit(void);
static int __init
mpc52xx_fec_init(void)
{
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
int ret;
ret = fec_mdio_init();
if (ret) {
@@ -1106,7 +1108,7 @@ static void __exit
mpc52xx_fec_exit(void)
{
of_unregister_platform_driver(&mpc52xx_fec_driver);
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
fec_mdio_exit();
#endif
}
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Josh Boyer @ 2007-09-16 16:37 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916162747.GV23573@pengutronix.de>
On Sun, 16 Sep 2007 18:27:47 +0200
Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
>
> Can we agree on one nomenclature - either i2c or iic?
>
> > + This driver can also be built as a module. If so, the module
> > + will be called i2c-ibm_iic.
>
> Are these drivers the same functionality (host i2c driver for 4xx)? If
> yes, shouldn't all in-tree users be migrated over and the old style
> driver be removed (with deprecation period)?
They are the same functionality, but for two different versions of the
arch. The old one is arch/ppc, the new one is arch/powerpc. 4xx is
being migrated to arch/powerpc so eventually what you say will happen.
The arch/ppc tree is scheduled for removal in June of 2008. For now,
we need both drivers since not everything in 4xx has moved yet.
josh
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Robert Schwebel @ 2007-09-16 16:27 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200709161352.03459.sr@denx.de>
On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 9f3a4cd..12453e2 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -220,7 +220,17 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on !PPC_MERGE
> + help
> + Say Y here if you want to use IIC peripheral found on
> + embedded IBM PPC 4xx based systems.
Can we agree on one nomenclature - either i2c or iic?
> + This driver can also be built as a module. If so, the module
> + will be called i2c-ibm_iic.
Are these drivers the same functionality (host i2c driver for 4xx)? If
yes, shouldn't all in-tree users be migrated over and the old style
driver be removed (with deprecation period)?
> +#define DBG_LEVEL 0
> +
> +#ifdef DBG
> +#undef DBG
> +#endif
> +
> +#ifdef DBG2
> +#undef DBG2
> +#endif
> +
> +#if DBG_LEVEL > 0
> +# define DBG(f,x...) printk(KERN_DEBUG "ibm-iic" f, ##x)
> +#else
> +# define DBG(f,x...) ((void)0)
> +#endif
> +#if DBG_LEVEL > 1
> +# define DBG2(f,x...) DBG(f, ##x)
> +#else
> +# define DBG2(f,x...) ((void)0)
> +#endif
Any reason why you can't use pr_debug?
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: [PATCH 4/7] powerpc: BestComm core support for Freescale MPC5200
From: Kumar Gala @ 2007-09-16 16:07 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Grant Likely, Paul Mackerras, PowerPC dev list
In-Reply-To: <1189940011134-git-send-email-tnt@246tNt.com>
On Sep 16, 2007, at 5:53 AM, Sylvain Munaut wrote:
> This patch adds support for the core of the BestComm API
> for the Freescale MPC5200(b). The BestComm engine is a
> microcode-controlled / tasks-based DMA used by several
> of the onchip devices.
>
> Setting up the tasks / memory allocation and all common
> low level functions are handled by this patch.
> The specifics details of each tasks and their microcode
> are split-out in separate patches.
>
> This is not the official API, but a much cleaner one.
> (hopefully)
>
> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> arch/powerpc/platforms/Kconfig | 2 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/bestcomm/Kconfig | 18 +
> arch/powerpc/sysdev/bestcomm/Makefile | 8 +
> arch/powerpc/sysdev/bestcomm/bestcomm.c | 657 +++++++++++++++
> +++++++++++
> arch/powerpc/sysdev/bestcomm/bestcomm.h | 136 ++++++
> arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 325 +++++++++++++
> arch/powerpc/sysdev/bestcomm/sram.c | 177 +++++++
> arch/powerpc/sysdev/bestcomm/sram.h | 54 +++
> 9 files changed, 1378 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig
> create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
> create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c
> create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h
this version still doesn't address comments made back in may:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
Also, what about splitting bestcomm.c into bestcomm_task.c &
bestcomm_drv.c (or just bestcomm.c) or something like that. It seems
'private API' isn't really the proper term.
- 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