On 02/22/2014 11:26 PM, Tomasz Figa wrote:
[Ccing Mike]
On 22.02.2014 23:02, Sylwester Nawrocki wrote:
On 02/21/2014 04:50 PM, Mark Rutland wrote:
On Thu, Feb 20, 2014 at 07:40:30PM +0000, Sylwester Nawrocki wrote:
+- #clock-cells: from the common clock bindings
(../clock/clock-bindings.txt),
+ must be 1. A clock provider is associated with the 'camera' node
and it should
+ be referenced by external sensors that use clocks provided by the
SoC on
+ CAM_*_CLKOUT pins. The clock specifier cell stores an index of a
clock.
+ The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks
respectively.
+
+- clock-output-names: from the common clock bindings, should contain
names of
+ clocks registered by the camera subsystem corresponding to
CAM_A_CLKOUT,
+ CAM_B_CLKOUT output clocks, in this order. Parent clock of these
clocks are
+ specified be first two entries of the clock-names property.
Do you need this?
All right, that might have been a bad idea, it mixes names of clocks
registered
by the main clock controller with names of clock input lines at the
device.
It's a mistake I have been usually sensitive to and now made it
myself. :/
My intention was to maintain the clock tree, since the camera block
doesn't
generate the clock itself, it merely passes through the clocks from the
SoC main
clock controller (CMU). So clk parents need to be properly set and since
there is no clock-output-names property at the CMU DT node,
of_clk_get_parent_name() cannot be used.
So presumably the DT binding would be only specifying that the sclk_cam0,
sclk_cam1 clock input entries are associated with output clocks named as
in clock-output-names property.
And the driver could either:
1) hard code those (well defined) CMU clock (clk parent) names,
I don't think this would be a good idea, as those CMU clock names may
vary between SoCs.
For the record, I'm not in favour of this approach, even though these clock
names happen to be same for all relevant SoCs.
2) clk_get() its input clock, retrieve name with __clk_get_name() and
pass
it as parent name to clk_register() - it sounds a bit hacky though.
This looks fine, at least until proper interface is added to CCF. Exynos
audio subsystem clock driver does exactly the same.
Hmm, I looked at this driver and somehow missed that.
However, the right thing would be to make it possible to use pointers to
struct clk instead of strings to list parent(s). This could be done by
adding .parents field (struct clk **) to clk_init_data struct and make
clk_register() use it if available.
We would just need to ensure the locking is done properly.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
