* OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl
@ 2012-07-27 9:43 Peter Ujfalusi
2012-08-07 11:10 ` Tony Lindgren
0 siblings, 1 reply; 4+ messages in thread
From: Peter Ujfalusi @ 2012-07-27 9:43 UTC (permalink / raw)
To: linux-omap, Tony Lindgren, Cousson, Benoit,
devicetree-discuss@lists.ozlabs.org, Grant Likely
Hello,
I need to find a solution to control 2 bits in CONTROL_DEVCONF0 on OMAP2/3 for
McBSP1 CLKR/FSR signal routing.
In boards using McBSP1 we might need to change bit 3 and 4 based on the audio
setup (how the board has been wired).
So far I have come up with the following idea to handle to but not really sure
if it is the correct way (I have taken the idea from the arm/dts: Add AM33XX
basic pinctrl support series).
In .dtsi file of the SoC:
control_devconf0: pinmux@48002274 {
compatible = "pinctrl-single";
reg = <0x48002274 4>; /* Single register */
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x5F>;
};
In the .dts file of the board which needs to change the CLKR/FSR configuration:
&control_devconf0 {
pinctrl-names = "default";
pinctrl-0 = <&mcbsp1_pins>;
mcbsp1_pins: pinmux_mcbsp1_pins {
pinctrl-single,pins = <0x00 0x18>; /* CLKR/FSR from CLKX/FSX
* pin */
};
};
Thanks for the help,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl
2012-07-27 9:43 OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl Peter Ujfalusi
@ 2012-08-07 11:10 ` Tony Lindgren
2012-08-08 11:53 ` Peter Ujfalusi
0 siblings, 1 reply; 4+ messages in thread
From: Tony Lindgren @ 2012-08-07 11:10 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap, Cousson, Benoit, devicetree-discuss@lists.ozlabs.org,
Grant Likely
* Peter Ujfalusi <peter.ujfalusi@ti.com> [120727 02:47]:
> Hello,
>
> I need to find a solution to control 2 bits in CONTROL_DEVCONF0 on OMAP2/3 for
> McBSP1 CLKR/FSR signal routing.
> In boards using McBSP1 we might need to change bit 3 and 4 based on the audio
> setup (how the board has been wired).
>
> So far I have come up with the following idea to handle to but not really sure
> if it is the correct way (I have taken the idea from the arm/dts: Add AM33XX
> basic pinctrl support series).
You need to also consider that CONTROL_DEVCONF0 has the MMC/SDIO module input
clock selection. So pinctrl-single binding would have to be expanded to also
support one-bit-per-mux type registers in addition to one-register-per-mux
registers. And then this could also be used for the MMC/SDIO module input clock.
> In .dtsi file of the SoC:
>
> control_devconf0: pinmux@48002274 {
> compatible = "pinctrl-single";
> reg = <0x48002274 4>; /* Single register */
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-single,register-width = <32>;
> pinctrl-single,function-mask = <0x5F>;
> };
The pinctrl-single,function-mask is for all the registers in the range,
we also need something to specify the device specific mux bits.
> In the .dts file of the board which needs to change the CLKR/FSR configuration:
>
> &control_devconf0 {
> pinctrl-names = "default";
> pinctrl-0 = <&mcbsp1_pins>;
>
> mcbsp1_pins: pinmux_mcbsp1_pins {
> pinctrl-single,pins = <0x00 0x18>; /* CLKR/FSR from CLKX/FSX
> * pin */
> };
>
> };
I think adding support for one-bit-per-mux would require adding something
like this for the binding:
mcbsp1_pins: pinmux_mcbsp1_pins {
/* offset bits mask */
pinctrl-single,bits = <0x00 0x18 0x18>;
};
As otherwise you would not know which bits to clear for alternative
named modes. Or got any better ideas?
Regards,
Tony
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl
2012-08-07 11:10 ` Tony Lindgren
@ 2012-08-08 11:53 ` Peter Ujfalusi
2012-08-09 6:36 ` Tony Lindgren
0 siblings, 1 reply; 4+ messages in thread
From: Peter Ujfalusi @ 2012-08-08 11:53 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Cousson, Benoit, devicetree-discuss@lists.ozlabs.org,
Grant Likely
On 08/07/2012 02:10 PM, Tony Lindgren wrote:
> You need to also consider that CONTROL_DEVCONF0 has the MMC/SDIO module input
> clock selection. So pinctrl-single binding would have to be expanded to also
> support one-bit-per-mux type registers in addition to one-register-per-mux
> registers. And then this could also be used for the MMC/SDIO module input clock.
Or if the clock selection for MMC/SDIO also static on a board we can just do
the mux config once, configuring McBSP1 and MMC/SDIO at the same time?
>> In .dtsi file of the SoC:
>>
>> control_devconf0: pinmux@48002274 {
>> compatible = "pinctrl-single";
>> reg = <0x48002274 4>; /* Single register */
>> #address-cells = <1>;
>> #size-cells = <0>;
>> pinctrl-single,register-width = <32>;
>> pinctrl-single,function-mask = <0x5F>;
>> };
>
> The pinctrl-single,function-mask is for all the registers in the range,
> we also need something to specify the device specific mux bits.
Yes, I understand that.
I think this all depends if we want to change the mux configurations runtime,
on the fly as well. If it is only done once at boot time why not just set up
the register (mux) as the board design dictates?
>> In the .dts file of the board which needs to change the CLKR/FSR configuration:
>>
>> &control_devconf0 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mcbsp1_pins>;
>>
>> mcbsp1_pins: pinmux_mcbsp1_pins {
>> pinctrl-single,pins = <0x00 0x18>; /* CLKR/FSR from CLKX/FSX
>> * pin */
>> };
>>
>> };
>
> I think adding support for one-bit-per-mux would require adding something
> like this for the binding:
>
> mcbsp1_pins: pinmux_mcbsp1_pins {
> /* offset bits mask */
> pinctrl-single,bits = <0x00 0x18 0x18>;
> };
>
> As otherwise you would not know which bits to clear for alternative
> named modes. Or got any better ideas?
I was also thought that this type of feature might be useful at some point in
pinctrl.
However if we have static mux configuration on a boards vendors can set up the
mux for their devices using the currently available bindings.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl
2012-08-08 11:53 ` Peter Ujfalusi
@ 2012-08-09 6:36 ` Tony Lindgren
0 siblings, 0 replies; 4+ messages in thread
From: Tony Lindgren @ 2012-08-09 6:36 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap, Cousson, Benoit, devicetree-discuss@lists.ozlabs.org,
Grant Likely
* Peter Ujfalusi <peter.ujfalusi@ti.com> [120808 04:53]:
> On 08/07/2012 02:10 PM, Tony Lindgren wrote:
> > You need to also consider that CONTROL_DEVCONF0 has the MMC/SDIO module input
> > clock selection. So pinctrl-single binding would have to be expanded to also
> > support one-bit-per-mux type registers in addition to one-register-per-mux
> > registers. And then this could also be used for the MMC/SDIO module input clock.
>
> Or if the clock selection for MMC/SDIO also static on a board we can just do
> the mux config once, configuring McBSP1 and MMC/SDIO at the same time?
Although the DEVCONF0 and 1 seem static, at least with pinctrl framework we
can keep it dynamic if needed and we're not relying on buggy bootloaders to
set it up.
Regards,
Tony
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-08-09 6:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-27 9:43 OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl Peter Ujfalusi
2012-08-07 11:10 ` Tony Lindgren
2012-08-08 11:53 ` Peter Ujfalusi
2012-08-09 6:36 ` Tony Lindgren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).