Re: [PATCH 8/8] rtc: max77686: add MAX77714 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

see below for the issues with interrupt implementation that I mentioned
in the cover letter.

On 11/10/21 17:56, Luca Ceresoli wrote:
> The RTC included in the MAX77714 PMIC is very similar to the one in the
> MAX77686. Reuse the rtc-max77686.c driver with the minimum required changes
> for the MAX77714 RTC.
> 
> Signed-off-by: Luca Ceresoli <luca@xxxxxxxxxxxxxxxx>
> ---
>  drivers/rtc/Kconfig        |  2 +-
>  drivers/rtc/rtc-max77686.c | 24 ++++++++++++++++++++++++
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e1bc5214494e..a73591ad292b 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -375,7 +375,7 @@ config RTC_DRV_MAX8997
>  
>  config RTC_DRV_MAX77686
>  	tristate "Maxim MAX77686"
> -	depends on MFD_MAX77686 || MFD_MAX77620 || COMPILE_TEST
> +	depends on MFD_MAX77686 || MFD_MAX77620 || MFD_MAX77714 || COMPILE_TEST
>  	help
>  	  If you say yes here you will get support for the
>  	  RTC of Maxim MAX77686/MAX77620/MAX77802 PMIC.
> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> index 9901c596998a..e6564bc2171e 100644
> --- a/drivers/rtc/rtc-max77686.c
> +++ b/drivers/rtc/rtc-max77686.c
> @@ -19,6 +19,7 @@
>  
>  #define MAX77686_I2C_ADDR_RTC		(0x0C >> 1)
>  #define MAX77620_I2C_ADDR_RTC		0x68
> +#define MAX77714_I2C_ADDR_RTC		0x48
>  #define MAX77686_INVALID_I2C_ADDR	(-1)
>  
>  /* Define non existing register */
> @@ -203,6 +204,28 @@ static const struct max77686_rtc_driver_data max77686_drv_data = {
>  	.regmap_config = &max77686_rtc_regmap_config,
>  };
>  
> +static const struct regmap_irq_chip max77714_rtc_irq_chip = {
> +	.name		= "max77714-rtc",
> +	.status_base	= MAX77686_RTC_INT,
> +	.mask_base	= MAX77686_RTC_INTM,
> +	.num_regs	= 1,
> +	.irqs		= max77686_rtc_irqs,
> +	.num_irqs	= ARRAY_SIZE(max77686_rtc_irqs) - 1, /* no WTSR on 77714 */
> +};
> +
> +static const struct max77686_rtc_driver_data max77714_drv_data = {
> +	.delay = 16000,
> +	.mask  = 0x7f,
> +	.map   = max77686_map,
> +	.alarm_enable_reg = false,
> +	.rtc_irq_from_platform = false,

As far as I could understand, rtc_irq_from_platform should be 'true'.
This would trigger the 'if' branch in function
max77686_init_rtc_regmap() [0]:

  if (info->drv_data->rtc_irq_from_platform) {
	struct platform_device *pdev = to_platform_device(info->dev);

	info->rtc_irq = platform_get_irq(pdev, 0);
	if (info->rtc_irq < 0)
		return info->rtc_irq;
  } else {
	info->rtc_irq =  parent_i2c->irq;
  }

Calling platform_get_irq() seems correct for the MAX77714, which can
generate various IRQ events, collecting them in a register, and raise a
single IRQ to the CPU via a physical pin.

However, if I set rtc_irq_from_platform = true, platform_get_irq()
returns IRQ number '1', which ends up in:

  dummy 0-0048: Failed to request IRQ 1 for max77714-rtc: -22
  max77686-rtc max77714-rtc: Failed to add RTC irq chip: -22
  max77686-rtc: probe of max77714-rtc failed with error -22

I compared my code with other MFD drivers and their cell drivers (but
their datasheets is not available so I had to add some guesswork), and
couldn't find out where my code is wrong.

Unfortunately I have no IRQ access on my board (and I don't need them
for my use case). For this reason I initially thought of disabling all
the IRQ code in rtc-max77686.c via a new flag, but it would be quite
invasive and I wouldn't even be able to test that existing hardware
still works. Implementing a new RTC driver for the MAX77714 does not
seem to be a sane option as the hardware is really 99% equal to the
MAX77686 RTC.

Any suggestions on how to move on? -- Thanks!

[0]
https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-max77686.c#L676

Regards,
-- 
Luca



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux