All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org, Alessandro Zummo <a.zummo@towertech.it>
Subject: Re: question about firmware RTC design (for rtcwake)
Date: Thu, 8 Jun 2023 11:05:57 +0200	[thread overview]
Message-ID: <20230608110557.16284eb2@thinkpad> (raw)
In-Reply-To: <20230607082828fd8d03fc@mail.local>

On Wed, 7 Jun 2023 10:28:28 +0200
Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:

> On 22/05/2023 23:14:54+0200, Marek Behún wrote:
> > > You probably need to look at rtc-meson-vrtc.c, rtc-fsl-ftm-alarm.c and
> > > rtc-brcmstb-waketimer.c which implement something similar.
> > > 
> > > Honestly, I would go for an in-between proposal where you would store
> > > the requested alarm time (or more likely countdown) on
> > > set_alarm/alarm_irq_enable so you would get .read_alarm working.
> > > 
> > > However, my main concern is that this is yet another custom protocol. We
> > > can't possibly have a driver for everyone implementing a timer in their
> > > FPGA/CPLD/cortexM.
> > > 
> > > How will you communicate with the MCU, can't you use an already existing
> > > driver?  
> > 
> > The MCU exposes a command interface over I2C. There already are
> > existing commands, which needs to stay for backwards compatibility.
> > 
> > It is theoretically possible to simulate an existing RTC device on
> > another I2C address, but I would need to study them, because the boards
> > are shipped with three different MCUs (STM32, GD32, NXP's MKL81) and
> > they sometimes have a little different I2C slave behavior.
> > 
> > But I will need to create a platform/mfd driver anyway for the system
> > off handler and GPIO controller. If I am going to create a new driver
> > anyway, why not add the RTC functionality as well?  
> 
> No, this is not how MFD is working, you will be writing a separate RTC
> driver or reusing an existing one. Have a look at the recent isl1208

THX for the reply.
I have one I2C client through which I need to implement RTC, GPIO and
system power off. I thought such drivers live in drivers/mfd... Am I
wrong?

Marek


> series:
> 
> https://lore.kernel.org/linux-rtc/OS0PR01MB5922DAC377266672ADA9FC28864DA@OS0PR01MB5922.jpnprd01.prod.outlook.com/T/#mab0a75187abf7d8aada2c3517ebfdf7241f4bc7a
> 
> This patch adds supports for the isl1208 on board of a PMIC, as you can
> see, this is a very small change versus a full blown RTC driver.


  reply	other threads:[~2023-06-08  9:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 14:46 question about firmware RTC design (for rtcwake) Marek Behún
2023-05-22 19:40 ` Alexandre Belloni
2023-05-22 21:14   ` Marek Behún
2023-06-07  8:28     ` Alexandre Belloni
2023-06-08  9:05       ` Marek Behún [this message]
2023-06-08  9:25         ` Alexandre Belloni

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=20230608110557.16284eb2@thinkpad \
    --to=kabel@kernel.org \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-rtc@vger.kernel.org \
    /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.