mbox series

[v8,0/2] gpmc wait pin additions

Message ID 20221021081612.591613-1-benedikt.niedermayr@siemens.com (mailing list archive)
Headers show
Series gpmc wait pin additions | expand

Message

Benedikt Niedermayr Oct. 21, 2022, 8:16 a.m. UTC 
From: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>

Currently it is not possible to configure the WAIT0PINPOLARITY and
WAIT1PINPOLARITY bits of the GPMC_CONFIG register directly via
device tree properties.

It is also not possible to use the same wait-pin for different
cs-regions.

While the current implementation may fullfill most usecases, it may not
be sufficient for more complex setups (e.g. FPGA/ASIC interfaces), where
more complex interfacing options where possible.

For example interfacing an ASIC which offers multiple cs-regions but
only one waitpin the current driver and dt-bindings are not sufficient.

While using the same waitpin for different cs-regions worked for older
kernels (4.14) the omap-gpmc.c driver refused to probe (-EBUSY) with
newer kernels (>5.10).

Changes since v1:
  * Rebase against recent 6.0.0-rc3 kernel
  * Updated eMail recipients list
Changes since v2:
  * Remove the gpmc register configuration out of the gpiochip
    callbacks. In this case the memory interface configuration
    is not done via gpio bindings.
  * Some minor code fixes
  * Changed git commit descriptions
Change since v3:
  * Use a uint32 dt-property instean a boolean one
  * If the dt-property is not set, then don't touch the
    GPMC_CONFIG register
  * Changed git commit descriptions
Changes since v4:
  * Use checkpatch with "--strict" option
  * Moved wait-pin sanity checks to gpmc_read_settings_dt()
  * Always assign WAITPINPOLARITY_DEFAULT on error cases
  * Track waitpin allocation within gpmc for determine
    allocation origin
Changes since v5:
  * Tracking of wait-pin allocations with polarity change detection
    * Introduced a new struct gpmc_waitpin
  * Add GPMC_* to global header definitions
  * Don't allow GPMC_WAITPINPOLARITY_DEFAULT when parsing dt-properties
  * Squashed wait-pin-polarity and shared-wait-pin patches, since they
    should not be separated
Changes since v6:
  * Move wait-pin allocation into gpmc_probe()
  * Fix s/gpmc/GPMC/ in commit description
  * use ti,wait-pin-polarity instead of gpmc,wait-pin-polarity
  * Refactored if clause in gpmc_alloc_waitpin()
  * Revert values for GPMC_WAITPINPOLARITY_ACTIVE_LOW and
    GPMC_WAITPINPOLARITY_ACTIVE_HIGH.
    Use the exact same values which are written into the register.
Changes since v7:
  * Renamed GPMC_WAITPINPOLARITY_DEFAULT to GPMC_WAITPINPOLARITY_INVALID
  * Call gpiochip_request_own_desc() only on first wait-pin allocation
  * Fixed use of old "gpmc,wait-pin-polarity" property.

Benedikt Niedermayr (2):
  memory: omap-gpmc: wait pin additions
  dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity

 .../memory-controllers/ti,gpmc-child.yaml     |   7 +
 drivers/memory/omap-gpmc.c                    | 122 ++++++++++++++++--
 include/linux/platform_data/gpmc-omap.h       |   8 ++
 3 files changed, 124 insertions(+), 13 deletions(-)

--
2.25.1

Comments

Roger Quadros Oct. 28, 2022, 11:56 a.m. UTC | #1 
Hello Benedikt,

On 21/10/2022 11:16, B. Niedermayr wrote:
> From: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
> 
> Currently it is not possible to configure the WAIT0PINPOLARITY and
> WAIT1PINPOLARITY bits of the GPMC_CONFIG register directly via
> device tree properties.
> 
> It is also not possible to use the same wait-pin for different
> cs-regions.
> 
> While the current implementation may fullfill most usecases, it may not
> be sufficient for more complex setups (e.g. FPGA/ASIC interfaces), where
> more complex interfacing options where possible.
> 
> For example interfacing an ASIC which offers multiple cs-regions but
> only one waitpin the current driver and dt-bindings are not sufficient.
> 
> While using the same waitpin for different cs-regions worked for older
> kernels (4.14) the omap-gpmc.c driver refused to probe (-EBUSY) with
> newer kernels (>5.10).

This series does not apply on v6.0 nor on v6.1-rc1.
Could you please rebase on v6.1-rc1 and send? Thanks!

cheers,
-roger

> 
> Changes since v1:
>   * Rebase against recent 6.0.0-rc3 kernel
>   * Updated eMail recipients list
> Changes since v2:
>   * Remove the gpmc register configuration out of the gpiochip
>     callbacks. In this case the memory interface configuration
>     is not done via gpio bindings.
>   * Some minor code fixes
>   * Changed git commit descriptions
> Change since v3:
>   * Use a uint32 dt-property instean a boolean one
>   * If the dt-property is not set, then don't touch the
>     GPMC_CONFIG register
>   * Changed git commit descriptions
> Changes since v4:
>   * Use checkpatch with "--strict" option
>   * Moved wait-pin sanity checks to gpmc_read_settings_dt()
>   * Always assign WAITPINPOLARITY_DEFAULT on error cases
>   * Track waitpin allocation within gpmc for determine
>     allocation origin
> Changes since v5:
>   * Tracking of wait-pin allocations with polarity change detection
>     * Introduced a new struct gpmc_waitpin
>   * Add GPMC_* to global header definitions
>   * Don't allow GPMC_WAITPINPOLARITY_DEFAULT when parsing dt-properties
>   * Squashed wait-pin-polarity and shared-wait-pin patches, since they
>     should not be separated
> Changes since v6:
>   * Move wait-pin allocation into gpmc_probe()
>   * Fix s/gpmc/GPMC/ in commit description
>   * use ti,wait-pin-polarity instead of gpmc,wait-pin-polarity
>   * Refactored if clause in gpmc_alloc_waitpin()
>   * Revert values for GPMC_WAITPINPOLARITY_ACTIVE_LOW and
>     GPMC_WAITPINPOLARITY_ACTIVE_HIGH.
>     Use the exact same values which are written into the register.
> Changes since v7:
>   * Renamed GPMC_WAITPINPOLARITY_DEFAULT to GPMC_WAITPINPOLARITY_INVALID
>   * Call gpiochip_request_own_desc() only on first wait-pin allocation
>   * Fixed use of old "gpmc,wait-pin-polarity" property.
> 
> Benedikt Niedermayr (2):
>   memory: omap-gpmc: wait pin additions
>   dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity
> 
>  .../memory-controllers/ti,gpmc-child.yaml     |   7 +
>  drivers/memory/omap-gpmc.c                    | 122 ++++++++++++++++--
>  include/linux/platform_data/gpmc-omap.h       |   8 ++
>  3 files changed, 124 insertions(+), 13 deletions(-)
> 
> --
> 2.25.1
>
Krzysztof Kozlowski Oct. 28, 2022, 12:53 p.m. UTC | #2 
On 28/10/2022 07:56, Roger Quadros wrote:
> Hello Benedikt,
> 
> On 21/10/2022 11:16, B. Niedermayr wrote:
>> From: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
>>
>> Currently it is not possible to configure the WAIT0PINPOLARITY and
>> WAIT1PINPOLARITY bits of the GPMC_CONFIG register directly via
>> device tree properties.
>>
>> It is also not possible to use the same wait-pin for different
>> cs-regions.
>>
>> While the current implementation may fullfill most usecases, it may not
>> be sufficient for more complex setups (e.g. FPGA/ASIC interfaces), where
>> more complex interfacing options where possible.
>>
>> For example interfacing an ASIC which offers multiple cs-regions but
>> only one waitpin the current driver and dt-bindings are not sufficient.
>>
>> While using the same waitpin for different cs-regions worked for older
>> kernels (4.14) the omap-gpmc.c driver refused to probe (-EBUSY) with
>> newer kernels (>5.10).
> 
> This series does not apply on v6.0 nor on v6.1-rc1.
> Could you please rebase on v6.1-rc1 and send? Thanks!

I am still kind of expecting your review of these. Shall I not?

Best regards,
Krzysztof
Roger Quadros Oct. 29, 2022, 6:25 p.m. UTC | #3 
On 21/10/2022 11:16, B. Niedermayr wrote:
> From: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
> 
> Currently it is not possible to configure the WAIT0PINPOLARITY and
> WAIT1PINPOLARITY bits of the GPMC_CONFIG register directly via
> device tree properties.
> 
> It is also not possible to use the same wait-pin for different
> cs-regions.
> 
> While the current implementation may fullfill most usecases, it may not
> be sufficient for more complex setups (e.g. FPGA/ASIC interfaces), where
> more complex interfacing options where possible.
> 
> For example interfacing an ASIC which offers multiple cs-regions but
> only one waitpin the current driver and dt-bindings are not sufficient.
> 
> While using the same waitpin for different cs-regions worked for older
> kernels (4.14) the omap-gpmc.c driver refused to probe (-EBUSY) with
> newer kernels (>5.10).
> 
> Changes since v1:
>   * Rebase against recent 6.0.0-rc3 kernel
>   * Updated eMail recipients list
> Changes since v2:
>   * Remove the gpmc register configuration out of the gpiochip
>     callbacks. In this case the memory interface configuration
>     is not done via gpio bindings.
>   * Some minor code fixes
>   * Changed git commit descriptions
> Change since v3:
>   * Use a uint32 dt-property instean a boolean one
>   * If the dt-property is not set, then don't touch the
>     GPMC_CONFIG register
>   * Changed git commit descriptions
> Changes since v4:
>   * Use checkpatch with "--strict" option
>   * Moved wait-pin sanity checks to gpmc_read_settings_dt()
>   * Always assign WAITPINPOLARITY_DEFAULT on error cases
>   * Track waitpin allocation within gpmc for determine
>     allocation origin
> Changes since v5:
>   * Tracking of wait-pin allocations with polarity change detection
>     * Introduced a new struct gpmc_waitpin
>   * Add GPMC_* to global header definitions
>   * Don't allow GPMC_WAITPINPOLARITY_DEFAULT when parsing dt-properties
>   * Squashed wait-pin-polarity and shared-wait-pin patches, since they
>     should not be separated
> Changes since v6:
>   * Move wait-pin allocation into gpmc_probe()
>   * Fix s/gpmc/GPMC/ in commit description
>   * use ti,wait-pin-polarity instead of gpmc,wait-pin-polarity
>   * Refactored if clause in gpmc_alloc_waitpin()
>   * Revert values for GPMC_WAITPINPOLARITY_ACTIVE_LOW and
>     GPMC_WAITPINPOLARITY_ACTIVE_HIGH.
>     Use the exact same values which are written into the register.
> Changes since v7:
>   * Renamed GPMC_WAITPINPOLARITY_DEFAULT to GPMC_WAITPINPOLARITY_INVALID
>   * Call gpiochip_request_own_desc() only on first wait-pin allocation
>   * Fixed use of old "gpmc,wait-pin-polarity" property.
> 
> Benedikt Niedermayr (2):
>   memory: omap-gpmc: wait pin additions
>   dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity
> 
>  .../memory-controllers/ti,gpmc-child.yaml     |   7 +
>  drivers/memory/omap-gpmc.c                    | 122 ++++++++++++++++--
>  include/linux/platform_data/gpmc-omap.h       |   8 ++
>  3 files changed, 124 insertions(+), 13 deletions(-)

For this series.

Reviewed-by: Roger Quadros <rogerq@kernel.org>

> 
> --
> 2.25.1
> 

cheers,
-roger
Roger Quadros Oct. 29, 2022, 6:26 p.m. UTC | #4 
On 21/10/2022 11:16, B. Niedermayr wrote:
> From: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
> 
> Currently it is not possible to configure the WAIT0PINPOLARITY and
> WAIT1PINPOLARITY bits of the GPMC_CONFIG register directly via
> device tree properties.
> 
> It is also not possible to use the same wait-pin for different
> cs-regions.
> 
> While the current implementation may fullfill most usecases, it may not
> be sufficient for more complex setups (e.g. FPGA/ASIC interfaces), where
> more complex interfacing options where possible.
> 
> For example interfacing an ASIC which offers multiple cs-regions but
> only one waitpin the current driver and dt-bindings are not sufficient.
> 
> While using the same waitpin for different cs-regions worked for older
> kernels (4.14) the omap-gpmc.c driver refused to probe (-EBUSY) with
> newer kernels (>5.10).
> 
> Changes since v1:
>   * Rebase against recent 6.0.0-rc3 kernel
>   * Updated eMail recipients list
> Changes since v2:
>   * Remove the gpmc register configuration out of the gpiochip
>     callbacks. In this case the memory interface configuration
>     is not done via gpio bindings.
>   * Some minor code fixes
>   * Changed git commit descriptions
> Change since v3:
>   * Use a uint32 dt-property instean a boolean one
>   * If the dt-property is not set, then don't touch the
>     GPMC_CONFIG register
>   * Changed git commit descriptions
> Changes since v4:
>   * Use checkpatch with "--strict" option
>   * Moved wait-pin sanity checks to gpmc_read_settings_dt()
>   * Always assign WAITPINPOLARITY_DEFAULT on error cases
>   * Track waitpin allocation within gpmc for determine
>     allocation origin
> Changes since v5:
>   * Tracking of wait-pin allocations with polarity change detection
>     * Introduced a new struct gpmc_waitpin
>   * Add GPMC_* to global header definitions
>   * Don't allow GPMC_WAITPINPOLARITY_DEFAULT when parsing dt-properties
>   * Squashed wait-pin-polarity and shared-wait-pin patches, since they
>     should not be separated
> Changes since v6:
>   * Move wait-pin allocation into gpmc_probe()
>   * Fix s/gpmc/GPMC/ in commit description
>   * use ti,wait-pin-polarity instead of gpmc,wait-pin-polarity
>   * Refactored if clause in gpmc_alloc_waitpin()
>   * Revert values for GPMC_WAITPINPOLARITY_ACTIVE_LOW and
>     GPMC_WAITPINPOLARITY_ACTIVE_HIGH.
>     Use the exact same values which are written into the register.
> Changes since v7:
>   * Renamed GPMC_WAITPINPOLARITY_DEFAULT to GPMC_WAITPINPOLARITY_INVALID
>   * Call gpiochip_request_own_desc() only on first wait-pin allocation
>   * Fixed use of old "gpmc,wait-pin-polarity" property.
> 
> Benedikt Niedermayr (2):
>   memory: omap-gpmc: wait pin additions
>   dt-bindings: memory-controllers: gpmc-child: add wait-pin polarity
> 
>  .../memory-controllers/ti,gpmc-child.yaml     |   7 +
>  drivers/memory/omap-gpmc.c                    | 122 ++++++++++++++++--
>  include/linux/platform_data/gpmc-omap.h       |   8 ++
>  3 files changed, 124 insertions(+), 13 deletions(-)

for this series

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-roger