On Wed, Feb 21, 2007 at 10:16:45AM +, Pavel Machek wrote:
Hi!
@@ -0,0 +1,206 @@
+
+ PPS - Pulse Per Second
+ --
+
+(C) Copyright 2007 Rodolfo Giometti [EMAIL PROTECTED]
If you add copyright, add license, too.
Ok
On Thu, Feb 22, 2007 at 12:33:35PM +0200, Paul Sokolovsky wrote:
We in handhelds.org codebase have attached patch* to make corgi_bl
more suitable for general use. This patch was submitted to Richard
(so, more votes needed ;-) ). Otherwise, snippet I pasted is from real
machine
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,
> implemented using notifier callback for FB core. Moreover, there's
My patch _uses_ that support.
> corgi_bl.c
Hello,
I'd like to add backlight support for input devices since my custom
board has a backlighted mini keyboard.
It could be acceptable to move the code from drivers/video/backlight/
to drivers/backlight/ renaming the "Backlight & LCD" name into
"Backlight" and adding two new entries "LCD" and,
Backlight control support for the PXA fram buffer.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
Each platform should define the backlight properties in its own setup
file in "linux/arch/arm/mach-pxa/" as follow:
static int pxafb_bl_get_brightness(struct backligh
On Mon, Feb 19, 2007 at 06:56:20PM -0800, H. Peter Anvin wrote:
> It's not a precondition for a file descriptor, either. There are plenty
> of ioctl-only device drivers in existence.
>
> Furthermore, a file descriptor doesn't imply a device entry. Consider
> pipe(2), for example.
>
> As far
On Mon, Feb 19, 2007 at 06:56:20PM -0800, H. Peter Anvin wrote:
It's not a precondition for a file descriptor, either. There are plenty
of ioctl-only device drivers in existence.
Furthermore, a file descriptor doesn't imply a device entry. Consider
pipe(2), for example.
As far as the
Backlight control support for the PXA fram buffer.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
Each platform should define the backlight properties in its own setup
file in linux/arch/arm/mach-pxa/ as follow:
static int pxafb_bl_get_brightness(struct backlight_device *bl_dev
Hello,
I'd like to add backlight support for input devices since my custom
board has a backlighted mini keyboard.
It could be acceptable to move the code from drivers/video/backlight/
to drivers/backlight/ renaming the Backlight LCD name into
Backlight and adding two new entries LCD and, maybe,
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,
implemented using notifier callback for FB core. Moreover, there's
My patch _uses_ that support.
corgi_bl.c driver
Hello,
I noticed that backlight support for this device is provided by the
pxafb_backlight_power() function which allows to turn on and off the
backlight. On the other hand I notice also the backlight driver
support which allows several configurations on a specific backlight.
It could be
Hello,
I noticed that backlight support for this device is provided by the
pxafb_backlight_power() function which allows to turn on and off the
backlight. On the other hand I notice also the backlight driver
support which allows several configurations on a specific backlight.
It could be
On Fri, Feb 16, 2007 at 08:51:35PM +, Russell King wrote:
>
> You can't because it doesn't go through the interfaces you're hooking
> into. Existing interfaces are "changed" to point at the UARTs using
> setserial, which does its work via an ioctl.
I see.
> Not specifically only userland -
On Fri, Feb 16, 2007 at 08:56:18PM +0100, Jan Dittmer wrote:
> Drop the linux prefix. It's in the linux kernel after all.
Ok.
> > +PROCFS support
> > +--
>
> New features shouldn't introduce new /proc stuff.
It's a must? I can leave procfs for backward compatibility with old
On Fri, Feb 16, 2007 at 07:12:08PM +, Russell King wrote:
>
> Yuck. Please. No. Doing it this way means you have to modify every
> single serial driver out there which is a mamouth task.
>
> > uart_handle_dcd_change(>port, status &
> > UART_MSR_DCD);
>
> Did you not
On Fri, Feb 16, 2007 at 07:12:08PM +, Russell King wrote:
Yuck. Please. No. Doing it this way means you have to modify every
single serial driver out there which is a mamouth task.
uart_handle_dcd_change(up-port, status
UART_MSR_DCD);
Did you not look to
On Fri, Feb 16, 2007 at 08:56:18PM +0100, Jan Dittmer wrote:
Drop the linux prefix. It's in the linux kernel after all.
Ok.
+PROCFS support
+--
New features shouldn't introduce new /proc stuff.
It's a must? I can leave procfs for backward compatibility with old
utilities?
On Fri, Feb 16, 2007 at 08:51:35PM +, Russell King wrote:
You can't because it doesn't go through the interfaces you're hooking
into. Existing interfaces are changed to point at the UARTs using
setserial, which does its work via an ioctl.
I see.
Not specifically only userland - if it
On Tue, Feb 13, 2007 at 06:22:01PM +, James Simmons wrote:
>
> The reason you have a cursor is because you are using the framebuffer
> console. Do you need fbcon ?
Yes. During the system update process on in the production stage a
console is very useful.
Ciao,
Rodolfo
--
GNU/Linux
On Tue, Feb 13, 2007 at 06:22:01PM +, James Simmons wrote:
The reason you have a cursor is because you are using the framebuffer
console. Do you need fbcon ?
Yes. During the system update process on in the production stage a
console is very useful.
Ciao,
Rodolfo
--
GNU/Linux
On Tue, Feb 13, 2007 at 05:48:29PM +, Russell King wrote:
>
> Maybe this should be a generic option? Or maybe issue ESC [ 25 l
> to disable the cursor if you're wanting to turn it off from userspace.
This is useful if you have a full screen boot logo. How I can issue
ESC [ 25 l at boot
Add cursor enable/disable, very useful if you wish a full screen boot
logo.
Cursor can be disabled from kernel command line:
video=pxafb:nocursor
or from sysfs interface:
echo 1 > /sys/module/pxafb/parameters/nocursor
Signed-off-by: Rodolfo Giometti <[EMAIL PRO
Add cursor enable/disable, very useful if you wish a full screen boot
logo.
Cursor can be disabled from kernel command line:
video=pxafb:nocursor
or from sysfs interface:
echo 1 /sys/module/pxafb/parameters/nocursor
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED
On Tue, Feb 13, 2007 at 05:48:29PM +, Russell King wrote:
Maybe this should be a generic option? Or maybe issue ESC [ 25 l
to disable the cursor if you're wanting to turn it off from userspace.
This is useful if you have a full screen boot logo. How I can issue
ESC [ 25 l at boot time?
APM-EMULATION: apm_get_power_status() should be NULL on init.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
If the function apm_get_info() do like this:
static int apm_get_info(char *buf, char **start, off_t fpos, int length)
{
struct apm_power_inf
ARM: Convert to use shared "Device Drivers" menu.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6783c2e..a2ca665 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -885,84 +885,7 @@ endmenu
source "net/Kco
ARM: Convert to use shared Device Drivers menu.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6783c2e..a2ca665 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -885,84 +885,7 @@ endmenu
source net/Kconfig
-menu Device Drivers
APM-EMULATION: apm_get_power_status() should be NULL on init.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
If the function apm_get_info() do like this:
static int apm_get_info(char *buf, char **start, off_t fpos, int length)
{
struct apm_power_info info
On Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote:
> However, it has since been reposted:
>
> http://article.gmane.org/gmane.linux.kernel/485833
> http://article.gmane.org/gmane.linux.kernel/485834
> http://article.gmane.org/gmane.linux.kernel/485835
>
On Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote:
However, it has since been reposted:
http://article.gmane.org/gmane.linux.kernel/485833
http://article.gmane.org/gmane.linux.kernel/485834
http://article.gmane.org/gmane.linux.kernel/485835
From: Rodolfo Giometti <[EMAIL PROTECTED]>
Patch to add support for Taos TSL2550 ambient light sensors.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 87ee3ce..18e60ec 100644
--- a/drivers/i2c/chips/K
On Mon, Jan 29, 2007 at 06:39:50PM -0800, Andrew Morton wrote:
> > +/* Insmod parameters */
> > +I2C_CLIENT_INSMOD_1(tsl2550);
> > +
> > +static int operating_mode = 0;
>
> The `= 0' is unneeded and undesirable.
Fixed.
> > ...
> >
> > +static int tsl2550_get_adc_value(struct i2c_client
On Mon, Jan 29, 2007 at 06:39:50PM -0800, Andrew Morton wrote:
+/* Insmod parameters */
+I2C_CLIENT_INSMOD_1(tsl2550);
+
+static int operating_mode = 0;
The `= 0' is unneeded and undesirable.
Fixed.
...
+static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
From: Rodolfo Giometti [EMAIL PROTECTED]
Patch to add support for Taos TSL2550 ambient light sensors.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 87ee3ce..18e60ec 100644
--- a/drivers/i2c/chips/Kconfig
+++ b
On Mon, Jan 29, 2007 at 11:53:46PM +, Richard Purdie wrote:
> I'm not sure this is a good idea. As you're creating a new interface,
> why not create something new/improved without the problems that
> confining yourself to APM emulation brings?
Because several applications (and expecially in
for ambient light sensor
+ *
+ * Copyright (C) 2007 Rodolfo Giometti <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Eurotech S.p.A. <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License
Hello,
some months ago I sent to the MIPS and ARM mail lists a patch to unify
the several APM emulation codes adding a new dedicated directory so it
can be used to put there the per board specific code avoiding code
duplications (see files ./arch/arm/kernel/apm.c,
./arch/mips/kernel/apm.c and
Hello,
some months ago I sent to the MIPS and ARM mail lists a patch to unify
the several APM emulation codes adding a new dedicated directory so it
can be used to put there the per board specific code avoiding code
duplications (see files ./arch/arm/kernel/apm.c,
./arch/mips/kernel/apm.c and
sensor
+ *
+ * Copyright (C) 2007 Rodolfo Giometti [EMAIL PROTECTED]
+ * Copyright (C) 2007 Eurotech S.p.A. [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software
On Mon, Jan 29, 2007 at 11:53:46PM +, Richard Purdie wrote:
I'm not sure this is a good idea. As you're creating a new interface,
why not create something new/improved without the problems that
confining yourself to APM emulation brings?
Because several applications (and expecially in
401 - 440 of 440 matches
Mail list logo
