* Re: [PATCH]: [MPC5200] (v2) Add ATA DMA support
From: Grant Likely @ 2008-07-04 3:26 UTC (permalink / raw)
To: Tim Yamin; +Cc: linuxppc-dev
In-Reply-To: <792f5f410807030835q4589a27eh4b7d13e93e922a5e@mail.gmail.com>
On Thu, Jul 03, 2008 at 04:35:27PM +0100, Tim Yamin wrote:
> There's also what I believe to be a hardware bug if you have high levels
> of BestComm ATA DMA activity along with heavy LocalPlus Bus activity;
> the address bus seems to sometimes get corrupted with ATA commands while
> the LocalPlus Bus operation is still active (i.e. Chip Select is asserted).
>
> I've asked Freescale about this but have not received a reply yet -- if
> anybody from Freescale has any ideas please contact me; I can supply some
> analyzer traces if needed. Therefore, for now, do not enable DMA if you
> need reliable LocalPlus Bus unless you do a fixup in your driver as
> follows:
>
> Locking example:
>
> while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
> {
> struct bcom_task_2 *tsk = pata_mpc52xx_ata_dma_task;
>
> if(bcom_buffer_done_2(tsk))
> return 1;
> }
>
> return 0;
>
> (Save the return value to `flags`)
>
> Unlocking example:
>
> if(flags == 0)
> clear_bit(0, &pata_mpc52xx_ata_dma_lock);
>
One more thing. For this description to be of any use, it needs to be
documented where somebody will actually see it. The commit message is
great for describing *why* a change is needed, but it's not seen
so much after the change is merged.
This description should probably be added to the header comment block of
the ATA driver, and it should be talked about in the Kconfig help text
too.
g.
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Grant Likely @ 2008-07-04 3:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, anton
In-Reply-To: <1215136480.7849.12.camel@localhost>
On Fri, Jul 04, 2008 at 11:54:40AM +1000, Michael Ellerman wrote:
> On Fri, 2008-07-04 at 11:50 +1000, Tony Breeds wrote:
> > On Thu, Jul 03, 2008 at 05:59:32PM -0700, Andrew Morton wrote:
> >
> > > Nope, the only account matching .*ppc.* and .*power.* is
> > > platform_ppc-32@kernel-bugs.osdl.org. (I have elevated bugzilla perms
> > > so I can can query the users list) (everyone should have this - it's
> > > handy).
> > >
> > > There is a category "Platform Specific/Hardware"/PPC-64. Those go to
> > > anton@samba.org.
> >
> > Can you get this changed to platform_ppc-64@kernel-bugs.osdl.org
> > (obvisouly this'll need to be created)?
>
> Just to be clear, Anton will still fix all the bugs single-handedly in
> his sleep .. we'll just be able to watch :)
He needs to use one of his hands? I though Anton just dreamt about the
bug and it would flee in terror.
g.
^ permalink raw reply
* RE: [PATCH v2 4/5] spi: Add OF binding support for SPI busses
From: Chen Gong @ 2008-07-04 3:54 UTC (permalink / raw)
To: Grant Likely
Cc: david-b, linuxppc-dev, fabrizio.garetto, linux-kernel,
spi-devel-general
In-Reply-To: <20080703010313.26187.99119.stgit@trillian.secretlab.ca>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Grant Likely
> Sent: 2008?7?3? 9:03
> To: linuxppc-dev@ozlabs.org;=20
> spi-devel-general@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Cc: david-b@pacbell.net; fabrizio.garetto@gmail.com
> Subject: [PATCH v2 4/5] spi: Add OF binding support for SPI busses
>=20
> From: Grant Likely <grant.likely@secretlab.ca>
>=20
> This patch adds support for populating an SPI bus based on data in the
> OF device tree. This is useful for powerpc platforms which use the
> device tree instead of discrete code for describing platform layout.
>=20
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>=20
> drivers/of/Kconfig | 6 +++
> drivers/of/Makefile | 1 +
> drivers/of/of_spi.c | 88=20
> ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of_spi.h | 18 ++++++++++
> 4 files changed, 113 insertions(+), 0 deletions(-)
>=20
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 3a7a11a..edd6e92 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -13,3 +13,9 @@ config OF_I2C
> depends on PPC_OF && I2C
> help
> OpenFirmware I2C accessors
> +
> +config OF_SPI
> + def_tristate SPI
> + depends on OF && PPC_OF && SPI
> + help
> + OpenFirmware SPI accessors
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 548772e..4c3c6f8 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -2,3 +2,4 @@ obj-y =3D base.o
> obj-$(CONFIG_OF_DEVICE) +=3D device.o platform.o
> obj-$(CONFIG_OF_GPIO) +=3D gpio.o
> obj-$(CONFIG_OF_I2C) +=3D of_i2c.o
> +obj-$(CONFIG_OF_SPI) +=3D of_spi.o
> diff --git a/drivers/of/of_spi.c b/drivers/of/of_spi.c
> new file mode 100644
> index 0000000..ed0c807
> --- /dev/null
> +++ b/drivers/of/of_spi.c
> @@ -0,0 +1,88 @@
> +/*
> + * SPI OF support routines
> + * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + *
> + * Support routines for deriving SPI device attachments from=20
> the device
> + * tree.
> + */
> +
> +#include <linux/of.h>
> +#include <linux/device.h>
> +#include <linux/spi/spi.h>
> +#include <linux/of_spi.h>
> +
> +/**
> + * of_register_spi_devices - Register child devices onto the SPI bus
> + * @master: Pointer to spi_master device
> + * @np: parent node of SPI device nodes
> + *
> + * Registers an spi_device for each child node of 'np' which=20
> has a 'reg'
> + * property.
> + */
> +void of_register_spi_devices(struct spi_master *master,=20
> struct device_node *np)
> +{
> + struct spi_device *spi;
> + struct device_node *nc;
> + const u32 *prop;
> + const char *sprop;
> + int rc;
> + int len;
> +
> + for_each_child_of_node(np, nc) {
> + /* Alloc an spi_device */
> + spi =3D spi_alloc_device(master);
> + if (!spi) {
> + dev_err(&master->dev, "spi_device alloc=20
> error for %s\n",
> + nc->full_name);
> + continue;
> + }
> +
> + /* Device address */
> + prop =3D of_get_property(nc, "reg", &len);
> + if (!prop || len < sizeof(*prop)) {
> + dev_err(&master->dev, "%s has no 'reg'=20
> property\n",
> + nc->full_name);
> + continue;
> + }
> + spi->chip_select =3D *prop;
> +
> + /* Mode (clock phase/polarity/etc.) */
> + if (of_find_property(nc, "spi,cpha", NULL))
> + spi->mode |=3D SPI_CPHA;
> + if (of_find_property(nc, "spi,cpol", NULL))
> + spi->mode |=3D SPI_CPOL;
so becuase in function spi_alloc_deive, spi is allocated by kzalloc,
how about writing as follows:
/* Mode (clock phase/polarity/etc.) */
prop =3D of_get_property(nc, "spi,cpha", NULL))
if (prop)
spi->mode |=3D *prop;
prop =3D of_get_property(nc, "spi,cpol", NULL))
if (prop)
spi->mode |=3D *prop;
> +
> + /* Device speed */
> + prop =3D of_get_property(nc, "max-speed", &len);
> + if (!prop || len < sizeof(*prop)) {
> + dev_err(&master->dev, "%s has no=20
> 'max-speed' property\n",
> + nc->full_name);
> + continue;
> + }
> + spi->max_speed_hz =3D *prop;
> +
> + /* IRQ */
> + spi->irq =3D irq_of_parse_and_map(nc, 0);
> +
> + /* Select device driver */
> + sprop =3D of_get_property(nc, "linux,modalias", &len);
> + if (sprop && len > 0)
> + strncpy(spi->modalias, sprop, KOBJ_NAME_LEN);
> + else
> + strncpy(spi->modalias, "spidev", KOBJ_NAME_LEN);
> +
how about writing as follows:
if (sprop && len > 0)
strncpy(spi->modalias, sprop, KOBJ_NAME_LEN -
1);
else
strncpy(spi->modalias, "spidev", KOBJ_NAME_LEN -
1);
^ permalink raw reply
* RE: [PATCH v2 3/5] of-bindings: Add binding documentation for SPI bussesand devices
From: Chen Gong @ 2008-07-04 3:59 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, spi-devel-general, linux-kernel
Cc: david-b, fabrizio.garetto
In-Reply-To: <20080703010308.26187.23037.stgit@trillian.secretlab.ca>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Grant Likely
> Sent: 2008?7?3? 9:03
> To: linuxppc-dev@ozlabs.org;=20
> spi-devel-general@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Cc: david-b@pacbell.net; fabrizio.garetto@gmail.com
> Subject: [PATCH v2 3/5] of-bindings: Add binding=20
> documentation for SPI bussesand devices
>=20
> From: Grant Likely <grant.likely@secretlab.ca>
>=20
> Add documentation about how to describe SPI busses in the device tree.
>=20
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>=20
> Documentation/powerpc/booting-without-of.txt | 60=20
> ++++++++++++++++++++++++++
> 1 files changed, 60 insertions(+), 0 deletions(-)
>=20
> diff --git a/Documentation/powerpc/booting-without-of.txt=20
> b/Documentation/powerpc/booting-without-of.txt
> index 1d2a772..7d3564f 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -58,6 +58,7 @@ Table of Contents
> o) Xilinx IP cores
> p) Freescale Synchronous Serial Interface
> q) USB EHCI controllers
> + t) SPI busses
> =20
> VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2870,6 +2871,65 @@ platforms are moved over to use the=20
> flattened-device-tree model.
> reg =3D <0xe8000000 32>;
> };
> =20
> + t) SPI (Serial Peripheral Interface) busses
> +
> + SPI busses can be described with a node for the SPI master device
> + and a set of child nodes for each SPI slave on the bus. For this
> + discussion, it is assumed that the system's SPI controller is in
> + SPI master mode. This binding does not describe SPI controllers
> + in slave mode.
> +
> + The SPI master node requires the following properties:
> + - #address-cells - number of cells required to define a=20
> chip select
> + address on the SPI bus.
> + - #size-cells - should be zero.
> + - compatible - name of SPI bus controller following=20
> generic names
> + recommended practice.
> + No other properties are required in the SPI bus node. =20
> It is assumed
> + that a driver for an SPI bus device will understand that=20
> it is an SPI bus.
> + However, the binding does not attempt to define the=20
> specific method for
> + assigning chip select numbers. Since SPI chip select=20
> configuration is
> + flexible and non-standardized, it is left out of this=20
> binding with the
> + assumption that board specific platform code will be=20
> used to manage
> + chip selects. Individual drivers can define additional=20
> properties to
> + support describing the chip select layout.
> +
> + SPI slave nodes must be children of the SPI master node and can
> + contain the following properties.
> + - reg - (required) chip select address of device.
> + - compatible - (required) name of SPI device=20
> following generic names
> + recommended practice
> + - max-speed - (required) Maximum SPI clocking=20
> speed of device in Hz
> + - spi,cpol - (optional) Device requires inverse=20
> clock polarity
> + - spi,cpha - (optional) Device requires shifted=20
> clock phase
> + - linux,modalias - (optional, Linux specific) Force=20
> binding of SPI device
> + to a particular spi_device driver. =20
> Useful for changing
> + driver binding between spidev and a=20
> kernel SPI driver.
> +
How about adding a "model" property to describe actual devie type.
Such as using a "sst25vf040b" device with spi-interface, we can
use model=3D"sst25vf040b" to describe it.
^ permalink raw reply
* Re: [PATCH v2 3/5] of-bindings: Add binding documentation for SPI bussesand devices
From: Grant Likely @ 2008-07-04 4:05 UTC (permalink / raw)
To: Chen Gong
Cc: david-b, linuxppc-dev, fabrizio.garetto, linux-kernel,
spi-devel-general
In-Reply-To: <58A20A281BAF1047B4EAE68DE5C0BDC2010121B9@zch01exm21.fsl.freescale.net>
On Fri, Jul 04, 2008 at 11:59:07AM +0800, Chen Gong wrote:
> > + - reg - (required) chip select address of device.
> > + - compatible - (required) name of SPI device
> > following generic names
> > + recommended practice
> > + - max-speed - (required) Maximum SPI clocking
> > speed of device in Hz
> > + - spi,cpol - (optional) Device requires inverse
> > clock polarity
> > + - spi,cpha - (optional) Device requires shifted
> > clock phase
> > + - linux,modalias - (optional, Linux specific) Force
> > binding of SPI device
> > + to a particular spi_device driver.
> > Useful for changing
> > + driver binding between spidev and a
> > kernel SPI driver.
> > +
>
> How about adding a "model" property to describe actual devie type.
> Such as using a "sst25vf040b" device with spi-interface, we can
> use model="sst25vf040b" to describe it.
That's what "compatible" is for. First value in the compatible list is
the actual device, followed by devices it is compatible with. In
your particular example, the value would be "sst,sst25vf040b" so that it
follows device tree conventions.
g.
^ permalink raw reply
* Re: [PATCH v2 4/5] spi: Add OF binding support for SPI busses
From: Grant Likely @ 2008-07-04 4:17 UTC (permalink / raw)
To: Chen Gong
Cc: david-b, linuxppc-dev, fabrizio.garetto, linux-kernel,
spi-devel-general
In-Reply-To: <58A20A281BAF1047B4EAE68DE5C0BDC2010121B7@zch01exm21.fsl.freescale.net>
On Fri, Jul 04, 2008 at 11:54:57AM +0800, Chen Gong wrote:
> Grant Likely wrote:
> > + /* Mode (clock phase/polarity/etc.) */
> > + if (of_find_property(nc, "spi,cpha", NULL))
> > + spi->mode |= SPI_CPHA;
> > + if (of_find_property(nc, "spi,cpol", NULL))
> > + spi->mode |= SPI_CPOL;
>
> so becuase in function spi_alloc_deive, spi is allocated by kzalloc,
> how about writing as follows:
> /* Mode (clock phase/polarity/etc.) */
> prop = of_get_property(nc, "spi,cpha", NULL))
> if (prop)
> spi->mode |= *prop;
> prop = of_get_property(nc, "spi,cpol", NULL))
> if (prop)
> spi->mode |= *prop;
spi,cpha and spi,cpol are defined as empty properties. The presence of
the property in the node means I need to set the flag in the spi_device.
> > + /* Select device driver */
> > + sprop = of_get_property(nc, "linux,modalias", &len);
> > + if (sprop && len > 0)
> > + strncpy(spi->modalias, sprop, KOBJ_NAME_LEN);
> > + else
> > + strncpy(spi->modalias, "spidev", KOBJ_NAME_LEN);
> > +
> how about writing as follows:
>
> if (sprop && len > 0)
> strncpy(spi->modalias, sprop, KOBJ_NAME_LEN -
> 1);
> else
> strncpy(spi->modalias, "spidev", KOBJ_NAME_LEN -
> 1);
Actually, neither are very good. What it should really be is:
if (sprop && len > 0)
strlcpy(spi->modalias, sprop, sizeof (spi->modalias));
else
strlcpy(spi->modalias, "spidev", sizeof (spi->modalias));
This ensures that the string is always null terminated and always the
right size.
... But the whole argument is a bit moot. The fact that I even defined
a "linux,modalias" property is a great big hairy hack that I would
never want my mother to see. Instead, I need a method to bind to an SPI
driver based on the compatible list. Jon Smirl has done some work
in this regard for i2c, but I haven't looked at it very deeply, and so
do not at all understand it (yet).
Thanks for the comments.
g.
^ permalink raw reply
* Re: New fsl device bindings file
From: Grant Likely @ 2008-07-04 4:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <BE229B94-773D-4FA8-AFD0-E46F5887F8D3@kernel.crashing.org>
On Thu, Jul 03, 2008 at 01:38:17PM -0500, Kumar Gala wrote:
>
> On Jul 3, 2008, at 1:34 PM, Grant Likely wrote:
>
>> On Thu, Jul 3, 2008 at 12:28 PM, Scott Wood <scottwood@freescale.com>
>> wrote:
>>> Documentation/powerpc/device-tree/fsl/cpm.txt
>>> Documentation/powerpc/device-tree/fsl/cpm/uart.txt
>>> Documentation/powerpc/device-tree/fsl/tsec.txt
>>> Documentation/powerpc/device-tree/interrupts.txt
>>> Documentation/powerpc/device-tree/dtb.txt
>>
>> May I suggest moving it to Documentation/of-bindings/ instead? Some
>> of these bindings (granted, not the fsl ones) will be used by
>> non-powerpc platforms (sparc, microblaze).
>
> I think the powerpc bindings should still be under Docs/powerpc/of-
> bindings/
>
> It makes it cleaner in that each arch/sub-arch maintainer can maintain
> Docs/<arch>/of-bindings and we can all vet changes to Docs/of-bindings
Personally, I think it would still be better to keep everything in one
place, even if large parts of it are arch specific. I think it would
encourage people to look across architecture boundaries when looking for
examples of how to document device tree bindings. It would also
discourage accidental duplication for parts that end up being used in
more than one architectures (ie. spi and i2c devices). Not everyone is
going to be well versed on the rules of what bindings should be arch
specific and what should go in the common dir. It will make everyone's
life easier if there is only one place to look.
(oh, and I think the subdirectories by manufacturer is a good layout).
g.
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree
From: Grant Likely @ 2008-07-04 5:54 UTC (permalink / raw)
To: Jon Smirl
Cc: Stephen Rothwell, linuxppc-dev, linux-next, Paul Mackerras,
Jean Delvare, Timur Tabi
In-Reply-To: <20080703152453.GB2284@secretlab.ca>
On Thu, Jul 3, 2008 at 9:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Jul 03, 2008 at 08:22:18AM -0400, Jon Smirl wrote:
>> Testing was good when the patch was initially posted in January. In
>> the last six months the initial patch set has been sliced and diced
>> into a bunch of different pieces but the contents of this patch are
>> essentially unchanged.
>>
>> I don't care which tree it uses to get to mainline, I'd just like to
>> see it get merged.
>
> Me too, but it is used by some of the mpc8xxx platforms too, so I'd like
> to see an ack from one of those users also.
Okay, I've tested it on my board. All looks good to me. I'd prefer
to hear back from one of the Freescale folks, but on a second reading
I think it is pretty safe. I'll make sure any merge conflicts are
resolved.
Jean, is it okay with you to drop it from your tree and merge it through mine?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Deputy maintainer for powerpc
From: Paul Mackerras @ 2008-07-04 6:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, torvalds, linux-kernel
I'm going to be on vacation for the next two weeks, and it looks
highly likely that Linus will open the 2.6.27 merge window during that
time, so I'm appointing Ben Herrenschmidt as my deputy maintainer.
During the next two weeks, he'll be the person collecting together any
further powerpc-related commits that need to go upstream, and sending
pull requests to Linus as necessary.
This is the start of a longer-term transition which will ultimately
result in me handing over the powerpc architecture maintainership to
Ben. Because of various work commitments, this will be a gradual
transition taking probably around 6 months.
Paul.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Grant Likely @ 2008-07-04 6:51 UTC (permalink / raw)
To: linuxppc-dev, Josh Boyer, Kumar Gala
In-Reply-To: <20080701175852.32575.39707.stgit@trillian.secretlab.ca>
Anyone had a chance to look at this? I think this could be used to
eliminate a lot of the platform specific default targets in
arch/powerpc/boot/Makefile by moving them into the defconfigs. Josh,
Kumar, what are your thoughts?
g.
On Tue, Jul 1, 2008 at 11:59 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> It is inconvenient to add additional default targets to the bootwrapper
> Makefile for each new board supported which just needs a different dts
> file. This change allows the defconfig to specify additional build
> targets.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/Kconfig | 13 +++++++++++++
> arch/powerpc/boot/Makefile | 3 +++
> 2 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 3934e26..f09f617 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -458,6 +458,19 @@ config CMDLINE
> some command-line options at build time by entering them here. In
> most cases you will need to specify the root device here.
>
> +config EXTRA_TARGETS
> + string "Additional default image types"
> + help
> + List additional targets to be built by the bootwrapper here (separated
> + by spaces). This is useful for targets that depend of device tree
> + files in the .dts directory.
> +
> + Targets in this list will be build as part of the default build
> + target, or when the user does a 'make zImage' or a
> + 'make zImage.initrd'.
> +
> + If unsure, leave blank
> +
> if !44x || BROKEN
> config ARCH_WANTS_FREEZER_CONTROL
> def_bool y
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 1cee2f9..1e38237 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -270,6 +270,9 @@ ifeq ($(CONFIG_PPC32),y)
> image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot
> endif
>
> +# Allow extra targets to be added to the defconfig
> +image-y += $(subst ",,$(CONFIG_EXTRA_TARGETS))
> +
> initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
> initrd-y := $(patsubst zImage%, zImage.initrd%, \
> $(patsubst dtbImage%, dtbImage.initrd%, \
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree
From: Jean Delvare @ 2008-07-04 7:35 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linuxppc-dev, linux-next, Paul Mackerras,
Timur Tabi
In-Reply-To: <fa686aa40807032254j76dd1892y7af76c1a2d555809@mail.gmail.com>
On Thu, 3 Jul 2008 23:54:26 -0600, Grant Likely wrote:
> On Thu, Jul 3, 2008 at 9:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Thu, Jul 03, 2008 at 08:22:18AM -0400, Jon Smirl wrote:
> >> Testing was good when the patch was initially posted in January. In
> >> the last six months the initial patch set has been sliced and diced
> >> into a bunch of different pieces but the contents of this patch are
> >> essentially unchanged.
> >>
> >> I don't care which tree it uses to get to mainline, I'd just like to
> >> see it get merged.
> >
> > Me too, but it is used by some of the mpc8xxx platforms too, so I'd like
> > to see an ack from one of those users also.
>
> Okay, I've tested it on my board. All looks good to me. I'd prefer
> to hear back from one of the Freescale folks, but on a second reading
> I think it is pretty safe. I'll make sure any merge conflicts are
> resolved.
>
> Jean, is it okay with you to drop it from your tree and merge it through mine?
Sure, no problem. It's done now, the patch is yours.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Wolfgang Grandegger @ 2008-07-04 7:53 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080703174844.GA27966@polina.dev.rtsoft.ru>
Hi Anton,
Anton Vorontsov wrote:
> This patch adds few bindings for the new drivers to be submitted through
> the appropriate maintainers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Segher, thanks for the comments on the previous version. Do you see any
> issues with this one or anything I could improve further?
>
> And if there are no issues... Kumar, could you apply this for powerpc-next?
As you know, I have some additions to your bindings and I posted a patch
recently:
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058617.html
Segher did not comment yet, maybe you would like to have a look. And do
you have some news about the corresponding NAND support from the MTD people?
I really appreciate breaking booting-without-of.txt up. Will this happen
already for powerpc-next (for 2.6.27)?
Thanks,
Wolfgang.
^ permalink raw reply
* Re: Need stable 2.6 kernel for TQM823L
From: Stefan Roese @ 2008-07-04 8:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807031839.19123.tmaenner@aehr.com>
Hi Tom,
On Friday 04 July 2008, Thomas Maenner wrote:
> > arch/ppc is depreciated and will disappear in 2.6.27. I don't know if
> > anyone is actively keeping 8xx support working in arch/ppc so you may
> > experience significant breakage.
> >
> > g.
>
> Not exactly what I was hoping to hear...
>
> What are the reasons to not port these TQs to 2.6?
> Lack of resources? Not enough interest?
We (DENX) have been maintaining those TQM8xx boards (U-Boot & Linux). But till
now nobody asked us to port these over to arch/powerpc. You may understand
that we won't do this "just for fun". If you are interested in an
arch/powerpc port for these boards, we could do this of course. Please
contact me off list if you are interested in such a project.
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* powerpc: fix swapcontext backwards compatibility due to VSX ucontext changes
From: Michael Neuling @ 2008-07-04 8:25 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
When the ucontext changed to add the VSX context, this broke backwards
compatibly on swapcontext. swapcontext only compares the ucontext
size passed in from the user to the new kernel ucontext size.
This adds a check against the old ucontext size (with VMX but without
VSX). It also adds some sanity check for ucontexts without VSX, but
where VSX is used according the MSR. Fixes for both 32 and 64bit
processes on 64bit kernels
Kudos to Paulus for noticing.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Benh: please apply to your 2.6.27 tree.
PS "I for one welcome our new powerpc linux maintainer overload" :-)
arch/powerpc/kernel/signal_32.c | 36 +++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/signal_64.c | 35 +++++++++++++++++++++++++++++++----
2 files changed, 66 insertions(+), 5 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
@@ -68,6 +68,13 @@
#define ucontext ucontext32
/*
+ * Userspace code may pass a ucontext which doesn't include VSX added
+ * at the end. We need to check for this case.
+ */
+#define UCONTEXTSIZEWITHOUTVSX \
+ (sizeof(struct ucontext) - sizeof(elf_vsrreghalf_t32))
+
+/*
* Returning 0 means we return to userspace via
* ret_from_except and thus restore all user
* registers from *regs. This is what we need
@@ -930,12 +937,39 @@ long sys_swapcontext(struct ucontext __u
{
unsigned char tmp;
+#ifdef CONFIG_PPC64
+ unsigned long new_msr = 0;
+
+ if (new_ctx &&
+ __get_user(new_msr, &new_ctx->uc_mcontext.mc_gregs[PT_MSR]))
+ return -EFAULT;
+ if (/*
+ * Check that the context is not smaller than the original
+ * size (with VMX but without VSX)
+ */
+ (ctx_size < UCONTEXTSIZEWITHOUTVSX) ||
+ /*
+ * If userspace doesn't provide enough room for VSX data,
+ * but current thread has used VSX, we don't have anywhere
+ * to store the full context back into.
+ */
+ ((ctx_size < sizeof(struct ucontext)) &&
+ (regs->msr & MSR_VSX) && old_ctx) ||
+ /*
+ * If the new context state sets the MSR VSX bits but
+ * it doesn't provide VSX state.
+ */
+ ((ctx_size < sizeof(struct ucontext)) &&
+ (new_msr & MSR_VSX)))
+ /* ... computer says "noooo" */
+ return -EINVAL;
+#else
/* Context size is for future use. Right now, we only make sure
* we are passed something we understand
*/
if (ctx_size < sizeof(struct ucontext))
return -EINVAL;
-
+#endif
if (old_ctx != NULL) {
struct mcontext __user *mctx;
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_64.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
@@ -268,6 +268,13 @@ static long setup_trampoline(unsigned in
}
/*
+ * Userspace code may pass a ucontext which doesn't include VSX added
+ * at the end. We need to check for this case.
+ */
+#define UCONTEXTSIZEWITHOUTVSX \
+ (sizeof(struct ucontext) - 32*sizeof(long))
+
+/*
* Handle {get,set,swap}_context operations
*/
int sys_swapcontext(struct ucontext __user *old_ctx,
@@ -277,10 +284,30 @@ int sys_swapcontext(struct ucontext __us
unsigned char tmp;
sigset_t set;
- /* Context size is for future use. Right now, we only make sure
- * we are passed something we understand
- */
- if (ctx_size < sizeof(struct ucontext))
+ unsigned long new_msr = 0;
+
+ if (new_ctx &&
+ __get_user(new_msr, &new_ctx->uc_mcontext.gp_regs[PT_MSR]))
+ return -EFAULT;
+ if (/*
+ * Check that the context is not smaller than the original
+ * size (with VMX but without VSX)
+ */
+ (ctx_size < UCONTEXTSIZEWITHOUTVSX) ||
+ /*
+ * If userspace doesn't provide enough room for VSX data,
+ * but current thread has used VSX, we don't have anywhere
+ * to store the full context back into.
+ */
+ ((ctx_size < sizeof(struct ucontext)) &&
+ (regs->msr & MSR_VSX) && old_ctx) ||
+ /*
+ * If the new context state sets the MSR VSX bits but
+ * it doesn't provide VSX state.
+ */
+ ((ctx_size < sizeof(struct ucontext)) &&
+ (new_msr & MSR_VSX)))
+ /* ... computer says "No" */
return -EINVAL;
if (old_ctx != NULL) {
^ permalink raw reply
* GPIO @ MPC5200
From: Andre Schwarz @ 2008-07-04 9:57 UTC (permalink / raw)
To: s.hauer, Grant Likely; +Cc: linux-ppc list
Sascha, Grant,
I'm running on 2.6.26-rc6 with an MPC5200B based system.
Looks like some (for me) crucial GPIO are touched during boot.
Is this possible ?
Of course I have compiled in GPIO-Lib and specified the GPIOs in the dts.
But no access yet - I'd like to preserve the setup from u-boot...
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH] fsl-diu-fb: Update Freescale DIU driver to use page_alloc_exact()
From: Timur Tabi @ 2008-07-04 10:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, linux-kernel
In-Reply-To: <20080630132426.a89c32b0.akpm@linux-foundation.org>
On Jun 30, 2008, at 4:24 PM, Andrew Morton wrote:
> This is also incorrect. We cannot pass u64 or uint64_t into printk at
> all. We do not know what type the architectures uses to implement
> them. It should be cast to a known type. In this case `unsigned long
> long'.
Ok, I'll fix these, but I'm on vacation now and won't get to it for
another 10 days.
^ permalink raw reply
* Re: Need stable 2.6 kernel for TQM823L
From: Jochen Friedrich @ 2008-07-04 10:12 UTC (permalink / raw)
To: Thomas Maenner; +Cc: linuxppc-embedded
In-Reply-To: <200807031839.19123.tmaenner@aehr.com>
Hi Tom,
> Not exactly what I was hoping to hear...
>
> What are the reasons to not port these TQs to 2.6?
> Lack of resources? Not enough interest?
It's probably not enough interest.
However, the port should be fairly easy. Some time ago, I posted a
port for the Dbox2 hardware, which is also based on the MPC823 CPU.
You can use this as a starting point just by ripping off the DBox2
specific parts (you'd have to convert the device tree to v1 though):
http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=15875
Thanks,
Jochen
^ permalink raw reply
* Re: [alsa-devel] [PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Timur Tabi @ 2008-07-04 11:03 UTC (permalink / raw)
To: Grant Likely; +Cc: liam.girdwood, alsa-devel, broonie, linuxppc-dev
In-Reply-To: <20080703162809.GH2284@secretlab.ca>
> i2s@2200 { // PSC2
> compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> cell-index = <1>;
cell-index should be zero-based, not one-based.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-04 11:05 UTC (permalink / raw)
To: Grant Likely; +Cc: liam.girdwood, alsa-devel, broonie, linuxppc-dev
In-Reply-To: <20080703163351.GJ2284@secretlab.ca>
On Jul 3, 2008, at 12:33 PM, Grant Likely wrote:
> Yes, but you hadn't written these functions when I wrote this helper.
> :-P. I believe ASoC v2 makes all this stuff unnecessary, but I'm
> waiting for v2 to hit mainline before I port forward.
FYI, it took me about a month to port my drivers to ASoC V2. I had
more work than most people because I addressed issues that others
drivers didn't. For instance, my CS4270 driver is the only codec
driver in V2 that supports multiple instances of itself.
^ permalink raw reply
* Update maintainers for powerpc
From: Paul Mackerras @ 2008-07-04 11:04 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, trini, anton, akpm
This updates the MAINTAINERS entries for powerpc. It adds Ben H to
the overall Linux for PowerPC entry and makes it clear this covers
both 32-bit and 64-bit machines. It removes the separate entry we had
for Linux on 64-bit PowerPC where Anton and I were listed as
maintainers - Anton hasn't been involved in the day-to-day maintenance
of the code for several years. Finally, it removes the entry for the
Linux for PowerPC boot code where Tom Rini was listed as the
maintainer. That code got completely rewritten when we merged
32-bit and 64-bit, and I and the various platform maintainers have
been maintaining that code since.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus, could this go in for 2.6.26 please?
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f0ec46..e1b62c1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2474,9 +2474,11 @@ M: James.Bottomley@HansenPartnership.com
W: http://www.hansenpartnership.com/voyager
S: Maintained
-LINUX FOR POWERPC
+LINUX FOR POWERPC (32-BIT AND 64-BIT)
P: Paul Mackerras
M: paulus@samba.org
+P: Benjamin Herrenschmidt
+M: benh@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
@@ -2516,13 +2518,6 @@ W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
L: linuxppc-dev@ozlabs.org
S: Maintained
-LINUX FOR POWERPC BOOT CODE
-P: Tom Rini
-M: trini@kernel.crashing.org
-W: http://www.penguinppc.org/
-L: linuxppc-dev@ozlabs.org
-S: Maintained
-
LINUX FOR POWERPC EMBEDDED PPC8XX
P: Vitaly Bordug
M: vitb@kernel.crashing.org
@@ -2551,17 +2546,6 @@ P: Arnaldo Carvalho de Melo
M: acme@ghostprotocols.net
S: Maintained
-LINUX FOR 64BIT POWERPC
-P: Paul Mackerras
-M: paulus@samba.org
-M: paulus@au.ibm.com
-P: Anton Blanchard
-M: anton@samba.org
-M: anton@au.ibm.com
-W: http://www.penguinppc.org/ppc64/
-L: linuxppc-dev@ozlabs.org
-S: Supported
-
LINUX SECURITY MODULE (LSM) FRAMEWORK
P: Chris Wright
M: chrisw@sous-sol.org
^ permalink raw reply related
* Re: powerpc: fix swapcontext backwards compatibility due to VSX ucontext changes
From: Paul Mackerras @ 2008-07-04 11:08 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <31609.1215159925@neuling.org>
Michael Neuling writes:
> + /*
> + * If userspace doesn't provide enough room for VSX data,
> + * but current thread has used VSX, we don't have anywhere
> + * to store the full context back into.
> + */
> + ((ctx_size < sizeof(struct ucontext)) &&
> + (regs->msr & MSR_VSX) && old_ctx) ||
I think we need to check current->thread.used_vsr rather than
regs->msr here (in both instances of this code).
Paul.
^ permalink raw reply
* Re: Full Linux distributions
From: Detlev Zundel @ 2008-07-04 11:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <27dfa3d0807031659n4a03dd63i4793c3231d224ae6@mail.gmail.com>
Hi Daniel,
> I've been using the ELDK for an amcc440EP ppc board. It's turned out
> to be rather convenient, especially when running a networked
> environment.
I'm glad to hear that the ELDK is useful.
> The guy who primarily maintains it is very helpful also.
To be honest, the ELDK is maintained by our company. It has become too
much for a single individual.
We of course invite others from the community to get involved
here. There is a mailinglist[1] to discuss ELDK related topics and all
sources needed to build it are available from our git server[2].
One of the inconveniences preventing likely many attempts to get
involved is our old build system, which ensures excellent distribution
compatibility however.
So one of the first goals I try to invest spare time is to fix the build
process into being runnable on modern distros also. We just cannot drop
support for the old build environment to be as widely compatible as
possible.
Cheers
Detlev
[1] http://lists.denx.de/mailman/listinfo/eldk
[2] http://git.denx.de/
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH 1/3] ehea: fix might sleep problem
From: Jeff Garzik @ 2008-07-04 12:14 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, hering2, linux-kernel,
kamalesh, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200807031618.46087.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> A mutex has to be replaced by spinlocks as it can be called from
> a context which does not allow sleeping.
> The kzalloc flag GFP_KERNEL has to be replaced by GFP_ATOMIC
> for the same reason.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied 1-3 to 2.6.26
^ permalink raw reply
* Re: [PATCH v3] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
From: Jeff Garzik @ 2008-07-04 12:17 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sathya Narayanan, netdev
In-Reply-To: <1214902685-10489-1-git-send-email-sr@denx.de>
Stefan Roese wrote:
> From: Sathya Narayanan <sathyan@teamf1.com>
>
> The descriptor pointers were not initialized to NIL values, so it was
> poiniting to some random addresses which was completely invalid. This
> fix takes care of initializing the descriptor to NIL values and clearing
> the valid descriptors on clean ring operation.
>
> Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/net/ibm_newemac/core.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index 5d2108c..ca63fa0 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -2719,6 +2719,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
> /* Clean rings */
> memset(dev->tx_desc, 0, NUM_TX_BUFF * sizeof(struct mal_descriptor));
> memset(dev->rx_desc, 0, NUM_RX_BUFF * sizeof(struct mal_descriptor));
> + memset(dev->tx_skb, 0, NUM_TX_BUFF * sizeof(struct sk_buff *));
> + memset(dev->rx_skb, 0, NUM_RX_BUFF * sizeof(struct sk_buff *));
>
applied to 2.6.26
^ permalink raw reply
* Re: [PATCH v2] ibm_newemac: Fixes entry of short packets
From: Jeff Garzik @ 2008-07-04 12:17 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sathya Narayanan, netdev
In-Reply-To: <1214902699-10534-1-git-send-email-sr@denx.de>
Stefan Roese wrote:
> From: Sathya Narayanan <sathyan@teamf1.com>
>
> Short packets has to be discarded by the driver. So this patch addresses the
> issue of discarding the short packets of size lesser then ethernet header
> size.
>
> Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/net/ibm_newemac/core.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index ca63fa0..babc79a 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1636,6 +1636,12 @@ static int emac_poll_rx(void *param, int budget)
> goto next;
> }
>
> + if (len < ETH_HLEN) {
> + ++dev->estats.rx_dropped_stack;
> + emac_recycle_rx_skb(dev, slot, len);
> + goto next;
> + }
> +
> if (len && len < EMAC_RX_COPY_THRESH) {
applied 2.6.26
^ 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