| Message ID | 20210608102547.4880-1-steven_lee@aspeedtech.com |
|---|---|
| Headers | show |
| Series | ASPEED sgpio driver enhancement. | expand |
On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > AST2600 supports 2 SGPIO master interfaces one with 128 pins another one > with 80 pins. > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > --- > arch/arm/boot/dts/aspeed-g6.dtsi | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi > index f96607b7b4e2..c55baaf94314 100644 > --- a/arch/arm/boot/dts/aspeed-g6.dtsi > +++ b/arch/arm/boot/dts/aspeed-g6.dtsi > @@ -377,6 +377,34 @@ > #interrupt-cells = <2>; > }; > > + sgpiom0: sgpiom@1e780500 { > + #gpio-cells = <2>; > + gpio-controller; > + compatible = "aspeed,ast2600-sgpiom-128"; > + reg = <0x1e780500 0x100>; > + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&syscon ASPEED_CLK_APB2>; The example in the binding document used ASPEED_CLK_APB. Which is correct? I assume ASPEED_CLK_APB2? > + interrupt-controller; > + bus-frequency = <12000000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_sgpm1_default>; > + status = "disabled"; > + }; > + > + sgpiom1: sgpiom@1e780600 { > + #gpio-cells = <2>; > + gpio-controller; > + compatible = "aspeed,ast2600-sgpiom-80"; > + reg = <0x1e780600 0x100>; > + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&syscon ASPEED_CLK_APB2>; > + interrupt-controller; > + bus-frequency = <12000000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_sgpm2_default>; > + status = "disabled"; > + }; > + > gpio1: gpio@1e780800 { > #gpio-cells = <2>; > gpio-controller; > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > Add an else-if condition in the probe function to check whether ngpios is > multiple of 8. > Per AST datasheet, numbers of available serial GPIO pins in Serial GPIO > Configuration Register must be n bytes. For instance, if n = 1, it means > AST SoC supports 8 GPIO pins. > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
The 06/09/2021 08:43, Andrew Jeffery wrote: > > > On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > > AST2600 supports 2 SGPIO master interfaces one with 128 pins another one > > with 80 pins. > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > --- > > arch/arm/boot/dts/aspeed-g6.dtsi | 28 ++++++++++++++++++++++++++++ > > 1 file changed, 28 insertions(+) > > > > diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi > > index f96607b7b4e2..c55baaf94314 100644 > > --- a/arch/arm/boot/dts/aspeed-g6.dtsi > > +++ b/arch/arm/boot/dts/aspeed-g6.dtsi > > @@ -377,6 +377,34 @@ > > #interrupt-cells = <2>; > > }; > > > > + sgpiom0: sgpiom@1e780500 { > > + #gpio-cells = <2>; > > + gpio-controller; > > + compatible = "aspeed,ast2600-sgpiom-128"; > > + reg = <0x1e780500 0x100>; > > + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; > > + clocks = <&syscon ASPEED_CLK_APB2>; > > The example in the binding document used ASPEED_CLK_APB. Which is correct? I assume ASPEED_CLK_APB2? > The example in the binding document is for aspeed-g5. aspeed-g5 and aspeed-g6 use different clocks. Should I add a new patch for adding an example for aspeed-g6? > > + interrupt-controller; > > + bus-frequency = <12000000>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_sgpm1_default>; > > + status = "disabled"; > > + }; > > + > > + sgpiom1: sgpiom@1e780600 { > > + #gpio-cells = <2>; > > + gpio-controller; > > + compatible = "aspeed,ast2600-sgpiom-80"; > > + reg = <0x1e780600 0x100>; > > + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; > > + clocks = <&syscon ASPEED_CLK_APB2>; > > + interrupt-controller; > > + bus-frequency = <12000000>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_sgpm2_default>; > > + status = "disabled"; > > + }; > > + > > gpio1: gpio@1e780800 { > > #gpio-cells = <2>; > > gpio-controller; > > -- > > 2.17.1 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >
On Wed, 9 Jun 2021, at 11:21, Steven Lee wrote: > The 06/09/2021 08:43, Andrew Jeffery wrote: > > > > > > On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > > > AST2600 supports 2 SGPIO master interfaces one with 128 pins another one > > > with 80 pins. > > > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > > --- > > > arch/arm/boot/dts/aspeed-g6.dtsi | 28 ++++++++++++++++++++++++++++ > > > 1 file changed, 28 insertions(+) > > > > > > diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi > > > index f96607b7b4e2..c55baaf94314 100644 > > > --- a/arch/arm/boot/dts/aspeed-g6.dtsi > > > +++ b/arch/arm/boot/dts/aspeed-g6.dtsi > > > @@ -377,6 +377,34 @@ > > > #interrupt-cells = <2>; > > > }; > > > > > > + sgpiom0: sgpiom@1e780500 { > > > + #gpio-cells = <2>; > > > + gpio-controller; > > > + compatible = "aspeed,ast2600-sgpiom-128"; > > > + reg = <0x1e780500 0x100>; > > > + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; > > > + clocks = <&syscon ASPEED_CLK_APB2>; > > > > The example in the binding document used ASPEED_CLK_APB. Which is correct? I assume ASPEED_CLK_APB2? > > > > The example in the binding document is for aspeed-g5. > aspeed-g5 and aspeed-g6 use different clocks. > Should I add a new patch for adding an example for aspeed-g6? > Oh, I missed that. Never mind then! Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
On Tue, Jun 8, 2021 at 12:26 PM Steven Lee <steven_lee@aspeedtech.com> wrote: > AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one > with 80 pins, AST2500/AST2400 SoC has 1 SGPIO master interface that > supports up to 80 pins. > In the current driver design, the max number of sgpio pins is hardcoded > in macro MAX_NR_HW_SGPIO and the value is 80. > > For supporting sgpio master interfaces of AST2600 SoC, the patch series > contains the following enhancement: > - Convert txt dt-bindings to yaml. > - Update aspeed-g6 dtsi to support the enhanced sgpio. > - Define max number of gpio pins in ast2600 platform data. Old chip > uses the original hardcoded value. > - Support muiltiple SGPIO master interfaces. > - Support up to 128 pins. > - Support wdt reset tolerance. > - Fix irq_chip issues which causes multiple sgpio devices use the same > irq_chip data. > - Replace all of_*() APIs with device_*(). > > Changes from v4: v5 looks good to me! I just need Rob's or another DT persons nod on the bindings (or timeout) before I merge it. Poke me if nothing happens. > ARM: dts: aspeed-g6: Add SGPIO node. > ARM: dts: aspeed-g5: Remove ngpios from sgpio node. These two need to be merged through the SoC tree, the rest I will handle. Yours, Linus Walleij
The 06/09/2021 18:54, Linus Walleij wrote: > On Tue, Jun 8, 2021 at 12:26 PM Steven Lee <steven_lee@aspeedtech.com> wrote: > > > AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one > > with 80 pins, AST2500/AST2400 SoC has 1 SGPIO master interface that > > supports up to 80 pins. > > In the current driver design, the max number of sgpio pins is hardcoded > > in macro MAX_NR_HW_SGPIO and the value is 80. > > > > For supporting sgpio master interfaces of AST2600 SoC, the patch series > > contains the following enhancement: > > - Convert txt dt-bindings to yaml. > > - Update aspeed-g6 dtsi to support the enhanced sgpio. > > - Define max number of gpio pins in ast2600 platform data. Old chip > > uses the original hardcoded value. > > - Support muiltiple SGPIO master interfaces. > > - Support up to 128 pins. > > - Support wdt reset tolerance. > > - Fix irq_chip issues which causes multiple sgpio devices use the same > > irq_chip data. > > - Replace all of_*() APIs with device_*(). > > > > Changes from v4: > > v5 looks good to me! > > I just need Rob's or another DT persons nod on the bindings (or timeout) > before I merge it. Poke me if nothing happens. > > > ARM: dts: aspeed-g6: Add SGPIO node. > > ARM: dts: aspeed-g5: Remove ngpios from sgpio node. > > These two need to be merged through the SoC tree, the rest I will handle. > Hi Linus, Andrew, Per the comment in the following mail https://lkml.org/lkml/2021/6/9/317 I was wondering if I should prepare v6 for the currnet solution or I should drop this patch series then prepare another patch for the new solution(piar GPIO input/output) which breaks userspace but is better than the current solution. Thanks, Steven > Yours, > Linus Walleij
On Thu, Jun 10, 2021 at 4:24 AM Steven Lee <steven_lee@aspeedtech.com> wrote: > Per the comment in the following mail > https://lkml.org/lkml/2021/6/9/317 > > I was wondering if I should prepare v6 for the currnet solution or > I should drop this patch series then prepare another patch for the > new solution(piar GPIO input/output) which breaks userspace but is > better than the current solution. I would say just go ahead with the new solution. AFAIK Aspeed has pretty tight control over what kind of userspace run on these systems. BTW please influence Aspeed to use the GPIO character device and ligpiod https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ if you are doing any kind of userspace GPIO control (which I suspect that you do). Yours, Linus Walleij
The 06/10/2021 15:50, Linus Walleij wrote: > On Thu, Jun 10, 2021 at 4:24 AM Steven Lee <steven_lee@aspeedtech.com> wrote: > > > Per the comment in the following mail > > https://lkml.org/lkml/2021/6/9/317 > > > > I was wondering if I should prepare v6 for the currnet solution or > > I should drop this patch series then prepare another patch for the > > new solution(piar GPIO input/output) which breaks userspace but is > > better than the current solution. > > I would say just go ahead with the new solution. AFAIK Aspeed > has pretty tight control over what kind of userspace run on these > systems. > > BTW please influence Aspeed to use the GPIO character device > and ligpiod > https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ > if you are doing any kind of userspace GPIO control (which I > suspect that you do). > We currently use gpioset and gpioget that provided by libgpiod to test aspeed gpio and sgpio drivers. For the current solution on AST2600, the valid range of input pins is 0 ~ 127, the valid range of output pins is 128 ~ 255. So we access input pins by the following command ``` gpioget $chipId 0 1 2 3 4 ... 127 ``` and access output pins by the following command ``` gpioset $chipId 128=1 129=0 130=1 131=1 ... 255=1 ``` The new solution will change the gpio id order as follows Input: ``` gpioget $chipId 0 2 4 6 8 ... 254 ``` Output: ``` gpioset $chipId 1=1 3=0 5=1 7=1 ... 255=1 ``` Thanks, Steven > Yours, > Linus Walleij
On Tue, Jun 08, 2021 at 06:25:37PM +0800, Steven Lee wrote: > AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one > with 80 pins. Add ast2600-sgpiom0-80 and ast2600-sgpiom-128 compatibles > and update descriptions to introduce the max number of available gpio > pins that AST2600 supported. > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > Reviewed-by: Andrew Jeffery <andrew@aj.id.au> > --- > Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > index b2ae211411ff..0e42eded3c1e 100644 > --- a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > @@ -10,9 +10,10 @@ maintainers: > - Andrew Jeffery <andrew@aj.id.au> > > description: > - This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full > - featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to > - support the following options > + This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC, > + AST2600 have two sgpio master one with 128 pins another one with 80 pins, > + AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial > + GPIO pins can be programmed to support the following options > - Support interrupt option for each input port and various interrupt > sensitivity option (level-high, level-low, edge-high, edge-low) > - Support reset tolerance option for each output port > @@ -25,6 +26,8 @@ properties: > enum: > - aspeed,ast2400-sgpio > - aspeed,ast2500-sgpio > + - aspeed,ast2600-sgpiom-80 > + - aspeed,ast2600-sgpiom-128 If the number of GPIOs is the only difference, then I don't think you should get rid of ngpios. It's one thing if it varies from one SoC to the next, but if something is per instance we should have a property. Rob
On Fri, 11 Jun 2021, at 01:53, Rob Herring wrote: > On Tue, Jun 08, 2021 at 06:25:37PM +0800, Steven Lee wrote: > > AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one > > with 80 pins. Add ast2600-sgpiom0-80 and ast2600-sgpiom-128 compatibles > > and update descriptions to introduce the max number of available gpio > > pins that AST2600 supported. > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > Reviewed-by: Andrew Jeffery <andrew@aj.id.au> > > --- > > Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > index b2ae211411ff..0e42eded3c1e 100644 > > --- a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > @@ -10,9 +10,10 @@ maintainers: > > - Andrew Jeffery <andrew@aj.id.au> > > > > description: > > - This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full > > - featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to > > - support the following options > > + This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC, > > + AST2600 have two sgpio master one with 128 pins another one with 80 pins, > > + AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial > > + GPIO pins can be programmed to support the following options > > - Support interrupt option for each input port and various interrupt > > sensitivity option (level-high, level-low, edge-high, edge-low) > > - Support reset tolerance option for each output port > > @@ -25,6 +26,8 @@ properties: > > enum: > > - aspeed,ast2400-sgpio > > - aspeed,ast2500-sgpio > > + - aspeed,ast2600-sgpiom-80 > > + - aspeed,ast2600-sgpiom-128 > > If the number of GPIOs is the only difference, then I don't think you > should get rid of ngpios. It's one thing if it varies from one SoC to > the next, but if something is per instance we should have a property. > There are two issues: 1. The maximum number of GPIOs supported by the controller 2. The maximum number of GPIOs supported by the platform These are different because of what the controller does - here's some previous discussion on the topic: https://lore.kernel.org/linux-gpio/f2875111-9ba9-43b7-b2a4-d00c8725f5a0@www.fastmail.com/ We've used ngpios to describe 2; this decision was made prior to the 2600 design - the SGPIO controller for both the 2400 and 2500 supported a maximum of 80 GPIOs. With the 2600 we have to differentiate between the two SGPIO controllers because they support a different maximum number of GPIOs. The proposed approach of different compatibles keeps the behaviour of ngpios the same across all controller implementations. Cheers, Andrew
On Wed, Jun 9, 2021 at 8:46 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > > On Wed, 9 Jun 2021, at 13:42, Steven Lee wrote: > > The 06/09/2021 08:55, Andrew Jeffery wrote: > > > > > > > > > On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > > > > We use platform data to store GPIO pin mask and the max number of > > > > available GPIO pins for AST2600. > > > > Refactor driver to also add the platform data for AST2400/AST2500 and > > > > remove unused MAX_NR_HW_SGPIO and ASPEED_SGPIO_PINS_MASK macros. > > > > > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > > > --- > > > > drivers/gpio/gpio-aspeed-sgpio.c | 34 +++++++++++--------------------- > > > > 1 file changed, 12 insertions(+), 22 deletions(-) > > > > > > > > diff --git a/drivers/gpio/gpio-aspeed-sgpio.c b/drivers/gpio/gpio-aspeed-sgpio.c > > > > index ea20a0127748..7d0a4f6fd9d1 100644 > > > > --- a/drivers/gpio/gpio-aspeed-sgpio.c > > > > +++ b/drivers/gpio/gpio-aspeed-sgpio.c > > > > @@ -17,21 +17,8 @@ > > > > #include <linux/spinlock.h> > > > > #include <linux/string.h> > > > > > > > > -/* > > > > - * MAX_NR_HW_GPIO represents the number of actual hardware-supported GPIOs (ie, > > > > - * slots within the clocked serial GPIO data). Since each HW GPIO is both an > > > > - * input and an output, we provide MAX_NR_HW_GPIO * 2 lines on our gpiochip > > > > - * device. > > > > - * > > > > - * We use SGPIO_OUTPUT_OFFSET to define the split between the inputs and > > > > - * outputs; the inputs start at line 0, the outputs start at OUTPUT_OFFSET. > > > > - */ > > > > -#define MAX_NR_HW_SGPIO 80 > > > > -#define SGPIO_OUTPUT_OFFSET MAX_NR_HW_SGPIO > > > > - > > > > #define ASPEED_SGPIO_CTRL 0x54 > > > > > > > > -#define ASPEED_SGPIO_PINS_MASK GENMASK(9, 6) > > > > #define ASPEED_SGPIO_CLK_DIV_MASK GENMASK(31, 16) > > > > #define ASPEED_SGPIO_ENABLE BIT(0) > > > > #define ASPEED_SGPIO_PINS_SHIFT 6 > > > > @@ -484,6 +471,11 @@ static int aspeed_sgpio_setup_irqs(struct > > > > aspeed_sgpio *gpio, > > > > return 0; > > > > } > > > > > > > > +static const struct aspeed_sgpio_pdata ast2400_sgpio_pdata = { > > > > + .max_ngpios = 80, > > > > + .pin_mask = GENMASK(9, 6), > > > > +}; > > > > + > > > > static const struct aspeed_sgpio_pdata ast2600_sgpiom_128_pdata = { > > > > .max_ngpios = 128, > > > > .pin_mask = GENMASK(10, 6), > > > > @@ -495,8 +487,8 @@ static const struct aspeed_sgpio_pdata > > > > ast2600_sgpiom_80_pdata = { > > > > }; > > > > > > > > static const struct of_device_id aspeed_sgpio_of_table[] = { > > > > - { .compatible = "aspeed,ast2400-sgpio" }, > > > > - { .compatible = "aspeed,ast2500-sgpio" }, > > > > + { .compatible = "aspeed,ast2400-sgpio", .data = &ast2400_sgpio_pdata, > > > > }, > > > > + { .compatible = "aspeed,ast2500-sgpio", .data = &ast2400_sgpio_pdata, > > > > }, > > > > { .compatible = "aspeed,ast2600-sgpiom-128", .data = > > > > &ast2600_sgpiom_128_pdata, }, > > > > { .compatible = "aspeed,ast2600-sgpiom-80", .data = > > > > &ast2600_sgpiom_80_pdata, }, > > > > {} > > > > @@ -521,13 +513,11 @@ static int __init aspeed_sgpio_probe(struct > > > > platform_device *pdev) > > > > return PTR_ERR(gpio->base); > > > > > > > > pdata = device_get_match_data(&pdev->dev); > > > > - if (pdata) { > > > > - gpio->max_ngpios = pdata->max_ngpios; > > > > - pin_mask = pdata->pin_mask; > > > > - } else { > > > > - gpio->max_ngpios = MAX_NR_HW_SGPIO; > > > > - pin_mask = ASPEED_SGPIO_PINS_MASK; > > > > - } > > > > + if (!pdata) > > > > + return -EINVAL; > > > > + > > > > + gpio->max_ngpios = pdata->max_ngpios; > > > > + pin_mask = pdata->pin_mask; > > > > > > Hmm, okay, maybe just re-order the patches so this commit comes before the previous one. That way we don't immediately rip out this condition that we just introduced in the previous patch. > > > > > > I think I suggested squashing it into the previous patch, but with the removal of the comments and macros I think it's worth leaving it separate, just reordered. > > > > > > > I was wondering if I can squash patch-05 and patch-06 into one patch > > as this patch(patch-06) requires macros, structures, and functions that > > modified in the previous patch(patch-05). > > Yeah, fair enough. Just squash them. > > Cheers, > > Andrew I'm ready to pick this up as soon as you respin the series. Bart
The 06/12/2021 03:02, Bartosz Golaszewski wrote: > On Wed, Jun 9, 2021 at 8:46 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > > > > > > On Wed, 9 Jun 2021, at 13:42, Steven Lee wrote: > > > The 06/09/2021 08:55, Andrew Jeffery wrote: > > > > > > > > > > > > On Tue, 8 Jun 2021, at 19:55, Steven Lee wrote: > > > > > We use platform data to store GPIO pin mask and the max number of > > > > > available GPIO pins for AST2600. > > > > > Refactor driver to also add the platform data for AST2400/AST2500 and > > > > > remove unused MAX_NR_HW_SGPIO and ASPEED_SGPIO_PINS_MASK macros. > > > > > > > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > > > > --- > > > > > drivers/gpio/gpio-aspeed-sgpio.c | 34 +++++++++++--------------------- > > > > > 1 file changed, 12 insertions(+), 22 deletions(-) > > > > > > > > > > diff --git a/drivers/gpio/gpio-aspeed-sgpio.c b/drivers/gpio/gpio-aspeed-sgpio.c > > > > > index ea20a0127748..7d0a4f6fd9d1 100644 > > > > > --- a/drivers/gpio/gpio-aspeed-sgpio.c > > > > > +++ b/drivers/gpio/gpio-aspeed-sgpio.c > > > > > @@ -17,21 +17,8 @@ > > > > > #include <linux/spinlock.h> > > > > > #include <linux/string.h> > > > > > > > > > > -/* > > > > > - * MAX_NR_HW_GPIO represents the number of actual hardware-supported GPIOs (ie, > > > > > - * slots within the clocked serial GPIO data). Since each HW GPIO is both an > > > > > - * input and an output, we provide MAX_NR_HW_GPIO * 2 lines on our gpiochip > > > > > - * device. > > > > > - * > > > > > - * We use SGPIO_OUTPUT_OFFSET to define the split between the inputs and > > > > > - * outputs; the inputs start at line 0, the outputs start at OUTPUT_OFFSET. > > > > > - */ > > > > > -#define MAX_NR_HW_SGPIO 80 > > > > > -#define SGPIO_OUTPUT_OFFSET MAX_NR_HW_SGPIO > > > > > - > > > > > #define ASPEED_SGPIO_CTRL 0x54 > > > > > > > > > > -#define ASPEED_SGPIO_PINS_MASK GENMASK(9, 6) > > > > > #define ASPEED_SGPIO_CLK_DIV_MASK GENMASK(31, 16) > > > > > #define ASPEED_SGPIO_ENABLE BIT(0) > > > > > #define ASPEED_SGPIO_PINS_SHIFT 6 > > > > > @@ -484,6 +471,11 @@ static int aspeed_sgpio_setup_irqs(struct > > > > > aspeed_sgpio *gpio, > > > > > return 0; > > > > > } > > > > > > > > > > +static const struct aspeed_sgpio_pdata ast2400_sgpio_pdata = { > > > > > + .max_ngpios = 80, > > > > > + .pin_mask = GENMASK(9, 6), > > > > > +}; > > > > > + > > > > > static const struct aspeed_sgpio_pdata ast2600_sgpiom_128_pdata = { > > > > > .max_ngpios = 128, > > > > > .pin_mask = GENMASK(10, 6), > > > > > @@ -495,8 +487,8 @@ static const struct aspeed_sgpio_pdata > > > > > ast2600_sgpiom_80_pdata = { > > > > > }; > > > > > > > > > > static const struct of_device_id aspeed_sgpio_of_table[] = { > > > > > - { .compatible = "aspeed,ast2400-sgpio" }, > > > > > - { .compatible = "aspeed,ast2500-sgpio" }, > > > > > + { .compatible = "aspeed,ast2400-sgpio", .data = &ast2400_sgpio_pdata, > > > > > }, > > > > > + { .compatible = "aspeed,ast2500-sgpio", .data = &ast2400_sgpio_pdata, > > > > > }, > > > > > { .compatible = "aspeed,ast2600-sgpiom-128", .data = > > > > > &ast2600_sgpiom_128_pdata, }, > > > > > { .compatible = "aspeed,ast2600-sgpiom-80", .data = > > > > > &ast2600_sgpiom_80_pdata, }, > > > > > {} > > > > > @@ -521,13 +513,11 @@ static int __init aspeed_sgpio_probe(struct > > > > > platform_device *pdev) > > > > > return PTR_ERR(gpio->base); > > > > > > > > > > pdata = device_get_match_data(&pdev->dev); > > > > > - if (pdata) { > > > > > - gpio->max_ngpios = pdata->max_ngpios; > > > > > - pin_mask = pdata->pin_mask; > > > > > - } else { > > > > > - gpio->max_ngpios = MAX_NR_HW_SGPIO; > > > > > - pin_mask = ASPEED_SGPIO_PINS_MASK; > > > > > - } > > > > > + if (!pdata) > > > > > + return -EINVAL; > > > > > + > > > > > + gpio->max_ngpios = pdata->max_ngpios; > > > > > + pin_mask = pdata->pin_mask; > > > > > > > > Hmm, okay, maybe just re-order the patches so this commit comes before the previous one. That way we don't immediately rip out this condition that we just introduced in the previous patch. > > > > > > > > I think I suggested squashing it into the previous patch, but with the removal of the comments and macros I think it's worth leaving it separate, just reordered. > > > > > > > > > > I was wondering if I can squash patch-05 and patch-06 into one patch > > > as this patch(patch-06) requires macros, structures, and functions that > > > modified in the previous patch(patch-05). > > > > Yeah, fair enough. Just squash them. > > > > Cheers, > > > > Andrew > > I'm ready to pick this up as soon as you respin the series. > Hi Bart, Per the discussion in the following mail threads, I may redesign aspeed sgpio driver for the new solution. https://lkml.org/lkml/2021/6/3/1507 https://lkml.org/lkml/2021/6/10/240 Patch02- Patch06 of this patch series will need to be modified for the new solution, although some of them have Reviewed-by tag. Thanks, Steven > Bart
On Thu, Jun 10, 2021 at 5:27 PM Andrew Jeffery <andrew@aj.id.au> wrote: > > > > On Fri, 11 Jun 2021, at 01:53, Rob Herring wrote: > > On Tue, Jun 08, 2021 at 06:25:37PM +0800, Steven Lee wrote: > > > AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one > > > with 80 pins. Add ast2600-sgpiom0-80 and ast2600-sgpiom-128 compatibles > > > and update descriptions to introduce the max number of available gpio > > > pins that AST2600 supported. > > > > > > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> > > > Reviewed-by: Andrew Jeffery <andrew@aj.id.au> > > > --- > > > Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml | 9 ++++++--- > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > > index b2ae211411ff..0e42eded3c1e 100644 > > > --- a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > > +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml > > > @@ -10,9 +10,10 @@ maintainers: > > > - Andrew Jeffery <andrew@aj.id.au> > > > > > > description: > > > - This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full > > > - featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to > > > - support the following options > > > + This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC, > > > + AST2600 have two sgpio master one with 128 pins another one with 80 pins, > > > + AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial > > > + GPIO pins can be programmed to support the following options > > > - Support interrupt option for each input port and various interrupt > > > sensitivity option (level-high, level-low, edge-high, edge-low) > > > - Support reset tolerance option for each output port > > > @@ -25,6 +26,8 @@ properties: > > > enum: > > > - aspeed,ast2400-sgpio > > > - aspeed,ast2500-sgpio > > > + - aspeed,ast2600-sgpiom-80 > > > + - aspeed,ast2600-sgpiom-128 > > > > If the number of GPIOs is the only difference, then I don't think you > > should get rid of ngpios. It's one thing if it varies from one SoC to > > the next, but if something is per instance we should have a property. > > > > There are two issues: > > 1. The maximum number of GPIOs supported by the controller > 2. The maximum number of GPIOs supported by the platform > > These are different because of what the controller does - here's some previous discussion on the topic: > > https://lore.kernel.org/linux-gpio/f2875111-9ba9-43b7-b2a4-d00c8725f5a0@www.fastmail.com/ > > We've used ngpios to describe 2; this decision was made prior to the 2600 design - the SGPIO controller for both the 2400 and 2500 supported a maximum of 80 GPIOs. With the 2600 we have to differentiate between the two SGPIO controllers because they support a different maximum number of GPIOs. The proposed approach of different compatibles keeps the behaviour of ngpios the same across all controller implementations. Okay, that makes sense. Reviewed-by: Rob Herring <robh@kernel.org>