Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > > So, if the collie folk would like to clean their changes up and send > > > them to me as the driver author, I'll see about integrating them into > > > my version and we'll take it from there. > > > > Okay, will do. [Is there chance to pull your tree using git? It would > > help a bit...] ... > However, if the UCB stuff is going to get worked on, I don't mind > setting up, maintaining and publishing a git tree for that that, > provided it then vanishes once merged into mainline. That falls > within the "very limited purposes" clause above. Yes, that would help a lot, because I'd have a tree to diff against. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. Okay, will do. [Is there chance to pull your tree using git? It would help a bit...] ... However, if the UCB stuff is going to get worked on, I don't mind setting up, maintaining and publishing a git tree for that that, provided it then vanishes once merged into mainline. That falls within the very limited purposes clause above. Yes, that would help a lot, because I'd have a tree to diff against. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Tue, Jul 26, 2005 at 12:06:59AM +0200, Pavel Machek wrote: > > > Also it looks to me like mcp.h should go into asm/arch-sa1100, so > > > that other drivers can use it... > > > > That doesn't make sense when you have other non-SA1100 devices using > > mcp-core.c. Whether that happens or not I've no idea - I can't see > > what everyone's using out there (just like I've absolutely zero > > idea what collie folk are doing or not doing.) > > set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it > breaks compilation, because struct members will not be available; at > least in this version), so I doubt it has many non-SA1100 users... That's not conclusive in itself - if it's only usable on SA1100 platforms, why was that ifdef added? > > So, if the collie folk would like to clean their changes up and send > > them to me as the driver author, I'll see about integrating them into > > my version and we'll take it from there. > > Okay, will do. [Is there chance to pull your tree using git? It would > help a bit...] My git usage is limited to the final stage of my development - iow providing an integration and test bed for merging upstream. My work prior to that is all patch based (as per the tarball of patches I posted previously) with scripts to manage them - I like the power to re-order, split, merge, insert and remove patches at random, which includes whole series of patches vs individual patches themselves. Consequently, if I were to publish my git trees, what you'll find is that they're indentical copies of Linus' tree except for maybe when Linus is away, or hasn't pulled that night, or... What you're actually seeing with the UCB stuff is the effect of me stopping maintaining the -rmk trees - code effectively got "dropped" from public view at that point, and I'm not going to start publishing such a tree any time soon. It completely detracts from the task of ensuring mainline kernels work for ARM - since the -rmk tree is/was seen as the tree for everything ARM to be merged into, and hence upstream merging became my problem. No, never again will I make a fool of myself like that. Hence, I'll never again publish a kernel tree myself, except maybe for very limited purposes. However, if the UCB stuff is going to get worked on, I don't mind setting up, maintaining and publishing a git tree for that that, provided it then vanishes once merged into mainline. That falls within the "very limited purposes" clause above. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > > The problem is that the parent doesn't actually know how many > > > devices to create nor what to call them, and they're logically > > > indistinguishable from each other so there's no logical naming > > > system. > > > > Then we should probably not try to force them into driver model. Have > > parent device register struct device and when sub-drivers register > > they could attach class devices (like input devices) directly to the > > "main" device thus hiding presence of sub-sections of the chip from > > sysfs completely. My point is that we should not be using > > class_interface here - its purpose is diferent. > > If you look at _my_ version, you'll notice that it doesn't use the > class interface stuff. A previous version of it did, and this seems > to be what the collie stuff is based upon. > > What I suggest is that the collie folk need to update their driver > to my version so that we don't have two different forks of the same Yep, will do, and sorry for the confusion. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > > > This adds support for reading ADCs (etc), neccessary to operate touch > > > > screen on Sharp Zaurus sl-5500. > > > > > > I would like to know what the diffs are between my version (attached) > > > and this version before they get applied. > > > > Hmm, diff looks quite big (attached), and I got it from lenz for 99% > > part. > > It looks like John's version is actually based on a previous revision > of this driver. 8/ Oops. > > I have made quite a lot of cleanups to touchscreen part, and it seems > > to be acceptable by input people. I think it should go into > > drivers/input/touchscreen/collie_ts.c... > > Err, why should my assabet touchscreen be called "collie_ts" ? > collie is just a platform which happens to use it - it's got > no relevance to the driver naming at all. Okay, I did not quite realized it was shared. > > Also it looks to me like mcp.h should go into asm/arch-sa1100, so > > that other drivers can use it... > > That doesn't make sense when you have other non-SA1100 devices using > mcp-core.c. Whether that happens or not I've no idea - I can't see > what everyone's using out there (just like I've absolutely zero > idea what collie folk are doing or not doing.) set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it breaks compilation, because struct members will not be available; at least in this version), so I doubt it has many non-SA1100 users... > > > The only reason my version has not been submitted is because it lives > > > in the drivers/misc directory, and mainline kernel folk don't like > > > drivers which clutter up that directory. In fact, I had been told > > > that drivers/misc should remain completely empty - which makes this > > > set of miscellaneous drivers homeless. > > > > Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc > > better place? > > arch/arm/soc? That means that (a) we end up with another directory to > accumulate crap, (b) it's not a SoC so doesn't belong in a directory > named as such, (c) it means that the MCP and UCB drivers get their > individual files scattered throughout the kernel tree, one in this > directory, one in that directory, one in another random directory. > That's far from ideal. Well, I believe that UCB layer is quite well define and it looks quite okay for touchscreen driver to be near other touchscreens... ucb-core still needs to go somewhere, if drivers/misc was vetoed, perhaps arch/arm/misc would be okay? > Anyway, summarising this, the results are that what we have here is > a complete and utter mess. ;( Yep :-(. > So, if the collie folk would like to clean their changes up and send > them to me as the driver author, I'll see about integrating them into > my version and we'll take it from there. Okay, will do. [Is there chance to pull your tree using git? It would help a bit...] Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > Can we change this to "while (!kthread_should_stop())" to make me > > completely happy? > > I still ask, and I'll keep repeating this. What is the difference > between this and the reference implementation which is known to > work on other hardware. I think I posted diffs already, but they were rather big and against wrong version. I'll try to get better diffs. > Let's not go all out on one implementation for one set of hardware, > but try to work out what we need to do to the generic reference > implementation to make it work on this hardware. I did not know it is supposed to work on other devices, too. My fault. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
> > I have made quite a lot of cleanups to touchscreen part, and it seems
> > to be acceptable by input people. I think it should go into
> > drivers/input/touchscreen/collie_ts.c... Also it looks to me like
> > mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
>
> I have couple of nitpicks (below) and one bigger concern - I am
> surprised that a driver for a physical device is implemented as an
> interface to a class device. This precludes implementing any kind of
> power management in the driver and pushes it into the parent and is
> generally speaking is a wrong thing to do (IMHO).
I'll port my changes to newer version of rmk's tree, that should solve
it.
> > +static int ucb1x00_thread(void *_ts)
> > +{
> > + struct ucb1x00_ts *ts = _ts;
> > + struct task_struct *tsk = current;
> > + int valid;
> > +
> > + ts->rtask = tsk;
>
> Just move that assignment into ucb1x00_input_open and kill all this
> "current" stuff.
It will still want to set the priority, but yes, it cleaned it.
> > + /*
> > +* We run as a real-time thread. However, thus far
> > +* this doesn't seem to be necessary.
> > +*/
> > + tsk->policy = SCHED_FIFO;
> > + tsk->rt_priority = 1;
> > +
> > + valid = 0;
> > + for (;;) {
>
> Can we change this to "while (!kthread_should_stop())" to make me
> completely happy?
:-) Ok.
[Just FYI, I'll post agregated patch when I solve file placement and
port to newer version.]
Cleanups suggested by Dmitri.
---
commit 60814924ed695d863fa226c24b3d4e96054c8b66
tree 0e88e8272c23926c5654ae10bfe14d4cb2af84ab
parent ff30d8505b88064a5f6e6e70bd42028150a864e2
author <[EMAIL PROTECTED](none)> Mon, 25 Jul 2005 23:35:21 +0200
committer <[EMAIL PROTECTED](none)> Mon, 25 Jul 2005 23:35:21 +0200
drivers/input/touchscreen/collie_ts.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
--- a/drivers/input/touchscreen/collie_ts.c
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -158,8 +158,6 @@ static int ucb1x00_thread(void *_ts)
struct task_struct *tsk = current;
int valid;
- ts->rtask = tsk;
-
/*
* We run as a real-time thread. However, thus far
* this doesn't seem to be necessary.
@@ -168,7 +166,7 @@ static int ucb1x00_thread(void *_ts)
tsk->rt_priority = 1;
valid = 0;
- for (;;) {
+ while (!kthread_should_stop()) {
unsigned int x, y, p, val;
ts->restart = 0;
@@ -231,9 +229,6 @@ static int ucb1x00_thread(void *_ts)
msleep_interruptible(10);
}
-
- if (kthread_should_stop())
- break;
}
ts->rtask = NULL;
@@ -273,11 +268,12 @@ static int ucb1x00_ts_open(struct input_
ts->y_res = ucb1x00_ts_read_yres(ts);
ucb1x00_adc_disable(ts->ucb);
- task = kthread_run(ucb1x00_thread, ts, "ktsd");
- if (!IS_ERR(task)) {
+ ts->rtask = kthread_run(ucb1x00_thread, ts, "ktsd");
+ if (!IS_ERR(ts->task)) {
ret = 0;
} else {
ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
+ ts->rtask = NULL;
ret = -EFAULT;
}
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:47:25AM -0500, Dmitry Torokhov wrote: > On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > > If you look at _my_ version, you'll notice that it doesn't use the > > class interface stuff. A previous version of it did, and this seems > > to be what the collie stuff is based upon. > > I was only commenting on something that was posted on LKML for > inclusion into input subtree that I am interested in. I don't track > ARM development that closely. Where can we see your version, please? See earlier in this thread, 24th July. > > What I suggest is that the collie folk need to update their driver > > to my version so that we don't have two different forks of the same > > driver in existance. Then we can start discussing whether things > > should be using kthreads or not. > > Do you have any reason why, generally speaking, threads should not be > used? They seem to clean up code in drivers quite a bit. It depends what the reasoning is behind them. The touchscreen driver is threaded because it wants to collect touschreen samples independently of the availability of a user thread. Moreover, obtaining ADC samples needs a sleeping context since it may take a while to complete. However, putting all UCB interrupts into a thread does not make sense to me - if we allow UCB interrupts to sleep, it allows one UCB interrupt to be processed at the exclusion of the others. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: > > On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > > > On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: > > > > If the problem is that you have a single piece of hardware you need to > > > > bind several drivers to - I guess you will have to create a new > > > > sub-device bus for that. Or just register sub-devices on the same bus > > > > the parent device is registered on - I am not sure what is best in > > > > this particular case - I am not familiar with the arch. > > > > > > That is exactly the problem - these kinds of devices do _not_ fit > > > well into the device model. A struct device for every different > > > possible sub-unit is completely overkill. > > > > > > For instance, you may logically use one ADC and some GPIO lines > > > on the device for X and something else for Y and they logically > > > end up in different drivers. > > > > > > The problem is that the parent doesn't actually know how many > > > devices to create nor what to call them, and they're logically > > > indistinguishable from each other so there's no logical naming > > > system. > > > > > > > Then we should probably not try to force them into driver model. Have > > parent device register struct device and when sub-drivers register > > they could attach class devices (like input devices) directly to the > > "main" device thus hiding presence of sub-sections of the chip from > > sysfs completely. My point is that we should not be using > > class_interface here - its purpose is diferent. > > If you look at _my_ version, you'll notice that it doesn't use the > class interface stuff. A previous version of it did, and this seems > to be what the collie stuff is based upon. > I was only commenting on something that was posted on LKML for inclusion into input subtree that I am interested in. I don't track ARM development that closely. Where can we see your version, please? > What I suggest is that the collie folk need to update their driver > to my version so that we don't have two different forks of the same > driver in existance. Then we can start discussing whether things > should be using kthreads or not. Do you have any reason why, generally speaking, threads should not be used? They seem to clean up code in drivers quite a bit. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: > On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: > > > If the problem is that you have a single piece of hardware you need to > > > bind several drivers to - I guess you will have to create a new > > > sub-device bus for that. Or just register sub-devices on the same bus > > > the parent device is registered on - I am not sure what is best in > > > this particular case - I am not familiar with the arch. > > > > That is exactly the problem - these kinds of devices do _not_ fit > > well into the device model. A struct device for every different > > possible sub-unit is completely overkill. > > > > For instance, you may logically use one ADC and some GPIO lines > > on the device for X and something else for Y and they logically > > end up in different drivers. > > > > The problem is that the parent doesn't actually know how many > > devices to create nor what to call them, and they're logically > > indistinguishable from each other so there's no logical naming > > system. > > > > Then we should probably not try to force them into driver model. Have > parent device register struct device and when sub-drivers register > they could attach class devices (like input devices) directly to the > "main" device thus hiding presence of sub-sections of the chip from > sysfs completely. My point is that we should not be using > class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 06:56:07AM +0200, Pavel Machek wrote: > Hi! > > > > This adds support for reading ADCs (etc), neccessary to operate touch > > > screen on Sharp Zaurus sl-5500. > > > > I would like to know what the diffs are between my version (attached) > > and this version before they get applied. > > Hmm, diff looks quite big (attached), and I got it from lenz for 99% > part. It looks like John's version is actually based on a previous revision of this driver. 8/ > I have made quite a lot of cleanups to touchscreen part, and it seems > to be acceptable by input people. I think it should go into > drivers/input/touchscreen/collie_ts.c... Err, why should my assabet touchscreen be called "collie_ts" ? collie is just a platform which happens to use it - it's got no relevance to the driver naming at all. > Also it looks to me like mcp.h should go into asm/arch-sa1100, so > that other drivers can use it... That doesn't make sense when you have other non-SA1100 devices using mcp-core.c. Whether that happens or not I've no idea - I can't see what everyone's using out there (just like I've absolutely zero idea what collie folk are doing or not doing.) > > The only reason my version has not been submitted is because it lives > > in the drivers/misc directory, and mainline kernel folk don't like > > drivers which clutter up that directory. In fact, I had been told > > that drivers/misc should remain completely empty - which makes this > > set of miscellaneous drivers homeless. > > Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc > better place? arch/arm/soc? That means that (a) we end up with another directory to accumulate crap, (b) it's not a SoC so doesn't belong in a directory named as such, (c) it means that the MCP and UCB drivers get their individual files scattered throughout the kernel tree, one in this directory, one in that directory, one in another random directory. That's far from ideal. Anyway, summarising this, the results are that what we have here is a complete and utter mess. ;( So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: > > If the problem is that you have a single piece of hardware you need to > > bind several drivers to - I guess you will have to create a new > > sub-device bus for that. Or just register sub-devices on the same bus > > the parent device is registered on - I am not sure what is best in > > this particular case - I am not familiar with the arch. > > That is exactly the problem - these kinds of devices do _not_ fit > well into the device model. A struct device for every different > possible sub-unit is completely overkill. > > For instance, you may logically use one ADC and some GPIO lines > on the device for X and something else for Y and they logically > end up in different drivers. > > The problem is that the parent doesn't actually know how many > devices to create nor what to call them, and they're logically > indistinguishable from each other so there's no logical naming > system. > Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the "main" device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: > If the problem is that you have a single piece of hardware you need to > bind several drivers to - I guess you will have to create a new > sub-device bus for that. Or just register sub-devices on the same bus > the parent device is registered on - I am not sure what is best in > this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. > Can we change this to "while (!kthread_should_stop())" to make me > completely happy? I still ask, and I'll keep repeating this. What is the difference between this and the reference implementation which is known to work on other hardware. Let's not go all out on one implementation for one set of hardware, but try to work out what we need to do to the generic reference implementation to make it work on this hardware. IOW, you're working on the wrong version. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi Pavel,
On 7/24/05, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> I have made quite a lot of cleanups to touchscreen part, and it seems
> to be acceptable by input people. I think it should go into
> drivers/input/touchscreen/collie_ts.c... Also it looks to me like
> mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
I have couple of nitpicks (below) and one bigger concern - I am
surprised that a driver for a physical device is implemented as an
interface to a class device. This precludes implementing any kind of
power management in the driver and pushes it into the parent and is
generally speaking is a wrong thing to do (IMHO).
If the problem is that you have a single piece of hardware you need to
bind several drivers to - I guess you will have to create a new
sub-device bus for that. Or just register sub-devices on the same bus
the parent device is registered on - I am not sure what is best in
this particular case - I am not familiar with the arch. It is my
understanding that the purpose of interfaces to to present different
"views" to userspace and therefore they are not quie suited for what
you are trying to do...
> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
Just move that assignment into ucb1x00_input_open and kill all this
"current" stuff.
> +
> + /*
> +* We run as a real-time thread. However, thus far
> +* this doesn't seem to be necessary.
> +*/
> + tsk->policy = SCHED_FIFO;
> + tsk->rt_priority = 1;
> +
> + valid = 0;
> + for (;;) {
Can we change this to "while (!kthread_should_stop())" to make me
completely happy?
Thanks!
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
> > This adds support for reading ADCs (etc), neccessary to operate touch
> > screen on Sharp Zaurus sl-5500.
>
> I would like to know what the diffs are between my version (attached)
> and this version before they get applied.
Hmm, diff looks quite big (attached), and I got it from lenz for 99%
part.
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
> The only reason my version has not been submitted is because it lives
> in the drivers/misc directory, and mainline kernel folk don't like
> drivers which clutter up that directory. In fact, I had been told
> that drivers/misc should remain completely empty - which makes this
> set of miscellaneous drivers homeless.
Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc
better place?
Pavel
--- linux-rmk/drivers/input/touchscreen/Kconfig 2005-07-14 00:41:02.0
+0200
+++ linux-z/drivers/input/touchscreen/Kconfig 2005-07-21 17:22:31.0
+0200
@@ -36,6 +36,15 @@
To compile this driver as a module, choose M here: the
module will be called ads7846_ts.
+config TOUCHSCREEN_COLLIE
+ tristate "Collie touchscreen (for Sharp SL-5500)"
+ depends on MCP_UCB1200
+ help
+ Say Y here to enable the driver for the touchscreen on the
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
config TOUCHSCREEN_GUNZE
tristate "Gunze AHL-51S touchscreen"
select SERIO
--- linux-rmk/drivers/input/touchscreen/Makefile2005-07-14
00:41:02.0 +0200
+++ linux-z/drivers/input/touchscreen/Makefile 2005-07-21 06:39:52.0
+0200
@@ -6,6 +6,7 @@
obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
--- linux-rmk/drivers/misc/Makefile 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/Makefile 2005-07-21 06:36:17.0 +0200
@@ -6,12 +6,15 @@
obj-$(CONFIG_IBM_ASM) += ibmasm/
obj-$(CONFIG_HDPU_FEATURES)+= hdpuftrs/
-obj-$(CONFIG_MCP) += mcp-core.o
-obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
-obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
-obj-$(CONFIG_MCP_UCB1200_TS) += ucb1x00-ts.o
+obj-$(CONFIG_MCP) += mcp-core.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
+obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
ifeq ($(CONFIG_SA1100_ASSABET),y)
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
endif
+
+obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
+
+ucb1400-core-y := ucb1x00-core.o mcp-ac97.o
+obj-$(CONFIG_UCB1400_TS) += ucb1400-core.o ucb1x00-ts.o
Only in linux-z/drivers/misc: mcp-ac97.c
--- linux-rmk/drivers/misc/mcp-core.c 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/mcp-core.c 2005-07-21 06:57:36.0 +0200
@@ -19,9 +19,9 @@
#include
#include
-#include "mcp.h"
+#include
-#define to_mcp(d) container_of(d, struct mcp, attached_device)
+#define to_mcp(d) ((struct mcp *)(d)->platform_data)
#define to_mcp_driver(d) container_of(d, struct mcp_driver, drv)
static int mcp_bus_match(struct device *dev, struct device_driver *drv)
@@ -46,7 +46,7 @@
return 0;
}
-static int mcp_bus_suspend(struct device *dev, pm_message_t state)
+static int mcp_bus_suspend(struct device *dev, u32 state)
{
struct mcp *mcp = to_mcp(dev);
int ret = 0;
@@ -179,26 +179,40 @@
spin_unlock_irqrestore(>lock, flags);
}
-static void mcp_release(struct device *dev)
-{
- struct mcp *mcp = container_of(dev, struct mcp, attached_device);
-
- kfree(mcp);
+static void mcp_host_release(struct device *dev) {
+ struct mcp *mcp = dev->platform_data;
+ complete(>attached_device_released);
}
int mcp_host_register(struct mcp *mcp, struct device *parent)
{
- mcp->attached_device.parent = parent;
- mcp->attached_device.bus = _bus_type;
- mcp->attached_device.dma_mask = parent->dma_mask;
- mcp->attached_device.release = mcp_release;
- strcpy(mcp->attached_device.bus_id, "mcp0");
- return device_register(>attached_device);
+ int ret;
+ struct device *dev = kmalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+ memset(dev, 0, sizeof(*dev));
+ dev->platform_data = mcp;
+ dev->parent = parent;
+ dev->bus = _bus_type;
+ dev->dma_mask = parent->dma_mask;
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
This adds support for reading ADCs (etc), neccessary to operate touch
screen on Sharp Zaurus sl-5500.
I would like to know what the diffs are between my version (attached)
and this version before they get applied.
Hmm, diff looks quite big (attached), and I got it from lenz for 99%
part.
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
The only reason my version has not been submitted is because it lives
in the drivers/misc directory, and mainline kernel folk don't like
drivers which clutter up that directory. In fact, I had been told
that drivers/misc should remain completely empty - which makes this
set of miscellaneous drivers homeless.
Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc
better place?
Pavel
--- linux-rmk/drivers/input/touchscreen/Kconfig 2005-07-14 00:41:02.0
+0200
+++ linux-z/drivers/input/touchscreen/Kconfig 2005-07-21 17:22:31.0
+0200
@@ -36,6 +36,15 @@
To compile this driver as a module, choose M here: the
module will be called ads7846_ts.
+config TOUCHSCREEN_COLLIE
+ tristate Collie touchscreen (for Sharp SL-5500)
+ depends on MCP_UCB1200
+ help
+ Say Y here to enable the driver for the touchscreen on the
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
config TOUCHSCREEN_GUNZE
tristate Gunze AHL-51S touchscreen
select SERIO
--- linux-rmk/drivers/input/touchscreen/Makefile2005-07-14
00:41:02.0 +0200
+++ linux-z/drivers/input/touchscreen/Makefile 2005-07-21 06:39:52.0
+0200
@@ -6,6 +6,7 @@
obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
--- linux-rmk/drivers/misc/Makefile 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/Makefile 2005-07-21 06:36:17.0 +0200
@@ -6,12 +6,15 @@
obj-$(CONFIG_IBM_ASM) += ibmasm/
obj-$(CONFIG_HDPU_FEATURES)+= hdpuftrs/
-obj-$(CONFIG_MCP) += mcp-core.o
-obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
-obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
-obj-$(CONFIG_MCP_UCB1200_TS) += ucb1x00-ts.o
+obj-$(CONFIG_MCP) += mcp-core.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
+obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
ifeq ($(CONFIG_SA1100_ASSABET),y)
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
endif
+
+obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
+
+ucb1400-core-y := ucb1x00-core.o mcp-ac97.o
+obj-$(CONFIG_UCB1400_TS) += ucb1400-core.o ucb1x00-ts.o
Only in linux-z/drivers/misc: mcp-ac97.c
--- linux-rmk/drivers/misc/mcp-core.c 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/mcp-core.c 2005-07-21 06:57:36.0 +0200
@@ -19,9 +19,9 @@
#include asm/dma.h
#include asm/system.h
-#include mcp.h
+#include asm/arch-sa1100/mcp.h
-#define to_mcp(d) container_of(d, struct mcp, attached_device)
+#define to_mcp(d) ((struct mcp *)(d)-platform_data)
#define to_mcp_driver(d) container_of(d, struct mcp_driver, drv)
static int mcp_bus_match(struct device *dev, struct device_driver *drv)
@@ -46,7 +46,7 @@
return 0;
}
-static int mcp_bus_suspend(struct device *dev, pm_message_t state)
+static int mcp_bus_suspend(struct device *dev, u32 state)
{
struct mcp *mcp = to_mcp(dev);
int ret = 0;
@@ -179,26 +179,40 @@
spin_unlock_irqrestore(mcp-lock, flags);
}
-static void mcp_release(struct device *dev)
-{
- struct mcp *mcp = container_of(dev, struct mcp, attached_device);
-
- kfree(mcp);
+static void mcp_host_release(struct device *dev) {
+ struct mcp *mcp = dev-platform_data;
+ complete(mcp-attached_device_released);
}
int mcp_host_register(struct mcp *mcp, struct device *parent)
{
- mcp-attached_device.parent = parent;
- mcp-attached_device.bus = mcp_bus_type;
- mcp-attached_device.dma_mask = parent-dma_mask;
- mcp-attached_device.release = mcp_release;
- strcpy(mcp-attached_device.bus_id, mcp0);
- return device_register(mcp-attached_device);
+ int ret;
+ struct device *dev = kmalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+ memset(dev, 0, sizeof(*dev));
+ dev-platform_data = mcp;
+ dev-parent = parent;
+ dev-bus = mcp_bus_type;
+
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi Pavel,
On 7/24/05, Pavel Machek [EMAIL PROTECTED] wrote:
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
I have couple of nitpicks (below) and one bigger concern - I am
surprised that a driver for a physical device is implemented as an
interface to a class device. This precludes implementing any kind of
power management in the driver and pushes it into the parent and is
generally speaking is a wrong thing to do (IMHO).
If the problem is that you have a single piece of hardware you need to
bind several drivers to - I guess you will have to create a new
sub-device bus for that. Or just register sub-devices on the same bus
the parent device is registered on - I am not sure what is best in
this particular case - I am not familiar with the arch. It is my
understanding that the purpose of interfaces to to present different
views to userspace and therefore they are not quie suited for what
you are trying to do...
+static int ucb1x00_thread(void *_ts)
+{
+ struct ucb1x00_ts *ts = _ts;
+ struct task_struct *tsk = current;
+ int valid;
+
+ ts-rtask = tsk;
Just move that assignment into ucb1x00_input_open and kill all this
current stuff.
+
+ /*
+* We run as a real-time thread. However, thus far
+* this doesn't seem to be necessary.
+*/
+ tsk-policy = SCHED_FIFO;
+ tsk-rt_priority = 1;
+
+ valid = 0;
+ for (;;) {
Can we change this to while (!kthread_should_stop()) to make me
completely happy?
Thanks!
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Can we change this to while (!kthread_should_stop()) to make me completely happy? I still ask, and I'll keep repeating this. What is the difference between this and the reference implementation which is known to work on other hardware. Let's not go all out on one implementation for one set of hardware, but try to work out what we need to do to the generic reference implementation to make it work on this hardware. IOW, you're working on the wrong version. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 06:56:07AM +0200, Pavel Machek wrote: Hi! This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. Hmm, diff looks quite big (attached), and I got it from lenz for 99% part. It looks like John's version is actually based on a previous revision of this driver. 8/ I have made quite a lot of cleanups to touchscreen part, and it seems to be acceptable by input people. I think it should go into drivers/input/touchscreen/collie_ts.c... Err, why should my assabet touchscreen be called collie_ts ? collie is just a platform which happens to use it - it's got no relevance to the driver naming at all. Also it looks to me like mcp.h should go into asm/arch-sa1100, so that other drivers can use it... That doesn't make sense when you have other non-SA1100 devices using mcp-core.c. Whether that happens or not I've no idea - I can't see what everyone's using out there (just like I've absolutely zero idea what collie folk are doing or not doing.) The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc better place? arch/arm/soc? That means that (a) we end up with another directory to accumulate crap, (b) it's not a SoC so doesn't belong in a directory named as such, (c) it means that the MCP and UCB drivers get their individual files scattered throughout the kernel tree, one in this directory, one in that directory, one in another random directory. That's far from ideal. Anyway, summarising this, the results are that what we have here is a complete and utter mess. ;( So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. I was only commenting on something that was posted on LKML for inclusion into input subtree that I am interested in. I don't track ARM development that closely. Where can we see your version, please? What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. Do you have any reason why, generally speaking, threads should not be used? They seem to clean up code in drivers quite a bit. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:47:25AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. I was only commenting on something that was posted on LKML for inclusion into input subtree that I am interested in. I don't track ARM development that closely. Where can we see your version, please? See earlier in this thread, 24th July. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. Do you have any reason why, generally speaking, threads should not be used? They seem to clean up code in drivers quite a bit. It depends what the reasoning is behind them. The touchscreen driver is threaded because it wants to collect touschreen samples independently of the availability of a user thread. Moreover, obtaining ADC samples needs a sleeping context since it may take a while to complete. However, putting all UCB interrupts into a thread does not make sense to me - if we allow UCB interrupts to sleep, it allows one UCB interrupt to be processed at the exclusion of the others. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
I have couple of nitpicks (below) and one bigger concern - I am
surprised that a driver for a physical device is implemented as an
interface to a class device. This precludes implementing any kind of
power management in the driver and pushes it into the parent and is
generally speaking is a wrong thing to do (IMHO).
I'll port my changes to newer version of rmk's tree, that should solve
it.
+static int ucb1x00_thread(void *_ts)
+{
+ struct ucb1x00_ts *ts = _ts;
+ struct task_struct *tsk = current;
+ int valid;
+
+ ts-rtask = tsk;
Just move that assignment into ucb1x00_input_open and kill all this
current stuff.
It will still want to set the priority, but yes, it cleaned it.
+ /*
+* We run as a real-time thread. However, thus far
+* this doesn't seem to be necessary.
+*/
+ tsk-policy = SCHED_FIFO;
+ tsk-rt_priority = 1;
+
+ valid = 0;
+ for (;;) {
Can we change this to while (!kthread_should_stop()) to make me
completely happy?
:-) Ok.
[Just FYI, I'll post agregated patch when I solve file placement and
port to newer version.]
Cleanups suggested by Dmitri.
---
commit 60814924ed695d863fa226c24b3d4e96054c8b66
tree 0e88e8272c23926c5654ae10bfe14d4cb2af84ab
parent ff30d8505b88064a5f6e6e70bd42028150a864e2
author [EMAIL PROTECTED](none) Mon, 25 Jul 2005 23:35:21 +0200
committer [EMAIL PROTECTED](none) Mon, 25 Jul 2005 23:35:21 +0200
drivers/input/touchscreen/collie_ts.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
--- a/drivers/input/touchscreen/collie_ts.c
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -158,8 +158,6 @@ static int ucb1x00_thread(void *_ts)
struct task_struct *tsk = current;
int valid;
- ts-rtask = tsk;
-
/*
* We run as a real-time thread. However, thus far
* this doesn't seem to be necessary.
@@ -168,7 +166,7 @@ static int ucb1x00_thread(void *_ts)
tsk-rt_priority = 1;
valid = 0;
- for (;;) {
+ while (!kthread_should_stop()) {
unsigned int x, y, p, val;
ts-restart = 0;
@@ -231,9 +229,6 @@ static int ucb1x00_thread(void *_ts)
msleep_interruptible(10);
}
-
- if (kthread_should_stop())
- break;
}
ts-rtask = NULL;
@@ -273,11 +268,12 @@ static int ucb1x00_ts_open(struct input_
ts-y_res = ucb1x00_ts_read_yres(ts);
ucb1x00_adc_disable(ts-ucb);
- task = kthread_run(ucb1x00_thread, ts, ktsd);
- if (!IS_ERR(task)) {
+ ts-rtask = kthread_run(ucb1x00_thread, ts, ktsd);
+ if (!IS_ERR(ts-task)) {
ret = 0;
} else {
ucb1x00_free_irq(ts-ucb, UCB_IRQ_TSPX, ts);
+ ts-rtask = NULL;
ret = -EFAULT;
}
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! Can we change this to while (!kthread_should_stop()) to make me completely happy? I still ask, and I'll keep repeating this. What is the difference between this and the reference implementation which is known to work on other hardware. I think I posted diffs already, but they were rather big and against wrong version. I'll try to get better diffs. Let's not go all out on one implementation for one set of hardware, but try to work out what we need to do to the generic reference implementation to make it work on this hardware. I did not know it is supposed to work on other devices, too. My fault. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. Hmm, diff looks quite big (attached), and I got it from lenz for 99% part. It looks like John's version is actually based on a previous revision of this driver. 8/ Oops. I have made quite a lot of cleanups to touchscreen part, and it seems to be acceptable by input people. I think it should go into drivers/input/touchscreen/collie_ts.c... Err, why should my assabet touchscreen be called collie_ts ? collie is just a platform which happens to use it - it's got no relevance to the driver naming at all. Okay, I did not quite realized it was shared. Also it looks to me like mcp.h should go into asm/arch-sa1100, so that other drivers can use it... That doesn't make sense when you have other non-SA1100 devices using mcp-core.c. Whether that happens or not I've no idea - I can't see what everyone's using out there (just like I've absolutely zero idea what collie folk are doing or not doing.) set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it breaks compilation, because struct members will not be available; at least in this version), so I doubt it has many non-SA1100 users... The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc better place? arch/arm/soc? That means that (a) we end up with another directory to accumulate crap, (b) it's not a SoC so doesn't belong in a directory named as such, (c) it means that the MCP and UCB drivers get their individual files scattered throughout the kernel tree, one in this directory, one in that directory, one in another random directory. That's far from ideal. Well, I believe that UCB layer is quite well define and it looks quite okay for touchscreen driver to be near other touchscreens... ucb-core still needs to go somewhere, if drivers/misc was vetoed, perhaps arch/arm/misc would be okay? Anyway, summarising this, the results are that what we have here is a complete and utter mess. ;( Yep :-(. So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. Okay, will do. [Is there chance to pull your tree using git? It would help a bit...] Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same Yep, will do, and sorry for the confusion. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Tue, Jul 26, 2005 at 12:06:59AM +0200, Pavel Machek wrote: Also it looks to me like mcp.h should go into asm/arch-sa1100, so that other drivers can use it... That doesn't make sense when you have other non-SA1100 devices using mcp-core.c. Whether that happens or not I've no idea - I can't see what everyone's using out there (just like I've absolutely zero idea what collie folk are doing or not doing.) set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it breaks compilation, because struct members will not be available; at least in this version), so I doubt it has many non-SA1100 users... That's not conclusive in itself - if it's only usable on SA1100 platforms, why was that ifdef added? So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. Okay, will do. [Is there chance to pull your tree using git? It would help a bit...] My git usage is limited to the final stage of my development - iow providing an integration and test bed for merging upstream. My work prior to that is all patch based (as per the tarball of patches I posted previously) with scripts to manage them - I like the power to re-order, split, merge, insert and remove patches at random, which includes whole series of patches vs individual patches themselves. Consequently, if I were to publish my git trees, what you'll find is that they're indentical copies of Linus' tree except for maybe when Linus is away, or hasn't pulled that night, or... What you're actually seeing with the UCB stuff is the effect of me stopping maintaining the -rmk trees - code effectively got dropped from public view at that point, and I'm not going to start publishing such a tree any time soon. It completely detracts from the task of ensuring mainline kernels work for ARM - since the -rmk tree is/was seen as the tree for everything ARM to be merged into, and hence upstream merging became my problem. No, never again will I make a fool of myself like that. Hence, I'll never again publish a kernel tree myself, except maybe for very limited purposes. However, if the UCB stuff is going to get worked on, I don't mind setting up, maintaining and publishing a git tree for that that, provided it then vanishes once merged into mainline. That falls within the very limited purposes clause above. -- Russell King Linux kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote: > On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: > > This adds support for reading ADCs (etc), neccessary to operate touch > > screen on Sharp Zaurus sl-5500. > > I would like to know what the diffs are between my version (attached) > and this version before they get applied. > > The only reason my version has not been submitted is because it lives > in the drivers/misc directory, and mainline kernel folk don't like > drivers which clutter up that directory. In fact, I had been told > that drivers/misc should remain completely empty - which makes this > set of miscellaneous drivers homeless. but clearly drivers/misc/ is not empty, unless you mean at its top level. The IBM ASM service processor driver is there (added in 2.6.x) as well as some hdpuftrs/ driver, which is not in any Kconfig file or defconfig file. :( --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Sun, 2005-07-24 at 17:47 +0100, Russell King wrote: > On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: > > This adds support for reading ADCs (etc), neccessary to operate touch > > screen on Sharp Zaurus sl-5500. > > I would like to know what the diffs are between my version (attached) > and this version before they get applied. > > The only reason my version has not been submitted is because it lives > in the drivers/misc directory, and mainline kernel folk don't like > drivers which clutter up that directory. In fact, I had been told > that drivers/misc should remain completely empty - which makes this > set of miscellaneous drivers homeless. I've been wondering about suggesting the creation of a drivers/soc directory. The idea would be for it to contain "system on chip" type support code. I use that description loosely to fit any code which needs to support drivers in multiple driver subsections. An example use in my Zaurus tree is the TSC2101 which contains a touchscreen, battery monitoring and sound. Handhelds.org has devices such as the ASIC2/ASIC3 in the ipaqs (and other handhelds) which cover many different drivers subsections. Where practical, the sub drivers such as the touchscreen could be placed into the specific driver areas such as drivers/input/touchscreen/ but the core chip specific support would be in drivers/soc and the files would be connected. Would that be acceptable in mainline? Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: > This adds support for reading ADCs (etc), neccessary to operate touch > screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ucb1x00.tar.gz Description: GNU Zip compressed data
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ucb1x00.tar.gz Description: GNU Zip compressed data
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Sun, 2005-07-24 at 17:47 +0100, Russell King wrote: On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. I've been wondering about suggesting the creation of a drivers/soc directory. The idea would be for it to contain system on chip type support code. I use that description loosely to fit any code which needs to support drivers in multiple driver subsections. An example use in my Zaurus tree is the TSC2101 which contains a touchscreen, battery monitoring and sound. Handhelds.org has devices such as the ASIC2/ASIC3 in the ipaqs (and other handhelds) which cover many different drivers subsections. Where practical, the sub drivers such as the touchscreen could be placed into the specific driver areas such as drivers/input/touchscreen/ but the core chip specific support would be in drivers/soc and the files would be connected. Would that be acceptable in mainline? Richard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote: On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote: This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. but clearly drivers/misc/ is not empty, unless you mean at its top level. The IBM ASM service processor driver is there (added in 2.6.x) as well as some hdpuftrs/ driver, which is not in any Kconfig file or defconfig file. :( --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] Touchscreen support for sharp sl-5500
This adds support for reading ADCs (etc), neccessary to operate touch
screen on Sharp Zaurus sl-5500.
Please apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -30,3 +30,20 @@ config IBM_ASM
endmenu
+menu "Multimedia Capabilities Port drivers"
+
+config MCP
+ tristate
+
+# Interface drivers
+config MCP_SA1100
+ tristate "Support SA1100 MCP interface"
+ depends on ARCH_SA1100
+ select MCP
+
+# Chip drivers
+config MCP_UCB1200
+ tristate "Support for UCB1200 / UCB1300"
+ depends on MCP
+
+endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -5,3 +5,11 @@ obj- := misc.o # Dummy rule to force bui
obj-$(CONFIG_IBM_ASM) += ibmasm/
obj-$(CONFIG_HDPU_FEATURES)+= hdpuftrs/
+
+obj-$(CONFIG_MCP) += mcp-core.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
+
+obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
+
+ucb1400-core-y := ucb1x00-core.o mcp-ac97.o
+obj-$(CONFIG_UCB1400_TS) += ucb1400-core.o ucb1x00-ts.o
diff --git a/drivers/misc/mcp-core.c b/drivers/misc/mcp-core.c
new file mode 100644
--- /dev/null
+++ b/drivers/misc/mcp-core.c
@@ -0,0 +1,257 @@
+/*
+ * linux/drivers/misc/mcp-core.c
+ *
+ * Copyright (C) 2001 Russell King
+ *
+ * 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 Foundation; either version 2 of the License.
+ *
+ * Generic MCP (Multimedia Communications Port) layer. All MCP locking
+ * is solely held within this file.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define to_mcp(d) ((struct mcp *)(d)->platform_data)
+#define to_mcp_driver(d) container_of(d, struct mcp_driver, drv)
+
+static int mcp_bus_match(struct device *dev, struct device_driver *drv)
+{
+ return 1;
+}
+
+static int mcp_bus_probe(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ struct mcp_driver *drv = to_mcp_driver(dev->driver);
+
+ return drv->probe(mcp);
+}
+
+static int mcp_bus_remove(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ struct mcp_driver *drv = to_mcp_driver(dev->driver);
+
+ drv->remove(mcp);
+ return 0;
+}
+
+static int mcp_bus_suspend(struct device *dev, u32 state)
+{
+ struct mcp *mcp = to_mcp(dev);
+ int ret = 0;
+
+ if (dev->driver) {
+ struct mcp_driver *drv = to_mcp_driver(dev->driver);
+
+ ret = drv->suspend(mcp, state);
+ }
+ return ret;
+}
+
+static int mcp_bus_resume(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ int ret = 0;
+
+ if (dev->driver) {
+ struct mcp_driver *drv = to_mcp_driver(dev->driver);
+
+ ret = drv->resume(mcp);
+ }
+ return ret;
+}
+
+static struct bus_type mcp_bus_type = {
+ .name = "mcp",
+ .match = mcp_bus_match,
+ .suspend= mcp_bus_suspend,
+ .resume = mcp_bus_resume,
+};
+
+/**
+ * mcp_set_telecom_divisor - set the telecom divisor
+ * @mcp: MCP interface structure
+ * @div: SIB clock divisor
+ *
+ * Set the telecom divisor on the MCP interface. The resulting
+ * sample rate is SIBCLOCK/div.
+ */
+void mcp_set_telecom_divisor(struct mcp *mcp, unsigned int div)
+{
+ spin_lock_irq(>lock);
+ mcp->set_telecom_divisor(mcp, div);
+ spin_unlock_irq(>lock);
+}
+
+/**
+ * mcp_set_audio_divisor - set the audio divisor
+ * @mcp: MCP interface structure
+ * @div: SIB clock divisor
+ *
+ * Set the audio divisor on the MCP interface.
+ */
+void mcp_set_audio_divisor(struct mcp *mcp, unsigned int div)
+{
+ spin_lock_irq(>lock);
+ mcp->set_audio_divisor(mcp, div);
+ spin_unlock_irq(>lock);
+}
+
+/**
+ * mcp_reg_write - write a device register
+ * @mcp: MCP interface structure
+ * @reg: 4-bit register index
+ * @val: 16-bit data value
+ *
+ * Write a device register. The MCP interface must be enabled
+ * to prevent this function hanging.
+ */
+void mcp_reg_write(struct mcp *mcp, unsigned int reg, unsigned int val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ mcp->reg_write(mcp, reg, val);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+/**
+ * mcp_reg_read - read a device register
+ * @mcp: MCP interface structure
+ * @reg: 4-bit register index
+ *
+ * Read a device register and return its value. The MCP interface
+ * must be enabled to prevent this function hanging.
+ */
+unsigned int mcp_reg_read(struct mcp *mcp, unsigned int reg)
+{
+ unsigned long flags;
+
[patch 1/2] Touchscreen support for sharp sl-5500
This adds support for reading ADCs (etc), neccessary to operate touch
screen on Sharp Zaurus sl-5500.
Please apply,
Pavel
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -30,3 +30,20 @@ config IBM_ASM
endmenu
+menu Multimedia Capabilities Port drivers
+
+config MCP
+ tristate
+
+# Interface drivers
+config MCP_SA1100
+ tristate Support SA1100 MCP interface
+ depends on ARCH_SA1100
+ select MCP
+
+# Chip drivers
+config MCP_UCB1200
+ tristate Support for UCB1200 / UCB1300
+ depends on MCP
+
+endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -5,3 +5,11 @@ obj- := misc.o # Dummy rule to force bui
obj-$(CONFIG_IBM_ASM) += ibmasm/
obj-$(CONFIG_HDPU_FEATURES)+= hdpuftrs/
+
+obj-$(CONFIG_MCP) += mcp-core.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
+
+obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
+
+ucb1400-core-y := ucb1x00-core.o mcp-ac97.o
+obj-$(CONFIG_UCB1400_TS) += ucb1400-core.o ucb1x00-ts.o
diff --git a/drivers/misc/mcp-core.c b/drivers/misc/mcp-core.c
new file mode 100644
--- /dev/null
+++ b/drivers/misc/mcp-core.c
@@ -0,0 +1,257 @@
+/*
+ * linux/drivers/misc/mcp-core.c
+ *
+ * Copyright (C) 2001 Russell King
+ *
+ * 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 Foundation; either version 2 of the License.
+ *
+ * Generic MCP (Multimedia Communications Port) layer. All MCP locking
+ * is solely held within this file.
+ */
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/smp.h
+#include linux/device.h
+
+#include asm/dma.h
+#include asm/system.h
+
+#include asm/arch-sa1100/mcp.h
+
+#define to_mcp(d) ((struct mcp *)(d)-platform_data)
+#define to_mcp_driver(d) container_of(d, struct mcp_driver, drv)
+
+static int mcp_bus_match(struct device *dev, struct device_driver *drv)
+{
+ return 1;
+}
+
+static int mcp_bus_probe(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ struct mcp_driver *drv = to_mcp_driver(dev-driver);
+
+ return drv-probe(mcp);
+}
+
+static int mcp_bus_remove(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ struct mcp_driver *drv = to_mcp_driver(dev-driver);
+
+ drv-remove(mcp);
+ return 0;
+}
+
+static int mcp_bus_suspend(struct device *dev, u32 state)
+{
+ struct mcp *mcp = to_mcp(dev);
+ int ret = 0;
+
+ if (dev-driver) {
+ struct mcp_driver *drv = to_mcp_driver(dev-driver);
+
+ ret = drv-suspend(mcp, state);
+ }
+ return ret;
+}
+
+static int mcp_bus_resume(struct device *dev)
+{
+ struct mcp *mcp = to_mcp(dev);
+ int ret = 0;
+
+ if (dev-driver) {
+ struct mcp_driver *drv = to_mcp_driver(dev-driver);
+
+ ret = drv-resume(mcp);
+ }
+ return ret;
+}
+
+static struct bus_type mcp_bus_type = {
+ .name = mcp,
+ .match = mcp_bus_match,
+ .suspend= mcp_bus_suspend,
+ .resume = mcp_bus_resume,
+};
+
+/**
+ * mcp_set_telecom_divisor - set the telecom divisor
+ * @mcp: MCP interface structure
+ * @div: SIB clock divisor
+ *
+ * Set the telecom divisor on the MCP interface. The resulting
+ * sample rate is SIBCLOCK/div.
+ */
+void mcp_set_telecom_divisor(struct mcp *mcp, unsigned int div)
+{
+ spin_lock_irq(mcp-lock);
+ mcp-set_telecom_divisor(mcp, div);
+ spin_unlock_irq(mcp-lock);
+}
+
+/**
+ * mcp_set_audio_divisor - set the audio divisor
+ * @mcp: MCP interface structure
+ * @div: SIB clock divisor
+ *
+ * Set the audio divisor on the MCP interface.
+ */
+void mcp_set_audio_divisor(struct mcp *mcp, unsigned int div)
+{
+ spin_lock_irq(mcp-lock);
+ mcp-set_audio_divisor(mcp, div);
+ spin_unlock_irq(mcp-lock);
+}
+
+/**
+ * mcp_reg_write - write a device register
+ * @mcp: MCP interface structure
+ * @reg: 4-bit register index
+ * @val: 16-bit data value
+ *
+ * Write a device register. The MCP interface must be enabled
+ * to prevent this function hanging.
+ */
+void mcp_reg_write(struct mcp *mcp, unsigned int reg, unsigned int val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(mcp-lock, flags);
+ mcp-reg_write(mcp, reg, val);
+ spin_unlock_irqrestore(mcp-lock, flags);
+}
+
+/**
+ * mcp_reg_read - read a device register
+ * @mcp: MCP interface structure
+ * @reg: 4-bit register index
+ *
+ * Read a device register and return its value. The MCP interface
+ * must be enabled to prevent this function hanging.
+ */
