Thomas,
On Tue, Mar 5, 2013 at 3:49 PM, Thomas Abraham
<thomas.abraham@xxxxxxxxxx> wrote:
> Yes, I am currently held up with supporting default pin states at slot
> level. One option that could be considered is to list out the default
> pin states for all slots in the parent node of the slots. So it would
> be something like below as an example.
>
> dwmmc2@12220000 {
> <....>
>
> pinctrl-names = "slot0-default", "slot1-default";
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
> pinctrl-1 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4 &sd2_bus8>;
>
> slot@0 {
> reg = <0>;
> bus-width = <4>;
> disable-wp;
> };
>
> slot@1 {
> reg = <0>;
> bus-width = <8>;
> disable-wp;
> };
> };
>
> Then, during the initial slot setup stage, the driver, knowing the
> current slot number that is being setup, can setup the pin state for
> the particular slot using the devm_pinctrl_get_select API. pinctrl
> subsystem would not setup the default pin state in this case.
>
> Does this look like a hack?
That feels like a hack to me. The right place for the slot data is
under the slot node, not in the parent. ...but I would certainly
defer to any experts that might have a different opinion.
> For now, I have prepared patches without
> this approach, since Exynos5250 has just one slot, I have just listed
> only one default pin state, which the pinctrl framework helps to setup
> during driver bind.
That actually doesn't seem awful to me. It's basically saying that we
are describing pinmux at a device level and not a slot level. It
would make it a pain to dynamically adjust pinmux on a slot-by-slot
basis, but is that a terrible thing?
In the two-slot case you could just do:
pinctrl-0 = <&sd1_clk &sd1_cmd &sd1_cd &sd2_bus4 &sd2_clk &sd2_cmd
&sd1_cd &sd1_bus4>;
pinctrl-names = "default";
In other words the default state just sets up pin muxing for all the
whole controller (AKA all slots).
...but maybe someone will yell at me for that suggestion. It's really
hard to justify all this extra work for the multiple slot case when
there are no current users that I know of...
-Doug
--
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
