Re: v3.19-rc1 regression(?) on N900
Hi, On 26/12/14 00:21, Aaro Koskinen wrote: > ...however, I can confirm that framebuffer is broken: > > [8.230743] omapfb omapfb: no displays > [8.255584] omapfb omapfb: failed to setup omapfb > [8.260620] platform omapfb: Driver omapfb requests probe deferral > [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node > '/ocp/spi@48098000/acx565akm@2[0]' - status (0) > [8.284271] acx565akm spi1.2: failed to find video source > [8.290069] spi spi1.2: Driver acx565akm requests probe deferral > > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint > by matching reg-id). When I revert that, also FB works with 3.19-rc1. I've attached a patch for this. Only hack-tested on OMAP3 beagle, so please report if it works. Tomi From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Mon, 29 Dec 2014 09:57:11 +0200 Subject: [PATCH] OMAPDSS: SDI: fix output port_num After the commit ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by matching reg-id) we look for the SDI output using the port number. However, the SDI driver doesn't set the port number, which causes the SDI display to not initialize. Fix this by setting the SDI port number to 1. We use a hardcoded value, as SDI was used only on OMAP3 and it's always port number 1 there. Reported-by: Aaro Koskinen Reported-by: Pavel Machek Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/sdi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c index d51a983075bc..5c2ccab5a958 100644 --- a/drivers/video/fbdev/omap2/dss/sdi.c +++ b/drivers/video/fbdev/omap2/dss/sdi.c @@ -342,6 +342,8 @@ static void sdi_init_output(struct platform_device *pdev) out->output_type = OMAP_DISPLAY_TYPE_SDI; out->name = "sdi.0"; out->dispc_channel = OMAP_DSS_CHANNEL_LCD; + /* We have SDI only on OMAP3, where it's on port 1 */ + out->port_num = 1; out->ops.sdi = &sdi_ops; out->owner = THIS_MODULE; -- 2.2.1 signature.asc Description: OpenPGP digital signature
Re: am335x: cpsw: interrupt failure
On Fri, Dec 12, 2014 at 8:19 PM, Yegor Yefremov wrote: > On Fri, Dec 12, 2014 at 6:32 PM, Felipe Balbi wrote: >> Hi, >> >> On Fri, Dec 12, 2014 at 01:00:51PM +0100, Yegor Yefremov wrote: >>> U-Boot version: 2014.07 >>> Kernel config is omap2plus with enabled USB >>> >>> # cat /proc/version >>> Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 >>> 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP >>> Mon Dec 8 22:47:43 CET 2014 >> >> Wasn't GCC 4.8.x total crap for building ARM kernels ? IIRC it was even >> blacklisted. Can you try with 4.9.x just to make sure ? > > Will do. Adding linux-omap. Beginning of this discussion: http://comments.gmane.org/gmane.linux.network/341427 Quick summary: starting with kernel 3.18 or commit 55601c9f24670ba926ebdd4d712ac3b177232330 am335x (at least BBB and some custom boards) stalls at high network load. Reproducible via nuttcp within some minutes nuttcp -S (on BBB) nuttcp -t -N 4 -T30m 192.168.1.235 (on host) As Felipe Balbi suggested, I tried both 4.8.3 and 4.9.2 toolchains, but both show the same behavior. Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP Mon Dec 8 22:47:43 CET 2014 Linux version 3.18.1 (user@user-VirtualBox) (gcc version 4.9.2 (Buildroot 2015.02-git-00582-g10b9761) ) #1 SMP Mon Dec 29 09:22:29 CET 2014 Let me know, if you can reproduce this issue. Thanks. Yegor -- 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+: hwmod: print error if wait_target_ready() failed
On 19/12/14 14:34, Lokesh Vutla wrote: > Fixed pr_debug to pr_err when hwmod returns an error when enabling > a module. > > Signed-off-by: Lokesh Vutla Acked-by: Roger Quadros cheers, -roger -- 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/2] phy: ti-pipe3: Fix SATA across suspend/resume
On 22/12/14 15:52, Kishon Vijay Abraham I wrote:
> Hi Roger,
>
> On Friday 19 December 2014 05:35 PM, Roger Quadros wrote:
>> Failed test case: Boot without SATA drive connected. Suspend/resume
>> the board and then connect SATA drive. It fails to enumerate.
>>
>> Due to Errata i783 "SATA Lockup After SATA DPLL Unlock/Relock"
>> we can't allow SATA DPLL to be in the unlocked state.
>> The SATA refclk (sata_ref_clk) is the source of the SATA_DPLL.
>> Till now this clock was controlled by the AHCI SATA driver and was being
>> shut off during system suspend (if the SATA drive was not already attached)
>> causing the SATA DPLL to be unlocked and so causing errata i783.
>>
>> To prevent sata_ref_clk from being disabled, we move the control of
>> this clock from the SATA AHCI driver to the SATA PHY driver and prevent
>> it from being disabled.
>>
>> This also fixes the issue of SATA not working on OMAP5/DRA7 when
>> AHCI platform driver is built as a module.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/boot/dts/dra7.dtsi | 4 ++--
>> arch/arm/boot/dts/omap5.dtsi | 4 ++--
>> drivers/phy/phy-ti-pipe3.c | 53
>> +++-
>> 3 files changed, 41 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 63bf99b..8c35b84 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -1090,8 +1090,8 @@
>><0x4A096800 0x40>; /* pll_ctrl */
>> reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> ctrl-module = <&omap_control_sata>;
>> -clocks = <&sys_clkin1>;
>> -clock-names = "sysclk";
>> +clocks = <&sys_clkin1>, <&sata_ref_clk>;
>> +clock-names = "sysclk", "refclk";
>> #phy-cells = <0>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index b321fdf..bb498e7 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -929,8 +929,8 @@
>><0x4A096800 0x40>; /* pll_ctrl */
>> reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> ctrl-module = <&omap_control_sata>;
>> -clocks = <&sys_clkin>;
>> -clock-names = "sysclk";
>> +clocks = <&sys_clkin>, <&sata_ref_clk>;
>> +clock-names = "sysclk", "refclk";
>> #phy-cells = <0>;
>> };
>> };
>> diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
>> index e60ff14..e08edd9 100644
>> --- a/drivers/phy/phy-ti-pipe3.c
>> +++ b/drivers/phy/phy-ti-pipe3.c
>> @@ -85,6 +85,7 @@ struct ti_pipe3 {
>> struct pipe3_dpll_map *dpll_map;
>> u8 id;
>> bool enabled;
>> +bool refclk_enabled;/* this flag is needed specifically for SATA */
>> spinlock_t lock;/* serialize clock enable/disable */
>> };
>>
>> @@ -333,21 +334,20 @@ static int ti_pipe3_probe(struct platform_device *pdev)
>> }
>> }
>>
>> +phy->refclk = devm_clk_get(phy->dev, "refclk");
>> +if (IS_ERR(phy->refclk)) {
>> +dev_err(&pdev->dev, "unable to get refclk\n");
>> +return PTR_ERR(phy->refclk);
>> +}
>
> This will break older dtbs. AFAIK, newer kernels should be compatible with
> older dtbs too. cc'ed devicet...@vger.kernel.org for clarification.
If I make refclk optional that still leaves SATA broken on older dtbs. Wouldn't
it be better to fix the DTBs via stable instead?
cheers,
-roger
--
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: dts: cm-t3x: add NAND support
Hi Dmitry,
On 28/12/14 16:30, Dmitry Lifshitz wrote:
> CM-T3517, CM-T3530 and CM-T3730 features NAND storage chip connected to
> GPMC bus.
>
> Add GPMC DT entry into the root DT file omap3-cm-t3x.dtsi, common for
> all three modules.
>
> NAND timings are calculated to be safe for CM-T3x devices as it works
> now in non DT boot (in this case the timings are updated by U-Boot).
I didn't get this part. You provide the GPMC timings in the DT now so they will
override
u-boot configured timings.
>
> Update GPMC ranges in boards DT files to include all connected devices.
>
> Signed-off-by: Dmitry Lifshitz
> ---
>
> v2 * Update GPMC ranges with NAND values in omap3-cm-t3x30.dtsi.
>* Add commit message details
>
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 58
> +
> arch/arm/boot/dts/omap3-cm-t3x30.dtsi |3 +-
> arch/arm/boot/dts/omap3-sbc-t3517.dts |4 ++
> arch/arm/boot/dts/omap3-sbc-t3530.dts | 10 ++
> arch/arm/boot/dts/omap3-sbc-t3730.dts |5 ++-
> 5 files changed, 70 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> index 6ea6d46..4d091ca 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> +++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> @@ -259,3 +259,61 @@
> pinctrl-names = "default";
> pinctrl-0 = <&mcbsp2_pins>;
> };
> +
> +&gpmc {
> + ranges = <0 0 0x 0x0100>;
Isn't this ranges property redundant as it will be overridden by the board
specific dts?
> +
> + nand@0,0 {
> + reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
> + nand-bus-width = <8>;
> + gpmc,device-width = <1>;
> + ti,nand-ecc-opt = "sw";
any particular reason for sticking with "sw"? Isn't it better to use at least
"ham1"
or migrate to stronger schemes like "bch4" or "bch8"?
"ham1" scheme is compatible with ROM loader so the boot partition could be
flashed from Linux.
For bch4/8 you will have to keep boot partition/s locked from Linux access as
we don't yet
support mixed ECC schemes among partitions.
> +
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <120>;
> + gpmc,cs-wr-off-ns = <120>;
> +
> + gpmc,adv-on-ns = <0>;
> + gpmc,adv-rd-off-ns = <120>;
> + gpmc,adv-wr-off-ns = <120>;
> +
> + gpmc,we-on-ns = <6>;
> + gpmc,we-off-ns = <90>;
> +
> + gpmc,oe-on-ns = <6>;
> + gpmc,oe-off-ns = <90>;
> +
> + gpmc,page-burst-access-ns = <6>;
> + gpmc,access-ns = <72>;
> + gpmc,cycle2cycle-delay-ns = <60>;
> +
> + gpmc,rd-cycle-ns = <120>;
> + gpmc,wr-cycle-ns = <120>;
> + gpmc,wr-access-ns = <186>;
> + gpmc,wr-data-mux-bus-ns = <90>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "xloader";
> + reg = <0 0x8>;
> + };
> + partition@0x8 {
> + label = "uboot";
> + reg = <0x8 0x1e>;
> + };
> + partition@0x26 {
> + label = "uboot environment";
> + reg = <0x26 0x4>;
> + };
> + partition@0x2a {
> + label = "linux";
> + reg = <0x2a 0x40>;
> + };
> + partition@0x6a {
> + label = "rootfs";
> + reg = <0x6a 0x1f88>;
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
> b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
> index 9a4a3ab..d9e92b6 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
> +++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
> @@ -50,7 +50,8 @@
> #include "omap-gpmc-smsc911x.dtsi"
>
> &gpmc {
> - ranges = <5 0 0x2c00 0x0100>;
> + ranges = <5 0 0x2c00 0x0100>, /* CM-T3x30 SMSC9x Eth */
> + <0 0 0x 0x0100>; /* CM-T3x NAND */
Isn't this ranges property redundant as it will anyways be overridden by the
board specific dts?
>
> smsc1: ethernet@gpmc {
> compatible = "smsc,lan9221", "smsc,lan9115";
> diff --git a/arch/arm/boot/dts/omap3-sbc-t3517.dts
> b/arch/arm/boot/dts/omap3-sbc-t3517.dts
> index 1798653..c2d5c28 100644
> --- a/arch/arm/boot/dts/omap3-sbc-t3517.dts
> +++ b/arch/arm/boot/dts/omap3-sbc-t3517.dts
> @@ -69,3 +69,7 @@
> };
> };
>
> +&gpmc {
> + ranges = <4 0 0x2d00 0x0100>, /* SB-T35 SMSC9x Eth */
> + <0 0 0x 0x0100>; /* CM-T3x NAND */
> +};
> diff --git a/arch/arm/boot/dts/omap3-sbc-t3530.dts
> b/arch/arm/boot/dts/omap3-sbc-t3530.dts
> index c994f0f..834bc78 100644
> --- a/arch/arm/boot/dts/omap3-sbc-t3530.dts
> +++ b/arch/arm/boot/dts/omap3-sbc-t3
Re: am335x: cpsw: interrupt failure
On 12/29/2014 04:33 AM, Yegor Yefremov wrote: > On Fri, Dec 12, 2014 at 8:19 PM, Yegor Yefremov > wrote: >> On Fri, Dec 12, 2014 at 6:32 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Fri, Dec 12, 2014 at 01:00:51PM +0100, Yegor Yefremov wrote: U-Boot version: 2014.07 Kernel config is omap2plus with enabled USB # cat /proc/version Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP Mon Dec 8 22:47:43 CET 2014 >>> >>> Wasn't GCC 4.8.x total crap for building ARM kernels ? IIRC it was even >>> blacklisted. Can you try with 4.9.x just to make sure ? >> >> Will do. > > Adding linux-omap. Beginning of this discussion: > http://comments.gmane.org/gmane.linux.network/341427 > > Quick summary: starting with kernel 3.18 or commit > 55601c9f24670ba926ebdd4d712ac3b177232330 am335x (at least BBB and some > custom boards) stalls at high network load. Reproducible via nuttcp > within some minutes > > nuttcp -S (on BBB) > nuttcp -t -N 4 -T30m 192.168.1.235 (on host) > > As Felipe Balbi suggested, I tried both 4.8.3 and 4.9.2 toolchains, > but both show the same behavior. > > Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > Mon Dec 8 22:47:43 CET 2014 > Linux version 3.18.1 (user@user-VirtualBox) (gcc version 4.9.2 > (Buildroot 2015.02-git-00582-g10b9761) ) #1 SMP Mon Dec 29 09:22:29 > CET 2014 > > Let me know, if you can reproduce this issue. I have seen the irq 0 error messages on the black since 3.18+, but didn't bisect it yet. For me, these errors occurred with a slightly misconfigured emacs24-nox, which drove the cpu load way up - over 50% - with just cursor movement (it still gets above 20% which seems unacceptably high). I'm not sure if all the crashes were over ssh; I hadn't considered the cpsw relevant until reading this. I'll retest over the serial console. I have seen abrupt resets without messages on earlier kernels so perhaps the commit is not the root cause. Regards, Peter Hurley -- 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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface
On 20:34-20141228, Tomasz Figa wrote: > May I ask you (or anyone else working on OMAP) to try to figure out > what the issue is? It is stopping L2 cache support for Exynos4 being http://slexy.org/view/s2BnzxVglj Took a register dump and compared -> Got the same dump http://slexy.org/view/s21YRHpzeW . Basically, this implies: possible sequence change broke AM437x or some secure function call (which i have'nt dumped). Is it possible to break up this patch into easier patches? -- Regards, Nishanth Menon -- 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: am335x: cpsw: interrupt failure
On Mon, Dec 29, 2014 at 10:33:26AM +0100, Yegor Yefremov wrote: > On Fri, Dec 12, 2014 at 8:19 PM, Yegor Yefremov > wrote: > > On Fri, Dec 12, 2014 at 6:32 PM, Felipe Balbi wrote: > >> Hi, > >> > >> On Fri, Dec 12, 2014 at 01:00:51PM +0100, Yegor Yefremov wrote: > >>> U-Boot version: 2014.07 > >>> Kernel config is omap2plus with enabled USB > >>> > >>> # cat /proc/version > >>> Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > >>> 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > >>> Mon Dec 8 22:47:43 CET 2014 > >> > >> Wasn't GCC 4.8.x total crap for building ARM kernels ? IIRC it was even > >> blacklisted. Can you try with 4.9.x just to make sure ? > > > > Will do. > > Adding linux-omap. Beginning of this discussion: > http://comments.gmane.org/gmane.linux.network/341427 > > Quick summary: starting with kernel 3.18 or commit > 55601c9f24670ba926ebdd4d712ac3b177232330 am335x (at least BBB and some > custom boards) stalls at high network load. Reproducible via nuttcp > within some minutes > > nuttcp -S (on BBB) > nuttcp -t -N 4 -T30m 192.168.1.235 (on host) > > As Felipe Balbi suggested, I tried both 4.8.3 and 4.9.2 toolchains, > but both show the same behavior. > > Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > Mon Dec 8 22:47:43 CET 2014 > Linux version 3.18.1 (user@user-VirtualBox) (gcc version 4.9.2 > (Buildroot 2015.02-git-00582-g10b9761) ) #1 SMP Mon Dec 29 09:22:29 > CET 2014 > > Let me know, if you can reproduce this issue. finally managed to reproduce this, it took quite a bit of effort though. I'll see if I can gether more information about the problem. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Hi,
On Mon, Dec 29, 2014 at 04:07:50PM +0800, Sneeker Yeh wrote:
> Hi,
>
> 2014-12-29 14:41 GMT+08:00 Sneeker Yeh :
>
> > Hi,
> >
> > 2014-12-22 23:37 GMT+08:00 Felipe Balbi :
> >
> >> On Tue, Dec 16, 2014 at 10:10:28AM +0800, Sneeker Yeh wrote:
> >> > Synopsis DesignWare USB3 IP Core integrated with a config-free
> >> > phy needs special handling during device disconnection to avoid
> >> > the host controller dying.
> >> >
> >> > This quirk makes sure PORT_CSC is cleared after the disable slot
> >> > command when usb device is disconnected from internal root hub,
> >> > otherwise, Synopsis core would fall into a state that cannot use
> >> > any endpoint command. Consequently, device disconnection procedure
> >> > might not be finished because sometimes endpoint need to be stop
> >> > by endpoint stop command issuing.
> >> >
> >> > Symptom usually happens when disconnected device is keyboard,
> >> > mouse, and hub.
> >>
> >> you need to point us to the synopsys STARS ticket number. That's the
> >> only way to reference this specific quirk. Add it to a comment
> >> somewhere.
> >>
> >
> > Thanks, we're still waiting for Synopsis STARS ticket number.
> > I'll add it to comment later.
> >
> >
> Sorry I didn't express myself clearly.
>
> So far Fujitsu Semiconductor got Synopsys internal case id , that is "
> Case: 8000679552".
> However the contents belongs this id cannot be referred except Fujitsu
> Semiconductor and Synopsys.
> Synopsis decide the official errata (STAR information) will be disclosed
> next February.
>
> Would you suggest if this quirk can be accepted with this case ID, or can
> only be accepted with STARS ticket number?
The thing is that without the STARS number I can't really verify which
versions of the IP would be affected. Clearly, it's not only your setup
and I think it's pretty unfair to have "is_compatible("fujitsu")" to
enable the quirk only for you. Isn't there a better way of enabling the
quirk based off of revision detection couple with a look on GHWPARAMS*
registers ?
What's tricking me is this claim that only config-free PHYs would be
affected, why ?
I still have many questions about this patch which are not answered by
commit log nor can I poke around on Synopsys solvnet for answers :-s
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer
Hi,
On Mon, Dec 29, 2014 at 01:52:04AM +0800, Sneeker Yeh wrote:
> Hi,
>
> 2014-12-22 23:59 GMT+08:00 Felipe Balbi :
>
> > Hi,
> >
> > On Tue, Dec 16, 2014 at 10:10:27AM +0800, Sneeker Yeh wrote:
> > > This patch adds support for Synopsis DesignWare USB3 IP Core found
> > > on Fujitsu Socs.
> > >
> > > Signed-off-by: Sneeker Yeh
> > > ---
> > > .../devicetree/bindings/usb/fujitsu-dwc3.txt | 25 +++
> > > drivers/usb/dwc3/Kconfig | 11 ++
> > > drivers/usb/dwc3/Makefile |1 +
> > > drivers/usb/dwc3/dwc3-mb86s70.c| 194
> >
> > > 4 files changed, 231 insertions(+)
> > > create mode 100644
> > Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
> > > create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
> > b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
> > > new file mode 100644
> > > index 000..df77f91
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
> > > @@ -0,0 +1,25 @@
> > > +FUJITSU GLUE COMPONENTS
> > > +
> > > +MB86S7x DWC3 GLUE
> > > + - compatible : Should be "fujitsu,mb86s70-dwc3"
> > > + - clocks: from common clock binding, handle to usb clock.
> > > + - clock-names: from common clock binding.
> > > + - #address-cells, #size-cells : Must be present if the device has
> > sub-nodes
> > > + - ranges: the child address space are mapped 1:1 onto the parent
> > address space
> > > + - #stream-id-cells : handle to use "arm,mmu-400" ARM IOMMU driver
> > > +
> > > +Sub-nodes:
> > > +The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
> > > +- dwc3 :
> > > + The binding details of dwc3 can be found in:
> > > + Documentation/devicetree/bindings/usb/dwc3.txt
> > > +
> > > +usb3host: mb86s70_usb3host {
> > > + compatible = "fujitsu,mb86s70-dwc3";
> > > + clocks = <&clk_alw_1_1>;
> > > + clock-names = "bus_clk";
> > > + #address-cells = <2>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > + #stream-id-cells = <0>;
> > > +};
> > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> > > index 58b5b2c..3390d42 100644
> > > --- a/drivers/usb/dwc3/Kconfig
> > > +++ b/drivers/usb/dwc3/Kconfig
> > > @@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
> > > Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
> > > say 'Y' or 'M' if you have one such device.
> > >
> > > +config USB_DWC3_MB86S70
> > > + tristate "MB86S70 Designware USB3 Platform code"
> > > + default USB_DWC3
> > > + help
> > > + MB86S7X SOC ship with DesignWare Core USB3 IP inside,
> > > + this implementation also integrated Fujitsu USB PHY inside
> > > + this Core USB3 IP.
> > > +
> > > + say 'Y' or 'M' if you have one such device.
> > > +
> > > +
> > > config USB_DWC3_PCI
> > > tristate "PCIe-based Platforms"
> > > depends on PCI
> > > diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> > > index bb34fbc..05d1de2 100644
> > > --- a/drivers/usb/dwc3/Makefile
> > > +++ b/drivers/usb/dwc3/Makefile
> > > @@ -38,3 +38,4 @@ obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> > > obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
> > > obj-$(CONFIG_USB_DWC3_QCOM) += dwc3-qcom.o
> > > obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
> > > +obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
> > > diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c
> > b/drivers/usb/dwc3/dwc3-mb86s70.c
> > > new file mode 100644
> > > index 000..241c5bd
> > > --- /dev/null
> > > +++ b/drivers/usb/dwc3/dwc3-mb86s70.c
> > > @@ -0,0 +1,194 @@
> > > +/**
> > > + * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
> > > + *
> > > + * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
> > > + * http://jp.fujitsu.com/group/fsl
> > > + *
> > > + * Author: Alice Chan
> > > + * based on dwc3-exynos.c
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +struct dwc3_mb86s70 {
> > > + struct device *dev;
> > > + struct clk **clk_table;
> >
> > please align these.
>
>
> okay.
>
>
> >
>
>
> > > +};
> > > +
> > > +/* return 0 means successful */
> >
> > this comment is unnecessary :-)
> >
>
> okay
>
>
> >
> > > +static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
> > > +{
> > > + int ret, i;
> > > + struct clk *clk;
> > > +
> > > + if (!on)
> > > + go
Re: am335x: cpsw: interrupt failure
* Felipe Balbi [141229 07:53]: > On Mon, Dec 29, 2014 at 10:33:26AM +0100, Yegor Yefremov wrote: > > On Fri, Dec 12, 2014 at 8:19 PM, Yegor Yefremov > > wrote: > > > On Fri, Dec 12, 2014 at 6:32 PM, Felipe Balbi wrote: > > >> Hi, > > >> > > >> On Fri, Dec 12, 2014 at 01:00:51PM +0100, Yegor Yefremov wrote: > > >>> U-Boot version: 2014.07 > > >>> Kernel config is omap2plus with enabled USB > > >>> > > >>> # cat /proc/version > > >>> Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > > >>> 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > > >>> Mon Dec 8 22:47:43 CET 2014 > > >> > > >> Wasn't GCC 4.8.x total crap for building ARM kernels ? IIRC it was even > > >> blacklisted. Can you try with 4.9.x just to make sure ? > > > > > > Will do. > > > > Adding linux-omap. Beginning of this discussion: > > http://comments.gmane.org/gmane.linux.network/341427 > > > > Quick summary: starting with kernel 3.18 or commit > > 55601c9f24670ba926ebdd4d712ac3b177232330 am335x (at least BBB and some > > custom boards) stalls at high network load. Reproducible via nuttcp > > within some minutes > > > > nuttcp -S (on BBB) > > nuttcp -t -N 4 -T30m 192.168.1.235 (on host) > > > > As Felipe Balbi suggested, I tried both 4.8.3 and 4.9.2 toolchains, > > but both show the same behavior. > > > > Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > > 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > > Mon Dec 8 22:47:43 CET 2014 > > Linux version 3.18.1 (user@user-VirtualBox) (gcc version 4.9.2 > > (Buildroot 2015.02-git-00582-g10b9761) ) #1 SMP Mon Dec 29 09:22:29 > > CET 2014 > > > > Let me know, if you can reproduce this issue. > > finally managed to reproduce this, it took quite a bit of effort though. > I'll see if I can gether more information about the problem. Maybe check if the irqnr is 127 (or the last reserved interrupt) in irq-omap-intc.c. If so, also print out the previous interrupt. It seems the intc uses the last reserved interrupt to signal a spurious interrupt for the previous irqnr, so we should probably add some handling for that. If the previous interrupt is a cpsw interrupt, then there's probably something wrong with cpsw interrupt handling. Either a missing read-back to flush posted write in the cpsw interrupt handler, or the EOI registers are written at a wrong time. 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 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
Hi,
On Mon, Dec 29, 2014 at 12:05:57PM +0530, Amit Virdi wrote:
> >> >> When SG is used, there are two loops iterating to prepare TRBs:
> >> >> - Outer loop over the request_list
> >> >> - Inner loop over the SG list
> >> >>
> >> >> The driver must stop preparing TRBs when the max TRBs have been
> >> >> prepared. The
> >> >> code was missing break to get out of the outer loop.
> >> >>
> >> >> Signed-off-by: Amit Virdi
> >> >
> >> > which bug is this fixing ? Which kernels are affected ? This need to be
> >> > backported to which kernel ? Which commit introduced this bug ? How can
> >> > I validate this to be a valid fix ?
> >> >
> >>
> >> Problem description:
> >> DWC3 gadget sets up a pool of 32 TRBs for each EP during
> >> initialization. This means, the max TRBs that can be submitted for an
> >> EP is fixed to 32. Since the request queue for an EP is a linked list,
> >> any number of requests can be queued to it by the gadget layer.
> >> However, the dwc3 driver must not submit TRBs more than the pool it
> >> has created for. This limit wasn't respected when SG was used
> >> resulting in submitting more than the max TRBs, eventually leading to
> >> non-transfer of the TRBs submitted over the max limit.
> >
> > this would become a much, much better commit log than the one you
> > provided. It's a much more verbose description of the issue.
>
> Okay, I'll edit the commit message.
thanks
> >> Commit that introduced this bug:
> >> This bug is present from the day support for sg list was added to dwc3
> >> gadget., i.e. since commit eeb720fb21d61dfc3aac780e721150998ef603af
> >> ("usb: dwc3: gadget: add support for SG lists") - kernel version
> >> v3.2-rc7, hence v3.2
> >>
> >> Kernels affected:
> >> It is best to backport this fix to kernel v3.8+ as there were many
> >> enhancements/bug fixes from v3.2..v3.8
> >>
> >> Generic setup to reproduce/test this fix:
> >> This bug is reproduced whenever the number of TRBs that need to be
> >> submitted to the hardware from the software queue (request_list)
> >> becomes more than 32 on bulk endpoint. eg. if num_mapped_sgs is 2 and
> >> the request_list has 17 entries (hence, 34 potential TRBs), the
> >> scenario is reproduced.
> >>
> >> My setup details:
> >> For reproducing and testing the patches [1/4 and 2/4], I used an
> >> inhouse developed user space application that run on device side. This
> >> user space application interacts with the customized uvc webcam gadget
> >> to submit the video data to the DWC3 driver. The host side was running
> >> standard webcam application (cheese).
> >
> > oh, so this is something I can't easily reproduce myself. Then I'll need
> > full boot logs, register dump and full trace output of dwc3 running and
> > exhibiting the problem. Also, make sure you use either v3.18 or v3.19rc1
> > to validate your changes.
> >
>
> [Quoting you from the thread of patch 1/4]
>
> >> endpoint. Following is the log snippet once this bug is reproduced:
> >>
> >> dwc3 dwc3.0: ep2in-bulk: Transfer Not Ready
> >> dwc3 dwc3.0: queing request 24cc5780 to ep2in-bulk length 960002
> >> dwc3 dwc3.0: ep2in-bulk: req 24cc5780 dma 24eb6400 length 2 chain
> >> dwc3 dwc3.0: ep2in-bulk: req 24cc5780 dma 25901800 length 96
> >> dwc3 dwc3.0: queing request 24cc5000 to ep2in-bulk length 960002
> >> dwc3 dwc3.0: ep2in-bulk: Transfer Not Ready
> >> dwc3 dwc3.0: queing request 24cc5900 to ep2in-bulk length 960002
> >> -
> >>
> >> Without this fix, the hardware never generates "Transfer Complete"
> >> event for the corresponding EP and goes into an unknown state.
> >
> > whiuch kernel are you using to develop this ? Most of these messages
> > don't exist anymore with v3.19-rc because I have converted them into
> > tracepoints, considering you're showing me logs with these messages,
> > this tells me that you're sending me a patch developed/tested against a
> > kernel older than v3.18. I need to see full bootup logs, a register dump
> > (/sys/kernel/debug/*dwc3*/regdump) and a much larger debugging log from
> > dwc3 in order to accept patches from you. Sorry, but I cannot take
> > patches which were not tested against, at a minimum, the latest major
> > release.
> >
>
> Yes you're right that both the fixes [1/4] and [2/4] have only been
> build tested with the latest kernel. I should have mentioned this
> information in the commit message or the cover-letter itself.
yeah, you should've :-)
> The only reason why I have not been able to test these fixes on the
> latest is because the customized webcam gadget is not ported on the
> latest kernel. There have been a lot of changes in the video framework
> lately and that is not my area of expertise. So porting the customized
> webcam gadget to latest kernel and testing these fixes is not feasible
> for me.
right, so while I can see that both patches are very minimal and likely
to be correct, I have no way of guaranteeing that. The only thing I can
do, is run the tests which I already run (none of w
Re: am335x: cpsw: interrupt failure
On Mon, Dec 29, 2014 at 08:51:04AM -0800, Tony Lindgren wrote: > * Felipe Balbi [141229 07:53]: > > On Mon, Dec 29, 2014 at 10:33:26AM +0100, Yegor Yefremov wrote: > > > On Fri, Dec 12, 2014 at 8:19 PM, Yegor Yefremov > > > wrote: > > > > On Fri, Dec 12, 2014 at 6:32 PM, Felipe Balbi wrote: > > > >> Hi, > > > >> > > > >> On Fri, Dec 12, 2014 at 01:00:51PM +0100, Yegor Yefremov wrote: > > > >>> U-Boot version: 2014.07 > > > >>> Kernel config is omap2plus with enabled USB > > > >>> > > > >>> # cat /proc/version > > > >>> Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > > > >>> 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > > > >>> Mon Dec 8 22:47:43 CET 2014 > > > >> > > > >> Wasn't GCC 4.8.x total crap for building ARM kernels ? IIRC it was even > > > >> blacklisted. Can you try with 4.9.x just to make sure ? > > > > > > > > Will do. > > > > > > Adding linux-omap. Beginning of this discussion: > > > http://comments.gmane.org/gmane.linux.network/341427 > > > > > > Quick summary: starting with kernel 3.18 or commit > > > 55601c9f24670ba926ebdd4d712ac3b177232330 am335x (at least BBB and some > > > custom boards) stalls at high network load. Reproducible via nuttcp > > > within some minutes > > > > > > nuttcp -S (on BBB) > > > nuttcp -t -N 4 -T30m 192.168.1.235 (on host) > > > > > > As Felipe Balbi suggested, I tried both 4.8.3 and 4.9.2 toolchains, > > > but both show the same behavior. > > > > > > Linux version 3.18.0 (user@user-VirtualBox) (gcc version 4.8.3 > > > 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #6 SMP > > > Mon Dec 8 22:47:43 CET 2014 > > > Linux version 3.18.1 (user@user-VirtualBox) (gcc version 4.9.2 > > > (Buildroot 2015.02-git-00582-g10b9761) ) #1 SMP Mon Dec 29 09:22:29 > > > CET 2014 > > > > > > Let me know, if you can reproduce this issue. > > > > finally managed to reproduce this, it took quite a bit of effort though. > > I'll see if I can gether more information about the problem. > > Maybe check if the irqnr is 127 (or the last reserved interrupt) > in irq-omap-intc.c. If so, also print out the previous interrupt. > It seems the intc uses the last reserved interrupt to signal a > spurious interrupt for the previous irqnr, so we should probably > add some handling for that. > > If the previous interrupt is a cpsw interrupt, then there's probably > something wrong with cpsw interrupt handling. Either a missing > read-back to flush posted write in the cpsw interrupt handler, > or the EOI registers are written at a wrong time. yeah, I'll go over it, but I first need to reproduce it again. Just rebooted to try again and after half an hour, couldn't reproduce it anymore. Interesting race to end the year :-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel wrote: > OMAP34xx and OMAP36xx processors contain a register in the syscon area, > which can be used to determine the SoCs temperature. This patch provides > a DT based driver for the temperature sensor based on an older driver > written by Peter De Schrijver for the Nokia N900 and N9. The sensor looks like an earlier iteration of sensors used in newer OMAPs, which are already supported by maybe drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update that driver instead? -- Grazvydas -- 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] hwmon: Driver for OMAP3 temperature sensor
On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas wrote: > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel wrote: >> OMAP34xx and OMAP36xx processors contain a register in the syscon area, >> which can be used to determine the SoCs temperature. This patch provides >> a DT based driver for the temperature sensor based on an older driver >> written by Peter De Schrijver for the Nokia N900 and N9. > > The sensor looks like an earlier iteration of sensors used in newer > OMAPs, which are already supported by maybe > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update > that driver instead? Just to be clear - OMAP4 is the first time that the sensors were reliable enough to be used. --- Regards, Nishanth Menon -- 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: v3.19-rc1 regression(?) on N900
Hi, On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote: > On 26/12/14 00:21, Aaro Koskinen wrote: > > > ...however, I can confirm that framebuffer is broken: > > > > [8.230743] omapfb omapfb: no displays > > [8.255584] omapfb omapfb: failed to setup omapfb > > [8.260620] platform omapfb: Driver omapfb requests probe deferral > > [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > > node > > '/ocp/spi@48098000/acx565akm@2[0]' - status (0) > > [8.284271] acx565akm spi1.2: failed to find video source > > [8.290069] spi spi1.2: Driver acx565akm requests probe deferral > > > > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint > > by matching reg-id). When I revert that, also FB works with 3.19-rc1. > > I've attached a patch for this. Only hack-tested on OMAP3 beagle, so > please report if it works. That works, thanks. A. -- 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 3/7] mfd: menelaus: add initial DT support
Hi,
On Mon, Dec 29, 2014 at 01:34:45AM +0200, Aaro Koskinen wrote:
> > > Add initial DT support.
> > >
> > > Signed-off-by: Aaro Koskinen
> > > ---
> > > Documentation/devicetree/bindings/mfd/menelaus.txt | 30 +
> > > drivers/mfd/menelaus.c | 52
> > > --
> > > 2 files changed, 78 insertions(+), 4 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/menelaus.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/menelaus.txt
> > > b/Documentation/devicetree/bindings/mfd/menelaus.txt
> > > new file mode 100644
> > > index 000..5f69f23
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/menelaus.txt
> > > @@ -0,0 +1,30 @@
> > > +Menelaus (Texas Instruments TWL92330) Power Management chip
> > > +
> > > +Menelaus provides facilities to control the power resources.
> > > +
> > > +Required properties:
> > > +- compatible: must be "menelaus"
> > > +- reg: I2C address of the chip
> > > +
> > > +Optional properties:
> > > +- interrupts: the interrupt
> > > +- ti,autosleep: All regulators are put to sleep by default.
> > > +- ti,vcore-min-microvolt: Range floor for the HW controlled VCORE
> > > +- ti,vcore-max-microvolt: Range roof for the HW controlled VCORE
> > > +
> > > +The use of ti,autosleep is recommended at least on Nokia N800/N810.
> > > +
> > > +Example:
> > > +
> > > +&i2c1 {
> > > + clock-frequency = <40>;
> > > +
> > > + pmic@72 {
> > > + compatible = "menelaus";
> > > + reg = <0x72>;
> > > + interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> > > + ti,autosleep;
> > > + ti,vcore-min-microvolt = <105>;
> > > + ti,vcore-max-microvolt = <140>;
> >
> > looks like these should be first converted to actual regulators
> > otherwise we will have to maintain this binding forever which means that
> > any effort of adding regulator fwk support for menelaus will become a
> > lot more difficult because it'll have to cope with the legacy/bogus
> > binding.
>
> I was thinking such conversion could be done with incremental patches...
> There's basically only one board (n8x0) that uses this and not likely
> to be any others. Is there a way to declare bindings unstable?
AFAICT, once they hit a major release, they're stable for life :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
On Mon 2014-12-29 12:01:03, Nishanth Menon wrote: > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas wrote: > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel wrote: > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area, > >> which can be used to determine the SoCs temperature. This patch provides > >> a DT based driver for the temperature sensor based on an older driver > >> written by Peter De Schrijver for the Nokia N900 and N9. > > > > The sensor looks like an earlier iteration of sensors used in newer > > OMAPs, which are already supported by maybe > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update > > that driver instead? > > Just to be clear - OMAP4 is the first time that the sensors were > reliable enough to be used. When testing initial version of the patch, they seem to work very well in the omap3 case. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface
On 12/23/2014 04:48 AM, Marek Szyprowski wrote:
> -static void l2c310_resume(void)
> +static void l2c310_configure(void __iomem *base)
> {
> - void __iomem *base = l2x0_base;
> + unsigned revision;
>
> - if (!(readl_relaxed(base + L2X0_CTRL) & L2X0_CTRL_EN)) {
> - unsigned revision;
> -
> - /* restore pl310 setup */
> - writel_relaxed(l2x0_saved_regs.tag_latency,
> -base + L310_TAG_LATENCY_CTRL);
> - writel_relaxed(l2x0_saved_regs.data_latency,
> -base + L310_DATA_LATENCY_CTRL);
> - writel_relaxed(l2x0_saved_regs.filter_end,
> -base + L310_ADDR_FILTER_END);
> - writel_relaxed(l2x0_saved_regs.filter_start,
> -base + L310_ADDR_FILTER_START);
> -
> - revision = readl_relaxed(base + L2X0_CACHE_ID) &
> - L2X0_CACHE_ID_RTL_MASK;
> -
> - if (revision >= L310_CACHE_ID_RTL_R2P0)
> - l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
> - L310_PREFETCH_CTRL);
> - if (revision >= L310_CACHE_ID_RTL_R3P0)
> - l2c_write_sec(l2x0_saved_regs.pwr_ctrl, base,
> - L310_POWER_CTRL);
> -
> - l2c_enable(base, l2x0_saved_regs.aux_ctrl, 8);
> -
> - /* Re-enable full-line-of-zeros for Cortex-A9 */
> - if (l2x0_saved_regs.aux_ctrl & L310_AUX_CTRL_FULL_LINE_ZERO)
> - set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
> - }
> + /* restore pl310 setup */
> + writel_relaxed(l2x0_saved_regs.tag_latency,
> +base + L310_TAG_LATENCY_CTRL);
> + writel_relaxed(l2x0_saved_regs.data_latency,
> +base + L310_DATA_LATENCY_CTRL);
> + writel_relaxed(l2x0_saved_regs.filter_end,
> +base + L310_ADDR_FILTER_END);
> + writel_relaxed(l2x0_saved_regs.filter_start,
> +base + L310_ADDR_FILTER_START);
> +
^^ The above change broke AM437xx. Looks like the change causes the
following behavior difference on AM437x. For some reason, touching any
of the above 4 registers(even with the values read from the same
registers) causes AM437x to go beserk. Comment the 4 writes and we
reach shell. looks like l2c310_resume is not invoked prior to this
series. :(.. now that we reuse that logic to actually do programming,
we start to see the problem.
one option might be to write only those registers that differ from
saved_registers (example: unmodified values dont need reprogramming).
Looks like the following also need addressing:
data->save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in __l2c_init
if you'd like to split this up in pieces, [1] might be nice - will go
good to change the pl310, aurora etc in each chunks to enable better
review.
[1]
https://github.com/nmenon/linux-2.6-playground/commits/temp/l2c-patch2-splitup
--
Regards,
Nishanth Menon
--
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] hwmon: Driver for OMAP3 temperature sensor
On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote: > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote: > > On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas > > wrote: > > > On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel > > > wrote: > > >> OMAP34xx and OMAP36xx processors contain a register in the syscon area, > > >> which can be used to determine the SoCs temperature. This patch provides > > >> a DT based driver for the temperature sensor based on an older driver > > >> written by Peter De Schrijver for the Nokia N900 and N9. > > > > > > The sensor looks like an earlier iteration of sensors used in newer > > > OMAPs, which are already supported by maybe > > > drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update > > > that driver instead? > > > > Just to be clear - OMAP4 is the first time that the sensors were > > reliable enough to be used. > > When testing initial version of the patch, they seem to work very well > in the omap3 case. > Pavel, can you look into the omap4 thermal driver to see if it can be used ? Thanks, Guenter -- 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] hwmon: Driver for OMAP3 temperature sensor
On 12/29/2014 12:15 PM, Pavel Machek wrote: > On Mon 2014-12-29 12:01:03, Nishanth Menon wrote: >> On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas >> wrote: >>> On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel wrote: OMAP34xx and OMAP36xx processors contain a register in the syscon area, which can be used to determine the SoCs temperature. This patch provides a DT based driver for the temperature sensor based on an older driver written by Peter De Schrijver for the Nokia N900 and N9. >>> >>> The sensor looks like an earlier iteration of sensors used in newer >>> OMAPs, which are already supported by maybe >>> drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update >>> that driver instead? >> >> Just to be clear - OMAP4 is the first time that the sensors were >> reliable enough to be used. > > When testing initial version of the patch, they seem to work very well > in the omap3 case. Just be careful when you try to make thermal policy like decisions based on this sensor. Placement of the sensor w.r.t the actual logic generating heat has to be a factor as well. If you are just looking for an approximation temperature (thermometerish kind), you might be ok with this. I am not sure we'd find any TI data around this.. just a heads up. Also notice http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used" I think there were accuracy issues at certain values etc.. So remember to do a off mode type PM tests as well before you consider requesting these to be merged. -- Regards, Nishanth Menon -- 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: dts: cm-t3x: add NAND support
Hi Roger,
On 12/29/2014 03:06 PM, Roger Quadros wrote:
Hi Dmitry,
On 28/12/14 16:30, Dmitry Lifshitz wrote:
CM-T3517, CM-T3530 and CM-T3730 features NAND storage chip connected to
GPMC bus.
Add GPMC DT entry into the root DT file omap3-cm-t3x.dtsi, common for
all three modules.
NAND timings are calculated to be safe for CM-T3x devices as it works
now in non DT boot (in this case the timings are updated by U-Boot).
I didn't get this part. You provide the GPMC timings in the DT now so they will
override
u-boot configured timings.
In the board files for CM-T3x modules we did not override NAND timings
configured in U-Boot. Now, with DT boot, we do not want to rely on boot
loader settings wherever is possible. So, we specify the timings
explicitly.
In order to avoid regression, the timings setup is the same as we do in
U-Boot.
Update GPMC ranges in boards DT files to include all connected devices.
Signed-off-by: Dmitry Lifshitz
---
v2 * Update GPMC ranges with NAND values in omap3-cm-t3x30.dtsi.
* Add commit message details
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 58 +
arch/arm/boot/dts/omap3-cm-t3x30.dtsi |3 +-
arch/arm/boot/dts/omap3-sbc-t3517.dts |4 ++
arch/arm/boot/dts/omap3-sbc-t3530.dts | 10 ++
arch/arm/boot/dts/omap3-sbc-t3730.dts |5 ++-
5 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 6ea6d46..4d091ca 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -259,3 +259,61 @@
pinctrl-names = "default";
pinctrl-0 = <&mcbsp2_pins>;
};
+
+&gpmc {
+ ranges = <0 0 0x 0x0100>;
Isn't this ranges property redundant as it will be overridden by the board
specific dts?
+
+ nand@0,0 {
+ reg = <0 0 4>;/* CS0, offset 0, IO size 4 */
+ nand-bus-width = <8>;
+ gpmc,device-width = <1>;
+ ti,nand-ecc-opt = "sw";
any particular reason for sticking with "sw"? Isn't it better to use at least
"ham1"
or migrate to stronger schemes like "bch4" or "bch8"?
"ham1" scheme is compatible with ROM loader so the boot partition could be
flashed from Linux.
For bch4/8 you will have to keep boot partition/s locked from Linux access as
we don't yet
support mixed ECC schemes among partitions.
The regression issue should be considered here. Our customers have
thousands of boards running rootfs with "sw" ecc. Updating the kernel is
not a reason for reformatting the NAND.
+
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <120>;
+ gpmc,cs-wr-off-ns = <120>;
+
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <120>;
+ gpmc,adv-wr-off-ns = <120>;
+
+ gpmc,we-on-ns = <6>;
+ gpmc,we-off-ns = <90>;
+
+ gpmc,oe-on-ns = <6>;
+ gpmc,oe-off-ns = <90>;
+
+ gpmc,page-burst-access-ns = <6>;
+ gpmc,access-ns = <72>;
+ gpmc,cycle2cycle-delay-ns = <60>;
+
+ gpmc,rd-cycle-ns = <120>;
+ gpmc,wr-cycle-ns = <120>;
+ gpmc,wr-access-ns = <186>;
+ gpmc,wr-data-mux-bus-ns = <90>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "xloader";
+ reg = <0 0x8>;
+ };
+ partition@0x8 {
+ label = "uboot";
+ reg = <0x8 0x1e>;
+ };
+ partition@0x26 {
+ label = "uboot environment";
+ reg = <0x26 0x4>;
+ };
+ partition@0x2a {
+ label = "linux";
+ reg = <0x2a 0x40>;
+ };
+ partition@0x6a {
+ label = "rootfs";
+ reg = <0x6a 0x1f88>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
index 9a4a3ab..d9e92b6 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -50,7 +50,8 @@
#include "omap-gpmc-smsc911x.dtsi"
&gpmc {
- ranges = <5 0 0x2c00 0x0100>;
+ ranges = <5 0 0x2c00 0x0100>, /* CM-T3x30 SMSC9x Eth */
+<0 0 0x 0x0100>; /* CM-T3x NAND */
Isn't this ranges property redundant as it will anyways be overridden by the
board specific dts?
The ranges are specified here (and other files below) by design.
We built a tree like structure to organize DT files -
d234e4239 "ARM: dts: sbc-t3x: refactor DT support"
It allows to inherit/override properties common for different boards.
Our customers
