All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [PATCH v2] gpio: octeon_gpio: Add GPIO controller driver for Octeon
Date: Tue, 21 Jul 2020 13:03:16 +0200	[thread overview]
Message-ID: <206e2fc1-3284-6520-c9ba-a52191501a78@denx.de> (raw)
In-Reply-To: <187a977eaafb9384b53e21b6d2ea6d3f152c769b.camel@gmail.com>

Hi Daniel,

On 18.07.20 15:25, Daniel Schwierzeck wrote:
> 
>> From: Suneel Garapati <sgarapati@marvell.com>
>>
>> Add support for GPIO controllers found on Octeon II/III and Octeon TX
>> TX2 SoC platforms.
>>
>> Signed-off-by: Aaron Williams <awilliams@marvell.com>
>> Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
>> Cc: Aaron Williams <awilliams@marvell.com>
>> Cc: Chandrakala Chavva <cchavva@marvell.com>
>> ---
>> v2 (Stefan):
>> - Removed #ifdef's for Octeon vs OcteonTX/TX2 completely
>>    The differentiation is now made via driver data / compatible
>>    string
>>
>> RFC -> v1 (Stefan)
>> - Separated this patch from the OcteonTX/TX2 RFC patch series into a
>>    single patch. This is useful, as the upcoming MIPS Octeon support will
>>    use this GPIO driver.
>> - Added MIPS Octeon II/III support (big endian). Rename driver and its
>>    function names from "octeontx" to "octeon" to better match all Octeon
>>    platforms.
>> - Moved from union to defines / bitmasks. This makes the driver usage
>>    on little- and big-endian platforms much easier.
>> - Used clrbits_64() instead of clrbits_le64() and friends to support
>>    usage on little- and big-endian systems
>> - Removed dev->req_seq assignment
>> - Enhanced Kconfig text
>> - Rewrote GPIO_BIT macro
>> - Dropped many macros to calculate the registers offsets and implemented
>>    simple functions for this (easier to read)
>> - Used GENMASK_ULL and FIELD_GET helpers
>> - Minor cosmetic changes (dropped brackets etc)
>> - Reword commit text and subject
>>
>>   drivers/gpio/Kconfig       |  10 ++
>>   drivers/gpio/Makefile      |   1 +
>>   drivers/gpio/octeon_gpio.c | 253 +++++++++++++++++++++++++++++++++++++
>>   3 files changed, 264 insertions(+)
>>   create mode 100644 drivers/gpio/octeon_gpio.c
>>
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index d87f6cc105..451896f400 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -316,6 +316,16 @@ config PIC32_GPIO
>>   	help
>>   	  Say yes here to support Microchip PIC32 GPIOs.
>>   
>> +config OCTEON_GPIO
>> +	bool "Octeon II/III/TX/TX2 GPIO driver"
>> +	depends on DM_GPIO && (ARCH_OCTEON || ARCH_OCTEONTX || ARCH_OCTEONTX2)
>> +	default y
>> +	help
>> +	  Add support for the Marvell Octeon GPIO driver. This is used with
>> +	  various Octeon parts such as Octeon II/III and OcteonTX/TX2.
>> +	  Octeon II/III has 32 GPIOs (count defined via DT) and OcteonTX/TX2
>> +	  has 64 GPIOs (count defined via internal register).
>> +
> 
> found another issue:
> 
> drivers/gpio/octeon_gpio.c: In function 'octeon_gpio_probe':
> drivers/gpio/octeon_gpio.c:189:16: warning: implicit declaration of
> function 'dm_pci_map_bar'; did you mean 'pci_map_bar'? [-Wimplicit-
> function-declaration]
>    189 |   priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0,
>        |                ^~~~~~~~~~~~~~
>        |                pci_map_bar
> drivers/gpio/octeon_gpio.c:189:14: warning: assignment to 'void *' from
> 'int' makes pointer from integer without a cast [-Wint-conversion]
>    189 |   priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0,
>        |              ^

Ah, I did not see this in my local builds, as I have enabled DM_PCI
here and forgot to add this dependency.

> due to the dependency on DM_PCI you need to express this in Kconfig
> with "depends on DM_PCI ...". Alternatively you need to wrap the PCI
> specific code with a "#ifdef CONFIG_DM_PCI" as the DM_PCI specific
> function prototypes in pci.h are also wrapped with "#ifdef
> CONFIG_DM_PCI". The former option will build and link DM PCI code which
> is not used and therefore bloats the U-Boot binary.
> 
> I guess the choice mainly depends on whether you'll add a PCI host
> controller driver for Octeon MIPS64 in the future and can live with the
> extra but unused PCI code until then.

We can definitely live with the temporarily unused PCI code. I don't
want to add these #ifdefs again, which I removed explicitly upon Simon's
request.

To solve this, I would prefer to add a "select DM_PCI & PCI" to
arch/mips/Kconfig for Octeon, as this PCI probing construct is not
only used in this GPIO driver, but also in many other drivers shared
between MIPS Octeon and the also upcoming ARM64 Octeon TX/TX2 support,
like I2C, SPI etc. Here all devices are PCI based hence the PCI probing
dependency.

Is this okay with you? Or should I stay with the dependency in the
drivers Kconfig file?

>>   config STM32_GPIO
>>   	bool "ST STM32 GPIO driver"
>>   	depends on DM_GPIO && (ARCH_STM32 || ARCH_STM32MP)
>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
>> index 7638259007..eb6364adb4 100644
>> --- a/drivers/gpio/Makefile
>> +++ b/drivers/gpio/Makefile
>> @@ -58,6 +58,7 @@ obj-$(CONFIG_HIKEY_GPIO)	+= hi6220_gpio.o
>>   obj-$(CONFIG_HSDK_CREG_GPIO)	+= hsdk-creg-gpio.o
>>   obj-$(CONFIG_IMX_RGPIO2P)	+= imx_rgpio2p.o
>>   obj-$(CONFIG_PIC32_GPIO)	+= pic32_gpio.o
>> +obj-$(CONFIG_OCTEON_GPIO)	+= octeon_gpio.o
>>   obj-$(CONFIG_MVEBU_GPIO)	+= mvebu_gpio.o
>>   obj-$(CONFIG_MSM_GPIO)		+= msm_gpio.o
>>   obj-$(CONFIG_$(SPL_)PCF8575_GPIO)	+= pcf8575_gpio.o
>> diff --git a/drivers/gpio/octeon_gpio.c b/drivers/gpio/octeon_gpio.c
>> new file mode 100644
>> index 0000000000..d7ac9a1910
>> --- /dev/null
>> +++ b/drivers/gpio/octeon_gpio.c
>> @@ -0,0 +1,253 @@
>> +// SPDX-License-Identifier:    GPL-2.0
>> +/*
>> + * Copyright (C) 2018 Marvell International Ltd.
>> + *
>> + * (C) Copyright 2011
>> + * eInfochips Ltd. <www.einfochips.com>
>> + * Written-by: Ajay Bhargav <ajay.bhargav@einfochips.com>
>> + *
>> + * (C) Copyright 2010
>> + * Marvell Semiconductor <www.marvell.com>
>> + */
>> +
>> +#include <common.h>
>> +#include <dm.h>
>> +#include <errno.h>
>> +#include <fdtdec.h>
>> +#include <pci_ids.h>
>> +#include <asm/bitops.h>
>> +#include <asm/gpio.h>
>> +#include <asm/io.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/compat.h>
>> +#include <dt-bindings/gpio/gpio.h>
> 
> don't use common.h anymore. Also some headers are unused. I can build
> the driver with:
> 
> #include <dm.h>
> #include <pci.h>
> #include <pci_ids.h>
> #include <asm/gpio.h>
> #include <asm/io.h>
> #include <linux/bitfield.h>
> #include <linux/compat.h>
> #include <dt-bindings/gpio/gpio.h>

Yes, thanks. I'll change this in v3.

Thanks,
Stefan

  reply	other threads:[~2020-07-21 11:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 12:19 [PATCH v2] gpio: octeon_gpio: Add GPIO controller driver for Octeon Stefan Roese
2020-05-31 14:08 ` Simon Glass
2020-07-16 18:44 ` Daniel Schwierzeck
2020-07-17  6:03   ` Stefan Roese
2020-07-18 13:25 ` Daniel Schwierzeck
2020-07-21 11:03   ` Stefan Roese [this message]
2020-07-21 14:59     ` Daniel Schwierzeck
2020-07-22  8:54       ` Stefan Roese
2020-07-22 11:47         ` Daniel Schwierzeck
2020-07-23 10:07           ` Stefan Roese
2020-07-28 18:58           ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=206e2fc1-3284-6520-c9ba-a52191501a78@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.