* [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Daniel Phillips @ 2006-04-05 22:02 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060325010524.GA8117@ccure.user-mode-linux.org>
Jeff Dike wrote:
> This is the big question with this patch. How incestuous do I want to
> get with the VM system in order to get it to free up pages? For now,
> I decided to be fairly hands-off, allocate as many pages as I can get,
> and return the total number to the host. The host, if it wasn't happy
> with the results, can wait a bit while the UML notices that it is
> really low on memory and frees some up, and then hit up the UML for
> the remainder.
And also wrote:
> page = alloc_page(GFP_ATOMIC);
A slightly different objection than Andrew's: this will rapidly eat up
all the pages available for, e.g., receiving network packets, probably
not what you want. How about flags=0? This will dip a little way into
reserves but not as far as interrupts or realtime tasks, and will not
attempt any reclaim. (Maybe we should have a GFP define for that.)
> INIT_LIST_HEAD(&unplugged->list);
> list_add(&unplugged->list, &unplugged_pages);
You don't need to initialize the list element you are adding.
Regards,
Daniel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)
From: Philippe Gerum @ 2006-04-05 22:02 UTC (permalink / raw)
To: Randy Smith; +Cc: xenomai
In-Reply-To: <44342E91.4080007@domain.hid>
Randy Smith wrote:
>
>
> Philippe Gerum wrote:
>
>> Wrt 2.4 kernels, the project provides patches against snapshots of
>> Denx's development tree, accessible from
>> http://www.denx.de/en/Software/CVS. The date of the snapshot was
>> missing in the patch filenames, which introduced a fair amount of
>> confusion; this has been fixed in the repository. All 2.4-based Adeos
>> patches for ppc have been built against Denx's devel tree as of
>> 2005-11-09 so far. The Adeos version is always given by the trailing
>> rev. number of any patch filename, e.g. 1.0-04 is the latest Adeos
>> rev. for 2.4/ppc kernels.
>>
>> For 2.6/ppc kernels, we provide patches against vanilla kernel trees
>> as released by kernel.org.
>
> Thanks, That clears that up.
>
>>
>> Ok, it's a bit early for Xmas gifts, but anyway, try this patch on
>> 2.4.25-11 as shipped with the ELDK 3.1:
>>
>> http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch
>>
>>
> I have downloaded the patch and will try it over the next few days and
> report back. Thanks again and Feliz Navidad or perhaps I should say
> Joyeux Noël?
>
Joyeux Noël would be perfect. Merry Christmas to you too.
[Redshift effect is ongoing on Xenomai-core]
--
Philippe.
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Roger Luethi @ 2006-04-05 22:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: zlynx, linux-kernel, linville
In-Reply-To: <20060405002909.2ab4482b.akpm@osdl.org>
On Wed, 05 Apr 2006 00:29:09 -0700, Andrew Morton wrote:
> Roger Luethi <rl@hellgate.ch> wrote:
> >
> > Any suggestions for an elegant solution?
>
> Move the locking down lower, so it just locks the stuff which needs locking?
>
> It all depends on what the lock's role is, and so often that's a big secret.
Indeed.
Over a dozen drivers now use calls like mii_ethtool_gset or
generic_mii_ioctl, and only one (sis190) makes the call without grabbing
the lock to the driver private data.
Pushing that lock down is not something I'd do lightly.
> If the intention is to prevent concurrent execution of mdio_read()
> (reasonable) and we really need that 1 msec delay between writing the
I'm afraid that delay is not negotiable -- unless we want to go back to
polling the chip for link state changes.
Roger
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Bjorn Helgaas @ 2006-04-05 22:01 UTC (permalink / raw)
To: Luck, Tony; +Cc: Zou Nan hai, Andrew Morton, LKML, linux-ia64
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh. Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map. I think that was
> > clearly a bug. So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
>
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
>
> The problem looks to come from this code in vgacon.c:
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> vga_vram_size = vga_vram_end - vga_vram_base;
>
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000. But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable. So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
>
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size? But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.
I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
that we need to map the memory starting at vga_vram_end. I think
it would cleaner (though much more intrusive) to do something like
the patch below, which basically just hard-codes (base, size)
rather than (base, end).
> If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
Regardless of how we solve the vga_vram_size issue, I still think
ioremap_nocache() is more appropriate in this case. A framebuffer
won't work like we expect if it's mapped WB, will it?
(The patch below assumes the ioremap_nocache change precedes it.)
[PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
VGA_MAP_MEM translates to ioremap() on some architectures. It
makes sense to do this to vga_vram_base, because we're going to
access memory between vga_vram_base and vga_vram_end.
But it doesn't really make sense to map starting at vga_vram_end,
because we aren't going to access memory starting there. On ia64,
which always has to be different, ioremapping vga_vram_end gives
you something completely incompatible with ioremapped vga_vram_start,
so vga_vram_size ends up being nonsense.
As a bonus, we often know the size up front, so we can use ioremap()
correctly, rather than giving it a zero size.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm5/drivers/video/console/vgacon.c
===================================================================
--- work-mm5.orig/drivers/video/console/vgacon.c 2006-04-03 15:04:48.000000000 -0600
+++ work-mm5/drivers/video/console/vgacon.c 2006-04-05 15:48:37.000000000 -0600
@@ -391,7 +391,7 @@
static struct resource ega_console_resource =
{ .name = "ega", .start = 0x3B0, .end = 0x3BF };
vga_video_type = VIDEO_TYPE_EGAM;
- vga_vram_end = 0xb8000;
+ vga_vram_size = 0x8000;
display_desc = "EGA+";
request_resource(&ioport_resource,
&ega_console_resource);
@@ -401,7 +401,7 @@
static struct resource mda2_console_resource =
{ .name = "mda", .start = 0x3BF, .end = 0x3BF };
vga_video_type = VIDEO_TYPE_MDA;
- vga_vram_end = 0xb2000;
+ vga_vram_size = 0x2000;
display_desc = "*MDA";
request_resource(&ioport_resource,
&mda1_console_resource);
@@ -418,7 +418,7 @@
if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
int i;
- vga_vram_end = 0xc0000;
+ vga_vram_size = 0x8000;
if (!ORIG_VIDEO_ISVGA) {
static struct resource ega_console_resource
@@ -443,7 +443,7 @@
* and COE=1 isn't necessarily a good idea)
*/
vga_vram_base = 0xa0000;
- vga_vram_end = 0xb0000;
+ vga_vram_size = 0x10000;
outb_p(6, VGA_GFX_I);
outb_p(6, VGA_GFX_D);
#endif
@@ -475,7 +475,7 @@
static struct resource cga_console_resource =
{ .name = "cga", .start = 0x3D4, .end = 0x3D5 };
vga_video_type = VIDEO_TYPE_CGA;
- vga_vram_end = 0xba000;
+ vga_vram_size = 0x2000;
display_desc = "*CGA";
request_resource(&ioport_resource,
&cga_console_resource);
@@ -483,9 +483,8 @@
}
}
- vga_vram_base = VGA_MAP_MEM(vga_vram_base);
- vga_vram_end = VGA_MAP_MEM(vga_vram_end);
- vga_vram_size = vga_vram_end - vga_vram_base;
+ vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+ vga_vram_end = vga_vram_base + vga_vram_size;
/*
* Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@
char *charmap;
if (vga_video_type != VIDEO_TYPE_EGAM) {
- charmap = (char *) VGA_MAP_MEM(colourmap);
+ charmap = (char *) VGA_MAP_MEM(colourmap, 0);
beg = 0x0e;
#ifdef VGA_CAN_DO_64KB
if (vga_video_type == VIDEO_TYPE_VGAC)
beg = 0x06;
#endif
} else {
- charmap = (char *) VGA_MAP_MEM(blackwmap);
+ charmap = (char *) VGA_MAP_MEM(blackwmap, 0);
beg = 0x0a;
}
Index: work-mm5/include/asm-alpha/vga.h
===================================================================
--- work-mm5.orig/include/asm-alpha/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h 2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,6 @@
#define vga_readb(a) readb((u8 __iomem *)(a))
#define vga_writeb(v,a) writeb(v, (u8 __iomem *)(a))
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap(x, s))
#endif
Index: work-mm5/include/asm-arm/vga.h
===================================================================
--- work-mm5.orig/include/asm-arm/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h 2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,7 @@
#include <asm/hardware.h>
#include <asm/io.h>
-#define VGA_MAP_MEM(x) (PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s) (PCIMEM_BASE + (x))
#define vga_readb(x) (*((volatile unsigned char *)x))
#define vga_writeb(x,y) (*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
===================================================================
--- work-mm5.orig/include/asm-i386/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h 2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
===================================================================
--- work-mm5.orig/include/asm-ia64/vga.h 2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h 2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,7 @@
extern unsigned long vga_console_iobase;
extern unsigned long vga_console_membase;
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
===================================================================
--- work-mm5.orig/include/asm-m32r/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h 2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
===================================================================
--- work-mm5.orig/include/asm-mips/vga.h 2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h 2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s) (0xb0000000L + (unsigned long)(x))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
===================================================================
--- work-mm5.orig/include/asm-powerpc/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h 2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,9 @@
extern unsigned long vgacon_remap_base;
#ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
#else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
#endif
#define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
===================================================================
--- work-mm5.orig/include/asm-sparc64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h 2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,6 @@
return *addr;
}
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
#endif
Index: work-mm5/include/asm-x86_64/vga.h
===================================================================
--- work-mm5.orig/include/asm-x86_64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h 2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
===================================================================
--- work-mm5.orig/include/asm-xtensa/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h 2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,7 @@
#ifndef _XTENSA_VGA_H
#define _XTENSA_VGA_H
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
===================================================================
--- work-mm5.orig/drivers/video/console/mdacon.c 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c 2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
mda_num_columns = 80;
mda_num_lines = 25;
- mda_vram_base = VGA_MAP_MEM(0xb0000);
mda_vram_len = 0x01000;
+ mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
mda_index_port = 0x3b4;
mda_value_port = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
===================================================================
--- work-mm5.orig/drivers/video/vga16fb.c 2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c 2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
}
/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
- info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+ info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
if (!info->screen_base) {
printk(KERN_ERR "vga16fb: unable to map device\n");
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Bjorn Helgaas @ 2006-04-05 22:01 UTC (permalink / raw)
To: Luck, Tony; +Cc: Zou Nan hai, Andrew Morton, LKML, linux-ia64
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
On Wednesday 05 April 2006 15:17, Luck, Tony wrote:
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh. Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map. I think that was
> > clearly a bug. So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
>
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
>
> The problem looks to come from this code in vgacon.c:
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> vga_vram_size = vga_vram_end - vga_vram_base;
>
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000. But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable. So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
>
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size? But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c.
I think the VGA_MAP_MEM(vga_vram_end) is just bogus -- it's not
that we need to map the memory starting at vga_vram_end. I think
it would cleaner (though much more intrusive) to do something like
the patch below, which basically just hard-codes (base, size)
rather than (base, end).
> If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
Regardless of how we solve the vga_vram_size issue, I still think
ioremap_nocache() is more appropriate in this case. A framebuffer
won't work like we expect if it's mapped WB, will it?
(The patch below assumes the ioremap_nocache change precedes it.)
[PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use
VGA_MAP_MEM translates to ioremap() on some architectures. It
makes sense to do this to vga_vram_base, because we're going to
access memory between vga_vram_base and vga_vram_end.
But it doesn't really make sense to map starting at vga_vram_end,
because we aren't going to access memory starting there. On ia64,
which always has to be different, ioremapping vga_vram_end gives
you something completely incompatible with ioremapped vga_vram_start,
so vga_vram_size ends up being nonsense.
As a bonus, we often know the size up front, so we can use ioremap()
correctly, rather than giving it a zero size.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm5/drivers/video/console/vgacon.c
=================================--- work-mm5.orig/drivers/video/console/vgacon.c 2006-04-03 15:04:48.000000000 -0600
+++ work-mm5/drivers/video/console/vgacon.c 2006-04-05 15:48:37.000000000 -0600
@@ -391,7 +391,7 @@
static struct resource ega_console_resource { .name = "ega", .start = 0x3B0, .end = 0x3BF };
vga_video_type = VIDEO_TYPE_EGAM;
- vga_vram_end = 0xb8000;
+ vga_vram_size = 0x8000;
display_desc = "EGA+";
request_resource(&ioport_resource,
&ega_console_resource);
@@ -401,7 +401,7 @@
static struct resource mda2_console_resource { .name = "mda", .start = 0x3BF, .end = 0x3BF };
vga_video_type = VIDEO_TYPE_MDA;
- vga_vram_end = 0xb2000;
+ vga_vram_size = 0x2000;
display_desc = "*MDA";
request_resource(&ioport_resource,
&mda1_console_resource);
@@ -418,7 +418,7 @@
if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10) {
int i;
- vga_vram_end = 0xc0000;
+ vga_vram_size = 0x8000;
if (!ORIG_VIDEO_ISVGA) {
static struct resource ega_console_resource
@@ -443,7 +443,7 @@
* and COE=1 isn't necessarily a good idea)
*/
vga_vram_base = 0xa0000;
- vga_vram_end = 0xb0000;
+ vga_vram_size = 0x10000;
outb_p(6, VGA_GFX_I);
outb_p(6, VGA_GFX_D);
#endif
@@ -475,7 +475,7 @@
static struct resource cga_console_resource { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
vga_video_type = VIDEO_TYPE_CGA;
- vga_vram_end = 0xba000;
+ vga_vram_size = 0x2000;
display_desc = "*CGA";
request_resource(&ioport_resource,
&cga_console_resource);
@@ -483,9 +483,8 @@
}
}
- vga_vram_base = VGA_MAP_MEM(vga_vram_base);
- vga_vram_end = VGA_MAP_MEM(vga_vram_end);
- vga_vram_size = vga_vram_end - vga_vram_base;
+ vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
+ vga_vram_end = vga_vram_base + vga_vram_size;
/*
* Find out if there is a graphics card present.
@@ -1020,14 +1019,14 @@
char *charmap;
if (vga_video_type != VIDEO_TYPE_EGAM) {
- charmap = (char *) VGA_MAP_MEM(colourmap);
+ charmap = (char *) VGA_MAP_MEM(colourmap, 0);
beg = 0x0e;
#ifdef VGA_CAN_DO_64KB
if (vga_video_type = VIDEO_TYPE_VGAC)
beg = 0x06;
#endif
} else {
- charmap = (char *) VGA_MAP_MEM(blackwmap);
+ charmap = (char *) VGA_MAP_MEM(blackwmap, 0);
beg = 0x0a;
}
Index: work-mm5/include/asm-alpha/vga.h
=================================--- work-mm5.orig/include/asm-alpha/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-alpha/vga.h 2006-04-05 15:42:35.000000000 -0600
@@ -46,6 +46,6 @@
#define vga_readb(a) readb((u8 __iomem *)(a))
#define vga_writeb(v,a) writeb(v, (u8 __iomem *)(a))
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap(x, 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap(x, s))
#endif
Index: work-mm5/include/asm-arm/vga.h
=================================--- work-mm5.orig/include/asm-arm/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-arm/vga.h 2006-04-05 15:42:21.000000000 -0600
@@ -4,7 +4,7 @@
#include <asm/hardware.h>
#include <asm/io.h>
-#define VGA_MAP_MEM(x) (PCIMEM_BASE + (x))
+#define VGA_MAP_MEM(x,s) (PCIMEM_BASE + (x))
#define vga_readb(x) (*((volatile unsigned char *)x))
#define vga_writeb(x,y) (*((volatile unsigned char *)y) = (x))
Index: work-mm5/include/asm-i386/vga.h
=================================--- work-mm5.orig/include/asm-i386/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-i386/vga.h 2006-04-05 15:42:49.000000000 -0600
@@ -12,7 +12,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-ia64/vga.h
=================================--- work-mm5.orig/include/asm-ia64/vga.h 2006-04-05 09:57:55.000000000 -0600
+++ work-mm5/include/asm-ia64/vga.h 2006-04-05 15:43:09.000000000 -0600
@@ -17,7 +17,7 @@
extern unsigned long vga_console_iobase;
extern unsigned long vga_console_membase;
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap_nocache(vga_console_membase + (x), s))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-m32r/vga.h
=================================--- work-mm5.orig/include/asm-m32r/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-m32r/vga.h 2006-04-05 15:43:22.000000000 -0600
@@ -14,7 +14,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-mips/vga.h
=================================--- work-mm5.orig/include/asm-mips/vga.h 2006-03-23 10:22:17.000000000 -0700
+++ work-mm5/include/asm-mips/vga.h 2006-04-05 15:43:32.000000000 -0600
@@ -13,7 +13,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (0xb0000000L + (unsigned long)(x))
+#define VGA_MAP_MEM(x,s) (0xb0000000L + (unsigned long)(x))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-powerpc/vga.h
=================================--- work-mm5.orig/include/asm-powerpc/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-powerpc/vga.h 2006-04-05 15:43:57.000000000 -0600
@@ -42,9 +42,9 @@
extern unsigned long vgacon_remap_base;
#ifdef __powerpc64__
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
#else
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
#endif
#define vga_readb(x) (*(x))
Index: work-mm5/include/asm-sparc64/vga.h
=================================--- work-mm5.orig/include/asm-sparc64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-sparc64/vga.h 2006-04-05 15:44:08.000000000 -0600
@@ -28,6 +28,6 @@
return *addr;
}
-#define VGA_MAP_MEM(x) (x)
+#define VGA_MAP_MEM(x,s) (x)
#endif
Index: work-mm5/include/asm-x86_64/vga.h
=================================--- work-mm5.orig/include/asm-x86_64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-x86_64/vga.h 2006-04-05 15:44:18.000000000 -0600
@@ -12,7 +12,7 @@
* access the videoram directly without any black magic.
*/
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/include/asm-xtensa/vga.h
=================================--- work-mm5.orig/include/asm-xtensa/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-xtensa/vga.h 2006-04-05 15:44:31.000000000 -0600
@@ -11,7 +11,7 @@
#ifndef _XTENSA_VGA_H
#define _XTENSA_VGA_H
-#define VGA_MAP_MEM(x) (unsigned long)phys_to_virt(x)
+#define VGA_MAP_MEM(x,s) (unsigned long)phys_to_virt(x)
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
Index: work-mm5/drivers/video/console/mdacon.c
=================================--- work-mm5.orig/drivers/video/console/mdacon.c 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/drivers/video/console/mdacon.c 2006-04-05 15:46:33.000000000 -0600
@@ -313,8 +313,8 @@
mda_num_columns = 80;
mda_num_lines = 25;
- mda_vram_base = VGA_MAP_MEM(0xb0000);
mda_vram_len = 0x01000;
+ mda_vram_base = VGA_MAP_MEM(0xb0000, mda_vram_len);
mda_index_port = 0x3b4;
mda_value_port = 0x3b5;
Index: work-mm5/drivers/video/vga16fb.c
=================================--- work-mm5.orig/drivers/video/vga16fb.c 2006-03-23 10:22:16.000000000 -0700
+++ work-mm5/drivers/video/vga16fb.c 2006-04-05 15:49:34.000000000 -0600
@@ -1351,7 +1351,7 @@
}
/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
- info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS);
+ info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
if (!info->screen_base) {
printk(KERN_ERR "vga16fb: unable to map device\n");
^ permalink raw reply
* Re: fix kbuild warning in iptable_nat.o
From: Patrick McHardy @ 2006-04-05 22:00 UTC (permalink / raw)
To: Darren Jenkins; +Cc: kernel Janitors, Randy.Dunlap, netfilter-devel
In-Reply-To: <1143719875.8469.14.camel@localhost.localdomain>
Darren Jenkins\ wrote:
> G'day list
>
> There are a couple of Kbuild warnings in net/ipv4/netfilter/ that would
> be nice to get rid of.
>
> WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch: reference
> to .init.text:ip_conntrack_init from .text between 'init_or_cleanup' (at
> offset 0x7ea) and '__hash_conntrack'
> WARNING: net/ipv4/netfilter/iptable_nat.o - Section mismatch: reference
> to .init.text:ip_nat_rule_init from .text between 'init_or_cleanup' (at
> offset 0x455) and 'nat_decode_session'
>
> I have a patch for the 'iptable_nat.o' warning below, and I was just
> wanting to check in and see if any of you netfilter guys had a problem
> with this patch, or with me doing a similar patch for the
> 'ip_canntrack.o' warning.
>
>
> Any input would be welcome, thanks in advance :).
I have a patch queued that just splits the init/cleanup parts.
^ permalink raw reply
* [KJ] Re: fix kbuild warning in iptable_nat.o
From: Patrick McHardy @ 2006-04-05 22:00 UTC (permalink / raw)
To: Darren Jenkins; +Cc: kernel Janitors, Randy.Dunlap, netfilter-devel
In-Reply-To: <1143719875.8469.14.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
Darren Jenkins\ wrote:
> G'day list
>
> There are a couple of Kbuild warnings in net/ipv4/netfilter/ that would
> be nice to get rid of.
>
> WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch: reference
> to .init.text:ip_conntrack_init from .text between 'init_or_cleanup' (at
> offset 0x7ea) and '__hash_conntrack'
> WARNING: net/ipv4/netfilter/iptable_nat.o - Section mismatch: reference
> to .init.text:ip_nat_rule_init from .text between 'init_or_cleanup' (at
> offset 0x455) and 'nat_decode_session'
>
> I have a patch for the 'iptable_nat.o' warning below, and I was just
> wanting to check in and see if any of you netfilter guys had a problem
> with this patch, or with me doing a similar patch for the
> 'ip_canntrack.o' warning.
>
>
> Any input would be welcome, thanks in advance :).
I have a patch queued that just splits the init/cleanup parts.
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* [Xenomai-core] Re: Manual interrupt handling by cli/sti instructions
From: Philippe Gerum @ 2006-04-05 21:58 UTC (permalink / raw)
To: Rodrigo Rosenfeld Rosas; +Cc: xenomai-core
In-Reply-To: <200604041623.47796.lbocseg@domain.hid>
Rodrigo Rosenfeld Rosas wrote:
> Hi Philippe,
>
> Actually I think it is an Adeos issue, but it is also relevant for Xenomai.
>
> Does Adeos have any protection (I do not know if it is even possible to)
> against a Linux module issuing a cli/sti code directly through arch specific
> code instead of through some Linux API. Putting it in other way, is it
> possible that a third-party module breaks out the determinism in the Xenomai
> domain?
Yes, we cannot do much about misbehaving binary-only module or code
which does not use the kernel API to control the interrupt mask at CPU
level.
A way to deal with this on x86 would be to move the kernel code to a
different protection ring than #0, so that using protected insns like
cli/sti would beget an exception (provided no one fiddles with the iopl
though), and route the hw masking/unmasking requests to the virtualized
Adeos pipeline stall/unstall ops instead. Obviously, an awful lot of
other issues would be raised by such move, such as dealing with other
protected insns/accesses, and beyond that, all the mess people doing
full O/S virtualization have to deal with on a daily basis.
Another way would be to play the "afterburing" game I guess, searching
for cli/sti opcodes in the kernel/driver image and poking replacement
code to do the same virtualization stuff, but the original opcodes are
only 1-byte long, so some additional trickery would likely be needed,
along with other issues the afterburning technique raises (e.g. you
don't want to replace _all_ hw interrupt masking/unmasking in the image
blindly).
>
> Thanks in advance,
>
> Rodrigo.
>
>
> _______________________________________________________
> Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça.
> http://br.messenger.yahoo.com/
>
--
Philippe.
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ
From: Jan Kiszka @ 2006-04-05 21:58 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <44343CF6.4090500@domain.hid>
[-- Attachment #1.1: Type: text/plain, Size: 2410 bytes --]
Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Philippe Gerum wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>
>>>>> Jan Kiszka wrote:
>>>>> > Hi,
>>>>> > > my colleagues and I need some hint where to continue our search
>>>>> for the
>>>>> > cause of a weird cleanup issue:
>>>>> > > An application of our robotics framework sometimes terminates
>>>>> (though
>>>>> > successfully) in a way that the system timer IRQ no longer arrives
>>>>> > afterwards or no re-program takes place anymore. All other Linux IRQs
>>>>> > are fine (Ethernet, keyboard, etc.). I cannot provide an easy test
>>>>> case
>>>>> > yet as besides the framework some expensive gyroscope and the 16550A
>>>>> > driver are involved.
>>>>>
>>>>> I observed a similar issue when xnpod_stop_timer was called when
>>>>> shutting down the posix skin. I assumed that the problem was that
>>>>> xnpod_shutdown already called xnpod_stop_timer, so xnpod_stop_timer (and
>>>>> in particular xnarch_stop_timer) ended up being called twice.
>>>>>
>>>> Err, sorry. Forget about my previous reply: xnarch_stop_timer is _not_
>>>> protected by the XNTIMED flag, but only the last part of the
>>>> housekeeping chores performed upon stopping the systimer are. IOW,
>>>> this is a latent bug, and xnpod_stop_timer should be fixed.
>>>>
>>> Commit 884 should do that.
>>>
>> Sorry for replying late: nope, this has no influence on our issue.
>>
>> Well, someone put that damn piece of hardware on my desk, saying: "It
>> doesn't work." What he did not say is that there are multiple issues
>> contained :-/. I found and fixed (patch will follow) a severe bug in the
>> 16550A driver, but the strange timer issue stays (though it's still
>> tricky to reproduce).
>>
>> The point is - and that's likely why your patch doesn't help - that we
>> do not stop the system timer, i.e. unload all skins. We just terminate
>> an application. I did some research but failed to find a test case (only
>> our software "manages" to trigger this). Actually, it seems the hardware
>> timer is no longer working, because also other RT-tasks no longer time
>> out. Moreover, I checked nkpod->htimer.status, but it remains 0 all the
>> time. I need more time...
>>
>
> Attached is an ipipe-freeze of the frozen system. It's taken at the time
F***, the usual "see [not-attached] attachment".
[-- Attachment #1.2: frozen-timer2.bz2 --]
[-- Type: application/octet-stream, Size: 18756 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ
From: Jan Kiszka @ 2006-04-05 21:56 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <44341AE6.5030804@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Philippe Gerum wrote:
>>> Gilles Chanteperdrix wrote:
>>>
>>>> Jan Kiszka wrote:
>>>> > Hi,
>>>> > > my colleagues and I need some hint where to continue our search
>>>> for the
>>>> > cause of a weird cleanup issue:
>>>> > > An application of our robotics framework sometimes terminates
>>>> (though
>>>> > successfully) in a way that the system timer IRQ no longer arrives
>>>> > afterwards or no re-program takes place anymore. All other Linux IRQs
>>>> > are fine (Ethernet, keyboard, etc.). I cannot provide an easy test
>>>> case
>>>> > yet as besides the framework some expensive gyroscope and the 16550A
>>>> > driver are involved.
>>>>
>>>> I observed a similar issue when xnpod_stop_timer was called when
>>>> shutting down the posix skin. I assumed that the problem was that
>>>> xnpod_shutdown already called xnpod_stop_timer, so xnpod_stop_timer (and
>>>> in particular xnarch_stop_timer) ended up being called twice.
>>>>
>>> Err, sorry. Forget about my previous reply: xnarch_stop_timer is _not_
>>> protected by the XNTIMED flag, but only the last part of the
>>> housekeeping chores performed upon stopping the systimer are. IOW,
>>> this is a latent bug, and xnpod_stop_timer should be fixed.
>>>
>> Commit 884 should do that.
>>
>
> Sorry for replying late: nope, this has no influence on our issue.
>
> Well, someone put that damn piece of hardware on my desk, saying: "It
> doesn't work." What he did not say is that there are multiple issues
> contained :-/. I found and fixed (patch will follow) a severe bug in the
> 16550A driver, but the strange timer issue stays (though it's still
> tricky to reproduce).
>
> The point is - and that's likely why your patch doesn't help - that we
> do not stop the system timer, i.e. unload all skins. We just terminate
> an application. I did some research but failed to find a test case (only
> our software "manages" to trigger this). Actually, it seems the hardware
> timer is no longer working, because also other RT-tasks no longer time
> out. Moreover, I checked nkpod->htimer.status, but it remains 0 all the
> time. I need more time...
>
Attached is an ipipe-freeze of the frozen system. It's taken at the time
the main thread of the terminating application has successfully
rt_task_join'ed the last remaining RT-thread. I took 2000 trace points
before and after that point and additionally instrumented
rthal_timer_program_shot() (special trace 0x01, the argument is the
delay). The interesting stuff happens around 600 us after the freeze: it
seems the scheduled Linux timer arrives then but doesn't get much
attention beyond from ipipe.
Any idea what to look for next? I have a "perfect" test system now,
though I still see no light at the end of the tunnel how to export it to
other boxes.
Enough for today.
Jan
PS: This trace was taken over 2.6.15 to exclude any issues with the new
2.6.16. Both kernels show the same effect.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: clone return code
From: Daniel 'NebuchadnezzaR' Dehennin @ 2006-04-05 21:55 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <87psjvu4wa.fsf@thorr.asgardr.info>
Le 4599 Septembre 1993, David S. Miller a tapoté:
> The system call convention follows that of SunOS on which
> the syscall handling was based. Return "1" in the %o1
> register in the child and "0" in the parent, and that's how
> the the call sites distinguish the two cases.
It's what I understand from arch/sparc64/kernel/process.c
> Why is this an issue?
It's not an issue anymore ;-) this behavior is handle now.
Thanks a lot.
--
Daniel 'NebuchadnezzaR' Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x2A408F69
^ permalink raw reply
* Re: [PATCH] modules_install must not remove existing modules
From: Valdis.Kletnieks @ 2006-04-05 21:52 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: Sam Ravnborg, linux-kernel
In-Reply-To: <200604052333.51085.agruen@suse.de>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Wed, 05 Apr 2006 23:33:50 +0200, Andreas Gruenbacher said:
> When installing external modules with `make modules_install', the
> first thing that happens is a rm -rf of the target directory. This
> works only once, and breaks when installing more than one (set of)
> external module(s).
Can this be re-worked to ensure that it clears the target directory
the *first* time? It would suck mightily if a previous build of 2.6.17-rc2
left a net_foo.ko lying around to get insmod'ed by accident (consider the case
of CONFIG_NETFOO=m getting changed to y or n, and other possible horkage.
Module versioning will catch some, but not all, of this crap....)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: Q on audit, audit-syscall
From: Herbert Rosmanith @ 2006-04-05 21:47 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Kyle Moffett, Robin Holt, linux-kernel
In-Reply-To: <200604052036.k35KaQXk021296@turing-police.cc.vt.edu>
> 'man auditd' and friends. This is providing after-the-fact reporting
> of security-related events for audit and forensic analysis. We have *no*
sure, I've already found audit, unfortunately, it wont compile on my system :-(
else I'd already be busy analysing how it works. this is yet another time
that using auto-tools results in more work than without. I get a failure
in an automatically generated, 7000+ lines monster shell-script named "libtool".
I wonder why "libtool" is generated by audit:
# libtool - Provide generalized library-building support services.
# Generated automatically by (GNU audit 1.1.5)
(I thought "libtool" is part of the system - why does audit generate one
itself?)
anyway, the manpage describes how auditd/libaudit works - not how it has been
implemented/how it communicates with the kernel.
I want to know how it works "under the hood", not just how to use it.
but I think I slowly get the idea (more on this below).
> idea if it will fill your needs, because you have explained what you're
> trying to *do* with ptrace. If you merely need a record that a syscall
as I said, "ptrace" is not an option, so I'm not trying to do anything with it.
> happened, this is what you want. If you want to apply a security restriction,
> you want to look at SELinux or perhaps a custom LSM. If you have some
^^^^^^^^^^^^
the idea already crossed my mind. but I rather start bottom up: LSM depends
on CONFIG_AUDIT* (this is correct, isn't it?), so I examine AUDIT first. if
AUDIT doesnt support what I need, I continue with LSM.
> other need, you need some other tool.
> So what problem are you trying to solve by using ptrace()?
I'm *not* using ptrace :-)
Kyle suggested I use it, but I dont want to.
> > (2) in linux/Documentation/devices.txt I've found an "audit device":
> > 103 block Audit device
> > 0 = /dev/audit Audit device
>
> "That is an old worn-out magic word" -- ADVENT.FOR
> I think that's a leftover from before the audit subsystem was converted
> to use netlink.
ok.
good, some clear words!
so this obsolete entry should be removed or clearly flagged as "obsolete".
see what I mean: linux/Documentation is not the place to go when you look for
accurate docs! it has some potential to lead to confusion. this was not the
first time that docs in linux/Documentation proofed outdated - but I realised
only after I "crashed into the wall".
> > (3) audit-1.1.5/lib is using "socket(PF_NETLINK,SOCK_RAW,NETLINK_AUDIT)"
> > is this the way to communicate with the audit-system enabled by
> > CONFIG_AUDIT/_AUDITSYSCALL? or is this something different.
>
> Well, this is how auditd talks to the netlink socket.
ok.
is this correct: I can communicate with the whole audit system via the netlink-socket
and there is no other means (e.g. a syscall, a /proc interface, a block-device with
major 103 ;-))) for it. good! this was the info I was looking for.
> Whether it supports the functionality you need in a unpatched kernel depends on
> what you're trying to do
Thanks, I'll find out myself. The next step is playing with the audit-messages
from <linux/audit.h> to see if
> (which you still haven't explained).
how goes the joke ... "I can explain it to you, but then I'd have to shoot you":-)
sorry :-))
no, really: it's (1) too easy (2) unpublished (3) the background is not related to
the linux kernel at all (4) I dont want you to solve my "homework".
but I understand ... someone asks "how does X work", then you usually ask "tell us
why do you want to use X" in order to see if "X" is the correct method at all. but
in this case, I have to find out myself if method "X" fits my needs. sorry.
> > > otherwise it's impossible to help you. You want to trace and
> > > intercept syscalls, no?
> >
> > > It implicitly doesn't make any sense to try to trace and intercept syscalls
> > > from one process in more than one other.
> >
> > I'm pretty sure I can find a quote from the fortune program saying
> > that "if something does not make sense for you, that doesnt mean that it wont
> > make sense for someone else". In fact, it makes sense for me.
>
> Good. Please enlighten us what the proper system behavior is, if *two* processes
> are ptrace()ing the same target process - and one specifies PTRACE_CONT and
good point! this again proves that ptrace is not an option - as I noted
in my first mail.
[...]
> LAuS was a long-ago predecessor of the current audit system. At the time
> it was written, it was correct, but it no longer is.
aha. good to know. thanks.
regards,
h.rosmanith
^ permalink raw reply
* Re: [PATCH] Add a /proc/self/exedir link
From: Mike Hearn @ 2006-04-05 21:52 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel, akpm
In-Reply-To: <m1fykr3ggb.fsf@ebiederm.dsl.xmission.com>
> I think if we can fix namespaces you don't have to be root to use
> them that is a superioir approach, and will cover more cases.
That would be nice. I assumed they needed root for security reasons
rather than architectural reasons.
> I have concerns about security policy ...
I'm not sure I understand. Only if you run that program, and if you
don't have access to the intermediate directory, how do you run it?
> This means I can not run any of your relocatable executalbes in
> a chroot environment unless I mount proc.
Why is mounting proc a bad thing? I have never seen a Linux distro that
does not provide proc and many desktop-level things depend on it.
> Given how long we have been without this I doubt many people actually
> care
You could argue the same for any new feature. Writing relocatable
software on UNIX is absolutely standard, except it's done at source
compile time not runtime. That fits with the traditional UNIX culture of
compiling software to install it, but the times they are a changin :)
> I'm not certain the directory of an inode even makes sense, and
> that is what you are asking for us to export.
How so? The code does work, though I guess you could devise a scenario
in which there is a running executable that is not attached to any
directory.
thanks -mike
^ permalink raw reply
* Re: OOM kills if swappiness set to 0, swap storms otherwise
From: Bill Davidsen @ 2006-04-05 20:47 UTC (permalink / raw)
To: Charles Shannon Hendrix, Linux Kernel Mailing List
In-Reply-To: <20060405144716.GA10353@widomaker.com>
Charles Shannon Hendrix wrote:
> Mon, 27 Mar 2006 @ 19:59 -0800, Andrew Morton said:
>
>> Much porkiness.
>>
>> /proc/meminfo is very useful for obtaining a top-level view of where all
>> the memory's gone to. I'd tentatively say that your options are to put up
>> with the swapping or find a new mail client.
>
> I use mutt for my email, and I have the same issue on a 1GB system.
>
> I really wish we could put an upper limit on what file cache can use.
>
> I understand the original poster was running a lot of pork, but you
> don't have to and still see a problem with swapping. Even running KDE
> my total application memory most of the time is 300MB or less on a
> machine with 1GB of memory.
>
> I shouldn't be suffering from swap storms.
Agreed, does meminfo show that you are? The reason I ask is that I have
noted that large memory machines and CD/DVD image writing suffer from
some interesting disk write patterns. The image being built gets cached
but not written, then the file is closed. At some point the kernel
notices several GB of old unwritten data and decides to write it. This
makes everything pretty slow for a while, even if you have 100MB/s disk
system.
>
> For example, my normal working set of programs eats about 250MB of memory. If
> I also start a job running to something like tag some mp3s, copy a CD, or just
> process a lot of files, it only takes a few minutes before performance becomes
> unacceptable.
In theory you should be able to tune this, but in practice I see what
you do. On small memory machines it's less noticable, oddly.
>
> If you are doing some work where you switch among several applications
> frequently, the pigginess of file cache becomes a serious problem.
>
> Isn't that bad behavior by any measure?
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* [Xenomai-core] Problem compiling POSIX skin for mvm
From: Bruno Rouchouse @ 2006-04-05 21:39 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
Hi !
Just having a little problem compiling my posix skin for the simulator.
GFP_USER doesn't seem to be defined anywhere. Did I misconfigure something ?
Does it have something to do with the one defined in
/usr/include/linux/gfp.h ?
Thanks.
--
Bruno Rouchouse
=-=-=-=-=-=-=-=-=-=-=
bruno@domain.hid$ pwd
/home/bruno/sim-build/skins/posix
bruno@domain.hid$ make install
Making install in .
make[1]: Entering directory `/home/bruno/sim-build/skins/posix'
if ../../gcic/gcic -DHAVE_CONFIG_H -I. -I../../../xenomai/sim/skins/posix
-I../../include -D_GNU_SOURCE -D__IN_XENO__
--gcic-backend=/home/bruno/install//libexec/gcic --skin-code
-I../../../xenomai/sim/../ksrc/skins -I../../../xenomai/sim/../include
-I../../../xenomai/sim/skins/posix/.. -g -MT shm.o -MD -MP -MF
".deps/shm.Tpo" -c -o shm.o ../../../xenomai/sim/../ksrc/skins/posix/shm.c;
\
then mv -f ".deps/shm.Tpo" ".deps/shm.Po"; else rm -f ".deps/shm.Tpo"; exit
1; fi
../../../xenomai/sim/../ksrc/skins/posix/shm.c: In function
`pse51_ftruncate':
../../../xenomai/sim/../ksrc/skins/posix/shm.c:556: `GFP_USER' undeclared
(first use in this function)
../../../xenomai/sim/../ksrc/skins/posix/shm.c:556: (Each undeclared
identifier is reported only once
../../../xenomai/sim/../ksrc/skins/posix/shm.c:556: for each function it
appears in.)
make[1]: *** [shm.o] Error 1
make[1]: Leaving directory `/home/bruno/sim-build/skins/posix'
make: *** [install-recursive] Error 1
bruno@domain.hid$ xeno-info
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux psodiem 2.6.14 #1 PREEMPT Sat Mar 18 02:04:03 CET 2006 i686 GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
util-linux 2.12p
mount 2.12p
module-init-tools 3.1
e2fsprogs 1.35
jfsutils 1.1.6
xfsprogs 2.6.20
pcmcia-cs 3.2.5
PPP 2.4.2
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.4
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
Modules Loaded ipv6 speedstep_smi speedstep_lib cpufreq_userspace
cpufreq_powersave cpufreq_ondemand pcnet_cs 8390 pcmcia firmware_class video
thermal processor ibm_acpi fan container button battery ac af_packet usbhid
i2c_piix4 uhci_hcd usbcore snd_cs46xx gameport snd_rawmidi snd_seq_device
snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd
soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core pci_hotplug
intel_agp agpgart irtty_sir sir_dev irda crc_ccitt rtc pcspkr tsdev md_mod
dm_mod psmouse mousedev lp unix
bruno@domain.hid$
[-- Attachment #2: Type: text/html, Size: 4088 bytes --]
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Andreas Schwab @ 2006-04-05 21:39 UTC (permalink / raw)
To: Luck, Tony; +Cc: Bjorn Helgaas, Zou Nan hai, Andrew Morton, LKML, linux-ia64
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
> }
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> - vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> - vga_vram_size = vga_vram_end - vga_vram_base;
> + vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> + vga_vram_size = vga_vram_end - vga_vram_base + 1;
Better use vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1) + 1, or you'll
screw up the other computations using vga_vram_end.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Andreas Schwab @ 2006-04-05 21:39 UTC (permalink / raw)
To: Luck, Tony; +Cc: Bjorn Helgaas, Zou Nan hai, Andrew Morton, LKML, linux-ia64
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
> }
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> - vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> - vga_vram_size = vga_vram_end - vga_vram_base;
> + vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> + vga_vram_size = vga_vram_end - vga_vram_base + 1;
Better use vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1) + 1, or you'll
screw up the other computations using vga_vram_end.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Andrew Morton @ 2006-04-05 21:37 UTC (permalink / raw)
To: Luck, Tony
Cc: bjorn.helgaas, nanhai.zou, linux-kernel, linux-ia64,
Antonino A. Daplas
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> wrote:
>
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh. Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map. I think that was
> > clearly a bug. So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
>
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
>
> The problem looks to come from this code in vgacon.c:
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> vga_vram_size = vga_vram_end - vga_vram_base;
>
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000. But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.
OK, so it's really an off-by-one error.
> So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
>
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size? But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c. If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
>
> ---
>
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
> }
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> - vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> - vga_vram_size = vga_vram_end - vga_vram_base;
> + vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> + vga_vram_size = vga_vram_end - vga_vram_base + 1;
>
> /*
> * Find out if there is a graphics card present.
Looks like the correct fix to me.
Tony (D), can you think of any problems with that approach?
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Andrew Morton @ 2006-04-05 21:37 UTC (permalink / raw)
To: Luck, Tony
Cc: bjorn.helgaas, nanhai.zou, linux-kernel, linux-ia64,
Antonino A. Daplas
In-Reply-To: <20060405211757.GA8536@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> wrote:
>
> On Wed, Apr 05, 2006 at 10:15:34AM -0600, Bjorn Helgaas wrote:
> > Huh. Intel firmware used to just not mention the VGA framebuffer
> > (0xa0000-0xc0000) at all in the EFI memory map. I think that was
> > clearly a bug. So maybe they fixed that by marking it WB (and
> > hopefully UC as well).
>
> Nope ... not fixed (at least not in the f/w that I'm running). The
> VGA buffer is still simply not mentioned in the EFI memory map.
>
> The problem looks to come from this code in vgacon.c:
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> vga_vram_size = vga_vram_end - vga_vram_base;
>
> vga_vram_base is 0xb8000, and this call gets a UC return of
> c0000000000b8000. But vga_vram_end is 0xc0000 ... which is
> the address of the start of a block of memory that is both
> WB and UC capable.
OK, so it's really an off-by-one error.
> So ioremap() gives us e0000000000c0000
> (which means that vga_vram_size is 2000000000008000, surely
> the biggest, baddest video card in the history of the world!).
>
> Perhaps the right fix is to subtract 1 from vga_vram_end and pass
> that into VGA_MAP_MEM(), and then add the 1 byte back when computing
> the size? But I don't know whether that might do something bad on
> some other architecture that uses vgacon.c. If this is not
> acceptable, then we can fall back and use the Nanhai/Bjorn fix
> of using ioremap_nocache().
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
>
> ---
>
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index d5a04b6..4ca9877 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -484,8 +484,8 @@ #endif
> }
>
> vga_vram_base = VGA_MAP_MEM(vga_vram_base);
> - vga_vram_end = VGA_MAP_MEM(vga_vram_end);
> - vga_vram_size = vga_vram_end - vga_vram_base;
> + vga_vram_end = VGA_MAP_MEM(vga_vram_end - 1);
> + vga_vram_size = vga_vram_end - vga_vram_base + 1;
>
> /*
> * Find out if there is a graphics card present.
Looks like the correct fix to me.
Tony (D), can you think of any problems with that approach?
^ permalink raw reply
* Re: rsync resetting contexts in /var/www
From: Erich Schubert @ 2006-04-05 21:36 UTC (permalink / raw)
To: J. Simonetti, SELinux@tycho.nsa.gov
In-Reply-To: <1144259773.25790.102.camel@moss-spartans.epoch.ncsc.mil>
Hi,
> issue or not. In the absence of -X, rsync should just be creating the
> new files with the default behavior, i.e. they should just inherit from
> the parent directory.
rsync writes data to temp files first, then renames them to their final
name IIRC. So even if you replace files with files from a remote machine
they'll probably get the default contexts again, just by not replacing
the existing ones, but actually being "moved in place" of the old files.
That is a sane behaviour, since network connections might be unstable
and you'll have intact files all the time that way. You could maybe
patch rsync to restore the old files label onto the new file, but I'm
not sure if that is the right way to do it.
I'm not a selinux "behaviour" expert, so what I just wrote might be
incorrect.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Friends are those who reach out for //\
your hand but touch your heart. V_/_
Alles verändert sich, sobald man sich selber verändert.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: amixer issues
From: Adrian McMenamin @ 2006-04-05 21:36 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
In-Reply-To: <20060405083635.GB11178@turing.informatik.uni-halle.de>
On Wed, 2006-04-05 at 10:36 +0200, Clemens Ladisch wrote:
> Adrian McMenamin wrote:
> > On Tue, 2006-04-04 at 18:17 +0200, Clemens Ladisch wrote:
> > > Adrian McMenamin wrote:
> > > > / # amixer -c 0
> > > > Invalid card number.
> > > > Usage: amixer <options> command
> > >
> > > Does /dev/snd/controlC0 exist, and does it point to the control device
> > > listed in /proc/asound/devices?
> >
> > / # ls -l /dev/snd
> > crw-rw-rw- 1 root sys 116, 0 Apr 4 19:13 controlC0
> >
> > / # cat /proc/asound/devices
> > 0: [0- 0]: ctl
>
> Looks OK.
>
> What is the output of "strace amixer -c0 controls"?
I have no strace. This is uclibc on SH4 embedded
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH] modules_install must not remove existing modules
From: Andreas Gruenbacher @ 2006-04-05 21:33 UTC (permalink / raw)
To: Sam Ravnborg, linux-kernel
When installing external modules with `make modules_install', the
first thing that happens is a rm -rf of the target directory. This
works only once, and breaks when installing more than one (set of)
external module(s). Bug introduced in:
http://www.kernel.org/hg/linux-2.6/?cs=bbb3915836f5
Sam, is this fix okay with you?
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Index: linux-2.6.16/Makefile
===================================================================
--- linux-2.6.16.orig/Makefile
+++ linux-2.6.16/Makefile
@@ -1131,7 +1131,6 @@ modules_install: _emodinst_ _emodinst_po
install-dir := $(if $(INSTALL_MOD_DIR),$(INSTALL_MOD_DIR),extra)
.PHONY: _emodinst_
_emodinst_:
- $(Q)rm -rf $(MODLIB)/$(install-dir)
$(Q)mkdir -p $(MODLIB)/$(install-dir)
$(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modinst
--
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs
^ permalink raw reply
* Re: [PATCH] Keys: Improve usage of memory barriers and remove IRQ disablement
From: Nick Piggin @ 2006-04-05 9:23 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, akpm, keyrings, linux-kernel, David S. Miller
In-Reply-To: <29064.1144226770@warthog.cambridge.redhat.com>
David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> | int atomic_inc_and_test(atomic_t *v);
> | int atomic_dec_and_test(atomic_t *v);
> |
> | These two routines increment and decrement by 1, respectively, the
> | given atomic counter. They return a boolean indicating whether the
> | resulting counter value was zero or not.
> |
> | It requires explicit memory barrier semantics around the operation as
> | above.
>
> Note the last paragraph. "It requires" should be "They require", but the
> sense would seem to be obvious. However, it's not clear on a second reading
> as to whether this is an instruction to the _caller_ or an instruction to the
> arch _implementer_.
>
Yes, I remember Dave M clarified this sometime ago (on lkml I guess). It
is a little confusing, but I think the wording is for the implementer's
point of view. Dave will pull me up if I'm wrong...
> I suppose from reading the abstract at the top:
>
> | This document is intended to serve as a guide to Linux port maintainers on
> | how to implement atomic counter, bitops, and spinlock interfaces properly.
>
> that it is meant to be read by the implementor and not the user/caller, in which
> case, Nick is correct.
>
> It seems I need to adjust my memory barrier doc, and perhaps I should adjust
> atomic_ops.txt too to make it clearer.
>
I think that would be good. atomic_ops.txt is very useful for API users
as well, so if it can be made more general without becoming ambiguous,
I'm sure that would be appreciated.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* [-mm patch] drivers/media/video/ks0127.c: code cleanup
From: Martin Samuelsson @ 2006-04-05 21:28 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, mchehab, js, v4l-dvb-maintainer
Code cleanup and coding style compliance changes:
- Extraneous spaces within parentheses, brackets and braces removed.
- Unnecessary initializations removed.
- All lines shorter than 80 columns.
- Constant msgs size of 2 replaced with ARRAY_SIZE(msgs).
- Single statement braces banished.
- udelay() -> msleep().
- Unused ks0127_getcrop() removed.
- schedule_timeout() -> schedule_timeout_interruptible().
- current->state = TASK_INTERRUPTIBLE removed.
- module_init/module_exit corrected.
- Removed the Emacs stuff.
Signed-off-by: Martin Samuelsson <sam@home.se>
---
ks0127.c | 443 +++++++++++++++++++++++++++++++-----------------------------
1 files changed, 236 insertions(+), 207 deletions(-)
The gigantic list of register name definitions; should it be moved to ks0127.h?
--- linux-2.6.17-rc1-mm1-ab-avs6eyes/drivers/media/video/ks0127-old.c 2006-04-06 00:26:07.000000000 +0200
+++ linux-2.6.16-git15-avs6eyes/drivers/media/video/ks0127.c 2006-04-06 00:37:52.000000000 +0200
@@ -1,5 +1,5 @@
/*
- * Video Capture Driver ( Video for Linux 1/2 )
+ * Video Capture Driver (Video for Linux 1/2)
* for the Matrox Marvel G200,G400 and Rainbow Runner-G series
*
* This module is an interface to the KS0127 video decoder chip.
@@ -216,24 +216,25 @@ struct ks0127 {
};
-static int debug = 0; /* insmod parameter */
+static int debug; /* insmod parameter */
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug output");
MODULE_LICENSE("GPL");
-static u8 reg_defaults[ 64 ];
+static u8 reg_defaults[64];
static void init_reg_defaults(void)
{
- u8* table = reg_defaults;
+ u8 *table = reg_defaults;
table[KS_CMDA] = 0x2c; /* VSE=0, CCIR 601, autodetect standard */
table[KS_CMDB] = 0x12; /* VALIGN=0, AGC control and input */
table[KS_CMDC] = 0x00; /* Test options */
- table[KS_CMDD] = 0x01; /* clock & input select, write 1 to PORTA */
+ /* clock & input select, write 1 to PORTA */
+ table[KS_CMDD] = 0x01;
table[KS_HAVB] = 0x00; /* HAV Start Control */
table[KS_HAVE] = 0x00; /* HAV End Control */
table[KS_HS1B] = 0x10; /* HS1 Start Control */
@@ -253,15 +254,18 @@ static void init_reg_defaults(void)
table[KS_SAT] = 0x00; /* Color Saturation Control*/
table[KS_HUE] = 0x00; /* Hue Control */
table[KS_VERTIA] = 0x00; /* Vertical Processing Control A */
- table[KS_VERTIB] = 0x12; /* Vertical Processing Control B, luma 1 line delayed */
+ /* Vertical Processing Control B, luma 1 line delayed */
+ table[KS_VERTIB] = 0x12;
table[KS_VERTIC] = 0x0b; /* Vertical Processing Control C */
table[KS_HSCLL] = 0x00; /* Horizontal Scaling Ratio Low */
table[KS_HSCLH] = 0x00; /* Horizontal Scaling Ratio High */
table[KS_VSCLL] = 0x00; /* Vertical Scaling Ratio Low */
table[KS_VSCLH] = 0x00; /* Vertical Scaling Ratio High */
- table[KS_OFMTA] = 0x30; /* 16 bit YCbCr 4:2:2 output; I can't make the bt866 like 8 bit /Sam */
+ /* 16 bit YCbCr 4:2:2 output; I can't make the bt866 like 8 bit /Sam */
+ table[KS_OFMTA] = 0x30;
table[KS_OFMTB] = 0x00; /* Output Control B */
- table[KS_VBICTL] = 0x5d; /* VBI Decoder Control; 4bit fmt: avoid Y overflow */
+ /* VBI Decoder Control; 4bit fmt: avoid Y overflow */
+ table[KS_VBICTL] = 0x5d;
table[KS_CCDAT2] = 0x00; /* Read Only register */
table[KS_CCDAT1] = 0x00; /* Read Only register */
table[KS_VBIL30] = 0xa8; /* VBI data decoding options */
@@ -277,8 +281,8 @@ static void init_reg_defaults(void)
table[KS_VAVB] = 0x07; /* VAV Begin */
table[KS_VAVE] = 0x00; /* VAV End */
table[KS_CTRACK] = 0x00; /* Chroma Tracking Control */
- table[KS_POLCTL] = 0x41; //0x01; /* Timing Signal Polarity Control */
- table[KS_REFCOD] = 0x80; /*0xa4;*/ /* Reference Code Insertion Control */
+ table[KS_POLCTL] = 0x41; /* Timing Signal Polarity Control */
+ table[KS_REFCOD] = 0x80; /* Reference Code Insertion Control */
table[KS_INVALY] = 0x10; /* Invalid Y Code */
table[KS_INVALU] = 0x80; /* Invalid U Code */
table[KS_INVALV] = 0x80; /* Invalid V Code */
@@ -288,11 +292,14 @@ static void init_reg_defaults(void)
table[KS_USRSAV] = 0x00; /* reserved */
table[KS_USREAV] = 0x00; /* reserved */
table[KS_SHS1A] = 0x00; /* User Defined SHS1 A */
- table[KS_SHS1B] = 0x80; /* User Defined SHS1 B, ALT656=1 on 0127B */
+ /* User Defined SHS1 B, ALT656=1 on 0127B */
+ table[KS_SHS1B] = 0x80;
table[KS_SHS1C] = 0x00; /* User Defined SHS1 C */
table[KS_CMDE] = 0x00; /* Command Register E */
table[KS_VSDEL] = 0x00; /* VS Delay Control */
- table[KS_CMDF] = 0x02; /* Command Register F, update -immediately- (there might come no vsync)*/
+ /* Command Register F, update -immediately- */
+ /* (there might come no vsync)*/
+ table[KS_CMDF] = 0x02;
}
@@ -311,40 +318,40 @@ static void init_reg_defaults(void)
*/
-static u8 ks0127_read( struct ks0127* ks, u8 reg )
+static u8 ks0127_read(struct ks0127 *ks, u8 reg)
{
struct i2c_client *c = ks->client;
char val = 0;
struct i2c_msg msgs[] = {
- { c->addr, 0, sizeof(reg), ® },
- { c->addr, I2C_M_RD | I2C_M_NO_RD_ACK, sizeof(val), &val}};
+ {c->addr, 0, sizeof(reg), ®},
+ {c->addr, I2C_M_RD | I2C_M_NO_RD_ACK, sizeof(val), &val}};
int ret;
- ret = i2c_transfer(c->adapter, msgs, 2);
- if (ret != 2)
- dprintk( "ks0127_write error\n" );
+ ret = i2c_transfer(c->adapter, msgs, ARRAY_SIZE(msgs));
+ if (ret != ARRAY_SIZE(msgs))
+ dprintk("ks0127_write error\n");
return val;
}
-static void ks0127_write( struct ks0127* ks, u8 reg, u8 val )
+static void ks0127_write(struct ks0127 *ks, u8 reg, u8 val)
{
- char msg[] = { reg, val };
+ char msg[] = {reg, val};
- if ( i2c_master_send(ks->client, msg, sizeof(msg) ) != sizeof(msg) ) {
- dprintk( "ks0127_write error\n" );
- }
- ks->regs[ reg ] = val;
+ if (i2c_master_send(ks->client, msg, sizeof(msg)) != sizeof(msg))
+ dprintk("ks0127_write error\n");
+
+ ks->regs[reg] = val;
}
/* generic bit-twiddling */
-static void ks0127_and_or( struct ks0127* ks, u8 reg, u8 and_v, u8 or_v )
+static void ks0127_and_or(struct ks0127 *ks, u8 reg, u8 and_v, u8 or_v)
{
- u8 val = ks->regs[ reg ];
+ u8 val = ks->regs[reg];
val = (val & and_v) | or_v;
- ks0127_write( ks, reg, val );
+ ks0127_write(ks, reg, val);
}
@@ -352,29 +359,30 @@ static void ks0127_and_or( struct ks0127
/****************************************************************************
* ks0127 private api
****************************************************************************/
-static void ks0127_reset( struct ks0127* ks )
+static void ks0127_reset(struct ks0127* ks)
{
int i;
- u8* table = reg_defaults;
+ u8 *table = reg_defaults;
ks->ks_type = KS_TYPE_UNKNOWN;
- dprintk( "ks0127: reset\n" );
- udelay(1000);
+ dprintk("ks0127: reset\n");
+ msleep(1);
- /* initialize all registers to known values (except STAT, 0x21, 0x22, TEST and 0x38,0x39 ) */
+ /* initialize all registers to known values */
+ /* (except STAT, 0x21, 0x22, TEST and 0x38,0x39) */
- for(i = 1; i < 33; i++ )
- ks0127_write( ks, i, table[i] );
+ for(i = 1; i < 33; i++)
+ ks0127_write(ks, i, table[i]);
for(i = 35; i < 40; i++)
- ks0127_write( ks, i, table[i] );
+ ks0127_write(ks, i, table[i]);
for(i = 41; i < 56; i++)
- ks0127_write( ks, i, table[i] );
+ ks0127_write(ks, i, table[i]);
for(i = 58; i < 64; i++)
- ks0127_write( ks, i, table[i] );
+ ks0127_write(ks, i, table[i]);
if ((ks0127_read(ks, KS_STAT) & 0x80) == 0) {
@@ -401,32 +409,8 @@ static void ks0127_reset( struct ks0127*
}
}
-
-void ks0127_getcrop(struct ks0127 *ks, int *xstart, int *xend, int *ystart, int *yend)
-{
- *xstart = ((ks0127_read(ks, KS_HXTRA) & 0xe0) << 3) +
- ks0127_read(ks, KS_HAVB);
-
- *xend = ((ks0127_read(ks, KS_HXTRA) & 0x1c) << 6) +
- ks0127_read(ks, KS_HAVE);
-
- if ((*xstart) & 0x400)
- *xstart |= ~0x3ff;
-
- if ((*xend) & 0x400)
- *xend |= ~0x3ff;
-
- *ystart = ks0127_read(ks, KS_VAVB) >> 2;
- *yend = ks0127_read(ks, KS_VAVE);
- dprintk("ks0127: ystart=%d yend=%d\n", *ystart, *yend);
-
- *ystart = (*ystart - 2) * 2;
- *yend = (*yend - 2) * 2;
-}
-
-
-static int
-ks0127_command(struct i2c_client *client, unsigned int cmd, void *arg)
+static int ks0127_command(struct i2c_client *client,
+ unsigned int cmd, void *arg)
{
struct ks0127 *ks = i2c_get_clientdata(client);
@@ -434,195 +418,244 @@ ks0127_command(struct i2c_client *client
int status;
- if( !ks )
+ if (!ks)
return -ENODEV;
switch (cmd) {
case DECODER_INIT:
- dprintk( "ks0127: command DECODER_INIT\n" );
- ks0127_reset( ks );
+ dprintk("ks0127: command DECODER_INIT\n");
+ ks0127_reset(ks);
break;
case DECODER_SET_INPUT:
- switch( *iarg ) {
+ switch(*iarg) {
case KS_INPUT_COMPOSITE_1:
case KS_INPUT_COMPOSITE_2:
case KS_INPUT_COMPOSITE_3:
case KS_INPUT_COMPOSITE_4:
case KS_INPUT_COMPOSITE_5:
case KS_INPUT_COMPOSITE_6:
- dprintk( "ks0127: command DECODER_SET_INPUT %d: Composite\n", *iarg );
- ks0127_and_or( ks, KS_CMDA, 0xfc, 0x00 ); /* autodetect 50/60 Hz */
- ks0127_and_or( ks, KS_CMDA, ~0x40, 0x00 ); /* VSE=0 */
- ks0127_and_or( ks, KS_CMDB, 0xb0, *iarg ); /* set input line */
- ks0127_and_or( ks, KS_CMDC, 0x70, 0x0a ); /* non-freerunning mode */
- ks0127_and_or( ks, KS_CMDD, 0x03, 0x00 ); /* analog input */
- ks0127_and_or( ks, KS_CTRACK, 0xcf, 0x00 ); /* enable chroma demodulation */
- ks0127_and_or( ks, KS_LUMA, 0x00, (reg_defaults[KS_LUMA])|0x0c ); /* chroma trap, HYBWR=1 */
- ks0127_and_or( ks, KS_VERTIA, 0x08, 0x81 ); /* scaler fullbw, luma comb off */
- ks0127_and_or( ks, KS_VERTIC, 0x0f, 0x90 ); /* manual chroma comb .25 .5 .25 */
-
- ks0127_and_or( ks, KS_CHROMB, 0x0f, 0x90 ); /* chroma path delay */
-
- ks0127_write( ks, KS_UGAIN, reg_defaults[KS_UGAIN] );
- ks0127_write( ks, KS_VGAIN, reg_defaults[KS_VGAIN] );
- ks0127_write( ks, KS_UVOFFH, reg_defaults[KS_UVOFFH] );
- ks0127_write( ks, KS_UVOFFL, reg_defaults[KS_UVOFFL] );
+ dprintk("ks0127: command DECODER_SET_INPUT %d: "
+ "Composite\n", *iarg);
+ /* autodetect 50/60 Hz */
+ ks0127_and_or(ks, KS_CMDA, 0xfc, 0x00);
+ /* VSE=0 */
+ ks0127_and_or(ks, KS_CMDA, ~0x40, 0x00);
+ /* set input line */
+ ks0127_and_or(ks, KS_CMDB, 0xb0, *iarg);
+ /* non-freerunning mode */
+ ks0127_and_or(ks, KS_CMDC, 0x70, 0x0a);
+ /* analog input */
+ ks0127_and_or(ks, KS_CMDD, 0x03, 0x00);
+ /* enable chroma demodulation */
+ ks0127_and_or(ks, KS_CTRACK, 0xcf, 0x00);
+ /* chroma trap, HYBWR=1 */
+ ks0127_and_or(ks, KS_LUMA, 0x00,
+ (reg_defaults[KS_LUMA])|0x0c);
+ /* scaler fullbw, luma comb off */
+ ks0127_and_or(ks, KS_VERTIA, 0x08, 0x81);
+ /* manual chroma comb .25 .5 .25 */
+ ks0127_and_or(ks, KS_VERTIC, 0x0f, 0x90);
+
+ /* chroma path delay */
+ ks0127_and_or(ks, KS_CHROMB, 0x0f, 0x90);
+
+ ks0127_write(ks, KS_UGAIN, reg_defaults[KS_UGAIN]);
+ ks0127_write(ks, KS_VGAIN, reg_defaults[KS_VGAIN]);
+ ks0127_write(ks, KS_UVOFFH, reg_defaults[KS_UVOFFH]);
+ ks0127_write(ks, KS_UVOFFL, reg_defaults[KS_UVOFFL]);
break;
case KS_INPUT_SVIDEO_1:
case KS_INPUT_SVIDEO_2:
case KS_INPUT_SVIDEO_3:
- dprintk( "ks0127: command DECODER_SET_INPUT %d: S-Video\n", *iarg );
- ks0127_and_or( ks, KS_CMDA, 0xfc, 0x00 ); /* autodetect 50/60 Hz */
- ks0127_and_or( ks, KS_CMDA, ~0x40, 0x00 ); /* VSE=0 */
- ks0127_and_or( ks, KS_CMDB, 0xb0, *iarg ); /* set input line */
- ks0127_and_or( ks, KS_CMDC, 0x70, 0x0a ); /* non-freerunning mode */
- ks0127_and_or( ks, KS_CMDD, 0x03, 0x00 ); /* analog input */
- ks0127_and_or( ks, KS_CTRACK, 0xcf, 0x00 ); /* enable chroma demodulation */
- ks0127_and_or( ks, KS_LUMA, 0x00, reg_defaults[KS_LUMA] );
- ks0127_and_or( ks, KS_VERTIA, 0x08, (reg_defaults[KS_VERTIA]&0xf0)|0x01 ); /* disable luma comb */
- ks0127_and_or( ks, KS_VERTIC, 0x0f, reg_defaults[KS_VERTIC]&0xf0 );
-
- ks0127_and_or( ks, KS_CHROMB, 0x0f, reg_defaults[KS_CHROMB]&0xf0 );
-
- ks0127_write( ks, KS_UGAIN, reg_defaults[KS_UGAIN] );
- ks0127_write( ks, KS_VGAIN, reg_defaults[KS_VGAIN] );
- ks0127_write( ks, KS_UVOFFH, reg_defaults[KS_UVOFFH] );
- ks0127_write( ks, KS_UVOFFL, reg_defaults[KS_UVOFFL] );
+ dprintk("ks0127: command DECODER_SET_INPUT %d: "
+ "S-Video\n", *iarg);
+ /* autodetect 50/60 Hz */
+ ks0127_and_or(ks, KS_CMDA, 0xfc, 0x00);
+ /* VSE=0 */
+ ks0127_and_or(ks, KS_CMDA, ~0x40, 0x00);
+ /* set input line */
+ ks0127_and_or(ks, KS_CMDB, 0xb0, *iarg);
+ /* non-freerunning mode */
+ ks0127_and_or(ks, KS_CMDC, 0x70, 0x0a);
+ /* analog input */
+ ks0127_and_or(ks, KS_CMDD, 0x03, 0x00);
+ /* enable chroma demodulation */
+ ks0127_and_or(ks, KS_CTRACK, 0xcf, 0x00);
+ ks0127_and_or(ks, KS_LUMA, 0x00,
+ reg_defaults[KS_LUMA]);
+ /* disable luma comb */
+ ks0127_and_or(ks, KS_VERTIA, 0x08,
+ (reg_defaults[KS_VERTIA]&0xf0)|0x01);
+ ks0127_and_or(ks, KS_VERTIC, 0x0f,
+ reg_defaults[KS_VERTIC]&0xf0);
+
+ ks0127_and_or(ks, KS_CHROMB, 0x0f,
+ reg_defaults[KS_CHROMB]&0xf0);
+
+ ks0127_write(ks, KS_UGAIN, reg_defaults[KS_UGAIN]);
+ ks0127_write(ks, KS_VGAIN, reg_defaults[KS_VGAIN]);
+ ks0127_write(ks, KS_UVOFFH, reg_defaults[KS_UVOFFH]);
+ ks0127_write(ks, KS_UVOFFL, reg_defaults[KS_UVOFFL]);
break;
case KS_INPUT_YUV656:
- dprintk( "ks0127: command DECODER_SET_INPUT 15: YUV656\n" );
- if (ks->norm == VIDEO_MODE_NTSC || ks->norm == KS_STD_PAL_M) {
- ks0127_and_or( ks, KS_CMDA, 0xfc, 0x03 ); /* force 60 Hz */
- } else {
- ks0127_and_or( ks, KS_CMDA, 0xfc, 0x02 ); /* force 50 Hz */
- }
-
- ks0127_and_or( ks, KS_CMDA, 0xff, 0x40 ); /* VSE=1 */
- ks0127_and_or( ks, KS_CMDB, 0xb0, (*iarg | 0x40)); /* set input line and VALIGN */
- ks0127_and_or( ks, KS_CMDC, 0x70, 0x87 ); /* freerunning mode, TSTGEN = 1 TSTGFR=11 TSTGPH=0 TSTGPK=0 VMEM=1*/
- ks0127_and_or( ks, KS_CMDD, 0x03, 0x08); /* digital input, SYNDIR = 0 INPSL=01 CLKDIR=0 EAV=0 */
- ks0127_and_or( ks, KS_CTRACK, 0xcf, 0x30 ); /* disable chroma demodulation */
- ks0127_and_or( ks, KS_LUMA, 0x00, 0x71 ); /* HYPK =01 CTRAP = 0 HYBWR=0 PED=1 RGBH=1 UNIT=1 */
- ks0127_and_or( ks, KS_VERTIC, 0x0f, reg_defaults[KS_VERTIC]&0xf0 );
-
- ks0127_and_or( ks, KS_VERTIA, 0x08, 0x81 ); /* scaler fullbw, luma comb off */
-
- ks0127_and_or( ks, KS_CHROMB, 0x0f, reg_defaults[KS_CHROMB]&0xf0 );
-
- ks0127_and_or( ks, KS_CON, 0x00, 0x00);
- ks0127_and_or( ks, KS_BRT, 0x00, 32); /* spec: 34 */
- ks0127_and_or( ks, KS_SAT, 0x00, 0xe8); /* spec: 229 (e5) */
- ks0127_and_or( ks, KS_HUE, 0x00, 0);
-
- ks0127_and_or( ks, KS_UGAIN, 0x00, 238);
- ks0127_and_or( ks, KS_VGAIN, 0x00, 0x00);
-
- ks0127_and_or( ks, KS_UVOFFH, 0x00, 0x4f); /*UOFF:0x30, VOFF:0x30, TSTCGN=1 */
- ks0127_and_or( ks, KS_UVOFFL, 0x00, 0x00);
+ dprintk("ks0127: command DECODER_SET_INPUT 15: "
+ "YUV656\n");
+ if (ks->norm == VIDEO_MODE_NTSC ||
+ ks->norm == KS_STD_PAL_M)
+ /* force 60 Hz */
+ ks0127_and_or(ks, KS_CMDA, 0xfc, 0x03);
+ else
+ /* force 50 Hz */
+ ks0127_and_or(ks, KS_CMDA, 0xfc, 0x02);
+
+ ks0127_and_or(ks, KS_CMDA, 0xff, 0x40); /* VSE=1 */
+ /* set input line and VALIGN */
+ ks0127_and_or(ks, KS_CMDB, 0xb0, (*iarg | 0x40));
+ /* freerunning mode, */
+ /* TSTGEN = 1 TSTGFR=11 TSTGPH=0 TSTGPK=0 VMEM=1*/
+ ks0127_and_or(ks, KS_CMDC, 0x70, 0x87);
+ /* digital input, SYNDIR = 0 INPSL=01 CLKDIR=0 EAV=0 */
+ ks0127_and_or(ks, KS_CMDD, 0x03, 0x08);
+ /* disable chroma demodulation */
+ ks0127_and_or(ks, KS_CTRACK, 0xcf, 0x30);
+ /* HYPK =01 CTRAP = 0 HYBWR=0 PED=1 RGBH=1 UNIT=1 */
+ ks0127_and_or(ks, KS_LUMA, 0x00, 0x71);
+ ks0127_and_or(ks, KS_VERTIC, 0x0f,
+ reg_defaults[KS_VERTIC]&0xf0);
+
+ /* scaler fullbw, luma comb off */
+ ks0127_and_or(ks, KS_VERTIA, 0x08, 0x81);
+
+ ks0127_and_or(ks, KS_CHROMB, 0x0f,
+ reg_defaults[KS_CHROMB]&0xf0);
+
+ ks0127_and_or(ks, KS_CON, 0x00, 0x00);
+ ks0127_and_or(ks, KS_BRT, 0x00, 32); /* spec: 34 */
+ /* spec: 229 (e5) */
+ ks0127_and_or(ks, KS_SAT, 0x00, 0xe8);
+ ks0127_and_or(ks, KS_HUE, 0x00, 0);
+
+ ks0127_and_or(ks, KS_UGAIN, 0x00, 238);
+ ks0127_and_or(ks, KS_VGAIN, 0x00, 0x00);
+
+ /*UOFF:0x30, VOFF:0x30, TSTCGN=1 */
+ ks0127_and_or(ks, KS_UVOFFH, 0x00, 0x4f);
+ ks0127_and_or(ks, KS_UVOFFL, 0x00, 0x00);
break;
default:
- dprintk( "ks0127: command DECODER_SET_INPUT: Unknown input %d\n", *iarg );
+ dprintk("ks0127: command DECODER_SET_INPUT: "
+ "Unknown input %d\n", *iarg);
break;
}
- /* hack: CDMLPF sometimes spontaneously switches on; force back off */
- ks0127_write( ks, KS_DEMOD, reg_defaults[KS_DEMOD] );
+ /* hack: CDMLPF sometimes spontaneously switches on; */
+ /* force back off */
+ ks0127_write(ks, KS_DEMOD, reg_defaults[KS_DEMOD]);
break;
case DECODER_SET_OUTPUT:
- switch( *iarg ) {
+ switch(*iarg) {
case KS_OUTPUT_YUV656E:
- dprintk( "ks0127: command DECODER_SET_OUTPUT: OUTPUT_YUV656E (Missing)\n" );
+ dprintk("ks0127: command DECODER_SET_OUTPUT: "
+ "OUTPUT_YUV656E (Missing)\n");
return -EINVAL;
break;
case KS_OUTPUT_EXV:
- dprintk( "ks0127: command DECODER_SET_OUTPUT: OUTPUT_EXV\n" );
- ks0127_and_or( ks, KS_OFMTA, 0xf0, 0x09 );
+ dprintk("ks0127: command DECODER_SET_OUTPUT: "
+ "OUTPUT_EXV\n");
+ ks0127_and_or(ks, KS_OFMTA, 0xf0, 0x09);
break;
}
break;
case DECODER_SET_NORM: //sam This block mixes old and new norm names...
/* Set to automatic SECAM/Fsc mode */
- ks0127_and_or( ks, KS_DEMOD, 0xf0, 0x00 );
+ ks0127_and_or(ks, KS_DEMOD, 0xf0, 0x00);
ks->norm = *iarg;
- switch( *iarg )
+ switch(*iarg)
{
- /* this is untested !! It just detects PAL_N/NTSC_M (no special frequencies)
- And you have to set the standard a second time afterwards */
+ /* this is untested !! */
+ /* It just detects PAL_N/NTSC_M (no special frequencies) */
+ /* And you have to set the standard a second time afterwards */
case VIDEO_MODE_AUTO:
- dprintk( "ks0127: command DECODER_SET_NORM: AUTO\n" );
+ dprintk("ks0127: command DECODER_SET_NORM: AUTO\n");
- /* The chip determines the format based on the current field rate */
- ks0127_and_or( ks, KS_CMDA, 0xfc, 0x00 );
- ks0127_and_or( ks, KS_CHROMA, 0x9f, 0x20 ); //0x40 );
- /* This is wrong for PAL ! As I said, you need to set the standard once again !! */
+ /* The chip determines the format */
+ /* based on the current field rate */
+ ks0127_and_or(ks, KS_CMDA, 0xfc, 0x00);
+ ks0127_and_or(ks, KS_CHROMA, 0x9f, 0x20);
+ /* This is wrong for PAL ! As I said, */
+ /* you need to set the standard once again !! */
ks->format_height = 240;
ks->format_width = 704;
break;
case VIDEO_MODE_NTSC:
- dprintk( "ks0127: command DECODER_SET_NORM: NTSC_M\n" );
- ks0127_and_or( ks, KS_CHROMA, 0x9f, 0x20 ); //0x00 );
+ dprintk("ks0127: command DECODER_SET_NORM: NTSC_M\n");
+ ks0127_and_or(ks, KS_CHROMA, 0x9f, 0x20);
ks->format_height = 240;
ks->format_width = 704;
break;
case KS_STD_NTSC_N:
- dprintk( "ks0127: command KS0127_SET_STANDARD: NTSC_N (fixme)\n" );
- ks0127_and_or( ks, KS_CHROMA, 0x9f, 0x40 ); //0x00 );
+ dprintk("ks0127: command KS0127_SET_STANDARD: "
+ "NTSC_N (fixme)\n");
+ ks0127_and_or(ks, KS_CHROMA, 0x9f, 0x40);
ks->format_height = 240;
ks->format_width = 704;
break;
case VIDEO_MODE_PAL:
- dprintk( "ks0127: command DECODER_SET_NORM: PAL_N\n" );
- ks0127_and_or( ks, KS_CHROMA, 0x9f, 0x20 ); //0x60 );
+ dprintk("ks0127: command DECODER_SET_NORM: PAL_N\n");
+ ks0127_and_or(ks, KS_CHROMA, 0x9f, 0x20);
ks->format_height = 290;
ks->format_width = 704;
break;
case KS_STD_PAL_M:
- dprintk( "ks0127: command KS0127_SET_STANDARD: PAL_M (fixme)\n" );
- ks0127_and_or( ks, KS_CHROMA, 0x9f, 0x40 ); //0x60 );
+ dprintk("ks0127: command KS0127_SET_STANDARD: "
+ "PAL_M (fixme)\n");
+ ks0127_and_or(ks, KS_CHROMA, 0x9f, 0x40);
ks->format_height = 290;
ks->format_width = 704;
break;
case VIDEO_MODE_SECAM:
- dprintk( "ks0127: command KS0127_SET_STANDARD: SECAM\n" );
+ dprintk("ks0127: command KS0127_SET_STANDARD: "
+ "SECAM\n");
ks->format_height = 290;
ks->format_width = 704;
/* set to secam autodetection */
- ks0127_and_or( ks, KS_CHROMA, 0xdf, 0x20 );
- ks0127_and_or( ks, KS_DEMOD, 0xf0, 0x00 );
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(HZ/10+1);
+ ks0127_and_or(ks, KS_CHROMA, 0xdf, 0x20);
+ ks0127_and_or(ks, KS_DEMOD, 0xf0, 0x00);
+ schedule_timeout_interruptible(HZ/10+1);
/* did it autodetect? */
- if( ks0127_read( ks, KS_DEMOD ) & 0x40 )
+ if (ks0127_read(ks, KS_DEMOD) & 0x40)
break;
/* force to secam mode */
- ks0127_and_or( ks, KS_DEMOD, 0xf0, 0x0f );
+ ks0127_and_or(ks, KS_DEMOD, 0xf0, 0x0f);
break;
default:
- dprintk( "ks0127: command DECODER_SET_NORM: Unknown norm %d\n", *iarg );
+ dprintk("ks0127: command DECODER_SET_NORM: "
+ "Unknown norm %d\n", *iarg);
break;
}
break;
case DECODER_SET_PICTURE:
- dprintk( "ks0127: command DECODER_SET_PICTURE not yet supported (fixme)\n" );
+ dprintk("ks0127: command DECODER_SET_PICTURE "
+ "not yet supported (fixme)\n");
return -EINVAL;
//sam todo: KS0127_SET_BRIGHTNESS: Merge into DECODER_SET_PICTURE
@@ -650,13 +683,21 @@ ks0127_command(struct i2c_client *client
int *iarg = arg;
int enable = (*iarg != 0);
if (enable) {
- dprintk( "ks0127: command DECODER_ENABLE_OUTPUT on (%d)\n", enable );
- ks0127_and_or( ks, KS_OFMTA, 0xcf, 0x30 ); // All output pins on
- ks0127_and_or( ks, KS_CDEM, 0x7f, 0x00 ); // Obey the OEN pin
+ dprintk("ks0127: command "
+ "DECODER_ENABLE_OUTPUT on "
+ "(%d)\n", enable);
+ /* All output pins on */
+ ks0127_and_or(ks, KS_OFMTA, 0xcf, 0x30);
+ /* Obey the OEN pin */
+ ks0127_and_or(ks, KS_CDEM, 0x7f, 0x00);
} else {
- dprintk( "ks0127: command DECODER_ENABLE_OUTPUT off (%d)\n", enable );
- ks0127_and_or( ks, KS_OFMTA, 0xcf, 0x00 ); // Video output pins off
- ks0127_and_or( ks, KS_CDEM, 0x7f, 0x80 ); // Ignore the OEN pin
+ dprintk("ks0127: command "
+ "DECODER_ENABLE_OUTPUT off "
+ "(%d)\n", enable);
+ /* Video output pins off */
+ ks0127_and_or(ks, KS_OFMTA, 0xcf, 0x00);
+ /* Ignore the OEN pin */
+ ks0127_and_or(ks, KS_CDEM, 0x7f, 0x80);
}
}
break;
@@ -667,23 +708,22 @@ ks0127_command(struct i2c_client *client
//sam todo: KS0127_SET_HSCALE:
case DECODER_GET_STATUS:
- dprintk( "ks0127: command DECODER_GET_STATUS\n" );
+ dprintk("ks0127: command DECODER_GET_STATUS\n");
*iarg = 0;
- status = ks0127_read( ks, KS_STAT );
- if(!(status & 0x20)) /* NOVID not set */
+ status = ks0127_read(ks, KS_STAT);
+ if (!(status & 0x20)) /* NOVID not set */
*iarg = (*iarg & DECODER_STATUS_GOOD);
- if((status & 0x01)) /* CLOCK set */
+ if ((status & 0x01)) /* CLOCK set */
*iarg = (*iarg & DECODER_STATUS_COLOR);
- if((status & 0x08)) { /* PALDET set */
+ if ((status & 0x08)) /* PALDET set */
*iarg = (*iarg & DECODER_STATUS_PAL);
- } else {
+ else
*iarg = (*iarg & DECODER_STATUS_NTSC);
- }
break;
//Catch any unknown command
default:
- dprintk( "ks0127: command unknown: %04X\n", cmd );
+ dprintk("ks0127: command unknown: %04X\n", cmd);
return -EINVAL;
}
return 0;
@@ -694,14 +734,16 @@ ks0127_command(struct i2c_client *client
static int ks0127_probe(struct i2c_adapter *adapter);
static int ks0127_detach(struct i2c_client *client);
-static int ks0127_command(struct i2c_client *client, unsigned int cmd, void *arg );
+static int ks0127_command(struct i2c_client *client,
+ unsigned int cmd, void *arg);
/* Addresses to scan */
-static unsigned short normal_i2c[] = { I2C_KS0127_ADDON>>1, I2C_KS0127_ONBOARD>>1, I2C_CLIENT_END };
-static unsigned short probe[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-static unsigned short ignore[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
+static unsigned short normal_i2c[] = {I2C_KS0127_ADDON>>1,
+ I2C_KS0127_ONBOARD>>1, I2C_CLIENT_END};
+static unsigned short probe[2] = {I2C_CLIENT_END, I2C_CLIENT_END};
+static unsigned short ignore[2] = {I2C_CLIENT_END, I2C_CLIENT_END};
static struct i2c_client_address_data addr_data = {
normal_i2c,
probe,
@@ -709,12 +751,8 @@ static struct i2c_client_address_data ad
};
static struct i2c_driver i2c_driver_ks0127 = {
- .driver = {
- .name = "ks0127",
- },
-
+ .driver.name = "ks0127",
.id = I2C_DRIVERID_KS0127,
-
.attach_adapter = ks0127_probe,
.detach_client = ks0127_detach,
.command = ks0127_command
@@ -735,13 +773,13 @@ static int ks0127_found_proc(struct i2c_
struct i2c_client *client;
client = kzalloc(sizeof(*client), GFP_KERNEL);
- if(client == NULL)
+ if (client == NULL)
return -ENOMEM;
- memcpy( client, &ks0127_client_tmpl, sizeof(*client) );
+ memcpy(client, &ks0127_client_tmpl, sizeof(*client));
- ks = kzalloc( sizeof(*ks), GFP_KERNEL );
- if( ks == NULL ) {
- kfree( client );
+ ks = kzalloc(sizeof(*ks), GFP_KERNEL);
+ if (ks == NULL) {
+ kfree(client);
return -ENOMEM;
}
@@ -755,11 +793,11 @@ static int ks0127_found_proc(struct i2c_
ks->ks_type = KS_TYPE_UNKNOWN;
/* power up */
- ks0127_write( ks, KS_CMDA, 0x2c );
+ ks0127_write(ks, KS_CMDA, 0x2c);
mdelay(10);
/* reset the device */
- ks0127_reset( ks );
+ ks0127_reset(ks);
printk(KERN_INFO "ks0127: attach: %s video decoder\n",
ks->addr==(I2C_KS0127_ADDON>>1) ? "addon" : "on-board");
@@ -779,26 +817,26 @@ static int ks0127_detach(struct i2c_clie
{
struct ks0127 *ks = i2c_get_clientdata(client);
- ks0127_write( ks, KS_OFMTA, 0x20 ); /*tristate*/
- ks0127_write( ks, KS_CMDA, 0x2c | 0x80 ); /* power down */
+ ks0127_write(ks, KS_OFMTA, 0x20); /*tristate*/
+ ks0127_write(ks, KS_CMDA, 0x2c | 0x80); /* power down */
i2c_detach_client(client);
kfree(ks);
kfree(client);
- dprintk( "ks0127: detach\n" );
+ dprintk("ks0127: detach\n");
return 0;
}
-static int ks0127_init_module(void)
+static int __devinit ks0127_init_module(void)
{
init_reg_defaults();
i2c_add_driver(&i2c_driver_ks0127);
return 0;
}
-static void ks0127_cleanup_module(void)
+static void __devexit ks0127_cleanup_module(void)
{
i2c_del_driver(&i2c_driver_ks0127);
}
@@ -806,12 +844,3 @@ static void ks0127_cleanup_module(void)
module_init(ks0127_init_module);
module_exit(ks0127_cleanup_module);
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-basic-offset: 8
- * compile-command: "cd ../../.. && make modules SUBDIRS=drivers/media/video"
- * End:
- */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.