On Monday 18 February 2013, Dongjin Kim wrote:
This patch adds the compatible string for MSHC controller of Exynos4412, and
share the controller specific properties with Exynos5250 since they have same
features. Its driver data name is changed to exynos_drv_data instead SoC
specific name.
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without
On Tuesday 19 February 2013, Alexander Shiyan wrote:
Hello.
Strange, but I not received an original answer from Arnd, have only this mail.
I got a reject notice from mail.ru, which apparently didn't like the
SMTP server of my German ISP. I already tried to resend my mail to you,
and now try
:
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tuesday 19 February 2013, kishon wrote:
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY
drivers
to create/destroy a PHY and APIs for the PHY
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that
On Tuesday 19 February 2013, kishon wrote:
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
Currently drivers/phy and drivers/net/phy are independent and are not
related to each other. There are some fundamental differences on how
these frameworks work. IIUC
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
It's a fine line, but I think a phy is something that resembles
On Friday 15 February 2013, Lee Jones wrote:
struct ab8500 *ab8500;
+ int chip_id = -EINVAL;
ab8500 = dev_get_drvdata(dev);
- return sprintf(buf, %#x\n, ab8500 ? ab8500-chip_id : -EINVAL);
+ if(ab8500) {
+ chip_id = ab8500-chip_id;
+
On Friday 15 February 2013, Lee Jones wrote:
+ {
+ .name = ab8500-charger,
+ .of_compatible = stericsson,ab8500-charger,
+ .num_resources = ARRAY_SIZE(ab8500_charger_resources),
+ .resources = ab8500_charger_resources,
+#ifndef
On Wednesday 20 February 2013, Vinod Koul wrote:
Since there is still churn, would it make sense if I just revert the SPEAr13xx
patch (your first patch) and send a pull request to Linus.
Since there are no users and not much testing has been done, I think we can
push
these to 3.10 via
On Wednesday 20 February 2013, Alexander Shiyan wrote:
On 20 February 2013 13:41, Alexander Shiyan shc_w...@mail.ru wrote:
One problem is that every user needs to add their syscon compatible device
support(platform_device_id) in syscon driver first before they can use it.
But it looks to
On Wednesday 20 February 2013, Vinod Koul wrote:
On Wed, Feb 20, 2013 at 09:50:25AM +, Arnd Bergmann wrote:
On Wednesday 20 February 2013, Vinod Koul wrote:
Since there is still churn, would it make sense if I just revert the
SPEAr13xx
patch (your first patch) and send a pull
On Wednesday 20 February 2013, Dong Aisheng wrote:
On 20 February 2013 18:06, Arnd Bergmann a...@arndb.de wrote:
I would first like to get an answer to the question I asked in my first
mail,
which is what the use case of non-DT support in this driver is. If this
is used only by a new
On Wednesday 20 February 2013, Dong Aisheng wrote:
But one question i wonder is that it may be hard to know how many poteintial
non-dt platforms may use syscon.
Yes, good point. Of course we want as many platforms as possible to
use syscon, just like we want them to use DT, because both things
On Wednesday 20 February 2013, Alexander Shiyan wrote:
OK. I can convert platform to DT, no so easy, but possible.
But I will use syscon as way to using DT (and MULTIPLATFORM in the future),
this mean that I should completely drop ATAG support from this platform
(since I cannot use syscon
are merged
is below.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 4fef29f..5829b67 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -76,9 +76,6 @@ config HAVE_LATENCYTOP_SUPPORT
config NO_DMA
def_bool n
-config ARCH_NO_VIRT_TO_BUS
On Wednesday 20 February 2013, Alexander Shiyan wrote:
No. Target have a three SYSCON registers and two SYSFLG. All these registers
can be combined into three syscon devices.
Only these registers will be handled via syscon device, so it is not only one.
Or you mean about handle all register
On Wednesday 20 February 2013, Alexander Shiyan wrote:
On Wednesday 20 February 2013, Alexander Shiyan wrote:
No. Target have a three SYSCON registers and two SYSFLG. All these
registers
can be combined into three syscon devices.
Only these registers will be handled via syscon
-off-by: Alexander Shiyan shc_w...@mail.ru
Looks good to me now.
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers
for you to fetch changes up to
bindings for mmc and i2c
* tegra bindings for hdmi, keyboard, audio, as well as some updates
* at91 bindings for hardware ecc and for devices on RM9200
* mxs bindings for cfa100xx
* sunxi support for Miniand Hackberry board
Arnd Bergmann
, separating
these from the Versatile Express reference implementation.
Obviously, this new platform is multiplatform capable so it
can be combined with existing machines in the same kernel.
Arnd Bergmann (2):
ARM: arch_timer: include
The following changes since commit 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39:
Linux 3.8-rc7 (2013-02-09 08:20:39 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/boards
for you to fetch changes up to
Andrew Lunn (1):
cpuidle: kirkwood: Move out of mach directory
Arnd Bergmann (5):
ARM: prima2: fix __init section for cpu hotplug
Merge tag 'renesas-soc5-for-v3.9' of
git://git.kernel.org/.../horms/renesas into next/soc
Merge tag 'omap-for-v3.9/usb
, but this
is the initial conversion.
Arnd Bergmann (2):
Merge tag 'renesas-pinmux2-for-v3.9' of
git://git.kernel.org/.../horms/renesas into next/sh-pinmux
Merge branch 'next/sh-pinmux' into for-next
Laurent Pinchart (80
irq_match array has context clashes with turning
omap4_sar_ram_init into an omap_early_initcall()
André Hentschel (1):
ARM: OMAP2+: Include soc.h to drm.c to fix compiling
Arnd Bergmann (5):
[media] davinci: do
unneeded include files
cpuidle: kirkwood: Move out of mach directory
André Hentschel (1):
ARM: OMAP2+: Include soc.h to drm.c to fix compiling
AnilKumar Ch (1):
ARM: OMAP2+: AM33XX: omap2plus_defconfig: Add support for few drivers
Arnd Bergmann (31):
mfd/vexpress
early uart output in fifo mode
Arnd Bergmann (17):
mfd/vexpress: vexpress_sysreg_setup must not be __init
ARM: msm: proc_comm_boot_wait should not be __init
ARM: disable virt_to_bus/virt_to_bus almost everywhere
ARM: samsung: fix assembly syntax for new gas
ARM
On Friday 22 February 2013, Thierry Reding wrote:
On Fri, Feb 22, 2013 at 03:13:12PM +0800, Dong Aisheng wrote:
On Fri, Feb 22, 2013 at 11:01:18AM +0400, Alexander Shiyan wrote:
On Thu, Feb 21, 2013 at 07:29:02PM +0400, Alexander Shiyan wrote:
This patch allow using syscon driver from
/.. later
2. Some of the fallout of review (DeviceTree support, multi-platform-image
support) were added on top of orig series, primarily to record the revision
history.
For the series:
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Saturday 23 February 2013, Alexander Shiyan wrote:
The driver can be used in various subsystems and therefore should not
be unloaded when it is defined in the kernel configuration, so remove
support for unloading it.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
I think the
On Tuesday 19 February 2013, Cyrill Gorcunov wrote:
From: Alexander Kartashov alekskartas...@parallels.com
Subject: arm: Wire up kcmp syscall
Signed-off-by: Alexander Kartashov alekskartas...@parallels.com
Cc: Russell King li...@arm.linux.org.uk
Acked-by: Arnd Bergmann a...@arndb.de
Looks
On Friday 15 February 2013, Lee Jones wrote:
A recent patch saw the device.h include being removed from some other
include files and replaced with a 'struct device' declaration instead.
However, neither the include nor the declaration is actually required.
Signed-off-by: Lee Jones
On Monday 25 February 2013, Vineet Gupta wrote:
Have you queued up this change via one of your trees already for 3.9-rcX ?
If not, I can fold it in with a bunch of Kconfig cleanups for ARC
(GENERIC_SIGALTSTACK, HAVE_IRQ_WORK), given that those bits are already in
linus'
tree.
I haven't
On Monday 25 February 2013, Lee Jones wrote:
and others that use 'struct device'. C99 requires that a struct is declared
in advance before you use it in a function declaration.
Hmm... I wonder why it doesn't complain then?
I'll remove the patch.
It's only a problem if the file is
its registers.
The actual PPE- and SPE-side context switch code are two separate
patches.
From: Mark Nutter [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
arch/ppc64/kernel/spu_base.c| 27 ++
fs/spufs/Makefile |4
fs/spufs/context.c
Thankfully, there is now documentation available to the world about
the Cell architecture (http://cell.scei.co.jp/e_download.html), so I
am now able to disclose more of our work on the SPU file system.
This is a rather big update compared to the previous version, as it
contains work from Mark
[EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
context.c | 48
file.c | 239
spufs.h |3
4 files changed, 243 insertions(+), 47 deletions(-)
--- linux-cg.orig/fs/spufs/context.c2005
PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
Makefile | 46 +++
spu_restore.c | 336 +
spu_restore_crt0.S | 116 ++
spu_save.c | 203
spu_save_crt0.S
about dropping the functionality
again.
If anyone has strong opinions on how useful or harmful
this patch is, please tell me.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
arch/ppc64/kernel/spu_base.c |7 +++
fs/spufs/file.c | 16
include/asm-ppc64
the execution is done
with new system calls instead of mkdir, rmdir and this
call.
This will make an SPU thread a property of a Linux user
space thread instead of the global object that can be
used by any process.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
arch/ppc64/kernel/misc.S |2
fs
On Freedag 26 August 2005 10:17, Pekka Enberg wrote:
I am confused. The code is architecture specific and does device I/O. Why do
you want to put this in fs/ and not drivers/?
I never really thought of it as a device driver but rather an architecture
extension, so it started out in
On Dunnersdag 01 September 2005 06:22, Murali N Iyer wrote:
Architecture cell seems to be fine. What is your thought on supporting
multiple different hardware configurations under cell. I think this patch
has been tested only in CPBW hardware. For example +++
My general idea about future Cell
substantial changes
at some point, e.g. when we merge arch/powerpc/kernel/setup.c.
However, I don't think it makes much difference wether that
is done while the code resides in arch/ppc64 or arch/powerpc.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--
arch/powerpc/platforms/cell/Makefile
On Middeweken 17 August 2005 21:52, [EMAIL PROTECTED] wrote:
+#ifdef __KERNEL_SYSCALLS__
+#include linux/compiler.h
+#include linux/types.h
+#include linux/syscalls.h
+
+struct pt_regs;
+struct sigaction;
+asmlinkage long xtensa_execve(char *filenamei, char **argv, char **envp,
+
These are a few updates for the BPA platform of ppc64. Only the first
two patches are meant for inclusion, the others are provided here
for people who are running on Cell already and cannot wait for clean
versions of the patches ;-)
I also have lots of updates pending for spufs, but will send
performance on
SMP systems spurious kernel panics in the IPI code.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--- linux-2.6.13-rc6.orig/arch/ppc64/kernel/bpa_iic.c
+++ linux-2.6.13-rc6/arch/ppc64/kernel/bpa_iic.c
@@ -205,6 +205,18 @@ static struct iic_regs __iomem *find_iic
}
#ifdef CONFIG_SMP
in applying the patch to generic kernels.
You will however need it if you intend to run on present Cell
hardware.
From: Utz Bacher [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
--- linux-cg.orig/drivers/char/Kconfig 2005-08-18 17:09:44.971886072 -0400
+++ linux-cg/drivers/char/Kconfig
This patch is not meant for inclusion in a generic kernel,
but is currently needed to support the available HW.
Most of the things done in here are workarounds for
deficiencies in the present hardware or firmware that
will be solved there in later releases.
Signed-off-by: Arnd Bergmann [EMAIL
- fix device cleanup
From: Jens Osterkamp [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
diff -u devel-akpm/drivers/net/spider_net.c
linux-2.6.13-rc3/drivers/net/spider_net.c
--- devel-akpm/drivers/net/spider_net.c 2005-08-06 15:34:31.0 -0700
+++ linux-2.6.13-rc3/drivers
On Dinsdag 23 August 2005 22:43, Miklos Szeredi wrote:
64 bit architectures all implement their own compatibility sys_open(),
when in fact the difference is simply not forcing the O_LARGEFILE
flag. So use the a common function instead.
Index: linux/arch/x86_64/ia32/sys_ia32.c
On Friday 26 January 2007 21:41, Andrew Morton wrote:
I'm somewhat surprised that this wasn't done earlier. I wonder if there's
some subtle reason why this won't work. How well tested is this?
http://www.opengroup.org/onlinepubs/95399/functions/utimes.html
lists a slight difference
.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
This bug was reported earlier in
http://bugzilla.kernel.org/show_bug.cgi?id=7711 by
[EMAIL PROTECTED]
I have not been able to find out _why_ all my CF cards reject
the SETFEATURES_XFER command, but I have verified that the
same happens when trying
in the cell_virtual_cntr() routine
was moved to a for-loop before the for_each_cpu loop
Signed-off-by: Carl Love [EMAIL PROTECTED]
Signed-off-by: Maynard Johnson [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Just a small side note: Please give each of your patches a one-line
summary
[EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Any suggestion for a one-line patch title?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Monday 29 January 2007 20:48, Maynard Johnson wrote:
Subject: Enable SPU switch notification to detect currently active SPU tasks.
From: Maynard Johnson [EMAIL PROTECTED]
This patch adds to the capability of spu_switch_event_register so that the
caller is also notified of currently
On Tuesday 30 January 2007 05:24, Dirk Hohndel wrote:
I thought there was coldfire mentioned too, or maybe my memory is
playing tricks on me. Maybe I'm misremembering the ppc bit.
I believe we had AMD, Freescale and Intel last year, no PPC.
Freescale's bigger CPUs are all PPC, although
On Monday 29 January 2007 20:45, Maynard Johnson wrote:
On December 14, 2006, I posted a patch that added support to the
OProfile kernel driver for profiling Cell SPUs. There have been some
changes/fixes to this patch since the original posting (including
forward porting from 2.6.18-based
On Tuesday 30 January 2007 16:31, Maynard Johnson wrote:
On solution would be to move the notify_active flag from ctx-spu
into ctx itself, but maybe there are other ways to solve this.
In an earlier review of this patch, Christopher Hellwig suggested I move
the notify_active flag to be a
On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
Arnd Bergmann wrote:
+ kt = ktime_set(0, profiling_interval);
+ if (!spu_prof_running)
+ goto STOP;
+ hrtimer_forward(timer, timer-base-get_time(), kt);
+ return HRTIMER_RESTART
On Wednesday 31 January 2007 00:31, Carl Love wrote:
Unfortunately, the only way we know how to
figure out what the LFSR value that corresponds to the number in the
sequence that is N before the last value (0xFF) is to calculate the
previous value N times. It is like trying to ask what is
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
Why do you store them per spu in the first place? The physical spu
doesn't have any relevance to this at all, the only data that is
per spu is the sample data collected on a profiling interrupt,
which you can then copy in the
On Thursday 28 December 2006 16:51, Avi Kivity wrote:
Greg, /dev/kvm is a MISC_DYNAMIC_MINOR device. Is there any way of
using it without udev? Should I allocate a static number?
You can write a small script that parses /proc/misc and creates the device,
like
# /sbin/mknod /dev/kvm c 10
On Sunday 31 December 2006 13:32, Pierre Ossman wrote:
Arnd Bergmann wrote:
I'm a complete MTD noob, but what uses does the MTD layer have besides
JFFS2. If it's none, than this advantage isn't that big of a deal.
* It becomes possible to use MMC cards with jffs2 even with CONFIG_BLOCK
of a hotplug even, or happening at
boot-time.
It has been compile tested on ia64, s390, i386 and x86_64.
I can't test it here, since I'm travelling at the moment, but
this version looks good to me. Thanks for picking it up again!
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
Acked-by: Arnd
On Monday 08 January 2007 00:43, Stephen Rothwell wrote:
+asmlinkage long sys_sysinfo(struct sysinfo __user *info)
+{
+ struct sysinfo val;
+
+ do_sysinfo(val);
- out:
if (copy_to_user(info, val, sizeof(struct sysinfo)))
return -EFAULT;
People have
On Sünnavend 06 August 2005 01:43, Linus Torvalds wrote:
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -324,7 +324,7 @@ EXPORT_SYMBOL(__res);
EXPORT_SYMBOL(next_mmu_context);
On Maandag 08 August 2005 14:06, Hiroki Kaminaga wrote:
If the cause is in some insmod'ed module, then I would like to get
info of that module. If I get the address of that module, I can get
info such as symbol name defined by that module, etc. Then I could say
in module mmm, at func fff, at
the symbol directly. This does a little less compile-time
checks but helps reduce the noise. The big advantage of this
would be that we could once again build kernels with -Werror on
developer machines.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/include/linux/module.h b/include
On Friday 15 December 2006 18:14, Dave Hansen wrote:
+ if (system_state = SYSTEM_RUNNING)
+ return 1;
+ if (!early_pfn_valid(pfn))
+ return 0;
+ if (!early_pfn_in_nid(pfn, nid))
+ return 0;
I haven't tried it, but I assume this is
On Saturday 16 December 2006 09:03, KAMEZAWA Hiroyuki wrote:
@@ -273,10 +284,13 @@
if (ret)
goto error;
}
+ atomic_inc(memory_hotadd_count);
/* call arch's memory hotadd */
ret = arch_add_memory(nid, start, size);
On Tuesday 19 December 2006 00:16, Dave Hansen wrote:
How about an enum, or a pair of #defines?
enum context
{
EARLY,
HOTPLUG
};
Sounds good, but since this is in a global header file, it needs
to be in an appropriate name space, like
enum memmap_context {
On Monday 18 December 2006 08:17, Karel Zak wrote:
- remove FS/device detection code
(libblkid from e2fsprogs or libvolumeid is replacement)
I saw that the current Fedora already dynamically links /bin/mount
against /usr/lib/libblkid.so. This obviously does not work if
/usr is
On Wednesday 27 December 2006 04:08, H. Peter Anvin wrote:
I'd suggest that you make sure that mount always gets statically linked
against libblkid to avoid these problems.
That's a pretty silly statement. The real issue is that any library
needed by binaries in /bin or /sbin should
On Wednesday 27 December 2006 19:15, Karel Zak wrote:
On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
On Monday 18 December 2006 08:17, Karel Zak wrote:
- remove FS/device detection code
(libblkid from e2fsprogs or libvolumeid is replacement)
I saw
amount of kernel memory on
small machines that have an MMC slot but no other block device.
I still want to be sure that I'm on the right track with this driver
and did not make a conceptual mistake.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Index: linux-cg/drivers/mmc/mmc.c
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
[c02b0289] __sched_text_start+0x5f9/0xb00
[c024a623] net_rx_action+0xb3/0x180
[c01210f2] __do_softirq+0x72/0xe0
[c0105205] do_IRQ+0x45/0x80
This doesn't seem to be related
On Tuesday 09 January 2007 14:37, Avi Kivity wrote:
struct kvm_vcpu_area {
u32 vcpu_area_size;
u32 exit_reason;
sigset_t sigmask; // for use during vcpu execution
Since Jeff brought up the point of 32 bit compatibility:
When this structure is shared between 64 bit kernel and
32
On Tuesday 09 January 2007 14:47, Jeff Garzik wrote:
Can we please avoid adding a ton of new ioctls? ioctls inevitably
require 64-bit compat code for certain architectures, whereas
sysfs/procfs does not.
For performance reasons, an ascii string based interface is not
desireable here, some
On Friday 01 December 2006 14:19, Jan Glauber wrote:
I've chosen the char driver since it allows the user to decide which
pseudo-random
numbers he wants to use. That means there is a new interface for the s390
PRNG, called /dev/prandom.
I would like to know if there are any objections,
On Wednesday 06 December 2006 23:04, Maynard Johnson wrote:
text(struct spu *spu, struct
spu_context *ctx)
Is this really the right strategy? First, it serializes all spu
context
switching at the node level. Second, it performs 17 callouts for
I could be wrong, but I think if
On Friday 08 December 2006 18:10, Maynard Johnson wrote:
#define _SPU_H
#ifdef __KERNEL__
+#include linux/fs.h
+#include linux/notifier.h
#include linux/workqueue.h
#include linux/sysdev.h
Thanks for pointing this out. I'm fixing this in a different way though,
with by adding
of problem, it also adds a WARN_ON(!buf)
to sg_set_buf() so we get a log message even platforms without
sparsemem.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/drivers/ata/libata-core.c
===
--- linux-2.6.orig/drivers
After a lot of debugging in spufs, I found that a crash that we encountered
on Cell actually was caused by a change in the memory management.
The patch that caused it is archived in http://lkml.org/lkml/2006/11/1/43,
and this one has been discussed back and forth, but I fear that the current
On Thursday 14 December 2006 00:17, Mike Kravetz wrote:
Thanks for the debug work! Just curious if you really need
CONFIG_NODES_SPAN_OTHER_NODES defined for your platform? Can you get
those types of memory layouts? If not, an easy/immediate fix for you
might be to simply turn off the
On Friday 01 December 2006 18:21, Al Viro wrote:
There is a tempting
possibility to do that gradually, with all intermediates still in working
state, provided that on all platforms currently supported by the kernel
unsigned long and void * are indeed passed the same way (again, only for
On Friday 01 December 2006 21:01, Maynard Johnson wrote:
+static void notify_spus_active(void)
+{
+ int node;
+ for (node = 0; node MAX_NUMNODES; node++) {
+ struct spu *spu;
+ mutex_lock(spu_prio-active_mutex[node]);
+
On Thursday 16 November 2006 01:45, Christoph Lameter wrote:
On Thu, 16 Nov 2006, Arnd Bergmann wrote:
- we want to be able to boot with the 'mem=512M' option, which effectively
disables the memory on the second node (each node has 512MiB).
- Each node has 8 SPUs, all of which we want
On Thursday 16 November 2006 19:04, Avi Kivity wrote:
+struct kvm_msr_entry {
+ __u32 index;
+ __u32 reserved;
+ __u64 data;
+};
+
+/* for KVM_GET_MSRS and KVM_SET_MSRS */
+struct kvm_msrs {
+ __u32 vcpu;
+ __u32 nmsrs; /* number of msrs in entries */
+
+
On Sunday 19 November 2006 21:30, Jay Cliburn wrote:
This patch contains the main C file for the Attansic L1 gigabit ethernet
adapter driver.
Just a few style comments:
+ /* PCI config space info */
+ hw-vendor_id = pdev-vendor;
+ hw-device_id = pdev-device;
+
On Thursday 06 September 2012, ABRAHAM, KISHON VIJAY wrote:
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++
On Friday 07 September 2012, Lee Jones wrote:
+ // External Micro SD slot
+ sdi@80126000 {
+ arm,primecell-periphid = 0x10480180;
+ max-frequency = 5000;
+ bus-width = 8;
+
On Friday 07 September 2012, Lee Jones wrote:
The HREF Device Tree now has support for its four SDIs. So, if we
continue registering them from platform code when Device Tree is
enabled we'll cause a double probe of the same devices. To prevent
that we'll just remove registration.
On Friday 07 September 2012, Lee Jones wrote:
MFD core code attempts to convert specified hardware (local) IRQ
numbers to virtual-IRQs, which something Linux can understand. This
works great when only one IRQ is specified. However, converting
entire ranges is currently unsupported. If this
On Friday 07 September 2012, Lee Jones wrote:
Based on v3.6-rc4
This patch consists of Device Tree related enablement for
ST-Ericsson's development HREF hardware reference board.
Most devices are very similar, if not the same to the
previously enabled Snowball low-cost development board.
On Friday 07 September 2012, Lee Jones wrote:
On Fri, Sep 07, 2012 at 12:35:41PM +, Arnd Bergmann wrote:
On Friday 07 September 2012, Lee Jones wrote:
MFD core code attempts to convert specified hardware (local) IRQ
numbers to virtual-IRQs, which something Linux can understand
On Friday 07 September 2012, Lee Jones wrote:
On Fri, Sep 07, 2012 at 01:37:26PM +, Arnd Bergmann wrote:
On Friday 07 September 2012, Lee Jones wrote:
On Fri, Sep 07, 2012 at 12:35:41PM +, Arnd Bergmann wrote:
The examples I had seen before were all just ranges of two interrupts
On Friday 07 September 2012, Lee Jones wrote:
Just running this by you, as there is method in the madness.
Linus wanted to keep changes to the Device Tree and changes
in platform code separate, which is my reason for submitting
all of my changes to date that way.
What I do (not sure if
1101 - 1200 of 32729 matches
Mail list logo
