On 22/03/15 16:24, Mark Brown wrote:
On Fri, Mar 20, 2015 at 09:22:43PM +0000, Howard Mitchell wrote:
+ if (pcm512x->pll_lock) {
+ if (of_property_read_u32(np, "pll-lock", &val) >= 0) {
+ if (val > 6) {
+ dev_err(dev, "Invalid pll-lock\n");
+ ret = -EINVAL;
+ goto err_clk;
+ }
+ pcm512x->pll_lock = val;
+ }
This breaks existing boards which rely on GPIO 4 being set as the lock
output. This is very unfortunate since it's a silly thing for the
driver to default to but nontheless we should really continue to support
them - at a guess Peter's board is relying on this, and even if it isn't
someone else's might.
I take your point, but the reason I pushed this patch was that I wanted
to use GPIO4 for pll-out and unfortunately because the pll-lock
configuration is after the pll-out configuration it stomps on it. If I
modify the patch to provide a default for pll-lock I will then be
obliged to specify pll-lock on another GPIO. The pcm5122 has limited IO
so being forced to have a GPIO for pll-lock seems wrong to me. A future
user of the device may well decide to use the GPIOs for other purposes
and therefore not want a pll-lock signal at all. Surely we should allow
for that possibility?
Given that Peter has indicated that he'd be happy with this solution and
that this code hasn't reached a published kernel would it be reasonable
to go ahead with my current patch (happy to clean up the indent issues
that Peter pointed out of course)?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html