* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Domen Puncer @ 2007-10-25 19:41 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071025185706.29496.qmail@farnsworth.org>
On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> Domen wrote:
> > > use your platform's dma mapping functions, rather than virt_to_phys()
> > >
> > > it might be the exact same implementation, inside the platform
> > > internals, but drivers should not be using this directly.
> >
> > I've replaced this with dma_map_single(), unmatched with
> > dma_unmap_single(), since bestcomm doesn't have a way to do that
> > and it's blank on ppc32 anyway.
> >
> > Is this OK? PPC guys?
>
> Even though dma_unmap_single() may be a no-op, calls to
> dma_map_single() must be matched with calls to dma_unmap_single().
>
> Perhaps with the additions below:
>
> > +static void mpc52xx_fec_free_rx_buffers(struct bcom_task *s)
> > +{
> > + struct sk_buff *skb;
> > +
> > + while (!bcom_queue_empty(s)) {
> > + skb = bcom_retrieve_buffer(s, NULL, NULL);
>
> dma_unmap_single(&skb->dev->dev, skb-data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
It looks to me like dma_unmap_single takes the mapped address
(what dma_map_single returned), and not the address we're mapping
(skb->data).
Domen
^ permalink raw reply
* settimeofday not working
From: Rune Torgersen @ 2007-10-25 19:40 UTC (permalink / raw)
To: linuxppc-dev
Hi
I upgraded my board-port from 2.6.18 (8280 in arch/ppc) to 2.6.23 (Yes,
I know, arch/powerpc. I am planning on doing that, I just wanted the old
stuff working first).
On any kernel newer than 2.6.20, settimeofday does not work.
I try to set the current date, but when I read back the time, it is
still the old date (in our case, Jan 1 1970)
Any idea of where I should start looking?
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Benjamin Berg @ 2007-10-25 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad, Dmitry Torokhov
In-Reply-To: <1193318605.6092.11.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
On Thu, 2007-25-10 at 15:23 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 10:29 -0400, Dmitry Torokhov wrote:
>
> > Do yo know who has powerbooks with older geyser models (0x214, 215,
> > 216)?
>
> Not sure, Benjamin? We're talking about the touchpad, just lsusb should
> be enough.
lsusb says I have a 0x215
(Bus 003 Device 002: ID 05ac:0215 Apple Computer, Inc.)
Everything is working fine with a 2.6.24-rc1 kernel (ie. no bogus
messages).
> > It would be nice to know if they send the data continiously and
> > whether the geyser 3 reset hack works on them.
>
> That'd be good, but for fountains it definitely doesn't work.
Benjamin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Dale Farnsworth @ 2007-10-25 18:57 UTC (permalink / raw)
To: domen.puncer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071025141035.GG3369@nd47.coderock.org>
Domen wrote:
> > use your platform's dma mapping functions, rather than virt_to_phys()
> >
> > it might be the exact same implementation, inside the platform
> > internals, but drivers should not be using this directly.
>
> I've replaced this with dma_map_single(), unmatched with
> dma_unmap_single(), since bestcomm doesn't have a way to do that
> and it's blank on ppc32 anyway.
>
> Is this OK? PPC guys?
Even though dma_unmap_single() may be a no-op, calls to
dma_map_single() must be matched with calls to dma_unmap_single().
Perhaps with the additions below:
> +static void mpc52xx_fec_free_rx_buffers(struct bcom_task *s)
> +{
> + struct sk_buff *skb;
> +
> + while (!bcom_queue_empty(s)) {
> + skb = bcom_retrieve_buffer(s, NULL, NULL);
dma_unmap_single(&skb->dev->dev, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> + kfree_skb(skb);
> + }
> +}
> +
> +static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct
> bcom_task *rxtsk)
> +{
> + while (!bcom_queue_full(rxtsk)) {
> + struct sk_buff *skb;
> + struct bcom_fec_bd *bd;
> +
> + skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
> + if (skb == NULL)
> + return -EAGAIN;
skb->dev = dev;
> +
> + /* zero out the initial receive buffers to aid debugging */
> + memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
> +
> + bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
> +
> + bd->status = FEC_RX_BUFFER_SIZE;
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> + FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> +
> + bcom_submit_next_buffer(rxtsk, skb);
> + }
> +
> + return 0;
> +}
[...]
> +static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> +{
> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
> + struct bcom_fec_bd *bd;
> +
> + if (bcom_queue_full(priv->tx_dmatsk)) {
> + if (net_ratelimit())
> + dev_err(&dev->dev, "transmit queue overrun\n");
> + return 1;
> + }
> +
> + spin_lock_irq(&priv->lock);
> + dev->trans_start = jiffies;
> +
> + bd = (struct bcom_fec_bd *)
> + bcom_prepare_next_buffer(priv->tx_dmatsk);
> +
> + bd->status = skb->len | BCOM_FEC_TX_BD_TFD | BCOM_FEC_TX_BD_TC;
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
> +
> + bcom_submit_next_buffer(priv->tx_dmatsk, skb);
> +
> + if (bcom_queue_full(priv->tx_dmatsk)) {
> + netif_stop_queue(dev);
> + }
> +
> + spin_unlock_irq(&priv->lock);
> +
> + return 0;
> +}
> +
> +/* This handles BestComm transmit task interrupts
> + */
> +static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *dev = dev_id;
> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
> +
> + spin_lock(&priv->lock);
> +
> + while (bcom_buffer_done(priv->tx_dmatsk)) {
> + struct sk_buff *skb;
> + skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL, NULL);
> + /* Here (and in rx routines) would be a good place for
> + * dma_unmap_single(), but bcom doesn't return bcom_bd of the
> + * finished transfer, and _unmap is empty on this platfrom.
> + */
Replace the above comment with:
dma_unmap_single(&dev->dev, skb->data,
skb->len, DMA_TO_DEVICE);
> +
> + dev_kfree_skb_irq(skb);
> + }
> +
> + netif_wake_queue(dev);
> +
> + spin_unlock(&priv->lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *dev = dev_id;
> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
> +
> + while (bcom_buffer_done(priv->rx_dmatsk)) {
> + struct sk_buff *skb;
> + struct sk_buff *rskb;
> + struct bcom_fec_bd *bd;
> + u32 status;
> +
> + rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status, NULL);
dma_unmap_single(&dev->dev, rskb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> +
> + /* Test for errors in received frame */
> + if (status & BCOM_FEC_RX_BD_ERRORS) {
> + /* Drop packet and reuse the buffer */
> + bd = (struct bcom_fec_bd *)
> + bcom_prepare_next_buffer(priv->rx_dmatsk);
> +
> + bd->status = FEC_RX_BUFFER_SIZE;
> + bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> +
> + bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
> +
> + dev->stats.rx_dropped++;
> +
> + continue;
> + }
> +
> + /* skbs are allocated on open, so now we allocate a new one,
> + * and remove the old (with the packet) */
> + skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
> + if (skb) {
> + /* Process the received skb */
> + int length = status & BCOM_FEC_RX_BD_LEN_MASK;
skb->dev = dev;
> +
> + skb_put(rskb, length - 4); /* length without CRC32 */
> +
> + rskb->dev = dev;
Above line is no longer needed since we set rskb->dev on skb allocation.
> + rskb->protocol = eth_type_trans(rskb, dev);
> +
> + netif_rx(rskb);
> + dev->last_rx = jiffies;
> + } else {
> + /* Can't get a new one : reuse the same & drop pkt */
> + dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
> + dev->stats.rx_dropped++;
> +
> + skb = rskb;
> + }
> +
> + bd = (struct bcom_fec_bd *)
> + bcom_prepare_next_buffer(priv->rx_dmatsk);
> +
> + bd->status = FEC_RX_BUFFER_SIZE;
> + bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> +
> + bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> + }
> +
> + return IRQ_HANDLED;
> +}
-Dale Farnsworth
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-25 18:50 UTC (permalink / raw)
To: Matt Sealey; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <4720DA11.9030103@genesi-usa.com>
Matt Sealey wrote:
> Compatible property on /builtin@F0000000/usb@F0001000 is
>
> ohci-bigendian
> ohci-be
> mpc5200-ohci
> mpc5200-usb
>
> device_type is "usb", model is "mpc5200-ohci".
>
> Although I worry about cluttering up the cleanup, it is probably just
> adding an "if property(big-endian) OR compatible(mpc5200-ohci)"
> to that small big-endian check there.
>
We should also keep "ohci-bigendian" and "ohci-be" in the match table.
> I am currently moving on the assumption that the "correct" device
> tree for the Efika (notwithstanding the above) would be
>
> usb@F0001000 {
> device-type = "usb-ohci"
> compatible = "mpc5200-ohci,mpc5200-usb-ohci"
It should also have compatible "usb-ohci" entry as a more general one.
Others are for device-specific quirks:
compatible = "mpc5200-usb-ohci","usb-ohci"
> big-endian
> }
>
> Or some variation including all the relevant checked-for
> properties.
>
> I don't like the old "ohci-bigendian" and "ohci-be" properties.
> Picking out "ohci-bigendian" and "ohci-be" was someone's drunken
> idea, I'm sure, so I am happy to let them die a horrible death
> and never rear up ever again.
:)
>
> Using mpc5200-ohci out is by far the safest idea, although it
> leaves in a rather platform-specific fix, I prefer singling out that
> platform and potentially causing nasty looks towards the
> direction of Genesi/bplan, than having ohci-bigendian continue
> to exist for the sake of it :D
So, do you suggest to use "mpc5200-ohci" instead of "ohci-be" in the
match table?
>
> There is another solution; change the properties in the Linux
> device tree fixups, but I would loathe that solution as it adds
> yet another part of the kernel to track.
>
> Unfortunately the current device tree is a complete, stupid mess,
> a result of a bunch of guys not looking at the problem, and I
> have said this before (rant mode :) - I think device_type,
> compatible should report the KIND of device it is, and the model
> property should be used to pick out the particular quirks of
> the chipset. We could have had a nice system where "usb" is paired
> with compatible "ohci", and model is "mpc5200". No dashes or
> spaces or 10 strings to compare..
>
:)
Thanks,
Valentine.
^ permalink raw reply
* [RFC] [PATCH] PowerPC: Workaround for the 440EP(x)/GR(x) processors identical PVR issue.
From: Valentine Barshak @ 2007-10-25 18:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
they have identical cores. However, FPU is not supported on GR(x) and
enabling APU instruction broadcast in the CCR0 register (to enable FPU)
may cause unpredictable results. There's no safe way to detect FPU
support at runtime. This patch provides a workarund for the issue.
We use a POWER6 "logical PVR approach". First, we identify all EP(x)
and GR(x) processors as GR(x) ones (which is safe). Then we check
the device tree cpu path. If we have a EP(x) processor entry,
we call identify_cpu again with PVR | 0x8. This bit is always 0
in the real PVR. This way we enable FPU only for 440EP(x).
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/cputable.c | 36 ++++++++++++++++++++++++++++--------
arch/powerpc/kernel/prom.c | 12 ++++++++++++
2 files changed, 40 insertions(+), 8 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/kernel/cputable.c linux-2.6/arch/powerpc/kernel/cputable.c
--- linux-2.6.orig/arch/powerpc/kernel/cputable.c 2007-10-25 19:19:35.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/cputable.c 2007-10-25 21:11:59.000000000 +0400
@@ -1104,6 +1104,16 @@ static struct cpu_spec __initdata cpu_sp
{
.pvr_mask = 0xf0000fff,
.pvr_value = 0x40000850,
+ .cpu_name = "440GR Rev. A",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc440",
+ },
+ { /* Use logical PVR for 440EP (logical pvr = pvr | 0x8) */
+ .pvr_mask = 0xf0000fff,
+ .pvr_value = 0x40000858,
.cpu_name = "440EP Rev. A",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
@@ -1115,28 +1125,27 @@ static struct cpu_spec __initdata cpu_sp
{
.pvr_mask = 0xf0000fff,
.pvr_value = 0x400008d3,
- .cpu_name = "440EP Rev. B",
+ .cpu_name = "440GR Rev. B",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
- .cpu_setup = __setup_cpu_440ep,
.platform = "ppc440",
},
- { /* 440EPX */
- .pvr_mask = 0xf0000ffb,
- .pvr_value = 0x200008D0,
- .cpu_name = "440EPX",
+ { /* Use logical PVR for 440EP (logical pvr = pvr | 0x8) */
+ .pvr_mask = 0xf0000fff,
+ .pvr_value = 0x400008db,
+ .cpu_name = "440EP Rev. B",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
- .cpu_setup = __setup_cpu_440epx,
+ .cpu_setup = __setup_cpu_440ep,
.platform = "ppc440",
},
{ /* 440GRX */
.pvr_mask = 0xf0000ffb,
- .pvr_value = 0x200008D8,
+ .pvr_value = 0x200008D0,
.cpu_name = "440GRX",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE,
@@ -1145,6 +1154,17 @@ static struct cpu_spec __initdata cpu_sp
.cpu_setup = __setup_cpu_440grx,
.platform = "ppc440",
},
+ { /* Use logical PVR for 440EPx (logical pvr = pvr | 0x8) */
+ .pvr_mask = 0xf0000ffb,
+ .pvr_value = 0x200008D8,
+ .cpu_name = "440EPX",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440epx,
+ .platform = "ppc440",
+ },
{ /* 440GP Rev. B */
.pvr_mask = 0xf0000fff,
.pvr_value = 0x40000440,
diff -pruN linux-2.6.orig/arch/powerpc/kernel/prom.c linux-2.6/arch/powerpc/kernel/prom.c
--- linux-2.6.orig/arch/powerpc/kernel/prom.c 2007-10-25 19:19:35.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/prom.c 2007-10-25 21:11:59.000000000 +0400
@@ -697,6 +697,18 @@ static int __init early_init_dt_scan_cpu
prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
if (prop && (*prop & 0xff000000) == 0x0f000000)
identify_cpu(0, *prop);
+#if defined(CONFIG_44x) && defined(CONFIG_PPC_FPU)
+ /*
+ * Since 440GR(x)/440EP(x) processors have the same pvr,
+ * we check the node path and set bit 28 in the cur_cpu_spec
+ * pvr for EP(x) processor version. This bit is always 0 in
+ * the "real" pvr. Then we call identify_cpu again with
+ * the new logical pvr to enable FPU support.
+ */
+ if (strstr(uname, "440EP")) {
+ identify_cpu(0, cur_cpu_spec->pvr_value | 0x8);
+ }
+#endif
}
check_cpu_feature_properties(node);
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: Jon Loeliger @ 2007-10-25 18:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071020084737.GG26642@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> > Use of "d#', "o#", "h#" and "b#" are gone in version 1.
>
> Also good. We might want to keep b#, since there's no C way of doing
> binary literals, but in that case I'd suggest recognizing it at the
> lexical level, not the grammar level as we do now (which would mean a
> space between the b# and the digits would no longer be permissible).
I added 0(b|B)[01]+ literal support.
> Now my big concern with this patch: the dts_version global, set by the
> parser, used by the lexer. I assume you've tested this and it works
> in practice,
Yes.
> but you're relying on the semantic action from the .y
> file being executed before the lexer meets any token that depends on
> it.
Of course that is how it works. No problem.
> I don't know about you, but I have to think pretty hard about how flow
> of control will move between lexer and parser rules in a shift-reduce
> parser at the best of times. With the %glr-parser option, bison will
> use the Tomita algorithm. That means the parser state could be split
> if there are ambiguities, or non-LALR(1) portions of the grammar
> (which there are). In that case the execution of the parser rules
> will be delayed until after the split is resolved again, however many
> tokens down the track.
So, I removed the ambiguity.
> Therefore, I'd prefer that instead of having this general version
> number, we introduce a separate token for each new version. So
> /dts-version-1/ or whatever. Any new, incompatible, dts version is a
> big deal in any case - not something we want to happen often - so a
> new token for each version is not a big deal, I think. With this
> approach, the version flag can be tripped in the lexer, and the
> ordering of lexer rule execution is obvious.
I don't see how this will work at the purely lexical level in
a reliable way. Sure, I see the lexer matching the token and
setting some variable (dts_version = 0 or 1) as needed.
But there is no really good way to enforce that this happens at
an early enough state that it covers the rest of the file short
of having a staged lexical context state machine. And that just
seems way hacky to me.
With it in the grammar, we can enforce it being early in the file
and can be assured of it happening in time to affect the rest of
the parse. Personally, I think having it be a general statement
like:
/<option>/ <value> ;
makes a whole lot more sense than having the purely lexical
context. Future versions of the DTS files will be syntactically
correct even when moving to a (now) hypothetical version 2 file.
> I'm also inclined to leave the syntax for bytestrings as it is, in
Why? Why not be allowed to form up a series of expressions
that make up a byte string? Am I missing something obvious here?
> [snip]
> > +<*>{DOT}{DOT} {
>
> You should be able to just use \.\. or ".." here rather than having to
> indirect through a character class.
Oh, yeah, I meant to revert that again. No problem.
> > +0(x|X){HEXDIGIT}+ {
>
> Does C recognize both 0x and 0X, or just 0x? I don't remember off the
> top of my head.
Yep.
> > +u64 expr_from_string(char *s, unsigned int base)
> > +{
> > + u64 v;
> > + char *e;
> > +
> > + v = strtoull(s, &e, base);
> > + if (*e) {
> > + fprintf(stderr,
> > + "Line %d: Invalid literal value '%s' : "
> > + "%c is not a base %d digit; %lld assumed\n",
> > + yylloc.first_line, s, *e,
> > + base == 0 ? expr_default_base : base,
> > + (unsigned long long) v);
>
> Do we need this error checking? Won't the regexes mean that the
> string *must* be a valid literal by this point?
It's still needed for the legacy bits where you have modified
the base for the following numbers. Specifically, you can say
something like "d# 123abc" and it will scan lexically, but
not be correct semantically still. Blah.
> > @@ -46,25 +47,27 @@ extern struct boot_info *the_boot_info;
> > int hexlen;
> > u64 addr;
> > struct reserve_info *re;
> > + u64 ire;
>
> What's "ire" supposed to be short for?
Oh, longer term. I have a intermediate representation for
expressions up my sleeve. Sorry, wasn't clear there...
> > + | label DT_MEMRESERVE expr '-' expr ';'
>
> Oh.. you haven't actually abolished the '-' syntax, even in version 1
> mode. Since we're already making an incompatible syntax change, we
> should really make this one at the same time.
I can make that fail, no problem.
> > +cell:
> > + expr
> > + {
> > + $$ = expr_cell_value($1);
> > + }
> > + ;
> > +
> > +expr:
> > + expr_primary
> > + ;
> > +
> > +expr_primary:
> > + opt_cell_base DT_LITERAL
> > + {
> > + $$ = $2;
> > + }
>
> Hrm. I realise you haven't actually implemented expressions here, but
Right. Initial framework....
> > +void yywarn(char const *s, ...)
>
> Ick.. we can tolerate yyblah() names for the things we inherit from
> yacc, but lets not introduce our own, hey.
It's pretty normal, I think. But we can introduce something else
and map yyerror() into an error variant. Got name suggestions?
> > +unsigned int dts_version = 0;
> > +unsigned int expr_default_base = 10;
> > +
> > +
> > +void set_dts_version(u64 vers)
> > +{
> > + if (vers > 1) {
> > + yywarn("Unknown version %lld; 0 assumed\n", vers);
> > + dts_version = 0;
> > + } else {
> > + dts_version = vers;
> > + }
> > +
> > + if (dts_version == 0) {
> > + expr_default_base = 16;
> > + in_lexer_use_base = 16;
> > + } else {
> > + expr_default_base = 10;
> > + in_lexer_use_base = 10;
>
> Uh.. I don't think we should need either of expr_default_base and
> in_lexer_use_base, let alone both..
You need to temporarily know what the base of the next number
will be for "d#"-like constructs, and then you need to know
what to revert to again (default). Sure, we could consult the
dts_version again directly at that time if you'd rather.
> > - fprintf(f, "%x", be32_to_cpu(*cp++));
> > + if (dts_version == 0) {
>
> Where does dts_version get set in the -Odts case?
The same call to set_dts_version() as any other case.
jdl
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-25 18:13 UTC (permalink / raw)
To: Matt Sealey; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <4720DD18.9000603@genesi-usa.com>
Matt Sealey wrote:
> Valentine,
>
> Please do the very minimal required to keep supporting the Efika.
>
> As for an little endian OHCI controller on an OF bus, I would not
> consider it an impossibility. But, not having the big-endian
> property fixes this; OHCI is little-endian by default. You need
> only report "difference" in device trees, overzealous naming of
> a billion kinds of 99.99999% compatible controllers is just a
> waste of space.
>
> I prefer the new binding to a degree. I like the big-endian property
> and I like the reporting of a standard controller type (usb-ohci
> rather than building in chip names). However by making the driver
> support only the recommending binding, we break old platforms for
> the sake of making new ones cleaner.
>
> I wish someone would have sat down and defined the 5200 device
> tree in a design committee rather than a peer review post-commit
> system. In fact, that is a great idea, we can start this off with
> the MPC5121E right now, and get the damn thing RIGHT.
>
OK, I'll submit a new patch in a bit.
Thanks,
Valentine.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-25 18:14 UTC (permalink / raw)
To: Valentine Barshak; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <4720CE3E.5030204@ru.mvista.com>
Valentine,
Please do the very minimal required to keep supporting the Efika.
As for an little endian OHCI controller on an OF bus, I would not
consider it an impossibility. But, not having the big-endian
property fixes this; OHCI is little-endian by default. You need
only report "difference" in device trees, overzealous naming of
a billion kinds of 99.99999% compatible controllers is just a
waste of space.
I prefer the new binding to a degree. I like the big-endian property
and I like the reporting of a standard controller type (usb-ohci
rather than building in chip names). However by making the driver
support only the recommending binding, we break old platforms for
the sake of making new ones cleaner.
I wish someone would have sat down and defined the 5200 device
tree in a design committee rather than a peer review post-commit
system. In fact, that is a great idea, we can start this off with
the MPC5121E right now, and get the damn thing RIGHT.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Valentine Barshak wrote:
> Grant Likely wrote:
>> On 10/25/07, Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>>> Grant Likely wrote:
>>>> On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
>>>>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>>>>> Can we just make sure real quickly that the changing of compatibles
>>>>>> doesn't break existing, not-easily-flashable firmwares?
>>>>> Yeah, I'm not keen on such breakage either...
>>>> Add my voice to the chorus. It's okay to change the binding, but make
>>>> sure the old binding is still supported.
>>>>
>>>> Cheers,
>>>> g.
>>>>
>>> Actually, I thought that changing the DTS stuff for mpc52xx boards would
>>> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
>>> bindings as well.
>>
>> Even if that were the case; I'm nervous about breaking compatibility
>> with old device trees.
>
> If we keep the old bindings intact in the driver code then the old dts
> files should work fine. But I'm starting to doubt we really need any new
> bindings for this if we still have to keep the old ones.
> BTW, does anybody know of any ohci-le devices on OF bus?
> Thanks,
> Valentine.
>
>>
>> We probably need a formal guideline here. ie. When is it okay to drop
>> compatibility with old dts files?
>>
>>> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
>>> property on Efika?
>>
>> If it doesn't, it can be added during prom_init.c We're already doing
>> a bunch of efika fixups there anyway.
>>
>> Cheers,
>> g.
>>
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-25 18:10 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <fa686aa40710250721m54dda956qe7c8986416d0dfa2@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> If it doesn't, it can be added during prom_init.c We're already doing
> a bunch of efika fixups there anyway.
I want those to go away. Far, far away.
http://www.powerdeveloper.org/platforms/efika/devicetree
Not the most elegant solution right now, but it works (kinda, a few bugs
to sort out).
Note that Domen's ethernet driver plus a bunch of Sylvain's stuff if
it is ever cleaned up (deep sleep etc.) will not work without these
device tree changes. You should realise that if we plugged every tiny
thing into prom_init.c we would double the size of the file just for
Efika fixes.
And that's dumb.
Compatibility with old device trees should go away after there is a
production firmware people can download - like the x86 hardware monitor
drivers in lmsensors report "please upgrade your BIOS" if they have
been disabled, users will happily update their BIOS to an updated
version if it is available.
For Efika, right now, it is not.
And for Efika, right now, I fear the stupidity some of the device tree
design (mandated by a text file..) means any new firmware update
will have far more strings and reporting than it should ever truly
need.
Although you can restrict Linux kernels from running on firmwares below
a certain version, we can't knowingly restrict the board firmware to only
running Linux kernels above a certain version.
Therefore, this is an exercise in not pissing people off, not really
of any technical merit. We already had Pegasos keyboard support disappear
because someone decided the device tree usage needed to be changed. Given
the size of the fix in nvramrc, it's harmless, given that Pegasos is
a dead platform, it's harmless. Efika is still in production.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2007-10-25 18:01 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071023212404.GA30942@loki.buserror.net>
On Tue, Oct 23, 2007 at 04:24:04PM -0500, Scott Wood wrote:
> +#ifdef CONFIG_SUSPEND
> +void generic_suspend_disable_irqs(void)
> +{
> + preempt_disable();
> +
> + /* Disable the decrementer, so that it doesn't interfere
> + * with suspending.
> + */
> +
> + set_dec(0x7fffffff);
> + hard_irq_disable();
> + set_dec(0x7fffffff);
> +}
> +
> +void generic_suspend_enable_irqs(void)
> +{
> + wakeup_decrementer();
> +
> + local_irq_enable();
> + preempt_enable();
> +}
Doh, that should be hard_irq_enable().
-Scott
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-25 18:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <47208273.8050601@ru.mvista.com>
Compatible property on /builtin@F0000000/usb@F0001000 is
ohci-bigendian
ohci-be
mpc5200-ohci
mpc5200-usb
device_type is "usb", model is "mpc5200-ohci".
Although I worry about cluttering up the cleanup, it is probably just
adding an "if property(big-endian) OR compatible(mpc5200-ohci)"
to that small big-endian check there.
I am currently moving on the assumption that the "correct" device
tree for the Efika (notwithstanding the above) would be
usb@F0001000 {
device-type = "usb-ohci"
compatible = "mpc5200-ohci,mpc5200-usb-ohci"
big-endian
}
Or some variation including all the relevant checked-for
properties.
I don't like the old "ohci-bigendian" and "ohci-be" properties.
Picking out "ohci-bigendian" and "ohci-be" was someone's drunken
idea, I'm sure, so I am happy to let them die a horrible death
and never rear up ever again.
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
There is another solution; change the properties in the Linux
device tree fixups, but I would loathe that solution as it adds
yet another part of the kernel to track.
Unfortunately the current device tree is a complete, stupid mess,
a result of a bunch of guys not looking at the problem, and I
have said this before (rant mode :) - I think device_type,
compatible should report the KIND of device it is, and the model
property should be used to pick out the particular quirks of
the chipset. We could have had a nice system where "usb" is paired
with compatible "ohci", and model is "mpc5200". No dashes or
spaces or 10 strings to compare..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Valentine Barshak wrote:
> Grant Likely wrote:
>> On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
>>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>>> Can we just make sure real quickly that the changing of compatibles
>>>> doesn't break existing, not-easily-flashable firmwares?
>>> Yeah, I'm not keen on such breakage either...
>>
>> Add my voice to the chorus. It's okay to change the binding, but make
>> sure the old binding is still supported.
>>
>> Cheers,
>> g.
>>
>
> Actually, I thought that changing the DTS stuff for mpc52xx boards would
> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
> bindings as well.
> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
> property on Efika?
> Thanks,
> Valentine.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-25 17:11 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <fa686aa40710250721m54dda956qe7c8986416d0dfa2@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>> Grant Likely wrote:
>>> On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
>>>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>>>> Can we just make sure real quickly that the changing of compatibles
>>>>> doesn't break existing, not-easily-flashable firmwares?
>>>> Yeah, I'm not keen on such breakage either...
>>> Add my voice to the chorus. It's okay to change the binding, but make
>>> sure the old binding is still supported.
>>>
>>> Cheers,
>>> g.
>>>
>> Actually, I thought that changing the DTS stuff for mpc52xx boards would
>> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
>> bindings as well.
>
> Even if that were the case; I'm nervous about breaking compatibility
> with old device trees.
If we keep the old bindings intact in the driver code then the old dts
files should work fine. But I'm starting to doubt we really need any new
bindings for this if we still have to keep the old ones.
BTW, does anybody know of any ohci-le devices on OF bus?
Thanks,
Valentine.
>
> We probably need a formal guideline here. ie. When is it okay to drop
> compatibility with old dts files?
>
>> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
>> property on Efika?
>
> If it doesn't, it can be added during prom_init.c We're already doing
> a bunch of efika fixups there anyway.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Grant Likely @ 2007-10-25 16:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4720C27B.7020408@grandegger.com>
On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Wolfgang Grandegger wrote:
> > Grant Likely wrote:
> >> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> >>> Hello,
> >>>
> >>> The access to PCI memory space does not to work (I allways read 0xff) on
> >>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
> >>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
> >>> realized, that CONFIG_PCI is not set in the default configuration.
> >> arch/ppc or arch/powerpc?
> >>
> >> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
> >> eth adapters plugged in and the devices are usable. This is a
> >> 2.6.24-rc1 arch/powerpc kernel.
> >
> > I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
> > work either:
> >
> > e100: probe of 0000:00:18.0 failed with error -11
> >
> > It looks like that 2.6.23 needs some more patches.
>
> Indeed, it works with 2.6.24-rc1:
>
> e100: eth0: e100_probe: addr 0xa0000000, irq 16, MAC addr 00:0e:0c:74:8c:f2
Okay, when I get a chance I'll try 2.6.23 on my lite5200
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Wolfgang Grandegger @ 2007-10-25 16:21 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4720B218.80607@grandegger.com>
Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> Hello,
>>>
>>> The access to PCI memory space does not to work (I allways read 0xff) on
>>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
>>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
>>> realized, that CONFIG_PCI is not set in the default configuration.
>> arch/ppc or arch/powerpc?
>>
>> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
>> eth adapters plugged in and the devices are usable. This is a
>> 2.6.24-rc1 arch/powerpc kernel.
>
> I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
> work either:
>
> e100: probe of 0000:00:18.0 failed with error -11
>
> It looks like that 2.6.23 needs some more patches.
Indeed, it works with 2.6.24-rc1:
e100: eth0: e100_probe: addr 0xa0000000, irq 16, MAC addr 00:0e:0c:74:8c:f2
Wolfgang.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-25 16:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710242011y771d5cbbuaa1eb274672ccb48@mail.gmail.com>
Jon Smirl wrote:
> This could work. The generic codec is a alsa soc_device_driver, not a
> of_device_driver. The codec node could instantiate the fabric as a
> of_device_driver which could then instantiate the soc_device_driver
> for the generic codec.
>
> The generic codecs are supposed to work cross platform so they can't
> include code that munges the of device tree.
My understanding of ASoC is that the fabric driver is supposed to be OF-aware,
and the codec and other drivers are not. The other drivers have ASoC entry
points that the fabric driver calls to provide information.
Example:
Fabric driver:
static int mpc8610hpcd_startup(struct snd_pcm_substream *substream)
{
...
if (codec_dai->dai_ops.set_fmt) {
ret = codec_dai->dai_ops.set_fmt(codec_dai, machine_data->dai_format);
if (ret < 0) {
printk(KERN_ERR "mpc8610-hpcd: could not set codec "
"driver audio format (ret=%i)\n", ret);
return ret;
}
}
codec driver:
static int cs4270_set_dai_fmt(struct snd_soc_codec_dai *codec_dai,
unsigned int format)
{
...
switch (format & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
case SND_SOC_DAIFMT_LEFT_J:
cs4270->mode = format & SND_SOC_DAIFMT_FORMAT_MASK;
break;
In my device tree, the I2S node specifies the interface (this node layout is
what I came up with 6 months ago when I started working on this.)
ssi@16000 {
compatible = "fsl,ssi";
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
/* This is probably not the right way to tell the
SSI driver how to configure the interface */
fsl,mode = "i2s-slave";
codec {
compatible = "cs4270";
};
};
The fabric driver reads "i2s-slave" and converts that to SND_SOC_DAIFMT_I2S.
^ permalink raw reply
* Re: [PATCH 09/11] [POWERPC] Motion-PRO: Add LED support.
From: Marian Balakowicz @ 2007-10-25 15:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710240718t202a8d14lab24f11e8d53e0eb@mail.gmail.com>
Grant Likely wrote:
...
>> +
>> +static int __init mpled_init(void)
>> +{
>> + int i, error;
>> +
>> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
>> + led[i].reg_addr = mpc52xx_find_and_map(led[i].reg_compat);
>
> Please use of-platform-bus bindings instead. Let the of-platform bus
> take care of scanning the tree for you. Don't do it manually.
Hm, let me try that instead, thanks for the suggestion.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-25 15:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Martin Krause
In-Reply-To: <fa686aa40710250653o6e7df26y1890d5c485a6d508@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
>>
>> < + flash@00000000 {
>> < + compatible = "cfi-flash";
>> < + reg = <00000000 02000000>;
>> < + bank-width = <4>;
>> < + device-width = <2>;
>> < + #size-cells = <1>;
>> < + #address-cells = <1>;
>> < + partition@0 {
>> < + label = "firmware";
>> < + reg = <0 a0000>;
>> < + };
>> < + partition@a0000 {
>> < + label = "dtb";
>> < + reg = <a0000 20000>;
>> < + };
>> < + partition@c0000 {
>> < + label = "kernel";
>> < + reg = <c0000 240000>;
>> < + };
>> < + partition@300000 {
>> < + label = "initrd";
>> < + reg = <300000 200000>;
>> < + };
>> < + partition@500000 {
>> < + label = "small-fs";
>> < + reg = <500000 400000>;
>> < + };
>> < + partition@900000 {
>> < + label = "misc";
>> < + reg = <900000 800000>;
>> < + };
>> < + partition@1100000 {
>> < + label = "big-fs";
>> < + reg = <1100000 f00000>;
>> < + };
>> < + };
>> < + };
>>
>> This MTD layout only works on boards with 32 MiB (or 64 MiB) flash
>> memory. On TQM5200 boards with smaller Flashes (16 MiB, 8 MiB and 4 MiB)
>> the MTD partition borders do not match with the physikal memory borders.
>
> If there is a variant board with a different configuration, then the
> device tree needs to be changed for that variant board; either by
> having multiple .dts files in arch/powerpc/boot/dts or by having the
> bootloader populate the correct information. A dtb as passed to the
> kernel must exactly represent the hardware.
>
> That also means that there is going to be a different flash map for
> each possible flash size configuration.
Agree, that's one particular configuration (I guess I should add
proper comment), that should be updated if needed. But I'am not sure
if we should have multiple .dts files if it's only flash layout that
changes.
>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
>> partition could not be used. "big-fs", because the memory is too small
>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
>> flash border. So only the first 9 MiB of the flash could be used in Linux.
>> The remaining 7 MiB couldn't be accessed.
>
> Perhaps it would be better to drop the flash layout from the in-kernel
> dts files entirely since flash layout can be a fluid thing.
Well, but that would not be really user friendly, I'd rather stick
with some default config.
m.
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-25 15:23 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20071024015115.GK10595@localhost.localdomain>
David Gibson wrote:
> On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
>
> [snip]
>> + lpb@fc000000 {
>> + model = "fsl,lpb";
>> + compatible = "lpb";
>
> Not nearly specific enough. Must include a vendor prefix at least,
> and should have a lot more revision information. You should always be
> able to pick the right driver with compatible alone, "model" should
> generally be for human consumption, the driver shouldn't need it.
>
>> + device_type = "lpb";
>
> Drop this. Again, presence of a device_type property is the
> exception, not the rule.
>
>> + ranges = <0 fc000000 02000000>;
>
> You need #address-cells and #size-cells properties, too.
>
> [snip]
OK, will update that. I guess I'll also need to use 'compatible' and
skip type when passing bus ids to of_platform_bus_probe().
m.
^ permalink raw reply
* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Arnd Bergmann @ 2007-10-25 15:19 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <Pine.LNX.4.62.0710251649520.3812@pademelon.sonytel.be>
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> In many cases these ioctls can indeed not be handled.
> E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
> cache. But this ioctl is not supported, not before and not after 2.6.23.
> Before 2.6.23, it didn't print the message, in 2.6.23, it does.
What I would expect to happen here is:
compat_blkdev_ioctl gets into the BLKFLSBUF case and calls blkdev_ioctl,
which calls blkdev_driver_ioctl, which returns -ENOTTY because
ps3disk_fops does not contain an unlocked_ioctl() or ioctl() method.
compat_sys_ioctl then detects that BLKFLSBUF was already handled by
compat_blkdev_ioctl (it did not return -ENOIOCTLCMD) and propagates
the error code to user space, without printing the message.
Whatever is different from that description must be what goes wrong.
Arnd <><
^ permalink raw reply
* Re: USB Host Controlle for MPC855/MPC8xx in linux 2.4?
From: Gerhard Jaeger @ 2007-10-25 14:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <741129.8675.qm@web55901.mail.re3.yahoo.com>
On Donnerstag, 25. Oktober 2007, hamed khateb wrote:
> Hi
>
> anyone has driver for USB Host Controlle for MPC855/MPC8xx in linux 2.4?
>
> I read in the Archives mail which was sended by Henrik , Henrink use the driver of Brad Parker's for MPC875 (or MPC8xx) , so any one know how I can contact Henrik or Brad Parker's?
>
> this is the link of the email of Henrik : http://ozlabs.org/pipermail/linuxppc-embedded/2007-October/028566.html
>
You might have a look here:
http://www.heeltoe.com/software/usb/usb.html
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Wolfgang Grandegger @ 2007-10-25 15:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710250745i57f2a88sbc08478738ee382a@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Hello,
>>
>> The access to PCI memory space does not to work (I allways read 0xff) on
>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
>> realized, that CONFIG_PCI is not set in the default configuration.
>
> arch/ppc or arch/powerpc?
>
> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
> eth adapters plugged in and the devices are usable. This is a
> 2.6.24-rc1 arch/powerpc kernel.
I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
work either:
e100: probe of 0000:00:18.0 failed with error -11
It looks like that 2.6.23 needs some more patches.
Thanks.
Wolfgang.
^ permalink raw reply
* Re: libfdt: Test on trees with different block layouts
From: Jon Loeliger @ 2007-10-25 14:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071025050558.GE24856@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> At present, all the example dtbs we use in the testsuite are version
> 17 and have reservation map, then structure block then strings block
> (the natural ordering based on alignment constraints). However, all
> libfdt's read-only and in-place write functions should also work on
> v16 trees, and on trees with other layouts.
>
> This patch adds a testcase / utility function to rearrange the blocks
> of a dtb and/or regress a v17 tree to v16, and uses it to run tests on
> trees with different layouts and versions.
>
> Signed-off-by: David Gibson <david@tgibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: [PATCH 02/11] [POWERPC] Add 'lpb' bus type for MPC5200 LocalPlus Bus
From: Marian Balakowicz @ 2007-10-25 14:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071024000941.GA10926@lixom.net>
Olof Johansson wrote:
>
> On Wed, Oct 24, 2007 at 01:13:15AM +0200, Marian Balakowicz wrote:
>> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
>> ---
>
> Your patch lacks any kind of description beyond the title. (I know, it's a
> real simple patch, but a real simple description would do too :)
All right, will add one.
>
>> --- a/arch/powerpc/kernel/of_platform.c
>> +++ b/arch/powerpc/kernel/of_platform.c
>> @@ -49,6 +49,7 @@ static struct of_device_id of_default_bus_ids[] = {
>> { .type = "plb4", },
>> { .type = "opb", },
>> { .type = "ebc", },
>> + { .type = "lpb", },
>
> I thought it was consensus to keep the new bus ids only in platform
> code and not add them to the default list, and just pass that list in
> to of_platform_bus_probe().
Sounds reasonable, will move it to the 5xxx platform code.
Cheers,
m.
^ permalink raw reply
* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Geert Uytterhoeven @ 2007-10-25 14:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <200710251620.50218.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1797 bytes --]
On Thu, 25 Oct 2007, Arnd Bergmann wrote:
> On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> > If you want to look into this, the question is just why these messages are
> > printed now, while they weren't printed before. I don't think any other
> > behavior got changed.
>
> I'm not so sure about that. The reason that the messages are printed now
> is that there is no fallback handler for these ioctl numbers any more,
> but they are instead expected to be handled by the compat_blkdev_ioctl()
> function, which is only called for block devices.
>
> My first idea was that the ioctl numbers are used on files that are
> not block devices, in this case the warning message would be (somewhat)
> appropriate.
>
> Whenever we get one of these messages on a real block device, that is
> supposed to mean that an ioctl that was actually valid could not be
> executed, and compat_blkdev_ioctl() returned -ENOIOCTLCMD.
In many cases these ioctls can indeed not be handled.
E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
cache. But this ioctl is not supported, not before and not after 2.6.23.
Before 2.6.23, it didn't print the message, in 2.6.23, it does.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ 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