| Message ID | 1354155670-6267-2-git-send-email-chao.xie@marvell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Chao Xie <chao.xie@marvell.com> writes: Hi Chao Xie, First of all, could you please send patches from rtc-pxa to me also, as I'm maintaining that driver ? Second point, the original design of the driver relies on the special case of writing zeroes to WOM and DOM, as mentionned in PXA27x Developers Guide, chapter 21.4.2.3.5 "Writing Alarm Registers with Invalid (Zero) Data", which states : > Day-Of-Week (DOW), or Week-Of-Month (WOM), Day of Month (DOM), Month or Year > fields—Zero is not valid for these fields. If zero is written into any of > these fields, it is ignored while generating the alarm. I'd like to know if your patch fixes something, or is an enhancement ? Cheers. -- Robert PS: I've not checked the patch yet, that's just a prelimary comment on the patch message.
On Fri, Nov 30, 2012 at 4:04 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > Chao Xie <chao.xie@marvell.com> writes: > > Hi Chao Xie, > > First of all, could you please send patches from rtc-pxa to me also, as I'm > maintaining that driver ? > > Second point, the original design of the driver relies on the special case of > writing zeroes to WOM and DOM, as mentionned in PXA27x Developers Guide, chapter > 21.4.2.3.5 "Writing Alarm Registers with Invalid (Zero) Data", which states : >> Day-Of-Week (DOW), or Week-Of-Month (WOM), Day of Month (DOM), Month or Year >> fields—Zero is not valid for these fields. If zero is written into any of >> these fields, it is ignored while generating the alarm. > > I'd like to know if your patch fixes something, or is an enhancement ? > > Cheers. > > -- > Robert > > PS: I've not checked the patch yet, that's just a prelimary comment on the patch > message. hi I am sorry, i just use get_maintainer.pl to get the "to" list. I have go through the spec. The spec has the desctiption about the invalid data writing. I am a little confused about the "wrting 0 to DOW". The descrption is confused. first it said that "If zero is written into any of these fields, it is ignored while generating the alarm", then it gives a example, that if writing 0 to DOW, "For example, if a zero is written into a DOW field, the alarm is set every day at the time written in the Hours, Minutes, and Seconds field”. It seems that the Year/Month/Week will not take effect. I will do the test on the board again, and send out the update.
On Mon, Dec 3, 2012 at 10:40 AM, Chao Xie <xiechao.mail@gmail.com> wrote: > On Fri, Nov 30, 2012 at 4:04 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: >> Chao Xie <chao.xie@marvell.com> writes: >> >> Hi Chao Xie, >> >> First of all, could you please send patches from rtc-pxa to me also, as I'm >> maintaining that driver ? >> >> Second point, the original design of the driver relies on the special case of >> writing zeroes to WOM and DOM, as mentionned in PXA27x Developers Guide, chapter >> 21.4.2.3.5 "Writing Alarm Registers with Invalid (Zero) Data", which states : >>> Day-Of-Week (DOW), or Week-Of-Month (WOM), Day of Month (DOM), Month or Year >>> fields—Zero is not valid for these fields. If zero is written into any of >>> these fields, it is ignored while generating the alarm. >> >> I'd like to know if your patch fixes something, or is an enhancement ? >> >> Cheers. >> >> -- >> Robert >> >> PS: I've not checked the patch yet, that's just a prelimary comment on the patch >> message. > > hi > I am sorry, i just use get_maintainer.pl to get the "to" list. > I have go through the spec. The spec has the desctiption about the > invalid data writing. > I am a little confused about the "wrting 0 to DOW". The descrption is > confused. first it said that "If zero is written into any of these > fields, it is ignored > while generating the alarm", then it gives a example, that if writing > 0 to DOW, "For example, if a zero is written into a DOW field, the > alarm is set > every day at the time written in the Hours, Minutes, and Seconds > field”. It seems that the Year/Month/Week will not take effect. > I will do the test on the board again, and send out the update. hi, Robert You are right. it does not matter to set WOM and DOW. please ignore this patch.
diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c index f771b2e..22ea4f5 100644 --- a/drivers/rtc/rtc-pxa.c +++ b/drivers/rtc/rtc-pxa.c @@ -62,6 +62,10 @@ #define RYxR_MONTH_S 5 #define RYxR_MONTH_MASK (0xf << RYxR_MONTH_S) #define RYxR_DAY_MASK 0x1f +#define RDxR_WOM_S 20 +#define RDxR_WOM_MASK (0x7 << RDxR_WOM_S) +#define RDxR_DOW_S 17 +#define RDxR_DOW_MASK (0x7 << RDxR_DOW_S) #define RDxR_HOUR_S 12 #define RDxR_HOUR_MASK (0x1f << RDxR_HOUR_S) #define RDxR_MIN_S 6 @@ -100,7 +104,10 @@ static u32 ryxr_calc(struct rtc_time *tm) static u32 rdxr_calc(struct rtc_time *tm) { - return (tm->tm_hour << RDxR_HOUR_S) | (tm->tm_min << RDxR_MIN_S) + return ((((tm->tm_mday + 6) / 7) << RDxR_WOM_S) & RDxR_WOM_MASK) + | (((tm->tm_wday + 1) << RDxR_DOW_S) & RDxR_DOW_MASK) + | (tm->tm_hour << RDxR_HOUR_S) + | (tm->tm_min << RDxR_MIN_S) | tm->tm_sec; } @@ -109,6 +116,7 @@ static void tm_calc(u32 rycr, u32 rdcr, struct rtc_time *tm) tm->tm_year = ((rycr & RYxR_YEAR_MASK) >> RYxR_YEAR_S) - 1900; tm->tm_mon = (((rycr & RYxR_MONTH_MASK) >> RYxR_MONTH_S)) - 1; tm->tm_mday = (rycr & RYxR_DAY_MASK); + tm->tm_wday = ((rdcr & RDxR_DOW_MASK) >> RDxR_DOW_S) - 1; tm->tm_hour = (rdcr & RDxR_HOUR_MASK) >> RDxR_HOUR_S; tm->tm_min = (rdcr & RDxR_MIN_MASK) >> RDxR_MIN_S; tm->tm_sec = rdcr & RDxR_SEC_MASK;
The original calculation does not take care of week-of-month and day-of-week. It will make rdar/rdcr not matched when set the alarm. Signed-off-by: Chao Xie <chao.xie@marvell.com> --- drivers/rtc/rtc-pxa.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)