* Re: [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: Grant Likely @ 2010-12-23 21:58 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-3-git-send-email-dirk.brandewie@gmail.com>
On Wed, Dec 22, 2010 at 11:57:27AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds linking device tree blob into vmlinux. DTB's are
> added by adding the blob object name to list of objects to be linked
> into the image.
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> arch/x86/platform/ce4100/Makefile | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
> index 91fc929..e5f3b7b 100644
> --- a/arch/x86/platform/ce4100/Makefile
> +++ b/arch/x86/platform/ce4100/Makefile
> @@ -1 +1,11 @@
> obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
> +clean-files := *dtb.S
> +
> +ifdef CONFIG_X86_OF
> +###
> +# device tree blob
> +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
> +
> +$(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
> +endif
Skipped for now; will pick up after ce4100 is in mainline since this
is a pretty low-risk change.
g.
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: Grant Likely @ 2010-12-23 22:13 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-5-git-send-email-dirk.brandewie@gmail.com>
On Wed, Dec 22, 2010 at 11:57:29AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> Modify arch/powerpc/boot/Makefile to use dtc command in
> scripts/Makefile.lib
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
applied, thanks
g.
> ---
> arch/microblaze/boot/Makefile | 12 +++---------
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
> index be01d78..4c4e58e 100644
> --- a/arch/microblaze/boot/Makefile
> +++ b/arch/microblaze/boot/Makefile
> @@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
>
> OBJCOPYFLAGS := -O binary
>
> -# Where the DTS files live
> -dtstree := $(srctree)/$(src)/dts
> -
> # Ensure system.dtb exists
> $(obj)/linked_dtb.o: $(obj)/system.dtb
>
> @@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
> $(call if_changed,strip)
> @echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
>
> -# Rule to build device tree blobs
> -DTC = $(objtree)/scripts/dtc/dtc
>
> # Rule to build device tree blobs
> -quiet_cmd_dtc = DTC $@
> - cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
> +DTC_FLAGS := -p 1024
>
> -$(obj)/%.dtb: $(dtstree)/%.dts FORCE
> - $(call if_changed,dtc)
> +$(obj)/%.dtb: $(src)/dts/%.dts FORCE
> + $(call cmd,dtc)
>
> clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: Grant Likely @ 2010-12-23 22:13 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-4-git-send-email-dirk.brandewie@gmail.com>
On Wed, Dec 22, 2010 at 11:57:28AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> Modify arch/powerpc/boot/Makefile to use dtc command in
> scripts/Makefile.lib
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
applied, thanks
g.
> ---
> arch/powerpc/boot/Makefile | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index fae8192..96deec6 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -35,7 +35,7 @@ endif
>
> BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
>
> -DTS_FLAGS ?= -p 1024
> +DTC_FLAGS ?= -p 1024
>
> $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
> $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
> @@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> $(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
>
> # Rule to build device tree blobs
> -DTC = $(objtree)/scripts/dtc/dtc
> -
> -$(obj)/%.dtb: $(dtstree)/%.dts
> - $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
> +$(obj)/%.dtb: $(src)/dts/%.dts
> + $(call cmd,dtc)
>
> # If there isn't a platform selected then just strip the vmlinux.
> ifeq (,$(image-y))
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2010-12-23 22:33 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <4D13C402.2090209@mentor.com>
On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
> On 12/23/2010 12:56 PM, Grant Likely wrote:
> >Hi Meador. Comments below.
> >
> >g.
>
> Thanks a lot for the feedback Grant.
>
> >You should probably list them here anyway to aid the reader.
>
> Will do.
>
> >What is the use case for the protected-sources property? Wouldn't the
> >irqs simply not be referenced by any device nodes? Documenting the
> >reason for this property would be useful here.
>
> One use case is the original [1]:
>
> Some HW platforms, such as the new cell blades, requires some
> MPIC sources to be left alone by the operating system. This
> implements support for a "protected-sources" property in the
> mpic controller node containing a list of source numbers to be
> protected against operating system interference.
>
> Our use case is to reserve certain IRQs for certain OSes in an AMP
> system. As an example, consider that OS 1 has (simplified for
> discussion):
>
> mpic: pic@40000 {
> ...
> protected-sources = <0xb1>;
>
> msgr@41400 {
> interrupts = <0xb0 2 0xb1 2 0xb2 2 0xb3 2>;
> };
> };
>
> and OS 2 has:
>
> mpic: pic@40000 {
> ...
> protected-sources = <0xb0>;
>
> msgr@41400 {
> interrupts = <0xb0 2 0xb1 2 0xb2 2 0xb3 2>;
> };
> };
>
> where OS 1 is sent messages through the message register tied to
> 0xb0 and OS 2 is sent messages through the message register tied to
> 0xb1.
>
> We can't just remove the IRQ of the _other_ OS from the 'interrupts'
> property in the message node because we need to know the IRQ in
> order to talk to the other OS. So, we use protected sources to tell
> the OS that an IRQ is not available for its own use, while at the
> same time keeping complete information on all the IRQ mappings for
> the message registers.
If the OS cannot use the IRQ, then it better not be encoded into an
'interrupts' property. Instead, they should be encoded into a
different property (which could use exactly the same encoding as
'interrupts') that tells the driver that it is the target processor's
irq. Something like 'target-interrupts-cpu0 = <0xb1 2>' for OS#1 in
the example.
>
> I will update the documentation.
>
> >I'd rather see the 'generic' value of mpic-msgr omitted and instead
> >allow new parts to claim compatibility with an older chip. Generic
> >or wildcard compatible values can be troublesome because the meaning
> >has a tendency to change over time.
>
> I don't completely see the issue here. Do you have a specific
> example of how generic values like this cause problems?
For example, both the mpc83xx family and the mpc5xxx family of
processors implement the same i2c core (historically using compatible
"fsl,i2c"), but the behaviour of the two parts is subtly and
incompatibly different. The actual implementation name has to be
matched to figure out how to drive the core correctly. So, in that
case which implementation does "fsl,i2c" really describe?
> How do you
> see this working in terms of processing the data? It seems like we
> are going to have to be aware of N values instead of 1, which seems
> worse.
This argument has been rehashed many times, but it basically comes
down to compatible values should ideally be anchored to a real
implemented device, not to a family of devices, or to an unversioned
specification.
In practise, the implementation doesn't actually look any different
except that the 'reference' version specifies a specific
implementation instead of a generic name. To use a concrete example,
if there are two parts using this MPIC, like the freescale p2040 and
p4080, and say for argument that the p2040 was implemented first, then
the compatible values would look like:
for the p2040: compatible = "fsl,p2040-msgr";
for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
and the driver could simply bind on "fsl,p2040-msgr" to work with both
chips. So, instead of an arbitrary "fsl,mpic-msgr" string,
"fsl,p2040-msgr" is used as the baseline value and there is no
ambiguity about which part it describes.
If the p4080 is actually subtly different from the p2040, then
it would not claim compatibility with the former and the driver can
match against either string; adapting its behaviour as necessary.
>
> >? This needs some more explanation. cell-index often gets abused as
> >a way to enumerate devices. Typically, the address of the device
> >itself is sufficient to identify the device.
>
> The message registers typically come in blocks of four memory mapped
> registers and may not be in contiguous memory (example [3]). The
> intent of 'cell-index' is to put an ordering on the blocks (so, yes,
> enumeration). We could order them by address as well I suppose.
> One less property to worry about :)
:-) I'd prefer to see a binding that doesn't need to enumerate nodes.
If the nodes *really* need to be enumerated, then I recommend looking
at using properties in the aliases node to assign globally enumerated
names, or at explicitly having an order list in the parent node.
>
> >Are these registers memory mapped? If so, then the parent node
> >needs to have a 'ranges' property.
>
> Yes, they are. I will look into adding that.
Thanks.
g.
>
>
> [1] commit 7fd7218610600b16f6f0af3f9d9353ba0265c09f, http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=7fd7218610600b16f6f0af3f9d9353ba0265c09f
>
> [2] Documentation/powerpc/dts-bindings/fsl/msi-pic.txt
>
> [3] http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8572ERM.pdf?fr=g
>
> --
> Meador Inge | meador_inge AT mentor.com
> Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH] of/address: use propper endianess in get_flags
From: Grant Likely @ 2010-12-23 22:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sodaville, Sebastian Andrzej Siewior, linuxppc-dev
In-Reply-To: <1291245312.32570.411.camel@pasglop>
On Thu, Dec 02, 2010 at 10:15:12AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-12-01 at 10:54 +0100, Sebastian Andrzej Siewior wrote:
> > This patch changes u32 to __be32 for all "ranges", "prop" and "addr" and
> > such. Those variables are pointing to the device tree which containts
> > intergers in big endian format.
> > Most functions are doing it right because of_read_number() is doing the
> > right thing for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
> > of_bus_isa_map() were accessing the data directly and were doing it wrong.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied for -next, thanks.
g.
> ---
>
> > ---
> > arch/powerpc/include/asm/prom.h | 2 +-
> > drivers/of/address.c | 54 ++++++++++++++++++++------------------
> > include/linux/of_address.h | 6 ++--
> > 3 files changed, 32 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
> > index ae26f2e..ab34f60 100644
> > --- a/arch/powerpc/include/asm/prom.h
> > +++ b/arch/powerpc/include/asm/prom.h
> > @@ -42,7 +42,7 @@ extern void pci_create_OF_bus_map(void);
> >
> > /* Translate a DMA address from device space to CPU space */
> > extern u64 of_translate_dma_address(struct device_node *dev,
> > - const u32 *in_addr);
> > + const __be32 *in_addr);
> >
> > #ifdef CONFIG_PCI
> > extern unsigned long pci_address_to_pio(phys_addr_t address);
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 3a1c7e7..b4559c5 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -12,13 +12,13 @@
> > (ns) > 0)
> >
> > static struct of_bus *of_match_bus(struct device_node *np);
> > -static int __of_address_to_resource(struct device_node *dev, const u32 *addrp,
> > - u64 size, unsigned int flags,
> > +static int __of_address_to_resource(struct device_node *dev,
> > + const __be32 *addrp, u64 size, unsigned int flags,
> > struct resource *r);
> >
> > /* Debug utility */
> > #ifdef DEBUG
> > -static void of_dump_addr(const char *s, const u32 *addr, int na)
> > +static void of_dump_addr(const char *s, const __be32 *addr, int na)
> > {
> > printk(KERN_DEBUG "%s", s);
> > while (na--)
> > @@ -26,7 +26,7 @@ static void of_dump_addr(const char *s, const u32 *addr, int na)
> > printk("\n");
> > }
> > #else
> > -static void of_dump_addr(const char *s, const u32 *addr, int na) { }
> > +static void of_dump_addr(const char *s, const __be32 *addr, int na) { }
> > #endif
> >
> > /* Callbacks for bus specific translators */
> > @@ -36,10 +36,10 @@ struct of_bus {
> > int (*match)(struct device_node *parent);
> > void (*count_cells)(struct device_node *child,
> > int *addrc, int *sizec);
> > - u64 (*map)(u32 *addr, const u32 *range,
> > + u64 (*map)(u32 *addr, const __be32 *range,
> > int na, int ns, int pna);
> > int (*translate)(u32 *addr, u64 offset, int na);
> > - unsigned int (*get_flags)(const u32 *addr);
> > + unsigned int (*get_flags)(const __be32 *addr);
> > };
> >
> > /*
> > @@ -55,7 +55,7 @@ static void of_bus_default_count_cells(struct device_node *dev,
> > *sizec = of_n_size_cells(dev);
> > }
> >
> > -static u64 of_bus_default_map(u32 *addr, const u32 *range,
> > +static u64 of_bus_default_map(u32 *addr, const __be32 *range,
> > int na, int ns, int pna)
> > {
> > u64 cp, s, da;
> > @@ -85,7 +85,7 @@ static int of_bus_default_translate(u32 *addr, u64 offset, int na)
> > return 0;
> > }
> >
> > -static unsigned int of_bus_default_get_flags(const u32 *addr)
> > +static unsigned int of_bus_default_get_flags(const __be32 *addr)
> > {
> > return IORESOURCE_MEM;
> > }
> > @@ -110,10 +110,10 @@ static void of_bus_pci_count_cells(struct device_node *np,
> > *sizec = 2;
> > }
> >
> > -static unsigned int of_bus_pci_get_flags(const u32 *addr)
> > +static unsigned int of_bus_pci_get_flags(const __be32 *addr)
> > {
> > unsigned int flags = 0;
> > - u32 w = addr[0];
> > + u32 w = be32_to_cpup(addr);
> >
> > switch((w >> 24) & 0x03) {
> > case 0x01:
> > @@ -129,7 +129,8 @@ static unsigned int of_bus_pci_get_flags(const u32 *addr)
> > return flags;
> > }
> >
> > -static u64 of_bus_pci_map(u32 *addr, const u32 *range, int na, int ns, int pna)
> > +static u64 of_bus_pci_map(u32 *addr, const __be32 *range, int na, int ns,
> > + int pna)
> > {
> > u64 cp, s, da;
> > unsigned int af, rf;
> > @@ -160,7 +161,7 @@ static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
> > return of_bus_default_translate(addr + 1, offset, na - 1);
> > }
> >
> > -const u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
> > +const __be32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
> > unsigned int *flags)
> > {
> > const __be32 *prop;
> > @@ -207,7 +208,7 @@ EXPORT_SYMBOL(of_get_pci_address);
> > int of_pci_address_to_resource(struct device_node *dev, int bar,
> > struct resource *r)
> > {
> > - const u32 *addrp;
> > + const __be32 *addrp;
> > u64 size;
> > unsigned int flags;
> >
> > @@ -237,12 +238,13 @@ static void of_bus_isa_count_cells(struct device_node *child,
> > *sizec = 1;
> > }
> >
> > -static u64 of_bus_isa_map(u32 *addr, const u32 *range, int na, int ns, int pna)
> > +static u64 of_bus_isa_map(u32 *addr, const __be32 *range, int na, int ns,
> > + int pna)
> > {
> > u64 cp, s, da;
> >
> > /* Check address type match */
> > - if ((addr[0] ^ range[0]) & 0x00000001)
> > + if ((addr[0] ^ range[0]) & cpu_to_be32(1))
> > return OF_BAD_ADDR;
> >
> > /* Read address values, skipping high cell */
> > @@ -264,10 +266,10 @@ static int of_bus_isa_translate(u32 *addr, u64 offset, int na)
> > return of_bus_default_translate(addr + 1, offset, na - 1);
> > }
> >
> > -static unsigned int of_bus_isa_get_flags(const u32 *addr)
> > +static unsigned int of_bus_isa_get_flags(const __be32 *addr)
> > {
> > unsigned int flags = 0;
> > - u32 w = addr[0];
> > + u32 w = be32_to_cpup(addr);
> >
> > if (w & 1)
> > flags |= IORESOURCE_IO;
> > @@ -330,7 +332,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> > struct of_bus *pbus, u32 *addr,
> > int na, int ns, int pna, const char *rprop)
> > {
> > - const u32 *ranges;
> > + const __be32 *ranges;
> > unsigned int rlen;
> > int rone;
> > u64 offset = OF_BAD_ADDR;
> > @@ -398,7 +400,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> > * that can be mapped to a cpu physical address). This is not really specified
> > * that way, but this is traditionally the way IBM at least do things
> > */
> > -u64 __of_translate_address(struct device_node *dev, const u32 *in_addr,
> > +u64 __of_translate_address(struct device_node *dev, const __be32 *in_addr,
> > const char *rprop)
> > {
> > struct device_node *parent = NULL;
> > @@ -475,22 +477,22 @@ u64 __of_translate_address(struct device_node *dev, const u32 *in_addr,
> > return result;
> > }
> >
> > -u64 of_translate_address(struct device_node *dev, const u32 *in_addr)
> > +u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
> > {
> > return __of_translate_address(dev, in_addr, "ranges");
> > }
> > EXPORT_SYMBOL(of_translate_address);
> >
> > -u64 of_translate_dma_address(struct device_node *dev, const u32 *in_addr)
> > +u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
> > {
> > return __of_translate_address(dev, in_addr, "dma-ranges");
> > }
> > EXPORT_SYMBOL(of_translate_dma_address);
> >
> > -const u32 *of_get_address(struct device_node *dev, int index, u64 *size,
> > +const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
> > unsigned int *flags)
> > {
> > - const u32 *prop;
> > + const __be32 *prop;
> > unsigned int psize;
> > struct device_node *parent;
> > struct of_bus *bus;
> > @@ -525,8 +527,8 @@ const u32 *of_get_address(struct device_node *dev, int index, u64 *size,
> > }
> > EXPORT_SYMBOL(of_get_address);
> >
> > -static int __of_address_to_resource(struct device_node *dev, const u32 *addrp,
> > - u64 size, unsigned int flags,
> > +static int __of_address_to_resource(struct device_node *dev,
> > + const __be32 *addrp, u64 size, unsigned int flags,
> > struct resource *r)
> > {
> > u64 taddr;
> > @@ -564,7 +566,7 @@ static int __of_address_to_resource(struct device_node *dev, const u32 *addrp,
> > int of_address_to_resource(struct device_node *dev, int index,
> > struct resource *r)
> > {
> > - const u32 *addrp;
> > + const __be32 *addrp;
> > u64 size;
> > unsigned int flags;
> >
> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > index 8aea06f..2feda6e 100644
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -3,7 +3,7 @@
> > #include <linux/ioport.h>
> > #include <linux/of.h>
> >
> > -extern u64 of_translate_address(struct device_node *np, const u32 *addr);
> > +extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
> > extern int of_address_to_resource(struct device_node *dev, int index,
> > struct resource *r);
> > extern void __iomem *of_iomap(struct device_node *device, int index);
> > @@ -21,7 +21,7 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
> > #endif
> >
> > #ifdef CONFIG_PCI
> > -extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
> > +extern const __be32 *of_get_pci_address(struct device_node *dev, int bar_no,
> > u64 *size, unsigned int *flags);
> > extern int of_pci_address_to_resource(struct device_node *dev, int bar,
> > struct resource *r);
> > @@ -32,7 +32,7 @@ static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
> > return -ENOSYS;
> > }
> >
> > -static inline const u32 *of_get_pci_address(struct device_node *dev,
> > +static inline const __be32 *of_get_pci_address(struct device_node *dev,
> > int bar_no, u64 *size, unsigned int *flags)
> > {
> > return NULL;
>
>
^ permalink raw reply
* [PATCH][GIT PULL] powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
From: Steven Rostedt @ 2010-12-24 5:46 UTC (permalink / raw)
To: LKML; +Cc: Andrew Morton, Joerg Sommer, linuxppc-dev
Ben,
Joerg reported a crash with the irqsoff tracer with PPC32.
Unfortunately, I don't have a ppc32 that I can work with (my kids took
it from me). I posted a test patch on the BZ that was opened for it:
https://bugzilla.kernel.org/show_bug.cgi?id=16573
Anyway, I was also able to reproduce the crash on PPC64. This patch
handles that case.
The following patch is in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: ppc/ftrace
Steven Rostedt (1):
powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
----
arch/powerpc/include/asm/irqflags.h | 40 ++++++++++++++++++++++++++--------
1 files changed, 30 insertions(+), 10 deletions(-)
---------------------------
commit 5025019505da6731f8be13940bb978617599c935
Author: Steven Rostedt <srostedt@redhat.com>
Date: Thu Dec 23 21:07:39 2010 -0800
powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
When an interrupt occurs in userspace, we can call trace_hardirqs_on/off()
With one level stack. But if we have irqsoff tracing enabled,
it checks both CALLER_ADDR0 and CALLER_ADDR1. The second call
goes two stack frames up. If this is from user space, then there may
not exist a second stack.
Add a second stack when calling trace_hardirqs_on/off() otherwise
the following oops might occur:
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=2 PA Semi PWRficient
last sysfs file: /sys/block/sda/size
Modules linked in: ohci_hcd ehci_hcd usbcore
NIP: c0000000000e1c00 LR: c0000000000034d4 CTR: 000000011012c440
REGS: c00000003e2f3af0 TRAP: 0300 Not tainted (2.6.37-rc6+)
MSR: 9000000000001032 <ME,IR,DR> CR: 48044444 XER: 20000000
DAR: 00000001ffb9db50, DSISR: 0000000040000000
TASK = c00000003e1a00a0[2088] 'emacs' THREAD: c00000003e2f0000 CPU: 1
GPR00: 0000000000000001 c00000003e2f3d70 c00000000084e0d0 c0000000008816e8
GPR04: 000000001034c678 000000001032e8f9 0000000010336540 0000000040020000
GPR08: 0000000040020000 00000001ffb9db40 c00000003e2f3e30 0000000060000000
GPR12: 100000000000f032 c00000000fff0280 000000001032e8c9 0000000000000008
GPR16: 00000000105be9c0 00000000105be950 00000000105be9b0 00000000105be950
GPR20: 00000000ffb9dc50 00000000ffb9dbf0 00000000102f0000 00000000102f0000
GPR24: 00000000102e0000 00000000102f0000 0000000010336540 c0000000009ded38
GPR28: 00000000102e0000 c0000000000034d4 c0000000007ccb10 c00000003e2f3d70
NIP [c0000000000e1c00] .trace_hardirqs_off+0xb0/0x1d0
LR [c0000000000034d4] decrementer_common+0xd4/0x100
Call Trace:
[c00000003e2f3d70] [c00000003e2f3e30] 0xc00000003e2f3e30 (unreliable)
[c00000003e2f3e30] [c0000000000034d4] decrementer_common+0xd4/0x100
Instruction dump:
81690000 7f8b0000 419e0018 f84a0028 60000000 60000000 60000000 e95f0000
80030000 e92a0000 eb6301f8 2f800000 <eb890010> 41fe00dc a06d000a eb1e8050
---[ end trace 4ec7fd2be9240928 ]---
Reported-by: Joerg Sommer <joerg@alea.gnuu.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
diff --git a/arch/powerpc/include/asm/irqflags.h b/arch/powerpc/include/asm/irqflags.h
index b85d8dd..b0b06d8 100644
--- a/arch/powerpc/include/asm/irqflags.h
+++ b/arch/powerpc/include/asm/irqflags.h
@@ -12,24 +12,44 @@
#else
#ifdef CONFIG_TRACE_IRQFLAGS
+#ifdef CONFIG_IRQSOFF_TRACER
+/*
+ * Since the ftrace irqsoff latency trace checks CALLER_ADDR1,
+ * which is the stack frame here, we need to force a stack frame
+ * in case we came from user space.
+ */
+#define TRACE_WITH_FRAME_BUFFER(func) \
+ mflr r0; \
+ stdu r1, -32(r1); \
+ std r0, 16(r1); \
+ stdu r1, -32(r1); \
+ bl func; \
+ ld r1, 0(r1); \
+ ld r1, 0(r1);
+#else
+#define TRACE_WITH_FRAME_BUFFER(func) \
+ bl func;
+#endif
+
/*
* Most of the CPU's IRQ-state tracing is done from assembly code; we
* have to call a C function so call a wrapper that saves all the
* C-clobbered registers.
*/
-#define TRACE_ENABLE_INTS bl .trace_hardirqs_on
-#define TRACE_DISABLE_INTS bl .trace_hardirqs_off
-#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
- cmpdi en,0; \
- bne 95f; \
- stb en,PACASOFTIRQEN(r13); \
- bl .trace_hardirqs_off; \
- b skip; \
-95: bl .trace_hardirqs_on; \
+#define TRACE_ENABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_on)
+#define TRACE_DISABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_off)
+
+#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
+ cmpdi en,0; \
+ bne 95f; \
+ stb en,PACASOFTIRQEN(r13); \
+ TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_off) \
+ b skip; \
+95: TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_on) \
li en,1;
#define TRACE_AND_RESTORE_IRQ(en) \
TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \
- stb en,PACASOFTIRQEN(r13); \
+ stb en,PACASOFTIRQEN(r13); \
96:
#else
#define TRACE_ENABLE_INTS
^ permalink raw reply related
* Re: [PATCH 1/2] eSPI: change the read behavior of the SPIRF
From: Grant Likely @ 2010-12-24 8:55 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1292894768-6737-1-git-send-email-Mingkai.hu@freescale.com>
On Tue, Dec 21, 2010 at 09:26:07AM +0800, Mingkai Hu wrote:
> The user must read N bytes of SPIRF (1 <= N <= 4) that do not exceed the
> amount of data in the receive FIFO, so read the SPIRF byte by byte when
> the data in receive FIFO is less than 4 bytes.
>
> On Simics, when read N bytes that exceed the amout of data in receive
> FIFO, we can't read the data out, that is we can't clear the rx FIFO,
> then the CPU will loop on the espi rx interrupt.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Applied to merge branch for 2.6.27, thanks.
g.
> ---
> The patch 2/2 is againsted on this patch, so I resent this patch again
> for convience which sent several weeks ago.
>
> drivers/spi/spi_fsl_espi.c | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
> index e3b4f64..ae78926 100644
> --- a/drivers/spi/spi_fsl_espi.c
> +++ b/drivers/spi/spi_fsl_espi.c
> @@ -507,16 +507,29 @@ void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)
>
> /* We need handle RX first */
> if (events & SPIE_NE) {
> - u32 rx_data;
> + u32 rx_data, tmp;
> + u8 rx_data_8;
>
> /* Spin until RX is done */
> while (SPIE_RXCNT(events) < min(4, mspi->len)) {
> cpu_relax();
> events = mpc8xxx_spi_read_reg(®_base->event);
> }
> - mspi->len -= 4;
>
> - rx_data = mpc8xxx_spi_read_reg(®_base->receive);
> + if (mspi->len >= 4) {
> + rx_data = mpc8xxx_spi_read_reg(®_base->receive);
> + } else {
> + tmp = mspi->len;
> + rx_data = 0;
> + while (tmp--) {
> + rx_data_8 = in_8((u8 *)®_base->receive);
> + rx_data |= (rx_data_8 << (tmp * 8));
> + }
> +
> + rx_data <<= (4 - mspi->len) * 8;
> + }
> +
> + mspi->len -= 4;
>
> if (mspi->rx)
> mspi->get_rx(rx_data, mspi);
> --
> 1.6.4
>
>
^ permalink raw reply
* Re: [PATCH 2/2] eSPI: fix wrong setting of the address in the command buffer
From: Grant Likely @ 2010-12-24 8:55 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1292894822-7983-1-git-send-email-Mingkai.hu@freescale.com>
On Tue, Dec 21, 2010 at 09:27:02AM +0800, Mingkai Hu wrote:
> Or else we cann't operate on the right address when the trans length
> is greater than 65535.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Applied to merge branch for 2.6.27, thanks.
g.
> ---
> drivers/spi/spi_fsl_espi.c | 16 +++++++++-------
> 1 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
> index ae78926..a99e233 100644
> --- a/drivers/spi/spi_fsl_espi.c
> +++ b/drivers/spi/spi_fsl_espi.c
> @@ -258,18 +258,18 @@ static int fsl_espi_bufs(struct spi_device *spi, struct spi_transfer *t)
> return mpc8xxx_spi->count;
> }
>
> -static void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
> +static inline void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
> {
> - if (cmd[1] && cmd[2] && cmd[3]) {
> + if (cmd) {
> cmd[1] = (u8)(addr >> 16);
> cmd[2] = (u8)(addr >> 8);
> cmd[3] = (u8)(addr >> 0);
> }
> }
>
> -static unsigned int fsl_espi_cmd2addr(u8 *cmd)
> +static inline unsigned int fsl_espi_cmd2addr(u8 *cmd)
> {
> - if (cmd[1] && cmd[2] && cmd[3])
> + if (cmd)
> return cmd[1] << 16 | cmd[2] << 8 | cmd[3] << 0;
>
> return 0;
> @@ -395,9 +395,11 @@ static void fsl_espi_rw_trans(struct spi_message *m,
> }
> }
>
> - addr = fsl_espi_cmd2addr(local_buf);
> - addr += pos;
> - fsl_espi_addr2cmd(addr, local_buf);
> + if (pos > 0) {
> + addr = fsl_espi_cmd2addr(local_buf);
> + addr += pos;
> + fsl_espi_addr2cmd(addr, local_buf);
> + }
>
> espi_trans->n_tx = n_tx;
> espi_trans->n_rx = trans_len;
> --
> 1.6.4
>
>
^ permalink raw reply
* Re: [PATCH 2/3] misc: at24: add more sanity checks for parameters
From: Grant Likely @ 2010-12-24 9:15 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1289995250-17927-3-git-send-email-w.sang@pengutronix.de>
On Wed, Nov 17, 2010 at 01:00:49PM +0100, Wolfram Sang wrote:
> Side-effects happen when passing 0 to either io_limit or page_size. Give
> an error in case of this misconfiguration.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
Applied for -next, thanks.
g.
> drivers/misc/eeprom/at24.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 3a53efc..ab1ad41 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -517,6 +517,11 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> if (!is_power_of_2(chip.byte_len))
> dev_warn(&client->dev,
> "byte_len looks suspicious (no power of 2)!\n");
> + if (!chip.page_size) {
> + dev_err(&client->dev, "page_size must not be 0!\n");
> + err = -EINVAL;
> + goto err_out;
> + }
> if (!is_power_of_2(chip.page_size))
> dev_warn(&client->dev,
> "page_size looks suspicious (no power of 2)!\n");
> @@ -681,6 +686,11 @@ static struct i2c_driver at24_driver = {
>
> static int __init at24_init(void)
> {
> + if (!io_limit) {
> + pr_err("at24: io_limit must not be 0!\n");
> + return -EINVAL;
> + }
> +
> io_limit = rounddown_pow_of_two(io_limit);
> return i2c_add_driver(&at24_driver);
> }
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Grant Likely @ 2010-12-24 9:15 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1289995250-17927-2-git-send-email-w.sang@pengutronix.de>
On Wed, Nov 17, 2010 at 01:00:48PM +0100, Wolfram Sang wrote:
> Information about the pagesize and read-only-status may also come from
> the devicetree. Parse this data, too, and act accordingly. While we are
> here, change the initialization printout a bit. write_max is useful to
> know to detect performance bottlenecks, the rest is superfluous.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied for -next, thanks.
g.
> ---
>
> Changes since last version:
>
> - use __be32 instead of u32
>
> Documentation/powerpc/dts-bindings/eeprom.txt | 28 +++++++++++++++++++++
> drivers/misc/eeprom/at24.c | 33 ++++++++++++++++++++----
> 2 files changed, 55 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt b/Documentation/powerpc/dts-bindings/eeprom.txt
> new file mode 100644
> index 0000000..4342c10
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/eeprom.txt
> @@ -0,0 +1,28 @@
> +EEPROMs (I2C)
> +
> +Required properties:
> +
> + - compatible : should be "<manufacturer>,<type>"
> + If there is no specific driver for <manufacturer>, a generic
> + driver based on <type> is selected. Possible types are:
> + 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
> + 24c128, 24c256, 24c512, 24c1024, spd
> +
> + - reg : the I2C address of the EEPROM
> +
> +Optional properties:
> +
> + - pagesize : the length of the pagesize for writing. Please consult the
> + manual of your device, that value varies a lot. A wrong value
> + may result in data loss! If not specified, a safety value of
> + '1' is used which will be very slow.
> +
> + - read-only: this parameterless property disables writes to the eeprom
> +
> +Example:
> +
> +eeprom@52 {
> + compatible = "atmel,24c32";
> + reg = <0x52>;
> + pagesize = <32>;
> +};
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 559b0b3..3a53efc 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -20,6 +20,7 @@
> #include <linux/log2.h>
> #include <linux/bitops.h>
> #include <linux/jiffies.h>
> +#include <linux/of.h>
> #include <linux/i2c.h>
> #include <linux/i2c/at24.h>
>
> @@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor *macc, const char *buf,
>
> /*-------------------------------------------------------------------------*/
>
> +#ifdef CONFIG_OF
> +static void at24_get_ofdata(struct i2c_client *client,
> + struct at24_platform_data *chip)
> +{
> + const __be32 *val;
> + struct device_node *node = client->dev.of_node;
> +
> + if (node) {
> + if (of_get_property(node, "read-only", NULL))
> + chip->flags |= AT24_FLAG_READONLY;
> + val = of_get_property(node, "pagesize", NULL);
> + if (val)
> + chip->page_size = be32_to_cpup(val);
> + }
> +}
> +#else
> +static void at24_get_ofdata(struct i2c_client *client,
> + struct at24_platform_data *chip)
> +{ }
> +#endif /* CONFIG_OF */
> +
> static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> struct at24_platform_data chip;
> @@ -485,6 +507,9 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> */
> chip.page_size = 1;
>
> + /* update chipdata if OF is present */
> + at24_get_ofdata(client, &chip);
> +
> chip.setup = NULL;
> chip.context = NULL;
> }
> @@ -597,19 +622,15 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
>
> i2c_set_clientdata(client, at24);
>
> - dev_info(&client->dev, "%zu byte %s EEPROM %s\n",
> + dev_info(&client->dev, "%zu byte %s EEPROM, %s, %u bytes/write\n",
> at24->bin.size, client->name,
> - writable ? "(writable)" : "(read-only)");
> + writable ? "writable" : "read-only", at24->write_max);
> if (use_smbus == I2C_SMBUS_WORD_DATA ||
> use_smbus == I2C_SMBUS_BYTE_DATA) {
> dev_notice(&client->dev, "Falling back to %s reads, "
> "performance will suffer\n", use_smbus ==
> I2C_SMBUS_WORD_DATA ? "word" : "byte");
> }
> - dev_dbg(&client->dev,
> - "page_size %d, num_addresses %d, write_max %d, use_smbus %d\n",
> - chip.page_size, num_addresses,
> - at24->write_max, use_smbus);
>
> /* export data to kernel code */
> if (chip.setup)
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: pcm030/032: add pagesize to dts
From: Grant Likely @ 2010-12-24 9:15 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1289995250-17927-4-git-send-email-w.sang@pengutronix.de>
On Wed, Nov 17, 2010 at 01:00:50PM +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied for -next, thanks.
g.
> ---
> arch/powerpc/boot/dts/pcm030.dts | 1 +
> arch/powerpc/boot/dts/pcm032.dts | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
> index 8a4ec30..e7c36bc 100644
> --- a/arch/powerpc/boot/dts/pcm030.dts
> +++ b/arch/powerpc/boot/dts/pcm030.dts
> @@ -259,6 +259,7 @@
> eeprom@52 {
> compatible = "catalyst,24c32";
> reg = <0x52>;
> + pagesize = <32>;
> };
> };
>
> diff --git a/arch/powerpc/boot/dts/pcm032.dts b/arch/powerpc/boot/dts/pcm032.dts
> index 85d857a..e175e2c 100644
> --- a/arch/powerpc/boot/dts/pcm032.dts
> +++ b/arch/powerpc/boot/dts/pcm032.dts
> @@ -257,8 +257,9 @@
> reg = <0x51>;
> };
> eeprom@52 {
> - compatible = "at24,24c32";
> + compatible = "catalyst,24c32";
> reg = <0x52>;
> + pagesize = <32>;
> };
> };
>
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH RESEND] pata_mpc52xx: driver needs BMDMA
From: Jeff Garzik @ 2010-12-24 18:38 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Andrew Morton, linux-kernel, linux-ide
In-Reply-To: <1293033011-19265-1-git-send-email-w.sang@pengutronix.de>
On 12/22/2010 10:50 AM, Wolfram Sang wrote:
> Found by this build-error if BMDMA is disabled:
>
> drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
> drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
> ...
>
> Move the Kconfig entry to the proper location as needed since
> 9a7780c9acb821fe1c2b6fc53f74cc2556ff5364 (libata-sff: make BMDMA optional)
>
> Signed-off-by: Wolfram Sang<w.sang@pengutronix.de>
> ---
>
> This is a build-failure, so fixing it before 2.6.37 would be great.
>
> drivers/ata/Kconfig | 20 ++++++++++----------
> drivers/ata/Makefile | 2 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH][GIT PULL] powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
From: Benjamin Herrenschmidt @ 2010-12-24 21:11 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, Andrew Morton, Joerg Sommer, LKML
In-Reply-To: <1293169566.22802.420.camel@gandalf.stny.rr.com>
On Fri, 2010-12-24 at 00:46 -0500, Steven Rostedt wrote:
> arch/powerpc/include/asm/irqflags.h | 40 ++++++++++++++++++++++++++--------
> 1 files changed, 30 insertions(+), 10 deletions(-)
> ---------------------------
> commit 5025019505da6731f8be13940bb978617599c935
> Author: Steven Rostedt <srostedt@redhat.com>
> Date: Thu Dec 23 21:07:39 2010 -0800
>
> powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
>
> When an interrupt occurs in userspace, we can call trace_hardirqs_on/off()
> With one level stack. But if we have irqsoff tracing enabled,
> it checks both CALLER_ADDR0 and CALLER_ADDR1. The second call
> goes two stack frames up. If this is from user space, then there may
> not exist a second stack.
>
> Add a second stack when calling trace_hardirqs_on/off() otherwise
> the following oops might occur:
Hrm... this is really gross :-) So we add gratuituous overhead because
the code below is dumb :-) What about making the code less stupid
instead when poking at the stack and detect it's coming from userspace
instead ?
Cheers,
Ben.
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT SMP NR_CPUS=2 PA Semi PWRficient
> last sysfs file: /sys/block/sda/size
> Modules linked in: ohci_hcd ehci_hcd usbcore
> NIP: c0000000000e1c00 LR: c0000000000034d4 CTR: 000000011012c440
> REGS: c00000003e2f3af0 TRAP: 0300 Not tainted (2.6.37-rc6+)
> MSR: 9000000000001032 <ME,IR,DR> CR: 48044444 XER: 20000000
> DAR: 00000001ffb9db50, DSISR: 0000000040000000
> TASK = c00000003e1a00a0[2088] 'emacs' THREAD: c00000003e2f0000 CPU: 1
> GPR00: 0000000000000001 c00000003e2f3d70 c00000000084e0d0 c0000000008816e8
> GPR04: 000000001034c678 000000001032e8f9 0000000010336540 0000000040020000
> GPR08: 0000000040020000 00000001ffb9db40 c00000003e2f3e30 0000000060000000
> GPR12: 100000000000f032 c00000000fff0280 000000001032e8c9 0000000000000008
> GPR16: 00000000105be9c0 00000000105be950 00000000105be9b0 00000000105be950
> GPR20: 00000000ffb9dc50 00000000ffb9dbf0 00000000102f0000 00000000102f0000
> GPR24: 00000000102e0000 00000000102f0000 0000000010336540 c0000000009ded38
> GPR28: 00000000102e0000 c0000000000034d4 c0000000007ccb10 c00000003e2f3d70
> NIP [c0000000000e1c00] .trace_hardirqs_off+0xb0/0x1d0
> LR [c0000000000034d4] decrementer_common+0xd4/0x100
> Call Trace:
> [c00000003e2f3d70] [c00000003e2f3e30] 0xc00000003e2f3e30 (unreliable)
> [c00000003e2f3e30] [c0000000000034d4] decrementer_common+0xd4/0x100
> Instruction dump:
> 81690000 7f8b0000 419e0018 f84a0028 60000000 60000000 60000000 e95f0000
> 80030000 e92a0000 eb6301f8 2f800000 <eb890010> 41fe00dc a06d000a eb1e8050
> ---[ end trace 4ec7fd2be9240928 ]---
>
> Reported-by: Joerg Sommer <joerg@alea.gnuu.de>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
> diff --git a/arch/powerpc/include/asm/irqflags.h b/arch/powerpc/include/asm/irqflags.h
> index b85d8dd..b0b06d8 100644
> --- a/arch/powerpc/include/asm/irqflags.h
> +++ b/arch/powerpc/include/asm/irqflags.h
> @@ -12,24 +12,44 @@
>
> #else
> #ifdef CONFIG_TRACE_IRQFLAGS
> +#ifdef CONFIG_IRQSOFF_TRACER
> +/*
> + * Since the ftrace irqsoff latency trace checks CALLER_ADDR1,
> + * which is the stack frame here, we need to force a stack frame
> + * in case we came from user space.
> + */
> +#define TRACE_WITH_FRAME_BUFFER(func) \
> + mflr r0; \
> + stdu r1, -32(r1); \
> + std r0, 16(r1); \
> + stdu r1, -32(r1); \
> + bl func; \
> + ld r1, 0(r1); \
> + ld r1, 0(r1);
> +#else
> +#define TRACE_WITH_FRAME_BUFFER(func) \
> + bl func;
> +#endif
> +
> /*
> * Most of the CPU's IRQ-state tracing is done from assembly code; we
> * have to call a C function so call a wrapper that saves all the
> * C-clobbered registers.
> */
> -#define TRACE_ENABLE_INTS bl .trace_hardirqs_on
> -#define TRACE_DISABLE_INTS bl .trace_hardirqs_off
> -#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
> - cmpdi en,0; \
> - bne 95f; \
> - stb en,PACASOFTIRQEN(r13); \
> - bl .trace_hardirqs_off; \
> - b skip; \
> -95: bl .trace_hardirqs_on; \
> +#define TRACE_ENABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_on)
> +#define TRACE_DISABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_off)
> +
> +#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
> + cmpdi en,0; \
> + bne 95f; \
> + stb en,PACASOFTIRQEN(r13); \
> + TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_off) \
> + b skip; \
> +95: TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_on) \
> li en,1;
> #define TRACE_AND_RESTORE_IRQ(en) \
> TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \
> - stb en,PACASOFTIRQEN(r13); \
> + stb en,PACASOFTIRQEN(r13); \
> 96:
> #else
> #define TRACE_ENABLE_INTS
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] powerpc: use simple_read_from_buffer
From: Akinobu Mita @ 2010-12-25 6:03 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Paul Mackerras, Akinobu Mita
Simplify read file operation for /proc/powerpc/rtas/* interface
by using simple_read_from_buffer.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/rtas_flash.c | 53 ++++---------------------------------
1 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index 2b442e6..bf5f5ce 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -256,31 +256,16 @@ static ssize_t rtas_flash_read(struct file *file, char __user *buf,
struct proc_dir_entry *dp = PDE(file->f_path.dentry->d_inode);
struct rtas_update_flash_t *uf;
char msg[RTAS_MSG_MAXLEN];
- int msglen;
- uf = (struct rtas_update_flash_t *) dp->data;
+ uf = dp->data;
if (!strcmp(dp->name, FIRMWARE_FLASH_NAME)) {
get_flash_status_msg(uf->status, msg);
} else { /* FIRMWARE_UPDATE_NAME */
sprintf(msg, "%d\n", uf->status);
}
- msglen = strlen(msg);
- if (msglen > count)
- msglen = count;
-
- if (ppos && *ppos != 0)
- return 0; /* be cheap */
-
- if (!access_ok(VERIFY_WRITE, buf, msglen))
- return -EINVAL;
- if (copy_to_user(buf, msg, msglen))
- return -EFAULT;
-
- if (ppos)
- *ppos = msglen;
- return msglen;
+ return simple_read_from_buffer(buf, count, ppos, msg, strlen(msg));
}
/* constructor for flash_block_cache */
@@ -394,26 +379,13 @@ static ssize_t manage_flash_read(struct file *file, char __user *buf,
char msg[RTAS_MSG_MAXLEN];
int msglen;
- args_buf = (struct rtas_manage_flash_t *) dp->data;
+ args_buf = dp->data;
if (args_buf == NULL)
return 0;
msglen = sprintf(msg, "%d\n", args_buf->status);
- if (msglen > count)
- msglen = count;
- if (ppos && *ppos != 0)
- return 0; /* be cheap */
-
- if (!access_ok(VERIFY_WRITE, buf, msglen))
- return -EINVAL;
-
- if (copy_to_user(buf, msg, msglen))
- return -EFAULT;
-
- if (ppos)
- *ppos = msglen;
- return msglen;
+ return simple_read_from_buffer(buf, count, ppos, msg, msglen);
}
static ssize_t manage_flash_write(struct file *file, const char __user *buf,
@@ -495,24 +467,11 @@ static ssize_t validate_flash_read(struct file *file, char __user *buf,
char msg[RTAS_MSG_MAXLEN];
int msglen;
- args_buf = (struct rtas_validate_flash_t *) dp->data;
+ args_buf = dp->data;
- if (ppos && *ppos != 0)
- return 0; /* be cheap */
-
msglen = get_validate_flash_msg(args_buf, msg);
- if (msglen > count)
- msglen = count;
-
- if (!access_ok(VERIFY_WRITE, buf, msglen))
- return -EINVAL;
-
- if (copy_to_user(buf, msg, msglen))
- return -EFAULT;
- if (ppos)
- *ppos = msglen;
- return msglen;
+ return simple_read_from_buffer(buf, count, ppos, msg, msglen);
}
static ssize_t validate_flash_write(struct file *file, const char __user *buf,
--
1.7.3.4
^ permalink raw reply related
* [PATCH] spufs: use simple_write_to_buffer
From: Akinobu Mita @ 2010-12-25 6:03 UTC (permalink / raw)
To: linux-kernel
Cc: cbe-oss-dev, Akinobu Mita, Paul Mackerras, Jeremy Kerr,
linuxppc-dev
Simplify several write fileoperations for spufs by using
simple_write_to_buffer().
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-dev@lists.ozlabs.org
---
arch/powerpc/platforms/cell/spufs/file.c | 27 +++++++--------------------
1 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 02f7b11..3c7c3f8 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -219,24 +219,17 @@ spufs_mem_write(struct file *file, const char __user *buffer,
loff_t pos = *ppos;
int ret;
- if (pos < 0)
- return -EINVAL;
if (pos > LS_SIZE)
return -EFBIG;
- if (size > LS_SIZE - pos)
- size = LS_SIZE - pos;
ret = spu_acquire(ctx);
if (ret)
return ret;
local_store = ctx->ops->get_ls(ctx);
- ret = copy_from_user(local_store + pos, buffer, size);
+ size = simple_write_to_buffer(local_store, LS_SIZE, ppos, buffer, size);
spu_release(ctx);
- if (ret)
- return -EFAULT;
- *ppos = pos + size;
return size;
}
@@ -574,18 +567,15 @@ spufs_regs_write(struct file *file, const char __user *buffer,
if (*pos >= sizeof(lscsa->gprs))
return -EFBIG;
- size = min_t(ssize_t, sizeof(lscsa->gprs) - *pos, size);
- *pos += size;
-
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
- ret = copy_from_user((char *)lscsa->gprs + *pos - size,
- buffer, size) ? -EFAULT : size;
+ size = simple_write_to_buffer(lscsa->gprs, sizeof(lscsa->gprs), pos,
+ buffer, size);
spu_release_saved(ctx);
- return ret;
+ return size;
}
static const struct file_operations spufs_regs_fops = {
@@ -630,18 +620,15 @@ spufs_fpcr_write(struct file *file, const char __user * buffer,
if (*pos >= sizeof(lscsa->fpcr))
return -EFBIG;
- size = min_t(ssize_t, sizeof(lscsa->fpcr) - *pos, size);
-
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
- *pos += size;
- ret = copy_from_user((char *)&lscsa->fpcr + *pos - size,
- buffer, size) ? -EFAULT : size;
+ size = simple_write_to_buffer(&lscsa->fpcr, sizeof(lscsa->fpcr), pos,
+ buffer, size);
spu_release_saved(ctx);
- return ret;
+ return size;
}
static const struct file_operations spufs_fpcr_fops = {
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH][GIT PULL] powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
From: Steven Rostedt @ 2010-12-25 21:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Andrew Morton, Joerg Sommer, LKML
In-Reply-To: <1293225065.16694.796.camel@pasglop>
On Sat, 2010-12-25 at 08:11 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2010-12-24 at 00:46 -0500, Steven Rostedt wrote:
>
> > arch/powerpc/include/asm/irqflags.h | 40 ++++++++++++++++++++++++++--------
> > 1 files changed, 30 insertions(+), 10 deletions(-)
> > ---------------------------
> > commit 5025019505da6731f8be13940bb978617599c935
> > Author: Steven Rostedt <srostedt@redhat.com>
> > Date: Thu Dec 23 21:07:39 2010 -0800
> >
> > powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
> >
> > When an interrupt occurs in userspace, we can call trace_hardirqs_on/off()
> > With one level stack. But if we have irqsoff tracing enabled,
> > it checks both CALLER_ADDR0 and CALLER_ADDR1. The second call
> > goes two stack frames up. If this is from user space, then there may
> > not exist a second stack.
> >
> > Add a second stack when calling trace_hardirqs_on/off() otherwise
> > the following oops might occur:
>
> Hrm... this is really gross :-) So we add gratuituous overhead because
> the code below is dumb :-) What about making the code less stupid
> instead when poking at the stack and detect it's coming from userspace
> instead ?
Note, when CONFIG_IRQSOFF_TRACE is set, there's already a bit of
overhead :-)
Anyway, I'll have to take a look at how the frame pointer is set up. Or
we could also set up all stacks coming into the kernel to have a "dummy"
frame pointer that wont hurt anything if we index into it.
Anyway, I'm off till the new year, so I'll worry about it then ;-)
-- Steve
^ permalink raw reply
* Re: Oops in trace_hardirqs_on (powerpc)
From: Jörg Sommer @ 2010-12-26 0:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <1293072176.22802.6.camel@gandalf.stny.rr.com>
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
Hi Steven,
Steven Rostedt hat am Wed 22. Dec, 21:42 (-0500) geschrieben:
> On Sun, 2010-12-19 at 14:27 +0100, Jörg Sommer wrote:
> > Did you've fixed this problem? The bug report is still marked as open.
> > https://bugzilla.kernel.org/show_bug.cgi?id=16573
> >
>
> I just posted a patch to that BZ. I have it here below too. Could you
> see if it fixes you problem. I only fixed the one place that you
> reported, it may need more fixes (and in that case a macro to do the
> work).
>
> I hit the same bug on my ppc64 box, and have a fix for that, that I'll
> post to LKML tomorrow.
>
> -- Steve
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index ed4aeb9..915cc03 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -879,7 +879,18 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
> */
> andi. r10,r9,MSR_EE
> beq 1f
> + /*
> + * Since the ftrace irqsoff latency trace checks CALLER_ADDR1,
> + * which is the stack frame here, we need to force a stack frame
> + * in case we came from user space.
> + */
> + stwu r1,-32(r1)
> + mflr r0
> + stw r0,4(r1)
> + stwu r1,-32(r1)
> bl trace_hardirqs_on
> + lwz r1,0(r1)
> + lwz r1,0(r1)
> lwz r9,_MSR(r1)
> 1:
> #endif /* CONFIG_TRACE_IRQFLAGS */
This patch eliminates the oopses.
Bye, Jörg.
--
Der Klügere gibt so lange nach bis er der Dumme ist.
[-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH][GIT PULL] powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
From: Benjamin Herrenschmidt @ 2010-12-27 21:38 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, Andrew Morton, Joerg Sommer, LKML
In-Reply-To: <1293311043.22802.434.camel@gandalf.stny.rr.com>
On Sat, 2010-12-25 at 16:04 -0500, Steven Rostedt wrote:
>
> Note, when CONFIG_IRQSOFF_TRACE is set, there's already a bit of
> overhead :-)
>
> Anyway, I'll have to take a look at how the frame pointer is set up.
> Or
> we could also set up all stacks coming into the kernel to have a
> "dummy"
> frame pointer that wont hurt anything if we index into it.
>
> Anyway, I'm off till the new year, so I'll worry about it then ;-)
Right, might be simpler to just make them loop back onto themselves or
something like that. I can have a look too if I get a chance.
Cheers,
Ben.
^ permalink raw reply
* PMU_IOC_SLEEP failed
From: jjDaNiMoTh @ 2010-12-28 12:25 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
what could be the problem here?
[root@myhost ~]# /usr/lib/hal/hal-system-power-pmu sleep
power-pmu : PMU_IOC_SLEEP failed
(same with pm-suspend, kernel version: any >= 2.6.33. I'm now on a .37-rc).
KMS is disabled (modprobe radeon modeset=0, and I can't switch over VT).
userspace thing has kms for radeon disabled (libdrm, mesa, xf86-video-ati).
There are some important parts of config should I attach?
Thanks
^ permalink raw reply
* Hang in Freescale Host Controller
From: Sabari @ 2010-12-28 13:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
Hi,
I am expereincing some sort of end less loop in FHCI, we are using linux
2.6.11 on MPC836X we got as part of BSP from freescale. When we connect the
usb device and try to do some data transfer we see an endless loop happens
in function
scan_ed_list(..) of fhci-hcd.c when list_type BULK list is passed to it.
Is any one faced similar issue on the freescale host controller interface
for any USB device? If so tell us how you have overcomed this issue.
Thanks,
Sabari.
[-- Attachment #2: Type: text/html, Size: 620 bytes --]
^ permalink raw reply
* Re: PMU_IOC_SLEEP failed
From: Michel Dänzer @ 2010-12-28 15:32 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev
In-Reply-To: <AANLkTiksBGDR=vJLArgShP8U_NWZ2OWXc65wiXRLv4kr@mail.gmail.com>
On Die, 2010-12-28 at 13:25 +0100, jjDaNiMoTh wrote:=20
>=20
> what could be the problem here?
>=20
> [root@myhost ~]# /usr/lib/hal/hal-system-power-pmu sleep
> power-pmu : PMU_IOC_SLEEP failed
>=20
> (same with pm-suspend, kernel version: any >=3D 2.6.33. I'm now on a .37-=
rc).
>=20
> KMS is disabled (modprobe radeon modeset=3D0, and I can't switch over VT)=
.
What exactly does "can't switch over VT" mean?
Sleep requires radeonfb, is that enabled?
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH] of_mmc_spi: add card detect irq support
From: Anton Vorontsov @ 2010-12-28 16:05 UTC (permalink / raw)
To: Grant Likely
Cc: David Brownell, Esben Haabendal, linux-mmc, David Brownell,
Andrew Morton, linuxppc-dev
In-Reply-To: <AANLkTimXJ-hSz3O1xPgLsZLxwkwBeqrW+gAmR8+6jGoW@mail.gmail.com>
On Mon, Aug 30, 2010 at 11:49:08AM -0600, Grant Likely wrote:
> On Mon, Aug 30, 2010 at 10:38 AM, David Brownell <david-b@pacbell.net> wrote:
> > Since I don't do OpenFirmware, let's hear from
> > Grant on this one.
>
> Looks good to me.
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
I wonder what happened with this patch?
Thanks,
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: PMU_IOC_SLEEP failed
From: jjDaNiMoTh @ 2010-12-28 16:39 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev
In-Reply-To: <1293550353.19556.224.camel@thor.local>
2010/12/28 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> What exactly does "can't switch over VT" mean?
After X is running, I can't switch over ctrl + alt + f{1,2,3,4,5,6}
consoles ( the screen flicker, then blank ). If I switch to f7, where
X live, all return to normal and I can see normal X window.
This doesn't happend with X active.
> Sleep requires radeonfb, is that enabled?
Of course, but I think there is something wrong:
(dmesg..)
[...]
radeonfb_pci_register BEGIN
radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0xb8000000-0xbfffffff pref=
]
radeonfb (0000:00:10.0): cannot request region 0.
radeonfb: probe of 0000:00:10.0 failed with error -16
^ permalink raw reply
* Re: PMU_IOC_SLEEP failed
From: Benjamin Herrenschmidt @ 2010-12-28 20:54 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinBQAMvmmNP5S_=++UOQDoTe-1efD39VF0PO5kB@mail.gmail.com>
On Tue, 2010-12-28 at 17:39 +0100, jjDaNiMoTh wrote:
> 2010/12/28 Michel Dänzer <michel@daenzer.net>:
> [cut]
> > What exactly does "can't switch over VT" mean?
> After X is running, I can't switch over ctrl + alt + f{1,2,3,4,5,6}
> consoles ( the screen flicker, then blank ). If I switch to f7, where
> X live, all return to normal and I can see normal X window.
> This doesn't happend with X active.
>
> > Sleep requires radeonfb, is that enabled?
>
> Of course, but I think there is something wrong:
>
> (dmesg..)
> [...]
> radeonfb_pci_register BEGIN
> radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0xb8000000-0xbfffffff pref]
> radeonfb (0000:00:10.0): cannot request region 0.
> radeonfb: probe of 0000:00:10.0 failed with error -16
That looks bad indeed. Send me the complete dmesg, a snapshot of the
device-tree (tar -c /proc/device-tree >foo.tar) and the output
of /proc/iomem please.
Cheers,
Ben.
^ permalink raw reply
* Re: PMU_IOC_SLEEP failed
From: jjDaNiMoTh @ 2010-12-28 23:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1293569648.17779.20.camel@pasglop>
2010/12/28 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Tue, 2010-12-28 at 17:39 +0100, jjDaNiMoTh wrote:
>> 2010/12/28 Michel D=C3=A4nzer <michel@daenzer.net>:
>> [cut]
>> > What exactly does "can't switch over VT" mean?
>> After X is running, I can't switch over ctrl + alt + f{1,2,3,4,5,6}
>> consoles ( the screen flicker, then blank ). If I switch to f7, where
>> X live, all return to normal and I can see normal X window.
>> This doesn't happend with X active.
>>
>> > Sleep requires radeonfb, is that enabled?
>>
>> Of course, but I think there is something wrong:
>>
>> (dmesg..)
>> [...]
>> radeonfb_pci_register BEGIN
>> radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0xb8000000-0xbfffffff p=
ref]
>> radeonfb (0000:00:10.0): cannot request region 0.
>> radeonfb: probe of 0000:00:10.0 failed with error -16
>
> That looks bad indeed. Send me the complete dmesg, a snapshot of the
> device-tree (tar -c /proc/device-tree >foo.tar) and the output
> of /proc/iomem please.
[1] http://nat.vacau.com/linux/iomem.txt.gz
[2] http://nat.vacau.com/linux/dmesg_37-rc.txt.gz
[3] http://nat.vacau.com/linux/device_tree.tar
Thank you
^ 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