Padconf not working on pm_defconfig?

Padconf not working on pm_defconfig?

[Gadiyar, Anand]

I'm seeing some strange behavior with linux-omap-pm branch
and possibly with linux-omap master as well. I booted up
a 3430 SDP with an image built using omap3_pm_defconfig.
(I enabled EHCI in the menuconfig).


The MUX framework reports that some padconfs are being changed:
MUX: setup Y9_3430_USB1HS_PHY_STP (0xfa0025d8): 0x0218 -> 0x0003
MUX: setup Y8_3430_USB1HS_PHY_CLK (0xfa0025da): 0x0200 -> 0x0003
MUX: setup AA14_3430_USB1HS_PHY_DIR (0xfa0025ec): 0x1700 -> 0x010b
MUX: setup AA11_3430_USB1HS_PHY_NXT (0xfa0025ee): 0x1700 -> 0x010b
MUX: setup AA8_3430_USB2HS_PHY_CLK (0xfa0025f0): 0x1700 -> 0x0003
MUX: setup AA9_3430_USB2HS_PHY_DIR (0xfa0025f4): 0x1700 -> 0x010b
MUX: setup T4_3430_USB2HS_PHY_D3 (0xfa0021de): 0x1708 -> 0x010b
MUX: setup T3_3430_USB2HS_PHY_D4 (0xfa0021d8): 0x1700 -> 0x010b

(some lines edited - this is just to illustrate that the MUX
framework thinks the padconfs are changed)



But, a dump of the registers after bootup shows many pads are being
set to GPIO mode:

EHCI Port 1 padconf
0x480025D8 = 0x00040004
0x480025DC = 0x00040004
0x480025E0 = 0x00040004
0x480025E4 = 0x00040004
0x480025E8 = 0x00040004
0x480025EC = 0x00040004

EHCI Port 2 padconf
0x480021D4 = 0x010B010B
0x480021D8 = 0x010B010B
0x480021DC = 0x010B010B
0x480025F0 = 0x00040004
0x480025F4 = 0x00040004
0x480025F8 = 0x00040004


I'll take a look in a while, but if someone already knows the reason
for this, let me know.

- Anand

RE: Padconf not working on pm_defconfig?

[Gupta, Ajay Kumar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Gadiyar, Anand
> Sent: Monday, December 14, 2009 3:24 PM
> To: linux-omap@vger.kernel.org; Kevin Hilman; Tony Lindgren
> Subject: Padconf not working on pm_defconfig?
> 
> I'm seeing some strange behavior with linux-omap-pm branch
> and possibly with linux-omap master as well. I booted up
> a 3430 SDP with an image built using omap3_pm_defconfig.
> (I enabled EHCI in the menuconfig).

Check if CONFIG_OMAP_MUX=y set.

-Ajay
> 
> 
> The MUX framework reports that some padconfs are being changed:
> MUX: setup Y9_3430_USB1HS_PHY_STP (0xfa0025d8): 0x0218 -> 0x0003
> MUX: setup Y8_3430_USB1HS_PHY_CLK (0xfa0025da): 0x0200 -> 0x0003
> MUX: setup AA14_3430_USB1HS_PHY_DIR (0xfa0025ec): 0x1700 -> 0x010b
> MUX: setup AA11_3430_USB1HS_PHY_NXT (0xfa0025ee): 0x1700 -> 0x010b
> MUX: setup AA8_3430_USB2HS_PHY_CLK (0xfa0025f0): 0x1700 -> 0x0003
> MUX: setup AA9_3430_USB2HS_PHY_DIR (0xfa0025f4): 0x1700 -> 0x010b
> MUX: setup T4_3430_USB2HS_PHY_D3 (0xfa0021de): 0x1708 -> 0x010b
> MUX: setup T3_3430_USB2HS_PHY_D4 (0xfa0021d8): 0x1700 -> 0x010b
> 
> (some lines edited - this is just to illustrate that the MUX
> framework thinks the padconfs are changed)
> 
> 
> 
> But, a dump of the registers after bootup shows many pads are being
> set to GPIO mode:
> 
> EHCI Port 1 padconf
> 0x480025D8 = 0x00040004
> 0x480025DC = 0x00040004
> 0x480025E0 = 0x00040004
> 0x480025E4 = 0x00040004
> 0x480025E8 = 0x00040004
> 0x480025EC = 0x00040004
> 
> EHCI Port 2 padconf
> 0x480021D4 = 0x010B010B
> 0x480021D8 = 0x010B010B
> 0x480021DC = 0x010B010B
> 0x480025F0 = 0x00040004
> 0x480025F4 = 0x00040004
> 0x480025F8 = 0x00040004
> 
> 
> I'll take a look in a while, but if someone already knows the reason
> for this, let me know.
> 
> - Anand
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Padconf not working on pm_defconfig?

[Gadiyar, Anand]

Gupta, Ajay Kumar wrote:
> > 
> > I'm seeing some strange behavior with linux-omap-pm branch
> > and possibly with linux-omap master as well. I booted up
> > a 3430 SDP with an image built using omap3_pm_defconfig.
> > (I enabled EHCI in the menuconfig).
> 
> Check if CONFIG_OMAP_MUX=y set.
> 

It's set.

Also, dumping the registers just after the usb-echi.c makes
these mux calls shows they are okay.

Something seems to be changing these later - debugging now.

- Anand

RE: Padconf not working on pm_defconfig?

[Gadiyar, Anand]

Gadiyar, Anand wrote:
> Gupta, Ajay Kumar wrote:
> > > 
> > > I'm seeing some strange behavior with linux-omap-pm branch
> > > and possibly with linux-omap master as well. I booted up
> > > a 3430 SDP with an image built using omap3_pm_defconfig.
> > > (I enabled EHCI in the menuconfig).
> > 
> > Check if CONFIG_OMAP_MUX=y set.
> > 
> 
> It's set.
> 
> Also, dumping the registers just after the usb-echi.c makes
> these mux calls shows they are okay.
> 
> Something seems to be changing these later - debugging now.
> 


Found it - I remember that these lines are muxed with ETK signals
and with the hwdebug signals.

So I looked at the debobs driver - and that's the culprit!
(Cc-ing the author of that driver)

How should this be handled? IMO, this driver has should use the
MUX framework for changing the mux modes.

What say?

- Anand

Re: Padconf not working on pm_defconfig?

[Kevin Hilman]

"Gadiyar, Anand" <gadiyar@ti.com> writes:

> Gadiyar, Anand wrote:
>> Gupta, Ajay Kumar wrote:
>> > > 
>> > > I'm seeing some strange behavior with linux-omap-pm branch
>> > > and possibly with linux-omap master as well. I booted up
>> > > a 3430 SDP with an image built using omap3_pm_defconfig.
>> > > (I enabled EHCI in the menuconfig).
>> > 
>> > Check if CONFIG_OMAP_MUX=y set.
>> > 
>> 
>> It's set.
>> 
>> Also, dumping the registers just after the usb-echi.c makes
>> these mux calls shows they are okay.
>> 
>> Something seems to be changing these later - debugging now.
>> 
>
>
> Found it - I remember that these lines are muxed with ETK signals
> and with the hwdebug signals.
>
> So I looked at the debobs driver - and that's the culprit!
> (Cc-ing the author of that driver)
>
> How should this be handled? IMO, this driver has should use the
> MUX framework for changing the mux modes.
>
> What say?

Yes, the debobs driver needs to be updated to use the MUX API.

But even with that, AFAICT, the new mux API will still allow
the last caller to "win" as there is no request/free API
to get pins.

Kevin

RE: Padconf not working on pm_defconfig?

[Gadiyar, Anand]

Kevin Hilman wroteL
> >
> > Found it - I remember that these lines are muxed with ETK signals
> > and with the hwdebug signals.
> >
> > So I looked at the debobs driver - and that's the culprit!
> > (Cc-ing the author of that driver)
> >
> > How should this be handled? IMO, this driver has should use the
> > MUX framework for changing the mux modes.
> >
> > What say?
> 
> Yes, the debobs driver needs to be updated to use the MUX API.
> 
> But even with that, AFAICT, the new mux API will still allow
> the last caller to "win" as there is no request/free API
> to get pins.
> 

At least the debug prints would have pointed me to this driver.

Okay, I'll try and cook something up for updating the debobs driver.

- Anand

Re: Padconf not working on pm_defconfig?

[Tony Lindgren]

* Gadiyar, Anand <gadiyar@ti.com> [091214 09:07]:
> Kevin Hilman wroteL
> > >
> > > Found it - I remember that these lines are muxed with ETK signals
> > > and with the hwdebug signals.
> > >
> > > So I looked at the debobs driver - and that's the culprit!
> > > (Cc-ing the author of that driver)
> > >
> > > How should this be handled? IMO, this driver has should use the
> > > MUX framework for changing the mux modes.
> > >
> > > What say?
> > 
> > Yes, the debobs driver needs to be updated to use the MUX API.
> > 
> > But even with that, AFAICT, the new mux API will still allow
> > the last caller to "win" as there is no request/free API
> > to get pins.
> > 
> 
> At least the debug prints would have pointed me to this driver.
> 
> Okay, I'll try and cook something up for updating the debobs driver.

Sounds like debobs should only set the pins based on platform_data
passed from the board-*.c file. Then maybe allow override from
cmdline on boards that have both debobs and ehci?

Regards,

Tony

RE: Padconf not working on pm_defconfig?

[Gadiyar, Anand]

Tony Lindgren wrote:
> 
> Sounds like debobs should only set the pins based on platform_data
> passed from the board-*.c file. Then maybe allow override from
> cmdline on boards that have both debobs and ehci?
> 

Not sure about this - I haven't studied the driver yet
(it's been on my TODO for a while. Interesting area :) )

The debobs driver allows these mux-modes to be set from sysfs,
I think. If so, all we need to do is save the old mode
and restore it back from sysfs.

Also, by default not change any of the mux modes.

Another thing I'd like to add is the option to use the alternate
set of hwdebug pads.

- Anand