* [PATCH] DTC: Remove an unneeded %token definition.
From: Jon Loeliger @ 2007-10-22 22:00 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
dtc-parser.y | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index c213526..61ed250 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -55,7 +55,6 @@ extern struct boot_info *the_boot_info;
%token <str> DT_CELL
%token <byte> DT_BYTE
%token <data> DT_STRING
-%token <str> DT_UNIT
%token <str> DT_LABEL
%token <str> DT_REF
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* [PATCH] DTC: Minor grammar rule shuffle.
From: Jon Loeliger @ 2007-10-22 21:59 UTC (permalink / raw)
To: linuxppc-dev
I like to see the basis cases established early in
the rule sets, so place "empty" reduction first.
Purely cosmetic.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
dtc-parser.y | 62 +++++++++++++++++++++++++++++-----------------------------
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 0d140e5..c213526 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -86,13 +86,13 @@ sourcefile:
;
memreserves:
- memreserve memreserves
+ /* empty */
{
- $$ = chain_reserve_entry($1, $2);
+ $$ = NULL;
}
- | /* empty */
+ | memreserve memreserves
{
- $$ = NULL;
+ $$ = chain_reserve_entry($1, $2);
}
;
@@ -122,13 +122,13 @@ nodedef:
;
proplist:
- proplist propdef
+ /* empty */
{
- $$ = chain_property($2, $1);
+ $$ = NULL;
}
- | /* empty */
+ | proplist propdef
{
- $$ = NULL;
+ $$ = chain_property($2, $1);
}
;
@@ -164,7 +164,11 @@ propdata:
;
propdataprefix:
- propdata ','
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | propdata ','
{
$$ = $1;
}
@@ -172,10 +176,6 @@ propdataprefix:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
opt_cell_base:
@@ -187,7 +187,11 @@ opt_cell_base:
;
celllist:
- celllist opt_cell_base DT_CELL
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | celllist opt_cell_base DT_CELL
{
$$ = data_append_cell($1,
cell_from_string($3, $2));
@@ -200,14 +204,14 @@ celllist:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
bytestring:
- bytestring DT_BYTE
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | bytestring DT_BYTE
{
$$ = data_append_byte($1, $2);
}
@@ -215,20 +219,16 @@ bytestring:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
subnodes:
- subnode subnodes
+ /* empty */
{
- $$ = chain_node($1, $2);
+ $$ = NULL;
}
- | /* empty */
+ | subnode subnodes
{
- $$ = NULL;
+ $$ = chain_node($1, $2);
}
;
@@ -251,13 +251,13 @@ nodename:
;
label:
- DT_LABEL
+ /* empty */
{
- $$ = $1;
+ $$ = NULL;
}
- | /* empty */
+ | DT_LABEL
{
- $$ = NULL;
+ $$ = $1;
}
;
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Benjamin Herrenschmidt @ 2007-10-22 21:24 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <20071022181336.GC4280@austin.ibm.com>
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote:
> On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
> >
> > On pseries there's a chance it will work for PCI error recovery, but if
> > so it's just lucky that firmware has left everything configured the same
> > way.
>
> ? The papr is quite clear that i is up to the OS to restore the msi
> state after an eeh error.
Via direct config space access or via firmware change-msi calls ?
> > Yes I think so. That way we can properly reconfigure via the firmware
> > interface. The other option would be to design some new arch hook to do
> > resume, but just doing a disable/enable seems simpler to me.
>
> Err, If you read the code for suspend/resume, it never actually calls
> disable/enable (and thus doesn't go to the firmware); it calls
> restore_msi_state() function!
>
> If suspend/resume needs to call firmware to restore the state, then,
> at the moment, suspend/resume is broken. As I mentioned earlier,
> I presumed that no powerpc laptops currently use msi-enabled devices,
> as otherwise, this would have been flushed out.
I don't know why you keep talking about powerpc laptops here ...
Ben.
^ permalink raw reply
* [PATCH] DTC: Remove the need for the GLR Parser.
From: Jon Loeliger @ 2007-10-22 21:13 UTC (permalink / raw)
To: linuxppc-dev
Previously, there were a few shift/reduce and reduce/reduce
errors in the grammar that were being handled by the not-so-popular
GLR Parser technique.
Flip a right-recursive stack-abusing rule into a left-recursive
stack-friendly rule and clear up three messes in one shot: No more
conflicts, no need for the GLR parser, and friendlier stackness.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Makefile | 1 -
dtc-parser.y | 5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
Both "make check" and the "compare all old and new DTB kernel files"
tests are happy with this change.
diff --git a/Makefile b/Makefile
index d7d1af5..84f0efe 100644
--- a/Makefile
+++ b/Makefile
@@ -207,7 +207,6 @@ clean: libfdt_clean tests_clean
%.tab.c %.tab.h %.output: %.y
@$(VECHO) BISON $@
- @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
$(BISON) -d $<
FORCE:
diff --git a/dtc-parser.y b/dtc-parser.y
index 4698793..0d140e5 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -18,7 +18,6 @@
* USA
*/
-%glr-parser
%locations
%{
@@ -123,9 +122,9 @@ nodedef:
;
proplist:
- propdef proplist
+ proplist propdef
{
- $$ = chain_property($1, $2);
+ $$ = chain_property($2, $1);
}
| /* empty */
{
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* Re: request_irq fails to get interrupt 12
From: Benjamin Herrenschmidt @ 2007-10-22 20:33 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710221255ubbe8c91pa09640f9b9cd0775@mail.gmail.com>
On Mon, 2007-10-22 at 13:55 -0600, Alan Bennett wrote:
> Ok, so what does it take to expose an interrupt vector on a pq2 PIC??
> -Alan
Also, if it's the default PIC or if you happen to have the PIC struct
irq_host pointer at hand, a quickish way for internal device interrupts
is to directly call irq_create_mapping() though using the device-tree is
nicer.
Ben.
> Current:
> /
> localbus{
> ...
> fundevice1 {
> interrupts = <c 8>;
> interrupt-parent = <&PIC>;
> };
> ...
> soc@e0000000 {
> PIC: interrupt-controller@10c00 {
> #interrupt-cells = <2>;
> interrupt-controller;
> reg = <10c00 80>;
> compatible = "fsl,mpc8248-pic", "fsl,pq2-pic";
> };
> Is the above device tree enough on its own?
> Do I have to write some platform code beyond:
> static void __init ep8248_pic_init(void)
> {
> struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
> if (!np) {
> printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
> return;
> }
>
> cpm2_pic_init(np);
> of_node_put(np);
> }
>
> -Alan
>
> Hello,
>
> > Freescale experts. Why on earth can't I request the IRQ for Timer1?
>
> Please consule my question on [1] and the answers.
>
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html
>
> bye
> Silvio Fricke
>
> --
> -- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
> Diplom-Informatiker (FH)
> Linux-Entwicklung
> ----------------------------------------------------------------------------
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC/PATCH 2/2] powerpc: irqtrace support to 64-bit powerpc
From: Benjamin Herrenschmidt @ 2007-10-22 20:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1193060107.9793.8.camel@johannes.berg>
On Mon, 2007-10-22 at 15:35 +0200, Johannes Berg wrote:
> On Mon, 2007-10-15 at 17:28 +1000, Benjamin Herrenschmidt wrote:
> > This adds the low level irq tracing hooks to the powerpc architecture
> > needed to enable full lockdep functionality
> >
> > Some rework from Johannes initial version, removing the asm trampoline that
> > isn't needed (thus improving perfs) and fixing a couple of bugs such as
> > incorrect initial preempt_count on the softirq alternate stack.
>
> Hmm. It breaks booting on my quad, I finally got around to testing
> without this patch and it turns out that it caused the boot failure I
> reported in another mail. This is with v2.6.23-6623-g55b70a0, a clean
> tree boots fine but with these two patches applied and configured in it
> fails during boot, hanging at some point, apparently when userspace is
> entered.
>
> On the other hand, it is fine with my original version. I'll have to
> find some time to check the differences hunk by hunk I guess.
Or I can try on my quad :-) I'll have a look. It did boot on some other
machines though. Funny.
Ben.
^ permalink raw reply
* Re: request_irq fails to get interrupt 12
From: Alan Bennett @ 2007-10-22 19:55 UTC (permalink / raw)
To: linuxppc-dev
Ok, so what does it take to expose an interrupt vector on a pq2 PIC??
-Alan
Current:
/
localbus{
...
fundevice1 {
interrupts = <c 8>;
interrupt-parent = <&PIC>;
};
...
soc@e0000000 {
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8248-pic", "fsl,pq2-pic";
};
Is the above device tree enough on its own?
Do I have to write some platform code beyond:
static void __init ep8248_pic_init(void)
{
struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
if (!np) {
printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
return;
}
cpm2_pic_init(np);
of_node_put(np);
}
-Alan
Hello,
> Freescale experts. Why on earth can't I request the IRQ for Timer1?
Please consule my question on [1] and the answers.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html
bye
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Linas Vepstas @ 2007-10-22 19:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, mcarlson, linuxppc-dev, mchan, linux-pci
In-Reply-To: <20071019.175308.54212640.davem@davemloft.net>
On Fri, Oct 19, 2007 at 05:53:08PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 19 Oct 2007 19:46:10 -0500
>
> > FWIW, it looks like not all that many arches do this; the output
> > for grep -r address_hi * is pretty thin. Then, looking at
> > i386/kernel/io_apic.c as an example, one can see that the
> > msi state save happens "by accident" if CONFIG_SMP is enabled;
> > and so its surely broekn on uniprocesor machines.
>
> I don't see this, in all cases write_msi_msg() will transfer
> the given "*msg" to entry->msg by this assignment in
> drivers/pci/msi.c:
>
> void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> {
> ...
> entry->msg = *msg;
> }
>
> So as long as write_msi_msg() is invoked, it will be saved
> properly.
As Michael Ellerman points out, the pseries msi setup is done
by firmware, and so this bit never happens.
As discussed in the other thread, I'll try to set up a patch
for an arch callback for restoring msi state.
-linas
^ permalink raw reply
* Re: Device trees and audio codecs
From: Segher Boessenkool @ 2007-10-22 18:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710211729k2f2a065cm56670d1b0f90a1af@mail.gmail.com>
It seems to me there are four issues here:
1) How to describe the audio transport controller;
2) How to describe the codecs;
3) How the various parts are connected together in the device tree;
4) How to describe the "layout".
>>> How do we want to be consistent with the Efika which uses an AC97
>>> codec that only connects to i2s?
>>
>> Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S
>> device if you do all the interleaving and whatever stuff by hand --
>> but
>> then you probably shouldn't call the I2S "host" an I2S anymore, but
>> name
>> it "ac97" in the device tree, or
>> "this-or-that-i2s-controller-hooked-up-
>> in-this-particular-crazy-way". You will want to know which driver to
>> use for the device, and if it's hooked up in "strange and unforeseen"
>> ways you want to know about it.
>
> I meant an ac97 bus. ac97 is conceptually the same as i2s with the
> control signals also routed over it. ac97 and i2s are handled in the
> same PSC on the 5200.
Okay. On any specific board, there can _only_ be ac97 or _only_ i2s
codecs hooked onto the bus; the device node for the PSC should say
which it is, either by having different "compatible" entries for the
different modes, or by having some device-specific property in there
saying which it is. Ideally, the name of the node would be "i2s" resp.
"ac97" as well.
This handles 1).
> I have received conflicting opinions as to whether a codec hooked to
> an ac97 bus should get a chip specific codec entry in the device tree.
Every codec gets its own device node, and its "compatible" entry
describes
it uniquely. This is a very basic property of device trees.
This handles 2).
> Without the codec specific entry only generic ac97 features can be
> used. The Efika has a STA9766. Looking at the data sheet for the chip
> I see that it implements some proprietary functions in addition to the
> standard ones.
>
> asoc has a generic ac97 driver. Should the ac97 bus be required to
> have a entry for the generic ac97 device? It would make loading the
> driver much easier.
If the kernel driver does _not_ recognise the codec in the device tree,
it could use a "generic" ac97 codec driver, if such a thing indeed
exists.
If on the other hand it knows about the specific codec, it can use a
chip-
specific driver.
AC'97 codecs are addressed over the AC'97 bus, so the codecs should be
children of the ac97 bus in the device tree, and have fully qualified
names like "audio@0" or "modem@1" etc. I2S codecs that are addressed
(== its configuration registers written) over I2C should be children of
their I2C bus in the device tree, with fully qualified names like
"audio@6c"; they should show which I2S bus they sit on, for example by
having an "i2s-bus" property (containing the phandle of the i2s bus) in
the codec node.
This is 3).
Now for 4), the layout thing; you could try to describe the layout in
the device tree, but that would probably fail; there just is too much
variance. If I understand you correctly, you have a platform-specific
layout driver; now you need to find a nice way to probe this from the
device tree. Maybe you should just look at the properties in the root
node of the device tree for this.
>> _Please_ don't name busses that are not plain I2S "i2s" in the device
>> tree. At best this means you'll need a quirk in the kernel code to
>> deal
>> with this later.
>
> the i2s and ac97 drivers for the mpc5200 already exist. I'm using
> these preexisting drivers.
Sure, but that doesn't mean you cannot fix the way things are probed in
those drivers. Bugs are there to fix ;-)
Segher
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Linas Vepstas @ 2007-10-22 18:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <1193017764.10318.17.camel@concordia>
On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
>
> On pseries there's a chance it will work for PCI error recovery, but if
> so it's just lucky that firmware has left everything configured the same
> way.
? The papr is quite clear that i is up to the OS to restore the msi
state after an eeh error.
> Yes I think so. That way we can properly reconfigure via the firmware
> interface. The other option would be to design some new arch hook to do
> resume, but just doing a disable/enable seems simpler to me.
Err, If you read the code for suspend/resume, it never actually calls
disable/enable (and thus doesn't go to the firmware); it calls
restore_msi_state() function!
If suspend/resume needs to call firmware to restore the state, then,
at the moment, suspend/resume is broken. As I mentioned earlier,
I presumed that no powerpc laptops currently use msi-enabled devices,
as otherwise, this would have been flushed out.
--linas
^ permalink raw reply
* RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-22 18:06 UTC (permalink / raw)
To: microblaze-uclinux
Cc: Leonid, Wolfgang Reissnegger, Arnd Bergmann, linuxppc-dev
In-Reply-To: <1300.2720-24480-247293449-1192847306@seznam.cz>
> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au=20
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of=20
> Michal Simek
> Sent: Friday, October 19, 2007 7:28 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: Stephen Neuendorffer; Grant Likely; Leonid; Arnd=20
> Bergmann; linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
> Subject: [microblaze-uclinux] Re: [microblaze-uclinux] RE:=20
> [PATCH v3] Device tree bindings for Xilinx devices
>=20
> Hi Steve and all,
> >Here's a full .dts generated using an updated version of
> >gen_mhs_devtree.py, following the proposal.
> >It happens to be a microblaze system, but you get the idea.
>=20
> I think that is no good idea generate dts with all information.
> Especially information about PVR - number 2 means - Full PVR=20
> and you can
> obtain information directly from PVR. It is waste of memory space.
> xilinx,pvr =3D <2>;
PowerPC does something with the powerpc equivalent of the PVR.
We should just do what they do...
=20
> In my opinion will be better generate only parameters which=20
> you want not all.
> That smells with unusable parameters.
In the long term, this may be true. In the short term:
1) dtb size is not the key problem
2) making sure that everything works is a key problem.
3) The code that generates the dts should be as simple as possible,
so that we can easily document what it does.
In the long term, I'm all for optimizing the device tree that gets
built,
assuming that it appears to be a problem in real systems.
Steve
^ permalink raw reply
* Re: request_irq fails to get interrupt 12
From: S. Fricke @ 2007-10-22 17:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bfa0697f0710220947t657b209ek6f6a011cd1e6e5cf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Hello,
> Freescale experts. Why on earth can't I request the IRQ for Timer1?
Please consule my question on [1] and the answers.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html
bye
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: Josh Boyer @ 2007-10-22 16:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1Ik0UO-000389-AN@jdl.com>
On Mon, 22 Oct 2007 11:50:52 -0500
Jon Loeliger <jdl@jdl.com> wrote:
> So, like, the other day David Gibson mumbled:
> > On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote:
> > > David Gibson <david@gibson.dropbear.id.au> writes:
> > >
> > > > What compiler/platform is this? I can't off the top of my head think
> > > > of one where size_t shouldn't be promoted to int automatically.
> > >
> > > Only types narrower than int are subject to integer promotion.
> >
> > Duh, yes. Sorry.
>
> So, Hmm. You want the patch as I wrote it applied?
> Or do you want to use %z in the format instead? It does
> seem like there is precedent to do that (in the kernel):
>
> % grep -r '%z' arch/
> arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
> arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
> arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3
> arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3
> arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3
> ...
> arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3
> arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3
> arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3
> arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */
> arch/um/drivers/cow_user.c: "limited to %zd characters\n", backing_file,
> arch/x86/kernel/pci-nommu_64.c: "nommu_%s: overflow %Lx+%zu of device mask %Lx\n",
>
> Opinions?
%z is fairly common now-a-days. The kernel janitors tend to LART
people for not using it rather quickly.
josh
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: Jon Loeliger @ 2007-10-22 16:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071020090633.GH26642@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote:
> > David Gibson <david@gibson.dropbear.id.au> writes:
> >
> > > What compiler/platform is this? I can't off the top of my head think
> > > of one where size_t shouldn't be promoted to int automatically.
> >
> > Only types narrower than int are subject to integer promotion.
>
> Duh, yes. Sorry.
So, Hmm. You want the patch as I wrote it applied?
Or do you want to use %z in the format instead? It does
seem like there is precedent to do that (in the kernel):
% grep -r '%z' arch/
arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3
arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3
arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3
...
arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3
arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3
arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3
arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */
arch/um/drivers/cow_user.c: "limited to %zd characters\n", backing_file,
arch/x86/kernel/pci-nommu_64.c: "nommu_%s: overflow %Lx+%zu of device mask %Lx\n",
Opinions?
Thanks,
jdl
^ permalink raw reply
* request_irq fails to get interrupt 12
From: Alan Bennett @ 2007-10-22 16:47 UTC (permalink / raw)
To: linuxppc-dev
Freescale experts. Why on earth can't I request the IRQ for Timer1?
static int __init
dvr_ph_init(void)
{
u32 rv;
int k;
//rv = driver_register(&dvr_ph_driver);
for (k=0;k<64;k++) {
rv = request_irq(k,dvrph_isr , 0, "dvr_ph", NULL);
if (rv!=-38) printkplus("request_irq for %d returns %d", k,rv);
}
return rv;
}
Results in:
dvr_ph_init 145 - enter the routine
dvr_ph_init 155 -
dvr_ph_init 161 - request_irq for 16 returns -16 (vector 16 = TMCNT)
dvr_ph_init 161 - request_irq for 32 returns 0 (vector 32 = FCC1)
dvr_ph_init 161 - request_irq for 33 returns -16 (vector 33 = FCC2)
dvr_ph_init 161 - request_irq for 40 returns 0 (vector 40 = SCC1)
dvr_ph_init 161 - request_irq for 43 returns 0 (vector 43 = SCC4)
^ permalink raw reply
* Re: [PATCH 1/4] DTC: Reformat grammar rules to not mix language syntax and yacc syntax.
From: Jon Loeliger @ 2007-10-22 16:41 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071020071224.GD26642@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Fri, Oct 19, 2007 at 12:42:32PM -0500, Jon Loeliger wrote:
> >
> > Use consistent indenting on all rule actions.
> >
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> Meh, I kind of did it that way to keep the simple rules less bulky,
> but I don't really care much either way.
>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
Cool. Thanks. Applied.
jdl
^ permalink raw reply
* Re: dtc: data.c doesn't need to include dtc-parser.tab.h
From: Jon Loeliger @ 2007-10-22 16:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071022040923.GA21138@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Presumably we used this #include once, but it's certainly not
> necessary now.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: dtc: Disable semantic checks by default
From: Jon Loeliger @ 2007-10-22 16:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071018072230.GA10392@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> At present, dtc makes a lot of semantic checks on the device tree by
> default, and will refuse to produce output if they fail. This means
> people tend to need -f to force output despite failing semantic checks
> rather a lot.
>
> This patch splits the device tree checks into structural checks (no
> bad or duplicate names or phandles) and semantic checks (everything
> else). By default, only the structural checks are performed, and are
> fatal. -f will force output even with structural errors (using this
> in -Idts mode would essentially always be a bad idea, but it might be
> useful in -Idtb mode for examining a malformed dtb).
>
> Semantic checks are only performed if the new -c command line option
> is supplied, and are always warnings only. Semantic checks will never
> be performed on a tree with structural errors.
>
> This patch is only a stopgap before implementing proper fine-grained
> error/warning handling, but it should at least get rid of the
> far-too-frequent need for -f for the time being.
>
> This patch removes the -f from the dtc testcases now that it's no
> longer necessary.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: Add missing RW_CHECK_HEADER to fdt_del_node()
From: Jon Loeliger @ 2007-10-22 16:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071018041725.GD8206@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> fdt_del_node(), unlike most of the rw functions does not check the
> fdt's header with RW_CHECK_HEADER. However, it could make a mess of
> things if the conditions in RW_CHECK_HEADER aren't met. So, this
> patch adds the omitted check.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: dtc: Make helper macros in trees.S more flexible
From: Jon Loeliger @ 2007-10-22 16:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071018041409.GC8206@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch makes the helper macros in trees.S use separate labels for
> the end of each dt subblock, rather than using only start labels.
> This means that the macros can now be used to create trees with the
> subblocks in non-standard orders.
>
> In addition, it adds a bunch of extra ; after lines of asm code in
> macros, making them safe to use in nested macros.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: Make fdt_string() return a const pointer
From: Jon Loeliger @ 2007-10-22 16:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071018021042.GC24236@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, fdt_string() returns a (non-const) char *, despite taking a
> const void *fdt. This is inconsistent with all the other read-only
> functions which all return const pointers into the blob.
>
> This patch fixes that.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
From: Yuri Tikhonov @ 2007-10-22 16:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E0BC0C69-03B1-4F7A-9DEC-0EA9DAC92FB7@kernel.crashing.org>
On Friday 19 October 2007 17:24, Kumar Gala wrote:
>
> On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote:
>
> > Yuri Tikhonov writes:
> >
> >> The following patch adds support for 256KB PAGE_SIZE on ppc44x-
> >> based boards.
> >> The applications to be run on the kernel with 256KB PAGE_SIZE have
> >> to be
> >> built using the modified version of binutils, where the MAXPAGESIZE
> >> definition is set to 0x40000 (as opposite to standard 0x10000).
> >
> > Have you measured the performance using a 64kB page size? If so, how
> > does it compare with the 256kB page size?
>
> I was wondering about this as well? Isn't this technically in
> violation of the ABI?
No it isn't the violation.
As stated in "System V ABI. PowerPC processor supplement"
(on which the "Linux Standard Base Core Specification for PPC32"
is based): " ... Virtual addresses and file offsets for the PowerPC processor family
segments are congruent modulo 64 Kbytes (0x10000) or larger powers of 2...".
So, 256 Kbytes is just a larger case.
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: Device trees and audio codecs
From: Timur Tabi @ 2007-10-22 15:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710211729k2f2a065cm56670d1b0f90a1af@mail.gmail.com>
Jon Smirl wrote:
> I meant an ac97 bus. ac97 is conceptually the same as i2s with the
> control signals also routed over it. ac97 and i2s are handled in the
> same PSC on the 5200.
>
> I have received conflicting opinions as to whether a codec hooked to
> an ac97 bus should get a chip specific codec entry in the device tree.
I think it should. For one thing, ASoC requires a pointer to a structure in the
codec device driver so that it knows which functions to call to change volume.
What if you have multiple i2s/ac97 devices and multiple codecs? You'll need to
know which i2s device is connected to which codec. The only way to distinguish
that is by having a node for the codec under the i2s node.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] powerpc: irqtrace support to 64-bit powerpc
From: Johannes Berg @ 2007-10-22 13:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071015072826.2D541DDE16@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Mon, 2007-10-15 at 17:28 +1000, Benjamin Herrenschmidt wrote:
> This adds the low level irq tracing hooks to the powerpc architecture
> needed to enable full lockdep functionality
>
> Some rework from Johannes initial version, removing the asm trampoline that
> isn't needed (thus improving perfs) and fixing a couple of bugs such as
> incorrect initial preempt_count on the softirq alternate stack.
Hmm. It breaks booting on my quad, I finally got around to testing
without this patch and it turns out that it caused the boot failure I
reported in another mail. This is with v2.6.23-6623-g55b70a0, a clean
tree boots fine but with these two patches applied and configured in it
fails during boot, hanging at some point, apparently when userspace is
entered.
On the other hand, it is fine with my original version. I'll have to
find some time to check the differences hunk by hunk I guess.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [bug] block subsystem related crash on Legacy iSeries viodasd.c
From: Will Schmidt @ 2007-10-22 13:56 UTC (permalink / raw)
To: Jens Axboe; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev
In-Reply-To: <20071021124426.GS10674@kernel.dk>
On Sun, 2007-10-21 at 14:44 +0200, Jens Axboe wrote:
> On Fri, Oct 19 2007, Will Schmidt wrote:
> > Hi Jens, Stephen, and Everyone else.
...
> You need this, will remember to fix that up for the new branch as well.
>
> diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
> index e824b67..2ce3622 100644
> --- a/drivers/block/viodasd.c
> +++ b/drivers/block/viodasd.c
> @@ -270,6 +270,7 @@ static int send_request(struct request *req)
> d = req->rq_disk->private_data;
>
> /* Now build the scatter-gather list */
> + memset(sg, 0, sizeof(sg));
> nsg = blk_rq_map_sg(req->q, req, sg);
> nsg = dma_map_sg(d->dev, sg, nsg, direction);
>
That appears to do the trick. Thanks!
Tested-By: Will Schmidt <will_schmidt@vnet.ibm.com>
^ 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