[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[Peter Ujfalusi]

SYS_NIRQ2 is servicing the interrupt from twl6040.
Configure the SYS_NIRQ2 so we can actually receive the interrupts.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 board/ti/sdp4430/sdp4430_mux_data.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/ti/sdp4430/sdp4430_mux_data.h b/board/ti/sdp4430/sdp4430_mux_data.h
index 0a20968..beb7c7a 100644
--- a/board/ti/sdp4430/sdp4430_mux_data.h
+++ b/board/ti/sdp4430/sdp4430_mux_data.h
@@ -216,7 +216,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{FREF_CLK1_OUT, (M0)},						/* fref_clk1_out */
 	{FREF_CLK2_OUT, (M0)},						/* fref_clk2_out */
 	{SYS_NIRQ1, (PTU | IEN | M0)},					/* sys_nirq1 */
-	{SYS_NIRQ2, (M7)},						/* sys_nirq2 */
+	{SYS_NIRQ2, (PTU | IEN | M0)},					/* sys_nirq2 */
 	{SYS_BOOT0, (PTU | IEN | M3)},					/* gpio_184 */
 	{SYS_BOOT1, (M3)},						/* gpio_185 */
 	{SYS_BOOT2, (PTD | IEN | M3)},					/* gpio_186 */
-- 
1.7.8.6

[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[R, Sricharan]

Hi Peter,

> ?board/ti/sdp4430/sdp4430_mux_data.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/board/ti/sdp4430/sdp4430_mux_data.h b/board/ti/sdp4430/sdp4430_mux_data.h
> index 0a20968..beb7c7a 100644
> --- a/board/ti/sdp4430/sdp4430_mux_data.h
> +++ b/board/ti/sdp4430/sdp4430_mux_data.h
> @@ -216,7 +216,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
> ? ? ? ?{FREF_CLK1_OUT, (M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* fref_clk1_out */
> ? ? ? ?{FREF_CLK2_OUT, (M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* fref_clk2_out */
> ? ? ? ?{SYS_NIRQ1, (PTU | IEN | M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq1 */
> - ? ? ? {SYS_NIRQ2, (M7)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq2 */
> + ? ? ? {SYS_NIRQ2, (PTU | IEN | M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq2 */

   Looks fine. But how about doing this in the kernel using mux framework?

Thanks,
 Sricharan

[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[Peter Ujfalusi]

Hi Sricharan,

On 05/17/2012 11:48 AM, R, Sricharan wrote:
>> diff --git a/board/ti/sdp4430/sdp4430_mux_data.h b/board/ti/sdp4430/sdp4430_mux_data.h
>> index 0a20968..beb7c7a 100644
>> --- a/board/ti/sdp4430/sdp4430_mux_data.h
>> +++ b/board/ti/sdp4430/sdp4430_mux_data.h
>> @@ -216,7 +216,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
>>        {FREF_CLK1_OUT, (M0)},                                          /* fref_clk1_out */
>>        {FREF_CLK2_OUT, (M0)},                                          /* fref_clk2_out */
>>        {SYS_NIRQ1, (PTU | IEN | M0)},                                  /* sys_nirq1 */
>> -       {SYS_NIRQ2, (M7)},                                              /* sys_nirq2 */
>> +       {SYS_NIRQ2, (PTU | IEN | M0)},                                  /* sys_nirq2 */
> 
>    Looks fine. But how about doing this in the kernel using mux framework?

The SYS_NIRQ2 has been configured correctly in case of PandaBoard in u-boot.
Looking at the kernel: neither of the sdp4430 or PandaBoard board files
are configuring SYS_NIRQ1/2, all relies on the bootloader to set this up.
I can as well send patches for sdp4430 and PandaBoard board files to
configure the SYS_NIRQ2 explicitly, but IMHO the bootloader can do this
for us with ease as well.
I think if we can we should set up things in a bootloader and let the
kernel to deal with smaller differences (like things differs between
board revisions and stuff).

Regards,
P?ter

[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[R, Sricharan]

Hi peter,

>>> @@ -216,7 +216,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
>>> ? ? ? ?{FREF_CLK1_OUT, (M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* fref_clk1_out */
>>> ? ? ? ?{FREF_CLK2_OUT, (M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* fref_clk2_out */
>>> ? ? ? ?{SYS_NIRQ1, (PTU | IEN | M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq1 */
>>> - ? ? ? {SYS_NIRQ2, (M7)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq2 */
>>> + ? ? ? {SYS_NIRQ2, (PTU | IEN | M0)}, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* sys_nirq2 */
>>
>> ? ?Looks fine. But how about doing this in the kernel using mux framework?
>
> The SYS_NIRQ2 has been configured correctly in case of PandaBoard in u-boot.
> Looking at the kernel: neither of the sdp4430 or PandaBoard board files
> are configuring SYS_NIRQ1/2, all relies on the bootloader to set this up.
> I can as well send patches for sdp4430 and PandaBoard board files to
> configure the SYS_NIRQ2 explicitly, but IMHO the bootloader can do this
> for us with ease as well.
> I think if we can we should set up things in a bootloader and let the
> kernel to deal with smaller differences (like things differs between
> board revisions and stuff).
  The issue here is we want to remove the way, kernel is dependent on
 bootloader for these settings. The bootloader should only the minimum required
 for boot. In fact we should get rid of this entire
core_padconf_array_non_essential
 itself. We have already seen that certain pins when set in bootloader
and not used
 in kernel creates problem during power transitions etc.  The only
solution is to
 remove all these in the bootloader..

Thanks,
 Sricharan

[U-Boot] [PATCH] sdp4430: fix mux configuration for SYS_NIRQ2

[Ujfalusi, Peter]

Hi Sricharan,

On Fri, May 18, 2012 at 7:41 AM, R, Sricharan <r.sricharan@ti.com> wrote:

> ?The issue here is we want to remove the way, kernel is dependent on
> ?bootloader for these settings. The bootloader should only the minimum required
> ?for boot. In fact we should get rid of this entire
> core_padconf_array_non_essential
> ?itself. We have already seen that certain pins when set in bootloader
> and not used
> ?in kernel creates problem during power transitions etc. ?The only
> solution is to
> ?remove all these in the bootloader..

Fair enough. I will send the patch for the kernel after my holiday.

-- 
P?ter