ns. Engineering and scientific users find the -rt
beneficially for servicing hardware like sensors or control systems.
If you are just trying to run calculations as fast as you can in user
space, you'd be better off using the non-rt variants.
--
Jeff Angielski
The PTR
I tried using the scripts/Lindent on it to
be sure there were no coding style issues but that messed up even your original
code.
In any event, here it is again:
>From 9acd29ff48c64e58a7f5cdb888c86e737c56281c Mon Sep 17 00:00:00 2001
From: Jeff Angielski
Date: Mon, 10 May 2010 10:26:34 -
on.
>From 61f1c203620b06463695b399bae27a884008f169 Mon Sep 17 00:00:00 2001
From: Jeff Angielski
Date: Mon, 10 May 2010 10:26:34 -0400
Subject: [PATCH] hwmon: (tmp421) Add nfactor support
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a
hanging off of the remote channels.
Signed-off-by: Jeff Angielski
---
drivers/hwmon/tmp421.c | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..7944627 100644
--- a/d
Here is a second attempt at a patch to add nfactor support to the tmp421 driver.
This includes the changes as suggested by Andre Prendel, the original driver
author.
>From 8ebe84174ff6bd294656d77183758044f19d8900 Mon Sep 17 00:00:00 2001
From: Jeff Angielski
Date: Mon, 10 May 2010 10:26
On 05/11/2010 03:03 PM, Andre Prendel wrote:
On Mon, May 10, 2010 at 10:43:07AM -0400, Jeff Angielski wrote:
Hi Jeff,
A few comments below.
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski
---
drivers/hwmon/tmp421.c | 42 ++
1
ogus processor loops for short timings.
Thus our bogomips value is no longer the speed at which the processor
runs empty loops, but the actual processor timebase value as obtained
after calibration at boot. " - Benjamin Herrenschmidt
Google(powerpc, bogomips, timebase)=happiness
--
Jef
,
Jeff
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
-denx 2.6.28.5
tag.
TIA
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/rt_lock.h:232:1: warning: this is the location of the previous
definition
/home/jaa/src/linux-2.6/arch/powerpc/include/asm/rwsem.h:167: error: expected
identifier or '(' before '{' token
make[1]: *** [arch/powerpc/kernel/
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
clock-frequency = <0>;
};
Of course, you also need to update your ft_blob_update() in u-boot to
fill in the correct value.
The default values in the cpm2 code did not work for my system clock
configuration.
--
Je
On Mon, 2008-12-22 at 15:01 -0600, Scott Wood wrote:
> >
> > c...@119c0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "fsl,mrdig-cpm", "fsl,cpm2";
> > reg = <0x119c0 0x30>;
> >
compatible = "fsl,mrdig-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11340 0x20 0x8600 0x100 0x113d0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
implementation?
Is the 8260 arch fully supported in powerpc (as opposed to the old ppc)?
Thanks for any information or guidance...
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org
15 matches
Mail list logo