Hi Daniel,
On Fri, 27 Mar 2009 17:49:27 +1100 Daniel Ng wrote:
>
> What are the current requirements for submitting a patch?
See Documentation/SubmittingPatches in the kernel tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpiXY9t
Hi Jens,
On Fri, 27 Mar 2009 07:42:08 +0100 Jens Axboe 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 Rothwells...@canb.auug.org.au
http://www.canb
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 poin
On Fri, Mar 27 2009, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 26 Mar 2009 08:50:03 -0500 James Bottomley
> 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) w
Hi all,
On Thu, 26 Mar 2009 08:50:03 -0500 James Bottomley
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.
> > >
> > > ==
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
---
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.
On Thu, Mar 26, 2009 at 4:14 PM, Wolfgang Grandegger
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,t
Dear jeff angielski,
In message <1238103309.20670.17.ca...@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/pa
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,
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
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
2009/3/26 Albrecht Dreà :
> 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.
You
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 th
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 mac
Anton Vorontsov 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
Anton Vorontsov 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
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
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 ac
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 ++
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
On Thu, Mar 26, 2009 at 10:35 AM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> On Thu, Mar 26, 2009 at 9:33 AM, Wolfgang Grandegger
>> wrote:
>>> Grant Likely wrote:
Does using the reg property give the driver enough information to
reliably program the MAR for NAND connections
Eric Dumazet wrote on 26/03/2009 15:15:25:
>
> Joakim Tjernlund a écrit :
> > 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_geth ethernet interaface.
> >
> > Signed-off-by: Joakim Tjernlund
> > ---
> > d
Anton Vorontsov wrote on 26/03/2009 14:39:18:
>
> Hi Joakim,
Hi Anton
>
> On Thu, Mar 26, 2009 at 01:54:37PM +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. Rewo
Grant Likely wrote:
> On Thu, Mar 26, 2009 at 9:33 AM, Wolfgang Grandegger
> 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? Related to that, sh
On Wed, Mar 25, 2009 at 07:06:50PM +0200, Goldberger, Yigal wrote:
> I'll try to be as accurate as I can.
> Yesterday I downloaded ELDK 4.2 from DENX site and Installed it.
> I want to build a Xenomai enabled kernel.
> I saw that my kernel is 2.6.24-xenomai and that's what I'm trying to build.
[sni
On Thu, Mar 26, 2009 at 9:33 AM, Wolfgang Grandegger
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? Related to that, should the binding include
>
>
Grant Likely wrote:
> On Thu, Mar 26, 2009 at 1:42 AM, Wolfgang Grandegger
> wrote:
>> Grant Likely wrote:
>>> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger
>>> wrote:
Grant Likely wrote:
> For the chip offset, it's not clear what the meaning is. First, does
> the UPM contr
On Wed, Mar 11, 2009 at 7:22 PM, Timur Tabi wrote:
> Add the definition of the fsl,ssi-asynchronous property to ssi.txt
> (documentation
> of the device tree bindings for the Freescale SSI device).
>
> Also tidy up the layout of ssi.txt.
>
> Signed-off-by: Timur Tabi
Kumar, can you pick this up
On Thu, Mar 26, 2009 at 1:42 AM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger
>> wrote:
>>> Grant Likely wrote:
For the chip offset, it's not clear what the meaning is. First, does
the UPM controller support access of multip
Joakim Tjernlund a écrit :
> 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_geth ethernet interaface.
>
> Signed-off-by: Joakim Tjernlund
> ---
> drivers/net/ucc_geth.c | 32
>
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
output of lspci -vv
-bash-3.2# lspci -vv
00:0c.0 Class 0c03: Unknown device 1106:3038 (rev 62)
Subsystem: Unknown device 1106:3038
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Ste-Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
TAb
Hi Joakim,
On Thu, Mar 26, 2009 at 01:54:37PM +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.
>
> Signed-off-by:
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_geth ethernet interaface.
Signed-off-by: Joakim Tjernlund
---
drivers/net/ucc_geth.c | 32
drivers/net/ucc_geth.h |1 -
2 files
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.
Signed-off-by: Joakim Tjernlund
---
drivers/net/ucc_geth.c | 40 ---
Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:
Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc001af64
Oops: Kernel access of bad area, sig: 11 [#1]
The wrong usage of "(void *)__pa(&temperature)" in rt
Grant Likely wrote:
> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger
> wrote:
>> Grant Likely wrote:
>>> For the chip offset, it's not clear what the meaning is. First, does
>>> the UPM controller support access of multiple chips simultaneously?
>> The offset drives the corresponding addre
38 matches
Mail list logo
