Hello.
Mark A. Greer wrote:
Pinmux is a distinct problem, and doing it right needs
information that's just not available to clock code.
All it needs to know is what device is being enabled which is
exactly the same thing the clock code needs to know and exactly
the same thing the psc code needs to know. From the device,
we can determine the pins, clock src, and psc module that need to
be set up.
The three are separate but related in that they all have to be
done corretly for the device to work. If any one of the three isn't
set up correctly before the driver accesses that device, there's
a problem. And, there's no point in setting one of them up if you
aren't going to set all of them up (well, a clock src could be used
for more than one device but we still call clk_enable() on a per device
basis, not on a per clock basis).
So, all three are coupled by the nature of the hardware whether
or not the code is coupled.
Right now, we have the clock and psc coupled but the pinmux decoupled.
I don't understand why. The only thing I can guess is that you're
looking at pinmux as individual pins instead of a set of pins that
need to be setup correctly for a device to work. If not, then why
is it okay to couple psc & clock but not okay to couple the pinmux
as well?
It makes sense to have all three set up at the same time and
clk_enable() is the obvious place since a) drivers already call
it and b) its called exactly when it makes sense to do the pinmux
set up.
Without coupling pinmux with the other two, then we have to add
explicit calls to set up the pinmux in either:
a) The board code where you risk creating pinmux conflicts with
devices that will never be enabled or else you have to add
conditional logic based on Kconfig options.
Tangled and ugly conditional logic.
b) The drivers. This means we'll just add a call to set up the
pinmux immediately after every clk_enable() call. I hope
this isn't the plan.
Well, at least that would have been better than (a). I could agree to (b)
but it sounds like everyone's plan here was actually (a). :-/
its really
nice to have it done automatically (and not having a hundred
davinci_cfg_reg() calls in every board file).
The cleanest way is IMO to have it set up when the device
is registered. The device registration code can know e.g.
that when the platform data says MMC has eight pins, it
had better mux all eight pins. (If there are mux options,
like DAT4 coming out on one of several pins, it can be told
which option that board uses.)
The same could be said for enabling the clock and psc too.
The problem is we don't know what the user actually wants enabled--
that is, what drivers are config'd in--at device registration time
(without #ifdef CONFIG_<driver> everywhere). So, IMHO, the right
way to go is to register all of the devices that a board supports
but the user picks which ones are actually used via CONFIG options.
When a driver runs, it calls clk_enable() (or some other single hook)
to set up the clock, psc, and pinmux.
[BTW, I don't care if the hook is called clk_enable() or psc_enable()
or pinmux_enable() or throw_a_dead_chicken_enable() as long as its only
one hook to enable all three. I use clk_enable() since drivers already
call it.]
An example with the da830 evm is nand & nor flash. The board has
both but only one can be used at a time.
Mark, you're ovesimlifying the matter here too much: NAND and NOR flashes
are on the User Interface daughterboard, along with LCD -- that naturally can
or cannot be plugged in. Depending on the revision of the board, you either
can't have on-board MMC working if the daughter board is plugged in, or only
if you're using one of the flashes on it (there's a GPIO expander on that
dougterboard controlling the multiplexing of several pins to LCD or flashes
and additionally controlling multiplexing of the MMC pins on the later board
revisions, so that you can have MMC with the daughter board plugged in -- at
least when you don't need flashes. (Unfortunately, you need to setup that GPIO
expander from kernel for the LCD/MMC to be used because by defalt it selects
flashes.)
David, Kevin, if you're already feeling confused by the gory details of
this, that was part of my task of giving you a feel how hairy the pinmux
issues can become with only one daugtherboard. :-)
I prefer the device be registered for both
No way. :-) They use the *same AEMIF pins*, so the pinmux conflicts
between them just can *not* be detected, and so I had to resort to a choice
selecting either kind of flash (or LCD).
and the user pick which one he/she wants via
CONFIG options. Otherwise, we need to add #ifdef CONFIG_<driver>'s
to the board code.
2) It detects and complains about pinmux contention and there
is a lot of potential contention with the da830.
No less so than with OMAP, or lots of other SoCs. Contention
is rarely a problem given a clearly structured framework for
board init ... like being able to rely on device registration
to perform the pinmux.
For the da830 evm, this means adding #ifdef CONFIG_<driver> to board
code.
Which would in no way prevent the pinmux conflicts as the user can always
select mutually exclusive drivers! So unless you add more ugly #ifdef'ery to
explicitly check for the incompatible driver configurations (mega igly -- and
yet this is what we had for DM644x EVM with NAND/NOR flashes and IDE), you're
still subject to pinmux conflicts.
So, assuming that patch eventually makes it in, we can't just register
every device because the drivers can pick unwanted devices, clk_enable
them and break some other device because it stole its pins.
If only the devices that exist on the board get registered, that
type of confusion won't happen.
Yes it will...you're just used to boards that don't populate devices
with conflicting pinmux requirements. :)
I'm not sure why actually, given the example of DM6446 EVM which has
IDE/NAND/NOR mutually exclusive. Perhahs, nobody has ever put enough attention
to these issues. And I know that OMAP at least has some daughter boards too --
perhaps the
Mark
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
