* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Wolfgang Grandegger @ 2009-03-27 8:07 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-mtd, devicetree-discuss list
In-Reply-To: <fa686aa40903261622wa2a93f9i98435080c7ab6cea@mail.gmail.com>
Grant Likely wrote:
> On Thu, Mar 26, 2009 at 4:14 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Anton Vorontsov wrote:
>>> On Thu, Mar 26, 2009 at 11:02:06AM -0600, Grant Likely wrote:
>>>> In other words, this device is not register-level compatible with the
>>>> fsl,upm-nand device. Give the node a new compatible value
>>>> (tqc,tqm8548-upm-nand) and add another entry to the of_fun_match table
>>>> for the new device. Use the .data element in the match table to
>>>> supply an alternate fun_cmd_ctrl() function for this board (instead of
>>>> using a property value do decide which fun_cmd_ctrl() behaviour to
>>>> use). New boards that *do* use the same addressing scheme can claim
>>>> compatibility with tqc,tqm8548-upm-nand.
>>> I don't like this. :-/
>>>
>>> UPM is an universal thing, so there are thousands of ways we can
>>> connect NAND to the UPM. Of which only ~10 would be sane (others are
>>> insane, and nobody would do this. If they do, _then_ we'll fall back
>>> to <board>-upm-nand scheme for a particular board).
>> Yep.
>>
>>> I don't see any problem with fsl,upm-addr-line-cs-offsets. It can
>>> describe any scheme in "addr lines are cs" connection, it's a common
>>> setup for multi-chip memory, we shouldn't treat it is as something
>>> extraordinary.
>> I fully agree. I'm going to provide a patch on monday.
>
> Well, I still don't think it is the wisest choice. My position is
> that it is better to be conservative and pedantic now because it is
> easy to relax the rules from that point. If it turns out after some
> experience with "fsl,upm-addr-line-cs-offset" that the scheme has a
> serious flaw, then the impact is contained. On the other side, if it
> is confirmed and useful and correct, it is a trivial change to make it
> available to everything that claims compatibility with fsl,upm-nand.
>
> That said, I won't oppose it if you go this route. However at the
> very least, please change the nand node's compatible list to be:
>
> compatible = "tqc,tqm8548-upm-nand", "fsl,upm-nand";
>
> The custom glue logic makes it something unique, so "tqc,..." should
> be at the start of the list to describe it as such, even if the driver
> only ever uses "fsl,upm-nand".
That's a good idea in case we need it lateron. For the time being, I
prefer to make the driver as generic as possible. Currently there are
only two boards using the driver, the MPC8360RTDK and the TQM8548. and
it's unlikely that there will be much more in the future.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Rework the TX logic.
From: David Miller @ 2009-03-27 7:42 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <OFEB54C9DC.647D70E1-ONC1257585.0064475A-C1257585.0064C85F@transmode.se>
These patches don't apply to the current tree, could you please
respin your final version against at the very least Linus's tree?
Thanks.
^ permalink raw reply
* Re: How to submit patches?
From: Stephen Rothwell @ 2009-03-27 6:55 UTC (permalink / raw)
To: Daniel Ng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <547eba1b0903262349ne434f33of96c0a31a452f2af@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
Hi Daniel,
On Fri, 27 Mar 2009 17:49:27 +1100 Daniel Ng <daniel.ng1234@gmail.com> wrote:
>
> What are the current requirements for submitting a patch?
See Documentation/SubmittingPatches in the kernel tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Next March 25: Boot failure on powerpc [recursive locking detected]
From: Stephen Rothwell @ 2009-03-27 6:53 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-scsi, James Bottomley, linuxppc-dev, linux-next
In-Reply-To: <20090327064208.GQ27476@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi Jens,
On Fri, 27 Mar 2009 07:42:08 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> I'll update for-next, sorry about that. I had dropped it from
> for-2.6.30, but forgot to update akpm/next branches.
Thanks. Its OK for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* How to submit patches?
From: Daniel Ng @ 2009-03-27 6:49 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
What are the current requirements for submitting a patch?
I have created a patch which provides an SPI_LSB_FIRST option for the
SPI Bit-banging driver.
The SPI Bit-banging driver currently only supports MSB-first data
transmission (see include/linux/spi/spi_bitbang.h).
If someone could point me to the relevant, current documentation for
submitting kernel driver patches, I'd be most appreciative.
Cheers,
Daniel
^ permalink raw reply
* Re: Next March 25: Boot failure on powerpc [recursive locking detected]
From: Jens Axboe @ 2009-03-27 6:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-scsi, James Bottomley, linuxppc-dev, linux-next
In-Reply-To: <20090327165624.47a29945.sfr@canb.auug.org.au>
On Fri, Mar 27 2009, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 26 Mar 2009 08:50:03 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >
> > On Thu, 2009-03-26 at 12:04 +0530, Sachin Sant wrote:
> > > Sachin Sant wrote:
> > > > Today's next failed to boot on a powerpc box
> > > > (Power6 blade IBM,7998-61X) with following recursive locking message.
> > > >
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 2.6.29-next-20090325 #1
> > > After bisecting the failure seems to be because of the following
> > > patch from James ( block: move SCSI timeout check into block )
> > >
> > > http://patchwork.kernel.org/patch/8017/
> > >
> > > If i back out the above mentioned patch, the machine boots fine
> > > without any problems.
> >
> > Yes, that patch already got dropped for other reasons:
> >
> > http://marc.info/?t=123740773700002
> >
> > I'm going to see if I can redo it in a better way, since moving this
> > type of timeout checking from scsi to block is a useful generalisation.
>
> I will revert it from next-20090327 as well as it is still in the
> for-next branch of the block tree.
I'll update for-next, sorry about that. I had dropped it from
for-2.6.30, but forgot to update akpm/next branches.
--
Jens Axboe
^ permalink raw reply
* Re: Next March 25: Boot failure on powerpc [recursive locking detected]
From: Stephen Rothwell @ 2009-03-27 5:56 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-scsi, James Bottomley, linuxppc-dev, linux-next
In-Reply-To: <1238075403.3342.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
Hi all,
On Thu, 26 Mar 2009 08:50:03 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Thu, 2009-03-26 at 12:04 +0530, Sachin Sant wrote:
> > Sachin Sant wrote:
> > > Today's next failed to boot on a powerpc box
> > > (Power6 blade IBM,7998-61X) with following recursive locking message.
> > >
> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.29-next-20090325 #1
> > After bisecting the failure seems to be because of the following
> > patch from James ( block: move SCSI timeout check into block )
> >
> > http://patchwork.kernel.org/patch/8017/
> >
> > If i back out the above mentioned patch, the machine boots fine
> > without any problems.
>
> Yes, that patch already got dropped for other reasons:
>
> http://marc.info/?t=123740773700002
>
> I'm going to see if I can redo it in a better way, since moving this
> type of timeout checking from scsi to block is a useful generalisation.
I will revert it from next-20090327 as well as it is still in the
for-next branch of the block tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix bugs introduced by sysfs changes (v2)
From: Benjamin Herrenschmidt @ 2009-03-27 5:29 UTC (permalink / raw)
To: linuxppc-dev
Rusty's patch to change our sysfs access to various registers
to use smp_call_function_single() introduced a whole bunch of
warnings. This fixes them. This version also fixes an actual
bug in here where it did mtspr instead of mfspr when reading
the files
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/sysfs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/sysfs.c 2009-03-27 14:12:04.000000000 +1100
+++ linux-work/arch/powerpc/kernel/sysfs.c 2009-03-27 14:16:06.000000000 +1100
@@ -134,17 +134,15 @@ void ppc_enable_pmcs(void)
}
EXPORT_SYMBOL(ppc_enable_pmcs);
-
#define SYSFS_PMCSETUP(NAME, ADDRESS) \
static void read_##NAME(void *val) \
{ \
- mtspr(ADDRESS, *(unsigned long *)val); \
+ *(unsigned long *)val = mfspr(ADDRESS); \
} \
-static unsigned long write_##NAME(unsigned long val) \
+static void write_##NAME(void *val) \
{ \
ppc_enable_pmcs(); \
mtspr(ADDRESS, *(unsigned long *)val); \
- return 0; \
} \
static ssize_t show_##NAME(struct sys_device *dev, \
struct sysdev_attribute *attr, \
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Anton Vorontsov @ 2009-03-26 23:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <fa686aa40903261622wa2a93f9i98435080c7ab6cea@mail.gmail.com>
On Thu, Mar 26, 2009 at 05:22:36PM -0600, Grant Likely wrote:
[...]
> That said, I won't oppose it if you go this route. However at the
> very least, please change the nand node's compatible list to be:
>
> compatible = "tqc,tqm8548-upm-nand", "fsl,upm-nand";
Yeah, that's definitely a good idea.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Grant Likely @ 2009-03-26 23:22 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, linux-mtd, devicetree-discuss list
In-Reply-To: <49CBFE52.6090706@grandegger.com>
On Thu, Mar 26, 2009 at 4:14 PM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> Anton Vorontsov wrote:
>> On Thu, Mar 26, 2009 at 11:02:06AM -0600, Grant Likely wrote:
>>> In other words, this device is not register-level compatible with the
>>> fsl,upm-nand device. =A0Give the node a new compatible value
>>> (tqc,tqm8548-upm-nand) and add another entry to the of_fun_match table
>>> for the new device. =A0Use the .data element in the match table to
>>> supply an alternate fun_cmd_ctrl() function for this board (instead of
>>> using a property value do decide which fun_cmd_ctrl() behaviour to
>>> use). =A0New boards that *do* use the same addressing scheme can claim
>>> compatibility with tqc,tqm8548-upm-nand.
>>
>> I don't like this. :-/
>>
>> UPM is an universal thing, so there are thousands of ways we can
>> connect NAND to the UPM. Of which only ~10 would be sane (others are
>> insane, and nobody would do this. If they do, _then_ we'll fall back
>> to <board>-upm-nand scheme for a particular board).
>
> Yep.
>
>> I don't see any problem with fsl,upm-addr-line-cs-offsets. It can
>> describe any scheme in "addr lines are cs" connection, it's a common
>> setup for multi-chip memory, we shouldn't treat it is as something
>> extraordinary.
>
> I fully agree. I'm going to provide a patch on monday.
Well, I still don't think it is the wisest choice. My position is
that it is better to be conservative and pedantic now because it is
easy to relax the rules from that point. If it turns out after some
experience with "fsl,upm-addr-line-cs-offset" that the scheme has a
serious flaw, then the impact is contained. On the other side, if it
is confirmed and useful and correct, it is a trivial change to make it
available to everything that claims compatibility with fsl,upm-nand.
That said, I won't oppose it if you go this route. However at the
very least, please change the nand node's compatible list to be:
compatible =3D "tqc,tqm8548-upm-nand", "fsl,upm-nand";
The custom glue logic makes it something unique, so "tqc,..." should
be at the start of the list to describe it as such, even if the driver
only ever uses "fsl,upm-nand".
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Xenomai on powerpc
From: Wolfgang Denk @ 2009-03-26 22:52 UTC (permalink / raw)
To: jeff angielski; +Cc: linuxppc-dev
In-Reply-To: <1238103309.20670.17.camel@penguin>
Dear jeff angielski,
In message <1238103309.20670.17.camel@penguin> you wrote:
>
> Which DENX git tree should I be using with the xenomai 2.4.7 patches?
> The linux-2.6-denx.git or the ipipe-2.6.git?
linux-2.6-denx.git
> I could not find the tags mentioned in the
> xenomai/ksrc/arch/powerpc/patches/README in either repository. In fact,
> the xenomai 2.6.28.5 patch won't compile against the 2.6-denx 2.6.28.5
> tag.
Did you really use the DENX-v2.6.28.5 tag?
[Note: this is kind of off topic here; you better ask such questions
either on the xenomai-help or the eldk mailing lists.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
-- Tom Christiansen in <5ldjbm$jtk$1@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: Bootlog bug?
From: Michael Ellerman @ 2009-03-26 22:51 UTC (permalink / raw)
To: ron_madrid; +Cc: linuxppc-dev
In-Reply-To: <736813.1073.qm@web83507.mail.sp1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]
On Thu, 2009-03-26 at 11:25 -0700, Ron Madrid wrote:
> I have a little problem with my boot messages. I'm not sure what this
> is, but does anyone have any ideas as to what it could be or what
> further information I could give to help track this down. As of now
> this is not manifesting itself, but I don't know what it might do.
You have ended up with a duplicate device, or duplicate device _name_,
somehow.
This is the warn:
WARN(ret == -EEXIST, KERN_WARNING "sysfs: duplicate filename '%s' "
"can not be created\n", sd->s_name);
Turning on verbose bug info would show you the name.
cheers
> ------------[ cut here ]------------
> Badness at c00bdebc [verbose debug info unavailable]
> NIP: c00bdebc LR: c00bdea4 CTR: 00000000
> REGS: c7827d90 TRAP: 0700 Not tainted (2.6.27)
> MSR: 00029032 <EE,ME,IR,DR> CR: 22022042 XER: 20000000
> TASK = c7816400[1] 'swapper' THREAD: c7826000
> GPR00: c00bdea4 c7827e40 c7816400 ffffffef c7800dcc c7800afc c7811540 00000000
> GPR08: 000001e0 c03c0000 00000040 00000000 82044048 10101400 07ffb000 00000000
> GPR16: 07ff0350 07ff59b4 00000000 00000000 00000000 c03ac84c c03ac820 c7857210
> GPR24: 00000000 00000000 00000000 00000001 c7811540 fffffffe c78b4480 c7827e58
> NIP [c00bdebc] sysfs_add_one+0x28/0x30
> LR [c00bdea4] sysfs_add_one+0x10/0x30
> Call Trace:
> [c7827e40] [c00bdea4] sysfs_add_one+0x10/0x30 (unreliable)
> [c7827e50] [c00bf12c] sysfs_do_create_link+0xac/0x15c
> [c7827e80] [c01a09b4] bus_add_device+0xf4/0x190
> [c7827ea0] [c019f1a0] device_add+0x38c/0x5c8
> [c7827ef0] [c0225db4] of_device_register+0x24/0x34
> [c7827f00] [c0009844] of_platform_device_create+0x44/0x74
> [c7827f10] [c00098ec] of_platform_bus_create+0x78/0xc8
> [c7827f30] [c0009a5c] of_platform_bus_probe+0x120/0x150
> [c7827f50] [c037a3e4] __machine_initcall_mpc831x_rdb_declare_of_platform_devices+0x4c/0x60
> [c7827f60] [c0003874] do_one_initcall+0x38/0x188
> [c7827fd0] [c036917c] kernel_init+0x88/0xf4
> [c7827ff0] [c0011b10] kernel_thread+0x44/0x60
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Wolfgang Grandegger @ 2009-03-26 22:14 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <20090326173302.GA23187@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Mar 26, 2009 at 11:02:06AM -0600, Grant Likely wrote:
> []
>>>> Here is another thought. The binding is describing that address lines
>>>> are used to activate CS lines. Offset for chip access purposes is
>>>> derived from the address line, but it doesn't directly describe the
>>>> hardware. The following may be a better description of the hardware.
>>>>
>>>> fsl,upm-addr-line-cs = <9 10>;
>>> The TQM8548 hardware has some logic connected to the two address lines
>>> allowing to select up to 4 chips with two address lines:
>>>
>>> fsl,upm-addr-line-cs-offsets = <0x0 0x200 0x400 0x600>
>> Ah. I see. This is board specific then. I think it is premature to
>> try and define a generic solution here because it depends on custom
>> board hardware and different boards could use very different logic.
>> The next board could end up doing something completely different. I'd
>> rather start to see trends in multiple boards implementing the same
>> scheme before trying to craft a generic scheme.
>>
>> In other words, this device is not register-level compatible with the
>> fsl,upm-nand device. Give the node a new compatible value
>> (tqc,tqm8548-upm-nand) and add another entry to the of_fun_match table
>> for the new device. Use the .data element in the match table to
>> supply an alternate fun_cmd_ctrl() function for this board (instead of
>> using a property value do decide which fun_cmd_ctrl() behaviour to
>> use). New boards that *do* use the same addressing scheme can claim
>> compatibility with tqc,tqm8548-upm-nand.
>
> I don't like this. :-/
>
> UPM is an universal thing, so there are thousands of ways we can
> connect NAND to the UPM. Of which only ~10 would be sane (others are
> insane, and nobody would do this. If they do, _then_ we'll fall back
> to <board>-upm-nand scheme for a particular board).
Yep.
> I don't see any problem with fsl,upm-addr-line-cs-offsets. It can
> describe any scheme in "addr lines are cs" connection, it's a common
> setup for multi-chip memory, we shouldn't treat it is as something
> extraordinary.
I fully agree. I'm going to provide a patch on monday.
Wolfgang.
^ permalink raw reply
* Xenomai on powerpc
From: jeff angielski @ 2009-03-26 21:35 UTC (permalink / raw)
To: linuxppc-dev
Which DENX git tree should I be using with the xenomai 2.4.7 patches?
The linux-2.6-denx.git or the ipipe-2.6.git?
I could not find the tags mentioned in the
xenomai/ksrc/arch/powerpc/patches/README in either repository. In fact,
the xenomai 2.6.28.5 patch won't compile against the 2.6-denx 2.6.28.5
tag.
TIA
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
^ permalink raw reply
* Re: Q: define i2c nodes in device tree?
From: Timur Tabi @ 2009-03-26 20:02 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1238093075.5262.0@antares>
2009/3/26 Albrecht Dre=DF <albrecht.dress@arcor.de>:
> and some other like "gpio-controller" instead of "gpio" but (surprise) it
> doesn't work - dmesg says that the driver is registered, but nothing else
> shows up. =A0Unfortunately, I couldn't find documentation about the namin=
g
> conventions of the i2c child nodes.
You need to have a "gpio I2C" device driver that registers the same
name as what's in the DTS, like this:
cs4270:codec@4f {
compatible =3D "cirrus,cs4270";
reg =3D <0x4f>;
/* MCLK source is a stand-alone oscillator */
clock-frequency =3D <12288000>;
};
...
static struct i2c_device_id cs4270_id[] =3D {
{"cs4270", 0},
{}
};
MODULE_DEVICE_TABLE(i2c, cs4270_id);
> As I actually want to use the chips as parallel io (not separate gpio's) =
and
> thus would need to write my own driver I wonder if I really have to decla=
re
> it in the device tree? =A0Would the simple way -just load the kernel modu=
le as
> with arm/intel- also work? =A0Would it be possible to use additional reso=
urces
> like an interrupt pin on the '5200 without the device tree?
No, the only acceptable way to do this is on PowerPC is with a device
tree entry and a driver that registers itself properly.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Q: define i2c nodes in device tree?
From: Albrecht Dreß @ 2009-03-26 18:44 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Hi all,
I have some probably dumb questions regarding the definition of i2c
slaves in the of device tree file...
My test system is a lite5200b board to which I attached two pca8575 io
expander chips at i2c addresses 0x20 and 0x21. Using the stock kernel
2.6.29, I added the driver from the GPIO section, but I couldn't figure
out how to add them to the dts file. I tried e.g.
<snip>
i2c@3d40 {
[...]
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
[...]
gpio@20 {
compatible = "pcf857x";
device_type = "gpio";
reg = <0x20 1>;
};
};
</snip>
and some other like "gpio-controller" instead of "gpio" but (surprise)
it doesn't work - dmesg says that the driver is registered, but nothing
else shows up. Unfortunately, I couldn't find documentation about the
naming conventions of the i2c child nodes.
As I actually want to use the chips as parallel io (not separate
gpio's) and thus would need to write my own driver I wonder if I really
have to declare it in the device tree? Would the simple way -just load
the kernel module as with arm/intel- also work? Would it be possible
to use additional resources like an interrupt pin on the '5200 without
the device tree?
Any information about a proper approach would be really helpful!
Thanks in advance, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Bootlog bug?
From: Ron Madrid @ 2009-03-26 18:25 UTC (permalink / raw)
To: linuxppc-dev
I have a little problem with my boot messages. I'm not sure what this is, but does anyone have any ideas as to what it could be or what further information I could give to help track this down. As of now this is not manifesting itself, but I don't know what it might do.
Using MPC831x RDB machine description
Linux version 2.6.27 (root@localhost.localdomain) (gcc version 4.2.2) #1 Fri Feb 6 15:06:45 PST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc831x_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
PCI host bridge /sleep-nexus/pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e2000000..0x00000000e20fffff -> 0x0000000000000000
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00008000
Normal 0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00008000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttyS0,115200
IPIC (128 IRQ sources) at fdefa700
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[7800001] shift[22] registered
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 125836k/131072k available (3684k kernel code, 5096k reserved, 128k data, 97k bss, 192k init)
SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 66.56 BogoMIPS (lpj=133120)
Mount-cache hash table entries: 512
net_namespace: 288 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:00.0: PME# disabled
bus: 00 index 0 io port: [0, fffff]
bus: 00 index 1 mmio: [90000000, 9fffffff]
bus: 00 index 2 mmio: [80000000, 8fffffff]
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
------------[ cut here ]------------
Badness at c00bdebc [verbose debug info unavailable]
NIP: c00bdebc LR: c00bdea4 CTR: 00000000
REGS: c7827d90 TRAP: 0700 Not tainted (2.6.27)
MSR: 00029032 <EE,ME,IR,DR> CR: 22022042 XER: 20000000
TASK = c7816400[1] 'swapper' THREAD: c7826000
GPR00: c00bdea4 c7827e40 c7816400 ffffffef c7800dcc c7800afc c7811540 00000000
GPR08: 000001e0 c03c0000 00000040 00000000 82044048 10101400 07ffb000 00000000
GPR16: 07ff0350 07ff59b4 00000000 00000000 00000000 c03ac84c c03ac820 c7857210
GPR24: 00000000 00000000 00000000 00000001 c7811540 fffffffe c78b4480 c7827e58
NIP [c00bdebc] sysfs_add_one+0x28/0x30
LR [c00bdea4] sysfs_add_one+0x10/0x30
Call Trace:
[c7827e40] [c00bdea4] sysfs_add_one+0x10/0x30 (unreliable)
[c7827e50] [c00bf12c] sysfs_do_create_link+0xac/0x15c
[c7827e80] [c01a09b4] bus_add_device+0xf4/0x190
[c7827ea0] [c019f1a0] device_add+0x38c/0x5c8
[c7827ef0] [c0225db4] of_device_register+0x24/0x34
[c7827f00] [c0009844] of_platform_device_create+0x44/0x74
[c7827f10] [c00098ec] of_platform_bus_create+0x78/0xc8
[c7827f30] [c0009a5c] of_platform_bus_probe+0x120/0x150
[c7827f50] [c037a3e4] __machine_initcall_mpc831x_rdb_declare_of_platform_devices+0x4c/0x60
[c7827f60] [c0003874] do_one_initcall+0x38/0x188
[c7827fd0] [c036917c] kernel_init+0x88/0xf4
[c7827ff0] [c0011b10] kernel_thread+0x44/0x60
Instruction dump:
912b0028 4bffffbc 9421fff0 7c0802a6 90010014 4bffff2d 2f83ffef 419e0014
80010014 38210010 7c0803a6 4e800020 <0fe00000> 4bffffec 9421ffe0 7c0802a6
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
msgmni has been set to 246
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
brd: module loaded
loop: module loaded
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:01
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
nand_bbt: ECC error while reading bad block table
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Creating 3 MTD partitions on "e2800000.flash":
0x00000000-0x00200000 : "u-boot"
0x00200000-0x00800000 : "kernel"
0x00800000-0x04000000 : "fs"
eLBC NAND device at 0xe2800000, bank 0
usbmon: debugfs is not available
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
Empty flash at 0x004dbca8 ends at 0x004dc000
Empty flash at 0x01381ad8 ends at 0x01382000
Empty flash at 0x01383264 ends at 0x01383800
Empty flash at 0x015a9048 ends at 0x015a9800
Empty flash at 0x015aa990 ends at 0x015ab000
Empty flash at 0x015ba24c ends at 0x015ba800
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 192k init
Thanks for the help.
Ron
^ permalink raw reply
* Re: [PATCH] ucc_geth: Rework the TX logic.
From: Joakim Tjernlund @ 2009-03-26 18:26 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090326180354.GA31732@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 26/03/2009 19:03:54:
>
> On Thu, Mar 26, 2009 at 06:44:05PM +0100, Joakim Tjernlund wrote:
> > The line:
> > if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
> > break;
> > in ucc_geth_tx() didn not make sense to me. Rework & cleanup
> > this logic to something understandable.
> > ---
> >
> > Reworked the patch according to Antons comments.
> >
> > drivers/net/ucc_geth.c | 66
+++++++++++++++++++++++++++--------------------
> > 1 files changed, 38 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> > index 7fc91aa..465de3a 100644
> > --- a/drivers/net/ucc_geth.c
> > +++ b/drivers/net/ucc_geth.c
> > @@ -161,6 +161,17 @@ static struct ucc_geth_info ugeth_primary_info =
{
> >
> > static struct ucc_geth_info ugeth_info[8];
> >
> > +
> > +static inline u32 __iomem *bd2buf(u8 __iomem *bd)
> > +{
> > + return (u32 __iomem *)(bd+4);
>
> Spaces around "+"...
Bugger, I forgot when I moved it.
>
> Also, now it's obvious that we're just reading status or buf.
>
> So instead of these inlines we could use struct qe_bd as described
> in asm/qe.h.
>
> I.e.
>
> struct qe_bd *bd = ...;
>
> in_be32(&bd->buf);
> in_be16(&bd->status);
>
> Oh, wait. We can't, ucc_geth assumes status is u32, which includes
> the length field, i.e. ucc_fast.h defines:
>
> #define T_W 0x20000000
>
> :-(
>
> The cleanup work surely desires a separate patch, so bd2buf and
> bd2status are OK, for now.
Exactly, I did look at using struct qe_bd *bd, but that will
affect lots of stuff. Reading the status and len in one go is
also quite handy so I not sure it is a good idea to convert.
>
> I'll test the patch as soon as I'll get some QE board back on
> my table (actually I have one QE board handy, but it's a 1GHz
> one, while I'd like to test the patch on a slow machine, where
> we'll actually see performance regressions).
Good, I have more coming but it touches the same code so I really want
to sort out this one first.
Jocke
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Rework the TX logic.
From: Joakim Tjernlund @ 2009-03-26 18:20 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090326180543.GA2406@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 26/03/2009 19:05:43:
> On Thu, Mar 26, 2009 at 05:43:25PM +0100, Joakim Tjernlund wrote:
> [...]
> > > bd == ugeth->confBd[txQ]
> > > and
> > > !in_be32((u32 __iomem *)(bd+4))
> > >
> > > Are not equivalent wrt. speed. MMIO accessors should be rather
> > > slow comparing to normal memory.
> >
> > Yes, I know. I did it this way because I something broke under stress
> > when ugeth->confBd[txQ] instead. The ucc_geth_tx() and
> > ucc_geth_start_xmit()
> > gets out of sync somehow.
>
> Would be great if you could investigate it more. Maybe there is
> a serious bug somewhere, or maybe you're introducing another
> (yet hidden) bug...
I have spent some time on it and didn't see how to do it. I don't think
the current method hides any bugs. I have used this method on 8xx for
many years and it works well.
Actually the current method might work without the
spin_lock_irq(&ugeth->lock)/spin_unlock_irq(&ugeth->lock)
in ucc_geth_start_xmit(). I can't break it, can you?
Jocke
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Rework the TX logic.
From: Anton Vorontsov @ 2009-03-26 18:05 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <OF5FC70952.28684E98-ONC1257585.005ADBF9-C1257585.005BDD35@transmode.se>
On Thu, Mar 26, 2009 at 05:43:25PM +0100, Joakim Tjernlund wrote:
[...]
> > bd == ugeth->confBd[txQ]
> > and
> > !in_be32((u32 __iomem *)(bd+4))
> >
> > Are not equivalent wrt. speed. MMIO accessors should be rather
> > slow comparing to normal memory.
>
> Yes, I know. I did it this way because I something broke under stress
> when ugeth->confBd[txQ] instead. The ucc_geth_tx() and
> ucc_geth_start_xmit()
> gets out of sync somehow.
Would be great if you could investigate it more. Maybe there is
a serious bug somewhere, or maybe you're introducing another
(yet hidden) bug...
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] ucc_geth: Rework the TX logic.
From: Anton Vorontsov @ 2009-03-26 18:03 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <1238089445-28396-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Thu, Mar 26, 2009 at 06:44:05PM +0100, Joakim Tjernlund wrote:
> The line:
> if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
> break;
> in ucc_geth_tx() didn not make sense to me. Rework & cleanup
> this logic to something understandable.
> ---
>
> Reworked the patch according to Antons comments.
>
> drivers/net/ucc_geth.c | 66 +++++++++++++++++++++++++++--------------------
> 1 files changed, 38 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 7fc91aa..465de3a 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -161,6 +161,17 @@ static struct ucc_geth_info ugeth_primary_info = {
>
> static struct ucc_geth_info ugeth_info[8];
>
> +
> +static inline u32 __iomem *bd2buf(u8 __iomem *bd)
> +{
> + return (u32 __iomem *)(bd+4);
Spaces around "+"...
Also, now it's obvious that we're just reading status or buf.
So instead of these inlines we could use struct qe_bd as described
in asm/qe.h.
I.e.
struct qe_bd *bd = ...;
in_be32(&bd->buf);
in_be16(&bd->status);
Oh, wait. We can't, ucc_geth assumes status is u32, which includes
the length field, i.e. ucc_fast.h defines:
#define T_W 0x20000000
:-(
The cleanup work surely desires a separate patch, so bd2buf and
bd2status are OK, for now.
I'll test the patch as soon as I'll get some QE board back on
my table (actually I have one QE board handy, but it's a 1GHz
one, while I'd like to test the patch on a slow machine, where
we'll actually see performance regressions).
[...]
> + tx_ind = (tx_ind + 1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
Line over 80 columns.
[...]
> + if (num_freed)
> + netif_wake_queue(dev); /* We freed some buffers, so restart transmission */
Ditto.
Please make sure your patches pass scripts/checkpatch.pl.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ucc_geth: Rework the TX logic.
From: Joakim Tjernlund @ 2009-03-26 17:44 UTC (permalink / raw)
To: avorontsov, leoli, linuxppc-dev, netdev; +Cc: Joakim Tjernlund
The line:
if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
break;
in ucc_geth_tx() didn not make sense to me. Rework & cleanup
this logic to something understandable.
---
Reworked the patch according to Antons comments.
drivers/net/ucc_geth.c | 66 +++++++++++++++++++++++++++--------------------
1 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 7fc91aa..465de3a 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -161,6 +161,17 @@ static struct ucc_geth_info ugeth_primary_info = {
static struct ucc_geth_info ugeth_info[8];
+
+static inline u32 __iomem *bd2buf(u8 __iomem *bd)
+{
+ return (u32 __iomem *)(bd+4);
+}
+
+static inline u32 __iomem *bd2status(u8 __iomem *bd)
+{
+ return (u32 __iomem *)bd;
+}
+
#ifdef DEBUG
static void mem_disp(u8 *addr, int size)
{
@@ -3048,6 +3059,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
u8 __iomem *bd; /* BD pointer */
u32 bd_status;
u8 txQ = 0;
+ int tx_ind;
ugeth_vdbg("%s: IN", __func__);
@@ -3057,21 +3069,19 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Start from the next BD that should be filled */
bd = ugeth->txBd[txQ];
- bd_status = in_be32((u32 __iomem *)bd);
+ bd_status = in_be32(bd2status(bd));
/* Save the skb pointer so we can free it later */
- ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]] = skb;
+ tx_ind = ugeth->skb_curtx[txQ];
+ ugeth->tx_skbuff[txQ][tx_ind] = skb;
/* Update the current skb pointer (wrapping if this was the last) */
- ugeth->skb_curtx[txQ] =
- (ugeth->skb_curtx[txQ] +
- 1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
+ tx_ind = (tx_ind + 1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
+ ugeth->skb_curtx[txQ] = tx_ind;
/* set up the buffer descriptor */
- out_be32(&((struct qe_bd __iomem *)bd)->buf,
- dma_map_single(&ugeth->dev->dev, skb->data,
- skb->len, DMA_TO_DEVICE));
-
- /* printk(KERN_DEBUG"skb->data is 0x%x\n",skb->data); */
+ out_be32(bd2buf(bd),
+ dma_map_single(&ugeth->dev->dev, skb->data,
+ skb->len, DMA_TO_DEVICE));
bd_status = (bd_status & T_W) | T_R | T_I | T_L | skb->len;
@@ -3088,9 +3098,9 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* If the next BD still needs to be cleaned up, then the bds
are full. We need to tell the kernel to stop sending us stuff. */
- if (bd == ugeth->confBd[txQ]) {
- if (!netif_queue_stopped(dev))
- netif_stop_queue(dev);
+
+ if (!in_be32(bd2buf(bd))) {
+ netif_stop_queue(dev);
}
ugeth->txBd[txQ] = bd;
@@ -3198,41 +3208,41 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
struct ucc_geth_private *ugeth = netdev_priv(dev);
u8 __iomem *bd; /* BD pointer */
u32 bd_status;
+ int tx_ind, num_freed;
bd = ugeth->confBd[txQ];
- bd_status = in_be32((u32 __iomem *)bd);
-
+ bd_status = in_be32(bd2status(bd));
+ tx_ind = ugeth->skb_dirtytx[txQ];
+ num_freed = 0;
/* Normal processing. */
while ((bd_status & T_R) == 0) {
/* BD contains already transmitted buffer. */
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
- if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
- break;
+ if (bd == ugeth->txBd[txQ])
+ break; /* Queue is empty */
dev->stats.tx_packets++;
/* Free the sk buffer associated with this TxBD */
- dev_kfree_skb(ugeth->
- tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
- ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] = NULL;
- ugeth->skb_dirtytx[txQ] =
- (ugeth->skb_dirtytx[txQ] +
- 1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
-
- /* We freed a buffer, so now we can restart transmission */
- if (netif_queue_stopped(dev))
- netif_wake_queue(dev);
+ dev_kfree_skb(ugeth->tx_skbuff[txQ][tx_ind]);
+ ugeth->tx_skbuff[txQ][tx_ind] = NULL;
+ out_be32(bd2buf(bd), 0); /* Mark it free */
+ num_freed++;
+ tx_ind = (tx_ind + 1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
/* Advance the confirmation BD pointer */
if (!(bd_status & T_W))
bd += sizeof(struct qe_bd);
else
bd = ugeth->p_tx_bd_ring[txQ];
- bd_status = in_be32((u32 __iomem *)bd);
+ bd_status = in_be32(bd2status(bd));
}
ugeth->confBd[txQ] = bd;
+ ugeth->skb_dirtytx[txQ] = tx_ind;
+ if (num_freed)
+ netif_wake_queue(dev); /* We freed some buffers, so restart transmission */
return 0;
}
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Anton Vorontsov @ 2009-03-26 17:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <fa686aa40903261002l2c8e0d41s6e5ad4bc049058bf@mail.gmail.com>
On Thu, Mar 26, 2009 at 11:02:06AM -0600, Grant Likely wrote:
[]
> >> Here is another thought. The binding is describing that address lines
> >> are used to activate CS lines. Offset for chip access purposes is
> >> derived from the address line, but it doesn't directly describe the
> >> hardware. The following may be a better description of the hardware.
> >>
> >> fsl,upm-addr-line-cs = <9 10>;
> >
> > The TQM8548 hardware has some logic connected to the two address lines
> > allowing to select up to 4 chips with two address lines:
> >
> > fsl,upm-addr-line-cs-offsets = <0x0 0x200 0x400 0x600>
>
> Ah. I see. This is board specific then. I think it is premature to
> try and define a generic solution here because it depends on custom
> board hardware and different boards could use very different logic.
> The next board could end up doing something completely different. I'd
> rather start to see trends in multiple boards implementing the same
> scheme before trying to craft a generic scheme.
>
> In other words, this device is not register-level compatible with the
> fsl,upm-nand device. Give the node a new compatible value
> (tqc,tqm8548-upm-nand) and add another entry to the of_fun_match table
> for the new device. Use the .data element in the match table to
> supply an alternate fun_cmd_ctrl() function for this board (instead of
> using a property value do decide which fun_cmd_ctrl() behaviour to
> use). New boards that *do* use the same addressing scheme can claim
> compatibility with tqc,tqm8548-upm-nand.
I don't like this. :-/
UPM is an universal thing, so there are thousands of ways we can
connect NAND to the UPM. Of which only ~10 would be sane (others are
insane, and nobody would do this. If they do, _then_ we'll fall back
to <board>-upm-nand scheme for a particular board).
I don't see any problem with fsl,upm-addr-line-cs-offsets. It can
describe any scheme in "addr lines are cs" connection, it's a common
setup for multi-chip memory, we shouldn't treat it is as something
extraordinary.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
From: Grant Likely @ 2009-03-26 17:02 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss list, linux-mtd
In-Reply-To: <49CBAED4.8030802@grandegger.com>
On Thu, Mar 26, 2009 at 10:35 AM, Wolfgang Grandegger <wg@grandegger.com> w=
rote:
> Grant Likely wrote:
>> On Thu, Mar 26, 2009 at 9:33 AM, Wolfgang Grandegger <wg@grandegger.com>=
wrote:
>>> Grant Likely wrote:
>>>> Does using the reg property give the driver enough information to
>>>> reliably program the MAR for NAND connections that use the address
>>>> line chip select scheme? =A0Related to that, should the binding includ=
e
>>> In principle yes:
>>>
>>> =A0if (i > 0)
>>> =A0 =A0 =A0offset[i] =3D resource[i].start - resource[0].start;
>>
>> Ewww. =A0That's ugly.
>
> Yep.
>
>>>> a property that explicitly states that an address line chip select
>>>> scheme is being used?
>>> That's why I'm still in favor of:
>>>
>>> =A0fsl,upm-multi-chip-offsets =3D <0x200 0x400>
>>>
>>> That would state that the address line chip select scheme is used with
>>> the specified offsets. It also allows for a more elegant solution
>>> (code-wise).
>>
>> Alright. =A0Then at the very least the property name should reflect that
>> address lines CS is used to reduce the chance of confusion with
>> another multi-chip scheme. =A0Something like
>> fsl,upm-addr-line-cs-offsets maybe?
>
>
>>
>> Here is another thought. =A0The binding is describing that address lines
>> are used to activate CS lines. =A0Offset for chip access purposes is
>> derived from the address line, but it doesn't directly describe the
>> hardware. =A0The following may be a better description of the hardware.
>>
>> fsl,upm-addr-line-cs =3D <9 10>;
>
> The TQM8548 hardware has some logic connected to the two address lines
> allowing to select up to 4 chips with two address lines:
>
> =A0fsl,upm-addr-line-cs-offsets =3D <0x0 0x200 0x400 0x600>
Ah. I see. This is board specific then. I think it is premature to
try and define a generic solution here because it depends on custom
board hardware and different boards could use very different logic.
The next board could end up doing something completely different. I'd
rather start to see trends in multiple boards implementing the same
scheme before trying to craft a generic scheme.
In other words, this device is not register-level compatible with the
fsl,upm-nand device. Give the node a new compatible value
(tqc,tqm8548-upm-nand) and add another entry to the of_fun_match table
for the new device. Use the .data element in the match table to
supply an alternate fun_cmd_ctrl() function for this board (instead of
using a property value do decide which fun_cmd_ctrl() behaviour to
use). New boards that *do* use the same addressing scheme can claim
compatibility with tqc,tqm8548-upm-nand.
You can still use the property names already discussed, but only
document them as valid for the tqc,tqm8548-upm-nand variant of the
device.
Very little will need to change in your patch to handle it this way.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI context.
From: Joakim Tjernlund @ 2009-03-26 16:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <49CB8DFD.2050504@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> wrote on 26/03/2009 15:15:25:
>=20
> Joakim Tjernlund a =E9crit :
> > Also set NAPI weight to 64 as this is a common value.
> > This will make the system alot more responsive while
> > ping flooding the ucc=5Fgeth ethernet interaface.
> >=20
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> > drivers/net/ucc=5Fgeth.c | 32 ++++++++++++--------------------
> > drivers/net/ucc=5Fgeth.h | 1 -
> > 2 files changed, 12 insertions(+), 21 deletions(-)
> >=20
> > diff --git a/drivers/net/ucc=5Fgeth.c b/drivers/net/ucc=5Fgeth.c
> > index 097aed8..7fc91aa 100644
> > --- a/drivers/net/ucc=5Fgeth.c
> > +++ b/drivers/net/ucc=5Fgeth.c
> > @@ -3214,7 +3214,7 @@ static int ucc=5Fgeth=5Ftx(struct net=5Fdevice *d=
ev,=20
u8 txQ)
> > dev->stats.tx=5Fpackets++;
> >=20
> > /* Free the sk buffer associated with this TxBD */
> > - dev=5Fkfree=5Fskb=5Firq(ugeth->
> > + dev=5Fkfree=5Fskb(ugeth->
> > tx=5Fskbuff[txQ][ugeth->skb=5Fdirtytx[txQ]]);
> > ugeth->tx=5Fskbuff[txQ][ugeth->skb=5Fdirtytx[txQ]] =3D NULL;
> > ugeth->skb=5Fdirtytx[txQ] =3D
> > @@ -3248,9 +3248,16 @@ static int ucc=5Fgeth=5Fpoll(struct napi=5Fstruc=
t=20
*napi, int budget)
>=20
> > for (i =3D 0; i < ug=5Finfo->numQueuesRx; i++)
> > howmany +=3D ucc=5Fgeth=5Frx(ugeth, i, budget - howmany);
>=20
> Not related to your patch, but seeing above code, I can understand
> you might have a problem in flood situation : Only first queue(s) are
> depleted, and last one cannot be because howmany >=3D budget.
>=20
> This driver might have to remember last queue it handled at previous
> call ucc=5Fgeth=5Fpoll(), so that all rxqueues have same probability to b=
e=20
scanned.
>=20
> j =3D ug->lastslot;
> for (i =3D 0; ug=5Finfo->numQueuesRx; i++) {
> if (++j >=3D ug=5Finfo->numQueuesRx)
> j =3D 0;
> howmany +=3D ucc=5Fgeth=5Frx(ugeth, j, budget - howmany);
> if (howmany >=3D budget)
> break;
> }
> ug->lastslot =3D j;
yes, or scan the RX queues in prio order. However ATM there is only
one queue so it won't be a problem until one extends the driver with
several queues.
Thanks,
Jocke
^ 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