* Re: [PATCH] MTD for Taco
From: David Gibson @ 2008-01-06 3:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <4780491A.8080006@pikatech.com>
On Sat, Jan 05, 2008 at 10:20:58PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> >> I'm pretty sure that you don't need a board specific mapping driver
> >> for NOR flash. physmap_of should be exactly what you need. You just need
> >> to fill the device tree properties correctly.
> >>
> >
> > Absolutely. We should not be using C-coded maps in arch/powerpc
>
> Ok a couple of questions. How do I find out the size of the NOR flash?
> It was in a global in the ppc arch.
The flash size goes in the "reg" property of the flash node.
> Also, where is the best place to fixup the partitions? We have paritions
> that must be at the top and ones that must be at the bottom, so we
> dynamically setup the partitions based on the NOR size. The NOR size is
> variable.
Ok, you can fix this up in the bootwrapper.
> And is it ok the name the paritions in the dts based on an index? I
> notice others use an address, but since I don't know the address up
> front I just used index numbers.
No, the node name must match the node's "reg" property, which is the
partition's offset. If you're creating the partition nodess on the
fly in the bootwrapper you can get that right there. I'm also hoping
soon to add a function to fixup node names to libfdt, which will then
be usable in the wrapper.
--
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 2/3] Handle absolute pathnames correctly in dtc_open_file.
From: David Gibson @ 2008-01-06 3:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080104211045.GB28991@ld0162-tx32.am.freescale.net>
On Fri, Jan 04, 2008 at 03:10:45PM -0600, Scott Wood wrote:
> Also, free file->dir when freeing file.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> srcpos.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/srcpos.c b/srcpos.c
> index 7340c33..7a0c47e 100644
> --- a/srcpos.c
> +++ b/srcpos.c
> @@ -86,6 +86,16 @@ struct dtc_file *dtc_open_file(const char *fname,
> return file;
> }
>
> + if (fname[0] == '/') {
> + file->file = fopen(fname, "r");
> +
> + if (!file->file)
> + goto out;
> +
> + file->name = strdup(fname);
> + return file;
> + }
> +
> if (!search)
> search = &default_search;
>
> @@ -100,6 +110,7 @@ struct dtc_file *dtc_open_file(const char *fname,
> }
>
> out:
> + free((void *)file->dir);
That cast shouldn't be there.
> free(file);
> return NULL;
> }
> @@ -109,5 +120,6 @@ void dtc_close_file(struct dtc_file *file)
> if (fclose(file->file))
> die("Error closing \"%s\": %s\n", file->name, strerror(errno));
>
> + free((void *)file->dir);
Or here.
--
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] MTD for Taco
From: Sean MacLennan @ 2008-01-06 3:20 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev, david
In-Reply-To: <20080105122542.GH4326@localhost.localdomain>
David Gibson wrote:
>> I'm pretty sure that you don't need a board specific mapping driver
>> for NOR flash. physmap_of should be exactly what you need. You just need
>> to fill the device tree properties correctly.
>>
>
> Absolutely. We should not be using C-coded maps in arch/powerpc
>
>
Ok a couple of questions. How do I find out the size of the NOR flash?
It was in a global in the ppc arch.
Also, where is the best place to fixup the partitions? We have paritions
that must be at the top and ones that must be at the bottom, so we
dynamically setup the partitions based on the NOR size. The NOR size is
variable.
And is it ok the name the paritions in the dts based on an index? I
notice others use an address, but since I don't know the address up
front I just used index numbers.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Josh Boyer @ 2008-01-06 1:43 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1199570068.7291.65.camel@pasglop>
On Sun, 06 Jan 2008 08:54:28 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sat, 2008-01-05 at 15:48 -0600, Josh Boyer wrote:
> > No need for a defconfig update patch. Paul or I usually do a general
> > defconfig update for most boards before the next kernel version. This
> > will get picked up then.
>
> Will it ? I think the defconfigs will stick to the old value.
Put another way, if Kconfig doesn't update it automagically, I'll be
sure to do it myself. :)
josh
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-06 0:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <477EEDFA.9010205@freescale.com>
On Fri, Jan 04, 2008 at 08:39:54PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > And what distinction are you drawing between "first" and "second"
> > here?
>
> Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection,
> but it will never work without an I2S connection.
>
> > Why would the I2S need to scan for codecs? Wouldn't it be up to the
> > codec driver to register with I2S?
>
> Not in ASoC V1. The codec driver registers with ASoC, but the actual
> connection to other devices (e.g. the I2S driver) is done either in the I2S
> driver or in the fabric driver, depending on your mood. And that connection
> is done via a pointer to a structure in the codec driver.
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?
--
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-ibm_iic driver
From: David Gibson @ 2008-01-06 0:12 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Stefan Roese, Sean MacLennan
In-Reply-To: <200801052018.22954.arnd@arndb.de>
On Sat, Jan 05, 2008 at 08:18:22PM +0100, Arnd Bergmann wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
> >
> > Ok. The 44x based .dts files do not list 405-iic, so would I think I
> > will add two compatibility matches, one for 405 and one for 440EP. That
> > way I do not break all the current .dts files. Everybody ok with that?
> >
>
> Sounds good. There are obviously no other drivers that know only
> about 405 but not about 440, so there is no backwards compatibility
> problem. If we ever get a 450/460/470/... that we want to support
> with this driver, it can simply claim to be compatible with 440 or 405
> if not both.
Actually, I think checking for "ibm,iic" is ok. I'm sure there are
other IBM produced i2c chips, but "IIC" is also the name of the ASIC
block that implements this controller. "ibm,iic" in the compatible is
supposed to refer to this family of i2c bridges. Not a great choice
on my part, perhaps, but not so awful as to go changing the existing
device trees I think.
--
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] ibm_newemac: Increase number of default rx-/tx-buffers
From: Benjamin Herrenschmidt @ 2008-01-05 21:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <20080105154805.118eb3d1@vader.jdub.homelinux.org>
On Sat, 2008-01-05 at 15:48 -0600, Josh Boyer wrote:
> No need for a defconfig update patch. Paul or I usually do a general
> defconfig update for most boards before the next kernel version. This
> will get picked up then.
Will it ? I think the defconfigs will stick to the old value.
Ben.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Josh Boyer @ 2008-01-05 21:48 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1199566386.7291.58.camel@pasglop>
On Sun, 06 Jan 2008 07:53:06 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sat, 2008-01-05 at 13:38 +0100, Stefan Roese wrote:
> > On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > > Performance tests done by AMCC have shown that 256 buffer increase the
> > > > performance of the Linux EMAC driver. So let's update the default
> > > > values to match this setup.
> > > >
> > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > > ---
> > >
> > > Do we have the numbers ? Did they also measure latency ?
> >
> > I hoped this question would not come. ;) No, unfortunately I don't have any
> > numbers. Just the recommendation from AMCC to always use 256 buffers.
>
> Ok. Well, it's just a .config option so I suppose the patch is fine. Can
> you also update the defconfigs (at least for the recent AMCC boards) ?
No need for a defconfig update patch. Paul or I usually do a general
defconfig update for most boards before the next kernel version. This
will get picked up then.
josh
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Benjamin Herrenschmidt @ 2008-01-05 20:56 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <477FCADA.2010706@pikatech.com>
On Sat, 2008-01-05 at 13:22 -0500, Sean MacLennan wrote:
> Ok. I thought of that, but most 440EP boards have PCI set and don't need
> the special option. I was worried if I put 440EP someone down the road
> might remove it as "extraneous". We are probably the only 440EP board
> with no PCI ;)
Well, it's different.... PCI is an option that can be enabled ... or
not by the board. In our case, the HAS_OHCI thing is just a switch to
indicate that an OHCI can exist, it's not actually adding code, so
it can be safely left ON whenever a 440EP processor is there, it has
no bloat and won't conflict with the PCI option.
Ben.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Benjamin Herrenschmidt @ 2008-01-05 20:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200801051338.17957.sr@denx.de>
On Sat, 2008-01-05 at 13:38 +0100, Stefan Roese wrote:
> On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > Performance tests done by AMCC have shown that 256 buffer increase the
> > > performance of the Linux EMAC driver. So let's update the default
> > > values to match this setup.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> >
> > Do we have the numbers ? Did they also measure latency ?
>
> I hoped this question would not come. ;) No, unfortunately I don't have any
> numbers. Just the recommendation from AMCC to always use 256 buffers.
Ok. Well, it's just a .config option so I suppose the patch is fine. Can
you also update the defconfigs (at least for the recent AMCC boards) ?
Ben.
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Arnd Bergmann @ 2008-01-05 19:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stefan Roese, Sean MacLennan
In-Reply-To: <477FCA53.8010103@pikatech.com>
On Saturday 05 January 2008, Sean MacLennan wrote:
> > You do break arch/ppc support with this patch. We have to still support
> > arch/ppc a few month, so please don't break this support for now.
> > =A0=20
> Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this?
Yes, but it it's spelled CONFIG_PPC_MERGE, not CONFIG_PPC_MERGED.
Arnd=20
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-01-05 19:18 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <477FCE21.9080808@pikatech.com>
On Saturday 05 January 2008, Sean MacLennan wrote:
>
> Ok. The 44x based .dts files do not list 405-iic, so would I think I
> will add two compatibility matches, one for 405 and one for 440EP. That
> way I do not break all the current .dts files. Everybody ok with that?
>
Sounds good. There are obviously no other drivers that know only
about 405 but not about 440, so there is no backwards compatibility
problem. If we ever get a 450/460/470/... that we want to support
with this driver, it can simply claim to be compatible with 440 or 405
if not both.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Hwmon for Taco
From: Sean MacLennan @ 2008-01-05 18:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1199517763.7291.47.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> +module_exit(ad7414_exit);
>> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
>> +++ drivers/hwmon/taco-dtm.c 2008-01-05 00:06:21.000000000 -0500
>> @@ -0,0 +1,78 @@
>> +/*
>> + * drivers/hwmon/taco-dtm.c
>> + *
>> + * Overview: On the Taco, the fpga controls the fan. This provides
>> + * the temperature to the fpga.
>> + *
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <smaclennan@pikatech.com>
>> + *
>> + * 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/module.h>
>> +#include <linux/kthread.h>
>> +#include <linux/io.h>
>> +
>> +
>> +#define TACO_FPGA_BASE 0x80000000
>>
>
> That should be in the device-tree...
>
> Cheers,
> Ben.
>
>
>
It is in the device tree, I just forgot to update the driver to use it.
Thanks.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <200801051354.11202.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 05 January 2008, Stefan Roese wrote:
>
>>> This is probably not specific enough. I'm rather sure that someone at IBM
>>> has implemented an i2c chip that this driver doesn't support. Maybe
>>>
>>> .compatible = "ibm,405-iic"
>>>
>>> or similar would be a better thing to check for.
>>>
>> .compatible = "ibm,4xx-iic"
>>
>> please, since 405 and 440 have the same I2C controller.
>>
>>
>
> But that's not how compatible properties work -- they should not
> contain wildcards. If you have different devices that are
> backwards compatible, you should list the older one in all
> newer devices, e.g. the 440 can list that it is compatible
> with both ibm,405-iic and ibm,440-iic. If there was an earlier
> 401 that had iic as well, you may even want to include that
> in the device tree.
>
> Arnd <><
>
Ok. The 44x based .dts files do not list 405-iic, so would I think I
will add two compatibility matches, one for 405 and one for 440EP. That
way I do not break all the current .dts files. Everybody ok with that?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <200801051349.34488.sr@denx.de>
Stefan Roese wrote:
>
>> Otherwise, there are two options:
>>
>> 1. duplicate the driver like you suggested
>> 2. make the same driver both a ocp and of_platform, depending on
>> the configuration options.
>>
>> Since most of the driver is untouched by your patch, I'd lean to
>> the second option, but of course, that is more work for you.
>>
>
> I did send a patch for such a combined driver a few months ago:
>
> http://patchwork.ozlabs.org/linuxppc/patch?person=305&id=14181
>
> There were still same open issues and I didn't find the time till now to
> address them. It would be great if you could take care of these issues and
> submit a reworked version.
>
>
I can look into this. Thanks!
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:30 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200801051224.52693.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
>> driver. Since this driver is in the kernel.org kernel, should I rename
>> it and keep the old one around? I notice this was done with the emac
>> network driver.
>>
>
> The interesting question is whether there are any functional users in
> arch/ppc left for the original driver. If all platforms that used
> to use i2c-ibm_iic are broken already, you can can go ahead with
> the conversion. Otherwise, there are two options:
>
> 1. duplicate the driver like you suggested
> 2. make the same driver both a ocp and of_platform, depending on
> the configuration options.
>
> Since most of the driver is untouched by your patch, I'd lean to
> the second option, but of course, that is more work for you.
>
Given Stefan subsequent post, I'll go with the second option.
> Your patch otherwise looks good, but I have a few comments on
> details:
>
>
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -241,7 +241,6 @@ config I2C_PIIX4
>>
>> config I2C_IBM_IIC
>> tristate "IBM PPC 4xx on-chip I2C interface"
>> - depends on IBM_OCP
>> help
>> Say Y here if you want to use IIC peripheral found on
>> embedded IBM PPC 4xx based systems.
>>
>
> In any way, this one now needs to depend on PPC_MERGE now, you
> could even make it depend on PPC_4xx, but it's often better to
> allow building the driver when you can, even if it doesn't make
> sense on your hardware. This gives a better compile coverage.
>
>
>> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
>> index 9b43ff7..838006f 100644
>> --- a/drivers/i2c/busses/i2c-ibm_iic.c
>> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
>> @@ -3,6 +3,10 @@
>> *
>> * Support for the IIC peripheral on IBM PPC 4xx
>> *
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <smaclennan@pikatech.com>
>> + * Converted to an of_platform_driver.
>> + *
>>
>
> Changelogs in the file itself are discouraged. In this case, it's just
> one line, so it's not really harmful.
>
> I think the convention is for copyrights to be in chronological order,
> so you should put the copyright below Eugene's.
>
Ok, I will change it. To be honest, I didn't think it was enough of a
change to actually be worth a copyright, but PIKA is a little touchy
about copyrights right now and I wanted to point out I *only* did the
port. I will remove the changelog and move the copyright notice.
>
>> * Copyright (c) 2003, 2004 Zultys Technologies.
>> * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
>> *
>>
>
>
>
>> + dev->idx = index++;
>> +
>> + dev_set_drvdata(&ofdev->dev, dev);
>> +
>> + if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
>> + (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
>> + printk(KERN_CRIT "ibm-iic%d: Unable to get iic address\n",
>> + dev->idx);
>> ret = -EBUSY;
>> goto fail1;
>> }
>>
>> - if (!(dev->vaddr = ioremap(ocp->def->paddr, sizeof(struct iic_regs)))){
>> + if (!(dev->vaddr = ioremap(addr, sizeof(struct iic_regs)))){
>> printk(KERN_CRIT "ibm-iic%d: failed to ioremap device registers\n",
>> dev->idx);
>> ret = -ENXIO;
>> - goto fail2;
>> + goto fail1;
>> }
>>
>
> Use of_iomap here to save a few lines.
>
>
Cool, I didn't notice that function.
>> init_waitqueue_head(&dev->wq);
>>
>> - dev->irq = iic_force_poll ? -1 : ocp->def->irq;
>> - if (dev->irq >= 0){
>> + if(iic_force_poll)
>> + dev->irq = -1;
>> + else if((dev->irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
>> + printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
>> + dev->irq = -1;
>> + }
>> +
>> + if (dev->irq >= 0) {
>> /* Disable interrupts until we finish initialization,
>> assumes level-sensitive IRQ setup...
>> */
>>
>
> This was in the original driver, but I think it's wrong anyway:
> irq == 0 could be valid, so you shouldn't compare against that
> in general. Use NO_IRQ as a symbolic way to express an invalid
> IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
>
Ok.
>
>> @@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *ocp){
>>
>> if (dev->irq < 0)
>> printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
>> - dev->idx);
>> + dev->idx);
>>
>> /* Board specific settings */
>> - dev->fast_mode = iic_force_fast ? 1 : (iic_data ? iic_data->fast_mode : 0);
>> + dev->fast_mode = iic_force_fast ? 1 : 0;
>>
>
> If there is a good reason to specify fast or slow mode per board, you may want
> to make that a property in the device node.
>
>
Ok. I really don't know, none of the board ports I looked at used fast mode.
>> +
>> +static struct of_device_id ibm_iic_match[] =
>> {
>> - { .vendor = OCP_VENDOR_IBM, .function = OCP_FUNC_IIC },
>> - { .vendor = OCP_VENDOR_INVALID }
>> + { .type = "i2c", .compatible = "ibm,iic", },
>> + {}
>> };
>>
>
> This is probably not specific enough. I'm rather sure that someone at IBM
> has implemented an i2c chip that this driver doesn't support. Maybe
>
> .compatible = "ibm,405-iic"
>
> or similar would be a better thing to check for.
>
> Arnd <><
>
Ok, I will look into this.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Sean MacLennan @ 2008-01-05 18:22 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051026.26870.sr@denx.de>
Stefan Roese wrote:
> On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
>
>>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>>> index 7580aa5..480580c 100644
>>> --- a/drivers/usb/Kconfig
>>> +++ b/drivers/usb/Kconfig
>>> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
>>> # PPC:
>>> default y if STB03xxx
>>> default y if PPC_MPC52xx
>>> + default y if TACO
>>> # MIPS:
>>> default y if SOC_AU1X00
>>> # more:
>>>
>> I think we should instead reference use the 440EP here,
>>
>
> I vote for adding 440EP here.
>
> Best regards,
> Stefan
>
Ok. I thought of that, but most 440EP boards have PCI set and don't need
the special option. I was worried if I put 440EP someone down the road
might remove it as "extraneous". We are probably the only 440EP board
with no PCI ;)
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-05 18:20 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> This patch adds the maps for the taco. It also gets the ndfc.c NAND
>> driver in a compilable state. The map is guaranteed to change since the
>> exact NOR/NAND flash configuration is in flux right now when we found
>> the 256M NAND flash won't boot properly.
>>
>> Currently it configures the NOR in a reasonable fashion and leaves the
>> NAND as one honkin' parition.
>>
>
> <snip>
>
>
>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>> index 1c0e89f..f5e93cf 100644
>> --- a/drivers/mtd/nand/ndfc.c
>> +++ b/drivers/mtd/nand/ndfc.c
>> @@ -24,11 +24,6 @@
>> #include <linux/platform_device.h>
>>
>> #include <asm/io.h>
>> -#ifdef CONFIG_40x
>> -#include <asm/ibm405.h>
>> -#else
>> -#include <asm/ibm44x.h>
>> -#endif
>>
>
> You do break arch/ppc support with this patch. We have to still support
> arch/ppc a few month, so please don't break this support for now.
>
Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this?
>
>
>> struct ndfc_nand_mtd {
>> struct mtd_info mtd;
>> @@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_TACO
>> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
>> + * the taco!
>> + */
>>
>
> We definitely don't want to see such board specific stuff in the common
> NDFC driver. And I really doubt that you need this change for your board.
> We are using this ndfc driver on multiple boards, and all have no
> problems accessing the controller with 32bit read/writes. So you most
> likely have a problem with your board port. Perhaps something with
> with the EBC setup. Please re-check and compare with boards that are know
> to work, like Sequoia.
>
>
Does the Sequoia use a Rev C chip? We had to modify u-boot the same way.
As soon as we do an 8-bit access we get a machine check exception.
To be honest, I don't know what more to check.
>> +static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>> +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
>> +}
>> +
>> +static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
>> len) +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
>> +}
>> +
>> +static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
>> len) +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
>> + return -EFAULT;
>> +
>> + return 0;
>> +}
>> +#else
>>
>
> <snip>
>
>
>> +++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.000000000 -0500
>> @@ -0,0 +1,140 @@
>> +/*
>> + * $Id: $
>> + *
>> + * drivers/mtd/maps/taco.c
>> + *
>> + * Mapping for PIKA Taco flash
>>
>
> I'm pretty sure that you don't need a board specific mapping driver
> for NOR flash. physmap_of should be exactly what you need. You just need
> to fill the device tree properties correctly.
>
Yes, this was copied straight from the PPC port. The whole NOR/NAND
flash is in flux. Marketing really really wants to drop NOR for price
reasons. So I will probably leave this until a final decision is made.
> BTW: I noticed you are using the boot wrapper approach. This is not
> necessary anymore, since the latest U-Boot version has flattened
> device tree support included for 4xx too. Let me know if you have any
> questions about this.
>
I did this port over Christmas and had no access to the hardware guys so
I stayed away from u-boot since I had no way to recover from mistakes. I
hope to make towards the tree image approach but for now the in-kernel
version is much easier for me to work with.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Base Taco Platform support
From: Sean MacLennan @ 2008-01-05 18:10 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1199517639.7291.45.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-04 at 23:49 -0500, Sean MacLennan wrote:
>
>> Here is a patch for the base taco platform. It is against for-2.6.25. It
>> adds basically everything in the arch/powerpc.
>>
>
> Care to tell us a bit more about what Taco is ? Even better is to also
> do that in your Kconfig entry, maybe along with a URL to your web site.
>
> Cheers,
> Ben.
>
>
>
Can do, if I can figure out what it is ;) Basically it is a telephony
appliance geared mainly to low-density asterisk users.
I will update the Kconfig.
Cheers,
Sean
^ permalink raw reply
* Re: Control not branching to the instruction present at resetvec i.e 0xfffffffc
From: Misbah khan @ 2008-01-05 14:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OFD408300E.ACB35FD3-ON852573C6.0072065E-852573C6.007337FA@RFLELECT.COM>
Hi Mr Ravi ...
I suggest you to post a new concern in a new thread ....
----Misbah
ravi.rao wrote:
>
> Hi All,
> We have a custom target board based on PPC-EP405. We just got the
> board from the hardware team .I connected the board to BDI200 and powered
> it on.
> The control came to the resetvec address which is 0xfffffffc. I was able
> to read and write to flash. So I erased the flash and burnt the bootloader
> into flash from 0xfffc0000.
> I verified that the instruction at 0xfffffffc is 4bfc2104 whicis actually
> a branch to 0xfffc2100. Also a memory dump of 0xfffc2100 shows the correct
> code. This proved that
> the uboot bootloader was burnt properly.
> Now when I reset the board the control never reaches 0xfffc2100 i.e for
> some reason the code at the resetvec is not getting executed. Any help or
> pointers to resolve this is greatly appreciated.
> Thanks,
> Ravishankar Govindarao
> RFL Electronics Inc.
> E-mail : Ravi.Rao@rflelect.com
> Voice: 973.334.3100 Ext. 233
> Fax: 973.334.3863
>
> CONFIDENTIALITY NOTE
> This e-mail, including any attachments, may contain confidential and/or
> legally privileged information. The Information is intended only for the
> use of the individual or entity named on this e-mail . If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or the taking of any action in reliance on the contents of
> this transmitted Information is strictly prohibited. Further, if you are
> not the intended recipient, please notify us by return e-mail and delete
> the Information promptly.
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/Reading-a-config-file-in-a-driver-....-tp14591717p14633599.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Stefan Roese @ 2008-01-05 12:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051354.11202.arnd@arndb.de>
On Saturday 05 January 2008, Arnd Bergmann wrote:
> > > This is probably not specific enough. I'm rather sure that someone at
> > > IBM has implemented an i2c chip that this driver doesn't support. May=
be
> > >
> > > =A0=A0=A0=A0=A0=A0.compatible =3D "ibm,405-iic"
> > >
> > > or similar would be a better thing to check for.
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0.compatible =3D "ibm,4xx-iic"
> >
> > please, since 405 and 440 have the same I2C controller.
>
> But that's not how compatible properties work -- they should not
> contain wildcards. If you have different devices that are
> backwards compatible, you should list the older one in all
> newer devices, e.g. the 440 can list that it is compatible
> with both ibm,405-iic and ibm,440-iic. If there was an earlier
> 401 that had iic as well, you may even want to include that
> in the device tree.
OK. Thanks for clarifying.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-01-05 12:54 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051349.34488.sr@denx.de>
On Saturday 05 January 2008, Stefan Roese wrote:
> >
> > This is probably not specific enough. I'm rather sure that someone at I=
BM
> > has implemented an i2c chip that this driver doesn't support. Maybe
> >
> > =A0=A0=A0=A0=A0=A0.compatible =3D "ibm,405-iic"
> >
> > or similar would be a better thing to check for.
>=20
> =A0=A0=A0=A0=A0=A0=A0=A0.compatible =3D "ibm,4xx-iic"
>=20
> please, since 405 and 440 have the same I2C controller.
>=20
But that's not how compatible properties work -- they should not
contain wildcards. If you have different devices that are
backwards compatible, you should list the older one in all
newer devices, e.g. the 440 can list that it is compatible
with both ibm,405-iic and ibm,440-iic. If there was an earlier
401 that had iic as well, you may even want to include that
in the device tree.
Arnd <><
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Stefan Roese @ 2008-01-05 12:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, Sean MacLennan
In-Reply-To: <200801051224.52693.arnd@arndb.de>
On Saturday 05 January 2008, Arnd Bergmann wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
> > I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
> > driver. Since this driver is in the kernel.org kernel, should I rename
> > it and keep the old one around? I notice this was done with the emac
> > network driver.
>
> The interesting question is whether there are any functional users in
> arch/ppc left for the original driver. If all platforms that used
> to use i2c-ibm_iic are broken already, you can can go ahead with
> the conversion.
No, they are not all broken. We still have to support arch/ppc till mid of=
=20
this year.
> Otherwise, there are two options:=20
>
> 1. duplicate the driver like you suggested
> 2. make the same driver both a ocp and of_platform, depending on
> the configuration options.
>
> Since most of the driver is untouched by your patch, I'd lean to
> the second option, but of course, that is more work for you.
I did send a patch for such a combined driver a few months ago:
http://patchwork.ozlabs.org/linuxppc/patch?person=3D305&id=3D14181
There were still same open issues and I didn't find the time till now to=20
address them. It would be great if you could take care of these issues and=
=20
submit a reworked version.
> Your patch otherwise looks good, but I have a few comments on
>
> details:
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -241,7 +241,6 @@ config I2C_PIIX4
> > =A0
> > =A0config I2C_IBM_IIC
> > =A0=A0=A0=A0=A0=A0=A0=A0tristate "IBM PPC 4xx on-chip I2C interface"
> > -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> > =A0=A0=A0=A0=A0=A0=A0=A0help
> > =A0=A0=A0=A0=A0=A0=A0=A0 =A0Say Y here if you want to use IIC periphera=
l found on
> > =A0=A0=A0=A0=A0=A0=A0=A0 =A0embedded IBM PPC 4xx based systems.
>
> In any way, this one now needs to depend on PPC_MERGE now, you
> could even make it depend on PPC_4xx, but it's often better to
> allow building the driver when you can, even if it doesn't make
> sense on your hardware. This gives a better compile coverage.
>
> > diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
> > b/drivers/i2c/busses/i2c-ibm_iic.c index 9b43ff7..838006f 100644
> > --- a/drivers/i2c/busses/i2c-ibm_iic.c
> > +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> > @@ -3,6 +3,10 @@
> > =A0 *
> > =A0 * Support for the IIC peripheral on IBM PPC 4xx
> > =A0 *
> > + * Copyright (c) 2008 PIKA Technologies
> > + * Sean MacLennan <smaclennan@pikatech.com>
> > + * =A0Converted to an of_platform_driver.
> > + *
>
> Changelogs in the file itself are discouraged. In this case, it's just
> one line, so it's not really harmful.
>
> I think the convention is for copyrights to be in chronological order,
> so you should put the copyright below Eugene's.
>
> > =A0 * Copyright (c) 2003, 2004 Zultys Technologies.
> > =A0 * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.ne=
t>
> > =A0 *
> >
> >
> > +=A0=A0=A0=A0=A0=A0=A0dev->idx =3D index++;
> > +
> > +=A0=A0=A0=A0=A0=A0=A0dev_set_drvdata(&ofdev->dev, dev);
> > +
> > +=A0=A0=A0=A0=A0=A0=A0if((addrp =3D of_get_address(np, 0, NULL, NULL)) =
=3D=3D NULL ||
> > +=A0=A0=A0=A0=A0=A0=A0 =A0 (addr =3D of_translate_address(np, addrp)) =
=3D=3D OF_BAD_ADDR) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_CRIT "ibm-iic=
%d: Unable to get iic
> > address\n", +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =A0 dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -EBUSY;
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> > =A0=A0=A0=A0=A0=A0=A0=A0}
> > =A0
> > -=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(ocp->def->paddr, siz=
eof(struct
> > iic_regs)))){ +=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(addr, =
sizeof(struct
> > iic_regs)))){ printk(KERN_CRIT "ibm-iic%d: failed to ioremap device
> > registers\n", dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -ENXIO;
> > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail2;
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> > =A0=A0=A0=A0=A0=A0=A0=A0}
>
> Use of_iomap here to save a few lines.
>
> > =A0=A0=A0=A0=A0=A0=A0=A0init_waitqueue_head(&dev->wq);
> > =A0
> > -=A0=A0=A0=A0=A0=A0=A0dev->irq =3D iic_force_poll ? -1 : ocp->def->irq;
> > -=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0){
> > +=A0=A0=A0=A0=A0=A0=A0if(iic_force_poll)
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D -1;
> > +=A0=A0=A0=A0=A0=A0=A0else if((dev->irq =3D irq_of_parse_and_map(np, 0)=
) =3D=3D NO_IRQ) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_ERR __FILE__ =
": irq_of_parse_and_map
> > failed\n"); +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D =
=2D1;
> > +=A0=A0=A0=A0=A0=A0=A0}
> > +
> > +=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0) {
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/* Disable interrupts u=
ntil we finish initialization,
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 assumes level-sens=
itive IRQ setup...
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 */
>
> This was in the original driver, but I think it's wrong anyway:
> irq =3D=3D 0 could be valid, so you shouldn't compare against that
> in general. Use NO_IRQ as a symbolic way to express an invalid
> IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
>
> > @@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device
> > *ocp){=20
> > =A0=A0=A0=A0=A0=A0=A0=A0if (dev->irq < 0)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_WARNING "ib=
m-iic%d: using polling mode\n",
> > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d=
ev->idx);
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0 dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> > =A0=A0=A0=A0=A0=A0=A0=A0/* Board specific settings */
> > -=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_force_fast ? 1 : (iic_data=
?
> > iic_data->fast_mode : 0); +=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_=
force_fast ? 1 :
> > 0;
>
> If there is a good reason to specify fast or slow mode per board, you may
> want to make that a property in the device node.
>
> > +
> > +static struct of_device_id ibm_iic_match[] =3D
> > =A0{
> > -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_IBM, .function =3D OCP_F=
UNC_IIC },
> > -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_INVALID }
> > +=A0=A0=A0=A0=A0=A0=A0{ .type =3D "i2c", .compatible =3D "ibm,iic", },
> > +=A0=A0=A0=A0=A0=A0=A0{}
> > =A0};
>
> This is probably not specific enough. I'm rather sure that someone at IBM
> has implemented an i2c chip that this driver doesn't support. Maybe
>
> .compatible =3D "ibm,405-iic"
>
> or similar would be a better thing to check for.
.compatible =3D "ibm,4xx-iic"
please, since 405 and 440 have the same I2C controller.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Stefan Roese @ 2008-01-05 12:38 UTC (permalink / raw)
To: benh; +Cc: netdev, linuxppc-dev
In-Reply-To: <1199528388.7291.55.camel@pasglop>
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > Performance tests done by AMCC have shown that 256 buffer increase the
> > performance of the Linux EMAC driver. So let's update the default
> > values to match this setup.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
>
> Do we have the numbers ? Did they also measure latency ?
I hoped this question would not come. ;) No, unfortunately I don't have any
numbers. Just the recommendation from AMCC to always use 256 buffers.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: David Gibson @ 2008-01-05 12:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051041.18173.sr@denx.de>
On Sat, Jan 05, 2008 at 10:41:17AM +0100, Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
> > +++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.000000000 -0500
> > @@ -0,0 +1,140 @@
> > +/*
> > + * $Id: $
> > + *
> > + * drivers/mtd/maps/taco.c
> > + *
> > + * Mapping for PIKA Taco flash
>
> I'm pretty sure that you don't need a board specific mapping driver
> for NOR flash. physmap_of should be exactly what you need. You just need
> to fill the device tree properties correctly.
Absolutely. We should not be using C-coded maps in arch/powerpc
--
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
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