[patch] ucb1x00: touchscreen cleanups

[patch] ucb1x00: touchscreen cleanups

[Pavel Machek]

These are small ucb1x00-ts cleanups, as suggested by Vojtech, Dmitri
and the lists.

Signed-off-by: Pavel Machek <pavel@suse.cz>

Cleanups suggested by Dmitri, Vojtech and lists.

---
commit 79c98a2279c45098d102ba69ecf940c00da3dfee
tree f15a3d27de9a84694f4588374a5e383938866a54
parent 080578bff89927c0f5aeddd588bc2f5f7373f232
author <pavel@amd.(none)> Tue, 26 Jul 2005 09:44:33 +0200
committer <pavel@amd.(none)> Tue, 26 Jul 2005 09:44:33 +0200

 drivers/misc/ucb1x00-ts.c |   87 ++++++++++++---------------------------------
 1 files changed, 23 insertions(+), 64 deletions(-)

diff --git a/drivers/misc/ucb1x00-ts.c b/drivers/misc/ucb1x00-ts.c
--- a/drivers/misc/ucb1x00-ts.c
+++ b/drivers/misc/ucb1x00-ts.c
@@ -1,7 +1,8 @@
 /*
- *  linux/drivers/misc/ucb1x00-ts.c
+ *  Touchscreen driver for UCB1x00-based touchscreens
  *
  *  Copyright (C) 2001 Russell King, All Rights Reserved.
+ *  Copyright (C) 2005 Pavel Machek
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -30,6 +31,7 @@
 #include <linux/device.h>
 #include <linux/suspend.h>
 #include <linux/slab.h>
+#include <linux/kthread.h>
 
 #include <asm/dma.h>
 #include <asm/semaphore.h>
@@ -42,10 +44,7 @@ struct ucb1x00_ts {
 	struct ucb1x00		*ucb;
 
 	wait_queue_head_t	irq_wait;
-	struct semaphore	sem;
-	struct completion	init_exit;
 	struct task_struct	*rtask;
-	int			use_count;
 	u16			x_res;
 	u16			y_res;
 
@@ -55,20 +54,6 @@ struct ucb1x00_ts {
 
 static int adcsync;
 
-static inline void ucb1x00_ts_evt_add(struct ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
-{
-	input_report_abs(&ts->idev, ABS_X, x);
-	input_report_abs(&ts->idev, ABS_Y, y);
-	input_report_abs(&ts->idev, ABS_PRESSURE, pressure);
-	input_sync(&ts->idev);
-}
-
-static inline void ucb1x00_ts_event_release(struct ucb1x00_ts *ts)
-{
-	input_report_abs(&ts->idev, ABS_PRESSURE, 0);
-	input_sync(&ts->idev);
-}
-
 /*
  * Switch to interrupt mode.
  */
@@ -176,12 +161,6 @@ static int ucb1x00_thread(void *_ts)
 	DECLARE_WAITQUEUE(wait, tsk);
 	int valid;
 
-	ts->rtask = tsk;
-
-	daemonize("ktsd");
-	/* only want to receive SIGKILL */
-	allow_signal(SIGKILL);
-
 	/*
 	 * We could run as a real-time thread.  However, thus far
 	 * this doesn't seem to be necessary.
@@ -189,12 +168,10 @@ static int ucb1x00_thread(void *_ts)
 //	tsk->policy = SCHED_FIFO;
 //	tsk->rt_priority = 1;
 
-	complete(&ts->init_exit);
-
 	valid = 0;
 
 	add_wait_queue(&ts->irq_wait, &wait);
-	for (;;) {
+	while (!kthread_should_stop()) {
 		unsigned int x, y, p, val;
 		signed long timeout;
 
@@ -212,10 +189,7 @@ static int ucb1x00_thread(void *_ts)
 		ucb1x00_ts_mode_int(ts);
 		ucb1x00_adc_disable(ts->ucb);
 
-		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
-		schedule_timeout(HZ / 100);
-		if (signal_pending(tsk))
-			break;
+		msleep(10);
 
 		ucb1x00_enable(ts->ucb);
 		val = ucb1x00_reg_read(ts->ucb, UCB_TS_CR);
@@ -231,7 +205,8 @@ static int ucb1x00_thread(void *_ts)
 			 * spit out a "pen off" sample here.
 			 */
 			if (valid) {
-				ucb1x00_ts_event_release(ts);
+				input_report_abs(&ts->idev, ABS_PRESSURE, 0);
+				input_sync(&ts->idev);
 				valid = 0;
 			}
 
@@ -245,7 +220,10 @@ static int ucb1x00_thread(void *_ts)
 			 * to do any filtering they please.
 			 */
 			if (!ts->restart) {
-				ucb1x00_ts_evt_add(ts, p, x, y);
+				input_report_abs(&ts->idev, ABS_X, x);
+				input_report_abs(&ts->idev, ABS_Y, y);
+				input_report_abs(&ts->idev, ABS_PRESSURE, p);
+				input_sync(&ts->idev);
 				valid = 1;
 			}
 
@@ -256,14 +234,12 @@ static int ucb1x00_thread(void *_ts)
 		try_to_freeze();
 
 		schedule_timeout(timeout);
-		if (signal_pending(tsk))
-			break;
 	}
 
 	remove_wait_queue(&ts->irq_wait, &wait);
 
 	ts->rtask = NULL;
-	complete_and_exit(&ts->init_exit, 0);
+	return 0;
 }
 
 /*
@@ -282,14 +258,7 @@ static int ucb1x00_ts_open(struct input_
 	struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
 	int ret = 0;
 
-	if (down_interruptible(&ts->sem))
-		return -EINTR;
-
-	if (ts->use_count++ != 0)
-		goto out;
-
-	if (ts->rtask)
-		panic("ucb1x00: rtask running?");
+	BUG_ON(ts->rtask);
 
 	init_waitqueue_head(&ts->irq_wait);
 	ret = ucb1x00_hook_irq(ts->ucb, UCB_IRQ_TSPX, ucb1x00_ts_irq, ts);
@@ -305,19 +274,16 @@ static int ucb1x00_ts_open(struct input_
 	ts->y_res = ucb1x00_ts_read_yres(ts);
 	ucb1x00_adc_disable(ts->ucb);
 
-	init_completion(&ts->init_exit);
-	ret = kernel_thread(ucb1x00_thread, ts, CLONE_KERNEL);
-	if (ret >= 0) {
-		wait_for_completion(&ts->init_exit);
+	ts->rtask = kthread_run(ucb1x00_thread, ts, "ktsd");
+	if (!IS_ERR(ts->rtask)) {
 		ret = 0;
 	} else {
 		ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
+		ts->rtask = NULL;
+		ret = -EFAULT;
 	}
 
  out:
-	if (ret)
-		ts->use_count--;
-	up(&ts->sem);
 	return ret;
 }
 
@@ -328,19 +294,13 @@ static void ucb1x00_ts_close(struct inpu
 {
 	struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
 
-	down(&ts->sem);
-	if (--ts->use_count == 0) {
-		if (ts->rtask) {
-			send_sig(SIGKILL, ts->rtask, 1);
-			wait_for_completion(&ts->init_exit);
-		}
+	if (ts->rtask)
+		kthread_stop(ts->rtask);
 
-		ucb1x00_enable(ts->ucb);
-		ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
-		ucb1x00_reg_write(ts->ucb, UCB_TS_CR, 0);
-		ucb1x00_disable(ts->ucb);
-	}
-	up(&ts->sem);
+	ucb1x00_enable(ts->ucb);
+	ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
+	ucb1x00_reg_write(ts->ucb, UCB_TS_CR, 0);
+	ucb1x00_disable(ts->ucb);
 }
 
 #ifdef CONFIG_PM
@@ -379,7 +339,6 @@ static int ucb1x00_ts_add(struct ucb1x00
 
 	ts->ucb = dev->ucb;
 	ts->adcsync = adcsync ? UCB_SYNC : UCB_NOSYNC;
-	init_MUTEX(&ts->sem);
 
 	ts->idev.name       = "Touchscreen panel";
 	ts->idev.id.product = ts->ucb->id;

-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [patch] ucb1x00: touchscreen cleanups

[Mark Underwood]

Hi Pavel,

I am in the process of porting Linux 2.6.11.5 to the
Helio PDA (MIPS R3912 based) and if I remember
correctly it is using a UCB1x00 (or Toshiba clone).
Please could you make sure your patches will work
across arch. Now I have my kernel up and running (well
mainly falling :-() my next task is to get write the
frame buffer driver and then look at the UCB1x00 as I
need it for sound and touch screen. So in a day or two
I will start to try to integrate your work into my
kernel.

Best Regards,

Mark

--- Pavel Machek <pavel@ucw.cz> wrote:

> These are small ucb1x00-ts cleanups, as suggested by
> Vojtech, Dmitri
> and the lists.
> 
> Signed-off-by: Pavel Machek <pavel@suse.cz>
> 
> Cleanups suggested by Dmitri, Vojtech and lists.
> 
> ---
> commit 79c98a2279c45098d102ba69ecf940c00da3dfee
> tree f15a3d27de9a84694f4588374a5e383938866a54
> parent 080578bff89927c0f5aeddd588bc2f5f7373f232
> author <pavel@amd.(none)> Tue, 26 Jul 2005 09:44:33
> +0200
> committer <pavel@amd.(none)> Tue, 26 Jul 2005
> 09:44:33 +0200
> 
>  drivers/misc/ucb1x00-ts.c |   87
> ++++++++++++---------------------------------
>  1 files changed, 23 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/misc/ucb1x00-ts.c
> b/drivers/misc/ucb1x00-ts.c
> --- a/drivers/misc/ucb1x00-ts.c
> +++ b/drivers/misc/ucb1x00-ts.c
> @@ -1,7 +1,8 @@
>  /*
> - *  linux/drivers/misc/ucb1x00-ts.c
> + *  Touchscreen driver for UCB1x00-based
> touchscreens
>   *
>   *  Copyright (C) 2001 Russell King, All Rights
> Reserved.
> + *  Copyright (C) 2005 Pavel Machek
>   *
>   * This program is free software; you can
> redistribute it and/or modify
>   * it under the terms of the GNU General Public
> License version 2 as
> @@ -30,6 +31,7 @@
>  #include <linux/device.h>
>  #include <linux/suspend.h>
>  #include <linux/slab.h>
> +#include <linux/kthread.h>
>  
>  #include <asm/dma.h>
>  #include <asm/semaphore.h>
> @@ -42,10 +44,7 @@ struct ucb1x00_ts {
>  	struct ucb1x00		*ucb;
>  
>  	wait_queue_head_t	irq_wait;
> -	struct semaphore	sem;
> -	struct completion	init_exit;
>  	struct task_struct	*rtask;
> -	int			use_count;
>  	u16			x_res;
>  	u16			y_res;
>  
> @@ -55,20 +54,6 @@ struct ucb1x00_ts {
>  
>  static int adcsync;
>  
> -static inline void ucb1x00_ts_evt_add(struct
> ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
> -{
> -	input_report_abs(&ts->idev, ABS_X, x);
> -	input_report_abs(&ts->idev, ABS_Y, y);
> -	input_report_abs(&ts->idev, ABS_PRESSURE,
> pressure);
> -	input_sync(&ts->idev);
> -}
> -
> -static inline void ucb1x00_ts_event_release(struct
> ucb1x00_ts *ts)
> -{
> -	input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> -	input_sync(&ts->idev);
> -}
> -
>  /*
>   * Switch to interrupt mode.
>   */
> @@ -176,12 +161,6 @@ static int ucb1x00_thread(void
> *_ts)
>  	DECLARE_WAITQUEUE(wait, tsk);
>  	int valid;
>  
> -	ts->rtask = tsk;
> -
> -	daemonize("ktsd");
> -	/* only want to receive SIGKILL */
> -	allow_signal(SIGKILL);
> -
>  	/*
>  	 * We could run as a real-time thread.  However,
> thus far
>  	 * this doesn't seem to be necessary.
> @@ -189,12 +168,10 @@ static int ucb1x00_thread(void
> *_ts)
>  //	tsk->policy = SCHED_FIFO;
>  //	tsk->rt_priority = 1;
>  
> -	complete(&ts->init_exit);
> -
>  	valid = 0;
>  
>  	add_wait_queue(&ts->irq_wait, &wait);
> -	for (;;) {
> +	while (!kthread_should_stop()) {
>  		unsigned int x, y, p, val;
>  		signed long timeout;
>  
> @@ -212,10 +189,7 @@ static int ucb1x00_thread(void
> *_ts)
>  		ucb1x00_ts_mode_int(ts);
>  		ucb1x00_adc_disable(ts->ucb);
>  
> -		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> -		schedule_timeout(HZ / 100);
> -		if (signal_pending(tsk))
> -			break;
> +		msleep(10);
>  
>  		ucb1x00_enable(ts->ucb);
>  		val = ucb1x00_reg_read(ts->ucb, UCB_TS_CR);
> @@ -231,7 +205,8 @@ static int ucb1x00_thread(void
> *_ts)
>  			 * spit out a "pen off" sample here.
>  			 */
>  			if (valid) {
> -				ucb1x00_ts_event_release(ts);
> +				input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> +				input_sync(&ts->idev);
>  				valid = 0;
>  			}
>  
> @@ -245,7 +220,10 @@ static int ucb1x00_thread(void
> *_ts)
>  			 * to do any filtering they please.
>  			 */
>  			if (!ts->restart) {
> -				ucb1x00_ts_evt_add(ts, p, x, y);
> +				input_report_abs(&ts->idev, ABS_X, x);
> +				input_report_abs(&ts->idev, ABS_Y, y);
> +				input_report_abs(&ts->idev, ABS_PRESSURE, p);
> +				input_sync(&ts->idev);
>  				valid = 1;
>  			}
>  
> @@ -256,14 +234,12 @@ static int ucb1x00_thread(void
> *_ts)
>  		try_to_freeze();
>  
>  		schedule_timeout(timeout);
> -		if (signal_pending(tsk))
> -			break;
>  	}
>  
>  	remove_wait_queue(&ts->irq_wait, &wait);
>  
>  	ts->rtask = NULL;
> -	complete_and_exit(&ts->init_exit, 0);
> +	return 0;
>  }
>  
>  /*
> @@ -282,14 +258,7 @@ static int
> ucb1x00_ts_open(struct input_
>  	struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
>  	int ret = 0;
>  
> -	if (down_interruptible(&ts->sem))
> -		return -EINTR;
> -
> -	if (ts->use_count++ != 0)
> -		goto out;
> -
> -	if (ts->rtask)
> -		panic("ucb1x00: rtask running?");
> +	BUG_ON(ts->rtask);
>  
>  	init_waitqueue_head(&ts->irq_wait);
>  	ret = ucb1x00_hook_irq(ts->ucb, UCB_IRQ_TSPX,
> ucb1x00_ts_irq, ts);
> @@ -305,19 +274,16 @@ static int
> ucb1x00_ts_open(struct input_
>  	ts->y_res = ucb1x00_ts_read_yres(ts);
>  	ucb1x00_adc_disable(ts->ucb);
>  
> -	init_completion(&ts->init_exit);
> -	ret = kernel_thread(ucb1x00_thread, ts,
> CLONE_KERNEL);
> -	if (ret >= 0) {
> -		wait_for_completion(&ts->init_exit);
> +	ts->rtask = kthread_run(ucb1x00_thread, ts,
> "ktsd");
> +	if (!IS_ERR(ts->rtask)) {
>  		ret = 0;
>  	} else {
>  		ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
> +		ts->rtask = NULL;
> 
=== message truncated ===



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: [patch] ucb1x00: touchscreen cleanups

[Pavel Machek]

Hi!

> I am in the process of porting Linux 2.6.11.5 to the
> Helio PDA (MIPS R3912 based) and if I remember
> correctly it is using a UCB1x00 (or Toshiba clone).
> Please could you make sure your patches will work
> across arch. Now I have my kernel up and running (well
> mainly falling :-() my next task is to get write the
> frame buffer driver and then look at the UCB1x00 as I
> need it for sound and touch screen. So in a day or two
> I will start to try to integrate your work into my
> kernel.

Well, without MIPS PDA to test on.... No, I do not think I broke
anything... but you'll have to ensure testing yourself.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [patch] ucb1x00: touchscreen cleanups

[Russell King]

On Tue, Jul 26, 2005 at 09:46:27AM +0200, Pavel Machek wrote:
> @@ -55,20 +54,6 @@ struct ucb1x00_ts {
>  
>  static int adcsync;
>  
> -static inline void ucb1x00_ts_evt_add(struct ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
> -{
> -	input_report_abs(&ts->idev, ABS_X, x);
> -	input_report_abs(&ts->idev, ABS_Y, y);
> -	input_report_abs(&ts->idev, ABS_PRESSURE, pressure);
> -	input_sync(&ts->idev);
> -}
> -
> -static inline void ucb1x00_ts_event_release(struct ucb1x00_ts *ts)
> -{
> -	input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> -	input_sync(&ts->idev);
> -}
> -

Only one query: What's the reason for moving these?  I think keeping
them makes the code more readable.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch] ucb1x00: touchscreen cleanups

[Russell King]

On Tue, Jul 26, 2005 at 09:04:12AM +0100, Mark Underwood wrote:
> I am in the process of porting Linux 2.6.11.5 to the
> Helio PDA (MIPS R3912 based) and if I remember
> correctly it is using a UCB1x00 (or Toshiba clone).
> Please could you make sure your patches will work
> across arch.

Which UCB1x00 version?  There's about three of them - 1200, 1300 and
1400.  The 1200 and 1300 are non-AC'97 devices, which are targetted
by this driver.

> Now I have my kernel up and running (well
> mainly falling :-() my next task is to get write the
> frame buffer driver and then look at the UCB1x00 as I
> need it for sound and touch screen. So in a day or two
> I will start to try to integrate your work into my
> kernel.

Note that I'm maintaining the code and will be publishing a new set
of patches for it based upon Pavel's fixes.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch] ucb1x00: touchscreen cleanups

[Pavel Machek]

Hi!

> > @@ -55,20 +54,6 @@ struct ucb1x00_ts {
> >  
> >  static int adcsync;
> >  
> > -static inline void ucb1x00_ts_evt_add(struct ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
> > -{
> > -	input_report_abs(&ts->idev, ABS_X, x);
> > -	input_report_abs(&ts->idev, ABS_Y, y);
> > -	input_report_abs(&ts->idev, ABS_PRESSURE, pressure);
> > -	input_sync(&ts->idev);
> > -}
> > -
> > -static inline void ucb1x00_ts_event_release(struct ucb1x00_ts *ts)
> > -{
> > -	input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> > -	input_sync(&ts->idev);
> > -}
> > -
> 
> Only one query: What's the reason for moving these?  I think keeping
> them makes the code more readable.

Vojtech liked that better after moving, and it is few lines shorter,
but I have no strong feelings about that.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [patch] ucb1x00: touchscreen cleanups

[Mark Underwood]

--- Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Tue, Jul 26, 2005 at 09:04:12AM +0100, Mark
> Underwood wrote:
> > I am in the process of porting Linux 2.6.11.5 to
> the
> > Helio PDA (MIPS R3912 based) and if I remember
> > correctly it is using a UCB1x00 (or Toshiba
> clone).
> > Please could you make sure your patches will work
> > across arch.
> 
> Which UCB1x00 version?  There's about three of them
> - 1200, 1300 and
> 1400.  The 1200 and 1300 are non-AC'97 devices,
> which are targetted
> by this driver.

It is the UCB1200 (also known as the Toshiba TC35143F
or Betty).

> 
> > Now I have my kernel up and running (well
> > mainly falling :-() my next task is to get write
> the
> > frame buffer driver and then look at the UCB1x00
> as I
> > need it for sound and touch screen. So in a day or
> two
> > I will start to try to integrate your work into my
> > kernel.
> 
> Note that I'm maintaining the code and will be
> publishing a new set
> of patches for it based upon Pavel's fixes.

Thanks. I'll check them out then.

> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   -
> http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: [patch] ucb1x00: touchscreen cleanups

[Russell King]

On Sat, Jul 30, 2005 at 12:33:50PM +0100, Mark Underwood wrote:
> > > Now I have my kernel up and running (well
> > > mainly falling :-() my next task is to get write
> > the
> > > frame buffer driver and then look at the UCB1x00
> > as I
> > > need it for sound and touch screen. So in a day or
> > two
> > > I will start to try to integrate your work into my
> > > kernel.
> > 
> > Note that I'm maintaining the code and will be
> > publishing a new set
> > of patches for it based upon Pavel's fixes.
> 
> Thanks. I'll check them out then.

Since there appears to be some interest in these, I'll set about
converting the audio bits to ALSA rather than Nico's SA11x0 audio
driver.  I thought no one was using these chips anymore, and the
driver was dead!

I've recently edited the mcp structure which may make things less
awkward for others, and I'll continue moving in that direction
with this driver.

You can get the updated patches at:

	http://zeniv.linux.org.uk/pub/people/rmk/ucb/

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch] ucb1x00: touchscreen cleanups

[Pavel Machek]

Hi!

> > > Note that I'm maintaining the code and will be
> > > publishing a new set
> > > of patches for it based upon Pavel's fixes.
> > 
> > Thanks. I'll check them out then.
> 
> Since there appears to be some interest in these, I'll set about
> converting the audio bits to ALSA rather than Nico's SA11x0 audio
> driver.  I thought no one was using these chips anymore, and the
> driver was dead!
> 
> I've recently edited the mcp structure which may make things less
> awkward for others, and I'll continue moving in that direction
> with this driver.
> 
> You can get the updated patches at:
> 
> 	http://zeniv.linux.org.uk/pub/people/rmk/ucb/

Okay, what's the plan with mainstreaming those? Do they stay in
drivers/misc?
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] ucb1x00: touchscreen cleanups

[Russell King]

On Sat, Jul 30, 2005 at 10:46:58PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > Note that I'm maintaining the code and will be
> > > > publishing a new set
> > > > of patches for it based upon Pavel's fixes.
> > > 
> > > Thanks. I'll check them out then.
> > 
> > Since there appears to be some interest in these, I'll set about
> > converting the audio bits to ALSA rather than Nico's SA11x0 audio
> > driver.  I thought no one was using these chips anymore, and the
> > driver was dead!
> > 
> > I've recently edited the mcp structure which may make things less
> > awkward for others, and I'll continue moving in that direction
> > with this driver.
> > 
> > You can get the updated patches at:
> > 
> > 	http://zeniv.linux.org.uk/pub/people/rmk/ucb/
> 
> Okay, what's the plan with mainstreaming those? Do they stay in
> drivers/misc?

Let me put the second question a slightly different way: can anyone
think of a better way to organise the files which makes more sense
and doesn't end up with just a couple of files for the core UCB
and MCP support in some random directory elsewhere?

Arjan?  hch?  any comments / good ideas?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch] ucb1x00: touchscreen cleanups

[Mark Underwood]

--- Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Sat, Jul 30, 2005 at 10:46:58PM +0200, Pavel
> Machek wrote:
> > Hi!
> > 
> > > > > Note that I'm maintaining the code and will
> be
> > > > > publishing a new set
> > > > > of patches for it based upon Pavel's fixes.
> > > > 
> > > > Thanks. I'll check them out then.
> > > 
> > > Since there appears to be some interest in
> these, I'll set about
> > > converting the audio bits to ALSA rather than
> Nico's SA11x0 audio
> > > driver.  I thought no one was using these chips
> anymore, and the
> > > driver was dead!
> > > 
> > > I've recently edited the mcp structure which may
> make things less
> > > awkward for others, and I'll continue moving in
> that direction
> > > with this driver.
> > > 
> > > You can get the updated patches at:
> > > 
> > > 	http://zeniv.linux.org.uk/pub/people/rmk/ucb/
> > 
> > Okay, what's the plan with mainstreaming those? Do
> they stay in
> > drivers/misc?
> 
> Let me put the second question a slightly different
> way: can anyone
> think of a better way to organise the files which
> makes more sense
> and doesn't end up with just a couple of files for
> the core UCB
> and MCP support in some random directory elsewhere?
> 
> Arjan?  hch?  any comments / good ideas?

As this isn't the only chip of this sort (i.e. a
multi-function chip not on the CPU bus) maybe we
should store the bus driver in a common place. If
needed we could have a very simple bus driver
subsystem (this might already be in the kernel, I
haven't looked at the bus stuff) in which you register
a bus driver and client drivers register with the bus
driver. Just an idea :-).

Mark

> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   -
> http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: [patch] ucb1x00: touchscreen cleanups

[Richard Purdie]

On Sun, 2005-07-31 at 23:11 +0100, Mark Underwood wrote:
> As this isn't the only chip of this sort (i.e. a
> multi-function chip not on the CPU bus) maybe we
> should store the bus driver in a common place. If
> needed we could have a very simple bus driver
> subsystem (this might already be in the kernel, I
> haven't looked at the bus stuff) in which you register
> a bus driver and client drivers register with the bus
> driver. Just an idea :-).

This was the idea with the drivers/soc suggestion although I think that
name is perhaps misleading.

How about drivers/mfd where mfd = Multi Functional Devices?

I think it would be acceptable (and in keeping with the other drivers
e.g. pcmcia) to seeing the arch and platform specific modules with the
main driver as long as the naming reflected it (like the existing mcp
and ucb code does) i.e.:

mcp-core.c
mcp-sa1100.c
ucb1x00-code.c
ucb1x00-assabet.c
ucb1x00-collie.c

If code can be separated out into subsystems, I'm not so sure where they
should go though. The existing policy would suggest
drivers/input/touchscreen and sound/xxx for these...

ucb1x00-ts.c
ucb1x00-audio.c

Opinions/Comments?

Richard

Re: [patch] ucb1x00: touchscreen cleanups

[Pavel Machek]

Hi!

> > As this isn't the only chip of this sort (i.e. a
> > multi-function chip not on the CPU bus) maybe we
> > should store the bus driver in a common place. If
> > needed we could have a very simple bus driver
> > subsystem (this might already be in the kernel, I
> > haven't looked at the bus stuff) in which you register
> > a bus driver and client drivers register with the bus
> > driver. Just an idea :-).
> 
> This was the idea with the drivers/soc suggestion although I think that
> name is perhaps misleading.
> 
> How about drivers/mfd where mfd = Multi Functional Devices?
> 
> I think it would be acceptable (and in keeping with the other drivers
> e.g. pcmcia) to seeing the arch and platform specific modules with the
> main driver as long as the naming reflected it (like the existing mcp
> and ucb code does) i.e.:
> 
> mcp-core.c
> mcp-sa1100.c
> ucb1x00-code.c
> ucb1x00-assabet.c
> ucb1x00-collie.c
> 
> If code can be separated out into subsystems, I'm not so sure where they
> should go though. The existing policy would suggest
> drivers/input/touchscreen and sound/xxx for these...
> 
> ucb1x00-ts.c
> ucb1x00-audio.c
> 
> Opinions/Comments?

drivers/mfd sounds good, and yes, touchscreen and audio should go
where they belong.
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

How do we handle multi-function devices? [was Re: [patch] ucb1x00: touchscreen cleanups]

[Mark Underwood]

--- Richard Purdie <rpurdie@rpsys.net> wrote:

> On Sun, 2005-07-31 at 23:11 +0100, Mark Underwood
> wrote:
> > As this isn't the only chip of this sort (i.e. a
> > multi-function chip not on the CPU bus) maybe we
> > should store the bus driver in a common place. If
> > needed we could have a very simple bus driver
> > subsystem (this might already be in the kernel, I
> > haven't looked at the bus stuff) in which you
> register
> > a bus driver and client drivers register with the
> bus
> > driver. Just an idea :-).
> 
> This was the idea with the drivers/soc suggestion
> although I think that
> name is perhaps misleading.
> 
> How about drivers/mfd where mfd = Multi Functional
> Devices?

I was thinking of something like driver/bus into which
we might also be able to put the I2C and LL3 buses.
The only problem is that this might leave some parts
of the multi function chip homeless (if they can't
find a home in other subsystems).

> 
> I think it would be acceptable (and in keeping with
> the other drivers
> e.g. pcmcia) to seeing the arch and platform
> specific modules with the
> main driver as long as the naming reflected it (like
> the existing mcp
> and ucb code does) i.e.:
> 
> mcp-core.c
> mcp-sa1100.c
> ucb1x00-code.c
> ucb1x00-assabet.c
> ucb1x00-collie.c

Maybe, I haven't looked at pcmcia but the I2C
subsystem manages to avoid any arch dependent stuff so
couldn't we? I need to do more homework ;-), but
surely we only need a bus driver (IP block specific,
platform and arch independent), a core driver to
register busses and clients, and client drivers.

> 
> If code can be separated out into subsystems, I'm
> not so sure where they
> should go though. The existing policy would suggest
> drivers/input/touchscreen and sound/xxx for these...
> 
> ucb1x00-ts.c
> ucb1x00-audio.c

Yes, any function of a multi function device that can
live in a subsystem should do otherwise imagine the
mess, for example, with a chip that has a USB master
on it.

Mark

> 
> Opinions/Comments?
> 
> Richard
> 
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com