On Fri, Jul 4, 2008 at 10:26 PM, Hans J. Koch <hjk@linutronix.de> wrote:
This is crap. I'm sure you're having all sorts of problems with broken
FPGAs, but that's outside the scope of this discussion. If a device
needs to be acknowledged or not to deassert the interrupt line is
totally device specific and it has nothing to do with broken hardware
design.
As much as I enjoy arguing with you, we are doing this because there
is need for it. =)
Yes, and that's fine.
It's not a matter if it's possible or not. It's a matter of abstraction.
Exactly what do you mean by "so much objections"? You're the only one
blocking this, and it looks to me like you're just pushing your own
policy without thinking outside your little device driver box.
I'm not doing this because i want to change how UIO is working in
general or push some generic solution and force everyone to use it. I
_only_ want to export _our_ devices. If other people want to export
their devices the same way, then that's great. Uwe seems to want to do
that. Why do you feel you have to stop us? It's pretty natural for you
to have no insight in we are doing on the SuperH side, and because of
that you should just take our word for what we need and work with us
to resolve technical issues.
The advantage is that we don't need to be aware of device-specific
details in the kernel.
You seem to be happy with the usual UIO way of splitting the driver
code in a kernel stub and a user space driver. Good for you, but we
want to skip the device specific kernel stub.
For our needs - on-chip memory mapped hardware blocks - we'd like to
replace the kernel stub with a single reusable implementation, and
that way we end up with a single per-hardware block specific driver -
in user space. This way we can let people with RTOS experience do
their thing in user space, without worrying about them overwriting our
precious kernel data structures.
You are right that we still need to feed the platform driver
information about the device. We only want to pass the base address of
the hardware block and the interrupt number. There is no point for us
to be aware about the inner workings of the hardware block - we only
want to export the thing to user space and be done with it. And in
some rare cases we don't even have documentation for a certain block,
so acknowledging interrupts from inside the kernel is out of the
question.
Wrong. It's not always that easy. The way to acknowledge interrupts is
very device specific. A good in-kernel example of not so easy
acknowledging would be drivers/input/touchscreen/ads7846.c. Look at
the interrupt handler code ads7846_irq() - what does it do? Exactly
what the User IRQ Mode is doing - using disable_irq(). The reason for
this is slow SPI bus speed. It takes a long time to write to the touch
screen controller over the serial bus, and the interrupt line will
remain asserted until the device has been acknowledged properly.
Again, exactly how to acknowledge an interrupt is device or hardware
block specific. And it's not always as easy as writing to a single
register. Of course we will acknowledge the device in the way the chip
designer want us to, but we will do it from user space.
I'm not forcing you to use my code on your platforms. Feel free to use
it if it does what you want to do, if not you should just keep on
using your regular code. How can this be my problem? Don't NAK just
because the code isn't suitable for all your needs. I'm not trying to
solve your needs. I'm posting this code because _we_ need it.
No, you are wrong. It really doesn't get tested. Mainly because you
are refusing to accept my code. UIO _would_ be used and tested if we
can agree on these 50 lines of code and get on with our lives.
You still haven't given any real technical reason why it's better to
acknowledge in kernel space over acknowledging in user space. Having
all hardware block / device specific code in a single place will keep
interfaces clean and make maintainance easier for us.
SuperH hardware just happens to use unique interrupt lines for most
internal hardware blocks, and we'd like to take advantage of that and
skip the entire UIO kernel stub thing.
There is nothing suboptimal about it.
Thank you.
It is and has been working for more than a month. It's not suitable
for submission yet though, mainly since the UIO kernel interface is
unstable until we've agreed on this patch. The kernel interface
changed with the write() re-enabling method, remember? And I feel this
may happen again since it seems very hard for us to agree on things.
That may look like nonsense to you, but you fail to see the big picture if so.
No, I don't think so. But I do think you should work a bit on
understanding your position in the community and pay closer attention
to people with more experience than you. I may understand that you
feel the need to argue with me - since I only have a few small
contributions behind me - but when you're not listening to what Paul
has to say then you're just stupid. Stop ignoring people above you in
the food chain.
You can use git shortlog to get statistics.
/ magnus
--
