Hello Borislav,
Thursday, May 17, 2007, 2:25:54 PM, you wrote:
> -
> From: [EMAIL PROTECTED]
> A very small size (object file 432 bytes smaller) and readability
> optimization of ide.c
And how these "optimizations" fit with BUG_ON() purpose - to
be able to easily identify cause and
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
> Robin Getz <[EMAIL PROTECTED]> wrote:
>> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>>> > th
Hello ian,
Saturday, May 5, 2007, 4:46:26 PM, you wrote:
> On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:
>> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
>> control signaling over the USB bus for power-control purposes),
> it might be dumb, but it
Hello Anton,
Saturday, May 5, 2007, 3:32:30 PM, you wrote:
> Hello Henrique, Shem,
> On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
>> On Fri, 04 May 2007, Shem Multinymous wrote:
>> > >+enum power_supply_type {
>> > >+ POWER_SUPPLY_TYPE_BATTERY = 0,
>> > >+
Hello Greg,
Friday, May 4, 2007, 2:14:59 AM, you wrote:
> On Fri, May 04, 2007 at 01:31:21AM +0400, Anton Vorontsov wrote:
>> This function were placed in "#if 0" because nobody was using it.
>> We using it now.
> Why? Shouldn't you just export the pointer you need instead?
>> See http://lwn.n
Hello Dmitry,
Wednesday, May 2, 2007, 12:17:33 AM, you wrote:
> Hello Paul,
> Paul Sokolovsky wrote:
>>> ASIC-related code (I mean core) forms additional platform layer, so I
>>> suggest
>>> adding ASIC helpers to generic platform code i.e. drivers/platform.c
Hello Dmitry,
Tuesday, May 1, 2007, 10:08:23 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
>>> If you used ASIC acronym it would be more appropriate and not so
>>> ambiguous.
>>
>> Actually, thats not bad. I'd be ok with that is SoC isnt used.
>>
>
Hello Richard,
Tuesday, May 1, 2007, 6:01:15 PM, you wrote:
> On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote:
>> Either way, I don't pledge to be a HW designer with
>> contemporary lexicon. The aim was simple - as a single word would be
>> too ambiguo
Hello Dmitry,
Tuesday, May 1, 2007, 7:38:44 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
>>> Hi Paul,
>>
>>> I think your referring to the term "SoC (system-on-chip)" is confusing
>>> (at least for me). You rather consider companion chips than SoCs.
Hello Dmitry,
Tuesday, May 1, 2007, 4:53:09 PM, you wrote:
> Hi Paul,
> Paul Sokolovsky wrote:
>> In contemporary systems, lots of functionality oftentimes handled by various
>> kinds of SoCs (system-on-chip), representing a number of deversified
>> controllers packaged
Hello Alan,
Tuesday, May 1, 2007, 1:27:51 PM, you wrote:
>> > + * Copyright 2001 Compaq Computer Corporation.
>> > + *
>> > + * Use consistent with the GNU GPL is permitted,
>> > + * provided that this copyright notice is
>> > + * preserved in its entirety in all copies and derived works.
>> > +
Hello Ben,
Tuesday, May 1, 2007, 11:39:00 AM, you wrote:
> On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote:
[]
>> Initial implementation from few years ago registered per-SoC bus
>> for the purpose of attaching subdevices, but during LKML reviews it
>>
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
drivers/soc/Kconfig| 22 +
drivers/soc/Ma
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h
Hello linux-kernel,
In contemporary systems, lots of functionality oftentimes handled by various
kinds of SoCs (system-on-chip), representing a number of deversified
controllers packaged in one chip. Handling them is arguably an ongoing
problem, as diversity and number of devices included make i
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c
: Paul Sokolovsky <[EMAIL PROTECTED]>
include/asm-arm/hardware/ipaq-asic3.h | 609 +
1 files changed, 609 insertions(+), 0 deletions(-)
diff --git a/include/asm-arm/hardware/ipaq-asic3.h
b/include/asm-arm/hardware/ipaq-asic3.h
new file mode 100644
index 0
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>> >> > So, talking about what an (optional) implementation framework might
>> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
>> >> > I've looked at):
>>
>> > See patches in following messages ... a prelimina
Hello David,
Sunday, April 15, 2007, 10:47:57 PM, you wrote:
> On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
>> Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
>> > So, talking about what an (optional) implementation framework might
>> > look like (and
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
> On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
>> +static void (*old_apm_get_power_status)(struct apm_power_info*);
>> +
>> +static int __init apm_battery_init(void)
>> +{
>> + printk(KERN_INFO "APM Battery Dri
Hello Matthew,
Thursday, April 12, 2007, 5:24:30 PM, you wrote:
> On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote:
>> On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote:
>> > ACPI batteries can report capacity and rate in either mA or mW. Given
>>
>> You sure, capaci
Hello Juergen,
Wednesday, April 11, 2007, 9:47:01 AM, you wrote:
> Am Dienstag, 10. April 2007 23:30 schrieb Paul Sokolovsky:
>> Hello linux-arm-kernel,
>>
>> GPIODEV API: Core API definitions. Provided are:
>> 1. struct gpiodev_ops which must be included into plat
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
> On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>>
>> > /* defined by the platform using array, if/else/..., IDR, or
>> > whatever */
>> > struct gpio_yyy *gpio_to_yy
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
> it looks ok, but I have several questions:
> 1. why should we bind this to platform_device, what if the gpio device
> is not actually a "platform_device", say, a I2C device, a SPI device or
> even a USB device?
Good point. That w
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
> On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
>> > Nobody who really wants to have such an implementation framework has yet
>> > ponied up and done the work to make one.
>>
>> Well, sorr
-type=text/plain&f=h
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: include/linux/soc/asic3_base.h
===
RCS file: include/linux/soc/asic3_base.h
diff -N include/linux/soc/asic3_base.h
--- /dev/null 1 Jan 197
pproach is
followed for GPIODEV too.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: arch/arm/mach-pxa/generic.c
===
RCS file: /cvs/linux/kernel26/arch/arm/mach-pxa/generic.c,v
retrieving revision 1.39
retrieving revis
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO identifier
Hello Kernel lists,
This is updated and reworked API previously proposed at
http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback
(suggestions to use established kernel terminology/naming convention
and drop macros). There are also actual tested patches provided this
time, no
Hello H.,
Wednesday, March 28, 2007, 7:32:57 PM, you wrote:
> Paul Sokolovsky wrote:
>>
>> In this respect, VTABLE(), METHOD() macros serve the same purpose as
>> container_of() and list_for_each() - they are besides offering (more)
>> convenient syntax, also carr
Hello LKML,
We, HandHelds.org, for quite some time are working on generilized support
for consumer handheld devices (with primary focus on ARM-based PocketPC's
ans smartphones). While we made big progress in many areas, we still
were no able to put all the part of riddle together, producing clean
Hello NZG,
Tuesday, March 6, 2007, 8:46:29 PM, you wrote:
> I'm developing an SPI- bus >MMC/SD block driver translation layer.
> As part of this layer the write protect and card detect lines need to be read.
> The method for determining the state of these lines will be board specific.
> Is it ap
Hello Rodolfo,
Thursday, February 22, 2007, 10:32:04 AM, you wrote:
> On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote:
k>> Why? It's the same, except that it already exists, generic one (not
>> limited to pxafb), and requires 1 function (too bad that
Hello Rodolfo,
Wednesday, February 21, 2007, 6:12:10 PM, you wrote:
> On Wed, Feb 21, 2007 at 06:00:37PM +0200, Paul Sokolovsky wrote:
>>
>> On the other hand, there's already
>> drivers/video/backlight/backlight.c which provides generic BL support,
>> impleme
Hello Rodolfo,
Wednesday, February 21, 2007, 6:02:13 PM, you wrote:
> Hello,
> I'd like to add backlight support for input devices since my custom
> board has a backlighted mini keyboard.
There's already generic indicator API, currently mostly known as
"[new] LED [classdev] API", even though
Hello Rodolfo,
Wednesday, February 21, 2007, 4:53:53 PM, you wrote:
> Backlight control support for the PXA fram buffer.
Here're some comments: backlight support is already confusing
matter, and your patch IMHO makes it even more confusing for PXAFB.
Before even start with details, let's f
Hello David,
Tuesday, December 19, 2006, 2:59:11 AM, you wrote:
> On Monday 18 December 2006 4:54 pm, David Brownell wrote:
>> > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5&r2=1.6&f=h
>>
>> That patch you applied looks right to me -- why don't you
Hello David,
Monday, December 18, 2006, 6:28:58 AM, you wrote:
> On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote:
>> Small battery-powered systems, like PDAs, need a way to be
>> suspended most of the time and woken up just from time to time to
>>
he
patch below is initial try to implement it.
Formal part
===
Implement "alarm" attribute group for RTC classdevs. At this time,
add "since_epoch", "wakeup_enabled", and "pending" attributes. First
two support both read and write.
Hello linux-kernel,
Well, this was (at least) since 2.6.18, so I guess, someone
should finally submit it patch for it. And yes, kbuild parses that,
but that doesn't make it not typo, right?
--- drivers/rtc/Kconfig 2 Dec 2006 02:18:35 - 1.3
+++ drivers/rtc/Kconfig 17 Dec 2006 18:
Hello Lennert,
Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
[]
> (These
> days I build all kernels in EABI mode with old-ABI compat.) I have
> not run into any code generation issues with this compiler yet.
I wonder, if OABI-compat is known to actually work on OABI userspace,
I mean, o
.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/ne
Hello Jiri,
Monday, November 20, 2006, 1:45:51 AM, you wrote:
> Paul Sokolovsky wrote:
>> But alas, the commit message is not as good as some others are, and
>> doesn't mention what should be used instead. So, if find_bus() is
>> "unused", what should be
Hello linux-kernel,
We here at Handhelds.org upgrading our drivers to 2.6.18 and I just
caught a case of find_bus() being undefined during link. Quickly
traced this to
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5
44 matches
Mail list logo
