s feature
> configurable via DT. This is required for the Ka-Ro electronics
> platforms.
> [...]
How do you create the BBT the very first time with valuable data when the NAND
already contains factory bad blocks?
jbe
--
Pengutronix e.K. | Juergen Beisert
via DT. This is required for the Ka-Ro electronics
platforms.
[...]
How do you create the BBT the very first time with valuable data when the NAND
already contains factory bad blocks?
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions
Hi Hector,
On 07.06.2013 09:28, Hector Palacios wrote:
> On 06/07/2013 09:21 AM, maxime.rip...@free-electrons.com wrote:
>> Hi Hector,
>>
>> On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
>>> Someone told me, Qt5 cannot handle
Hi Hector,
On 07.06.2013 09:28, Hector Palacios wrote:
On 06/07/2013 09:21 AM, maxime.rip...@free-electrons.com wrote:
Hi Hector,
On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
Someone told me, Qt5 cannot handle this special RGB666 mode (even not the
def_rgb666_shift
Hi Hector,
Juergen Beisert wrote:
> Hector Palacios wrote:
> > On 05/24/2013 12:28 PM, Juergen Beisert wrote:
> > > Hector Palacios wrote:
> > >> On 05/23/2013 03:31 PM, Juergen Beisert wrote:
> > >>> maxime.rip...@free-electrons.com wrote:
>
Hector Palacios wrote:
> Hi Juergen,
>
> On 05/24/2013 12:28 PM, Juergen Beisert wrote:
> > Hector Palacios wrote:
> >> Hi Juergen,
> >>
> >> On 05/23/2013 03:31 PM, Juergen Beisert wrote:
> >>> Hi Maxime,
> >>>
> >>>
Hector Palacios wrote:
> Hi Juergen,
>
> On 05/23/2013 03:31 PM, Juergen Beisert wrote:
> > Hi Maxime,
> >
> > maxime.rip...@free-electrons.com wrote:
> >> On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
> >>> I'm using an i.MX28
Hector Palacios wrote:
Hi Juergen,
On 05/23/2013 03:31 PM, Juergen Beisert wrote:
Hi Maxime,
maxime.rip...@free-electrons.com wrote:
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
I'm using an i.MX28 based board with lcd connected with 18bits data
bus. My platform
Hector Palacios wrote:
Hi Juergen,
On 05/24/2013 12:28 PM, Juergen Beisert wrote:
Hector Palacios wrote:
Hi Juergen,
On 05/23/2013 03:31 PM, Juergen Beisert wrote:
Hi Maxime,
maxime.rip...@free-electrons.com wrote:
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote
Hi Hector,
Juergen Beisert wrote:
Hector Palacios wrote:
On 05/24/2013 12:28 PM, Juergen Beisert wrote:
Hector Palacios wrote:
On 05/23/2013 03:31 PM, Juergen Beisert wrote:
maxime.rip...@free-electrons.com wrote:
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote
R1
LCD_D20R4R2
LCD_D21R5R3
LCD_D22R6R4
LCD_D23R7R5
Is your display connected like LCD2 or LCD3? LCD3 must still handled like a 24
bit display shown in LCD1, wh
using the bits-per-pixel = 32 and bus-width = 18
entries in the device tree.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send
red -> 16..21 (skip 22/23).
> [...]
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.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
CLOSEST(6600, 1023));
return 0;
}
Result is on my x86 host (same on my ARM target):
Constants
-1 -> -1
-1 -> 0
0 -> 0
0 -> 0
1 -> 1
1 -> 3
2 -> 6
Variables
-1 -> 2147483647
-1 -> 4198403
0 -> 4198403
3300 -> 3
6600 -> 6
Regards,
Juergen
--
Pengutronix e.K.
x86 host (same on my ARM target):
Constants
-1 - -1
-1 - 0
0 - 0
0 - 0
1 - 1
1 - 3
2 - 6
Variables
-1 - 2147483647
-1 - 4198403
0 - 4198403
3300 - 3
6600 - 6
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry
Hi Guenter,
Guenter Roeck wrote:
> On Tue, Dec 18, 2012 at 10:04:56PM +0100, Juergen Beisert wrote:
> > Guenter Roeck wrote:
> > > On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
> > > > commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the cod
Hi Guenter,
Guenter Roeck wrote:
> On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
> > commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the code of
> > DIV_ROUND_CLOSEST in include/linux/kernel.h to fix a compile time
> > warning.
> >
&g
. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.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
. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.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
Hi Guenter,
Guenter Roeck wrote:
On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the code of
DIV_ROUND_CLOSEST in include/linux/kernel.h to fix a compile time
warning.
But now feeding in a zero into this macro
Hi Guenter,
Guenter Roeck wrote:
On Tue, Dec 18, 2012 at 10:04:56PM +0100, Juergen Beisert wrote:
Guenter Roeck wrote:
On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the code of
DIV_ROUND_CLOSEST in include
On Sunday 30 December 2007 16:38, Alan Cox wrote:
> > do you have any memories about the outb_p() use of misc_32.c:
> >
> > pos = (x + cols * y) * 2; /* Update cursor position */
> > outb_p(14, vidport);
> > outb_p(0xff & (pos >> 9), vidport+1);
> > outb_p(15,
On Sunday 30 December 2007 16:38, Alan Cox wrote:
do you have any memories about the outb_p() use of misc_32.c:
pos = (x + cols * y) * 2; /* Update cursor position */
outb_p(14, vidport);
outb_p(0xff (pos 9), vidport+1);
outb_p(15, vidport);
NON-RT tasks. So this will improve RT behaviour.
^^
Why?
IMHO: Simply decrease the RT priority of less important IRQs or increase all
other more important IRQs. IRQs are always more important than other
processes in a system, also in non RT systems.
Juergen
--
Dipl.-
.
^^
Why?
IMHO: Simply decrease the RT priority of less important IRQs or increase all
other more important IRQs. IRQs are always more important than other
processes in a system, also in non RT systems.
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix
On Wednesday 12 December 2007 15:30, Rene Herman wrote:
> On 12-12-07 09:59, Juergen Beisert wrote:
> > $ for i in `seq 5`; do ./port80; sleep 1; done
> > cycles: out 5260, in 2372
> > cycles: out 5260, in 2384
> > cycles: out 5260, in 2323
> > cycles: out 5
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model
On Wednesday 12 December 2007 15:30, Rene Herman wrote:
On 12-12-07 09:59, Juergen Beisert wrote:
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat
On Thursday 27 September 2007 18:13, Juergen Beisert wrote:
> Index: linux-2.6.22/arch/i386/kernel/cpu/cyrix.c
> ===
> --- linux-2.6.22.orig/arch/i386/kernel/cpu/cyrix.c
> +++ linux-2.6.22/arch/i386/kernel/cpu/cyrix.c
On Thursday 27 September 2007 18:13, Juergen Beisert wrote:
Index: linux-2.6.22/arch/i386/kernel/cpu/cyrix.c
===
--- linux-2.6.22.orig/arch/i386/kernel/cpu/cyrix.c
+++ linux-2.6.22/arch/i386/kernel/cpu/cyrix.c
@@ -169,7 +169,7
Hi AMrco,
On Thursday 27 September 2007 16:44, Marco Tralli wrote:
> I have random hangs on kernel boot or after few minutes on a NatSemi Geode
> GX1 based PC-104 (from Advantech) using kernel 2.6.23-rc6. The system
> locks, no way to use SysRq key, no usefull logs.
>
> No problems using kernel
Hi AMrco,
On Thursday 27 September 2007 16:44, Marco Tralli wrote:
I have random hangs on kernel boot or after few minutes on a NatSemi Geode
GX1 based PC-104 (from Advantech) using kernel 2.6.23-rc6. The system
locks, no way to use SysRq key, no usefull logs.
No problems using kernel 2.6.21
On Wednesday 29 August 2007 16:44, Daniel Drake wrote:
> On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote:
> > > My experiments show that when there is not much free physical memory,
> > > swapoff moves pages out of swap at a rate of approximately 5mb/sec.
> >
> > sounds like about disk
On Wednesday 29 August 2007 16:44, Daniel Drake wrote:
On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote:
My experiments show that when there is not much free physical memory,
swapoff moves pages out of swap at a rate of approximately 5mb/sec.
sounds like about disk speed (at
On Saturday 21 July 2007 14:00, Alexey Dobriyan wrote:
> On Fri, Jul 20, 2007 at 05:32:53PM +0200, Andi Kleen wrote:
> > --- /dev/null
> > +++ linux/include/asm-i386/processor-cyrix.h
> > @@ -0,0 +1,30 @@
> > +/*
> > + * NSC/Cyrix CPU indexed register access. Must be inlined instead of
> > + *
Hi Andi,
On Thursday 19 July 2007 11:25, Andi Kleen wrote:
> On Thursday 19 July 2007 10:52:48 Juergen Beisert wrote:
> > On Thursday 19 July 2007 10:22, Andi Kleen wrote:
> > > > Wow, that's a really cool bug; nice work! Don't forget to update
> > > > arch/i38
On Thursday 19 July 2007 10:22, Andi Kleen wrote:
> > Wow, that's a really cool bug; nice work! Don't forget to update
> > arch/i386/kernel/cpu/mtrr/state.c, though; it uses setCx86() as well. It
> > needs to include processor-cyrix.h.
>
> It also needs some big fat comments
No problem. Where
On Thursday 19 July 2007 09:17, Andres Salomon wrote:
> On Thu, 19 Jul 2007 08:49:05 +0200
>
> Juergen Beisert <[EMAIL PROTECTED]> wrote:
> > On Thursday 19 July 2007 03:02, Andrew Morton wrote:
> > > On Sun, 15 Jul 2007 21:06:27 +0200
> > >
> >
On Thursday 19 July 2007 03:02, Andrew Morton wrote:
> On Sun, 15 Jul 2007 21:06:27 +0200
>
> Juergen Beisert <[EMAIL PROTECTED]> wrote:
> > Replace NSC/Cyrix specific chipset access macros by inlined functions.
> > With the macros a line like this fails (and doe
On Thursday 19 July 2007 03:02, Andrew Morton wrote:
On Sun, 15 Jul 2007 21:06:27 +0200
Juergen Beisert [EMAIL PROTECTED] wrote:
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86
On Thursday 19 July 2007 09:17, Andres Salomon wrote:
On Thu, 19 Jul 2007 08:49:05 +0200
Juergen Beisert [EMAIL PROTECTED] wrote:
On Thursday 19 July 2007 03:02, Andrew Morton wrote:
On Sun, 15 Jul 2007 21:06:27 +0200
Juergen Beisert [EMAIL PROTECTED] wrote:
Replace NSC/Cyrix
On Thursday 19 July 2007 10:22, Andi Kleen wrote:
Wow, that's a really cool bug; nice work! Don't forget to update
arch/i386/kernel/cpu/mtrr/state.c, though; it uses setCx86() as well. It
needs to include processor-cyrix.h.
It also needs some big fat comments
No problem. Where to add?
Hi Andi,
On Thursday 19 July 2007 11:25, Andi Kleen wrote:
On Thursday 19 July 2007 10:52:48 Juergen Beisert wrote:
On Thursday 19 July 2007 10:22, Andi Kleen wrote:
Wow, that's a really cool bug; nice work! Don't forget to update
arch/i386/kernel/cpu/mtrr/state.c, though; it uses
it makes sense to mark the TSC unstable if the halt/suspend feature is
activated.
Juergen
From: Juergen Beisert <[EMAIL PROTECTED]>
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX
sense to mark the TSC unstable if the halt/suspend feature is
activated.
Juergen
From: Juergen Beisert [EMAIL PROTECTED]
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88
From: Juergen Beisert <[EMAIL PROTECTED]>
2nd try to include it into mainline.
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions thi
From: Juergen Beisert <[EMAIL PROTECTED]>
Trivial patch to build the IOWARRIOR when it is selected in Kconfig.
Signed-off-by: Juergen Beisert <[EMAIL PROTECTED]>
Index: drivers/usb/Makefile
===
--- drivers/usb/Makefile
From: Juergen Beisert [EMAIL PROTECTED]
Trivial patch to build the IOWARRIOR when it is selected in Kconfig.
Signed-off-by: Juergen Beisert [EMAIL PROTECTED]
Index: drivers/usb/Makefile
===
--- drivers/usb/Makefile
+++ drivers/usb
From: Juergen Beisert [EMAIL PROTECTED]
2nd try to include it into mainline.
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line
On Tuesday 12 June 2007 23:09, Jason Lunz wrote:
> In gmane.linux.kernel, you wrote:
> > I was wondering: is there any reason not to use ext2 on an USB
> > pendrive? Really my question is not only about USB pendrives, but any
> > device whose storage is flash based. Let's assume that the
On Tuesday 12 June 2007 23:09, Jason Lunz wrote:
In gmane.linux.kernel, you wrote:
I was wondering: is there any reason not to use ext2 on an USB
pendrive? Really my question is not only about USB pendrives, but any
device whose storage is flash based. Let's assume that the device has a
On Tuesday 12 June 2007 02:35, Kevin Bowling wrote:
> All of the posts fail to address the question here: what is the
> correct file system, or does one exist yet, for wear leveling flash
> storage.
> JFFS2 and logfs are nice for MTD, but for better flash
> memories that are likely to be used in
On Tuesday 12 June 2007 02:35, Kevin Bowling wrote:
All of the posts fail to address the question here: what is the
correct file system, or does one exist yet, for wear leveling flash
storage.
JFFS2 and logfs are nice for MTD, but for better flash
memories that are likely to be used in the
On Monday 11 June 2007 19:42, DervishD wrote:
> I just was curious about the issue and I was asking to know if
> anybody had tried this.
Think about compact flash devices. They also using some kind of flash memory
and also doing wear leveling. And I think they are not only used with
On Monday 11 June 2007 19:42, DervishD wrote:
I just was curious about the issue and I was asking to know if
anybody had tried this.
Think about compact flash devices. They also using some kind of flash memory
and also doing wear leveling. And I think they are not only used with
FAT16/32!
Hi Andrew,
On Wednesday 02 May 2007 02:48, Andrew Morton wrote:
> On Mon, 30 Apr 2007 17:33:41 +0200
>
> Juergen Beisert <[EMAIL PROTECTED]> wrote:
> > From: Juergen Beisert <[EMAIL PROTECTED]>
> >
> > Replace NSC/Cyrix specific chipset access macros by
Hi Andrew,
On Wednesday 02 May 2007 02:48, Andrew Morton wrote:
On Mon, 30 Apr 2007 17:33:41 +0200
Juergen Beisert [EMAIL PROTECTED] wrote:
From: Juergen Beisert [EMAIL PROTECTED]
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like
From: Juergen Beisert <[EMAIL PROTECTED]>
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as expected.
Note
On Monday 30 April 2007 14:20, Andreas Mohr wrote:
> Also, it would probably be good to convert these macros into inline
> functions in this header.
I tried with inlined functions and it works now as expected. I sent a patch,
maybe it helps others too.
Juergen
-
To unsubscribe from this list:
From: Juergen Beisert <[EMAIL PROTECTED]>
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as expected.
Note
Hi all,
I do not understand it, but setting up some chipset features (tweaks) fail on
Geode GX1.
In arch/i386/kernel/cpu/cyrix.c function geode_configure() tries to enable
the "suspend on halt power saving feature". This is the line:
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
If
Hi all,
I do not understand it, but setting up some chipset features (tweaks) fail on
Geode GX1.
In arch/i386/kernel/cpu/cyrix.c function geode_configure() tries to enable
the suspend on halt power saving feature. This is the line:
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
If
From: Juergen Beisert [EMAIL PROTECTED]
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as expected.
Note about
On Monday 30 April 2007 14:20, Andreas Mohr wrote:
Also, it would probably be good to convert these macros into inline
functions in this header.
I tried with inlined functions and it works now as expected. I sent a patch,
maybe it helps others too.
Juergen
-
To unsubscribe from this list:
From: Juergen Beisert [EMAIL PROTECTED]
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as expected.
Note about
Hi,
On Sunday 22 April 2007 00:42, OGAWA Hirofumi wrote:
> Yes. It seems that Windows does not update the ->free_clusters correctly.
> Probably, I think the option is good for now. What do you think about
> an attached patch?
Please don't ask me, because I'm not a filesystem expert. Sorry. My
Hi,
On Sunday 22 April 2007 00:42, OGAWA Hirofumi wrote:
Yes. It seems that Windows does not update the -free_clusters correctly.
Probably, I think the option is good for now. What do you think about
an attached patch?
Please don't ask me, because I'm not a filesystem expert. Sorry. My
On Thursday 19 April 2007 10:57, DervishD wrote:
> I have a portable device with a FAT32 formatted hard disk in it, and
> everytime I delete a file in the device *using the device itself to do
> it* the device increases its count of free space and if I plug the
> device in a Windows system,
On Thursday 19 April 2007 10:57, DervishD wrote:
I have a portable device with a FAT32 formatted hard disk in it, and
everytime I delete a file in the device *using the device itself to do
it* the device increases its count of free space and if I plug the
device in a Windows system,
Hi all,
is there a "nice" way to go to use the kfifo feature together with
copy_from/to_user without a temporarily buffer? I didn't find any example
yet.
Thanks in advance for any hint.
Juergen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hi all,
is there a nice way to go to use the kfifo feature together with
copy_from/to_user without a temporarily buffer? I didn't find any example
yet.
Thanks in advance for any hint.
Juergen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Friday 02 February 2007 07:29, Adrian Bunk wrote:
> Since there is AFAIK no actually observed problem fixed by this, it
> should be safe to simply revert the patch for 2.6.20.
The most important fix was:
Index: linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
On Friday 02 February 2007 07:29, Adrian Bunk wrote:
Since there is AFAIK no actually observed problem fixed by this, it
should be safe to simply revert the patch for 2.6.20.
The most important fix was:
Index: linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
On Tuesday 09 January 2007 18:33, Lennart Sorensen wrote:
> Then for the next one it does:
> ccr3 = GetCx86(CX86_CCR3);
> setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
>
> Couldn't that have been:
> setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10);
>
> No temp variable, and again it clearly does
On Tuesday 09 January 2007 16:43, Lennart Sorensen wrote:
> On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
> > In kernel 2.6, write back wrong register when configure Geode processor.
> > Instead of storing to CCR4, it stores to CCR3.
> >
> > ---
On Tuesday 09 January 2007 16:43, Lennart Sorensen wrote:
On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
In kernel 2.6, write back wrong register when configure Geode processor.
Instead of storing to CCR4, it stores to CCR3.
--- linux-2.6.19/arch/i386/kernel/cpu/cyrix.c.orig
On Tuesday 09 January 2007 18:33, Lennart Sorensen wrote:
Then for the next one it does:
ccr3 = GetCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 0x0f) | 0x10);
Couldn't that have been:
setCx86(CX86_CCR3, (getCx86(CX86_CCR3) 0x0f) | 0x10);
No temp variable, and again it clearly does not
Hi!
Is there any "standard" way to handle _one_ function in _one_ driver where the
hardware is divided into something like a platform device (some registers are
fixed in the chipset) and a PCI part? To bring the function up, registers in
both parts must be programmed and they depend on each
Hi!
Is there any standard way to handle _one_ function in _one_ driver where the
hardware is divided into something like a platform device (some registers are
fixed in the chipset) and a PCI part? To bring the function up, registers in
both parts must be programmed and they depend on each
Hi Alexey,
On Friday 12 January 2007 20:36, Alexey Dobriyan wrote:
> On Fri, Jan 12, 2007 at 01:43:42PM +0100, Juergen Beisert wrote:
> > does someone know how to forward a kernel command line option to
> > configure the AMD Geode GX1 framebuffer?
> >
> > I tri
Hi Alexey,
On Friday 12 January 2007 20:36, Alexey Dobriyan wrote:
On Fri, Jan 12, 2007 at 01:43:42PM +0100, Juergen Beisert wrote:
does someone know how to forward a kernel command line option to
configure the AMD Geode GX1 framebuffer?
I tried with video=gx1fb:[EMAIL PROTECTED
Hi,
does someone know how to forward a kernel command line option to configure the
AMD Geode GX1 framebuffer?
I tried with "video=gx1fb:[EMAIL PROTECTED]" but it does not work. On another
machine with an SIS framebuffer the line "video=sisfb:[EMAIL PROTECTED]" works
as expected.
Any ideas?
Hi,
does someone know how to forward a kernel command line option to configure the
AMD Geode GX1 framebuffer?
I tried with video=gx1fb:[EMAIL PROTECTED] but it does not work. On another
machine with an SIS framebuffer the line video=sisfb:[EMAIL PROTECTED] works
as expected.
Any ideas?
On Thursday 07 December 2006 09:02, ANIL JACOB wrote:
> At what stage of the initiation the probe function is called. I guess when
> compiled as a module, the only entry point of the driver I will be having
> is init function and the exit point is exit function. Then how will it be
> entering into
On Thursday 07 December 2006 09:02, ANIL JACOB wrote:
At what stage of the initiation the probe function is called. I guess when
compiled as a module, the only entry point of the driver I will be having
is init function and the exit point is exit function. Then how will it be
entering into the
87 matches
Mail list logo
