Re: [net-next PATCH] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy
On Tuesday 01 September 2015 09:06 PM, Tony Lindgren wrote: > * Mugunthan V N [150901 04:28]: >> --- a/Documentation/devicetree/bindings/net/cpsw.txt >> +++ b/Documentation/devicetree/bindings/net/cpsw.txt >> @@ -26,6 +26,9 @@ Optional properties: >> - dual_emac : Specifies Switch to act as Dual EMAC >> - syscon: Phandle to the system control device node, which is >>the control module device of the am33x >> +- select-slave-gpio : Should be added if a gpio line is required to >> + select which slave is connected to phy >> + > > How about using something more generic here for the name? > Something like mode-gpios? > Yeah, agreed, for DRA72x it is used for connecting to phy, if some other board wanted to drive a GPIO for something else we can use this node to drive GPIO. Will submit a v2 with name change Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node
Kevin Hilman writes: > ping... this boot failure has now landed in mainline sorry, I'm on leave at the moment and travelling so I'm unlikely to be able to look at this properly. I should be able to examine this issue before the end of the month but cannot promise sooner than that (though it is not impossible). Maybe it would be best to just revert it until a proper analysis can be done. NeilBrown > > On Thu, Aug 27, 2015 at 1:51 PM, Kevin Hilman wrote: >> On Wed, Jul 29, 2015 at 5:11 PM, NeilBrown wrote: >>> Now that twl4030_bci_probe can safely return -EPROBE_DEFER, >>> do so when devm_usb_get_phy_by_node returns that error. >>> >>> Signed-off-by: NeilBrown >> >> This patch has hit linux-next in the form of coommit 3fc3895e4fe1 >> (twl4030_charger: correctly handle -EPROBE_DEFER from >> devm_usb_get_phy_by_node) and kernelci.org found a regression on >> omap3-beagle-xm[1]. Bisecting[2] this boot failure pointed at this >> commit, and I verified that reverting it on top of next-20150827 gets >> the board booting again. I haven't debugged any further. >> >> Kevin >> >> [1] >> http://storage.kernelci.org/next/next-20150827/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm.html >> [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/88/console signature.asc Description: PGP signature
Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node
ping... this boot failure has now landed in mainline On Thu, Aug 27, 2015 at 1:51 PM, Kevin Hilman wrote: > On Wed, Jul 29, 2015 at 5:11 PM, NeilBrown wrote: >> Now that twl4030_bci_probe can safely return -EPROBE_DEFER, >> do so when devm_usb_get_phy_by_node returns that error. >> >> Signed-off-by: NeilBrown > > This patch has hit linux-next in the form of coommit 3fc3895e4fe1 > (twl4030_charger: correctly handle -EPROBE_DEFER from > devm_usb_get_phy_by_node) and kernelci.org found a regression on > omap3-beagle-xm[1]. Bisecting[2] this boot failure pointed at this > commit, and I verified that reverting it on top of next-20150827 gets > the board booting again. I haven't debugged any further. > > Kevin > > [1] > http://storage.kernelci.org/next/next-20150827/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm.html > [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/88/console -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again
Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.
According to the OMAP35x Technical Reference Manual
CONTROL_PADCONF_I2C3_SDA[15:0] 0x480021C4 mode0: i2c3_sda
CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
the pinmux address of gpio 170 must be 0x480021C6.
The former wrong address broke i2c3 (used by hdmi ddc), resulting in
kernel message:
omap_i2c 4806.i2c: controller timed out
Signed-off-by: Carl Frederik Werner
---
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index fd792a4..18b178b 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -202,7 +202,7 @@
tfp410_pins: pinmux_tfp410_pins {
pinctrl-single,pins = <
- 0x194 (PIN_OUTPUT | MUX_MODE4) /* hdq_sio.gpio_170 */
+ 0x196 (PIN_OUTPUT | MUX_MODE4) /* hdq_sio.gpio_170 */
>;
};
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote: * Keerthy [150901 10:22]: On Wednesday 26 August 2015 09:29 AM, Keerthy wrote: Currently apart from dra7, omap5 and amx3 all the other SoCs are identified using cpu_is_* functions which is not right since they are all SoCs(System on Chips). Hence changing the SoC identification code to use soc_is instead of cpu_is and keeping defines for cpu_is where needed. This allows us to replace the rest of cpu_is usage along with other fixes as needed. Tony, A Gentle ping on this. Looks good to me for v4.4. I'll apply it after some testing after -rc1. Thanks Tony. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
* Mark Brown [150901 11:40]: > On Tue, Sep 01, 2015 at 07:17:21AM -0700, Tony Lindgren wrote: > > > Why don't you just make reg unused for pbias_regulator since > > we already use regmap for this driver? > > > Then in the pbias driver just define the register offset from > > the syscon base? You may need to set it based on the compatible > > value, but it's not like it's going to change for SoC. > > > If we eventually add some API to calculate reg base offset > > from the syscon base it's easy to update the driver to use > > that. > > That'd work. The other thing I was thinking we could do is to get > syscon to treat any excessively large address that gets passed in that > looks like an absolute address appropriately. Hmm wouldn't that get messy for 64-bit :) How about something like: unsigned long syscon_regmap_get_offset(struct regmap *syscon, void __iomem *base) Not sure if that's something that some drivers would start to misuse with read/writel though.. Presumably not if the driver already is using syscon. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
On Tue, Sep 01, 2015 at 07:17:21AM -0700, Tony Lindgren wrote: > Why don't you just make reg unused for pbias_regulator since > we already use regmap for this driver? > Then in the pbias driver just define the register offset from > the syscon base? You may need to set it based on the compatible > value, but it's not like it's going to change for SoC. > If we eventually add some API to calculate reg base offset > from the syscon base it's easy to update the driver to use > that. That'd work. The other thing I was thinking we could do is to get syscon to treat any excessively large address that gets passed in that looks like an absolute address appropriately. signature.asc Description: Digital signature
Re: [PATCH] arm: omap2: vc: fix 'or' always true warning
On Tue, Sep 1, 2015 at 5:46 PM, Tony Lindgren wrote: > * Frans Klaver [150828 03:14]: >> From: Frans Klaver >> >> Fix the warning: >> arch/arm/mach-omap2/vc.c:302:47: warning: logical ‘or’ of collectively >> exhaustive tests is always true [-Wlogical-op] >> >> As we're toggling both CLKREQ and OFFMODE, we should also be checking >> OFFMODE. >> >> Signed-off-by: Frans Klaver > > Thanks apppying into omap-for-v4.3/fixes. Thanks! Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
* Keerthy [150901 10:22]: > > > On Wednesday 26 August 2015 09:29 AM, Keerthy wrote: > >Currently apart from dra7, omap5 and amx3 all the other SoCs > >are identified using cpu_is_* functions which is not right since > >they are all SoCs(System on Chips). Hence changing the SoC > >identification code to use soc_is instead of cpu_is and keeping > >defines for cpu_is where needed. This allows us to replace the > >rest of cpu_is usage along with other fixes as needed. > > Tony, > > A Gentle ping on this. Looks good to me for v4.4. I'll apply it after some testing after -rc1. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:
Currently apart from dra7, omap5 and amx3 all the other SoCs
are identified using cpu_is_* functions which is not right since
they are all SoCs(System on Chips). Hence changing the SoC
identification code to use soc_is instead of cpu_is and keeping
defines for cpu_is where needed. This allows us to replace the
rest of cpu_is usage along with other fixes as needed.
Tony,
A Gentle ping on this.
Regards,
Keerthy
Acked-by: Russell King
Signed-off-by: Keerthy
---
Changes in v2:
* Corrected a typo in the commit log.
arch/arm/mach-omap2/id.c | 30 +++
arch/arm/mach-omap2/soc.h | 193 ++
2 files changed, 123 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713f..24f24d4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -57,15 +57,15 @@ int omap_type(void)
if (val < OMAP2_DEVICETYPE_MASK)
return val;
- if (cpu_is_omap24xx()) {
+ if (soc_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
- } else if (cpu_is_ti81xx()) {
+ } else if (soc_is_ti81xx()) {
val = omap_ctrl_readl(TI81XX_CONTROL_STATUS);
} else if (soc_is_am33xx() || soc_is_am43xx()) {
val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
- } else if (cpu_is_omap34xx()) {
+ } else if (soc_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
- } else if (cpu_is_omap44xx()) {
+ } else if (soc_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
@@ -122,7 +122,7 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
- if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
+ if (soc_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -218,17 +218,17 @@ static void __init omap3_cpuinfo(void)
* on available features. Upon detection, update the CPU id
* and CPU class bits.
*/
- if (cpu_is_omap3630()) {
+ if (soc_is_omap3630()) {
cpu_name = "OMAP3630";
} else if (soc_is_am35xx()) {
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
- } else if (cpu_is_ti816x()) {
+ } else if (soc_is_ti816x()) {
cpu_name = "TI816X";
} else if (soc_is_am335x()) {
cpu_name = "AM335X";
} else if (soc_is_am437x()) {
cpu_name = "AM437x";
- } else if (cpu_is_ti814x()) {
+ } else if (soc_is_ti814x()) {
cpu_name = "TI814X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
@@ -275,11 +275,11 @@ void __init omap3xxx_check_features(void)
OMAP3_CHECK_FEATURE(status, SGX);
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
- if (cpu_is_omap3630())
+ if (soc_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
- if (cpu_is_omap3430() || cpu_is_omap3630())
+ if (soc_is_omap3430() || soc_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
- if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
+ if (soc_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
@@ -697,7 +697,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem
*tap)
tap_base = tap;
/* XXX What is this intended to do? */
- if (cpu_is_omap34xx())
+ if (soc_is_omap34xx())
tap_prod_id = 0x0210;
else
tap_prod_id = 0x0208;
@@ -715,11 +715,11 @@ static const char * const omap_types[] = {
static const char * __init omap_get_family(void)
{
- if (cpu_is_omap24xx())
+ if (soc_is_omap24xx())
return kasprintf(GFP_KERNEL, "OMAP2");
- else if (cpu_is_omap34xx())
+ else if (soc_is_omap34xx())
return kasprintf(GFP_KERNEL, "OMAP3");
- else if (cpu_is_omap44xx())
+ else if (soc_is_omap44xx())
return kasprintf(GFP_KERNEL, "OMAP4");
else if (soc_is_omap54xx())
return kasprintf(GFP_KERNEL, "OMAP5");
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d..bb824ae 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -148,13 +148,13 @@ static inline int soc_is_omap(void)
/*
* Ma
Re: [PATCH v5 0/3] ARM: AM437X: Add rtc clock handling
On Tuesday 01 September 2015 08:57 PM, Tony Lindgren wrote: * Alexandre Belloni [150826 14:57]: On 26/08/2015 at 11:01:27 -0700, Tony Lindgren wrote : * Keerthy [150826 09:54]: Tony, On Saturday 22 August 2015 02:48 AM, Alexandre Belloni wrote: Tony, On 18/08/2015 at 15:11:13 +0530, Keerthy wrote : The series is applicable for all am437x series of processors. It adds clock handling support. Boot tested on am437x-gp-evm. Keerthy (3): ARM: dts: AM437x: Add the internal and external clock nodes for rtc rtc: omap: Add internal clock enabling support rtc: omap: Add external clock enabling support I'm wondering how you want to get those patches merged. I can let you take 2 and 3 through arm-soc but you will miss 4.3. Or I can take 2 and 3 for 4.3 but the documentation will be missing. A gentle ping on this series. Alexandre, it's probably best that you take them all. The dts changes apply against Linux next with fuzz so there should not be any merge conflict. Feel free to add: Acked-by: Tony Lindgren So, I've rebased 1/3 on rtc-next to avoid depending on arm-soc. I've pushed everything and hopefully there won't be any issues in linux-next. We are quite close to the merge window so I would be much more confident sending them to Linus if you could test linux-next once the patches land there. Keerthy, I presume you have now tested these with Linux next? Yes. When i had posted v5. I tested them. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: DRA7: fix a typo in ethernet
* Tony Lindgren [150901 08:53]: > * Vishal Mahaveer [150825 12:01]: > > Register address in name of the node is wrong > > > > Signed-off-by: Vishal Mahaveer > > Acked-by: Mugunthan V N > > Thanks applying into omap-for-v4.3/fixes. Actually I'll wait on this one until -rc1 as it causes a merge conflict with the pending dts changes and SoC branch currently. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: DRA7: fix a typo in ethernet
* Vishal Mahaveer [150825 12:01]:
> Register address in name of the node is wrong
>
> Signed-off-by: Vishal Mahaveer
> Acked-by: Mugunthan V N
Thanks applying into omap-for-v4.3/fixes.
Tony
> ---
> arch/arm/boot/dts/dra7.dtsi |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 1e29ccf..9a20d46 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1398,7 +1398,7 @@
> ti,irqs-safe-map = <0>;
> };
>
> - mac: ethernet@4a10 {
> + mac: ethernet@48484000 {
> compatible = "ti,cpsw";
> ti,hwmods = "gmac";
> clocks = <&dpll_gmac_ck>, <&gmac_gmii_ref_clk_div>;
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA752: Add ID detect for ES2.0
* Nishanth Menon [150813 07:35]: > From: Vishal Mahaveer > > ES2.0 is a minor variant of ES1.1. ES2.0 is an incremental revision > with various fixes including the following: > - reset logic fixes > - few assymetric aging logic fixes > - MMC clock rate fixes > - Ethernet speed fixes > - edma fixes for mcasp > > NOTE: even though we use a compatible of dra742 and dra752, the usage in > the Linux kernel is more or less interchangable - we use dra752 more > often in the linux kernel compared to dra742 and 4.2-rc6 > > Signed-off-by: Vishal Mahaveer > Signed-off-by: Nishanth Menon > --- > based on linux-next next-20150812, applies to v4.2-rc6 as well. > Definetly not a 4.2 material, for 4.3, this probably missed the first merge > window for 4.3, will be great if it could be considered for the second merge > window. I'll apply this into omap-for-v4.3/fixes thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: vc: fix 'or' always true warning
* Frans Klaver [150828 03:14]:
> From: Frans Klaver
>
> Fix the warning:
> arch/arm/mach-omap2/vc.c:302:47: warning: logical ‘or’ of collectively
> exhaustive tests is always true [-Wlogical-op]
>
> As we're toggling both CLKREQ and OFFMODE, we should also be checking
> OFFMODE.
>
> Signed-off-by: Frans Klaver
Thanks apppying into omap-for-v4.3/fixes.
Tony
> ---
> arch/arm/mach-omap2/vc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 076fd20d7e5a..807bc79e3e3d 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -300,7 +300,7 @@ static void __init omap3_vc_init_pmic_signaling(struct
> voltagedomain *voltdm)
>
> val = voltdm->read(OMAP3_PRM_POLCTRL_OFFSET);
> if (!(val & OMAP3430_PRM_POLCTRL_CLKREQ_POL) ||
> - (val & OMAP3430_PRM_POLCTRL_CLKREQ_POL)) {
> + (val & OMAP3430_PRM_POLCTRL_OFFMODE_POL)) {
> val |= OMAP3430_PRM_POLCTRL_CLKREQ_POL;
> val &= ~OMAP3430_PRM_POLCTRL_OFFMODE_POL;
> pr_debug("PM: fixing sys_clkreq and sys_off_mode polarity to
> 0x%x\n",
> --
> 2.3.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP2+: omap-device: fix race deferred probe of omap_hsmmc vs omap_device_late_init
* Grygorii Strashko [150828 08:31]: > Kernel fails to boot 50% of times (form build to build) with > RT-patchset applied due to the following race - on late boot > stages deferred_probe_work_func->omap_hsmmc_probe races with > omap_device_late_ini. Applying into omap-for-v4.3/fixes thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy
* Mugunthan V N [150901 04:28]: > --- a/Documentation/devicetree/bindings/net/cpsw.txt > +++ b/Documentation/devicetree/bindings/net/cpsw.txt > @@ -26,6 +26,9 @@ Optional properties: > - dual_emac : Specifies Switch to act as Dual EMAC > - syscon : Phandle to the system control device node, which is > the control module device of the am33x > +- select-slave-gpio : Should be added if a gpio line is required to > + select which slave is connected to phy > + How about using something more generic here for the name? Something like mode-gpios? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] ARM: AM437X: Add rtc clock handling
* Alexandre Belloni [150826 14:57]: > On 26/08/2015 at 11:01:27 -0700, Tony Lindgren wrote : > > * Keerthy [150826 09:54]: > > > Tony, > > > > > > On Saturday 22 August 2015 02:48 AM, Alexandre Belloni wrote: > > > >Tony, > > > > > > > >On 18/08/2015 at 15:11:13 +0530, Keerthy wrote : > > > >>The series is applicable for all am437x series of processors. > > > >>It adds clock handling support. Boot tested on am437x-gp-evm. > > > >> > > > >>Keerthy (3): > > > >> ARM: dts: AM437x: Add the internal and external clock nodes for rtc > > > >> rtc: omap: Add internal clock enabling support > > > >> rtc: omap: Add external clock enabling support > > > >> > > > > > > > >I'm wondering how you want to get those patches merged. I can let you > > > >take 2 and 3 through arm-soc but you will miss 4.3. Or I can take 2 and > > > >3 for 4.3 but the documentation will be missing. > > > > > > A gentle ping on this series. > > > > Alexandre, it's probably best that you take them all. The dts changes > > apply against Linux next with fuzz so there should not be any merge > > conflict. Feel free to add: > > > > Acked-by: Tony Lindgren > > > > So, I've rebased 1/3 on rtc-next to avoid depending on arm-soc. I've > pushed everything and hopefully there won't be any issues in linux-next. > We are quite close to the merge window so I would be much more confident > sending them to Linus if you could test linux-next once the patches land > there. Keerthy, I presume you have now tested these with Linux next? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PowerVR SGX540 drivers for PandaBoard(OMAP4460) on vanilla kernel
* Sedat Marangoz [150813 05:14]: > Hi all, > > Is there a way to install PVR SGX540 driver to my PandaBoard > ES(OMAP4460) which runs on vanilla kernel and small filesystem. > The latest Graphics SDK does not have support for OMAP4. > I searched and found pvr_omap is available for Ubuntu 12.04 via > installing omap4-extras package. > Also, there is similar issue here: > https://e2e.ti.com/support/omap/f/849/t/287992 which advices to use > GLSDK. > > But in our project we are not using Ubuntu, instead there is small > ROOTFS and the kernel version is 3.10.80 (because of some specific > project reasons). > I found some packages here: > https://launchpad.net/~tiomap-dev/+archive/ubuntu/release/+packages . > And tried to build source package of > "pvr-omap4-dkms_1.9.0.7.1.1-1_armhf.deb" according to below > instructions, but I got lots of errors. > > export ARCH=arm > export CROSS_COMPILE= > export DISCIMAGE= > export KERNELDIR= (I tried both 3.8 and 3.10.80 kernel > versions source code) > cd eurasiacon/build/linux2/omap4430_linux/ > make > > I do not think pvr_omap4 source code has proper header and source > files for my kernel, am I wrong? Hmm would be nice to get this usable with mainline kernel.. Do you have a diffstat of what's missing for the headers and other things that could be in the mainline kernel? > Is there a way to install SGX540 driver to my Pandaboard ES (OMAP4460) > which has custom kernel such as version 3.10.80? Probably best to get it working with mainline kernel, 3.10 is getting kind of old :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
* Grygorii Strashko [150901 07:57]: > On 09/01/2015 05:50 PM, Tony Lindgren wrote: > >> > >>On -next, Above crash signature could be related to race > >>"ARM: OMAP2+: omap-device: fix race deferred probe of omap_hsmmc vs > >>omap_device_late_init" > >>http://www.spinics.net/lists/linux-omap/msg121622.html > > > >Good point thanks, yes that's the case. MMC probing fails and then we hit > >this > >separate issue while MMC is trying to probe. Applying your fix makes the > >abort disappear, but naturally does not get MMC working again. > > you may need CONFIG_GPIO_PCF857X=y for dra7-evm This is a regression at least on omap4 as pointed out by Olof. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
On 09/01/2015 05:50 PM, Tony Lindgren wrote: * Grygorii Strashko [150901 07:36]: On 09/01/2015 12:14 AM, Tony Lindgren wrote: * Tony Lindgren [150831 14:02]: And I must have tested next-20150827 instead of next-20150828. Or else it does not happen on every boot. In any case, I'm now getting the following on next-20150831 most of the time: [9.493133] omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup [9.500274] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed [9.506378] [ cut here ] [9.508941] WARNING: CPU: 0 PID: 6 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x224/0x350() [9.520568] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Read): Data Access in User mode during Functional access [9.524810] Modules linked in: rtc_twl twl4030_wdt [9.534820] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-next-20150831-2-gf55bad8 #1113 [9.544830] Hardware name: Generic OMAP4 (Flattened Device Tree) [9.544830] Workqueue: deferwq deferred_probe_work_func [9.554809] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [9.564819] [] (show_stack) from [] (dump_stack+0x84/0x9c) [9.574829] [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) [9.574951] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [9.584686] [] (warn_slowpath_fmt) from [] (l3_interrupt_handler+0x224/0x350) [9.594818] [] (l3_interrupt_handler) from [] (handle_irq_event_percpu+0x44/0x1f0) [9.604827] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x40/0x64) [9.614807] [] (handle_irq_event) from [] (handle_fasteoi_irq+0xcc/0x1c4) [9.625396] [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x3c) [9.638732] [] (generic_handle_irq) from [] (__handle_domain_irq+0x64/0xe0) [9.647827] [] (__handle_domain_irq) from [] (gic_handle_irq+0x40/0x8c) [9.654693] [] (gic_handle_irq) from [] (__irq_svc+0x58/0x78) [9.664367] Exception stack(0xee0cfd80 to 0xee0cfdc8) [9.665130] fd80: ee1ec010 c082f174 00d0 ee6b0800 ee6ae850 ee1ec000 ee1ec010 [9.674835] fda0: ee6b0cc0 00ee fa09c000 0003 ee0cfdd0 c04cd748 c04df4e0 [9.684814] fdc0: 2113 [9.684814] [] (__irq_svc) from [] (devm_clk_get+0x8/0x70) [9.694824] [] (devm_clk_get) from [] (omap_hsmmc_probe+0x2e8/0x9f0) [9.704833] [] (omap_hsmmc_probe) from [] (platform_drv_probe+0x44/0xac) [9.714691] [] (platform_drv_probe) from [] (driver_probe_device+0x1f4/0x2f0) [9.724548] [] (driver_probe_device) from [] (bus_for_each_drv+0x64/0x98) [9.733459] [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x118) [9.734832] [] (__device_attach) from [] (bus_probe_device+0x88/0x90) [9.744812] [] (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x90) [9.760040] [] (deferred_probe_work_func) from [] (process_one_work+0x1a4/0x558) [9.769470] [] (process_one_work) from [] (worker_thread+0x3c/0x514) [9.774688] [] (worker_thread) from [] (kthread+0xd4/0xf0) [9.785614] [] (kthread) from [] (ret_from_fork+0x14/0x24) [9.785614] ---[ end trace 402743bd8cfdde2f ]--- And with the (currently almost useless) l3 interrupt stuff taken out by removing the ti,omap4-l3-noc compatible from omap4.dtsi, we get a real trace that might be of some help to you: [8.440917] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed [8.447418] Unhandled fault: imprecise external abort (0x1406) at 0xbeafaa10 [8.454925] pgd = c0004000 [8.454986] [beafaa10] *pgd=/root/init: line 14: /sys/devices/6800.ocp/4 8098000.spi/spi_master/spi1/spi1[8.461334] Internal error: : 1406 [#1] SMP ARM .2/backlight/acx565akm/brightness: No such file [8.473175] Modules linked in:or directory rtc_twl twl4030_wdt [8.483520] CPU: 1 PID: 66 Comm: kworker/u4:1 Not tainted 4.2.0-next-20150831-2-gf55bad8-dirty #1115 [8.493652] Hardware name: Generic OMAP4 (Flattened Device Tree) [8.498352] Workqueue: deferwq deferred_probe_work_func [8.505493] task: ee5f4f40 ti: ee5f6000 task.ti: ee5f6000 [8.510803] PC is at devm_clk_get+0x8/0x70 [8.514801] LR is at omap_hsmmc_probe+0x2e8/0x9f0 [8.520385] pc : []lr : []psr: 20010013 [8.520385] sp : ee5f7dd0 ip : 0003 fp : fa09c000 [8.532470] r10: 00ee r9 : ee6904c0 r8 : [8.537963] r7 : ee1ec010 r6 : ee1ec000 r5 : ee6e7dd0 r4 : ee69 [8.544769] r3 : r2 : 00d0 r1 : c082f184 r0 : ee1ec010 [8.551666] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [8.559143] Control: 10c5387d Table: ae73804a DAC: 0051 [8.564727] Process kworker/u4:1 (pid: 66, stack limit = 0xee5f6218) [8.571441] Stack: (0xee5f7dd0 to 0xee5f8000) [8.576263] 7dc0: ee69 ee6e7dd0 ee1ec000 c04cd748 [8.584930] 7de0: c09cf8f8 ee1ed270 ee5de150 ee
Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
* Grygorii Strashko [150901 07:36]: > On 09/01/2015 12:14 AM, Tony Lindgren wrote: > > * Tony Lindgren [150831 14:02]: > >> > >> And I must have tested next-20150827 instead of next-20150828. Or > >> else it does not happen on every boot. In any case, I'm now getting > >> the following on next-20150831 most of the time: > >> > >> [9.493133] omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup > >> [9.500274] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed > >> [9.506378] [ cut here ] > >> [9.508941] WARNING: CPU: 0 PID: 6 at drivers/bus/omap_l3_noc.c:147 > >> l3_interrupt_handler+0x224/0x350() > >> [9.520568] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 > >> (Read): Data Access in User mode during Functional access > >> [9.524810] Modules linked in: rtc_twl twl4030_wdt > >> [9.534820] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted > >> 4.2.0-next-20150831-2-gf55bad8 #1113 > >> [9.544830] Hardware name: Generic OMAP4 (Flattened Device Tree) > >> [9.544830] Workqueue: deferwq deferred_probe_work_func > >> [9.554809] [] (unwind_backtrace) from [] > >> (show_stack+0x10/0x14) > >> [9.564819] [] (show_stack) from [] > >> (dump_stack+0x84/0x9c) > >> [9.574829] [] (dump_stack) from [] > >> (warn_slowpath_common+0x78/0xb4) > >> [9.574951] [] (warn_slowpath_common) from [] > >> (warn_slowpath_fmt+0x30/0x40) > >> [9.584686] [] (warn_slowpath_fmt) from [] > >> (l3_interrupt_handler+0x224/0x350) > >> [9.594818] [] (l3_interrupt_handler) from [] > >> (handle_irq_event_percpu+0x44/0x1f0) > >> [9.604827] [] (handle_irq_event_percpu) from [] > >> (handle_irq_event+0x40/0x64) > >> [9.614807] [] (handle_irq_event) from [] > >> (handle_fasteoi_irq+0xcc/0x1c4) > >> [9.625396] [] (handle_fasteoi_irq) from [] > >> (generic_handle_irq+0x28/0x3c) > >> [9.638732] [] (generic_handle_irq) from [] > >> (__handle_domain_irq+0x64/0xe0) > >> [9.647827] [] (__handle_domain_irq) from [] > >> (gic_handle_irq+0x40/0x8c) > >> [9.654693] [] (gic_handle_irq) from [] > >> (__irq_svc+0x58/0x78) > >> [9.664367] Exception stack(0xee0cfd80 to 0xee0cfdc8) > >> [9.665130] fd80: ee1ec010 c082f174 00d0 ee6b0800 ee6ae850 > >> ee1ec000 ee1ec010 > >> [9.674835] fda0: ee6b0cc0 00ee fa09c000 0003 ee0cfdd0 > >> c04cd748 c04df4e0 > >> [9.684814] fdc0: 2113 > >> [9.684814] [] (__irq_svc) from [] > >> (devm_clk_get+0x8/0x70) > >> [9.694824] [] (devm_clk_get) from [] > >> (omap_hsmmc_probe+0x2e8/0x9f0) > >> [9.704833] [] (omap_hsmmc_probe) from [] > >> (platform_drv_probe+0x44/0xac) > >> [9.714691] [] (platform_drv_probe) from [] > >> (driver_probe_device+0x1f4/0x2f0) > >> [9.724548] [] (driver_probe_device) from [] > >> (bus_for_each_drv+0x64/0x98) > >> [9.733459] [] (bus_for_each_drv) from [] > >> (__device_attach+0xb0/0x118) > >> [9.734832] [] (__device_attach) from [] > >> (bus_probe_device+0x88/0x90) > >> [9.744812] [] (bus_probe_device) from [] > >> (deferred_probe_work_func+0x60/0x90) > >> [9.760040] [] (deferred_probe_work_func) from [] > >> (process_one_work+0x1a4/0x558) > >> [9.769470] [] (process_one_work) from [] > >> (worker_thread+0x3c/0x514) > >> [9.774688] [] (worker_thread) from [] > >> (kthread+0xd4/0xf0) > >> [9.785614] [] (kthread) from [] > >> (ret_from_fork+0x14/0x24) > >> [9.785614] ---[ end trace 402743bd8cfdde2f ]--- > > > > And with the (currently almost useless) l3 interrupt stuff taken out by > > removing the ti,omap4-l3-noc compatible from omap4.dtsi, we get a real > > trace that might be of some help to you: > > > > [8.440917] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed > > [8.447418] Unhandled fault: imprecise external abort (0x1406) at > > 0xbeafaa10 > > [8.454925] pgd = c0004000 > > [8.454986] [beafaa10] *pgd=/root/init: line 14: > > /sys/devices/6800.ocp/4 > > 8098000.spi/spi_master/spi1/spi1[8.461334] Internal error: : 1406 [#1] > > SMP ARM > > .2/backlight/acx565akm/brightness: No such file [8.473175] Modules > > linked in:or directory > > rtc_twl twl4030_wdt > > [8.483520] CPU: 1 PID: 66 Comm: kworker/u4:1 Not tainted > > 4.2.0-next-20150831-2-gf55bad8-dirty #1115 > > [8.493652] Hardware name: Generic OMAP4 (Flattened Device Tree) > > [8.498352] Workqueue: deferwq deferred_probe_work_func > > [8.505493] task: ee5f4f40 ti: ee5f6000 task.ti: ee5f6000 > > [8.510803] PC is at devm_clk_get+0x8/0x70 > > [8.514801] LR is at omap_hsmmc_probe+0x2e8/0x9f0 > > [8.520385] pc : []lr : []psr: 20010013 > > [8.520385] sp : ee5f7dd0 ip : 0003 fp : fa09c000 > > [8.532470] r10: 00ee r9 : ee6904c0 r8 : > > [8.537963] r7 : ee1ec010 r6 : ee1ec000 r5 : ee6e7dd0 r4 : ee69 > > [8.544769] r3 : r2 : 00d0 r1 : c082f184 r0 : ee1ec010 > >
Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
On 09/01/2015 12:14 AM, Tony Lindgren wrote: > * Tony Lindgren [150831 14:02]: >> >> And I must have tested next-20150827 instead of next-20150828. Or >> else it does not happen on every boot. In any case, I'm now getting >> the following on next-20150831 most of the time: >> >> [9.493133] omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup >> [9.500274] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed >> [9.506378] [ cut here ] >> [9.508941] WARNING: CPU: 0 PID: 6 at drivers/bus/omap_l3_noc.c:147 >> l3_interrupt_handler+0x224/0x350() >> [9.520568] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 >> (Read): Data Access in User mode during Functional access >> [9.524810] Modules linked in: rtc_twl twl4030_wdt >> [9.534820] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted >> 4.2.0-next-20150831-2-gf55bad8 #1113 >> [9.544830] Hardware name: Generic OMAP4 (Flattened Device Tree) >> [9.544830] Workqueue: deferwq deferred_probe_work_func >> [9.554809] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [9.564819] [] (show_stack) from [] >> (dump_stack+0x84/0x9c) >> [9.574829] [] (dump_stack) from [] >> (warn_slowpath_common+0x78/0xb4) >> [9.574951] [] (warn_slowpath_common) from [] >> (warn_slowpath_fmt+0x30/0x40) >> [9.584686] [] (warn_slowpath_fmt) from [] >> (l3_interrupt_handler+0x224/0x350) >> [9.594818] [] (l3_interrupt_handler) from [] >> (handle_irq_event_percpu+0x44/0x1f0) >> [9.604827] [] (handle_irq_event_percpu) from [] >> (handle_irq_event+0x40/0x64) >> [9.614807] [] (handle_irq_event) from [] >> (handle_fasteoi_irq+0xcc/0x1c4) >> [9.625396] [] (handle_fasteoi_irq) from [] >> (generic_handle_irq+0x28/0x3c) >> [9.638732] [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x64/0xe0) >> [9.647827] [] (__handle_domain_irq) from [] >> (gic_handle_irq+0x40/0x8c) >> [9.654693] [] (gic_handle_irq) from [] >> (__irq_svc+0x58/0x78) >> [9.664367] Exception stack(0xee0cfd80 to 0xee0cfdc8) >> [9.665130] fd80: ee1ec010 c082f174 00d0 ee6b0800 ee6ae850 >> ee1ec000 ee1ec010 >> [9.674835] fda0: ee6b0cc0 00ee fa09c000 0003 ee0cfdd0 >> c04cd748 c04df4e0 >> [9.684814] fdc0: 2113 >> [9.684814] [] (__irq_svc) from [] >> (devm_clk_get+0x8/0x70) >> [9.694824] [] (devm_clk_get) from [] >> (omap_hsmmc_probe+0x2e8/0x9f0) >> [9.704833] [] (omap_hsmmc_probe) from [] >> (platform_drv_probe+0x44/0xac) >> [9.714691] [] (platform_drv_probe) from [] >> (driver_probe_device+0x1f4/0x2f0) >> [9.724548] [] (driver_probe_device) from [] >> (bus_for_each_drv+0x64/0x98) >> [9.733459] [] (bus_for_each_drv) from [] >> (__device_attach+0xb0/0x118) >> [9.734832] [] (__device_attach) from [] >> (bus_probe_device+0x88/0x90) >> [9.744812] [] (bus_probe_device) from [] >> (deferred_probe_work_func+0x60/0x90) >> [9.760040] [] (deferred_probe_work_func) from [] >> (process_one_work+0x1a4/0x558) >> [9.769470] [] (process_one_work) from [] >> (worker_thread+0x3c/0x514) >> [9.774688] [] (worker_thread) from [] >> (kthread+0xd4/0xf0) >> [9.785614] [] (kthread) from [] >> (ret_from_fork+0x14/0x24) >> [9.785614] ---[ end trace 402743bd8cfdde2f ]--- > > And with the (currently almost useless) l3 interrupt stuff taken out by > removing the ti,omap4-l3-noc compatible from omap4.dtsi, we get a real > trace that might be of some help to you: > > [8.440917] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed > [8.447418] Unhandled fault: imprecise external abort (0x1406) at > 0xbeafaa10 > [8.454925] pgd = c0004000 > [8.454986] [beafaa10] *pgd=/root/init: line 14: > /sys/devices/6800.ocp/4 > 8098000.spi/spi_master/spi1/spi1[8.461334] Internal error: : 1406 [#1] > SMP ARM > .2/backlight/acx565akm/brightness: No such file [8.473175] Modules linked > in:or directory > rtc_twl twl4030_wdt > [8.483520] CPU: 1 PID: 66 Comm: kworker/u4:1 Not tainted > 4.2.0-next-20150831-2-gf55bad8-dirty #1115 > [8.493652] Hardware name: Generic OMAP4 (Flattened Device Tree) > [8.498352] Workqueue: deferwq deferred_probe_work_func > [8.505493] task: ee5f4f40 ti: ee5f6000 task.ti: ee5f6000 > [8.510803] PC is at devm_clk_get+0x8/0x70 > [8.514801] LR is at omap_hsmmc_probe+0x2e8/0x9f0 > [8.520385] pc : []lr : []psr: 20010013 > [8.520385] sp : ee5f7dd0 ip : 0003 fp : fa09c000 > [8.532470] r10: 00ee r9 : ee6904c0 r8 : > [8.537963] r7 : ee1ec010 r6 : ee1ec000 r5 : ee6e7dd0 r4 : ee69 > [8.544769] r3 : r2 : 00d0 r1 : c082f184 r0 : ee1ec010 > [8.551666] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > none > [8.559143] Control: 10c5387d Table: ae73804a DAC: 0051 > [8.564727] Process kworker/u4:1 (pid: 66, stack limit = 0xee5f6218) > [8.571441] S
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
Hi,
I think the fix is rather easy here.. See below.
* Kishon Vijay Abraham I [150901 02:43]:
>
> Before commit d919501feffa8715147582c3ffce96fad0c7016f ARM: dts: dra7:
> add minimal l4 bus layout with control module support, the dt was like
>
> ocp {
> dra7_ctrl_general: tisyscon@4a002e00 {
> compatible = "syscon";
> reg = <0x4a002e00 0x7c>;
> };
>
> pbias_regulator: pbias_regulator {
> compatible = "ti,pbias-omap";
> reg = <0 0x4>;
> syscon = <&dra7_ctrl_general>;
> };
> };
Yes the reg = <0 0x4> above is wrong, it's not an offset from the
ocp but from the syscon base.
> But after commit d919501fef, the dt became like this (after a couple of
> fixes)
>
> ocp {
> l4_cfg: l4@4a00 {
> compatible = "ti,dra7-l4-cfg", "simple-bus";
> ranges = <0 0x4a00 0x22c000>;
>
> scm: scm@2000 {
> compatible = "ti,dra7-scm-core", "simple-bus";
> reg = <0x2000 0x2000>;
> ranges = <0 0x2000 0x2000>;
>
> scm_conf: scm_conf@0 {
> compatible = "syscon", "simple-bus";
> reg = <0x0 0x1400>;
> ranges = <0 0x0 0x1400>;
>
> pbias_regulator: pbias_regulator {
> compatible = "ti,pbias-omap";
> reg = <0xe00 0x4>;
> syscon = <&scm_conf>;
> };
> };
> };
> };
> };
And here we properly describe the hardware interconnect layout and
of_ioremap and friends do the right thing. And reg = <0xxe00 0x4>
is correct offset from the scm_conf base.
Why don't you just make reg unused for pbias_regulator since
we already use regmap for this driver?
Then in the pbias driver just define the register offset from
the syscon base? You may need to set it based on the compatible
value, but it's not like it's going to change for SoC.
If we eventually add some API to calculate reg base offset
from the syscon base it's easy to update the driver to use
that.
Cheers,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Antwort: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
> Hi Hannes, Hi Roger, > > On 27/08/15 08:52, Hannes Schmelzer wrote: > > Hi Tony, > > > > Did anyone test this changeset on some AM335x board? > > > > Today I ran into trouble with that because: > > > > The GPMC controller gets reseted on kernel boot due to the missing/removed > HWMOD_INIT_NO_RESET flag. > > > > Primary this should not be a big problem, but on my board (maybe on all > AM335x) the GPMC doesn't behave as described in TRM. > > Especially the GPMC_CONFIG register is not reset to 0h after reset, instead > it holds the value 0xa00 which is very strange because bit 10-31 are reserved. > > > > Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this > causes my system to stall on first access the connected NAND flash because it > never becomes ready due to the wrong wait pin polarity. Maybe others dont't > run into trouble because they may use WAIT0PIN, which one has it's old polarity. > > So nand ready/busy pin is connected to waitpin1 through an inverter on your board? > > On am335x-evm we use waitpin0. Nand ready/busy is directly connected to waitpin0. No there is no inverter between flash and AM335x, the READY_nBUSY line is directly connected to waitpin1. But your sentence brings some good idea to me, i will try to solder some inverter into the READY_nBUSY line on my board and see if the problem appears again. If i'm right in my theory that the value 0xa00 in GPMC_CONFIG register is the problem, the inverter would solve it. You're right am335x-evm uses waitpin0, which one is not affected from this "bug". I have to use waitpin1, because i also have a 2nd ethernet interface connected, and there is waitpin0 uses for collission detect signal from the phy (other pinmux). > For NAND operation read/write wait monitoring must be disabled. > The nand driver uses the WAIT pin purely for Read/Busy signalling. > Unfortunately the existing driver cannot handle anything other than waitpin 0 > for nand for DT boot. for sure ? have a look to omap-gpmc.c at line #90. Here i can see that either can be used. > > I've tried to address this issue here > http://thread.gmane.org/gmane.linux.drivers.devicetree/131076 This is useful if the READY_nBUSY line cannot be connected to the GPMC itself, instead it maybe connected to some other gpio. But it doesn't solve the problem. > > cheers, > -roger best regards, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: DT: cpsw: document missing compatible
On Mon, Aug 31, 2015 at 1:21 AM, Mugunthan V N wrote:
> CPSW driver has multiple compatibles for errata implentations but not
> documented, add necessary documentation.
>
> Signed-off-by: Mugunthan V N
Applied. Thanks.
Rob
> ---
>
> The compatibles are added in the commit 7da1160002f1 ('drivers:
> net: cpsw: add am335x errata workarround for interrutps') which
> is present in linux-next/master
>
> ---
> Documentation/devicetree/bindings/net/cpsw.txt | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
> b/Documentation/devicetree/bindings/net/cpsw.txt
> index 33fe846..a9df21a 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -2,7 +2,11 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
> --
>
> Required properties:
> -- compatible : Should be "ti,cpsw"
> +- compatible : Should be one of the below:-
> + "ti,cpsw" for backward compatible
> + "ti,am335x-cpsw" for AM335x controllers
> + "ti,am4372-cpsw" for AM437x controllers
> + "ti,dra7-cpsw" for DRA7x controllers
> - reg : physical base address and size of the cpsw
> registers map
> - interrupts : property with a value describing the interrupt
> --
> 2.5.0.474.g3a9835b
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] security: device_cgroup: fix RCU lockdep splat
On Tue, Sep 01, 2015 at 11:12:18AM +0200, Sebastian Ott wrote:
> On Mon, 31 Aug 2015, Felipe Balbi wrote:
> > while booting AM437x device, the following splat
> > triggered:
> >
> > [ 12.005238] ===
> > [ 12.009749] [ INFO: suspicious RCU usage. ]
> > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted
> > [ 12.019050] ---
> > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex
> > called without proper synchronization!
> > [ 12.033576] other info that might help us debug this:
> >
> > [ 12.041942] rcu_scheduler_active = 1, debug_locks = 0
> > [ 12.048796] 4 locks held by systemd/1:
> > [ 12.052700] #0: (sb_writers#7){.+.+.+}, at: []
> > __sb_start_write+0x8c/0xb0
> > [ 12.060954] #1: (&of->mutex){+.+.+.}, at: []
> > kernfs_fop_write+0x50/0x1b8
> > [ 12.069085] #2: (s_active#30){.+}, at: []
> > kernfs_fop_write+0x58/0x1b8
> > [ 12.077310] #3: (devcgroup_mutex){+.+...}, at: []
> > devcgroup_access_write+0x20/0x658
> > [ 12.086575] stack backtrace:
> > [ 12.091124] CPU: 0 PID: 1 Comm: systemd Not tainted 4.2.0-next-20150831
> > #1154
> > [ 12.098609] Hardware name: Generic AM43 (Flattened Device Tree)
> > [ 12.104807] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [ 12.112924] [] (show_stack) from []
> > (dump_stack+0x84/0x9c)
> > [ 12.120491] [] (dump_stack) from []
> > (verify_new_ex+0xc4/0xdc)
> > [ 12.128326] [] (verify_new_ex) from []
> > (devcgroup_access_write+0x374/0x658)
> > [ 12.137426] [] (devcgroup_access_write) from []
> > (cgroup_file_write+0x28/0x1bc)
> > [ 12.146796] [] (cgroup_file_write) from []
> > (kernfs_fop_write+0xc0/0x1b8)
> > [ 12.155620] [] (kernfs_fop_write) from []
> > (__vfs_write+0x1c/0xd8)
> > [ 12.163783] [] (__vfs_write) from []
> > (vfs_write+0x90/0x16c)
> > [ 12.171426] [] (vfs_write) from []
> > (SyS_write+0x44/0x9c)
> > [ 12.178806] [] (SyS_write) from []
> > (ret_fast_syscall+0x0/0x1c)
> >
> > Fix it by making sure rcu_read_lock() is held
> > around devcgroup_update_access().
>
> With this patch applied I got the following:
>
> [4.079102] BUG: sleeping function called from invalid context at
> mm/slub.c:1266
> [4.079105] in_atomic(): 0, irqs_disabled(): 0, pid: 1, name: systemd
that didn't trigger here. maybe I didn't have lock debugging enabled.
I'll have a look.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
Hi Hannes,
On 27/08/15 08:52, Hannes Schmelzer wrote:
> Hi Tony,
>
> Did anyone test this changeset on some AM335x board?
>
> Today I ran into trouble with that because:
>
> The GPMC controller gets reseted on kernel boot due to the missing/removed
> HWMOD_INIT_NO_RESET flag.
>
> Primary this should not be a big problem, but on my board (maybe on all
> AM335x) the GPMC doesn't behave as described in TRM.
> Especially the GPMC_CONFIG register is not reset to 0h after reset, instead
> it holds the value 0xa00 which is very strange because bit 10-31 are reserved.
>
> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this
> causes my system to stall on first access the connected NAND flash because it
> never becomes ready due to the wrong wait pin polarity. Maybe others dont't
> run into trouble because they may use WAIT0PIN, which one has it's old
> polarity.
So nand ready/busy pin is connected to waitpin1 through an inverter on your
board?
On am335x-evm we use waitpin0. Nand ready/busy is directly connected to
waitpin0.
For NAND operation read/write wait monitoring must be disabled.
The nand driver uses the WAIT pin purely for Read/Busy signalling.
Unfortunately the existing driver cannot handle anything other than waitpin 0
for nand for DT boot.
I've tried to address this issue here
http://thread.gmane.org/gmane.linux.drivers.devicetree/131076
cheers,
-roger
>
> First approach was simply to write 0x0 to the GPMC_CONFIG register during
> gpmc_probe function.
> It solves the problem.
>
> I also tried to issue some SYSRESET through GPMC registers without success,
> same strange behavior.
>
> What’s your thinking around that?
>
> Best regards,
> Hannes
>
>
> linux-omap-ow...@vger.kernel.org schrieb am 20.05.2015 23:21:03:
>
>> Von: Tony Lindgren
>> An: linux-omap@vger.kernel.org
>> Kopie: linux-arm-ker...@lists.infradead.org, Brian Hutchinson
>> , Paul Walmsley , Roger Quadros
>>
>> Datum: 20.05.2015 23:37
>> Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
>> Gesendet von: linux-omap-ow...@vger.kernel.org
>>
>> We support decoding the bootloader values if DEBUG is defined.
>> But we also need to change the struct omap_hwmod flags to have
>> HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
>> boot. Otherwise just the default timings will be displayed
>> instead of the bootloader configured timings.
>>
>> This also allows us to clean up the various GPMC related
>> hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
>> and HWMOD_INIT_NO_IDLE is not needed.
>>
>> Cc: Brian Hutchinson
>> Cc: Paul Walmsley
>> Cc: Roger Quadros
>> Signed-off-by: Tony Lindgren
>> ---
>> arch/arm/mach-omap2/omap_hwmod.h| 6 ++
>> arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 12 ++--
>> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 3 ++-
>> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++--
>> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 11 ++-
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 4 ++--
>> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 ++
>> drivers/memory/Kconfig | 8
>> drivers/memory/omap-gpmc.c | 6 +++---
>> 9 files changed, 29 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.h
>> b/arch/arm/mach-omap2/omap_hwmod.h
>> index 9611c91..b5d27ec 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.h
>> +++ b/arch/arm/mach-omap2/omap_hwmod.h
>> @@ -109,6 +109,12 @@ extern struct omap_hwmod_sysc_fields
>> omap_hwmod_sysc_type3;
>>
>> #define DEBUG_OMAPUART_FLAGS (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
>>
>> +#ifdef CONFIG_OMAP_GPMC_DEBUG
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS HWMOD_INIT_NO_RESET
>> +#else
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS 0
>> +#endif
>> +
>> #if defined(CONFIG_DEBUG_OMAP2UART1)
>> #undef DEBUG_OMAP2UART1_FLAGS
>> #define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/
>> mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> index 8821b9d..6dcfd03 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> @@ -762,16 +762,8 @@ struct omap_hwmod omap2xxx_gpmc_hwmod = {
>> .name = "gpmc",
>> .class = &omap2xxx_gpmc_hwmod_class,
>> .main_clk = "gpmc_fck",
>> - /*
>> -* XXX HWMOD_INIT_NO_RESET should not be needed for this IP
>> -* block. It is not being added due to any known bugs with
>> -* resetting the GPMC IP block, but rather because any timings
>> -* set by the bootloader are not being correctly programmed by
>> -* the kernel from the board file or DT data.
>> -* HWMOD_INIT_NO_RESET should be removed ASAP.
>> -*/
>> - .flags = (HWMOD_INIT_NO_IDLE | HWMOD
Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
Hi Hannes,
On 27/08/15 08:52, Hannes Schmelzer wrote:
> Hi Tony,
>
> Did anyone test this changeset on some AM335x board?
>
> Today I ran into trouble with that because:
>
> The GPMC controller gets reseted on kernel boot due to the missing/removed
> HWMOD_INIT_NO_RESET flag.
>
> Primary this should not be a big problem, but on my board (maybe on all
> AM335x) the GPMC doesn't behave as described in TRM.
> Especially the GPMC_CONFIG register is not reset to 0h after reset, instead
> it holds the value 0xa00 which is very strange because bit 10-31 are reserved.
>
> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this
> causes my system to stall on first access the connected NAND flash because it
> never becomes ready due to the wrong wait pin polarity. Maybe others dont't
> run into trouble because they may use WAIT0PIN, which one has it's old
> polarity.
So nand ready/busy pin is connected to waitpin1 through an inverter on your
board?
On am335x-evm we use waitpin0. Nand ready/busy is directly connected to
waitpin0.
For NAND operation read/write wait monitoring must be disabled.
The nand driver uses the WAIT pin purely for Read/Busy signalling.
Unfortunately the existing driver cannot handle anything other than waitpin 0
for nand for DT boot.
I've tried to address this issue here
http://thread.gmane.org/gmane.linux.drivers.devicetree/131076
cheers,
-roger
>
> First approach was simply to write 0x0 to the GPMC_CONFIG register during
> gpmc_probe function.
> It solves the problem.
>
> I also tried to issue some SYSRESET through GPMC registers without success,
> same strange behavior.
>
> What’s your thinking around that?
>
> Best regards,
> Hannes
>
>
> linux-omap-ow...@vger.kernel.org schrieb am 20.05.2015 23:21:03:
>
>> Von: Tony Lindgren
>> An: linux-omap@vger.kernel.org
>> Kopie: linux-arm-ker...@lists.infradead.org, Brian Hutchinson
>> , Paul Walmsley , Roger Quadros
>>
>> Datum: 20.05.2015 23:37
>> Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
>> Gesendet von: linux-omap-ow...@vger.kernel.org
>>
>> We support decoding the bootloader values if DEBUG is defined.
>> But we also need to change the struct omap_hwmod flags to have
>> HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
>> boot. Otherwise just the default timings will be displayed
>> instead of the bootloader configured timings.
>>
>> This also allows us to clean up the various GPMC related
>> hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
>> and HWMOD_INIT_NO_IDLE is not needed.
>>
>> Cc: Brian Hutchinson
>> Cc: Paul Walmsley
>> Cc: Roger Quadros
>> Signed-off-by: Tony Lindgren
>> ---
>> arch/arm/mach-omap2/omap_hwmod.h| 6 ++
>> arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 12 ++--
>> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 3 ++-
>> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++--
>> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 11 ++-
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 4 ++--
>> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 ++
>> drivers/memory/Kconfig | 8
>> drivers/memory/omap-gpmc.c | 6 +++---
>> 9 files changed, 29 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.h
>> b/arch/arm/mach-omap2/omap_hwmod.h
>> index 9611c91..b5d27ec 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.h
>> +++ b/arch/arm/mach-omap2/omap_hwmod.h
>> @@ -109,6 +109,12 @@ extern struct omap_hwmod_sysc_fields
>> omap_hwmod_sysc_type3;
>>
>> #define DEBUG_OMAPUART_FLAGS (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
>>
>> +#ifdef CONFIG_OMAP_GPMC_DEBUG
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS HWMOD_INIT_NO_RESET
>> +#else
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS 0
>> +#endif
>> +
>> #if defined(CONFIG_DEBUG_OMAP2UART1)
>> #undef DEBUG_OMAP2UART1_FLAGS
>> #define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/
>> mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> index 8821b9d..6dcfd03 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> @@ -762,16 +762,8 @@ struct omap_hwmod omap2xxx_gpmc_hwmod = {
>> .name = "gpmc",
>> .class = &omap2xxx_gpmc_hwmod_class,
>> .main_clk = "gpmc_fck",
>> - /*
>> -* XXX HWMOD_INIT_NO_RESET should not be needed for this IP
>> -* block. It is not being added due to any known bugs with
>> -* resetting the GPMC IP block, but rather because any timings
>> -* set by the bootloader are not being correctly programmed by
>> -* the kernel from the board file or DT data.
>> -* HWMOD_INIT_NO_RESET should be removed ASAP.
>> -*/
>> - .flags = (HWMOD_INIT_NO_IDLE | HWMOD
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
Now fixed Lee Jones mail address!
On Tuesday 01 September 2015 03:10 PM, Kishon Vijay Abraham I wrote:
> Hi Mark,
>
> On Monday 31 August 2015 08:22 PM, Mark Brown wrote:
>> On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote:
>>> On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
> On 08/19/2015 09:11 PM, Mark Brown wrote:
>>
>> So substract this address from the start of the resource to get the
>> offset? Or provide a wrapper function in the resource code which does
>> that.
> I'd be very appreciated if you have and can share any thought on
> How can we get this absolute base address to substract?
Ask the syscon device for its resource? Or have it provide an absolute
>>>
>>> Even if we get the absolute address of syscon, we have to do the
>>> subtraction only for the newer dtbs (previous dtbs already have only the
>>> offset). Do you recommend adding a new property to differentiate between
>>> older dtbs and newer dtbs? Any other suggestions here?
>>
>> Hang on. This is the first I've heard of any DTs not just having
>> absolute addresses. How does any of this work - has it ever worked, and
>> is the situation completely understood? My original concern with this
>
> Before commit d919501feffa8715147582c3ffce96fad0c7016f ARM: dts: dra7:
> add minimal l4 bus layout with control module support, the dt was like
>
> ocp {
> dra7_ctrl_general: tisyscon@4a002e00 {
> compatible = "syscon";
> reg = <0x4a002e00 0x7c>;
> };
>
> pbias_regulator: pbias_regulator {
> compatible = "ti,pbias-omap";
> reg = <0 0x4>;
> syscon = <&dra7_ctrl_general>;
> };
> };
>
> Here platform_get_resource in pbias driver returns '0' which is
> populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
> the base address from tisyscon@4a002e00 which is '0x4a002e00' and offset
> from enable_reg which is '0' inorder to write to the pbias register.
>
> But after commit d919501fef, the dt became like this (after a couple of
> fixes)
>
> ocp {
> l4_cfg: l4@4a00 {
> compatible = "ti,dra7-l4-cfg", "simple-bus";
> ranges = <0 0x4a00 0x22c000>;
>
> scm: scm@2000 {
> compatible = "ti,dra7-scm-core", "simple-bus";
> reg = <0x2000 0x2000>;
> ranges = <0 0x2000 0x2000>;
>
> scm_conf: scm_conf@0 {
> compatible = "syscon", "simple-bus";
> reg = <0x0 0x1400>;
> ranges = <0 0x0 0x1400>;
>
> pbias_regulator: pbias_regulator {
> compatible = "ti,pbias-omap";
> reg = <0xe00 0x4>;
> syscon = <&scm_conf>;
> };
> };
> };
> };
> };
>
> Here platform_get_resource in pbias driver returns '4a002e00' which is
> populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
> the base address from scm_conf@0 which is '0x4a002000' and offset from
> enable_reg which is '4a002e00' inorder to write to the pbias register
> and it results in a abort.
>
>> was that I coudn't understand the commit log and your original response
>> seemed to indicate that we always have the absolute address :( Perhaps
>
> We started having the absolute address only after the dt change (commit
> d919501fef and a couple of more dt fixes).
>
>> this is something to do with the brief mention of having moved the DT
>> node for some reason?
>>
>> We at least need some sort of coherent explanation of the problem and a
>> comprehensible fix to go with it. Right now it seems like things are
>> just being moved about to hide problems without either of these things
>> which seems like it makes the code less clear and more fragile.
>
> hmm.. IMO the actual problem was modelling the 'offset' as a resource
> (by populating the offset in 'reg' property) which was added when the
> initial pbias dt node was created. And now since the pbias dt node is
> being moved around, it's causing inadvertent address translation
> breaking the pbias driver. IMHO the value in 'reg' property of pbias dt
> node should be treated as 'offset' instead of address 'resource' and
> that's what my patch tried to do.
>>
address based interface for that matter?
>>
>>> Syscon doesn't directly expose any API's to write to it's register.
>>> Rather it uses regmap APIs to read/write to it's register. I'm not sure
>>> if it's possible to add regmap APIs to write to a register with absolute
>>> address. Any hints?
>>
>> Yes, I'm aware that it is regmap based! What I am suggesting is that if
>> people are making DTs like you
[PATCH] ARM: DTS: dra72-evm: remove cpsw gpio hogging and add select-slave-gpio
Since GPIO hogging fails to through error when booting with
gpio-pcf857x as module and NFS root filesystem. So by having
select-slave-gpio, it throw error to user so that the used can
make gpio-pcf857x as inbuilt for NFS. When using mmc/ramdisk as
root fs, cpsw will probe defer and re-probes again when
gpio-pcf857x module is inserted and ethernet becomes operational.
Signed-off-by: Mugunthan V N
---
This patch depends on driver changes [1] and tested on DRA72x, logs [2]
[1]: http://patchwork.ozlabs.org/patch/512783/
[2]: http://pastebin.ubuntu.com/12244652/
---
arch/arm/boot/dts/dra72-evm.dts | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index be9a89b..96d1bd3 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -343,12 +343,6 @@
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
-
- cpsw_sel_s0 {
- gpio-hog;
- gpios = <4 GPIO_ACTIVE_HIGH>;
- output-low;
- };
};
};
@@ -578,6 +572,7 @@
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
slaves = <1>;
+ select-slave-gpio = <&pcf_gpio_21 4 GPIO_ACTIVE_HIGH>;
};
&cpsw_emac0 {
--
2.5.0.474.g3a9835b
--
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
[net-next PATCH] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy
In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.
To solve this issue, introducing "select-slave-gpio" in DT when
gpio based muxing is required. This will through a warning when
vgpio get fails and returns probe defer. When gpio-pcf857x module
is installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk [1]
Signed-off-by: Mugunthan V N
---
This patch is texted on DRA72x, Logs [1] and pushed a branch [2]
[1]: http://pastebin.ubuntu.com/12244652/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git cpsw-gpio-optional
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 +++
drivers/net/ethernet/ti/cpsw.c | 10 ++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 33fe846..cb693aa 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -26,6 +26,9 @@ Optional properties:
- dual_emac: Specifies Switch to act as Dual EMAC
- syscon : Phandle to the system control device node, which is
the control module device of the am33x
+- select-slave-gpio: Should be added if a gpio line is required to
+ select which slave is connected to phy
+
Slave Properties:
Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..ce965ad 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id *of_id;
+ struct gpio_desc*select_slave;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,14 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
+ select_slave = devm_gpiod_get_optional(&pdev->dev, "select-slave",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(select_slave)) {
+ ret = PTR_ERR(select_slave);
+ dev_err(&pdev->dev, "gpio request failed, ret %d\n", ret);
+ goto clean_ndev_ret;
+ }
+
/*
* This may be required here for child devices.
*/
--
2.5.0.474.g3a9835b
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled
On 28/08/15 17:21, Jyri Sarha wrote: > Reconfigure and restart audio when display is enabled, if audio > playback was active before. This is needed in a situation when an > audio+video stream application opens the audio stream before the > video. When video stream is opened the display mode may change and > that aborts audio playback, because the display is momentarily > turned off. > > The audio configuration is stored when it is successfully applied and > a boolean is set when the audio playback is started and unset when > stopped. This data is used to reconfigure the audio when display is > re-enabled. The audio playback is aborted if the reconfiguration fails. > > A new spin lock is introduced in order to protect state variables > related to audio playback status. This is needed for the transition > from display enabled state (when audio start/stop commands can be > written to HW) to display disabled state (when audio start/stop > commands update only the hdmi.audio_playing variable) to always > serialize correctly with the start/stop audio commands. The already > existing mutex can not be used, because the audio start and stop > commands are executed in atomic context. > > For example: when display is turned back on we take the spinlock and > we can be sure that the audio start/stop status will not change while > we update the HW according to hdmi.audio_playing state and set > hdmi.display_enabled to true. After releasing the lock > hdmi.display_enabled is true and all audio_start and audio_stop > commands write their stuff directly to HW. > > Signed-off-by: Jyri Sarha > --- > Fixed one bad sentece in the description. > > drivers/video/fbdev/omap2/dss/hdmi.h | 9 - > drivers/video/fbdev/omap2/dss/hdmi4.c | 66 +- > drivers/video/fbdev/omap2/dss/hdmi5.c | 76 > --- > 3 files changed, 124 insertions(+), 27 deletions(-) Thanks, I've queued this for 4.4. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] security: device_cgroup: fix RCU lockdep splat
On Mon, 31 Aug 2015, Felipe Balbi wrote:
> while booting AM437x device, the following splat
> triggered:
>
> [ 12.005238] ===
> [ 12.009749] [ INFO: suspicious RCU usage. ]
> [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted
> [ 12.019050] ---
> [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex
> called without proper synchronization!
> [ 12.033576] other info that might help us debug this:
>
> [ 12.041942] rcu_scheduler_active = 1, debug_locks = 0
> [ 12.048796] 4 locks held by systemd/1:
> [ 12.052700] #0: (sb_writers#7){.+.+.+}, at: []
> __sb_start_write+0x8c/0xb0
> [ 12.060954] #1: (&of->mutex){+.+.+.}, at: []
> kernfs_fop_write+0x50/0x1b8
> [ 12.069085] #2: (s_active#30){.+}, at: []
> kernfs_fop_write+0x58/0x1b8
> [ 12.077310] #3: (devcgroup_mutex){+.+...}, at: []
> devcgroup_access_write+0x20/0x658
> [ 12.086575] stack backtrace:
> [ 12.091124] CPU: 0 PID: 1 Comm: systemd Not tainted 4.2.0-next-20150831
> #1154
> [ 12.098609] Hardware name: Generic AM43 (Flattened Device Tree)
> [ 12.104807] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 12.112924] [] (show_stack) from []
> (dump_stack+0x84/0x9c)
> [ 12.120491] [] (dump_stack) from []
> (verify_new_ex+0xc4/0xdc)
> [ 12.128326] [] (verify_new_ex) from []
> (devcgroup_access_write+0x374/0x658)
> [ 12.137426] [] (devcgroup_access_write) from []
> (cgroup_file_write+0x28/0x1bc)
> [ 12.146796] [] (cgroup_file_write) from []
> (kernfs_fop_write+0xc0/0x1b8)
> [ 12.155620] [] (kernfs_fop_write) from []
> (__vfs_write+0x1c/0xd8)
> [ 12.163783] [] (__vfs_write) from []
> (vfs_write+0x90/0x16c)
> [ 12.171426] [] (vfs_write) from []
> (SyS_write+0x44/0x9c)
> [ 12.178806] [] (SyS_write) from []
> (ret_fast_syscall+0x0/0x1c)
>
> Fix it by making sure rcu_read_lock() is held
> around devcgroup_update_access().
With this patch applied I got the following:
[4.079102] BUG: sleeping function called from invalid context at
mm/slub.c:1266
[4.079105] in_atomic(): 0, irqs_disabled(): 0, pid: 1, name: systemd
[4.079108] 5 locks held by systemd/1:
[4.079110] #0: (sb_writers#7){.+.+.+}, at: [<002c4450>]
vfs_write+0x180/0x1a8
[4.079120] #1: (&of->mutex){+.+.+.}, at: [<00354d32>]
kernfs_fop_write+0x6a/0x1a0
[4.079127] #2: (s_active#7){.+}, at: [<00354d3e>]
kernfs_fop_write+0x76/0x1a0
[4.079133] #3: (devcgroup_mutex){+.+.+.}, at: [<003f3f7e>]
devcgroup_access_write+0x46/0x7b8
[4.079143] #4: (rcu_read_lock){..}, at: [<003f3f38>]
devcgroup_access_write+0x0/0x7b8
[4.079149] Preemption disabled at:[<001ab52c>]
vprintk_default+0x44/0x58
[4.079155] CPU: 0 PID: 1 Comm: systemd Not tainted
4.2.0-02744-g65a9959-dirty #170
[4.079157]75c079b0 75c07a40 0002
75c07ae0 75c07a58 75c07a58 00113e9e
0089c4f4 0087b700 000b
75c07aa0 75c07a40
00113e9e 75c07a40 75c07aa0
[4.079239] Call Trace:
[4.079242] ([<00113d7e>] show_trace+0xfe/0x160)
[4.079244] [<00113e50>] show_stack+0x70/0xf0
[4.079247] [<006bb184>] dump_stack+0x7c/0xd8
[4.079250] [<00164e42>] ___might_sleep+0x19a/0x268
[4.079255] [<002bbc06>] __kmalloc_track_caller+0x2fe/0x460
[4.079258] [<00275fee>] kmemdup+0x3e/0x68
[4.079260] [<003f3dda>] dev_exception_add+0x4a/0x130
[4.079262] [<003f459e>] devcgroup_access_write+0x666/0x7b8
[4.079265] [<001ea100>] cgroup_file_write+0x50/0x1f0
[4.079267] [<00354e1a>] kernfs_fop_write+0x152/0x1a0
[4.079269] [<002c38f2>] __vfs_write+0x42/0x108
[4.079272] [<002c4362>] vfs_write+0x92/0x1a8
[4.079274] [<002c50fe>] SyS_write+0x66/0xd8
[4.079277] [<006c4f26>] system_call+0xd6/0x258
[4.079279] [<03fffd5cda58>] 0x3fffd5cda58
[4.079281] 5 locks held by systemd/1:
[4.079282] #0: (sb_writers#7){.+.+.+}, at: [<002c4450>]
vfs_write+0x180/0x1a8
[4.079289] #1: (&of->mutex){+.+.+.}, at: [<00354d32>]
kernfs_fop_write+0x6a/0x1a0
[4.079295] #2: (s_active#7){.+}, at: [<00354d3e>]
kernfs_fop_write+0x76/0x1a0
[4.079301] #3: (devcgroup_mutex){+.+.+.}, at: [<003f3f7e>]
devcgroup_access_write+0x46/0x7b8
[4.079307] #4: (rcu_read_lock){..}, at: [<003f3f38>]
devcgroup_access_write+0x0/0x7b8
grep RCU .config
# RCU Subsystem
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# RCU Debugging
CO
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
Hi Mark,
On Monday 31 August 2015 08:22 PM, Mark Brown wrote:
> On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
>>> On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
On 08/19/2015 09:11 PM, Mark Brown wrote:
>
> So substract this address from the start of the resource to get the
> offset? Or provide a wrapper function in the resource code which does
> that.
>>>
I'd be very appreciated if you have and can share any thought on
How can we get this absolute base address to substract?
>>>
>>> Ask the syscon device for its resource? Or have it provide an absolute
>>
>> Even if we get the absolute address of syscon, we have to do the
>> subtraction only for the newer dtbs (previous dtbs already have only the
>> offset). Do you recommend adding a new property to differentiate between
>> older dtbs and newer dtbs? Any other suggestions here?
>
> Hang on. This is the first I've heard of any DTs not just having
> absolute addresses. How does any of this work - has it ever worked, and
> is the situation completely understood? My original concern with this
Before commit d919501feffa8715147582c3ffce96fad0c7016f ARM: dts: dra7:
add minimal l4 bus layout with control module support, the dt was like
ocp {
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = "syscon";
reg = <0x4a002e00 0x7c>;
};
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap";
reg = <0 0x4>;
syscon = <&dra7_ctrl_general>;
};
};
Here platform_get_resource in pbias driver returns '0' which is
populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
the base address from tisyscon@4a002e00 which is '0x4a002e00' and offset
from enable_reg which is '0' inorder to write to the pbias register.
But after commit d919501fef, the dt became like this (after a couple of
fixes)
ocp {
l4_cfg: l4@4a00 {
compatible = "ti,dra7-l4-cfg", "simple-bus";
ranges = <0 0x4a00 0x22c000>;
scm: scm@2000 {
compatible = "ti,dra7-scm-core", "simple-bus";
reg = <0x2000 0x2000>;
ranges = <0 0x2000 0x2000>;
scm_conf: scm_conf@0 {
compatible = "syscon", "simple-bus";
reg = <0x0 0x1400>;
ranges = <0 0x0 0x1400>;
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <&scm_conf>;
};
};
};
};
};
Here platform_get_resource in pbias driver returns '4a002e00' which is
populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
the base address from scm_conf@0 which is '0x4a002000' and offset from
enable_reg which is '4a002e00' inorder to write to the pbias register
and it results in a abort.
> was that I coudn't understand the commit log and your original response
> seemed to indicate that we always have the absolute address :( Perhaps
We started having the absolute address only after the dt change (commit
d919501fef and a couple of more dt fixes).
> this is something to do with the brief mention of having moved the DT
> node for some reason?
>
> We at least need some sort of coherent explanation of the problem and a
> comprehensible fix to go with it. Right now it seems like things are
> just being moved about to hide problems without either of these things
> which seems like it makes the code less clear and more fragile.
hmm.. IMO the actual problem was modelling the 'offset' as a resource
(by populating the offset in 'reg' property) which was added when the
initial pbias dt node was created. And now since the pbias dt node is
being moved around, it's causing inadvertent address translation
breaking the pbias driver. IMHO the value in 'reg' property of pbias dt
node should be treated as 'offset' instead of address 'resource' and
that's what my patch tried to do.
>
>>> address based interface for that matter?
>
>> Syscon doesn't directly expose any API's to write to it's register.
>> Rather it uses regmap APIs to read/write to it's register. I'm not sure
>> if it's possible to add regmap APIs to write to a register with absolute
>> address. Any hints?
>
> Yes, I'm aware that it is regmap based! What I am suggesting is that if
> people are making DTs like yours with devices that are children of the
> syscon then presumably it might be useful for it to allow client drivers
> to pass absolute addresses in so that it can translate for them.
Arnd, Lee?
Thanks
Kishon
--
To unsubscribe
RE: [PATCH 2/3][v2] drivers: usb: dwc3: Add frame length adjustment quirk
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, September 01, 2015 12:51 PM
> To: Badola Nikhil-B46172
> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> o...@vger.kernel.org; ba...@ti.com; gre...@linuxfoundation.org
> Subject: Re: [PATCH 2/3][v2] drivers: usb: dwc3: Add frame length
> adjustment quirk
>
> Hi,
>
> On Mon, Aug 17, 2015 at 09:54:56AM +0530, Nikhil Badola wrote:
> > +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
> > +{
> > + if (dwc->revision < DWC3_REVISION_250A)
> > + return;
> > +
> > + if (fladj == 0)
> > + return;
> > +
> > + if (fladj) {
>
> right here you know fladj to be non-zero.
>
> > @@ -957,6 +990,7 @@ static int dwc3_probe(struct platform_device
> *pdev)
> > goto err1;
> > }
> >
> > +
>
> stray change
>
Will make both changes and send a new version.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3][v2] drivers: usb: dwc3: Add frame length adjustment quirk
Hi,
On Mon, Aug 17, 2015 at 09:54:56AM +0530, Nikhil Badola wrote:
> +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
> +{
> + if (dwc->revision < DWC3_REVISION_250A)
> + return;
> +
> + if (fladj == 0)
> + return;
> +
> + if (fladj) {
right here you know fladj to be non-zero.
> @@ -957,6 +990,7 @@ static int dwc3_probe(struct platform_device *pdev)
> goto err1;
> }
>
> +
stray change
--
balbi
signature.asc
Description: Digital signature
