On Sat, Jul 4, 2015 at 12:13 AM, Grant Likely wrote:
> On Tue, Jun 2, 2015 at 2:18 PM, Linus Walleij
> wrote:
>> On Sat, May 30, 2015 at 10:29 PM, Grant Likely
>> wrote:
>>> On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
>>> wrote:
>>
> However is the MFD cell approach acceptable?
On Tue, Jun 2, 2015 at 2:18 PM, Linus Walleij wrote:
> On Sat, May 30, 2015 at 10:29 PM, Grant Likely
> wrote:
>> On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
>> wrote:
>
However is the MFD cell approach acceptable?
>>>
>>> Yes it is.
>>
>> Going back to this old conversation... Actua
On Sat, May 30, 2015 at 10:29 PM, Grant Likely
wrote:
> On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
> wrote:
>>> However is the MFD cell approach acceptable?
>>
>> Yes it is.
>
> Going back to this old conversation... Actually, I disagree. There is
> absolutely no need to go the MFD appro
On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 07, 2014 at 12:44:28PM +0200, Linus Walleij wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
>> wrote:
>> > On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>>
>> >> But I also want to bring the dev
On Mon, Jul 07, 2014 at 12:44:28PM +0200, Linus Walleij wrote:
> On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
> wrote:
> > On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>
> >> But I also want to bring the device model into question: normally
> >> when a mother device spawn
On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
wrote:
> On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>> But I also want to bring the device model into question: normally
>> when a mother device spawns children across different subsystems
>> we model them as MFD devices (dri
Hi,
Would this patch interfere with adding support for using the CBUS pins
as GPIOs while operating in normal UART mode?
Most interesting question!
Care was taken to prevent using GPIOs if the serial device is in use
and vice versa.
What about CBUS GPIO support?
Ok, so we're not extendin
On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
> On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote:
>
> > The chips can operate either in regular or in bitbang mode. Care was
> > taken to prevent using GPIOs if the serial device is in use and vice
> > versa.
>
> Very interesting
On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote:
> The chips can operate either in regular or in bitbang mode. Care was
> taken to prevent using GPIOs if the serial device is in use and vice
> versa.
Very interesting patch! I've seen USB-based GPIO things before
but never a dual-mode thing.
On Mon, Jun 09, 2014 at 03:21:55PM +0200, Sascha Silbe wrote:
> Most FTDI USB serial / parallel adapter chips support an asynchronous
> "bitbang" mode. Make this functionality available as a GPIO controller
> so they can be used with the Linux GPIO API instead of requiring
> special user space soft
Hello.
On 06/09/2014 06:23 PM, One Thousand Gnomes wrote:
#include
#include
+#ifdef CONFIG_GPIOLIB
+#include
+#endif
Please create a new struct, a new file and put all the GPIO stuff in
there rather than #if bombing the driver.
You can then declare blank methods for the gpio stuff
> #include
> #include
> +#ifdef CONFIG_GPIOLIB
> +#include
> +#endif
Please create a new struct, a new file and put all the GPIO stuff in
there rather than #if bombing the driver.
You can then declare blank methods for the gpio stuff if GPIO is not
compiled in - ie in the headers
#ifdef C
Most FTDI USB serial / parallel adapter chips support an asynchronous
"bitbang" mode. Make this functionality available as a GPIO controller
so they can be used with the Linux GPIO API instead of requiring
special user space software that only works with this particular
family of chips.
The chips
13 matches
Mail list logo
