linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: larry <larry.lai@yunjingtech.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: lee@kernel.org, linus.walleij@linaro.org, pavel@ucw.cz,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-leds@vger.kernel.org, GaryWang@aaeon.com.tw,
	musa.lin@yunjingtech.com, jack.chang@yunjingtech.com,
	noah.hung@yunjingtech.com
Subject: Re: [PATCH V7 2/3] pinctrl: Add support pin control for UP board CPLD/FPGA
Date: Fri, 1 Dec 2023 16:40:57 +0800	[thread overview]
Message-ID: <e21cbadf-84a9-93b0-ea07-924c17df8eb4@yunjingtech.com> (raw)
In-Reply-To: <ZVOBz8-tahhrVmO-@smile.fi.intel.com>

Hi Andy,
   Sorry, replied Gary's mail again for plain text format & mail client
as Jones's suggestion.

On 14/11/2023 22:18, Andy Shevchenko wrote:
> On Tue, Oct 31, 2023 at 09:51:18AM +0800, larry.lai wrote:
>> The UP Squared board <http://www.upboard.com> implements certain
>> features (pin control) through an on-board FPGA.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Gary Wang <garywang@aaeon.com.tw>
>> Signed-off-by: larry.lai <larry.lai@yunjingtech.com>
> 
> Same comments as per previous patch.
> 
> ...
> 
>> +	help
>> +	  Pin controller for the FPGA GPIO lines on UP boards. Due to the
>> +	  hardware layout, these are meant to be controlled in tandem with their
>> +	  corresponding Intel SoC GPIOs.
> 
> + blank line here.
> 
>> +	  To compile this driver as a module, choose M here: the module
>> +	  will be called pinctrl-upboard.
> 
> ...
> 
>> + * UP Board HAT pin controller driver
>> + * remapping native pin to RPI pin and set CPLD pin dir
> 
> Same comment to all the comments as per previous patch.
> 
> ...
> 
> + Missing bits.h, types.h and maybe others.
> 
>> +#include <linux/dmi.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/gpio/driver.h>
> 
>> +#include <linux/kernel.h>
> 
> array_size.h ?

will remove.

> 
>> +#include <linux/mfd/upboard-fpga.h>
>> +#include <linux/module.h>
> 
>> +#include <linux/pinctrl/pinctrl.h>
>> +#include <linux/pinctrl/pinmux.h>
> 
> Move this...
> 
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/seq_file.h>
>> +#include <linux/string.h>
> 
> ...here to be a group of pinctrl headers.

will do.

> 
> 
>> +#include "core.h"
> 
> ...
> 
> 
>> +#include "intel/pinctrl-intel.h"
> 
> I do not think it's correct use of the header.

see below with pad regs define.

> 
> ...
> 
>> +/* for older kernel lost DIRECTION_IN/OUT definition */
>> +#ifndef GPIO_LINE_DIRECTION_IN
>> +#define GPIO_LINE_DIRECTION_IN		1
>> +#define GPIO_LINE_DIRECTION_OUT		0
>> +#endif
> 
> Are you submitting this to older kernel here? No. Then why this?

used in our dkms driver, will remove for upstream.

> 
> ...
> 
>> +/* Offset from regs */
>> +#define REVID						0x000
>> +#define REVID_SHIFT					16
>> +#define REVID_MASK					GENMASK(31, 16)
>> +#define PADBAR						0x00c
>> +
>> +/* Offset from pad_regs */
>> +#define PADCFG0						0x000
>> +#define PADCFG0_RXEVCFG_SHIFT		25
>> +#define PADCFG0_RXEVCFG_MASK		GENMASK(26, 25)
>> +#define PADCFG0_RXEVCFG_LEVEL		0
>> +#define PADCFG0_RXEVCFG_EDGE		1
>> +#define PADCFG0_RXEVCFG_DISABLED	2
>> +#define PADCFG0_RXEVCFG_EDGE_BOTH	3
>> +#define PADCFG0_PREGFRXSEL			BIT(24)
>> +#define PADCFG0_RXINV				BIT(23)
>> +#define PADCFG0_GPIROUTIOXAPIC		BIT(20)
>> +#define PADCFG0_GPIROUTSCI			BIT(19)
>> +#define PADCFG0_GPIROUTSMI			BIT(18)
>> +#define PADCFG0_GPIROUTNMI			BIT(17)
>> +#define PADCFG0_PMODE_SHIFT			10
>> +#define PADCFG0_PMODE_MASK			GENMASK(13, 10)
>> +#define PADCFG0_PMODE_GPIO			0
>> +#define PADCFG0_GPIORXDIS			BIT(9)
>> +#define PADCFG0_GPIOTXDIS			BIT(8)
>> +#define PADCFG0_GPIORXSTATE			BIT(1)
>> +#define PADCFG0_GPIOTXSTATE			BIT(0)
>> +
>> +#define PADCFG1						0x004
>> +#define PADCFG1_TERM_UP				BIT(13)
>> +#define PADCFG1_TERM_SHIFT			10
>> +#define PADCFG1_TERM_MASK			GENMASK(12, 10)
>> +#define PADCFG1_TERM_20K			BIT(2)
>> +#define PADCFG1_TERM_5K				BIT(1)
>> +#define PADCFG1_TERM_1K				BIT(0)
>> +#define PADCFG1_TERM_833			(BIT(1) | BIT(0))
>> +
>> +#define PADCFG2						0x008
>> +#define PADCFG2_DEBEN				BIT(0)
>> +#define PADCFG2_DEBOUNCE_SHIFT		1
>> +#define PADCFG2_DEBOUNCE_MASK		GENMASK(4, 1)
>> +
>> +#define DEBOUNCE_PERIOD_NSEC		31250
>> +
>> +/* Additional features supported by the hardware */
>> +#define PINCTRL_FEATURE_DEBOUNCE	BIT(0)
>> +#define PINCTRL_FEATURE_1K_PD		BIT(1)
> 
> Huh?! No way it should be here in _any_ form!

will remove, but we need set pad mode at runtime for HAP pins GPIO,
it's not a good way but get register offset from intel_pinctrl structure
can reduce data for each boards.

> 
> ...
> 
> I'm done with review as design wise this one is broken. Please, redesign and
> reimplement. Also split this per platform addition (as suggested for MFD),
> it will be easier to review.

will try to modify as your suggestion.

>
Best Regards,
Larry


  parent reply	other threads:[~2023-12-01  8:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31  1:51 [PATCH V7 0/3] Add support control UP board CPLD/FPGA pin control larry.lai
2023-10-31  1:51 ` [PATCH V7 1/3] mfd: Add support for UP board CPLD/FPGA larry.lai
2023-11-14 14:11   ` Andy Shevchenko
2023-11-24  9:11     ` GaryWang 汪之逸
2023-11-27  9:37       ` Lee Jones
2023-11-30  6:19     ` GaryWang 汪之逸
2023-12-01  8:19     ` larry
2023-10-31  1:51 ` [PATCH V7 2/3] pinctrl: Add support pin control " larry.lai
2023-11-01 10:42   ` Krzysztof Kozlowski
2023-11-13 14:15   ` Linus Walleij
2023-11-13 16:35     ` Andy Shevchenko
2023-11-14 14:18   ` Andy Shevchenko
2023-11-24  9:11     ` GaryWang 汪之逸
2023-11-30  6:19     ` GaryWang 汪之逸
2023-11-30 11:21       ` Lee Jones
2023-12-01  8:40     ` larry [this message]
2023-10-31  1:51 ` [PATCH V7 3/3] leds: Add support for UP board CPLD onboard LEDS larry.lai
2023-11-01 10:44   ` Krzysztof Kozlowski
2023-11-14 14:20 ` [PATCH V7 0/3] Add support control UP board CPLD/FPGA pin control Andy Shevchenko

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=e21cbadf-84a9-93b0-ea07-924c17df8eb4@yunjingtech.com \
    --to=larry.lai@yunjingtech.com \
    --cc=GaryWang@aaeon.com.tw \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jack.chang@yunjingtech.com \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=musa.lin@yunjingtech.com \
    --cc=noah.hung@yunjingtech.com \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).