Re: [PATCH v1] gpio: keystone: add dsp gpio controller driver

From: Santosh Shilimkar
Date: Thu Jul 24 2014 - 11:40:58 EST

On Thursday 24 July 2014 11:23 AM, Linus Walleij wrote:
> On Thu, Jul 24, 2014 at 4:21 PM, Santosh Shilimkar
> <santosh.shilimkar@xxxxxx> wrote:
>> On Thursday 24 July 2014 10:12 AM, Linus Walleij wrote:
>>> On Wed, Jul 23, 2014 at 5:25 PM, Santosh Shilimkar
>>> <santosh.shilimkar@xxxxxx> wrote:
>>>> I will try to answer this. This IP is indeed a GPIO block
>>>> but the IO's are used just OUTPUT lines from Linux
>>>> HOST perspective. These IOs are connected to the DSPs
>>>> as input/IRQ lines.
>>> So the DSP is another discrete IC, and could be something
>>> different, so this is board-level information?
>>> I'm really worrying whether this is general purpose or not :-/
>> Am not sure I follow you. This IP is completely controlled
>> by Linux OS to generate output signals. How does it matter
>> whether its connected to a peripheral or a discrete IC.
> What matters to me is whether it is general purpose or
> not, and what the use case is.
> The Kconfig symbol is called GPIO_KEYSTONE_DSP
> not GPIO_KEYSTONE. That does not sound very general
> purpose at all. Why is "DSP" at the end of that config
> option if it is general purpose?
That DSP is to just give different name since there
is another GPIO IP on keystone. We can get rid of that
DSP name but I think thats not your concern.

> And we know the Keystone
> already has another GPIO block, selected from the
> Kconfig symbol GPIO_DAVINCI. Probably that is the
> only real GPIO on this system.
Am sorry to say but real, unreal is very debatable.
A SOC can have more than one IP instance for different

> And the use case doesn't seem to be exactly for
> things like driving leds, reading keys, bit-banging SPI
> or MMC card detect or other such common cases.
> It seems to be to trigger IRQs on another processor and
> nothing else. Not general purpose.
> If writing bit such and such in some register has the
> effect of pulling a bit high or low in some other IP
> is not GPIO. It should be part of the driver for that
> other IP block.
Using GPIO as an interrupt line is a legitimate
usecase already supported GPIO lib.

> Further you wrote:
>> The DSP-ARM host IPC mechanism used on
>> Keystone is Linux user-space based and it does as
>> one of the component.
> And given that it's already hinted that this is actually
> only there to aid some userspace driver I'm even *less*
> interested in having it in the GPIO subsystem.
> Shoehorning this into the GPIO subsystem just seems
> like some convenient way to keep that DSP driver code
> in userspace instead of writing a proper kernel driver
> for the DSP.
> Like someone wants to avoid things like this:
> drivers/staging/tidspbridge
> drivers/remoteproc/omap_remoteproc.c
> drivers/remoteproc/da8xx_remoteproc.c
Not at all. The usecase is different. remoteproc's are more
for firmware download, powerup, powerdown, boot an external

> As a community maintainer, naturally doing such real
> kernel drivers is way better than trying to sneak something
> in under the radar, and now I'm worried that this is what
> is actually attempted by this driver, so I'm concerned.
I respect your view but in this particular case, I just
thought we are denying a legitimate plumbing. Because if
it doesn't fit here, fitting it in other subsystems will
be shoehorning in my view.

>> Given that this IP only output functionality is used but
>> that shouldn't matter. We have seen SOCs where GPIOs
>> are just used as input to form a Matrix Keyboard.
> Yes, that is common. And that is for example done with
> GPIO_DAVINCI which has lines out to open space
> and general purposes.
> This is not GPIO, this is DSPIO IMO.
I just think you are too much reading into that DSP name
which was just there to differentiate it from the other

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at