* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-22 13:48 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Andrew Morton, jes, linux-kernel, linuxppc-embedded
In-Reply-To: <43AA65F4.10409@intracom.gr>
Hi Pantelis,
Pantelis Antoniou wrote:
> Andrey Volkov wrote:
>
>> Hello Jes and all
>>
>> I try to use your allocator (gen_pool_xxx), idea of which
>> is a cute nice thing. But current implementation of it is
>> inappropriate for a _device_ (aka onchip, like framebuffer) memory
>> allocation, by next reasons:
>>
>> 1) Device memory is expensive resource by access time and/or size cost.
>> So we couldn't use (usually) this memory for the free blocks lists.
>> 2) Device memory usually have special requirement of access to it
>> (alignment/special insn). So we couldn't use part of allocated
>> blocks for some control structures (this problem solved in your
>> implementation, it's common remark)
>> 3) Obvious (IMHO) workflow of mem. allocator look like:
>> - at startup time, driver allocate some big
>> (almost) static mem. chunk(s) for a control/data structures.
>> - during work of the device, driver allocate many small
>> mem. blocks with almost identical size.
>> such behavior lead to degeneration of buddy method and
>> transform it to the first/best fit method (with long seek
>> by the free node list).
>> 4) The simple binary buddy method is far away from perfect for a device
>> due to a big internal fragmentation. Especially for a
>> network/mfd devices, for which, size of allocated data very
>> often is not a power of 2.
>>
>> I start to modify your code to satisfy above demands,
>> but firstly I wish to know your, or somebody else, opinion.
>>
>> Especially I will very happy if somebody have and could
>> provide to all, some device specific memory usage statistics.
>>
>
> Hi Andrey,
>
> FYI, on arch/ppc/lib/rheap.c theres an implementation of a remote heap.
>
> It is currently used for the management of freescale's CPM1 & CPM2 internal
> dual port RAM.
>
> Take a look, it might be what you have in mind.
>
> Regards
>
> Pantelis
Thanks I missed it (and small wonder! :( ).
Andrew, Is somebody count HOW MANY dev specific implementation
of buddy/first-fit allocators now in kernel?
--
Regards
Andrey Volkov
^ permalink raw reply
* Kernel cmdline
From: Achim Machura @ 2005-12-22 13:48 UTC (permalink / raw)
To: Linuxppc-Embedded (E-Mail)
Hello,
is the a posibility to read (parse) the cmdline in a driver, similar to cat
/proc/cmdline ?
best regards
Achim
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-22 14:15 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrew Morton, jes, linux-kernel, linuxppc-embedded
In-Reply-To: <43AAAEA2.8030200@varma-el.com>
Andrey Volkov wrote:
> Hi Pantelis,
>
> Pantelis Antoniou wrote:
>
>>Andrey Volkov wrote:
>>
[snip]
>>
>>Hi Andrey,
>>
>>FYI, on arch/ppc/lib/rheap.c theres an implementation of a remote heap.
>>
>>It is currently used for the management of freescale's CPM1 & CPM2 internal
>>dual port RAM.
>>
>>Take a look, it might be what you have in mind.
>>
>>Regards
>>
>>Pantelis
>
>
> Thanks I missed it (and small wonder! :( ).
>
> Andrew, Is somebody count HOW MANY dev specific implementation
> of buddy/first-fit allocators now in kernel?
>
Yes, it is indeed messy.
The rheap implementation is generic enough and I believe can fit most of the
special memory allocators needs. If you'd like I could move it somewhere
generic and test it.
Regards
Pantelis
^ permalink raw reply
* RE: Kernel cmdline
From: Jenkins, Clive @ 2005-12-22 14:59 UTC (permalink / raw)
To: achim.machura, Linuxppc-Embedded (E-Mail)
> From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Achim Machura
> Sent: 22 December 2005 13:48
> To: Linuxppc-Embedded (E-Mail)
> Subject: Kernel cmdline
>
>
> Hello,
>
> is the a posibility to read (parse) the cmdline in a driver, similar
to cat
> /proc/cmdline ?
>
> best regards
>
> Achim
Yes. Look at:
http://lxr.linux.no/source/init/main.c?v=3D2.6.10;a=3Dppc#L123
Clive
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* AW: Kernel cmdline
From: Achim Machura @ 2005-12-22 15:35 UTC (permalink / raw)
To: 'Jenkins, Clive'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <35786B99AB3FDC45A8215724617919736D91B7@gbrwgceumf01.eu.xerox.net>
> Yes. Look at:
> http://lxr.linux.no/source/init/main.c?v=2.6.10;a=ppc#L123
> Clive
Thanks,
but this exaple seems to work only with modules staticly linked into the
kernel.
I' ve to parse the commandline in a dynamic loaded modul.
Achim
^ permalink raw reply
* console problem on 8247
From: srideep.devireddy @ 2005-12-22 15:17 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
HI ,
i am trying to use Ram disk with my mpc8247 board and compiled both the linux kernel image and the ramdisk image and tried to load it on to the board when i try doing this i am getting a familiar error which is know to all hangs after uncompressing linux kernel ... actually so please do tell me what might be the problem as we are using SMC as the console .
=> bootm 100000 b00000
## Booting image at 00100000 ...
Image Name: Linux-2.4.20_mvl31-8272ads
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 680207 Bytes = 664.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FBC18D8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF49
bd address = 0x0FBC1BB4
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x02000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xF0000000
bootflags = 0x00000001
vco = 396 MHz
sccfreq = 99 MHz
brgfreq = 24.750 MHz
intfreq = 264 MHz
cpmfreq = 198 MHz
busfreq = 66 MHz
ethaddr = 00:11:22:33:44:55
IP addr = 192.168.80.196
baudrate = 115200 bps
## Loading RAMDisk Image at 00b00000 ...
Image Name: uImage.ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1827099 Bytes = 1.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0x00B00040 ... 0x00CBE15A (len=1827099=0x1BE11B)
Loading Ramdisk to 0fa02000, end 0fbc011b ... OK
## Transferring control to Linux (at address 00000000) ...
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 3891 bytes --]
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-22 15:44 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Andrew Morton, jes, linux-kernel, linuxppc-embedded
In-Reply-To: <43AAB508.7000007@intracom.gr>
Pantelis Antoniou wrote:
> Andrey Volkov wrote:
>
>> Hi Pantelis,
>>
>> Pantelis Antoniou wrote:
>>
>>> Andrey Volkov wrote:
>>>
>
> [snip]
>
>>>
>>> Hi Andrey,
>>>
>>> FYI, on arch/ppc/lib/rheap.c theres an implementation of a remote heap.
>>>
>>> It is currently used for the management of freescale's CPM1 & CPM2
>>> internal
>>> dual port RAM.
>>>
>>> Take a look, it might be what you have in mind.
>>>
>>> Regards
>>>
>>> Pantelis
>>
>>
>>
>> Thanks I missed it (and small wonder! :( ).
>>
>> Andrew, Is somebody count HOW MANY dev specific implementation
>> of buddy/first-fit allocators now in kernel?
>>
>
> Yes, it is indeed messy.
>
> The rheap implementation is generic enough and I believe can fit most of
> the
> special memory allocators needs. If you'd like I could move it somewhere
> generic and test it.
>
I'm sure lib/ will be appropriate place. and something like
"DON'T TRY REINVENT WHEEL, TRY FIX EXISTS" in documentation/ :).
Now couple word about rheap: I understand why you are use static
alignment in allocator, but its very specialized for CPM. IMO, align
must be a param of xx_alloc. For ex: device may demand alignment by
8 bytes, which ok until... you are try map this memory to the user
space (don't shoot at me, remember about framebuffer & co).
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: AW: Kernel cmdline
From: Kumar Gala @ 2005-12-22 15:50 UTC (permalink / raw)
To: achim.machura; +Cc: Linuxppc-Embedded (E-Mail), 'Jenkins, Clive'
In-Reply-To: <001f01c6070d$649e8f00$34f1ff0a@beint.local>
On Dec 22, 2005, at 9:35 AM, Achim Machura wrote:
>
>> Yes. Look at:
>> http://lxr.linux.no/source/init/main.c?v=2.6.10;a=ppc#L123
>> Clive
>
> Thanks,
>
> but this exaple seems to work only with modules staticly linked
> into the
> kernel.
>
> I' ve to parse the commandline in a dynamic loaded modul.
Why would you want to do this. Anyways, the cmd_line is to exported
to modules. You can provide modules there own params
- kumar
^ permalink raw reply
* MPC5200 Cache issue with Bestcomm
From: Amir Bukhari @ 2005-12-22 15:39 UTC (permalink / raw)
To: linuxppc-embedded
Sorry this question is not related to linux kernel, but I can't find any
sources which I can find any tipps for the issue I encoured.
I write a standalone application with TCP stack (I use lwip stack). I am
want to enable the cache to increase performance of my application.
------------------------
Here is my configuration of various registers:
#define CORE_HID0_INIT 0x8010C000
#define CORE_HID2_INIT 0x00000000
#define CORE_IBAT0U_INIT 0x000007FF
#define CORE_IBAT0L_INIT 0x00000001
#define CORE_DBAT0U_INIT 0x000007FF
#define CORE_DBAT0L_INIT 0x00000052
#define CORE_DBAT1U_INIT 0xF000000F // for MBAR
#define CORE_DBAT1L_INIT 0xF000002A // for MBAR
#define CORE_DBAT2U_INIT 0x40001FFF
#define CORE_DBAT2L_INIT 0x40000022 // for PCI
#define CORE_DBAT3U_INIT 0x50001FFF //
#define CORE_DBAT3L_INIT 0x50000022 //
XLARB configuration is :
#define XLARB_CONFIG_INIT 0x8000A006 // snoop window is
enabled
#define XLARB_PRIORITY_ENABLE_INIT 0x0000000F
#define XLARB_PRIORITY_INIT 0x11111010
#define XLARB_SNOOP_WINDOW_INIT 0x00000019 // base address is =
0
and 64Mbytes length
----------------
Now as soon as I enable cache the Bestcomm doesn't stop firing me a =
ethernet
packet receive. It doesn't stop this and this let my system hangs up. =
When
running the system without cache every thing work well.
I will be happy if someone can give me a tipp if I may missed something!
-Amir
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-22 16:09 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Andrew Morton, jes, linux-kernel
In-Reply-To: <43AAC9E8.2060105@varma-el.com>
>
[snip]
> I'm sure lib/ will be appropriate place. and something like
> "DON'T TRY REINVENT WHEEL, TRY FIX EXISTS" in documentation/ :).
>
> Now couple word about rheap: I understand why you are use static
> alignment in allocator, but its very specialized for CPM. IMO, align
> must be a param of xx_alloc. For ex: device may demand alignment by
> 8 bytes, which ok until... you are try map this memory to the user
> space (don't shoot at me, remember about framebuffer & co).
>
It is trivial to align to a given alignment in a call. Please search
the archives since this was needed for CPM2 and I've committed a patch.
As for mapping user space, since rheap only deals with addresses and never
touches the memory it's supposed to control, you can do pretty much everything.
I still don't understand what are you trying to do however.
Mind explaining?
> --
> Regards
> Andrey Volkov
>
Regards
Pantelis
^ permalink raw reply
* AW: AW: Kernel cmdline
From: Achim Machura @ 2005-12-22 16:01 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <85C67BBD-0072-4B64-A7B1-71871E755B76@kernel.crashing.org>
Hello,
> > I' ve to parse the commandline in a dynamic loaded modul.
>
> Why would you want to do this. Anyways, the cmd_line is to exported
> to modules. You can provide modules there own params
i want check an argument given by the bootloader via commandline
Achim
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Jes Sorensen @ 2005-12-22 15:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <43A98F90.9010001@varma-el.com>
>>>>> "Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
Andrey> idea of which is a cute nice thing. But current implementation
Andrey> of it is inappropriate for a _device_ (aka onchip, like
Andrey> framebuffer) memory allocation, by next reasons:
Andrey,
Keep in mind that genalloc was meant to be simple for basic memory
allocations. It was never meant to be an over complex super high
performance allocation mechanism.
Andrey> 1) Device memory is expensive resource by access time and/or
Andrey> size cost. So we couldn't use (usually) this memory for the
Andrey> free blocks lists.
This really is irrelevant, the space is only used within the object
when it's on the free list. Ie. if all memory is handed out there's
no space used for this purpose.
Andrey> 3) Obvious (IMHO) workflow of mem. allocator
Andrey> look like: - at startup time, driver allocate some big
Andrey> (almost) static mem. chunk(s) for a control/data structures.
Andrey> - during work of the device, driver allocate many small
Andrey> mem. blocks with almost identical size. such behavior lead to
Andrey> degeneration of buddy method and transform it to the
Andrey> first/best fit method (with long seek by the free node list).
This is only really valid for network devices, and even then it's not
quite so. For things like uncached allocations your observation is
completely off.
For the case of more traditional devices, the control structures will
be allocated from one end of the block, the rest will be used for
packet descriptors which will be going in and out of the memory pool
on a regular basis. In most normal cases these will all be of the same
size and it doesn't matter where in the memory space they were
allocated.
Andrey> 4) The simple binary buddy method is far away from perfect for
Andrey> a device due to a big internal fragmentation. Especially for a
Andrey> network/mfd devices, for which, size of allocated data very
Andrey> often is not a power of 2.
For network devices it's perfectly adequate as it will almost always
satisfy what I described above. Incoming packets will always be
allocated for a full MTU sized packet hence all allocated blocks will
be of the same size. For outgoing packets, the allcation is short
lived and while it may be that a good chunk of packets aren't all full
MTU sized, it is rarely worth the hassle of trying to make the
allocator allow to-the-byte sized allocations as the number of
outstanding outgoing packets will be very limited.
Andrey> I start to modify your code to satisfy above demands, but
Andrey> firstly I wish to know your, or somebody else, opinion.
I honestly don't think the majority of your demands are valid.
genalloc was meant to be simple, not an ultra fast at any random
block size allocator. So far I don't see any reason for changing to
the allocation algorithm into anything much more complex - doesn't
mean there couldn't be a reason for doing so, but I don't think you
have described any so far.
You mentioned frame buffers, but what is the kernel supposed to do
with those allocation wise? If you have a frame buffer console, the
memory is allocated once and handed to the frame buffer driver.
Ie. you don't need a ton of on demand allocations for that and for
X, the memory management is handled in the X server, not by the
kernel.
The only thing I think would make sense to implement is to allow it to
use indirect descriptor blocks for the memory it manages. This is not
because it's wrong to use the memory for the free list, as it will
only be used for this when the chunk is not in use, but because access
to certain types of memory isn't always valid through normal direct
access. Ie. if one used descriptor blocks residing in normal
GFP_KERNEL memory, it would be possible to use the allocator to manage
memory sitting on the other side of a PCI bus.
Regards,
Jes
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-22 18:18 UTC (permalink / raw)
To: Jes Sorensen, Pantelis Antoniou
Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <yq0d5jpuoqe.fsf@jaguar.mkp.net>
Hi Jes,
Jes Sorensen wrote:
>>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
>
>
> Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
> Andrey> idea of which is a cute nice thing. But current implementation
> Andrey> of it is inappropriate for a _device_ (aka onchip, like
> Andrey> framebuffer) memory allocation, by next reasons:
>
> Andrey,
>
> Keep in mind that genalloc was meant to be simple for basic memory
> allocations. It was never meant to be an over complex super high
> performance allocation mechanism.
>
> Andrey> 1) Device memory is expensive resource by access time and/or
> Andrey> size cost. So we couldn't use (usually) this memory for the
> Andrey> free blocks lists.
>
> This really is irrelevant, the space is only used within the object
> when it's on the free list. Ie. if all memory is handed out there's
> no space used for this purpose.
I point out 2 reasons: ACCESS TIME was first :), let take very
widespread case: PCI device with some onboard memory and any
N GHz proc. - result may be terrible: each access to device mem (which
usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
same as we made busy-wait with disabled interrupts after each read/write...
I possible awry when use 'control structures' in 2), I've in view
allocator's control structures (size/next etc), not device specific
control structs.
>
> Andrey> 3) Obvious (IMHO) workflow of mem. allocator
> Andrey> look like: - at startup time, driver allocate some big
> Andrey> (almost) static mem. chunk(s) for a control/data structures.
> Andrey> - during work of the device, driver allocate many small
> Andrey> mem. blocks with almost identical size. such behavior lead to
> Andrey> degeneration of buddy method and transform it to the
> Andrey> first/best fit method (with long seek by the free node list).
>
> This is only really valid for network devices, and even then it's not
> quite so. For things like uncached allocations your observation is
> completely off.
Could you give me some examples? Possible I overlooked something
significant.
>
> For the case of more traditional devices, the control structures will
> be allocated from one end of the block, the rest will be used for
> packet descriptors which will be going in and out of the memory pool
> on a regular basis.
This was main reason why I try to modify genalloc: I needed in
generic allocator for both short-live strictly aligned blocks and
long-live blocks with restriction by size.
> In most normal cases these will all be of the same
> size and it doesn't matter where in the memory space they were
> allocated.
And thats also why I consider that 'buddy' is not appropriate to be
'generic' (most cases == generic, isn't is :)?): when you're allocate
mainly same sized blocks, 'buddy' degraded to the first-fit.
Possible solution I see in mixed first-fit with lazy coalescent for
short lived blocks and first-fit with immediately coalescent for
long-lived blocks. But, again, I may overlook something significant.
And, certainly, I could overlooked someone else allocator implementation
in some driver.
>
> Andrey> 4) The simple binary buddy method is far away from perfect for
> Andrey> a device due to a big internal fragmentation. Especially for a
> Andrey> network/mfd devices, for which, size of allocated data very
> Andrey> often is not a power of 2.
>
snip
>
> Andrey> I start to modify your code to satisfy above demands, but
> Andrey> firstly I wish to know your, or somebody else, opinion.
>
> I honestly don't think the majority of your demands are valid.
> genalloc was meant to be simple, not an ultra fast at any random
> block size allocator. So far I don't see any reason for changing to
> the allocation algorithm into anything much more complex - doesn't
> mean there couldn't be a reason for doing so, but I don't think you
> have described any so far.
I disagree here, generic couldn't be very simple and slow, because in
this case simply no one will be use it, and hence we'll get today's
picture: reimplemented allocators in many drivers.
>
> You mentioned frame buffers, but what is the kernel supposed to do
> with those allocation wise? If you have a frame buffer console, the
> memory is allocated once and handed to the frame buffer driver.
> Ie. you don't need a ton of on demand allocations for that and for
> X, the memory management is handled in the X server, not by the
> kernel.
For video-only device this is true, but if device is a multifunctional,
which is frequent case in embedded systems, then kernel must control of
device memory allocation. Currently, however, even video cards for
desktops become more and more multifunctional (VIVO/audio etc.).
>
> The only thing I think would make sense to implement is to allow it to
> use indirect descriptor blocks for the memory it manages. This is not
> because it's wrong to use the memory for the free list, as it will
> only be used for this when the chunk is not in use, but because access
> to certain types of memory isn't always valid through normal direct
> access. Ie. if one used descriptor blocks residing in normal
> GFP_KERNEL memory, it would be possible to use the allocator to manage
> memory sitting on the other side of a PCI bus.
I describe above, why we couldn't/wouldn't use onboard memory for
allocator specific data.
Pantelis, Am I answered to your question (...what are you trying to
do...) too?
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-22 18:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Andrew Morton, Jes Sorensen, linux-kernel
In-Reply-To: <43AAEE12.5030009@varma-el.com>
On Thursday 22 December 2005 20:18, Andrey Volkov wrote:
> Hi Jes,
>
> Jes Sorensen wrote:
> >>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
> >
> >
> > Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
> > Andrey> idea of which is a cute nice thing. But current implementation
> > Andrey> of it is inappropriate for a _device_ (aka onchip, like
> > Andrey> framebuffer) memory allocation, by next reasons:
> >
> > Andrey,
> >
> > Keep in mind that genalloc was meant to be simple for basic memory
> > allocations. It was never meant to be an over complex super high
> > performance allocation mechanism.
> >
> > Andrey> 1) Device memory is expensive resource by access time and/or
> > Andrey> size cost. So we couldn't use (usually) this memory for the
> > Andrey> free blocks lists.
> >
> > This really is irrelevant, the space is only used within the object
> > when it's on the free list. Ie. if all memory is handed out there's
> > no space used for this purpose.
>
> I point out 2 reasons: ACCESS TIME was first :), let take very
> widespread case: PCI device with some onboard memory and any
> N GHz proc. - result may be terrible: each access to device mem (which
> usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
> same as we made busy-wait with disabled interrupts after each read/write...
>
> I possible awry when use 'control structures' in 2), I've in view
> allocator's control structures (size/next etc), not device specific
> control structs.
>
> >
> > Andrey> 3) Obvious (IMHO) workflow of mem. allocator
> > Andrey> look like: - at startup time, driver allocate some big
> > Andrey> (almost) static mem. chunk(s) for a control/data structures.
> > Andrey> - during work of the device, driver allocate many small
> > Andrey> mem. blocks with almost identical size. such behavior lead to
> > Andrey> degeneration of buddy method and transform it to the
> > Andrey> first/best fit method (with long seek by the free node list).
> >
> > This is only really valid for network devices, and even then it's not
> > quite so. For things like uncached allocations your observation is
> > completely off.
>
> Could you give me some examples? Possible I overlooked something
> significant.
>
> >
> > For the case of more traditional devices, the control structures will
> > be allocated from one end of the block, the rest will be used for
> > packet descriptors which will be going in and out of the memory pool
> > on a regular basis.
>
> This was main reason why I try to modify genalloc: I needed in
> generic allocator for both short-live strictly aligned blocks and
> long-live blocks with restriction by size.
>
> > In most normal cases these will all be of the same
> > size and it doesn't matter where in the memory space they were
> > allocated.
>
> And thats also why I consider that 'buddy' is not appropriate to be
> 'generic' (most cases == generic, isn't is :)?): when you're allocate
> mainly same sized blocks, 'buddy' degraded to the first-fit.
>
> Possible solution I see in mixed first-fit with lazy coalescent for
> short lived blocks and first-fit with immediately coalescent for
> long-lived blocks. But, again, I may overlook something significant.
> And, certainly, I could overlooked someone else allocator implementation
> in some driver.
>
> >
> > Andrey> 4) The simple binary buddy method is far away from perfect for
> > Andrey> a device due to a big internal fragmentation. Especially for a
> > Andrey> network/mfd devices, for which, size of allocated data very
> > Andrey> often is not a power of 2.
> >
> snip
> >
> > Andrey> I start to modify your code to satisfy above demands, but
> > Andrey> firstly I wish to know your, or somebody else, opinion.
> >
> > I honestly don't think the majority of your demands are valid.
> > genalloc was meant to be simple, not an ultra fast at any random
> > block size allocator. So far I don't see any reason for changing to
> > the allocation algorithm into anything much more complex - doesn't
> > mean there couldn't be a reason for doing so, but I don't think you
> > have described any so far.
> I disagree here, generic couldn't be very simple and slow, because in
> this case simply no one will be use it, and hence we'll get today's
> picture: reimplemented allocators in many drivers.
>
> >
> > You mentioned frame buffers, but what is the kernel supposed to do
> > with those allocation wise? If you have a frame buffer console, the
> > memory is allocated once and handed to the frame buffer driver.
> > Ie. you don't need a ton of on demand allocations for that and for
> > X, the memory management is handled in the X server, not by the
> > kernel.
>
> For video-only device this is true, but if device is a multifunctional,
> which is frequent case in embedded systems, then kernel must control of
> device memory allocation. Currently, however, even video cards for
> desktops become more and more multifunctional (VIVO/audio etc.).
>
> >
> > The only thing I think would make sense to implement is to allow it to
> > use indirect descriptor blocks for the memory it manages. This is not
> > because it's wrong to use the memory for the free list, as it will
> > only be used for this when the chunk is not in use, but because access
> > to certain types of memory isn't always valid through normal direct
> > access. Ie. if one used descriptor blocks residing in normal
> > GFP_KERNEL memory, it would be possible to use the allocator to manage
> > memory sitting on the other side of a PCI bus.
> I describe above, why we couldn't/wouldn't use onboard memory for
> allocator specific data.
>
> Pantelis, Am I answered to your question (...what are you trying to
> do...) too?
>
Yes. rheap seems to cover your cases...
> --
> Regards
> Andrey Volkov
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Regards
Pantelis
^ permalink raw reply
* [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
From: Marcelo Tosatti @ 2005-12-22 19:52 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek
Hi,
The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx.
The first entry is written with the same virtual/physical address, which
renders it invalid:
BDI>rms 792 0x00001e00
BDI>rms 824 1
BDI>rds 824
SPR 824 : 0xc08000c0 -1065353024
BDI>rds 825
SPR 825 : 0xc0800de0 -1065349664
BDI>rds 826
SPR 826 : 0x00000000 0
And the second entry, in addition, does not have its TLB index set
correctly.
Dan, I'm afraid that, with this problem fixed, the issue you mentioned
before with relation to conflicts with the vmalloc space becomes real.
* only pin available RAM at initial_mmu, the pinned mappings pointing
beyond the end of physical RAM cause conflicts with vmalloc() space.
Is there any way to know the RAM size at this point in boot? The bd_t
structure is board-specific, so no chance at offseting bd_t to reach the
"mem_size" field.
I see no improvements with the following patch on 128MB boxen, probably
because most referenced kernel data is above 24MB (SLAB caches, etc).
But lower mem machines should benefit significantly - anyone willing to
do some testing?
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index de09787..c67cb5c 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -733,13 +733,16 @@ initial_mmu:
mtspr SPRN_MD_TWC, r9
li r11, MI_BOOTINIT /* Create RPN for address 0 */
addis r11, r11, 0x0080 /* Add 8M */
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r11
+
+ addi r10, r10, 0x0100
+ mtspr SPRN_MD_CTR, r10
addis r8, r8, 0x0080 /* Add 8M */
mtspr SPRN_MD_EPN, r8
mtspr SPRN_MD_TWC, r9
addis r11, r11, 0x0080 /* Add 8M */
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r11
#endif
/* Since the cache is enabled according to the information we
^ permalink raw reply related
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-23 7:38 UTC (permalink / raw)
To: pantelis.antoniou
Cc: Andrew Morton, Jes Sorensen, linux-kernel, linuxppc-embedded
In-Reply-To: <200512222033.40156.pantelis.antoniou@gmail.com>
Pantelis Antoniou wrote:
> On Thursday 22 December 2005 20:18, Andrey Volkov wrote:
>
>>Hi Jes,
>>
>>Jes Sorensen wrote:
>>
>>>>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
>>>
>>>
>>>Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
>>>Andrey> idea of which is a cute nice thing. But current implementation
>>>Andrey> of it is inappropriate for a _device_ (aka onchip, like
>>>Andrey> framebuffer) memory allocation, by next reasons:
>>>
>>>Andrey,
>>>
>>>Keep in mind that genalloc was meant to be simple for basic memory
>>>allocations. It was never meant to be an over complex super high
>>>performance allocation mechanism.
>>>
>>>Andrey> 1) Device memory is expensive resource by access time and/or
>>>Andrey> size cost. So we couldn't use (usually) this memory for the
>>>Andrey> free blocks lists.
>>>
>>>This really is irrelevant, the space is only used within the object
>>>when it's on the free list. Ie. if all memory is handed out there's
>>>no space used for this purpose.
>>
>>I point out 2 reasons: ACCESS TIME was first :), let take very
>>widespread case: PCI device with some onboard memory and any
>>N GHz proc. - result may be terrible: each access to device mem (which
>>usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
>>same as we made busy-wait with disabled interrupts after each read/write...
>>
>>I possible awry when use 'control structures' in 2), I've in view
>>allocator's control structures (size/next etc), not device specific
>>control structs.
>>
>>
>>>Andrey> 3) Obvious (IMHO) workflow of mem. allocator
>>>Andrey> look like: - at startup time, driver allocate some big
>>>Andrey> (almost) static mem. chunk(s) for a control/data structures.
>>>Andrey> - during work of the device, driver allocate many small
>>>Andrey> mem. blocks with almost identical size. such behavior lead to
>>>Andrey> degeneration of buddy method and transform it to the
>>>Andrey> first/best fit method (with long seek by the free node list).
>>>
>>>This is only really valid for network devices, and even then it's not
>>>quite so. For things like uncached allocations your observation is
>>>completely off.
>>
>>Could you give me some examples? Possible I overlooked something
>>significant.
>>
>>
>>>For the case of more traditional devices, the control structures will
>>>be allocated from one end of the block, the rest will be used for
>>>packet descriptors which will be going in and out of the memory pool
>>>on a regular basis.
>>
>>This was main reason why I try to modify genalloc: I needed in
>>generic allocator for both short-live strictly aligned blocks and
>>long-live blocks with restriction by size.
>>
>>
>>>In most normal cases these will all be of the same
>>>size and it doesn't matter where in the memory space they were
>>>allocated.
>>
>>And thats also why I consider that 'buddy' is not appropriate to be
>>'generic' (most cases == generic, isn't is :)?): when you're allocate
>>mainly same sized blocks, 'buddy' degraded to the first-fit.
>>
>>Possible solution I see in mixed first-fit with lazy coalescent for
>>short lived blocks and first-fit with immediately coalescent for
>>long-lived blocks. But, again, I may overlook something significant.
>>And, certainly, I could overlooked someone else allocator implementation
>>in some driver.
>>
>>
>>>Andrey> 4) The simple binary buddy method is far away from perfect for
>>>Andrey> a device due to a big internal fragmentation. Especially for a
>>>Andrey> network/mfd devices, for which, size of allocated data very
>>>Andrey> often is not a power of 2.
>>>
>>
>>snip
>>
>>>Andrey> I start to modify your code to satisfy above demands, but
>>>Andrey> firstly I wish to know your, or somebody else, opinion.
>>>
>>>I honestly don't think the majority of your demands are valid.
>>>genalloc was meant to be simple, not an ultra fast at any random
>>>block size allocator. So far I don't see any reason for changing to
>>>the allocation algorithm into anything much more complex - doesn't
>>>mean there couldn't be a reason for doing so, but I don't think you
>>>have described any so far.
>>
>>I disagree here, generic couldn't be very simple and slow, because in
>>this case simply no one will be use it, and hence we'll get today's
>>picture: reimplemented allocators in many drivers.
>>
>>
>>>You mentioned frame buffers, but what is the kernel supposed to do
>>>with those allocation wise? If you have a frame buffer console, the
>>>memory is allocated once and handed to the frame buffer driver.
>>>Ie. you don't need a ton of on demand allocations for that and for
>>>X, the memory management is handled in the X server, not by the
>>>kernel.
>>
>>For video-only device this is true, but if device is a multifunctional,
>>which is frequent case in embedded systems, then kernel must control of
>>device memory allocation. Currently, however, even video cards for
>>desktops become more and more multifunctional (VIVO/audio etc.).
>>
>>
>>>The only thing I think would make sense to implement is to allow it to
>>>use indirect descriptor blocks for the memory it manages. This is not
>>>because it's wrong to use the memory for the free list, as it will
>>>only be used for this when the chunk is not in use, but because access
>>>to certain types of memory isn't always valid through normal direct
>>>access. Ie. if one used descriptor blocks residing in normal
>>>GFP_KERNEL memory, it would be possible to use the allocator to manage
>>>memory sitting on the other side of a PCI bus.
>>
>>I describe above, why we couldn't/wouldn't use onboard memory for
>>allocator specific data.
>>
>>Pantelis, Am I answered to your question (...what are you trying to
>>do...) too?
>>
>
>
> Yes. rheap seems to cover your cases...
>
Agree, I couldn't see nothing better for a basement of generic dev. alloc.
So, it will be much better if it will be moved to lib/.
Anyone have some more comments about subj. ?
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-23 7:46 UTC (permalink / raw)
To: Andrey Volkov
Cc: Andrew Morton, Jes Sorensen, linuxppc-embedded, linux-kernel
In-Reply-To: <43ABA972.4080701@varma-el.com>
>
[snip]
>
> Agree, I couldn't see nothing better for a basement of generic dev. alloc.
>
> So, it will be much better if it will be moved to lib/.
>
> Anyone have some more comments about subj. ?
>
Sure, but the call has to be made be a core developer.
Andrew?
Regards
Pantelis
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-23 10:17 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Andrew Morton, Jes Sorensen, linuxppc-embedded, linux-kernel
In-Reply-To: <43ABAB69.4060703@intracom.gr>
Pantelis Antoniou wrote:
>>
>
> [snip]
>
>>
>> Agree, I couldn't see nothing better for a basement of generic dev.
>> alloc.
>>
>> So, it will be much better if it will be moved to lib/.
>>
>> Anyone have some more comments about subj. ?
>>
>
> Sure, but the call has to be made be a core developer.
>
> Andrew?
Pantelis, what did you think about renaming rheap.c and rh_xxx, to
something like dev_xxx, since, for example, rh_alloc overlapped with
__rh_alloc (__RegionHach__alloc) in the drivers/md/dm-raid1.c.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Jes Sorensen @ 2005-12-23 10:59 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <43AAEE12.5030009@varma-el.com>
>>>>> "Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
Andrey> Hi Jes,
Andrey> Jes Sorensen wrote:
>> This really is irrelevant, the space is only used within the
>> object when it's on the free list. Ie. if all memory is handed out
>> there's no space used for this purpose.
Andrey> I point out 2 reasons: ACCESS TIME was first :), let take very
Andrey> widespread case: PCI device with some onboard memory and any N
Andrey> GHz proc. - result may be terrible: each access to device mem
Andrey> (which usually uncached) will slowed down this super fast proc
Andrey> to 33 MHZ, i.e same as we made busy-wait with disabled
Andrey> interrupts after each read/write...
Andrey,
As I said in my response, you need the control blocks because you are
not allowed to directly access things on the other side of the PCI bus
without using the readl/writel equivalent macros. It's got nothing to
do with access speed.
>> For the case of more traditional devices, the control structures
>> will be allocated from one end of the block, the rest will be used
>> for packet descriptors which will be going in and out of the memory
>> pool on a regular basis.
Andrey> This was main reason why I try to modify genalloc: I needed in
Andrey> generic allocator for both short-live strictly aligned blocks
Andrey> and long-live blocks with restriction by size.
genalloc is perfectly adequate for that purpose. The long lived
allocations will just be taken out first, the rest will be used for
the short lived.
>> In most normal cases these will all be of the same size and it
>> doesn't matter where in the memory space they were allocated.
Andrey> And thats also why I consider that 'buddy' is not appropriate
Andrey> to be 'generic' (most cases == generic, isn't is :)?): when
Andrey> you're allocate mainly same sized blocks, 'buddy' degraded to
Andrey> the first-fit.
huh?
>> I honestly don't think the majority of your demands are valid.
>> genalloc was meant to be simple, not an ultra fast at any random
>> block size allocator. So far I don't see any reason for changing to
>> the allocation algorithm into anything much more complex - doesn't
>> mean there couldn't be a reason for doing so, but I don't think you
>> have described any so far.
Andrey> I disagree here, generic couldn't be very simple and slow,
Andrey> because in this case simply no one will be use it, and hence
Andrey> we'll get today's picture: reimplemented allocators in many
Andrey> drivers.
Of course it can. I will continue to claim that you are trying to turn
it into something it doesn't need to be. The allocator I used was
based on the allocator from the old sym2 driver, which is a perfect
example of it being used by a device driver.
>> You mentioned frame buffers, but what is the kernel supposed to do
>> with those allocation wise? If you have a frame buffer console, the
>> memory is allocated once and handed to the frame buffer driver.
>> Ie. you don't need a ton of on demand allocations for that and for
>> X, the memory management is handled in the X server, not by the
>> kernel.
Andrey> For video-only device this is true, but if device is a
Andrey> multifunctional, which is frequent case in embedded systems,
Andrey> then kernel must control of device memory
Andrey> allocation. Currently, however, even video cards for desktops
Andrey> become more and more multifunctional (VIVO/audio etc.).
For multi functional devices you still often split the memory up at
init time. Some memory is never going to be given back (like the frame
buffer itself), other blocks are like the network packet descriptors
in a network device.
>> The only thing I think would make sense to implement is to allow
>> it to use indirect descriptor blocks for the memory it
>> manages. This is not because it's wrong to use the memory for the
>> free list, as it will only be used for this when the chunk is not
>> in use, but because access to certain types of memory isn't always
>> valid through normal direct access. Ie. if one used descriptor
>> blocks residing in normal GFP_KERNEL memory, it would be possible
>> to use the allocator to manage memory sitting on the other side of
>> a PCI bus.
Andrey> I describe above, why we couldn't/wouldn't use onboard memory
Andrey> for allocator specific data.
As I pointed out, your description wasn't valid. You are not allowed
to directly dereference memory on the other side of a PCI bus.
Regards,
Jes
^ permalink raw reply
* Compilation Error
From: Prabhat_Singh @ 2005-12-23 11:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Prabhat_Singh
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
Hi all,
I am building linux-2.4.32 kernel using ELDK tool for
MPC8248(MPC8272 family) based target board. After configuring kernel as
follow:
1)Make xconfig ARCH=ppc
Platform support:MPC8260 CPM support -y
MPC8272 family Support -y
Machine type : ADS8272
And after saving configuration ..
2)Make dep ARCH=ppc
3)Make bzImage ARCH=ppc
Now I am getting error like this..............
************************************************************************
**************************************
m /home/sibi/vpnporting/linux-2.4.32/include/linux/blk.h:4,
from m8260_setup.c:31:
/home/sibi/vpnporting/linux-2.4.32/include/asm/mpc8260.h:32:1: warning:
"PCI_DRAM_OFFSET" redefined
In file included from
/home/sibi/vpnporting/linux-2.4.32/include/asm/mpc8260.h:24,
from
/home/sibi/vpnporting/linux-2.4.32/include/asm/io.h:31,
from
/home/sibi/vpnporting/linux-2.4.32/include/linux/blkdev.h:11,
from
/home/sibi/vpnporting/linux-2.4.32/include/linux/blk.h:4,
from m8260_setup.c:31:
/home/sibi/vpnporting/linux-2.4.32/arch/ppc/platforms/pq2ads.h:85:1:
warning: this is the location of the previous
definitionm8260_setup.c:68: warning: `abort' was declared `extern' and
later `static'
m8260_setup.c: In function `abort':
m8260_setup.c:70: error: conflicting types for `xmon'
/home/sibi/vpnporting/linux-2.4.32/include/asm/system.h:49: error:
previous declaration of `xmon'
m8260_setup.c:70: warning: extern declaration of `xmon' doesn't match
global one
m8260_setup.c: In function `m8260_restart':
m8260_setup.c:129: warning: passing arg 1 of `m8260_gorom' makes pointer
from integer without a cast
m8260_setup.c: In function `m8260_show_percpuinfo':
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 3)
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 4)
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 5)
m8260_setup.c: At top level:
m8260_setup.c:68: warning: `abort' defined but not used
make[1]: *** [m8260_setup.o] Error 1
make[1]: Leaving directory
`/home/sibi/vpnporting/linux-2.4.32/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Error 2
If anyone encountered this type of problem please through light on this.
Thanks in advance
Thanks & Regards
Prabhat Singh
SE
Satyam Computer Services Ltd.
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
[-- Attachment #2: Type: text/html, Size: 12025 bytes --]
^ permalink raw reply
* Modifying u-boot
From: Mustafa Çayır @ 2005-12-23 14:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
hi,
Could you give me advice where i can start to modify u-boot for MVME6100 board?
Regards
Mustafa Çayır
[-- Attachment #2: Type: text/html, Size: 661 bytes --]
^ permalink raw reply
* Re: Modifying u-boot
From: Grant Likely @ 2005-12-23 15:23 UTC (permalink / raw)
To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <003c01c607d0$eab72160$9e01120a@bilisim.local>
Mustafa Çayır wrote:
> hi,
>
> Could you give me advice where i can start to modify u-boot for MVME6100
> board?
http://www.denx.de/wiki/DULG/Manual
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Benjamin Herrenschmidt @ 2005-12-23 23:59 UTC (permalink / raw)
To: Michael Hanselmann
Cc: Parag Warudkar, linux-kernel, linuxppc-dev, debian-powerpc
In-Reply-To: <20051204224221.GA28218@hansmi.ch>
Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
latest patch you posted, and while the kernel driver seem to work ok
(though you can feel the lack of a proper acceleration curve), the
synaptics driver in X doesn't work in any useable way. I updated the one
that comes with breezy to whatever was the latest on the author web site
(.44 I think) and while it detected the tracpkad, the result was soooooo
slooooow that it was totally unseable. I've tried the config tool that
comes with KDE for it but couldn't "boost" it to anything useful. Is
that expected or is there still issues to be resolved in the driver ?
I'm tempted to add some minimum support for a proper acceleration curve
in the kernel driver in fact...
Ben.
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: René Nussbaumer @ 2005-12-24 11:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <1135382385.4542.8.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hello
On Sat, Dec 24, 2005 at 10:59:44AM +1100, Benjamin Herrenschmidt wrote:
[...]
> comes with KDE for it but couldn't "boost" it to anything useful. Is
> that expected or is there still issues to be resolved in the driver ?
> I'm tempted to add some minimum support for a proper acceleration curve
> in the kernel driver in fact...
I'd the same problem. A quick look into Xorg.0.log tells me, that the
event device was missing. I created it manually and the acceleration and
other feautres are working now. Maybe you've still the same problem?
René
--
Written on a Gentoo Linux-system by René
http://www.forkbomb.ch
«Das Leben ist hart. Forkbomb ist härter.», (c) 2004 by Frank.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Pavel Machek @ 2005-12-24 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <1135382385.4542.8.camel@gaston>
Hi!
> Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> latest patch you posted, and while the kernel driver seem to work ok
> (though you can feel the lack of a proper acceleration curve), the
> synaptics driver in X doesn't work in any useable way. I updated the one
> that comes with breezy to whatever was the latest on the author web site
> (.44 I think) and while it detected the tracpkad, the result was soooooo
> slooooow that it was totally unseable. I've tried the config tool that
> comes with KDE for it but couldn't "boost" it to anything useful. Is
> that expected or is there still issues to be resolved in the driver ?
> I'm tempted to add some minimum support for a proper acceleration curve
> in the kernel driver in fact...
I do not think you should add it inside *kernel*. Proper acceleration
support really belongs to X...
Pavel
--
Thanks, Sharp!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox