Reg pinmux driver for OMAP based SoC- AM335X

Reg pinmux driver for OMAP based SoC- AM335X

[Mohammed, Afzal]

Hi Tony,

I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family).

Is there any specific plan you have in mind w.r.t incorporating
pincontrol driver for OMAP family of SoC's. There was an initial patch
for OMAP4 pin control driver, but it seems you were in favour of a
DT based approach. As per my understanding after going through few threads
(lot more remaining) is that pincontrol driver can be either a DT based
or non-DT based (either way we are going out of platform folders), and
it seems you prefer a DT based approach (have seen mentioning about
pinmux-simple.c).

Tegra pincontrol driver posted recently, seems to use DT to distinguish only
the SoC type, with all the pincontrol information for SoC present in Kernel.

I would be thankful if you can give me some pointers on how to proceed for
AM335X pincontrol driver and/or any work in progress for OMAP pincontrol driver.

Regards
Afzal

Re: Reg pinmux driver for OMAP based SoC- AM335X

[Tony Lindgren]

Hi,

* Mohammed, Afzal <afzal@ti.com> [120131 06:04]:
> Hi Tony,
> 
> I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family).
> 
> Is there any specific plan you have in mind w.r.t incorporating
> pincontrol driver for OMAP family of SoC's. There was an initial patch
> for OMAP4 pin control driver, but it seems you were in favour of a
> DT based approach. As per my understanding after going through few threads
> (lot more remaining) is that pincontrol driver can be either a DT based
> or non-DT based (either way we are going out of platform folders), and
> it seems you prefer a DT based approach (have seen mentioning about
> pinmux-simple.c).

With at least omaps, there are few good reasons to go for a common
DT only driver:

1. We already have about 6k lines of mux data and seem to be
   adding several thousands of lines of mux data each year.

2. The driver does not need this data, it just needs to know how
   to operate certain kind of mux registers. The data is mostly
   handy for developers for debugging, and that can be done via
   debugfs and userspace tools.
 
> Tegra pincontrol driver posted recently, seems to use DT to distinguish only
> the SoC type, with all the pincontrol information for SoC present in Kernel.
> 
> I would be thankful if you can give me some pointers on how to proceed for
> AM335X pincontrol driver and/or any work in progress for OMAP pincontrol driver.

The plan is to deprecate the existing arch/arm/*omap*/*mux* code,
and cut it down to minimum. And then add DT only mux support that should
work for at least omap2+. That should work for am335x too.

There's currently some discussion going on regarding the pinmux device
tree binding and how dynamic mux states should be handled. But I'd
assume we'll have basic support available very soon.

The driver I'm working leaves all the data out of kernel, and the driver
just knows how to handle a pinmux register instances. Then debugging
tools can be done in userspace via debugfs to display more detailed
SoC specific information.

So it might be worth waiting just a little bit longer. If you have
resources to spend on the pinmuxing, then creating some userspace tool
to display SoC specific information would be nice :) For the userspace
tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch].

Regards,

Tony

RE: Reg pinmux driver for OMAP based SoC- AM335X

[Hiremath, Vaibhav]

On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> Hi,
> 
> * Mohammed, Afzal <afzal@ti.com> [120131 06:04]:
> > Hi Tony,
> > 
> > I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family).
> > 
> > Is there any specific plan you have in mind w.r.t incorporating
> > pincontrol driver for OMAP family of SoC's. There was an initial patch
> > for OMAP4 pin control driver, but it seems you were in favour of a
> > DT based approach. As per my understanding after going through few threads
> > (lot more remaining) is that pincontrol driver can be either a DT based
> > or non-DT based (either way we are going out of platform folders), and
> > it seems you prefer a DT based approach (have seen mentioning about
> > pinmux-simple.c).
> 
> With at least omaps, there are few good reasons to go for a common
> DT only driver:
> 
> 1. We already have about 6k lines of mux data and seem to be
>    adding several thousands of lines of mux data each year.
> 
> 2. The driver does not need this data, it just needs to know how
>    to operate certain kind of mux registers. The data is mostly
>    handy for developers for debugging, and that can be done via
>    debugfs and userspace tools.
>  
> > Tegra pincontrol driver posted recently, seems to use DT to distinguish only
> > the SoC type, with all the pincontrol information for SoC present in Kernel.
> > 
> > I would be thankful if you can give me some pointers on how to proceed for
> > AM335X pincontrol driver and/or any work in progress for OMAP pincontrol driver.
> 
> The plan is to deprecate the existing arch/arm/*omap*/*mux* code,
> and cut it down to minimum. And then add DT only mux support that should
> work for at least omap2+. That should work for am335x too.
> 
> There's currently some discussion going on regarding the pinmux device
> tree binding and how dynamic mux states should be handled. But I'd
> assume we'll have basic support available very soon.
> 
> The driver I'm working leaves all the data out of kernel, and the driver
> just knows how to handle a pinmux register instances. 

Tony,

Is this hosted or accessible somewhere? Just for reference...

Thanks,
Vaibhav

> Then debugging
> tools can be done in userspace via debugfs to display more detailed
> SoC specific information.
> 
> So it might be worth waiting just a little bit longer. If you have
> resources to spend on the pinmuxing, then creating some userspace tool
> to display SoC specific information would be nice :) For the userspace
> tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch].
> 
> Regards,
> 
> Tony
> 

Re: Reg pinmux driver for OMAP based SoC- AM335X

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [120201 01:34]:
> On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> > 
> > The driver I'm working leaves all the data out of kernel, and the driver
> > just knows how to handle a pinmux register instances. 
> 
> Tony,
> 
> Is this hosted or accessible somewhere? Just for reference...

Still few more things to fix before I can post it..

Tony

Re: Reg pinmux driver for OMAP based SoC- AM335X

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120201 09:43]:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120201 01:34]:
> > On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> > > 
> > > The driver I'm working leaves all the data out of kernel, and the driver
> > > just knows how to handle a pinmux register instances. 
> > 
> > Tony,
> > 
> > Is this hosted or accessible somewhere? Just for reference...
> 
> Still few more things to fix before I can post it..

OK now posted as thread "[PATCH 0/2] Initial DT only generic
pinctrl-simple driver". Did not Cc any omap people as I assume
they're all reading linux-omap.

Regards,

Tony

RE: Reg pinmux driver for OMAP based SoC- AM335X

[Mohammed, Afzal]

Hi Tony,

On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> The plan is to deprecate the existing arch/arm/*omap*/*mux* code,
> and cut it down to minimum. And then add DT only mux support that should
> work for at least omap2+. That should work for am335x too.
> 
> There's currently some discussion going on regarding the pinmux device
> tree binding and how dynamic mux states should be handled. But I'd
> assume we'll have basic support available very soon.
> 
> The driver I'm working leaves all the data out of kernel, and the driver
> just knows how to handle a pinmux register instances. Then debugging
> tools can be done in userspace via debugfs to display more detailed
> SoC specific information.
> 
> So it might be worth waiting just a little bit longer. If you have
> resources to spend on the pinmuxing, then creating some userspace tool
> to display SoC specific information would be nice :) For the userspace
> tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch].

Thank you for the detailed reply.

I will wait for it and willing to help you in its testing.

I have been tasked on getting AM335X supported well in mainline,
and will move to other aspects of it while waiting.

Regards
Afzal