| Message ID | CAOMZO5CAkP4ugh-nLU=wqBPXTNePuxerWugd_tKxB3TDQ+0dsg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 1/17/12, Fabio Estevam <festevam@gmail.com> wrote: > On 1/16/12, Fabio Estevam <festevam@gmail.com> wrote: > >> I will make more tests to confirm and post a new patch. > > On my tests I am always getting the BUSY bit of HW_CLKCTRL_SAIF0 as 1, > no matter the timeout I add. > > BUSY bit is bit 29 of this register and matches the mx28 reference > manual description. > > Looking at the Freescale kernel this BUSY bit is defined as 1 instead. Not really, I looked at the wrong register. The issue can be solved by clearing CLKGATE bit prior to writing to DIV field, as described in the mx28 reference manual. Just sent the updated patch that allows audio to work on mx28. Regards, Fabio Estevam
diff --git a/arch/arm/mach-mxs/regs-clkctrl-mx28.h b/arch/arm/mach-mxs/regs-clkctrl-mx28.h index 7d1b061..1813ff0 100644 --- a/arch/arm/mach-mxs/regs-clkctrl-mx28.h +++ b/arch/arm/mach-mxs/regs-clkctrl-mx28.h @@ -288,7 +288,7 @@ #define BP_CLKCTRL_SAIF0_CLKGATE 31 #define BM_CLKCTRL_SAIF0_CLKGATE 0x80000000 -#define BM_CLKCTRL_SAIF0_BUSY 0x20000000 +#define BM_CLKCTRL_SAIF0_BUSY 1 #define BM_CLKCTRL_SAIF0_DIV_FRAC_EN 0x00010000 #define BP_CLKCTRL_SAIF0_DIV 0 #define BM_CLKCTRL_SAIF0_DIV 0x0000FFFF @@ -299,7 +299,7 @@ #define BP_CLKCTRL_SAIF1_CLKGATE 31 #define BM_CLKCTRL_SAIF1_CLKGATE 0x80000000 -#define BM_CLKCTRL_SAIF1_BUSY 0x20000000 +#define BM_CLKCTRL_SAIF1_BUSY 1 #define BM_CLKCTRL_SAIF1_DIV_FRAC_EN 0x00010000 #define BP_CLKCTRL_SAIF1_DIV 0 #define BM_CLKCTRL_SAIF1_DIV 0x0000FFFF
On 1/16/12, Fabio Estevam <festevam@gmail.com> wrote: > I will make more tests to confirm and post a new patch. On my tests I am always getting the BUSY bit of HW_CLKCTRL_SAIF0 as 1, no matter the timeout I add. BUSY bit is bit 29 of this register and matches the mx28 reference manual description. Looking at the Freescale kernel this BUSY bit is defined as 1 instead. If I do the change below: ,then audio can correctly work. Will clarify with Freescale team about this. I plan to also send a patch for replacing the for loops with a proper timeout mechanism as suggested by Wolfram. Regards, Fabio Estevam