be really big, do we want
(in the long run, not now) open up to the idea to slot in
hardware-accelerated memcpy() here?
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
l follow adding devm_krealloc_array() which is
> needed in the xilinx adc driver.
The series:
Acked-by: Linus Walleij
I really like this.
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
fig
it does:
select IRQ_SIM
Then this is used:
include/linux/irq_sim.h
This is intended for simulating IRQs and both GPIO and IIO use it.
I think this inserts IRQs from debugfs and I have no idea how
flexible that is.
If it is suitable for what you want to do I don't know but it
I suspect
irq_chip would be best because all drivers using GPIOs for interrupts
are expecting interrupts, and it would be an enormous task to
change them all and really annoying to create a new mechanism
on the side.
Yours,
Linus Walleij
___
V
On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote:
> On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote:
> > On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
> > wrote:
>
> > What we need to understand is if your new usecase is an outlier
> >
very time we add something new (and we will).
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
other messages
have been sent in .irq_bus_sync_unlock()
so that the next GPIO IRQ can be dispatched after that.
(Is this how messaged signalled interrupts work? No idea.
When in doubt ask the IRQ maintainers.)
Thanks,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
nux.git/tree/tools/gpio/gpio-event-mon.c
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
We really need a virtio GPIO driver, no doubt, so if everyone could
just work toward that goal and compromise with their specific pet
peeves that would be great.
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.li
rpmsg is conceptually a child of virtio: when the
subsystem was proposed by TI Arnd noted that virtio has large
similarities in shared memory transport and as the potential reuse
for buffer handling etc was excellent virtio was used as
a base for rpmsg/remot
gt;
> Based on the initial work posted by:
> "Enrico Weigelt, metux IT consult" .
>
> Signed-off-by: Viresh Kumar
I see there is a dependency that needs to be fixed but
the driver looks good to me:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
__
work item to allow sleep-able operations.
>
> Signed-off-by: Viresh Kumar
Looks good to me from a GPIO point of view:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
Virtualization mailing list
Virtualization@lists.linux-fo
nn (v1)
> Cc: Thomas Zimmermann
> Cc: Noralf Trønnes
> Cc: Gerd Hoffmann
> Cc: Eric Anholt
> Cc: Emil Velikov
> Cc: virtualization@lists.linux-foundation.org
> Cc: Linus Walleij
> Signed-off-by: Daniel Vetter
Makes perfect sense.
Revi
14 matches
Mail list logo
