* [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
[not found] ` <1426657537-41414-3-git-send-email-eddie.huang@mediatek.com>
@ 2015-03-30 7:41 ` 'Tomasz Figa' via rtc-linux
2015-03-31 9:44 ` Eddie Huang
[not found] ` <CAKdAkRSRXZ=1T+2Mfvjc4DsCCt1rxqGZpEuOUkU5KfPD2__BnQ@mail.gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: 'Tomasz Figa' via rtc-linux @ 2015-03-30 7:41 UTC (permalink / raw)
To: Eddie Huang
Cc: Lee Jones, Alessandro Zummo, Matthias Brugger, Samuel Ortiz,
srv_heupstream, Mauro Carvalho Chehab, rtc-linux, Greg KH,
Jingoo Han, linux-kernel@vger.kernel.org, Tianping Fang,
Tejun Heo, linux-mediatek, Uwe Kleine-König,
Joe Perches, Andrew Morton, David S. Miller,
linux-arm-kernel@lists.infradead.org
Hi Eddie,
Please see my comments inline.
On Wed, Mar 18, 2015 at 2:45 PM, Eddie Huang <eddie.huang@mediatek.com> wrote:
> From: Tianping Fang <tianping.fang@mediatek.com>
>
> Add Mediatek MT6397 RTC driver
[snip]
> +#define RTC_BBPU 0x0000
> +#define RTC_WRTGR 0x003c
> +#define RTC_IRQ_EN 0x0004
> +#define RTC_IRQ_STA 0x0002
> +
> +#define RTC_BBPU_CBUSY (1 << 6)
> +#define RTC_IRQ_STA_AL (1 << 0)
> +#define RTC_IRQ_STA_LP (1 << 3)
nit: Could you use BIT() macro for definitions of single bits? (+
further occurrences in the patch)
> +
> +#define RTC_AL_MASK 0x0008
> +#define RTC_TC_SEC 0x000a
> +#define RTC_TC_MIN 0x000c
> +#define RTC_TC_HOU 0x000e
> +#define RTC_TC_DOM 0x0010
> +#define RTC_TC_MTH 0x0014
> +#define RTC_TC_YEA 0x0016
> +#define RTC_AL_SEC 0x0018
> +#define RTC_AL_MIN 0x001a
[snip]
> +
> +static int mtk_rtc_read(struct mt6397_rtc *rtc, u32 offset, u32 *data)
> +{
> + u32 addr = rtc->addr_base + offset;
> +
> + if (offset < rtc->addr_range)
> + return regmap_read(rtc->regmap, addr, data);
> +
> + return -EINVAL;
> +}
> +
> +static int mtk_rtc_write(struct mt6397_rtc *rtc, u32 offset, u32 data)
> +{
> + u32 addr;
> +
> + addr = rtc->addr_base + offset;
> +
> + if (offset < rtc->addr_range)
> + return regmap_write(rtc->regmap, addr, data);
> +
> + return -EINVAL;
> +}
Do you actually need these wrappers? Could you use regmap_write() and
_read() directly? This would also enable you to use
regmap_update_bits() instead of implicit read, modify and write.
> +
> +static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> +{
> + int ret;
> + u32 data;
> +
> + ret = mtk_rtc_write(rtc, RTC_WRTGR, 1);
> + if (ret < 0)
> + goto exit;
> +
> + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
> + if (ret < 0)
> + goto exit;
> +
> + while (data & RTC_BBPU_CBUSY) {
> + cpu_relax();
> + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
> + if (ret < 0)
> + goto exit;
> + }
The initial read and the loop could be folded into a do {} while loop?
Also it would be safer to have a timeout here.
> +
> +exit:
> + return ret;
> +}
> +
> +static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
> +{
> + struct mt6397_rtc *rtc = data;
> + u32 irqsta, irqen;
> + int ret;
> +
> + ret = mtk_rtc_read(rtc, RTC_IRQ_STA, &irqsta);
> +
> + if ((ret >= 0) && (irqsta & RTC_IRQ_STA_AL)) {
> + rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
> + irqen = irqsta & ~RTC_IRQ_EN_AL;
> + mutex_lock(&rtc->lock);
> + if (mtk_rtc_write(rtc, RTC_IRQ_EN, irqen) < 0)
> + mtk_rtc_write_trigger(rtc);
> + mutex_unlock(&rtc->lock);
> +
> + return IRQ_HANDLED;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +static int __mtk_rtc_read_time(struct mt6397_rtc *rtc,
> + struct rtc_time *tm, int *sec)
> +{
> + int ret;
> +
> + mutex_lock(&rtc->lock);
> + ret = mtk_rtc_read(rtc, RTC_TC_SEC, &tm->tm_sec);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_MIN, &tm->tm_min);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_HOU, &tm->tm_hour);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_DOM, &tm->tm_mday);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_MTH, &tm->tm_mon);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_YEA, &tm->tm_year);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_TC_SEC, sec);
Would the hardware allow this to be merged into single burst transfer
reading all the registers into a buffer, so then you could just copy
the values from that buffer into target struct instead of issuing
multiple reads one by one?
Also shouldn't the unused bits be masked out?
> +
> +exit:
> + mutex_unlock(&rtc->lock);
> + return ret;
> +}
> +
> +static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + time64_t time;
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + int sec, ret;
> +
> + do {
> + ret = __mtk_rtc_read_time(rtc, tm, &sec);
> + if (ret < 0)
> + goto exit;
> + } while (sec < tm->tm_sec);
Shouldn't this be while (sec > tm->tm_sec)?
> +
> + tm->tm_year += RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon--;
Could you add a comment explaining why this is decremented?
> + time = rtc_tm_to_time64(tm);
> +
> + tm->tm_wday = (time / 86400 + 4) % 7;
Could you add a comment, or even better, an inline function with a
comment, explaining this calculation?
> +
> +exit:
> + return ret;
> +}
> +
> +static int mtk_rtc_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + int ret;
> +
> + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon++;
> +
> + mutex_lock(&rtc->lock);
> + ret = mtk_rtc_write(rtc, RTC_TC_YEA, tm->tm_year);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_TC_MTH, tm->tm_mon);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_TC_DOM, tm->tm_mday);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_TC_HOU, tm->tm_hour);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_TC_MIN, tm->tm_min);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_TC_SEC, tm->tm_sec);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write_trigger(rtc);
> +
> +exit:
> + mutex_unlock(&rtc->lock);
> + return ret;
> +}
> +
> +static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> +{
> + struct rtc_time *tm = &alm->time;
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + u32 irqen, pdn2;
> + int ret;
> +
> + mutex_lock(&rtc->lock);
> + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_PDN2, &pdn2);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_SEC, &tm->tm_sec);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_MIN, &tm->tm_min);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_HOU, &tm->tm_hour);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_DOM, &tm->tm_mday);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_MTH, &tm->tm_mon);
> + if (ret < 0)
> + goto err_exit;
> + ret = mtk_rtc_read(rtc, RTC_AL_YEA, &tm->tm_year);
> + if (ret < 0)
> + goto err_exit;
Similarly to _read_time(), could this be changed into a single burst read?
> +
> + alm->enabled = !!(irqen & RTC_IRQ_EN_AL);
> + alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> + mutex_unlock(&rtc->lock);
> +
> + tm->tm_year += RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon--;
> +
> + return 0;
> +err_exit:
> + mutex_unlock(&rtc->lock);
> + return ret;
> +}
> +
> +static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> +{
> + struct rtc_time *tm = &alm->time;
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + u32 irqen;
> + int ret;
> +
> + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon++;
> +
> + mutex_lock(&rtc->lock);
> + if (alm->enabled) {
Is this possible that an alarm was already set? Is it okay to keep it
enabled while changing the alarm time to new one?
> + ret = mtk_rtc_write(rtc, RTC_AL_YEA, tm->tm_year);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_MTH, tm->tm_mon);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_DOM, tm->tm_mday);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_HOU, tm->tm_hour);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_MIN, tm->tm_min);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_SEC, tm->tm_sec);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write(rtc, RTC_AL_MASK, RTC_AL_MASK_DOW);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_write_trigger(rtc);
> + if (ret < 0)
> + goto exit;
> + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> + if (ret < 0)
> + goto exit;
> + irqen |= RTC_IRQ_EN_ONESHOT_AL;
> + ret = mtk_rtc_write(rtc, RTC_IRQ_EN, irqen);
> + if (ret < 0)
> + goto exit;
regmap_update_bits() could be used instead of the read, modify and write above.
> + ret = mtk_rtc_write_trigger(rtc);
> + if (ret < 0)
> + goto exit;
> + } else {
> + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> + if (ret < 0)
> + goto exit;
> + irqen &= ~RTC_IRQ_EN_ONESHOT_AL;
> + ret = mtk_rtc_write(rtc, RTC_IRQ_EN, irqen);
> + if (ret < 0)
> + goto exit;
Ditto.
> + }
> +
> +exit:
> + mutex_unlock(&rtc->lock);
> + return ret;
> +}
> +
> +static struct rtc_class_ops mtk_rtc_ops = {
> + .read_time = mtk_rtc_read_time,
> + .set_time = mtk_rtc_set_time,
> + .read_alarm = mtk_rtc_read_alarm,
> + .set_alarm = mtk_rtc_set_alarm,
> +};
> +
> +static int mtk_rtc_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> + struct mt6397_rtc *rtc;
> + int ret = 0;
> +
> + rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt6397_rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + rtc->addr_base = res->start;
> + rtc->addr_range = res->end - res->start;
> +
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start);
> + if (rtc->irq <= 0)
> + goto out_rtc;
Just return an error code here directly. Which one is actually a good
question. Looks like existing code is using -EINVAL or -ENXIO. Any
ideas?
> +
> + rtc->regmap = mt6397_chip->regmap;
> + rtc->dev = &pdev->dev;q
> + mutex_init(&rtc->lock);
> +
> + platform_set_drvdata(pdev, rtc);
> +
> + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> + mtk_rtc_irq_handler_thread,
> + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> + "mt6397-rtc", rtc);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
> + rtc->irq, ret);
> + goto out_rtc;
> + }
> +
> + rtc->rtc_dev = rtc_device_register("mt6397-rtc", &pdev->dev,
> + &mtk_rtc_ops, THIS_MODULE);
> + if (IS_ERR(rtc->rtc_dev)) {
> + dev_err(&pdev->dev, "register rtc device failed\n");
> + return PTR_ERR(rtc->rtc_dev);
> + }
> +
> + device_init_wakeup(&pdev->dev, 1);
> +
> + return 0;
> +
> +out_rtc:
> + rtc_device_unregister(rtc->rtc_dev);
All references to this label are actually before rtc_device_register()
is even called. The proper thing to do here is to dispose the created
IRQ mapping.
> + return ret;
> +
> +}
> +
> +static int mtk_rtc_remove(struct platform_device *pdev)
> +{
> + struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
> +
> + rtc_device_unregister(rtc->rtc_dev);
What about the IRQ mapping created in probe?
Best regards,
Tomasz
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
[not found] ` <CAKdAkRSRXZ=1T+2Mfvjc4DsCCt1rxqGZpEuOUkU5KfPD2__BnQ@mail.gmail.com>
@ 2015-03-30 8:15 ` Eddie Huang
2015-03-31 22:01 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Eddie Huang @ 2015-03-30 8:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Lee Jones, Alessandro Zummo, Matthias Brugger, srv_heupstream,
Samuel Ortiz, Andrew Morton, David S. Miller, Greg KH,
Mauro Carvalho Chehab, Joe Perches, Tejun Heo, Jingoo Han, lkml,
rtc-linux, linux-arm-kernel@lists.infradead.org, linux-mediatek,
Uwe Kleine-König, Tianping Fang
Hi Dmitry,
On Fri, 2015-03-20 at 22:25 -0700, Dmitry Torokhov wrote:
> Hi Eddie,
>
>
> On Tue, Mar 17, 2015 at 10:45 PM, Eddie Huang <eddie.huang@mediatek.com> wrote:
> > +static int mtk_rtc_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> > + struct mt6397_rtc *rtc;
> > + int ret = 0;
> > +
> > + rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt6397_rtc), GFP_KERNEL);
> > + if (!rtc)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + rtc->addr_base = res->start;
> > + rtc->addr_range = res->end - res->start;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > + rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start);
> > + if (rtc->irq <= 0)
> > + goto out_rtc;
> > +
> > + rtc->regmap = mt6397_chip->regmap;
> > + rtc->dev = &pdev->dev;
> > + mutex_init(&rtc->lock);
> > +
> > + platform_set_drvdata(pdev, rtc);
> > +
> > + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> > + mtk_rtc_irq_handler_thread,
> > + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > + "mt6397-rtc", rtc);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
> > + rtc->irq, ret);
> > + goto out_rtc;
> > + }
> > +
> > + rtc->rtc_dev = rtc_device_register("mt6397-rtc", &pdev->dev,
> > + &mtk_rtc_ops, THIS_MODULE);
> > + if (IS_ERR(rtc->rtc_dev)) {
> > + dev_err(&pdev->dev, "register rtc device failed\n");
> > + return PTR_ERR(rtc->rtc_dev);
> > + }
> > +
> > + device_init_wakeup(&pdev->dev, 1);
> > +
> > + return 0;
> > +
> > +out_rtc:
> > + rtc_device_unregister(rtc->rtc_dev);
>
> This is wrong. Whenever you jump to this label the RTC device has not
> been registered yet.
Oops, will fix in next round.
Eddie
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [rtc-linux] Re: [PATCH v2 1/3] mfd: provide RTC resource in MT6397 MFD
[not found] ` <20150318073045.GE3318@x1>
@ 2015-03-30 8:17 ` Eddie Huang
0 siblings, 0 replies; 6+ messages in thread
From: Eddie Huang @ 2015-03-30 8:17 UTC (permalink / raw)
To: Lee Jones
Cc: Alessandro Zummo, Matthias Brugger, srv_heupstream, Samuel Ortiz,
Andrew Morton, David S. Miller, Greg KH, Mauro Carvalho Chehab,
Joe Perches, Tejun Heo, Jingoo Han, linux-kernel, rtc-linux,
linux-arm-kernel, linux-mediatek, Uwe Kleine-König
Hi Lee,
On Wed, 2015-03-18 at 07:30 +0000, Lee Jones wrote:
> On Wed, 18 Mar 2015, Eddie Huang wrote:
>
> > Provide MT6397 RTC interrupt, base address, and register in
> > MT6397 MFD.
> >
> > Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
> > ---
> > drivers/mfd/mt6397-core.c | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> > index b61c4eb..ef431d8 100644
> > --- a/drivers/mfd/mt6397-core.c
> > +++ b/drivers/mfd/mt6397-core.c
> > @@ -21,9 +21,24 @@
> > #include <linux/mfd/mt6397/core.h>
> > #include <linux/mfd/mt6397/registers.h>
> >
> > +static const struct resource mt6397_rtc_resources[] = {
> > + {
> > + .start = 0xe000,
> > + .end = 0xe03e,
>
> I'd like to see these defined please.
>
Sure, will change to use define next round.
Eddie
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
2015-03-30 7:41 ` [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver 'Tomasz Figa' via rtc-linux
@ 2015-03-31 9:44 ` Eddie Huang
2015-03-31 11:01 ` Tomasz Figa
0 siblings, 1 reply; 6+ messages in thread
From: Eddie Huang @ 2015-03-31 9:44 UTC (permalink / raw)
To: Tomasz Figa
Cc: Lee Jones, Alessandro Zummo, Matthias Brugger, Samuel Ortiz,
srv_heupstream, Mauro Carvalho Chehab, rtc-linux, Greg KH,
Jingoo Han, linux-kernel@vger.kernel.org, Tianping Fang,
Tejun Heo, linux-mediatek, Uwe Kleine-König,
Joe Perches, Andrew Morton, David S. Miller,
linux-arm-kernel@lists.infradead.org
Hi Tomasz,
On Mon, 2015-03-30 at 16:41 +0900, Tomasz Figa wrote:
> Hi Eddie,
>
> Please see my comments inline.
>
> On Wed, Mar 18, 2015 at 2:45 PM, Eddie Huang <eddie.huang@mediatek.com> wrote:
> > From: Tianping Fang <tianping.fang@mediatek.com>
> >
> > Add Mediatek MT6397 RTC driver
>
> [snip]
>
> > +#define RTC_BBPU 0x0000
> > +#define RTC_WRTGR 0x003c
> > +#define RTC_IRQ_EN 0x0004
> > +#define RTC_IRQ_STA 0x0002
> > +
> > +#define RTC_BBPU_CBUSY (1 << 6)
> > +#define RTC_IRQ_STA_AL (1 << 0)
> > +#define RTC_IRQ_STA_LP (1 << 3)
>
> nit: Could you use BIT() macro for definitions of single bits? (+
> further occurrences in the patch)
Will fix it.
>
> [snip]
>
> > +
> > +static int mtk_rtc_read(struct mt6397_rtc *rtc, u32 offset, u32 *data)
> > +{
> > + u32 addr = rtc->addr_base + offset;
> > +
> > + if (offset < rtc->addr_range)
> > + return regmap_read(rtc->regmap, addr, data);
> > +
> > + return -EINVAL;
> > +}
> > +
> > +static int mtk_rtc_write(struct mt6397_rtc *rtc, u32 offset, u32 data)
> > +{
> > + u32 addr;
> > +
> > + addr = rtc->addr_base + offset;
> > +
> > + if (offset < rtc->addr_range)
> > + return regmap_write(rtc->regmap, addr, data);
> > +
> > + return -EINVAL;
> > +}
>
> Do you actually need these wrappers? Could you use regmap_write() and
> _read() directly? This would also enable you to use
> regmap_update_bits() instead of implicit read, modify and write.
These wrappers used to check register range. But I think the check is
redundant, I will bypass the check and use regmap API directly.
>
> > +
> > +static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> > +{
> > + int ret;
> > + u32 data;
> > +
> > + ret = mtk_rtc_write(rtc, RTC_WRTGR, 1);
> > + if (ret < 0)
> > + goto exit;
> > +
> > + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
> > + if (ret < 0)
> > + goto exit;
> > +
> > + while (data & RTC_BBPU_CBUSY) {
> > + cpu_relax();
> > + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
> > + if (ret < 0)
> > + goto exit;
> > + }
>
> The initial read and the loop could be folded into a do {} while loop?
> Also it would be safer to have a timeout here.
Because I need to check return value, so not put initial read in do { }.
Indeed, it is safer to add timeout here.
> > +
> > +static int __mtk_rtc_read_time(struct mt6397_rtc *rtc,
> > + struct rtc_time *tm, int *sec)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&rtc->lock);
> > + ret = mtk_rtc_read(rtc, RTC_TC_SEC, &tm->tm_sec);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_MIN, &tm->tm_min);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_HOU, &tm->tm_hour);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_DOM, &tm->tm_mday);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_MTH, &tm->tm_mon);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_YEA, &tm->tm_year);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_TC_SEC, sec);
>
> Would the hardware allow this to be merged into single burst transfer
> reading all the registers into a buffer, so then you could just copy
> the values from that buffer into target struct instead of issuing
> multiple reads one by one?
OK, Sascha already mentioned this before, I think I should change to use
single burst reading.
>
> Also shouldn't the unused bits be masked out?
Hardware return zero in unused bits. So I think it not necessary to add
mask.
>
> > +
> > +exit:
> > + mutex_unlock(&rtc->lock);
> > + return ret;
> > +}
> > +
> > +static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + time64_t time;
> > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> > + int sec, ret;
> > +
> > + do {
> > + ret = __mtk_rtc_read_time(rtc, tm, &sec);
> > + if (ret < 0)
> > + goto exit;
> > + } while (sec < tm->tm_sec);
>
> Shouldn't this be while (sec > tm->tm_sec)?
No, it should keep it as is, this is used to check whether second
overflow (from 59 to 0). If yes, read time again.
>
> > +
> > + tm->tm_year += RTC_MIN_YEAR_OFFSET;
> > + tm->tm_mon--;
>
> Could you add a comment explaining why this is decremented?
Year register only have 7bits, use RTC_MIN_YEAR_OFFSET to reduce bit
usage. Minus the offset before write to register and add back the offset
after read register back. And month register start from 1, but tm_mon
start from zero. I will add comment.
>
> > + time = rtc_tm_to_time64(tm);
> > +
> > + tm->tm_wday = (time / 86400 + 4) % 7;
>
> Could you add a comment, or even better, an inline function with a
> comment, explaining this calculation?
rtc_tm_to_time64 function return time base on 01-01-1970 00:00:00.
This base time is Thursday. I will add comment
>
> > +
> > +exit:
> > + return ret;
> > +}
> > +
> > +static int mtk_rtc_set_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> > + tm->tm_mon++;
> > +
> > + mutex_lock(&rtc->lock);
> > + ret = mtk_rtc_write(rtc, RTC_TC_YEA, tm->tm_year);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_TC_MTH, tm->tm_mon);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_TC_DOM, tm->tm_mday);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_TC_HOU, tm->tm_hour);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_TC_MIN, tm->tm_min);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_TC_SEC, tm->tm_sec);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write_trigger(rtc);
> > +
> > +exit:
> > + mutex_unlock(&rtc->lock);
> > + return ret;
> > +}
> > +
> > +static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> > +{
> > + struct rtc_time *tm = &alm->time;
> > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> > + u32 irqen, pdn2;
> > + int ret;
> > +
> > + mutex_lock(&rtc->lock);
> > + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_PDN2, &pdn2);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_SEC, &tm->tm_sec);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_MIN, &tm->tm_min);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_HOU, &tm->tm_hour);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_DOM, &tm->tm_mday);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_MTH, &tm->tm_mon);
> > + if (ret < 0)
> > + goto err_exit;
> > + ret = mtk_rtc_read(rtc, RTC_AL_YEA, &tm->tm_year);
> > + if (ret < 0)
> > + goto err_exit;
>
> Similarly to _read_time(), could this be changed into a single burst read?
will change API.
>
> > +
> > + alm->enabled = !!(irqen & RTC_IRQ_EN_AL);
> > + alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> > + mutex_unlock(&rtc->lock);
> > +
> > + tm->tm_year += RTC_MIN_YEAR_OFFSET;
> > + tm->tm_mon--;
> > +
> > + return 0;
> > +err_exit:
> > + mutex_unlock(&rtc->lock);
> > + return ret;
> > +}
> > +
> > +static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> > +{
> > + struct rtc_time *tm = &alm->time;
> > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> > + u32 irqen;
> > + int ret;
> > +
> > + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> > + tm->tm_mon++;
> > +
> > + mutex_lock(&rtc->lock);
> > + if (alm->enabled) {
>
> Is this possible that an alarm was already set? Is it okay to keep it
> enabled while changing the alarm time to new one?
It's ok because all alarm time register set to hardware after call
mtk_rtc_write_trigger.
>
> > + ret = mtk_rtc_write(rtc, RTC_AL_YEA, tm->tm_year);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_MTH, tm->tm_mon);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_DOM, tm->tm_mday);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_HOU, tm->tm_hour);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_MIN, tm->tm_min);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_SEC, tm->tm_sec);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write(rtc, RTC_AL_MASK, RTC_AL_MASK_DOW);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_write_trigger(rtc);
> > + if (ret < 0)
> > + goto exit;
> > + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> > + if (ret < 0)
> > + goto exit;
> > + irqen |= RTC_IRQ_EN_ONESHOT_AL;
> > + ret = mtk_rtc_write(rtc, RTC_IRQ_EN, irqen);
> > + if (ret < 0)
> > + goto exit;
>
> regmap_update_bits() could be used instead of the read, modify and write above.
I will check how to use this api.
>
> > + ret = mtk_rtc_write_trigger(rtc);
> > + if (ret < 0)
> > + goto exit;
> > + } else {
> > + ret = mtk_rtc_read(rtc, RTC_IRQ_EN, &irqen);
> > + if (ret < 0)
> > + goto exit;
> > + irqen &= ~RTC_IRQ_EN_ONESHOT_AL;
> > + ret = mtk_rtc_write(rtc, RTC_IRQ_EN, irqen);
> > + if (ret < 0)
> > + goto exit;
>
> Ditto.
>
> > + }
> > +
> > +exit:
> > + mutex_unlock(&rtc->lock);
> > + return ret;
> > +}
> > +
> > +static struct rtc_class_ops mtk_rtc_ops = {
> > + .read_time = mtk_rtc_read_time,
> > + .set_time = mtk_rtc_set_time,
> > + .read_alarm = mtk_rtc_read_alarm,
> > + .set_alarm = mtk_rtc_set_alarm,
> > +};
> > +
> > +static int mtk_rtc_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> > + struct mt6397_rtc *rtc;
> > + int ret = 0;
> > +
> > + rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt6397_rtc), GFP_KERNEL);
> > + if (!rtc)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + rtc->addr_base = res->start;
> > + rtc->addr_range = res->end - res->start;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > + rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start);
> > + if (rtc->irq <= 0)
> > + goto out_rtc;
>
> Just return an error code here directly. Which one is actually a good
> question. Looks like existing code is using -EINVAL or -ENXIO. Any
> ideas?
I tend to use -EINVAL
>
> > +
> > + rtc->regmap = mt6397_chip->regmap;
> > + rtc->dev = &pdev->dev;q
> > + mutex_init(&rtc->lock);
> > +
> > + platform_set_drvdata(pdev, rtc);
> > +
> > + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> > + mtk_rtc_irq_handler_thread,
> > + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > + "mt6397-rtc", rtc);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
> > + rtc->irq, ret);
> > + goto out_rtc;
> > + }
> > +
> > + rtc->rtc_dev = rtc_device_register("mt6397-rtc", &pdev->dev,
> > + &mtk_rtc_ops, THIS_MODULE);
> > + if (IS_ERR(rtc->rtc_dev)) {
> > + dev_err(&pdev->dev, "register rtc device failed\n");
> > + return PTR_ERR(rtc->rtc_dev);
> > + }
> > +
> > + device_init_wakeup(&pdev->dev, 1);
> > +
> > + return 0;
> > +
> > +out_rtc:
> > + rtc_device_unregister(rtc->rtc_dev);
>
> All references to this label are actually before rtc_device_register()
> is even called. The proper thing to do here is to dispose the created
> IRQ mapping.
OK, will call irq_dispose_mapping and free_irq
>
> > + return ret;
> > +
> > +}
> > +
> > +static int mtk_rtc_remove(struct platform_device *pdev)
> > +{
> > + struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
> > +
> > + rtc_device_unregister(rtc->rtc_dev);
>
> What about the IRQ mapping created in probe?
OK, will call irq_dispose_mapping and free_irq
>
Eddie
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
2015-03-31 9:44 ` Eddie Huang
@ 2015-03-31 11:01 ` Tomasz Figa
0 siblings, 0 replies; 6+ messages in thread
From: Tomasz Figa @ 2015-03-31 11:01 UTC (permalink / raw)
To: Eddie Huang, Lee Jones
Cc: Alessandro Zummo, Matthias Brugger, Samuel Ortiz, srv_heupstream,
Mauro Carvalho Chehab, rtc-linux, Greg KH, Jingoo Han,
linux-kernel@vger.kernel.org, Tianping Fang, Tejun Heo,
linux-mediatek, Uwe Kleine-König, Joe Perches,
Andrew Morton, David S. Miller,
linux-arm-kernel@lists.infradead.org
Hi Eddie,
Please see my response inline.
On Tue, Mar 31, 2015 at 6:44 PM, Eddie Huang <eddie.huang@mediatek.com> wrote:
[snip]
>> > + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
>> > + if (ret < 0)
>> > + goto exit;
>> > +
>> > + while (data & RTC_BBPU_CBUSY) {
>> > + cpu_relax();
>> > + ret = mtk_rtc_read(rtc, RTC_BBPU, &data);
>> > + if (ret < 0)
>> > + goto exit;
>> > + }
>>
>> The initial read and the loop could be folded into a do {} while loop?
>> Also it would be safer to have a timeout here.
> Because I need to check return value, so not put initial read in do { }.
Hmm, inside the loop you also check return value. Considering the fact
that cpu_relax() doesn't do anything interesting besides issuing a
memory barrier (and probably could be omitted here) I don't see why
this couldn't be made a do {} while loop. (Obviously this is a bit of
bikeshedding, but by the way of other changes this could be changed as
well.)
[snip]
>>
>> Also shouldn't the unused bits be masked out?
> Hardware return zero in unused bits. So I think it not necessary to add
> mask.
>
OK. Thanks for explaining this.
>>
>> > +
>> > +exit:
>> > + mutex_unlock(&rtc->lock);
>> > + return ret;
>> > +}
>> > +
>> > +static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
>> > +{
>> > + time64_t time;
>> > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
>> > + int sec, ret;
>> > +
>> > + do {
>> > + ret = __mtk_rtc_read_time(rtc, tm, &sec);
>> > + if (ret < 0)
>> > + goto exit;
>> > + } while (sec < tm->tm_sec);
>>
>> Shouldn't this be while (sec > tm->tm_sec)?
> No, it should keep it as is, this is used to check whether second
> overflow (from 59 to 0). If yes, read time again.
>
Ah, right, of course, an overlooking on my side. Thanks for clarifying this.
[snip]
>> > + mutex_lock(&rtc->lock);
>> > + if (alm->enabled) {
>>
>> Is this possible that an alarm was already set? Is it okay to keep it
>> enabled while changing the alarm time to new one?
> It's ok because all alarm time register set to hardware after call
> mtk_rtc_write_trigger.
>
Fair enough. Thanks for explanation. Could you maybe add a comment
here saying that the new alarm setting will be committed after calling
mtk_rtc_write_trigger()?
[snip]
>> > + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> > + rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start);
>> > + if (rtc->irq <= 0)
>> > + goto out_rtc;
>>
>> Just return an error code here directly. Which one is actually a good
>> question. Looks like existing code is using -EINVAL or -ENXIO. Any
>> ideas?
> I tend to use -EINVAL
SGTM.
[snip]
>> > +
>> > +out_rtc:
>> > + rtc_device_unregister(rtc->rtc_dev);
>>
>> All references to this label are actually before rtc_device_register()
>> is even called. The proper thing to do here is to dispose the created
>> IRQ mapping.
> OK, will call irq_dispose_mapping and free_irq
>
OK, thanks. Please note that this will also mean changing
devm_request_threaded_irq() to normal request_threaded_irq().
Still, now as I think of it, I'm not sure if this driver is the right
place to call irq_create_mapping(). Instead, shouldn't the parent MFD
driver create the mapping and pass the final virtual IRQ number to
this driver through resources?
Lee, could you comment on this, please?
Best regards,
Tomasz
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
2015-03-30 8:15 ` Eddie Huang
@ 2015-03-31 22:01 ` Andrew Morton
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2015-03-31 22:01 UTC (permalink / raw)
To: Eddie Huang
Cc: Dmitry Torokhov, Lee Jones, Alessandro Zummo, Matthias Brugger,
srv_heupstream, Samuel Ortiz, David S. Miller, Greg KH,
Mauro Carvalho Chehab, Joe Perches, Tejun Heo, Jingoo Han, lkml,
rtc-linux, linux-arm-kernel@lists.infradead.org, linux-mediatek,
Uwe Kleine-König, Tianping Fang
On Mon, 30 Mar 2015 16:15:50 +0800 Eddie Huang <eddie.huang@mediatek.com> wrote:
> > > +out_rtc:
> > > + rtc_device_unregister(rtc->rtc_dev);
> >
> > This is wrong. Whenever you jump to this label the RTC device has not
> > been registered yet.
>
> Oops, will fix in next round.
Please ensure that Uwe's review comments (starting at
https://lkml.org/lkml/2015/3/17/494) have been addressed.
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-03-31 22:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1426657537-41414-1-git-send-email-eddie.huang@mediatek.com>
[not found] ` <1426657537-41414-3-git-send-email-eddie.huang@mediatek.com>
2015-03-30 7:41 ` [rtc-linux] Re: [PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver 'Tomasz Figa' via rtc-linux
2015-03-31 9:44 ` Eddie Huang
2015-03-31 11:01 ` Tomasz Figa
[not found] ` <CAKdAkRSRXZ=1T+2Mfvjc4DsCCt1rxqGZpEuOUkU5KfPD2__BnQ@mail.gmail.com>
2015-03-30 8:15 ` Eddie Huang
2015-03-31 22:01 ` Andrew Morton
[not found] ` <1426657537-41414-2-git-send-email-eddie.huang@mediatek.com>
[not found] ` <20150318073045.GE3318@x1>
2015-03-30 8:17 ` [rtc-linux] Re: [PATCH v2 1/3] mfd: provide RTC resource in MT6397 MFD Eddie Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox