Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Hi
On Thu, 16 Jul 2015, R, Vignesh wrote:
> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
> >
> > On Wed, 3 Jun 2015, Vignesh R wrote:
> >
> >> Add hwmod entries for the PWMSS on DRA7.
> >>
> >> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
> >> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
> >> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
> >> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
> >> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
> >
> > Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]? Or is
> > HSPCLKDIV a separate divider after the divide-by-2 you mention above?
>
> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> as clock input for PWMSS. But actually L4PER2_L4_GICLK(=L3_GICLK/2) is
> the clock input for PWMSS. This will be updated in TRM soon.
OK
> >> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
> >>},
> >> };
> >>
> >> +/* pwmss */
> >> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
> >> + .rev_offs = 0x0,
> >> + .sysc_offs = 0x4,
> >> + .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
> >
> > This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG". There's no
> > RESETSTATUS bit. There is a SOFTRESET bit.
> >
> > Could you please confirm whether this is intentional?
>
> sorry my bad... I will change this in v3.
OK
> >> +/* ecap0 */
> >> +struct omap_hwmod dra7xx_ecap0_hwmod = {
> >> + .name = "ecap0",
> >> + .class = _ecap_hwmod_class,
> >> + .clkdm_name = "l4per2_clkdm",
> >> + .main_clk = "l4_root_clk_div",
> >
> > Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating",
> > there appears to be a local "mini-PRCM" for the PWMSS which implements
> > clock gating and reports back on the status of what I'd guess is the local
> > clock gating FSM.
> >
> > So from that point of view, you should probably create a clock driver that
> > manages both the clock gate request bit and the FSM status bit. It should
> > be something that can be reused for the other PWMSS IP blocks. Then
> > you'd create per-IP block clock nodes and set the main_clk to point to
> > that node.
>
> Since, this register is within the config space of PWMSS, the individual
> gating and reporting for the modules within PWMSS
> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> the sole function this driver is doing). It has been the same since
> am335x. Adding new clock nodes will result in driver changes and also
> changes to am335x, am437x (and other platforms) hwmod files. It also
> involves adding new nodes to clocks.dtsi and it will be difficult to
> maintain backward compatibility for older platforms. Is it not better to
> keep this as is, in order to maintain consistency (with am335x, am437x
> etc) and also that these clock bits are within IP's config space?
It's certainly possible that we as maintainers didn't look closely enough
at the AM33xx data for the PWMSS when we merged it. But if that's
incorrect too, then now is the time to fix this. Otherwise it will never
get fixed, since each new group of people patching this code will keep
punting it off to the indeterminate future.
In terms of hwmod data: based on the register maps in sections 29.4.3,
29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.
They don't support the Highlander OCP registers, they have no individual
PRCM registers or register bitfields, and all of the idle and status
reporting is to the PWMSS top-level IP block itself. So it looks to me
like the eCAP, eQEP, and ePWM modules should be registered via DT, rather
than via hwmod. It looks like you can get away with using the
"simple-bus" abstraction, but you might ultimately have to define
something custom here. However, the PWMSS top level subsystem, described
in section 29.1, does have the OCP registers, sideband signals, etc., and
thus should remain a hwmod-registered device (via DT).
In terms of the clock data: based on section 29.1.4, section 29.1.5.2,
figure 29-3, and table 29-4, there are several clock gating control bits.
These should be modeled as clock nodes in the Linux common clock
framework. Furthermore these registers are located inside the PWMSS
subsystem itself, and a
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
Hi guys On Wed, 12 Aug 2015, Alexandre Belloni wrote: On 13/08/2015 at 00:38:50 +0530, Keerthy wrote : The intent here is to switch to a higher precision clock which is the internal clock when available. Alexandre, Is dynamic switching preferred over sticking to external clock always if present? I'd say that I don't really care. I'd say the best would be to make a decision based on clock-accuracy but maybe that is an information you don't have yet. Anyway, this could be added at a later date. Either the clock mux logic is glitchless, in which case the RTC is likely to lose at least 31 microseconds per switch; or it's not glitchless, in which case it's unsafe to switch the RTC clock source while the clock isn't gated. Keerthy, before submitting this patch for merging, I'd suggest consulting your hardware folks to figure out which case it is. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
On Mon, 10 Aug 2015, Keerthy wrote: Switch to external clock source during suspend and switch back to internal source on resume. This helps rtc ticking across suspend. Doesn't this type of dynamic switching make it likely that ticks will be lost? If the external, optional source is present, isn't it best just to use the external source 100% of the time? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod
On Mon, 10 Aug 2015, Keerthy wrote: The patch adds rtc hwmod. This is present on gp and sk evm and not on epos evm. Hence adding it selectively using a seprate list. Signed-off-by: Keerthy j-keer...@ti.com So just to confirm, the RTC IP block has been physically removed or permanently disabled on these new AM438x chips? So the registers are no longer accessible by the MPU? Is there a TRM available for these chips? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 3 Jun 2015, Vignesh R wrote:
Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
program clock domain to SW_WKUP.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 57d5df0c1fbd..7581e036bda6 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
.dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT,
.wkdep_srcs = l4per2_wkup_sleep_deps,
.sleepdep_srcs= l4per2_wkup_sleep_deps,
- .flags= CLKDM_CAN_HWSUP_SWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain mpu0_7xx_clkdm = {
Thanks, queued for v4.2-rc fixes. Note that I cannot test this, since I
don't have a DRA7xx board.
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 15 Jul 2015, Paul Walmsley wrote:
On Wed, 3 Jun 2015, Vignesh R wrote:
Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
program clock domain to SW_WKUP.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 57d5df0c1fbd..7581e036bda6 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
.dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT,
.wkdep_srcs = l4per2_wkup_sleep_deps,
.sleepdep_srcs= l4per2_wkup_sleep_deps,
- .flags= CLKDM_CAN_HWSUP_SWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain mpu0_7xx_clkdm = {
Thanks, queued for v4.2-rc fixes. Note that I cannot test this, since I
don't have a DRA7xx board.
You know, upon further thought, this doesn't make sense. If the bug
is with the PWMSS IP block specifically, why not just set
HWMOD_SWSUP_SIDLE on all the IP blocks where the hardware folks didn't
implement hardware smart-idle? At least that way, if those legacy IP
blocks aren't in use, the clockdomain can still enter hardware-supervised
idle?
This patch basically disables hardware-supervised/smart idle for all of
the IP blocks in that clockdomain?
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Hi,
some comments.
On Wed, 3 Jun 2015, Vignesh R wrote:
Add hwmod entries for the PWMSS on DRA7.
Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]? Or is
HSPCLKDIV a separate divider after the divide-by-2 you mention above?
[1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf
Signed-off-by: Vignesh R vigne...@ti.com
---
v2:
* add TRM references.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239
++
1 file changed, 239 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0e64c2fac0b5..86a7ac9a3138 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
},
};
+/* pwmss */
+static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x4,
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
This doesn't match SPRUHZ6 Table 29-13 PWMSS_SYSCONFIG. There's no
RESETSTATUS bit. There is a SOFTRESET bit.
Could you please confirm whether this is intentional?
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
+ .name = epwmss,
+ .sysc = dra7xx_epwmss_sysc,
+};
+
+static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
+ .name = ecap,
+};
+
+static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
+ .name = eqep,
+};
+
+struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
+ .name = ehrpwm,
+};
+
+/* epwmss0 */
+struct omap_hwmod dra7xx_epwmss0_hwmod = {
+ .name = epwmss0,
+ .class = dra7xx_epwmss_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs =
DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
+ },
+ },
Per my comment on the previous patch, sounds like it might be better to
mark this as HWMOD_SWSUP_SIDLE? Then again, see the next comment below
re: main_clk.
+};
+
+/* ecap0 */
+struct omap_hwmod dra7xx_ecap0_hwmod = {
+ .name = ecap0,
+ .class = dra7xx_ecap_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
Looking at SPRUHZ6 Section 29.1.4.2 PWMSS Modules Local Clock Gating,
there appears to be a local mini-PRCM for the PWMSS which implements
clock gating and reports back on the status of what I'd guess is the local
clock gating FSM.
So from that point of view, you should probably create a clock driver that
manages both the clock gate request bit and the FSM status bit. It should
be something that can be reused for the other PWMSS IP blocks. Then
you'd create per-IP block clock nodes and set the main_clk to point to
that node.
+};
+
+/* eqep0 */
+struct omap_hwmod dra7xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = dra7xx_eqep_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
Same main_clk comments as for ecap0.
+};
+
+/* ehrpwm0 */
+struct omap_hwmod dra7xx_ehrpwm0_hwmod = {
+ .name = ehrpwm0,
+ .class = dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
Same main_clk comments as for ecap0.
+};
+
+/* epwmss1 */
+struct omap_hwmod dra7xx_epwmss1_hwmod = {
+ .name = epwmss1,
+ .class = dra7xx_epwmss_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs =
DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET,
+ },
+ },
Same flags comment as for epwmss0.
+};
+
+/* ecap1 */
+struct omap_hwmod dra7xx_ecap1_hwmod = {
+ .name = ecap1,
+ .class = dra7xx_ecap_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
Same main_clk comments as for ecap0.
+};
+
+/* eqep1 */
+struct omap_hwmod dra7xx_eqep1_hwmod
Re: [PATCH 02/10] ARM: OMAP3: Fix crypto support for HS devices
On Tue, 26 May 2015, Pali Rohár wrote:
Hi Paul,
this patch is also for omap2... Can you review it too?
On Saturday 28 February 2015 17:24:36 Pavel Machek wrote:
On Thu 2015-02-26 14:49:52, Pali Rohár wrote:
Register crypto hwmod links only if they are not disabled in DT.
If DT information is missing, enable them only for GP devices.
Before this patch crypto hwmod links were always disabled for all HS
devices
and it was not possible to use omap-aes and omap-sham linux drivers.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Acked-by: Pavel Machek pa...@ucw.cz
Sent to Tony for v4.2, after tweaking it a bit (below)
- Paul
Subject: [PATCH] ARM: OMAP3: Fix crypto support for HS devices
Register crypto hwmod links only if they are not disabled in DT.
If DT information is missing, enable them only for GP devices.
Before this patch crypto hwmod links were always disabled for all HS
devices and it was not possible to use omap-aes and omap-sham linux
drivers.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Acked-by: Pavel Machek pa...@ucw.cz
[p...@pwsan.com: move the complex IP-block presence heuristics into their
own function to simplify the code; fix some checkpatch warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 107 +
1 file changed, 94 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0ca4d3fb7df6..dc55f8dedf2c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3736,29 +3736,54 @@ static struct omap_hwmod_ocp_if
*omap3xxx_hwmod_ocp_ifs[] __initdata = {
/* GP-only hwmod links */
static struct omap_hwmod_ocp_if *omap34xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- omap3xxx_l4_core__sham,
- omap3xxx_l4_core__aes,
NULL
};
static struct omap_hwmod_ocp_if *omap36xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- omap3xxx_l4_core__sham,
- omap3xxx_l4_core__aes,
NULL
};
static struct omap_hwmod_ocp_if *am35xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- /*
-* Apparently the SHA/MD5 and AES accelerator IP blocks are
-* only present on some AM35xx chips, and no one knows which
-* ones. See
-* http://www.spinics.net/lists/arm-kernel/msg215466.html So
-* if you need these IP blocks on an AM35xx, try uncommenting
-* the following lines.
-*/
+ NULL
+};
+
+/* crypto hwmod links */
+static struct omap_hwmod_ocp_if *omap34xx_sham_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__sham,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_aes_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__aes,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap36xx_sham_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__sham,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap36xx_aes_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__aes,
+ NULL
+};
+
+/*
+ * Apparently the SHA/MD5 and AES accelerator IP blocks are
+ * only present on some AM35xx chips, and no one knows which
+ * ones. See
+ * http://www.spinics.net/lists/arm-kernel/msg215466.html So
+ * if you need these IP blocks on an AM35xx, try uncommenting
+ * the following lines.
+ */
+static struct omap_hwmod_ocp_if *am35xx_sham_hwmod_ocp_ifs[] __initdata = {
/* omap3xxx_l4_core__sham, */
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *am35xx_aes_hwmod_ocp_ifs[] __initdata = {
/* omap3xxx_l4_core__aes, */
NULL
};
@@ -3860,10 +3885,41 @@ static struct omap_hwmod_ocp_if
*omap3xxx_dss_hwmod_ocp_ifs[] __initdata = {
NULL
};
+/**
+ * omap3xxx_hwmod_is_hs_ip_block_usable - is a security IP block accessible?
+ * @bus: struct device_node * for the top-level OMAP DT data
+ * @dev_name: device name used in the DT file
+ *
+ * Determine whether a secure IP block @dev_name is usable by Linux.
+ * There doesn't appear to be a 100% reliable way to determine this,
+ * so we rely on heuristics. If @bus is null, meaning there's no DT
+ * data, then we only assume the IP block is accessible if the OMAP is
+ * fused as a 'general-purpose' SoC. If however DT data is present,
+ * test to see if the IP block is described in the DT data and set to
+ * 'status = okay'. If so then we assume the ODM has configured the
+ * OMAP firewalls to allow access to the IP block.
+ *
+ * Return: 0 if device named @dev_name is not likely to be accessible,
+ * or 1 if it is likely to be accessible.
+ */
+static int __init omap3xxx_hwmod_is_hs_ip_block_usable(struct device_node *bus,
+ const char *dev_name)
+{
+ if (!bus)
+ return (omap_type() == OMAP2_DEVICE_TYPE_GP) ? 1 : 0
Re: [PATCH 1/2] ARM: OMAP: AM43xx hwmod: Add data for am43xx emif hwmod
On Wed, 6 May 2015, Dave Gerlach wrote: Without a hwmod for am43xx emif use counting for emif clockdomain does not happen correctly so it may be shut off by pm code unintentionally. Signed-off-by: Dave Gerlach d-gerl...@ti.com Thanks, sent upstream for v4.2. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] ARM: tegra: Cardhu device-tree comment spelling fix
On Fri, 10 Apr 2015, Marcel Ziswiler wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com This patch is missing a commit message; please add one. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: tegra: fix hda2codec_2x clock name in Tegra124 device tree
On Fri, 10 Apr 2015, Marcel Ziswiler wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com This one is also missing a commit message; please add one. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] ARM: tegra: enable HDA in defconfig
On Fri, 10 Apr 2015, Marcel Ziswiler wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com This one is also missing a commit message; please add one. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] Documentation: DT bindings: fix hda2codec_2x clock name for tegra30-hda
On Fri, 10 Apr 2015, Marcel Ziswiler wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Fix hda2codec_2x clock name in Tegra30 HDA controller device tree node documentation. While at it also fix coma vs. semicolon issue. Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com Reviewed-by: Paul Walmsley p...@pwsan.com against the Tegra K1 TRM v03p - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] Documentation: DT bindings: Tegra AHB: require the legacy base address for existing chips
Per Stephen Warren, note in the Tegra AHB DT binding documentation
that we specifically deprecate any attempt to use the IP block's
actual hardware base address, and advocate the use of the legacy
off-by-four address in the 'regs' property, for Tegra chips with
existing upstream Linux DT files that include a Tegra AHB node. This
patch updates the documentation accordingly.
Changing the existing kernel DT data isn't under consideration because
Linux kernel DT data policy is to preserve compatibility between newer
DT data files and older kernels. However, this additional step of
changing the documentation should discourage others from sending
kernel patches to try to change the legacy kernel DT data.
Furthermore, for out-of-tree software (such as bootloaders or other
operating systems) that may rely on Linux kernel DT binding
documentation as an ABI (but not the Linux kernel DT data itself),
such a change may allow future convergence with the Linux kernel DT
data without additional code changes.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Paul Walmsley pwalms...@nvidia.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
.../bindings/arm/tegra/nvidia,tegra20-ahb.txt |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
index 067c9790062f..9a4295b54539 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
@@ -5,9 +5,12 @@ Required properties:
Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain
'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124,
tegra132, or tegra210.
-- reg : Should contain 1 register ranges(address and length)
+- reg : Should contain 1 register ranges(address and length). For
+ Tegra20, Tegra30, and Tegra114 chips, the value must be 0x6000c004
+ 0x10c. For Tegra124, Tegra132 and Tegra210 chips, the value should
+ be be 0x6000c000 0x150.
-Example:
+Example (for a Tegra20 chip):
ahb: ahb@6000c004 {
compatible = nvidia,tegra20-ahb;
reg = 0x6000c004 0x10c; /* AHB Arbitration + Gizmo Controller
*/
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Stephen Warren wrote:
The binding document is supposed to say what value the reg property should
have.
If you look at other DT binding documentation in the kernel, this is
generally not the case. Consider these examples:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/i2c/i2c-omap.txt
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
For example, the bcm2835 I2C binding documentation only mentions one of
the two I2C controllers apparently available on the system:
$ fgrep -r i2c arch/arm/boot/dts/ | fgrep bcm2835 | fgrep \@
arch/arm/boot/dts/bcm2835.dtsi: i2c0: i2c@20205000 {
arch/arm/boot/dts/bcm2835.dtsi: i2c1: i2c@7e804000 {
$
The Exynos documentation contains only one address of many I2C controllers
on the various SoCs:
$ fgrep -r i2c arch/arm/boot/dts/ | fgrep exynos | fgrep \@
...
arch/arm/boot/dts/exynos4415.dtsi: i2c_0: i2c@1386 {
arch/arm/boot/dts/exynos4415.dtsi: i2c_1: i2c@1387 {
arch/arm/boot/dts/exynos4415.dtsi: i2c_2: i2c@1388 {
arch/arm/boot/dts/exynos4415.dtsi: i2c_3: i2c@1389 {
arch/arm/boot/dts/exynos4415.dtsi: i2c_4: i2c@138A {
arch/arm/boot/dts/exynos4415.dtsi: i2c_5: i2c@138B {
arch/arm/boot/dts/exynos4415.dtsi: i2c_6: i2c@138C {
arch/arm/boot/dts/exynos4415.dtsi: i2c_7: i2c@138D {
arch/arm/boot/dts/exynos5250.dtsi: i2c_0: i2c@12C6 {
arch/arm/boot/dts/exynos5250.dtsi: i2c_1: i2c@12C7 {
arch/arm/boot/dts/exynos5250.dtsi: i2c_2: i2c@12C8 {
arch/arm/boot/dts/exynos5250.dtsi: i2c_3: i2c@12C9 {
arch/arm/boot/dts/exynos5250.dtsi: i2c_4: i2c@12CA {
arch/arm/boot/dts/exynos5250.dtsi: i2c_5: i2c@12CB {
arch/arm/boot/dts/exynos5250.dtsi: i2c_6: i2c@12CC {
arch/arm/boot/dts/exynos5250.dtsi: i2c_7: i2c@12CD {
arch/arm/boot/dts/exynos5250.dtsi: i2c_8: i2c@12CE {
arch/arm/boot/dts/exynos5250.dtsi: i2c_9: i2c@121D {
arch/arm/boot/dts/exynos5420.dtsi: i2c_0: i2c@12C6 {
arch/arm/boot/dts/exynos5420.dtsi: i2c_1: i2c@12C7 {
arch/arm/boot/dts/exynos5420.dtsi: i2c_2: i2c@12C8 {
arch/arm/boot/dts/exynos5420.dtsi: i2c_3: i2c@12C9 {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_4: i2c@12CA {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_5: i2c@12CB {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_6: i2c@12CC {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_7: i2c@12CD {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_8: i2c@12E0 {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_9: i2c@12E1 {
arch/arm/boot/dts/exynos5420.dtsi: hsi2c_10: i2c@12E2 {
arch/arm/boot/dts/exynos5440.dtsi: i2c@F {
arch/arm/boot/dts/exynos5440.dtsi: i2c@1 {
...
$
And there are many other integration details that would need to be
specified in the documentation using the approach that you advocate - for
example, interrupt and DMA IDs, etc.
If we require some unusual offset in the reg property (i.e. something
other than what the HW documentation describes as the module base address),
that ought to be documented. We do have this situation for this module at
present, although the documentation unfortunately doesn't explicitly call this
out even though the example alludes to it.
I do think we should at least fix the example so it isn't confusing and
inconsistent with expected practice. We could either switch the example to
Tegra210 so we only provide the best example going forward, or have separate
examples for Tegra20/210 to highlight the difference.
We should also add documentation that Chips before Tegra210 (or
Tegra132?) *require* the extra offset. Any code or DT written to the
existing (admittedly slightly implicit) binding needs to continue to
work, so we should document this unusual requirement, even if we enhance
the Linux driver to accept either mode of operation.
After the two driver patches (after rmk's requested changes) are applied,
no unusual offset will be required, but if the legacy offset is specified,
it will be transparently handled.
As I see it, there are three possible cases:
1. the legacy, incorrect base address is used, in which case everything
will still work but there will be a warning;
2. the correct base address (from a hardware SoC integration point of
view) is used, in which case everything will work with no warnings,
3. a novel, completely incorrect base address is used, in which case the
IP block won't work at all and the driver will fail completely
After the patches, the driver now handles the first two cases. If you
would like the DT binding documentation practice
Re: [PATCH 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Stephen Warren wrote: On 03/19/2015 10:34 AM, Paul Walmsley wrote: On Thu, 19 Mar 2015, Stephen Warren wrote: On 03/19/2015 09:33 AM, Paul Walmsley wrote: On Tue, 17 Mar 2015, Stephen Warren wrote: On 03/17/2015 02:32 AM, Paul Walmsley wrote: For Tegra132 and later chips, we can now use the correct hardware base address for the Tegra AHB IP block in the DT data. Update the DT binding documentation to reflect this change. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 067c979..7692b4c 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -2,10 +2,15 @@ NVIDIA Tegra AHB Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. A table-based approach rather than prose might make this more legible? - compatible: Must contain the following: Tegra20: nvidia,tegra20-ahb Tegra30: nvidia,tegra30-ahb Tegra114: nvidia,tegra114-ahb, nvidia,tegra30-ahb Tegra124: nvidia,tegra124-ahb, nvidia,tegra30-ahb Tegra132: nvidia,tegra132-ahb Tegra210: nvidia,tegra210-ahb, nvidia,tegra132-ahb With any luck, we can extend that final item for future chips to be: Tegra210, TegraNNN: nvidia,tegrachip-ahb, nvidia,tegra132-ahb Perhaps we format the 114/124 entry that way too. I think I'm just going to drop this patch, since Russell prefers that the workaround is applied in the driver. With regards to using tables rather than narrative descriptions: perhaps consider a patch to Documentation/devicetree/bindings/submitting-patches.txt ? I don't know what the DT binding documentation maintainers' future plans are with regards to automated documentation reflow, etc., but submitting a patch there would stimulate at least some coordination on the issue. I don't think it's appropriate for that file to dictate that, in the same way that coding style documentation generally doesn't address that kind of detail regarding code structure. We do indeed specify details like this in our documentation guidelines. Here are two examples: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n103 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle#n464 Perhaps I phrased my point slightly differently form the core of what I meant. I'm not aware that review feedback can't address topics that are not already addressed by the documentation. Is there such a rule? Not that I'm aware of, but I'm not sure that I understand the point you're making. Care to rephrase to make it more explicit? Equally, I think if you want the documentation to address a particular point, it's appropriate for you to submit a patch to the documentation to update it, rather than ask the reviewer to do so before accepting the review feedback. I guess my question is this: do you intend that the table-based documentation approach you describe should apply generally to other DT binding documents with similar per-chip support lists? Or is there something about the Tegra AHB specifically that merits this format? If the former was intended -- in other words, you are proposing a policy that should be followed in the general case -- then I would suggest that the documentation policy should be described in a shared DT binding CodingStyle or submitting-patches document, as we do elsewhere in the kernel. For example, the guidance could read[*], using your earlier example: --- If different values of a DT property are required for different chips or different situations
Re: [PATCHv2 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Stephen Warren wrote: We should not document Linux 4.1 as the cut-off. DT bindings are supposed to be OS agnostic. While it's practically unlikely, it is entirely possible for some other OS to have already implemented support for this binding, and the current binding is an ABI. We have no control over if/when any non-Linux code is updated to add support for a 0-based offset for existing SoCs, and certainly no versions of Linux or any other OS can be updated retro-actively except perhaps a few linux-stable versions. We can however write the binding in such a way as support for new SoCs requires the new 0-based address, since there is no binding specification for those new chips yet, and the time when you add the new binding documentation is the first time any OS could possibly add conformant support for it. In summary, I believe the binding document must state that T20/30/114/124 require the offset of 4 in reg value, and newer chips require no offset in the reg value. We can still always accept either in the Linux kernel going forward based on the principle of being lenient re: input data. That's fine. I'll send a patch for that. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Stephen Warren wrote: On 03/19/2015 09:26 AM, Paul Walmsley wrote: On Tue, 17 Mar 2015, Russell King - ARM Linux wrote: On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote: Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. You could check that in the driver. If you can check it in the driver, you can also decide to ignore it if it were offset by 0x04 (possibly printing a warning.) That opens up the ability to fix the older Tegra DT files going forward while still remaining compatible with existing DT files, and avoiding the need for a complex note about this. That's fine, I'll do that and drop this patch. Don't we still want to update the DT binding documentation to state what the preferred base address (or at least set of legal base addresses) is/are? As far as I know, the DT binding documents are intended to be a reference for IP block integration data like base addresses. At least, that is not how they've been used in the past, in the cases that I'm familiar with. I can see some marginal utility in changing the base address in the example. But since the worst possible outcome of using the old address is a warning message at boot, that margin seems quite small indeed. Anyone who would blindly use the base address from the example to create a DT file for a new Tegra SoC isn't doing it correctly. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Tue, 17 Mar 2015, Stephen Warren wrote: On 03/17/2015 02:32 AM, Paul Walmsley wrote: For Tegra132 and later chips, we can now use the correct hardware base address for the Tegra AHB IP block in the DT data. Update the DT binding documentation to reflect this change. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 067c979..7692b4c 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -2,10 +2,15 @@ NVIDIA Tegra AHB Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. A table-based approach rather than prose might make this more legible? - compatible: Must contain the following: Tegra20: nvidia,tegra20-ahb Tegra30: nvidia,tegra30-ahb Tegra114: nvidia,tegra114-ahb, nvidia,tegra30-ahb Tegra124: nvidia,tegra124-ahb, nvidia,tegra30-ahb Tegra132: nvidia,tegra132-ahb Tegra210: nvidia,tegra210-ahb, nvidia,tegra132-ahb With any luck, we can extend that final item for future chips to be: Tegra210, TegraNNN: nvidia,tegrachip-ahb, nvidia,tegra132-ahb Perhaps we format the 114/124 entry that way too. I think I'm just going to drop this patch, since Russell prefers that the workaround is applied in the driver. With regards to using tables rather than narrative descriptions: perhaps consider a patch to Documentation/devicetree/bindings/submitting-patches.txt ? I don't know what the DT binding documentation maintainers' future plans are with regards to automated documentation reflow, etc., but submitting a patch there would stimulate at least some coordination on the issue. As a historical note, I thought this issue might have been caused by the HW lumping together a bunch of vaguely related features into the same address window, with offset 0 being unrelated to AHB. This is certainly the explanation for some other interesting reg value in DT on other HW modules in Tegra. However as best I can tell that isn't the case for this HW module; we just mapped the start of the reg value to the first defined register for some reason rather than aligning it with the entry in the address map. So, this series makes sense to me. The series, Acked-by: Stephen Warren swar...@nvidia.com (it'd be nice if the DT doc was modified as I described above, but not strictly necessary. I like Russell's ideas how to make this more transparent/automatic so old DTs can be converted too). I'll add the ack on the first patch, but since the second one has been changed, I won't add one there yet. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Tue, 17 Mar 2015, Russell King - ARM Linux wrote: On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote: Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. You could check that in the driver. If you can check it in the driver, you can also decide to ignore it if it were offset by 0x04 (possibly printing a warning.) That opens up the ability to fix the older Tegra DT files going forward while still remaining compatible with existing DT files, and avoiding the need for a complex note about this. That's fine, I'll do that and drop this patch. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Stephen Warren wrote: On 03/19/2015 09:33 AM, Paul Walmsley wrote: On Tue, 17 Mar 2015, Stephen Warren wrote: On 03/17/2015 02:32 AM, Paul Walmsley wrote: For Tegra132 and later chips, we can now use the correct hardware base address for the Tegra AHB IP block in the DT data. Update the DT binding documentation to reflect this change. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 067c979..7692b4c 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -2,10 +2,15 @@ NVIDIA Tegra AHB Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. A table-based approach rather than prose might make this more legible? - compatible: Must contain the following: Tegra20: nvidia,tegra20-ahb Tegra30: nvidia,tegra30-ahb Tegra114: nvidia,tegra114-ahb, nvidia,tegra30-ahb Tegra124: nvidia,tegra124-ahb, nvidia,tegra30-ahb Tegra132: nvidia,tegra132-ahb Tegra210: nvidia,tegra210-ahb, nvidia,tegra132-ahb With any luck, we can extend that final item for future chips to be: Tegra210, TegraNNN: nvidia,tegrachip-ahb, nvidia,tegra132-ahb Perhaps we format the 114/124 entry that way too. I think I'm just going to drop this patch, since Russell prefers that the workaround is applied in the driver. With regards to using tables rather than narrative descriptions: perhaps consider a patch to Documentation/devicetree/bindings/submitting-patches.txt ? I don't know what the DT binding documentation maintainers' future plans are with regards to automated documentation reflow, etc., but submitting a patch there would stimulate at least some coordination on the issue. I don't think it's appropriate for that file to dictate that, in the same way that coding style documentation generally doesn't address that kind of detail regarding code structure. We do indeed specify details like this in our documentation guidelines. Here are two examples: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n103 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle#n464 Rather, the code review process hopefully homes in on the best representation case-by-case. A table seems more succinct and unambiguous in this case. I understand that your point of view in this case is that the table format is superior. My point of view on this issue, which is that any potential improvement in using a table format is outweighed by the time involved in doing it. Additionally I believe that the presence of the information is the most important criterion. My point of view is also that formatting guidelines should be coordinated at a kernel-wide level with the DT maintainers and placed into common policy documentation. That way everyone's expectations are aligned. Reviews can be based on shared rules, rather than individual whim. Such an approach also codifies expectations for programs that operate on documentation data, like the scripts/kernel-doc code. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] Documentation: DT bindings: Tegra AHB: note base address change
On Thu, 19 Mar 2015, Paul Walmsley wrote: On Thu, 19 Mar 2015, Stephen Warren wrote: On 03/19/2015 09:26 AM, Paul Walmsley wrote: On Tue, 17 Mar 2015, Russell King - ARM Linux wrote: On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote: Required properties: - compatible : For Tegra20, must contain nvidia,tegra20-ahb. For - Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain - 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, - tegra132, or tegra210. -- reg : Should contain 1 register ranges(address and length) + Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must + contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114 + or tegra124. For Tegra132, the compatible string must contain + nvidia,tegra132-ahb. + +- reg : Should contain 1 register ranges(address and length). On Tegra20, + Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base + address of the IP block must end in 0x04. On DT files for later chips, the + actual hardware base address of the IP block should be used. You could check that in the driver. If you can check it in the driver, you can also decide to ignore it if it were offset by 0x04 (possibly printing a warning.) That opens up the ability to fix the older Tegra DT files going forward while still remaining compatible with existing DT files, and avoiding the need for a complex note about this. That's fine, I'll do that and drop this patch. Don't we still want to update the DT binding documentation to state what the preferred base address (or at least set of legal base addresses) is/are? As far as I know, the DT binding documents are intended to be a reference for IP block integration data like base addresses. The above is missing an important word: it should have read are _not_ intended - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Documentation: DT bindings: Tegra AHB: note base address change
For Tegra132 and later chips, we can now use the correct hardware base
address for the Tegra AHB IP block in the DT data. Update the DT binding
documentation to reflect this change.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Paul Walmsley pwalms...@nvidia.com
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Hiroshi DOYU hd...@nvidia.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Paul Walmsley pwalms...@nvidia.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
.../bindings/arm/tegra/nvidia,tegra20-ahb.txt | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
index 067c979..7692b4c 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
@@ -2,10 +2,15 @@ NVIDIA Tegra AHB
Required properties:
- compatible : For Tegra20, must contain nvidia,tegra20-ahb. For
- Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain
- 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124,
- tegra132, or tegra210.
-- reg : Should contain 1 register ranges(address and length)
+ Tegra30, must contain nvidia,tegra30-ahb. For Tegra114 and Tegra124, must
+ contain 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra114
+ or tegra124. For Tegra132, the compatible string must contain
+ nvidia,tegra132-ahb.
+
+- reg : Should contain 1 register ranges(address and length). On Tegra20,
+ Tegra30, Tegra114, and Tegra124 chips, the low byte of the physical base
+ address of the IP block must end in 0x04. On DT files for later chips, the
+ actual hardware base address of the IP block should be used.
Example:
ahb: ahb@6000c004 {
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] omap3 crypto fixes
On Sun, 8 Mar 2015, Pali Rohár wrote: On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: Are there any fixes in this series that should go into v4.0-rc series, or can it all wait for v4.1? I think these all should wait for v4.1. A. I would suggest to include at least patches 01, 04, 06. Probably those could go to -stable tree... but this decision is up to you. I'm not sure patch 1 is a fix. As far as I know we haven't run into any issues with it on real hardware - only on QEMU - unless you know otherwise, Pali? Are we sure that the QEMU model behavior matches the hardware? - Paul
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
On Fri, 6 Mar 2015, Dave Gerlach wrote: On 03/06/2015 11:44 AM, Paul Walmsley wrote: On Fri, 6 Mar 2015, Dave Gerlach wrote: On 03/05/2015 10:26 PM, Paul Walmsley wrote: On Thu, 5 Mar 2015, Dave Gerlach wrote: RTC hwmod is needed for proper operation of PM features like rtcwake and rtc-only mode so reuse the am33xx rtc hwmod. Signed-off-by: Dave Gerlach d-gerl...@ti.com Thanks, queued for v4.1. Thanks, but please note as I just commented in Patch 1 of this series, without the ti,no-init flag in place that is introduced there this patch will cause the am43x-epos-evm to fail to boot. If that's so, shouldn't it appear in the series after patch 3, then? If only patches 1 and 2 are applied, then won't the boot be broken on am43x-epos-evm ? Hmm yes you are correct that would be the case, seems I should have swapped the order. I've gotten into the habit of putting dt patches last to enable what gets introduced previously, guess it's not always the best thing to do. Thanks for pointing this out. OK dropped until this thing is sorted out. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
Hi Dave,
On Fri, 6 Mar 2015, Dave Gerlach wrote:
Paul,
On 03/05/2015 10:26 PM, Paul Walmsley wrote:
On Thu, 5 Mar 2015, Dave Gerlach wrote:
RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if
*am43xx_hwmod_ocp_ifs[] __initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am33xx_l4_wkup__rtc,
NULL,
};
Thanks, queued for v4.1.
Thanks, but please note as I just commented in Patch 1 of this series, without
the ti,no-init flag in place that is introduced there this patch will cause
the
am43x-epos-evm to fail to boot.
If that's so, shouldn't it appear in the series after patch 3, then?
If only patches 1 and 2 are applied, then won't the boot be broken on
am43x-epos-evm ?
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
On Thu, 5 Mar 2015, Dave Gerlach wrote: Introduce a dt property, ti,no-init, that prevents hwmod initialization. Even if a dt node is marked as disabled, hwmod still at least enables the hwmod and programs the sysconfig before attempting to idle it at boot. If an IP has been disabled by the hardware configuration on a platform, this will cause a hang due to writing to inactive registers. This property prevents that from happening by marking the hwmod as _HWMOD_STATE_DISABLED during init. I'm kind of wondering if hwmod should even touch a device if it's marked as disabled in the DT. Tony, what do you think? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
On Thu, 5 Mar 2015, Dave Gerlach wrote:
RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am33xx_l4_wkup__rtc,
NULL,
};
Thanks, queued for v4.1.
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W
On Mon, 2 Mar 2015, Vignesh R wrote: From: Poddar, Sourav sourav.pod...@ti.com These adds hwmod data for hdq/1w driver on AM43xx. Signed-off-by: Vignesh R vigne...@ti.com --- Change log: v2: * Add SYSC_HAS_AUTOIDLE flag. arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 ++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 37 insertions(+) Thanks, queued for v4.1. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W
Hi
On Fri, 27 Feb 2015, Vignesh R wrote:
From: Poddar, Sourav sourav.pod...@ti.com
This patch adds hwmod data for hdq/1w driver on AM43xx.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[vigne...@ti.com: Ported patch to v4.0-rc1]
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36
++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb85925e444..d4f1df28475c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -20,6 +20,7 @@
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
#include omap_hwmod_common_data.h
+#include hdq1w.h
/* IP blocks */
@@ -516,6 +517,33 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
.parent_hwmod = am43xx_dss_core_hwmod,
};
+/* HDQ1W */
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0014,
+ .syss_offs = 0x0018,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
This is missing the SYSC_HAS_AUTOIDLE bit. Is this intentional?
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = am43xx_hdq1w_sysc,
+ .reset = omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = am43xx_hdq1w_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -790,6 +818,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_hdq1w_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -889,6 +924,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l4_ls__hdq1w,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..48df3b55057e 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET 0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
+#define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET 0x04a0
#endif
--
1.9.1
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
+ Felipe, Nishanth Hi Lokesh, what's the status here? - Paul On Fri, 2 Jan 2015, Paul Walmsley wrote: Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - 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 - Paul - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi Felipe On Tue, 27 Jan 2015, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). Just checking on this. Heard anything from the hardware team? If not I'd say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
On Tue, 10 Feb 2015, Felipe Balbi wrote: On Tue, Feb 10, 2015 at 11:12:40PM +, Paul Walmsley wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). Just checking on this. Heard anything from the hardware team? If not I'd say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... nothing from HW team yet. Last I heard is that they can reproduce the issue, and are now digging through documentation (and maybe RTL, but I'm speculating) to see if that should be supported or not. From my point of view, however, the thing idles, it just doesn't report it. Ok sounds like the thing to do is to wait until you hear back from them, if they are still looking at it. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] Documentation: DT bindings: add nvidia, tegra132-denver compatible string
Add a compatible string for the NVIDIA Denver CPU to the ARM CPU DT binding documentation file. The primary objective here is to keep checkpatch.pl from warning when the compatible string is used in an SoC DT file, per: http://marc.info/?l=linux-tegram=142201349727836w=2 This second version changes the string from nvidia,denver to nvidia,tegra132-denver to more precisely describe the revision of the Denver CPU complex that is present in the Tegra132 SoC. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Heiko Stuebner he...@sntech.de Cc: Arnd Bergmann a...@arndb.de Cc: Catalin Marinas catalin.mari...@arm.com Cc: Olof Johansson o...@lixom.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Rohit Vaswani rvasw...@codeaurora.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: Marc Carino marc.cee...@gmail.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/cpus.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b2aacbe16ed9..8b9e0a95de31 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -175,6 +175,7 @@ nodes to be present and contain the properties described below. marvell,pj4a marvell,pj4b marvell,sheeva-v5 + nvidia,tegra132-denver qcom,krait qcom,scorpion - enable-method -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] Documentation: DT bindings: add more Tegra chip compatible strings
Align compatible strings for several IP blocks present on Tegra chips with the latest doctrine from the DT maintainers: http://marc.info/?l=devicetreem=142255654213019w=2 The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 DT binding text files have been updated for the following IP blocks: - PCIe - SOR - SoC timers - AHB gizmo - APB_MISC - pinmux control - UART - PWM - I2C - SPI - RTC - PMC - eFuse - AHCI - HDA - XUSB_PADCTRL - SDHCI - SOC_THERM - AHUB - I2S - EHCI - USB PHY N.B. The nvidia,tegra20-timer compatible string is removed from the nvidia,tegra30-timer.txt documentation file because it's already mentioned in the nvidia,tegra20-timer.txt documentation file. This second version takes into account the following requests from Rob Herring robherri...@gmail.com: - Per-IP block patches have been combined into a single patch - Explicit documentation about which compatible strings are actually matched by the driver has been removed. In its place is implicit documentation that loosely follows Rob's prescribed format: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... [...] You should attempt to document known values of chip if you use it Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Dylan Reid dgr...@chromium.org Cc: Eduardo Valentin edubez...@gmail.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Hans de Goede hdego...@redhat.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Jingchang Lu jingchang...@freescale.com Cc: John Crispin blo...@openwrt.org Cc: Kumar Gala ga...@codeaurora.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Mark Rutland mark.rutl...@arm.com Cc: Mikko Perttunen mperttu...@nvidia.com Cc: Murali Karicheri m-kariche...@ti.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: Pawel Moll pawel.m...@arm.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Peter Hurley pe...@hurleysoftware.com Cc: Rob Herring robh...@kernel.org Cc: Sean Paul seanp...@chromium.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Takashi Iwai ti...@suse.de Cc: Tejun Heo t...@kernel.org Cc: Terje Bergström tbergst...@nvidia.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Tuomas Tynkkynen ttynkky...@nvidia.com Cc: Wolfram Sang w...@the-dreams.de Cc: Zhang Rui rui.zh...@intel.com Cc: dri-de...@lists.freedesktop.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org --- .../bindings/arm/tegra/nvidia,tegra20-ahb.txt |5 - .../bindings/arm/tegra/nvidia,tegra20-pmc.txt |6 +- .../devicetree/bindings/ata/tegra-sata.txt |4 +++- .../bindings/fuse/nvidia,tegra20-fuse.txt | 10 +- .../bindings/gpu/nvidia,tegra20-host1x.txt |8 ++-- .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 10 +- .../bindings/misc/nvidia,tegra20-apbmisc.txt |9 - .../bindings/mmc/nvidia,tegra20-sdhci.txt |6 +- .../bindings/pci/nvidia,tegra20-pcie.txt |8 .../bindings/pinctrl/nvidia,tegra124-pinmux.txt|3 ++- .../pinctrl/nvidia,tegra124-xusb-padctl.txt|4 +++- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |7 --- .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt |4 +++- .../devicetree/bindings/serial/of-serial.txt |5 - .../bindings/sound/nvidia,tegra30-ahub.txt |5 - .../bindings/sound/nvidia,tegra30-hda.txt |4 +++- .../bindings/sound/nvidia,tegra30-i2s.txt |5 - .../bindings/spi/nvidia,tegra114-spi.txt |4 +++- .../devicetree/bindings/thermal/tegra-soctherm.txt |4 +++- .../bindings/timer/nvidia,tegra30-timer.txt|4 +++- .../bindings/usb/nvidia,tegra20-ehci.txt |5 - .../bindings/usb/nvidia,tegra20-usb-phy.txt|5 - 22 files changed, 85 insertions(+), 40 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 234406d41c12..067c9790062f 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -1,7 +1,10 @@ NVIDIA Tegra AHB Required properties: -- compatible : nvidia,tegra20-ahb or nvidia,tegra30-ahb +- compatible : For Tegra20, must contain nvidia,tegra20-ahb. For + Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain + 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, + tegra132, or tegra210. - reg : Should contain 1 register ranges(address and length) Example: diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra
[PATCH v2 1/3] Documentation: DT: document compatible string existence requirement
DT maintainers require all compatible strings used in chip or board DTS file to be previously documented somewhere in Documentation/devicetree/bindings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Document this requirement in the DT patch submission requirements text file. This second version updates the documentation to align with Rob's comments here: http://marc.info/?l=devicetreem=142255654213019w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: Jonathan Corbet cor...@lwn.net Cc: Paul Walmsley pwalms...@nvidia.com Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/submitting-patches.txt | 23 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index b7ba01ad1426..56742bc70218 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -15,6 +15,29 @@ I. For patch submitters 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. + 4) Any compatible strings used in a chip or board DTS file must be + previously documented in the corresponding DT binding text file + in Documentation/devicetree/bindings. This rule applies even if + the Linux device driver does not yet match on the compatible + string. [ checkpatch will emit warnings if this step is not + followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 + (checkpatch: add DT compatible string documentation checks). ] + + 5) The wildcard chip may be used in compatible strings, as in + the following example: + + - compatible: Must contain 'nvidia,chip-pcie, + nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... + + As in the above example, the known values of chip should be + documented if it is used. + + 6) If a documented compatible string is not yet matched by the + driver, the documentation should also include a compatible + string that is matched by the driver (as in the nvidia,tegra20-pcie + example above). + + II. For kernel maintainers 1) If you aren't comfortable reviewing a given binding, reply to it and ask -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Documentation: DT bindings: update DT binding docs with Tegra chips
Update some of the DT binding documentation text files, per Mark's comments at: http://marc.info/?l=linux-tegram=142201349727836w=2 The primary goal with this series is to avoid checkpatch.pl warnings and align to the policy that Mark described. This series also updates Documentation/devicetree/bindings/submitting-patches.txt to formally document this policy. These patches apply on next-20150123. This second version incorporates some revisions based on feedback from Rob Herring. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/24] Documentation: DT bindings: add nvidia, denver compatible string
Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add a compatible string for the NVIDIA Denver CPU to the ARM CPU DT binding documentation file. The primary objective here is to keep checkpatch.pl from warning when the compatible string is used in an SoC DT file, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Heiko Stuebner he...@sntech.de Cc: Arnd Bergmann a...@arndb.de Cc: Catalin Marinas catalin.mari...@arm.com Cc: Olof Johansson o...@lixom.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Rohit Vaswani rvasw...@codeaurora.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: Marc Carino marc.cee...@gmail.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/cpus.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b2aacbe16ed9..4ea31f0b7764 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -175,6 +175,7 @@ nodes to be present and contain the properties described below. marvell,pj4a marvell,pj4b marvell,sheeva-v5 + nvidia,denver (not yet matched in the code) There's not variations or versions of Denver cores or plans to change from the codename? Hard to say what the future will bring. I'll change it to nvidia,tegra132-denver. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Documentation: DT: document compatible string existence requirement
Hello Javier, On 01/29/2015 09:43 AM, Javier Martinez Canillas wrote: Hello Paul, On 01/29/2015 12:49 AM, Paul Walmsley wrote: DT maintainers require all compatible strings used in chip or board DTS file to be previously documented somewhere in Documentation/devicetree/bindings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 I would had preferred if checkpatch.pl didn't warn about the most specific variants of the IP blocks tbh. Since afaiu those were only added to the compatible string as a way to make it future proof in case there is going to be needed later. So in that sense I thought they were not part of the DT ABI. Now, dumping the unused specific strings in binding docs only to make checkpatch happy, will have the effect of making those unused strings become part of the DT ABI. Which mean that couldn't be dropped later if those are found to not be needed since there won't be a way to know if an OS following the DT binding will be matching those or not. But since the decision is to warn for all strings in a compatible property even if those are not used, I agree with you that it should be documented. Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thanks for the review. For what it's worth, I agree with almost everything you wrote. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
On Thu, 29 Jan 2015, Paul Walmsley wrote: Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? (Just in case it wasn't clear, I mean for the purposes of the current patch series, not necessarily in general) - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-te...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/pci/nvidia,tegra20-pcie.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index d763e047c6ae..e772884f1c33 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -5,6 +5,8 @@ Required properties: - nvidia,tegra20-pcie - nvidia,tegra30-pcie - nvidia,tegra124-pcie + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 11:08 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? I don't think the binding document should say anything about what the driver uses or not. OK, will remove those. It should describe what combinations of compatible strings in a dts are valid. I didn't look at every patch, but the ones like this one are. OK, will switch to the format you described earlier: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... I'd be fine with most of this all in one patch BTW. OK, will squash. You should attempt to document known values of chip if you use it (you could refer to another doc for the list). Is there an example of this in the tree that you have in mind, where another document is used for the list? Would it just contain a list of the Tegra chips, e.g., tegra30, tegra114, tegra124, etc? I was only highlighting what you can get away with if no one is paying attention, not that you don't need to add tegra132, etc. :) OK. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Hi Rob I've also updated the first patch, that tries to document what the DT maintainers' expectations are. Care to give this one a quick glance too? - Paul From: Paul Walmsley pwalms...@nvidia.com Date: Wed, 28 Jan 2015 16:43:16 -0700 Subject: [PATCH] Documentation: DT: document compatible string existence requirement DT maintainers require all compatible strings used in chip or board DTS file to be previously documented somewhere in Documentation/devicetree/bindings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Document this requirement in the DT patch submission requirements text file. This second version updates the documentation to align with Rob's comments here: http://marc.info/?l=devicetreem=142255654213019w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: Jonathan Corbet cor...@lwn.net Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/submitting-patches.txt | 23 ++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index b7ba01ad1426..56742bc70218 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -15,6 +15,29 @@ I. For patch submitters 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. + 4) Any compatible strings used in a chip or board DTS file must be + previously documented in the corresponding DT binding text file + in Documentation/devicetree/bindings. This rule applies even if + the Linux device driver does not yet match on the compatible + string. [ checkpatch will emit warnings if this step is not + followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 + (checkpatch: add DT compatible string documentation checks). ] + + 5) The wildcard chip may be used in compatible strings, as in + the following example: + + - compatible: Must contain 'nvidia,chip-pcie, + nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... + + As in the above example, the known values of chip should be + documented if it is used. + + 6) If a documented compatible string is not yet matched by the + driver, the documentation should also include a compatible + string that is matched by the driver (as in the nvidia,tegra20-pcie + example above). + + II. For kernel maintainers 1) If you aren't comfortable reviewing a given binding, reply to it and ask -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Hi Rob, I've implemented the changes that you requested. Could you give this a quick look and see if it's sufficiently close to what you wanted? Will plan to repost the entire (much smaller) series tomorrow. - Paul From: Paul Walmsley p...@pwsan.com Date: Thu, 29 Jan 2015 18:41:18 -0700 Subject: [PATCH] Documentation: DT bindings: add more Tegra chip compatible strings Align compatible strings for several IP blocks present on Tegra chips with the latest doctrine from the DT maintainers: http://marc.info/?l=devicetreem=142255654213019w=2 The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 DT binding text files have been updated for the following IP blocks: - PCIe - SOR - SoC timers - AHB gizmo - APB_MISC - pinmux control - UART - PWM - I2C - SPI - RTC - PMC - eFuse - AHCI - HDA - XUSB_PADCTRL - SDHCI - SOC_THERM - AHUB - I2S - EHCI - USB PHY N.B. The nvidia,tegra20-timer compatible string is removed from the nvidia,tegra30-timer.txt documentation file because it's already mentioned in the nvidia,tegra20-timer.txt documentation file. This second version takes into account the following requests from Rob Herring robherri...@gmail.com: - Per-IP block patches have been combined into a single patch - Explicit documentation about which compatible strings are actually matched by the driver has been removed. In its place is implicit documentation that loosely follows Rob's prescribed format: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... [...] You should attempt to document known values of chip if you use it Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Dylan Reid dgr...@chromium.org Cc: Eduardo Valentin edubez...@gmail.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Hans de Goede hdego...@redhat.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Jingchang Lu jingchang...@freescale.com Cc: John Crispin blo...@openwrt.org Cc: Kumar Gala ga...@codeaurora.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Mark Rutland mark.rutl...@arm.com Cc: Mikko Perttunen mperttu...@nvidia.com Cc: Murali Karicheri m-kariche...@ti.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: Pawel Moll pawel.m...@arm.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Peter Hurley pe...@hurleysoftware.com Cc: Rob Herring robh...@kernel.org Cc: Sean Paul seanp...@chromium.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Takashi Iwai ti...@suse.de Cc: Tejun Heo t...@kernel.org Cc: Terje Bergström tbergst...@nvidia.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Tuomas Tynkkynen ttynkky...@nvidia.com Cc: Wolfram Sang w...@the-dreams.de Cc: Zhang Rui rui.zh...@intel.com Cc: devicetree@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org --- .../devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt | 5 - .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt | 6 +- Documentation/devicetree/bindings/ata/tegra-sata.txt | 4 +++- Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt | 10 +- .../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 8 ++-- Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 10 +- .../devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt| 9 - Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 6 +- Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt | 8 .../devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt | 3 ++- .../bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt | 4 +++- Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 7 --- Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt | 4 +++- Documentation/devicetree/bindings/serial/of-serial.txt | 5 - .../devicetree/bindings/sound/nvidia,tegra30-ahub.txt | 5 - Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt | 4 +++- Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt | 5 - Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt | 4 +++- Documentation/devicetree/bindings/thermal/tegra-soctherm.txt | 4 +++- .../devicetree/bindings/timer/nvidia,tegra30-timer.txt | 4 +++- Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt | 5 - .../devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt | 5 - 22 files changed, 85 insertions(+), 40 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 234406d41c12..067c9790062f 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia
[PATCH 05/24] Documentation: DT bindings: add more chip compatible strings for Tegra AHB gizmo
Add compatible strings for the AHB gizmo IP block present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/arm/tegra/nvidia,tegra20-ahb.txt |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 234406d41c12..fef3a9ecb798 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -1,7 +1,11 @@ NVIDIA Tegra AHB Required properties: -- compatible : nvidia,tegra20-ahb or nvidia,tegra30-ahb +- compatible : nvidia,tegra20-ahb + nvidia,tegra30-ahb + nvidia,tegra124-ahb (not yet matched by the driver) + nvidia,tegra132-ahb (not yet matched by the driver) + nvidia,tegra210-ahb (not yet matched by the driver) - reg : Should contain 1 register ranges(address and length) Example: -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-te...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/pci/nvidia,tegra20-pcie.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index d763e047c6ae..e772884f1c33 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -5,6 +5,8 @@ Required properties: - nvidia,tegra20-pcie - nvidia,tegra30-pcie - nvidia,tegra124-pcie + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) - device_type: Must be pci - reg: A list of physical base address and length for each set of controller registers. Must contain an entry for each entry in the reg-names property. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/24] Documentation: DT bindings: add more chip compatible strings for Tegra timers
Add compatible strings for the timer IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 N.B. The nvidia,tegra20-timer compatible string is removed from the nvidia,tegra30-timer.txt documentation file because it's already mentioned in the nvidia,tegra20-timer.txt documentation file. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/timer/nvidia,tegra30-timer.txt|4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt index b5082a1cf461..bbf38d26605b 100644 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt @@ -6,7 +6,9 @@ trigger a legacy watchdog reset. Required properties: -- compatible : should be nvidia,tegra30-timer, nvidia,tegra20-timer. +- compatible : nvidia,tegra30-timer + nvidia,tegra124-timer (not yet matched in the driver) + nvidia,tegra132-timer (not yet matched in the driver) - reg : Specifies base physical address and size of the registers. - interrupts : A list of 6 interrupts; one per each of timer channels 1 through 5, and one for the shared interrupt for the remaining channels. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/24] Documentation: DT bindings: add more chip compatible strings for Tegra I2C
Add compatible strings for the I2C IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Wolfram Sang w...@the-dreams.de Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt index 87507e9ce6db..8e233d913a78 100644 --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt @@ -2,6 +2,9 @@ NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver. Required properties: - compatible : should be: + nvidia,tegra210-i2c (not yet matched by the driver) + nvidia,tegra132-i2c (not yet matched by the driver) + nvidia,tegra124-i2c (not yet matched by the driver) nvidia,tegra114-i2c nvidia,tegra30-i2c nvidia,tegra20-i2c -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/24] Documentation: DT: document compatible string existence requirement
DT maintainers require all compatible strings used in chip or board DTS file to be previously documented somewhere in Documentation/devicetree/bindings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Document this requirement in the DT patch submission requirements text file. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: Jonathan Corbet cor...@lwn.net Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/submitting-patches.txt |8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index b7ba01ad1426..4b2bbb6047c4 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -15,6 +15,14 @@ I. For patch submitters 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. + 4) Any compatible strings used in a chip or board DTS file must be + previously documented in the corresponding DT binding text file + in Documentation/devicetree/bindings. This rule applies even if + the Linux device driver does not yet match on the compatible + string. checkpatch will emit warnings if this step is not + followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 + (checkpatch: add DT compatible string documentation checks). + II. For kernel maintainers 1) If you aren't comfortable reviewing a given binding, reply to it and ask -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/24] Documentation: DT bindings: add more chip compatible strings for Tegra eFuse
Add compatible strings for the eFuse IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/fuse/nvidia,tegra20-fuse.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt index d8c98c7614d0..c602216826af 100644 --- a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt +++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt @@ -6,6 +6,7 @@ Required properties: nvidia,tegra30-efuse nvidia,tegra114-efuse nvidia,tegra124-efuse + nvidia,tegra132-efuse (not yet matched by the driver) Details: nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data due to a hardware bug. Tegra20 also lacks certain information which is -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/24] Documentation: DT bindings: add more chip compatible strings for Tegra XUSB pad control
Add compatible strings for the XUSB pad control IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../pinctrl/nvidia,tegra124-xusb-padctl.txt|4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt index 2f9c0bd66457..3c75716aa341 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt @@ -13,7 +13,9 @@ how to describe and reference PHYs in device trees. Required properties: -- compatible: should be nvidia,tegra124-xusb-padctl +- compatible: nvidia,tegra124-xusb-padctl, + nvidia,tegra132-xusb-padctl (not yet matched by the driver) + nvidia,tegra210-xusb-padctl (not yet matched by the driver) - reg: Physical base address and length of the controller's registers. - resets: Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/24] Documentation: DT bindings: add more chip compatible strings for Tegra SOC_THERM
Add compatible strings for the SOC_THERM IP block present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Zhang Rui rui.zh...@intel.com Cc: Eduardo Valentin edubez...@gmail.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: linux...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/thermal/tegra-soctherm.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt index ecf3ed76cd46..9113f3bcd6df 100644 --- a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt +++ b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt @@ -7,7 +7,9 @@ notifications. It is also used to manage emergency shutdown in an overheating situation. Required properties : -- compatible : nvidia,tegra124-soctherm. +- compatible : nvidia,tegra124-soctherm, + nvidia,tegra132-soctherm (not yet matched by the driver) + nvidia,tegra210-soctherm (not yet matched by the driver) - reg : Should contain 1 entry: - SOCTHERM register set - interrupts : Defines the interrupt used by SOCTHERM -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/24] Documentation: DT bindings: add more chip compatible strings for Tegra AHCI
Add compatible strings for the AHCI IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Tejun Heo t...@kernel.org Cc: Mikko Perttunen mperttu...@nvidia.com Cc: Hans de Goede hdego...@redhat.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/ata/tegra-sata.txt |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt b/Documentation/devicetree/bindings/ata/tegra-sata.txt index 946f2072570b..2c44860d075e 100644 --- a/Documentation/devicetree/bindings/ata/tegra-sata.txt +++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt @@ -1,7 +1,8 @@ Tegra124 SoC SATA AHCI controller Required properties : -- compatible : nvidia,tegra124-ahci. +- compatible : nvidia,tegra124-ahci, + nvidia,tegra132-ahci (not yet matched by the driver) - reg : Should contain 2 entries: - AHCI register set (SATA BAR5) - SATA register set -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/24] Documentation: DT bindings: add more chip compatible strings for Tegra HDA
Add compatible strings for the HDA IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Takashi Iwai ti...@suse.de Cc: Dylan Reid dgr...@chromium.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/sound/nvidia,tegra30-hda.txt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt index b4730c2822bc..a114ca135d03 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt @@ -1,7 +1,10 @@ NVIDIA Tegra30 HDA controller Required properties: -- compatible : nvidia,tegra30-hda +- compatible : nvidia,tegra30-hda, + nvidia,tegra114-hda (not yet matched by the driver) + nvidia,tegra124-hda (not yet matched by the driver) + nvidia,tegra132-hda (not yet matched by the driver) - reg : Should contain the HDA registers location and length. - interrupts : The interrupt from the HDA controller. - clocks : Must contain an entry for each required entry in clock-names. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/24] Documentation: DT bindings: add more chip compatible strings for Tegra RTC
Add compatible strings for the RTC IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt index 652d1ff2e8be..b6d27e17b5e4 100644 --- a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt @@ -6,7 +6,9 @@ state. Required properties: -- compatible : should be nvidia,tegra20-rtc. +- compatible : nvidia,tegra20-rtc + nvidia,tegra124-rtc (not yet matched by the driver) + nvidia,tegra132-rtc (not yet matched by the driver) - reg : Specifies base physical address and size of the registers. - interrupts : A single interrupt specifier. - clocks : Must contain one entry, for the module clock. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/24] Documentation: DT bindings: add more chip compatible strings for Tegra PMC
Add compatible strings for the PMC IP block present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/arm/tegra/nvidia,tegra20-pmc.txt |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt index 68ac65f82a1c..84bb31e7b778 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt @@ -6,7 +6,11 @@ modes. It provides power-gating controllers for SoC and CPU power-islands. Required properties: - name : Should be pmc -- compatible : Should contain nvidia,tegrachip-pmc. +- compatible : nvidia,tegra20-pmc + nvidia,tegra30-pmc + nvidia,tegra114-pmc + nvidia,tegra124-pmc + nvidia,tegra132-pmc (not yet matched by the driver) - reg : Offset and length of the register set for the device - clocks : Must contain an entry for each entry in clock-names. See ../clocks/clock-bindings.txt for details. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/24] Documentation: DT bindings: add more chip compatible strings for Tegra UART
Add compatible strings for the UART IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Jingchang Lu jingchang...@freescale.com Cc: Peter Hurley pe...@hurleysoftware.com Cc: Murali Karicheri m-kariche...@ti.com Cc: John Crispin blo...@openwrt.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/serial/of-serial.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt index b52b98234b9b..06ebae54cbcc 100644 --- a/Documentation/devicetree/bindings/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/serial/of-serial.txt @@ -9,6 +9,11 @@ Required properties: - ns16750 - ns16850 - nvidia,tegra20-uart + - nvidia,tegra30-uart (not yet matched by the driver) + - nvidia,tegra114-uart (not yet matched by the driver) + - nvidia,tegra124-uart (not yet matched by the driver) + - nvidia,tegra132-uart (not yet matched by the driver) + - nvidia,tegra210-uart (not yet matched by the driver) - nxp,lpc3220-uart - ralink,rt2880-uart - ibm,qpace-nwp-serial -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/24] Documentation: DT bindings: add more chip compatible strings for Tegra SPI
Add compatible strings for the SPI IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/spi/nvidia,tegra114-spi.txt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt index 7ea701e07dc2..63b6d748f1cb 100644 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt @@ -1,7 +1,10 @@ NVIDIA Tegra114 SPI controller. Required properties: -- compatible : should be nvidia,tegra114-spi. +- compatible : nvidia,tegra114-spi + nvidia,tegra124-spi (not yet matched by the driver) + nvidia,tegra132-spi (not yet matched by the driver) + nvidia,tegra210-spi (not yet matched by the driver) - reg: Should contain SPI registers location and length. - interrupts: Should contain SPI interrupts. - clock-names : Must include the following entries: -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/24] Documentation: DT bindings: add more chip compatible strings for Tegra I2S
Add compatible strings for the I2S IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/sound/nvidia,tegra30-i2s.txt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt index 0c113ffe3814..f46566a09eeb 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt @@ -1,7 +1,10 @@ NVIDIA Tegra30 I2S controller Required properties: -- compatible : nvidia,tegra30-i2s +- compatible : nvidia,tegra30-i2s, + nvidia,tegra114-i2s (not yet matched by driver) + nvidia,tegra124-i2s + nvidia,tegra132-i2s (not yet matched by driver) - reg : Should contain I2S registers location and length - clocks : Must contain one entry, for the module clock. See ../clocks/clock-bindings.txt for details. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/24] Documentation: DT bindings: add more chip compatible strings for Tegra124 pinmux
Add a Tegra132 compatible string to the pinmux IP blocks present on chips similar to Tegra124. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Sean Paul seanp...@chromium.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/pinctrl/nvidia,tegra124-pinmux.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt index 189814e7cdc7..4eb7163a2eb8 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt @@ -7,6 +7,7 @@ a baseline, and only documents the differences between the two bindings. Required properties: - compatible: nvidia,tegra124-pinmux + nvidia,tegra132-pinmux (not yet matched in the driver) - reg: Should contain a list of base address and size pairs for: -- first entry - the drive strength and pad control registers. -- second entry - the pinmux registers -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/24] Documentation: DT bindings: add more chip compatible strings for Tegra SOR
Add compatible strings for the SOR IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Terje Bergström tbergst...@nvidia.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Alexandre Courbot gnu...@gmail.com Cc: dri-de...@lists.freedesktop.org Cc: linux-te...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/gpu/nvidia,tegra20-host1x.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index 4c32ef0b7db8..0e828c00e7e4 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -198,6 +198,7 @@ of the following host1x client modules: Required properties: - compatible: nvidia,tegra124-sor +nvidia,tegra132-sor (not yet matched in the driver) - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. - clocks: Must contain an entry for each entry in clock-names. @@ -223,6 +224,7 @@ of the following host1x client modules: - dpaux: DisplayPort AUX interface - compatible: nvidia,tegra124-dpaux +nvidia,tegra132-dpaux (not yet matched in the driver) - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. - clocks: Must contain an entry for each entry in clock-names. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Documentation: DT bindings: update DT binding docs with Tegra chips
Update some of the DT binding documentation text files, per Mark's comments at: http://marc.info/?l=linux-tegram=142201349727836w=2 The primary goal with this series is to avoid checkpatch.pl warnings and align to the policy that Mark described. This series also updates Documentation/devicetree/bindings/submitting-patches.txt to formally document this policy. These patches apply on next-20150123. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/24] Documentation: DT bindings: add more chip compatible strings for Tegra EHCI
Add compatible strings for the EHCI IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/usb/nvidia,tegra20-ehci.txt |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt index 3dc9140e3dfb..5c95962d350a 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt @@ -6,7 +6,12 @@ Practice : Universal Serial Bus with the following modifications and additions : Required properties : - - compatible : Should be nvidia,tegra20-ehci. + - compatible : nvidia,tegra20-ehci + nvidia,tegra30-ehci + nvidia,tegra114-ehci (not yet matched by the driver) + nvidia,tegra124-ehci (not yet matched by the driver) + nvidia,tegra132-ehci (not yet matched by the driver) + nvidia,tegra210-ehci (not yet matched by the driver) - nvidia,phy : phandle of the PHY that the controller is connected to. - clocks : Must contain one entry, for the module clock. See ../clocks/clock-bindings.txt for details. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/24] Documentation: DT bindings: add more chip compatible strings for Tegra PWM
Add compatible strings for the PWM IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-...@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt index c7ea9d4a988b..f3390f602378 100644 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt @@ -4,6 +4,10 @@ Required properties: - compatible: should be one of: - nvidia,tegra20-pwm - nvidia,tegra30-pwm + - nvidia,tegra114-pwm (not yet matched by the driver) + - nvidia,tegra124-pwm (not yet matched by the driver) + - nvidia,tegra132-pwm (not yet matched by the driver) + - nvidia,tegra210-pwm (not yet matched by the driver) - reg: physical base address and length of the controller's registers - #pwm-cells: should be 2. See pwm.txt in this directory for a description of the cells format. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/24] Documentation: DT bindings: add more chip compatible strings for Tegra AHUB
Add compatible strings for the AHUB IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/sound/nvidia,tegra30-ahub.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt index 946e2ac46091..2d93e719e4d6 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt @@ -1,7 +1,9 @@ NVIDIA Tegra30 AHUB (Audio Hub) Required properties: -- compatible : nvidia,tegra30-ahub, nvidia,tegra114-ahub, etc. +- compatible : nvidia,tegra30-ahub, nvidia,tegra114-ahub, + nvidia,tegra124-ahub + nvidia,tegra132-ahub (not yet matched by the driver) - reg : Should contain the register physical address and length for each of the AHUB's register blocks. - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/24] Documentation: DT bindings: add more chip compatible strings for Tegra USB PHY
Add compatible strings for the USB PHY IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Tuomas Tynkkynen ttynkky...@nvidia.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/usb/nvidia,tegra20-usb-phy.txt|7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index c9205fbf26e2..11a33346c409 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -3,7 +3,12 @@ Tegra SOC USB PHY The device node for Tegra SOC USB PHY: Required properties : - - compatible : Should be nvidia,tegrachip-usb-phy. + - compatible : nvidia,tegra20-usb-phy + nvidia,tegra30-usb-phy + nvidia,tegra114-usb-phy (not yet matched by the driver) + nvidia,tegra124-usb-phy (not yet matched by the driver) + nvidia,tegra132-usb-phy (not yet matched by the driver) + nvidia,tegra210-usb-phy (not yet matched by the driver) - reg : Defines the following set of registers, in the order listed: - The PHY's own register set. Always present. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/24] Documentation: DT bindings: add more chip compatible strings for Tegra APB_MISC
Add compatible strings for the APB_MISC IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/misc/nvidia,tegra20-apbmisc.txt |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt index b97b8bef1fe5..2723f3e4e52d 100644 --- a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt @@ -3,9 +3,10 @@ NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 apbmisc block Required properties: - compatible : should be: nvidia,tegra20-apbmisc - nvidia,tegra30-apbmisc - nvidia,tegra114-apbmisc - nvidia,tegra124-apbmisc + nvidia,tegra30-apbmisc (not yet matched in the driver) + nvidia,tegra114-apbmisc (not yet matched in the driver) + nvidia,tegra124-apbmisc (not yet matched in the driver) + nvidia,tegra132-apbmisc (not yet matched in the driver) - reg: Should contain 2 entries: the first entry gives the physical address and length of the registers which contain revision and debug features. The second entry gives the physical address and length of the -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/24] Documentation: DT bindings: add nvidia, denver compatible string
Add a compatible string for the NVIDIA Denver CPU to the ARM CPU DT binding documentation file. The primary objective here is to keep checkpatch.pl from warning when the compatible string is used in an SoC DT file, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Heiko Stuebner he...@sntech.de Cc: Arnd Bergmann a...@arndb.de Cc: Catalin Marinas catalin.mari...@arm.com Cc: Olof Johansson o...@lixom.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Rohit Vaswani rvasw...@codeaurora.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: Marc Carino marc.cee...@gmail.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/cpus.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b2aacbe16ed9..4ea31f0b7764 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -175,6 +175,7 @@ nodes to be present and contain the properties described below. marvell,pj4a marvell,pj4b marvell,sheeva-v5 + nvidia,denver (not yet matched in the code) qcom,krait qcom,scorpion - enable-method -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/24] Documentation: DT bindings: add more chip compatible strings for Tegra SDHCI
Add compatible strings for the SDHCI IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: devicetree@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- .../bindings/mmc/nvidia,tegra20-sdhci.txt |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt index f357c16ea815..877e5883ff14 100644 --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt @@ -7,7 +7,12 @@ This file documents differences between the core properties described by mmc.txt and the properties used by the sdhci-tegra driver. Required properties: -- compatible : Should be nvidia,chip-sdhci +- compatible : nvidia,tegra20-sdhci + nvidia,tegra30-sdhci + nvidia,tegra114-sdhci + nvidia,tegra124-sdhci + nvidia,tegra132-sdhci (not yet matched by the driver) + nvidia,tegra210-sdhci (not yet matched by the driver) - clocks : Must contain one entry, for the module clock. See ../clocks/clock-bindings.txt for details. - resets : Must contain an entry for each entry in reset-names. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
On Tue, 27 Jan 2015, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi
the references below are from SPRUHL7
On Fri, 23 Jan 2015, Felipe Balbi wrote:
Without hwmod data for DebugSS, performance monitors
have no chance of running on AM43xx devices.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40
++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c8410160e..6709704dd5b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,7 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include prm44xx.h
#include omap_hwmod_common_data.h
@@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
.rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets),
};
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
+ { .role = dbg_sysclk, .clk = dbg_sysclk_ck },
+ { .role = dbg_clka, .clk = dbg_clka_ck, },
+ { .role = dbg_clkb, .clk = dbg_clkb_ck, },
+ { .role = dbg_clkc, .clk = dbg_clkc_ck, },
+};
+
+static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+/* debugss */
+static struct omap_hwmod am43xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am43xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = trace_clk_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
According to Table 6-275 PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field
Descriptions this should have a
.modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = am43xx_debugss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks),
+};
+
+/* debugss - l3_main_2 */
+static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = {
+ .master = am43xx_debugss_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= sys_clkin_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
According to Table 31-25 Debug Modules Memory Mapping there are a few
initiator ports on the DEBUGSS that are connected to various slave ports
on various chip-wide interconnects: L3_EMU, L4_PER, L4_WAKEUP, L4_CFG. I
would suggest starting by adding at least one of them as a struct
omap_hwmod_ocp_if record. The one attached to L3_EMU would seem like a
good one to start with.
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..bb42cd80526d 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -93,6 +93,7 @@
#define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET 0x0548
#define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET 0x0550
#define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET 0x0558
+#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET 0x0020
#define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET0x0228
#define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET0x0360
#define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350
--
2.3.0-rc1
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: Add initial device tree support for Tegra132
+ Arto, Terje for comments on the host1x section + Stephen Warren for comments on the serial DT data Hi Mark, thanks for the review. On Wed, 21 Jan 2015, Mark Rutland wrote: As mentioned in my reply to the DT list patch [1], there are a couple of bits I'd like to see cleaned up first, but in the meantime I have some comments from my first pass of the dtsi below. Some of these may equally apply to existing dts(i) files. I see a few undocumented compatible strings (at least when comparing against mainline). If there are other series or trees I should be looking at, any pointers would be appreciated. If not, documentation updates would be nice (checkpatch should complain otherwise). (discussed in the tegra132-pcie comments below) On Fri, Jan 16, 2015 at 11:45:29AM +, Paul Walmsley wrote: Add an initial device tree file for the Tegra132 SoC. The DT file is based on arch/arm/boot/dts/tegra124.dtsi and arch/arm/boot/dts/tegra114.dtsi, with the following significant changes: - Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster - Devices are arranged by bus, rather than in a flat topology - No polling delays have been defined for the thermal zones. I don't believe that this is a property of the SoC hardware, but rather of a given use-case. DT nodes representing IP blocks have generally been labeled according to the names used in Section 2.1 System Address Map of the _Tegra K1 64-Bit Mobile Processor Technical Reference Manual_ (DP-07148-001_ALPHA), with a few exceptions for disambiguation or abbreviated naming. Some of the known IP block aliases used by PCB designers (e.g., GEN2_I2C for I2C2) have been noted in DT node comments. Known future work: - Add support for the Denver CLUSTER_clocks IP block - Add support for the CPU thermal zone; now handled by a CCPLEX IP block - The CPU spin_table enable-method may change to PSCI at some point That sounds nice. Any idea if/when that would be likely to happen? The PSCI aspect? Unfortunately not at the moment due to the secure firmware dependency. - Add support for several missing IP blocks - Some drivers use unusual address spaces for devices which don't match the TRM and/or hardware decode. At some point these should be reconciled. This patch was originally based on a patch by Allen Martin amar...@nvidia.com and the Tegra124 and Tegra114 DTS files. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: Allen Martin amar...@nvidia.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Russell King li...@arm.linux.org.uk Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: Alexandre Courbot gnu...@gmail.com Cc: devicetree@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-te...@vger.kernel.org --- arch/arm64/boot/dts/Makefile| 1 + arch/arm64/boot/dts/tegra/Makefile | 3 + arch/arm64/boot/dts/tegra/tegra132.dtsi | 997 3 files changed, 1001 insertions(+) create mode 100644 arch/arm64/boot/dts/tegra/Makefile create mode 100644 arch/arm64/boot/dts/tegra/tegra132.dtsi diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index b411251..90f6284 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -3,6 +3,7 @@ dts-dirs += apm dts-dirs += arm dts-dirs += cavium dts-dirs += exynos +dts-dirs += tegra This should probably be 'nvidia' (and 'exynos' probably should have been 'samsung', given all the other directories are vendor names rather than SoC family names. OK, will change. always := $(dtb-y) subdir-y := $(dts-dirs) diff --git a/arch/arm64/boot/dts/tegra/Makefile b/arch/arm64/boot/dts/tegra/Makefile new file mode 100644 index 000..15dbaa0 --- /dev/null +++ b/arch/arm64/boot/dts/tegra/Makefile @@ -0,0 +1,3 @@ +always := $(dtb-y) +subdir-y:= $(dts-dirs) +clean-files := *.dtb diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi b/arch/arm64/boot/dts/tegra/tegra132.dtsi new file mode 100644 index 000..4b93bfe --- /dev/null +++ b/arch/arm64/boot/dts/tegra/tegra132.dtsi @@ -0,0 +1,997 @@ +#include dt-bindings/clock/tegra124-car.h +#include dt-bindings/gpio/tegra-gpio.h +#include dt-bindings/memory/tegra124-mc.h +#include dt-bindings/pinctrl/pinctrl-tegra.h +#include dt-bindings/pinctrl/pinctrl-tegra-xusb.h +#include dt-bindings/interrupt-controller/arm-gic.h +#include dt-bindings/thermal/tegra124-soctherm.h + +#include skeleton.dtsi I'd recommend against
Re: [PATCH 1/5] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi
On Thu, 18 Dec 2014, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
...
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56
++
arch/arm/mach-omap2/prcm43xx.h | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index fea01aa..bd9067e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
...
@@ -750,6 +788,22 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe0_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe1_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -848,6 +902,8 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l3__vpfe0,
+ am43xx_l3__vpfe1,
NULL,
};
According to SPRUHL7 Figure 14-1 VPFE Integration and Table 14-2 VPFE
Connectivity Attributes, a VPFE has two interconnect ports per instance:
one L4-Per port as a register target, and one L3 port as a DMA initiator.
It's unclear to me whether the L3 port can also serve as a register
target, but Section 2.1 ARM Cortex-A9 Memory Map, Table 4-1 L3
Master-Slave Connectivity, and Figure 4-2 L4 Topology suggest that it
cannot.
So if that's correct, there should be two more struct omap_hwmod_ocp_if
records added in this patch for the register target ports that are
connected to the L4. DSS is a good example: see am43xx_dss__l3_main and
am43xx_l4_ls__dss in this same file.
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm64: dts: Add initial device tree support for Tegra132
Add an initial device tree file for the Tegra132 SoC. The DT file is
based on arch/arm/boot/dts/tegra124.dtsi and
arch/arm/boot/dts/tegra114.dtsi, with the following significant
changes:
- Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
- Devices are arranged by bus, rather than in a flat topology
- No polling delays have been defined for the thermal zones. I don't
believe that this is a property of the SoC hardware, but rather of a
given use-case.
DT nodes representing IP blocks have generally been labeled according
to the names used in Section 2.1 System Address Map of the _Tegra K1
64-Bit Mobile Processor Technical Reference Manual_
(DP-07148-001_ALPHA), with a few exceptions for disambiguation or
abbreviated naming. Some of the known IP block aliases used by PCB
designers (e.g., GEN2_I2C for I2C2) have been noted in DT node
comments.
Known future work:
- Add support for the Denver CLUSTER_clocks IP block
- Add support for the CPU thermal zone; now handled by a CCPLEX IP block
- The CPU spin_table enable-method may change to PSCI at some point
- Add support for several missing IP blocks
- Some drivers use unusual address spaces for devices which don't match
the TRM and/or hardware decode. At some point these should be
reconciled.
This patch was originally based on a patch by Allen Martin
amar...@nvidia.com and the Tegra124 and Tegra114 DTS files.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Paul Walmsley pwalms...@nvidia.com
Cc: Allen Martin amar...@nvidia.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Alexandre Courbot gnu...@gmail.com
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
---
arch/arm64/boot/dts/Makefile| 1 +
arch/arm64/boot/dts/tegra/Makefile | 3 +
arch/arm64/boot/dts/tegra/tegra132.dtsi | 997
3 files changed, 1001 insertions(+)
create mode 100644 arch/arm64/boot/dts/tegra/Makefile
create mode 100644 arch/arm64/boot/dts/tegra/tegra132.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index b411251..90f6284 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -3,6 +3,7 @@ dts-dirs += apm
dts-dirs += arm
dts-dirs += cavium
dts-dirs += exynos
+dts-dirs += tegra
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/tegra/Makefile
b/arch/arm64/boot/dts/tegra/Makefile
new file mode 100644
index 000..15dbaa0
--- /dev/null
+++ b/arch/arm64/boot/dts/tegra/Makefile
@@ -0,0 +1,3 @@
+always := $(dtb-y)
+subdir-y:= $(dts-dirs)
+clean-files := *.dtb
diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi
b/arch/arm64/boot/dts/tegra/tegra132.dtsi
new file mode 100644
index 000..4b93bfe
--- /dev/null
+++ b/arch/arm64/boot/dts/tegra/tegra132.dtsi
@@ -0,0 +1,997 @@
+#include dt-bindings/clock/tegra124-car.h
+#include dt-bindings/gpio/tegra-gpio.h
+#include dt-bindings/memory/tegra124-mc.h
+#include dt-bindings/pinctrl/pinctrl-tegra.h
+#include dt-bindings/pinctrl/pinctrl-tegra-xusb.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/thermal/tegra124-soctherm.h
+
+#include skeleton.dtsi
+
+/ {
+ compatible = nvidia,tegra132;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ pcie-controller@0,01003000 {
+ compatible = nvidia,tegra132-pcie, nvidia,tegra124-pcie;
+ device_type = pci;
+ reg = 0x0 0x01003000 0x0 0x0800 /* PADS registers */
+ 0x0 0x01003800 0x0 0x0800 /* AFI registers */
+ 0x0 0x0200 0x0 0x1000; /* configuration space */
+ reg-names = pads, afi, cs;
+ interrupts = GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH, /* controller
interrupt */
+GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH; /* MSI interrupt
*/
+ interrupt-names = intr, msi;
+
+ #interrupt-cells = 1;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH;
+
+ bus-range = 0x00 0xff;
+ #address-cells = 3;
+ #size-cells = 2;
+
+ ranges = 0x8200 0 0x0100 0x0 0x0100 0 0x1000
/* port 0 configuration space */
+ 0x8200 0 0x01001000 0x0 0x01001000 0 0x1000
/* port 1 configuration space */
+ 0x8100 0 0x00x0 0x1200 0 0x0001
/* downstream I/O (64 KiB
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - 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 - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] PM / devfreq: tegra: add devfreq driver for Tegra Activity Monitor
Hi
I have not reviewed this code closely, but a few items just caught my eye
at a brief glance.
On Tue, 9 Dec 2014, Tomeu Vizoso wrote:
The ACTMON block can monitor several counters, providing averaging and firing
interrupts based on watermarking configuration. This implementation monitors
the MCALL and MCCPU counters to choose an appropriate frequency for the
external memory clock.
This patch is based on work by Alex Frid af...@nvidia.com and Mikko
Perttunen mikko.perttu...@kapsi.fi.
It's important to put people in the Cc: section, either when you're basing
your code off of their work, or when you mention them in the patch
description. This means including specific Cc: lines in the
Signed-off-by: section at the bottom of the patch -- not just mentioning
them in the patch description. That way, any further followup from others
after the patch is committed is more likely to be appropriately copied to
those people.
For some reason this doesn't happen with many Tegra upstream-bound patches
-- from a variety of submitters, including NVIDIA submitters! -- but it
needs to start happening.
Also I see that Aleks Frid wasn't cc'ed at all in the E-mail headers;
fixing at least that point.
+static struct tegra_devfreq_device_config actmon_device_configs[] = {
+ {
+ /* MCALL: All memory accesses (including from the CPUs) */
+ .offset = 0x1c0,
+ .irq_mask = 1 26,
+ .boost_up_coeff = 200,
+ .boost_down_coeff = 50,
+ .boost_up_threshold = 60,
+ .boost_down_threshold = 40,
+ },
+ {
+ /* MCCPU: memory accesses from the CPUs */
+ .offset = 0x200,
+ .irq_mask = 1 25,
+ .boost_up_coeff = 800,
+ .boost_down_coeff = 90,
+ .boost_up_threshold = 27,
+ .boost_down_threshold = 10,
+ .avg_dependency_threshold = 5,
+ },
+};
This data represents PM policy. In other words, it is use-case sensitive.
Different users may wish to change these values depending on their
application characteristics -- and it does not represent unchangeable
hardware fact.
On the other hand...
+static u32 actmon_readl(struct tegra_devfreq *tegra, u32 offset)
+{
+ return readl(tegra-regs + offset);
+}
+
+static void actmon_writel(struct tegra_devfreq *tegra, u32 val, u32 offset)
+{
+ writel(val, tegra-regs + offset);
+}
+
+static u32 device_readl(struct tegra_devfreq_device *dev, u32 offset)
+{
+ return readl(dev-regs + offset);
+}
+
+static void device_writel(struct tegra_devfreq_device *dev, u32 val,
+ u32 offset)
+{
+ writel(val, dev-regs + offset);
+}
+
+static unsigned long do_percent(unsigned long val, unsigned int pct)
+{
+ return val * pct / 100;
+}
+
+static void tegra_devfreq_update_avg_wmark(struct tegra_devfreq *tegra,
+struct tegra_devfreq_device *dev)
+{
+ u32 avg = dev-avg_count;
+ u32 avg_band_freq = tegra-max_freq * ACTMON_DEFAULT_AVG_BAND / KHZ;
+ u32 band = avg_band_freq * ACTMON_SAMPLING_PERIOD;
+
+ device_writel(dev, avg + band, ACTMON_DEV_AVG_UPPER_WMARK);
+
+ avg = max(dev-avg_count, band);
+ device_writel(dev, avg - band, ACTMON_DEV_AVG_LOWER_WMARK);
+}
+
+static void tegra_devfreq_update_wmark(struct tegra_devfreq *tegra,
+struct tegra_devfreq_device *dev)
+{
+ u32 val = tegra-cur_freq * ACTMON_SAMPLING_PERIOD;
+
+ device_writel(dev, do_percent(val, dev-config-boost_up_threshold),
+ ACTMON_DEV_UPPER_WMARK);
+
+ device_writel(dev, do_percent(val, dev-config-boost_down_threshold),
+ ACTMON_DEV_LOWER_WMARK);
+}
+
+static void actmon_write_barrier(struct tegra_devfreq *tegra)
+{
+ /* ensure the update has reached the ACTMON */
+ wmb();
+ actmon_readl(tegra, ACTMON_GLB_STATUS);
+}
+
+static irqreturn_t actmon_isr(int irq, void *data)
+{
+ struct tegra_devfreq *tegra = data;
+ struct tegra_devfreq_device *dev = NULL;
+ unsigned long flags;
+ u32 val, intr_status, dev_ctrl;
+ unsigned int i;
+
+ val = actmon_readl(tegra, ACTMON_GLB_STATUS);
+
+ for (i = 0; i ARRAY_SIZE(tegra-devices); i++) {
+ if (val tegra-devices[i].config-irq_mask) {
+ dev = tegra-devices + i;
+ break;
+ }
+ }
+
+ if (!dev)
+ return IRQ_NONE;
+
+ spin_lock_irqsave(tegra-lock, flags);
+
+ dev-avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
+ tegra_devfreq_update_avg_wmark(tegra, dev);
+
+ intr_status = device_readl(dev, ACTMON_DEV_INTR_STATUS);
+ dev_ctrl = device_readl(dev, ACTMON_DEV_CTRL);
+
+ if (intr_status ACTMON_DEV_INTR_CONSECUTIVE_UPPER) {
+ /*
+ * new_boost =
Re: [PATCH v3 1/2] ARM: OMAP2+: hwmod: AM43x: add hwmod support for ADC on AM43xx
On Fri, 21 Nov 2014, Vignesh R wrote: This patch adds hwmod support for ADC on AM43xx. Since clockdomain and offsets of adc_tsc are different from AM33xx, ADC data has been directly added to AM43xx hwmod file. Signed-off-by: Vignesh R vigne...@ti.com Thanks, will try to queue this for v3.19. Will update my previous pull request. Otherwise it's v3.20 material. Note that I cannot test this patch locally due to the lack of an AM43xx board. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
On Thu, 20 Nov 2014, Lokesh Vutla wrote:
On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote:
RTC IP have kicker feature which prevents spurious writes to its registers.
In order to write into any of the RTC registers, KICK values has te be
written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc
sysconfig register without writing into any kick register which is a noop.
When autoidle is allowed for rtc, interruts are not received until IDLEMODE
is set to SIDLE_SMART_WKUP.
Adding a reset function to unlock RTC registers so that IDLEMODE is
updated.
Ping..!!
Is this patch acceptable?
Lokesh
1. This looks like a fix. Is this intended to go in as a v3.18-rc patch,
or against v3.19? If so it would be very helpful for the maintainers if
you were to state that somewhere.
2. Your patch unlocks the RTC registers, but never relocks it. This seems
to defeat the point of the spurious write protection. Shouldn't your
patch only unlock the RTC immediately before the hwmod code touches the
RTC registers, and then relock it immediately afterwards, per SPRUHZ6
section 23.4.3.3? If so then the .reset function pointer is the wrong
place for this; I would suggest adding some .lock and .unlock function
pointers that are to be called before and after any register write to the
IP block.
3. Your macros don't mention DRA7xx specifically. Does this sequence
apply to some other TI chips, or just DRA7xx? Please document this in a
comment above the macros, and possibly change the name of the macros to
refer to DRA7XX.
- Paul
Thanks and regards,
Lokesh
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_reset.c| 23 +++
3 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h
b/arch/arm/mach-omap2/omap_hwmod.h
index 512f809..3703f99 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -744,6 +744,7 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod
*oh);
*/
extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
+int omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 5684f11..90e1df4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1584,6 +1584,7 @@ static struct omap_hwmod_class_sysconfig
dra7xx_rtcss_sysc = {
static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
.name = rtcss,
.sysc = dra7xx_rtcss_sysc,
+ .reset = omap_hwmod_rtc_unlock,
};
/* rtcss */
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
b/arch/arm/mach-omap2/omap_hwmod_reset.c
index 65e186c..b825a28 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -30,6 +30,12 @@
#include omap_hwmod.h
+#define RTC_KICK0_REG_OFFSET 0x6c
+#define RTC_KICK1_REG_OFFSET 0x70
+
+#define RTC_KICK0_VALUE0x83E70B13
+#define RTC_KICK1_VALUE0x95A4F1E0
+
/**
* omap_hwmod_aess_preprogram - enable AESS internal autogating
* @oh: struct omap_hwmod *
@@ -51,3 +57,20 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
return 0;
}
+
+/**
+ * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
+ * @oh: struct omap_hwmod *
+ *
+ * RTC IP have kicker feature. This prevents spurious writes to its
registers.
+ * In order to write into any of the RTC registers, KICK values has te be
+ * written in respective KICK registers. This is needed for hwmod to write
into
+ * sysconfig register.
+ */
+int omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
+{
+ omap_hwmod_write(RTC_KICK0_VALUE, oh, RTC_KICK0_REG_OFFSET);
+ omap_hwmod_write(RTC_KICK1_VALUE, oh, RTC_KICK1_REG_OFFSET);
+
+ return 0;
+}
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Add support for ADC on am437x-gp and am43x-epos-evm
On Fri, 14 Nov 2014, Tony Lindgren wrote: * Vignesh R vigne...@ti.com [141113 20:09]: On Tuesday 04 November 2014 04:45 PM, Vignesh R wrote: This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. The ADC clock hwmod data of am33xx has been moved to commom place so that both am43xx and am33xx can reuse them. tscadc DT node has been adided to am437x-gp and am43x-epos dt files. With these patches, ADC functionalities are now available on am43xx. Changelog: v2: Removed phy addresses in hwmod. Using DT instead. Removed unused ti,am4372 compatible string. Use macro to set clk domain name. Fixed subject format of all patches Please accept these patches. Adding Paul to Cc, I don't think Paul has seen these, probably because get_maintainer.pl did not catch these hwmod files? Yeah we didn't have top-level coverage for the data files and my attempts to find other in-depth reviewers has so far failed. So just sent this: http://marc.info/?l=linux-omapm=141650684712440w=2 Want to take it upstream? - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
On Fri, 21 Nov 2014, Vignesh R wrote:
On 11/20/2014 12:39 PM, Paul Walmsley wrote:
On Tue, 4 Nov 2014, Vignesh R wrote:
This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
hwmod structures of tscadc has been moved to ipblock_data so that it can
be reused in am43xx. The clock domain names are separately set for am33xx
and am43xx. Thus tscadc dt entries can now be added to am43xx board
dt files.
Signed-off-by: Vignesh R vigne...@ti.com
...
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 6e57b8ad0db5..b92a7c7825fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
...
+static void am33xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l4hs_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l4_wkup_clkdm);
+}
+
+static void am43xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l3_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l3s_tsc_clkdm);
+}
+
...
+ am33xx_hwmod_clockdomain();
I looked at this patch and the one before it. Is there some reason why we
need to share these two hwmods between AM33xx and AM43xx? It seems
cleaner just to add the ADC data directly to the AM43xx hwmod data file,
not touch the AM33xx data, and not add another runtime data update for the
clockdomains. Unless there's something that I'm missing?
I wanted to reuse hwmod structures. Except for clockdomain and offset,
rest of the hwmod data are same for AM33xx and AM43xx. Adding data to AM43xx
hwmod file just duplicates these structures. Do you still want me to move them
to AM43xx file?
Yes. It looks to me like the number of lines saved by eliminating the
duplication is not too different than the number of lines added with the
dynamic clockdomain rewriting. Plus then we can avoid the dynamic
clockdomain rewriting that we are only doing for two IP blocks. Ideally
the hwmod data is meant to be static, not changed at runtime. For the
moment we are stuck with the CLKCTRL rewriting but I personally consider
that to be a hack.
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
On Tue, 4 Nov 2014, Vignesh R wrote:
This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
hwmod structures of tscadc has been moved to ipblock_data so that it can
be reused in am43xx. The clock domain names are separately set for am33xx
and am43xx. Thus tscadc dt entries can now be added to am43xx board
dt files.
Signed-off-by: Vignesh R vigne...@ti.com
...
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 6e57b8ad0db5..b92a7c7825fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
...
+static void am33xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l4hs_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l4_wkup_clkdm);
+}
+
+static void am43xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l3_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l3s_tsc_clkdm);
+}
+
...
+ am33xx_hwmod_clockdomain();
I looked at this patch and the one before it. Is there some reason why we
need to share these two hwmods between AM33xx and AM43xx? It seems
cleaner just to add the ADC data directly to the AM43xx hwmod data file,
not touch the AM33xx data, and not add another runtime data update for the
clockdomains. Unless there's something that I'm missing?
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: cm-t54: fix serial console power supply.
On Thu, 4 Sep 2014, Dmitry Lifshitz wrote: LDO8 regulator is used for act led and serial cosole power supply. Its DT status is declared as disabled, however the serial console was functional until Commit 318dbb02b (regulator: palmas: Fix SMPS enable/disable/is_enabled) wich properly turns off LDO8 on boot. Fix serial cosole power supply (and act led) on boot by turning LDO8 on. Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il Tested-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On Thu, 17 Jul 2014, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [140716 11:59]: On Wed, 16 Jul 2014, Sebastian Andrzej Siewior wrote: On 2014-07-15 20:21:21 [+], Paul Walmsley wrote: Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is it okay to add a Tested-by from you? Tested-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc Thanks Sebastian. Mugunthan, next step would be for you to get a Reviewed-by: by someone who has access to the (non-public) DRA7xx TRM, and can review for SoC integration. Since Rajendra is no longer at TI, the right person is probably Tony. Then this patch should be mergeable. Yeah took a look at it and acked it. Thanks queued for 3.17. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: DRA7: hwmod: Add data for RTC
On Tue, 22 Jul 2014, Lokesh Vutla wrote: Hi Paul, On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote: Add hwmod data for RTC Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Can you take this patch. I have submitted logs also. Thanks, queued for 3.17. And thanks for running rtctest in your testlog - that's helpful and gives some extra confidence. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On Wed, 16 Jul 2014, Sebastian Andrzej Siewior wrote: On 2014-07-15 20:21:21 [+], Paul Walmsley wrote: Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is it okay to add a Tested-by from you? Tested-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc Thanks Sebastian. Mugunthan, next step would be for you to get a Reviewed-by: by someone who has access to the (non-public) DRA7xx TRM, and can review for SoC integration. Since Rajendra is no longer at TI, the right person is probably Tony. Then this patch should be mergeable. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Mon, 14 Jul 2014, Kishon Vijay Abraham I wrote: On Wednesday 09 July 2014 04:32 PM, Rajendra Nayak wrote: On Wednesday 09 July 2014 02:32 PM, Kishon Vijay Abraham I wrote: Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC. Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tested-by: Kishon Vijay Abraham I kis...@ti.com --- Changes from v1: * changed the clock domain to pcie_clkdm * Added PCIe as a slave port for l3_main. Looks good to me, Reviewed-by: Rajendra Nayak rna...@ti.com Paul, Can you pick this one? Yep, queued for 3.17. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
Hi Sebastian, On Wed, 9 Jul 2014, Sebastian Andrzej Siewior wrote: On 2014-07-09 11:55:52 [+0200], Sebastian Andrzej Siewior wrote: On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC I reverted my patch, applied this one and after boot I got: Oh me dum dum. I had --dry-run… Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is it okay to add a Tested-by from you? Mugunthan, could you please get a Reviewed-by: from one of the folks on the DRA7xx SoC integration reviewers list that I sent earlier? - Paul
Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx
On Mon, 7 Jul 2014, Andre Heider wrote:
On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
this series adds PRUv2 support to uio_pruss through devicetree, makes the
device usable on am33xx and enables it on beaglebone black.
Inspired by old patches from Matt Porter found in a downstream tree.
To archieve that this series:
* adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)
...
* is the hardreset thing I did there the right thing to do? I think the
proper way would be a reset controller (which apparently doesn't yet exist
for this SoC?) and let the driver deassert/assert on probe/remove?
* the platform device path has a clk_enable() / clk_put() calls. Are those
now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
calls?
Probably you only need pm_runtime_{get,put}_*() calls, unless you're
changing clock parents or rates in your driver code.
@OMAP guys: any comments? The series depends on patch 5 and 6; both touch
common hwmod code.
I'd suggest splitting the series into three independent pieces if
possible:
1. UIO code, for the UIO maintainer(s)
2. DT pieces for Tony
3. hwmod pieces for me
That way they can be cleanly merged by the respective maintainers.
As far as the hwmod piece goes, I'd be willing to merge your code as a
temporary workaround for the issue, and marking it as such; but I'd be
concerned about power management-related interactions (i.e., does the
PRUSS need to be reset upon return from deep idle states, etc.)
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
On Wed, 25 Jun 2014, Kishon Vijay Abraham I wrote: Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC. Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro for pcie1 phy and pcie2 phy. Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tested-by: Kishon Vijay Abraham I kis...@ti.com Thanks, queued for v3.17 with Rajendra's ack. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
On Tue, 24 Jun 2014, Suman Anna wrote:
OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
- Paul
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14
--
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
.../mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c| 9 -
arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 -
4 files changed, 37 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2f15979..65b1647 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,6 @@
#include linux/i2c-omap.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -163,18 +162,6 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1, .irq_id = 0, .usr_id = 0 },
- { .name = iva, .tx_id = 2, .rx_id = 3, .irq_id = 1, .usr_id = 3 },
-};
-
-static struct omap_mbox_pdata omap2420_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2420_mailbox_info),
- .info = omap2420_mailbox_info,
-};
-
static struct omap_hwmod omap2420_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -188,7 +175,6 @@ static struct omap_hwmod omap2420_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2420_mailbox_attrs,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 6d1b609..c2555cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,7 +17,6 @@
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -161,17 +160,6 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1 },
-};
-
-static struct omap_mbox_pdata omap2430_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2430_mailbox_info),
- .info = omap2430_mailbox_info,
-};
-
static struct omap_hwmod omap2430_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -185,7 +173,6 @@ static struct omap_hwmod omap2430_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2430_mailbox_attrs,
};
/* mcspi3 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
index 0413dab..c1e98d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
@@ -152,15 +152,6 @@ struct omap_hwmod_addr_space omap2_dma_system_addrs[] = {
{ }
};
-struct omap_hwmod_addr_space omap2_mailbox_addrs[] = {
- {
- .pa_start = 0x48094000,
- .pa_end = 0x48094000 + SZ_512 - 1,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
struct omap_hwmod_addr_space omap2_mcbsp1_addrs[] = {
{
.name = mpu,
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 2c38c6b..11ed5a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -33,7 +33,6 @@ extern struct omap_hwmod_addr_space
omap2_mcspi1_addr_space[];
extern struct omap_hwmod_addr_space omap2_mcspi2_addr_space[];
extern struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[];
extern struct omap_hwmod_addr_space omap2_dma_system_addrs[];
-extern struct omap_hwmod_addr_space omap2_mailbox_addrs[];
extern struct omap_hwmod_addr_space omap2_mcbsp1_addrs[];
extern struct omap_hwmod_addr_space omap2_hdq1w_addr_space[];
--
2.0.0
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree
Re: [PATCH 9/9] ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
On Tue, 24 Jun 2014, Suman Anna wrote:
The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index e2db378..8f5989d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -317,21 +317,11 @@ struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
.user = OCP_USER_MPU,
};
-static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
- {
- .pa_start = 0x480C8000,
- .pa_end = 0x480C8000 + (SZ_4K - 1),
- .flags = ADDR_TYPE_RT
- },
- { }
-};
-
/* l4 ls - mailbox */
struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
.master = am33xx_l4_ls_hwmod,
.slave = am33xx_mailbox_hwmod,
.clk= l4ls_gclk,
- .addr = am33xx_mailbox_addrs,
.user = OCP_USER_MPU,
};
Acked-by: Paul Walmsley p...@pwsan.com
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
On Wed, 23 Apr 2014, Roger Quadros wrote: From: Keshava Munegowda keshava_mgo...@ti.com Create hwmods for ocp2scp3 and sata modules. [Roger Q] Clean up. CC: Benoit Cousson bcous...@baylibre.com Acked-by: Paul Walmsley p...@pwsan.com Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Queued here; will try to get this into the early -rcs. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
On Fri, 13 Jun 2014, Paul Walmsley wrote: Hi Roger, On Wed, 23 Apr 2014, Roger Quadros wrote: From: Nikhil Devshatwar nikhil...@ti.com Add hwmods for ocp2scp3 and sata modules. [Roger Q] Clean up. Sorry for the delay on this. Have been corresponding with TI to figure out what to do about these DRA7xx/AM43xx patches, since I don't have boards or public documentation for these devices, so it's impossible for me to meaningfully review the patches. Looks like boards and/or public docs won't be coming any time soon. So for my part, here's what I'll need to merge any hwmod patches that involve AM437x or DRA7xx: 1. A Reviewed-by: from one of the following folks (which should come from a different person than who is submitting the patches): Roger Quadros Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren 2. A Tested-by: from one of the following folks (who can be the same as the person who is the same as the person who is submitting the patches): Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren Once these are in place, I'd be happy to queue it for 3.16. I've tried to clarify this a bit. The update is below. - Paul For boards that I don't have access to, that I don't have documentation for, such as the AM43xx and DRA7xx), for me to merge or ack SoC infrastructure or PM-related patches, I want to have: 1. a Reviewed-by: from people who: a. I think know something about SoC integration or PM in general, and about OMAP-style integration specifically; and b. who have a track record of doing strong and detailed reviews of that code, or who have contributed significantly to that code in the past. My initial list of those reviewers is listed above, and I am happy to consider extending it or modifying that list. 2. confidence that the patch or series has been tested against a mainline commit and isn't obviously breaking other things, like PM, and confidence that it's not adding new runtime warnings. I've listed an initial set of people above who I feel have proven track records in testing who I'm happy to accept Tested-by:s without further explanation. I'm sure I've missed some folks and if anyone who should be on that list is offended that I didn't mention them, please accept my apologies. For other folks, like yourself, who aren't on that list (yet), please just specifically state: a. what mainline commit they've tested the patch against, b. what other prerequisite patches were needed for the patch to apply, c. and a cut-and-paste of the serial console boot log from the boot portion of the test. in such a way that myself or someone else can easily doublecheck it. And frankly, I'll probably be happy to merge it. After someone has done these three things a few times, and I gain confidence that they're doing the right thing, I'm happy to add them to my list. The testing doesn't have to be expressed via a Tested-by: tag in cases where you're testing as part of a Signed-off-by:. Just be sure to state those three things above as part of the patch or series message. The boot log can either be placed on a different page and linked to, or sent in another public E-mail. If you can get two or three people to do the above, that's great - the more, the better. ... These two steps do not apply to boards that I have in my testbed or which I have documentation for (although they would definitely be very welcome in those cases too). -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
Hi Roger, On Wed, 23 Apr 2014, Roger Quadros wrote: From: Nikhil Devshatwar nikhil...@ti.com Add hwmods for ocp2scp3 and sata modules. [Roger Q] Clean up. Sorry for the delay on this. Have been corresponding with TI to figure out what to do about these DRA7xx/AM43xx patches, since I don't have boards or public documentation for these devices, so it's impossible for me to meaningfully review the patches. Looks like boards and/or public docs won't be coming any time soon. So for my part, here's what I'll need to merge any hwmod patches that involve AM437x or DRA7xx: 1. A Reviewed-by: from one of the following folks (which should come from a different person than who is submitting the patches): Roger Quadros Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren 2. A Tested-by: from one of the following folks (who can be the same as the person who is the same as the person who is submitting the patches): Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren Once these are in place, I'd be happy to queue it for 3.16. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
Hi Roger, On Mon, 5 May 2014, Roger Quadros wrote: Add the sysconfig class bits for the Super Speed USB controllers CC: Paul Walmsley p...@pwsan.com Signed-off-by: Roger Quadros rog...@ti.com As with the previous DRA7 hwmod patch, I'd like to get a Reviewed-by: and a Tested-by: before merging this one. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/6] ARM: AM43xx: fix dpll init in bypass mode
On Mon, 24 Mar 2014, Sathya Prakash M R wrote: From: Tomi Valkeinen tomi.valkei...@ti.com On AM43xx, if a PLL is in bypass at kernel init, the code in omap2_get_dpll_rate() will not realize this and will try to calculate the clock rate using the multiplier and the divider, resulting in errors. omap2_init_dpll_parent() has similar issue. Add the missing soc_is_am43xx() check to make the code work on AM43xx. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Sathya Prakash M R sath...@ti.com Thanks, queued for v3.15-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
On Wed, 12 Mar 2014, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140307 02:18]:
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
Paul, does this look OK to you?
I didn't go over every entry with a magnifying glass, but did take a
quick look at the sysc_offs and the clkdms - the basics look OK.
Acked-by: Paul Walmsley p...@pwsan.com
- Paul
Regards,
Tony
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if
*omap54xx_hwmod_ocp_ifs[] __initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.8.3.2
--
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
- Paul
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
