Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On Fri, Nov 14, 2014 at 1:58 AM, Tony Lindgren t...@atomide.com wrote: * Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) How will audio do dynamic muxing without that code? The pin must be remuxed back to internal clock when audio stops, or else PM breaks. GraÅžvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Grazvydas Ignotas nota...@gmail.com [141114 06:38]: On Fri, Nov 14, 2014 at 1:58 AM, Tony Lindgren t...@atomide.com wrote: * Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) How will audio do dynamic muxing without that code? The pin must be remuxed back to internal clock when audio stops, or else PM breaks. There's a standard way of dealing with that already available. We can just have runtime_pm functions call pinctrl_pm_select_sleep_state() and pinctrl_pm_select_default_state(). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Tero Kristo t-kri...@ti.com [141113 23:33]: On 11/14/2014 01:58 AM, Tony Lindgren wrote: The PRCM/clock cleanups that I have under work basically splits the clock inits under their respective IP blocks; currently everything is registered under generic PRCM. System control module will be one of the clock providers (and is going to look like a driver), which will be registering its own clocks. Yes that's nice. The clock modules in the SCM should probably use the syscon mapping unless there's a clear separate IO area for them. And then use pinctrl for registers that are muxes for external pins unless they are in some dedicated clock register area. This doesn't change the fact that pinctrl is directly mapping its own register space atm though, it might be possible to re-route this to use the generic system control module if need be though. Mapping dedicated IO areas to individual drivers is not a problem. These drivers can eventually be children of a core SCM driver if needed. I guess its just a political decision which way we want to go, currently we have lots of system control clocks under the clock data (for AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some cases it is nicer to have the data in the clock tree though, the drivers don't need to care if they are touching a clock or a pinctrl entity. Some people have been converting additional stuff to CCF outside of PRCM, like Archit did some work to try and get control module clock support for DRA7, and Tomi has been talking to convert some of the DSS internal clocks to CCF also. Setting up CCF drivers for SCM makes sense to me. I suggest the following guidelines: 1. If there's a clear separate dedicated IO area in SCM, it can be a driver implementing a Linux generic framework for CCF, regulators, pinctrl, or PHY. 2. For the random control registers, we should use syscon or pinctrl-single to implement Linux generic framwork functions for CCF, regulators, pinctrl or PHY. 3. For resource management, we can have a core SCM driver that takes care of the save and restore of registers and clocking if needed. I believe currently SCM clocks are always enabled though. We can set the drivers in #1 and #2 abobe to be childer of the core SCM driver if we ever need to manage clocks during runtime. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On 11/14/2014 01:58 AM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) The PRCM/clock cleanups that I have under work basically splits the clock inits under their respective IP blocks; currently everything is registered under generic PRCM. System control module will be one of the clock providers (and is going to look like a driver), which will be registering its own clocks. This doesn't change the fact that pinctrl is directly mapping its own register space atm though, it might be possible to re-route this to use the generic system control module if need be though. I guess its just a political decision which way we want to go, currently we have lots of system control clocks under the clock data (for AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some cases it is nicer to have the data in the clock tree though, the drivers don't need to care if they are touching a clock or a pinctrl entity. Some people have been converting additional stuff to CCF outside of PRCM, like Archit did some work to try and get control module clock support for DRA7, and Tomi has been talking to convert some of the DSS internal clocks to CCF also. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
Hi,
On 03/11/14 23:59, Marek Belisko wrote:
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and
acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+control_devconf1 {
+ pinctrl-name = default;
+ pinctrl-0 = tv_acbias_pins;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits =
+ 0 0x40800 0x40800
I think it would be good to have a comment in the .dts above, mentioning
that TVOUTBYPASS and TVACEN bits are being set.
+ ;
+ };
+};
OMAP3630 seems to have CONTROL_AVDAC1 and CONTROL_AVDAC2 registers. Did
you check if the SoC you use have those? It looks like they need
configuration also, if the exist.
So, I don't think tvbypass and acbias are really pinmux stuff, but it
does seem like an easy way to handle the devconf1 register, and I don't
see any issues with the setting being fixed.
However, devconf1 register seems to have bits for many devices,
including mcbsp, mmc, and even some Force MPU writes to be nonposted bit.
And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
places in the kernel. I wonder if adding a pinmux entry for it could
cause some rather odd problems.
Tony, any idea about this? How should CONTROL_DEVCONFx registers be
accessed?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Tomi Valkeinen tomi.valkei...@ti.com [141112 04:56]:
Hi,
On 03/11/14 23:59, Marek Belisko wrote:
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass
and acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+control_devconf1 {
+ pinctrl-name = default;
+ pinctrl-0 = tv_acbias_pins;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits =
+ 0 0x40800 0x40800
I think it would be good to have a comment in the .dts above, mentioning
that TVOUTBYPASS and TVACEN bits are being set.
+ ;
+ };
+};
OMAP3630 seems to have CONTROL_AVDAC1 and CONTROL_AVDAC2 registers. Did
you check if the SoC you use have those? It looks like they need
configuration also, if the exist.
Those look like AVDAC specific control registers that are not mux
registers. So those should be accessed the existing SCM (System Control
Mmodule) syscon area by the DSS code. For examples, see what
pbias-regulator.c is doing for some other registers in the syscon area.
So, I don't think tvbypass and acbias are really pinmux stuff, but it
does seem like an easy way to handle the devconf1 register, and I don't
see any issues with the setting being fixed.
The CONTROL_DEVCONF registers seem to be all related to muxing signals
and configuring ping signal levels. So I think the pinctrl-single is
OK to use with these.
However, devconf1 register seems to have bits for many devices,
including mcbsp, mmc, and even some Force MPU writes to be nonposted bit.
Yes theForce MPU writes to be nonposted debug bit is an odd one
there :) But we're not using that luckily anywhere..
And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
places in the kernel. I wonder if adding a pinmux entry for it could
cause some rather odd problems.
They can all use pinctrl-single no problem.
Tony, any idea about this? How should CONTROL_DEVCONFx registers be
accessed?
If they are pinctrl related like the CONTROL_DEVCONF registers, then
pincatrl-single is OK. However, for any registers in the SCM that are
not just routing signals, then the syscon mapping should be used. And
we should have a separate driver implementing some standard Linux
generic framework driver. For example a regulator or clock driver.
Anyways, I'll drop this $subject patch for now and set up a new branch
for the .dts changes.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
Hi Tony,
On Tue, Nov 11, 2014 at 12:36 AM, Tony Lindgren t...@atomide.com wrote:
* Marek Belisko ma...@goldelico.com [141103 14:01]:
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and
acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
The pinctrl-single entry should be in omap3.dtsi as the mux register is there
for all the omap3 devices, can you please update the patch for that?
Ok I'll do. Just one question. I checked TRM for omap3430 and omap3630 and
reserved bits in devconf1 are different. So keep function-mask for
omap3430 in omap3.dtsi
and redefine in omap36xx.dtsi (not sure if this will work in this
way)? Or exist other way how to deal with that? Thanks.
Regards,
Tony
omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+control_devconf1 {
+ pinctrl-name = default;
+ pinctrl-0 = tv_acbias_pins;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits =
+ 0 0x40800 0x40800
+ ;
+ };
+};
--
1.9.1
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Belisko Marek marek.beli...@gmail.com [141112 13:04]:
Hi Tony,
On Tue, Nov 11, 2014 at 12:36 AM, Tony Lindgren t...@atomide.com wrote:
* Marek Belisko ma...@goldelico.com [141103 14:01]:
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass
and acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
The pinctrl-single entry should be in omap3.dtsi as the mux register is
there
for all the omap3 devices, can you please update the patch for that?
Ok I'll do. Just one question. I checked TRM for omap3430 and omap3630 and
reserved bits in devconf1 are different. So keep function-mask for
omap3430 in omap3.dtsi
and redefine in omap36xx.dtsi (not sure if this will work in this
way)? Or exist other way how to deal with that? Thanks.
Oh OK. Yes if they are different you should have the common entry in
omap3.dtsi and the SoC specific fields in omap34xx.dtsi and
omap36xx.dtsi. And please leave out the bit for configuring the
MPUFORCEWRNP.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Marek Belisko ma...@goldelico.com [141103 14:01]:
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and
acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
The pinctrl-single entry should be in omap3.dtsi as the mux register is there
for all the omap3 devices, can you please update the patch for that?
Regards,
Tony
omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+control_devconf1 {
+ pinctrl-name = default;
+ pinctrl-0 = tv_acbias_pins;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits =
+ 0 0x40800 0x40800
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and
acbias).
Add single pinmux entry and enable it.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index e4d05f0..a456d37 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -118,6 +118,17 @@
};
};
};
+
+ /* pinmux for devconf1 */
+ control_devconf1: pinmux@480022d8 {
+ compatible = pinctrl-single;
+ reg = 0x480022d8 4; /* single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0xfc0bd5;
+ };
};
omap3_pmx_core {
@@ -497,3 +508,14 @@
};
};
};
+
+control_devconf1 {
+ pinctrl-name = default;
+ pinctrl-0 = tv_acbias_pins;
+
+ tv_acbias_pins: pinmux_tv_acbias_pins {
+ pinctrl-single,bits =
+ 0 0x40800 0x40800
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
