Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150218 15:58]: > On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > > Of course it's always possible to do do a omap3-n900-qemu.dts > > if larger changes are needed :) > > I would like to avoid using separate DTS for qemu. When we have > only one DTS file (for both qemu and real HW), we can test for > regression in qemu and we are sure that we have same software > configuration... Agreed, and I'd rather take the extra warning on rare to find hardware to avoid an etra .dts file. Are there any reasons whey the n900 qemu support could not be in the mainline qemu btw? 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: Enabling DBGEN signal in GP OMAP3
On Wed, Feb 18, 2015 at 5:00 AM, Matthijs van Duin wrote: > > 030-040 are the core debug control regs... in fact, judging by their > values and the fact you mentioned bit 13 controls DBGEN, these regs > look very much like the ICEPick-D core debug control regs, which > themselves are simplified versions of debug TAP control registers (for > which you can find the layout in the dm3730 TRM's debug chapter). > > 050 and 054 are unknown, but 058 reads 0x2000 which suggests it > may have an ownership claim command register there. Try writing > 0x4000 to it, if that succeeds and it reads back 0x7000 then > you're successfully claimed ownership which hopefully means you can > then write to other regs too, although they may not take effect unless > you enable the module by writing 0x8000 to the ownership claim > command register, after which it should read back 0xb000. Of > course it's also possible it only covers registers 050 and 054, > whatever they may be... (or it might be something else altogether) It turns out 050, 054 and 058 (but only them) are actually documented in dm3730 manual and are part of Emulation Pin Manager. 058 works as you (and the manual) describe, however claiming and enabling EPM registers still doesn't enable writing to 030 :( > > RXEN == INPUTENABLE > > At least on the am335x, disabling it causes the processor to perceive > the input as being low regardless of its actual level. Since the line > itself doesn't have to change level, this can be toggled pretty fast > probably. Using this to simulate an input does require the actual line > level to be high obviously. OK thanks for all the info. I've tested a spare floating pin by muxing it as a GPIO on my dm3730 and it works as you describe, nice. Hopefully this also applies to jtag pins there. >> I could try the bitbang method if you think it can work, although my >> board (openpandora) has a 10K pulldown resistor on nTRST that I'm not >> sure OMAP's internal pullup would win over. > > It won't, you'll need to externally drive it up, e.g. by connecting it > to the Vref pin that's also on the jtag connector. > >> Is there any way to check if anything works from the CPU? >> Maybe I could modify my board, I could connect some spare GPIO pads to >> jtag pads, but I don't know if it's even worth trying. > > If the ownership claim register doesn't work it may be worth a try, if > you're comfortable doing that. Connecting them to GPIOs will > definitely work, though just driving the inputs high and toggling > INPUTENABLE via padconf *may* also work and be simpler. Ok, sounds like I need to find and get rid of that 10k resistor, or connect the pad to 1.8V. It's just a shame that there doesn't seem to be a way to do it purely in software so that other pandora users could have hardware watchpoints. If you could share the programming sequence it would be great. Thanks again, Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150218 11:07]: > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: > > > */ +//reg = <1 0x300 0xf>;/* 16 byte IO range at > offset > > > 0x300 */ +reg = <1 0x0 0xf>; /* 16 byte IO > > > range > at > > > offset 0x300 */ > > > > > > bank-width = <2>; > > > pinctrl-names = "default"; > > > pinctrl-0 = <ðernet_pins>; > > > > Oh cool, the 0x300 offset is there mostly to suppress warnings > > about non-standard location. ... > > OK that's good news. Care to do a patch to set the offset 0x0 > > with added comment that qemu needs it? I'll test to make sure > > it works on the real hardware as well. > > Yes, I can send proper git format-patch, but first let me know if > that change does not break your HW... Yes using reg = <1 0 0xf> works, it just adds this extra warning: smc91x 200.ethernet (unnamed net_device) (uninitialized): smc91x: IOADDR d09d6000 doesn't match configuration (300). And I'm pretty sure that can be fixed by setting the EEPROM offset to 0 instead of the default 0x300. People with smc91x most likely want to write at least the MAC address to the EEPROM, so might as well set the offset to zero then too. Of course it's always possible to do do a omap3-n900-qemu.dts if larger changes are needed :) 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: Enabling DBGEN signal in GP OMAP3
* Matthijs van Duin [150218 10:32]:
> On 18 February 2015 at 15:54, Tony Lindgren wrote:
> > From memory.. I believe the issue was that for anything needing to
> > set the counter and rely on the counter interrupt things would fail
> > as the counter interrupts would not always happen.
>
> Correct, but the interrupt is just used to indicate when counters
> overflow, intended to be used to correctly keep track of the counters
> when they exceed 2^32 (which can happen easily when measuring across a
> timespan of more than a few seconds).
>
> However, no performance counter can increment more than twice per cpu
> cycle, which means it takes at least 2^31 cpu cycles to completely
> wrap a counter around. If you make sure you update local copies
> (untested code below) more often than once per 2^31 cycles they should
> therefore keep accurate track.
>
> void update_perf_counters( u64 ctr[4] )
> {
> for( int i = 0; i < 4; i++ ) {
> u32 val;
> asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
> asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
> ctr[i] += (u32)( val - ctr[i] );
> }
> }
Hmm yeah maybe oprofile/perf whatever has maximum value that can be
specified for the counter length that allows working around it.
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: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > * Pali Rohár [150218 11:07]: > > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: > > > > */ +// reg = <1 0x300 0xf>;/* 16 byte IO range at > > > > offset > > > > > > 0x300 */ + reg = <1 0x0 0xf>; /* 16 byte IO range > > > > at > > > > > > offset 0x300 */ > > > > > > > > bank-width = <2>; > > > > pinctrl-names = "default"; > > > > pinctrl-0 = <ðernet_pins>; > > > > > > Oh cool, the 0x300 offset is there mostly to suppress > > > warnings about non-standard location. > > ... > > > > OK that's good news. Care to do a patch to set the offset > > > 0x0 with added comment that qemu needs it? I'll test to > > > make sure it works on the real hardware as well. > > > > Yes, I can send proper git format-patch, but first let me > > know if that change does not break your HW... > > Yes using reg = <1 0 0xf> works, it just adds this extra > warning: > > smc91x 200.ethernet (unnamed net_device) (uninitialized): > smc91x: IOADDR d09d6000 doesn't match configuration (300). > > And I'm pretty sure that can be fixed by setting the EEPROM > offset to 0 instead of the default 0x300. People with smc91x > most likely want to write at least the MAC address to the > EEPROM, so might as well set the offset to zero then too. > > Of course it's always possible to do do a omap3-n900-qemu.dts > if larger changes are needed :) > > Regards, > > Tony I would like to avoid using separate DTS for qemu. When we have only one DTS file (for both qemu and real HW), we can test for regression in qemu and we are sure that we have same software configuration... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: v3.19: Nokia N900 (qemu) - omap_aes error
On Monday 09 February 2015 12:25:00 Pali Rohár wrote: > On Saturday 31 January 2015 16:29:36 Pali Rohár wrote: > > Hello, > > > > when I enable problematic omap_aes.ko driver (also in DT) > > for Nokia N900 machine in qemu (it emulates OMAP GP device, > > not HS) I get this error message in dmesg at modprobe time: > > > > [ 37.660339] [ cut here ] > > [ 37.663940] WARNING: CPU: 0 PID: 173 at arch/arm/mach- > > omap2/omap_hwmod.c:2182 _idle+0x28/0x64() > > [ 37.668762] omap_hwmod: aes: idle state can only be > > entered from enabled state > > [ 37.672271] Modules linked in: omap_aes(+) > > [ 37.675933] CPU: 0 PID: 173 Comm: modprobe Not tainted > > 3.19.0- rc5+ #299 > > [ 37.679534] Hardware name: Nokia RX-51 board > > [ 37.683227] [] (unwind_backtrace) from > > [] (show_stack+0x10/0x14) > > [ 37.686920] [] (show_stack) from [] > > (warn_slowpath_common+0x84/0xac) > > [ 37.690765] [] (warn_slowpath_common) from > > [] (warn_slowpath_fmt+0x2c/0x3c) > > [ 37.694366] [] (warn_slowpath_fmt) from > > [] (_idle+0x28/0x64) > > [ 37.698791] [] (_idle) from [] > > (omap_hwmod_idle+0x30/0x78) > > [ 37.702636] [] (omap_hwmod_idle) from > > [] (omap_device_idle+0x48/0x6c) > > [ 37.707153] [] (omap_device_idle) from > > [] (_od_runtime_suspend+0x1c/0x24) > > [ 37.710723] [] (_od_runtime_suspend) from > > [] (__rpm_callback+0x8c/0xdc) > > [ 37.714385] [] (__rpm_callback) from > > [] (rpm_callback+0x70/0x88) > > [ 37.717987] [] (rpm_callback) from [] > > (rpm_suspend+0x2e8/0x5a4) > > [ 37.721710] [] (rpm_suspend) from [] > > (__pm_runtime_idle+0x58/0x9c) > > [ 37.725402] [] (__pm_runtime_idle) from > > [] (omap_aes_probe+0x15c/0x448 [omap_aes]) > > [ 37.733489] [] (omap_aes_probe [omap_aes]) from > > [] (platform_drv_probe+0x48/0x90) > > [ 37.740936] [] (platform_drv_probe) from > > [] (really_probe+0xac/0x1e0) > > [ 37.745025] [] (really_probe) from [] > > (driver_probe_device+0x30/0x48) > > [ 37.749847] [] (driver_probe_device) from > > [] (__driver_attach+0x60/0x84) > > [ 37.753601] [] (__driver_attach) from > > [] (bus_for_each_dev+0x50/0x84) > > [ 37.758422] [] (bus_for_each_dev) from > > [] (bus_add_driver+0xac/0x1bc) > > [ 37.762207] [] (bus_add_driver) from > > [] (driver_register+0x9c/0xe0) > > [ 37.765899] [] (driver_register) from > > [] (do_one_initcall+0x100/0x1b0) > > [ 37.769653] [] (do_one_initcall) from > > [] (do_init_module+0x34/0x158) > > [ 37.773590] [] (do_init_module) from > > [] (SyS_init_module+0x54/0x64) > > [ 37.777252] [] (SyS_init_module) from > > [] (ret_fast_syscall+0x0/0x30) > > [ 37.780975] ---[ end trace 86c3e025b92e700d ]--- > > [ 37.784667] omap-aes 480c5000.aes: OMAP AES hw accel rev: > > 0.0 [ 37.789794] of_dma_request_slave_channel: dma-names > > property of node '/ocp/aes@480c5000' missing or empty > > [ 37.797668] omap-aes 480c5000.aes: Unable to request in > > DMA channel > > [ 37.801391]omap_aes_dma_init: error: -12 > > > > Error is not fatal, kernel does not crash and qemu emulation > > working fine. But error is there. > > > > I'm sure that qemu does not support omap aes hw emulation > > and so I except error message about missing hw part (or > > something else). But not above unwind_backtrace error > > message. > > > > Any idea why it happens? It is probably not related to AES > > but to DMA. It is for OMAP GP device (but emulated), so can > > TI comment this problem (as this is not HS under NDA)? > > Hello, > > what does that error line means? > > [ 37.668762] omap_hwmod: aes: idle state can only be entered > from enabled state > > Is not it bug in omap_hwmod.c code? In qemu dmesg log I see this debug line: [0.297851] omap_hwmod: aes: cannot be enabled for reset (3) So aes is in disabled state. Should not omap-aes driver check for aes state if is enabled? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: Nokia N900: omap aes is broken
On Wednesday 18 February 2015 22:02:30 Pali Rohár wrote:
> On Wednesday 18 February 2015 13:21:03 Pali Rohár wrote:
> > Hello,
> >
> > I tried to test OMAP AES driver on Nokia N900 with special
> > Nokia bootloader which enable L3 firewall for OMAP AES HW
> > support.
> >
> > I modified arch/arm/boot/dts/omap34xx-hs.dtsi file and
> > commented aes line which disable aes support in DT.
> >
> > Then I booted kernel and loaded omap-aes.ko module. And I
> > got this output in dmesg:
> >
> > [0.222930] platform 480c5000.aes: Cannot lookup hwmod
> > 'aes' [ 27.758148] omap-aes 480c5000.aes:
> > _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info
> > [ 27.765960] omap-aes 480c5000.aes: omap_aes_probe: failed
> > to get_sync(-19)
> > [ 29.257690] omap-aes 480c5000.aes: initialization failed.
> >
> > So it looks like some initialization data are missing for
> > Nokia N900 (omap3430 device).
> >
> > Can somebody look at it? I have patched 2.6.28 kernel were
> > omap aes support on this N900 device (with special
> > bootloader) is working.
> >
> > Maybe some other data are missing in DT or in hwmod?
>
> dma channels are missing in DT. I applied this patch:
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi
> b/arch/arm/boot/dts/omap3.dtsi index 01b7111..473d460 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -92,6 +92,8 @@
> ti,hwmods = "aes";
> reg = <0x480c5000 0x50>;
> interrupts = <0>;
> + dmas = <&sdma 65 &sdma 66>;
> + dma-names = "tx", "rx";
> };
>
> prm: prm@48306000 {
> @@ -550,6 +552,8 @@
> ti,hwmods = "sham";
> reg = <0x480c3000 0x64>;
> interrupts = <49>;
> + dmas = <&sdma 96>;
> + dma-names = "rx";
> };
>
> smartreflex_core: smartreflex@480cb000 {
>
>
> and omap-aes driver was successfully loaded. now it is in
> /proc/crypto
>
> I copied dma names and numbers from file
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
And I also needed to apply this patch:
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 11468ee..3281f30 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init omap3xxx_hwmod_init(void)
if (r < 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r < 0)
return r;
aes hwmod is defined in GP-only hwmod...
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Wednesday 11 February 2015 21:40:33 Nishanth Menon wrote: > On Wed, Feb 11, 2015 at 2:28 PM, Pali Rohár wrote: > > On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote: > >> On 11 February 2015 at 13:39, Pali Rohár > >> > > > > wrote: > >> >> Anyhow, since checking the firewalls/APs to see if you > >> >> have permission will probably only get you yet another > >> >> fault if things are walled off, the robust way of > >> >> dealing with this sort of situation is by probing the > >> >> device with a read while trapping bus faults. This also > >> >> handles modules that are unreachable for other reasons, > >> >> e.g. being disabled by eFuse. > >> > > >> > It is possible to patch kernel code to mask or ignore > >> > that fault? Can you help me with something like that? > >> > >> As I mentioned, I'm still learning my way around the > >> kernel, so I don't feel very comfortable suggesting a > >> concrete patch just yet. I've been browsing arch/arm/mm/ > >> however and my impression is that all that would be > >> required is editing fault.c by making a copy of do_bad but > >> containing > >> > >> return user_mode(regs) || !fixup_exception(regs); > >> > >> and hook it onto the appropriate fault codes. However, > >> this really needs the opinion of someone more familiar > >> with this code. > >> > >> I do have an observation to make on the issue of fault > >> decoding: the list in fsr-2level.c may be "standard ARMv3 > >> and ARMv4 aborts" but they are quite wrong for ARMv7 which > >> has: > >> > >> [ 0] - > >> [ 1] alignment fault > >> [ 2] debug event > >> [ 3] section access flag fault > >> [ 4] instruction cache maintainance fault (reported via > >> data abort) [ 5] section translation fault > >> [ 6] page access flag fault > >> [ 7] page translation fault > >> [ 8] bus error on access > >> [ 9] section domain fault > >> [10] - > >> [11] page domain fault > >> [12] bus error on section table walk > >> [13] section permission fault > >> [14] bus error on page table walk > >> [15] page permission fault > >> [16] (TLB conflict abort) > >> [17] - > >> [18] - > >> [19] - > >> [20] (lockdown abort) > >> [21] - > >> [22] async bus error (reported via data abort) > >> [23] - > >> [24] async parity/ECC error (reported via data abort) > >> [25] parity/ECC error on access > >> [26] (coprocessor abort) > >> [27] - > >> [28] parity/ECC error on section table walk > >> [29] - > >> [30] parity/ECC error on page table walk > >> [31] - > >> > >> Some entries are patched up near the bottom of fault.c but > >> many bogus messages remain, for example the "on linefetch" > >> vs "on non-linefetch" is misleading since no such thing > >> can be inferred from the fault status on v7. Also, the > >> i-cache maintenance fault handling looks wrong to me: it > >> should fetch the actual fault status from IFSR (even > >> though the address still comes from DFSR) and dispatch > >> based on that. > >> > >> Async external aborts (async bus error and async parity/ECC > >> error) give you basically no info. DFAR will contain > >> garbage hence displaying it will confuse rather than > >> enlighten, a traceback is pointless since the instruction > >> that caused the access is long retired, likewise > >> user_mode() doesn't matter since a transition to kernel > >> space may have happened after the access that cause the > >> abort. Basically they should be treated more as an IRQ > >> than as a fault (note they can also be masked just like > >> irqs). In case of a bus error, it may be appropriate to > >> just warn about it, or perhaps send a signal to the > >> current process, although in the latter case it should > >> have some means to distinguish it from a synchronous bus > >> error. > >> > >> At least on the cortex-a8, a parity/ECC error (whether > >> async or not) is to be regarded as absolutely fatal. > >> Quoth the TRM: "No recovery is possible. The abort handler > >> must disable the caches, communicate the fail directly > >> with the external system, request a reboot." > >> > >> Bit 10 no longer indicates an asynchronous (let alone > >> imprecise) fault. Apart from the debug events and async > >> aborts (and possibly some implementation-defined aborts), > >> all aborts listed are synchronous, and DFAR/IFAR is valid. > >> There's no technical obstruction to make these trappable > >> via the kernel exception handling mechanism. (Though at > >> least in case of parity/ECC errors one shouldn't.) > > > > Tony, Nishanth, or somebody else... can you help with memory > > management? Or do you know some expert for arch/arm/mm/ > > code? > > Folks in linux-arm-kernel are probably the right people, I > suppose. Looping them in. Hi folks in linux-arm-kernel! Can you help us with above problem? How to catch external abort on non-linefetch in kernel driver and prevent kernel panic? Here is that kernel panic log: http://thread.gmane.org/gmane.linux.ports.arm.omap/108397/ We want to check for "Unhandled fault: exter
Re: Nokia N900: omap aes is broken
On Wednesday 18 February 2015 13:21:03 Pali Rohár wrote:
> Hello,
>
> I tried to test OMAP AES driver on Nokia N900 with special
> Nokia bootloader which enable L3 firewall for OMAP AES HW
> support.
>
> I modified arch/arm/boot/dts/omap34xx-hs.dtsi file and
> commented aes line which disable aes support in DT.
>
> Then I booted kernel and loaded omap-aes.ko module. And I got
> this output in dmesg:
>
> [0.222930] platform 480c5000.aes: Cannot lookup hwmod
> 'aes' [ 27.758148] omap-aes 480c5000.aes:
> _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info
> [ 27.765960] omap-aes 480c5000.aes: omap_aes_probe: failed
> to get_sync(-19)
> [ 29.257690] omap-aes 480c5000.aes: initialization failed.
>
> So it looks like some initialization data are missing for
> Nokia N900 (omap3430 device).
>
> Can somebody look at it? I have patched 2.6.28 kernel were
> omap aes support on this N900 device (with special
> bootloader) is working.
>
> Maybe some other data are missing in DT or in hwmod?
dma channels are missing in DT. I applied this patch:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..473d460 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -92,6 +92,8 @@
ti,hwmods = "aes";
reg = <0x480c5000 0x50>;
interrupts = <0>;
+ dmas = <&sdma 65 &sdma 66>;
+ dma-names = "tx", "rx";
};
prm: prm@48306000 {
@@ -550,6 +552,8 @@
ti,hwmods = "sham";
reg = <0x480c3000 0x64>;
interrupts = <49>;
+ dmas = <&sdma 96>;
+ dma-names = "rx";
};
smartreflex_core: smartreflex@480cb000 {
and omap-aes driver was successfully loaded. now it is in /proc/crypto
I copied dma names and numbers from file
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
> * Pali Rohár [150218 07:23]:
> > On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
> > > Revert "ARM: dts: Disable smc91x on n900 until bootloader
> > > dependency is removed". We've now fixed the issues that
> > > caused problems with uninitialized hardware depending on
> > > the bootloader version. Mostly things got fixed with
> > > the following commits:
> > >
> > > 9a894953a97b ("ARM: dts: Fix bootloader version
> > > dependencies by muxing n900 smc91x pins") 7d2911c43815
> > > ("net: smc91x: Fix gpios for device tree based booting")
> > >
> > > Note that this only affects the early development boards
> > > with Ethernet that we still have in a few automated boot
> > > test systems.
> > >
> > > Signed-off-by: Tony Lindgren
> > >
> > > --- a/arch/arm/boot/dts/omap3-n900.dts
> > > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > > @@ -702,9 +702,6 @@
> > >
> > > ethernet@gpmc {
> > >
> > > compatible = "smsc,lan91c94";
> > >
> > > -
> > > - status = "disabled";
> > > -
> > >
> > > interrupt-parent = <&gpio2>;
> > > interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54
*/
> > > reg = <1 0x300 0xf>;/* 16 byte IO range at
offset
> > > 0x300
> > >
> > > */
> >
> > Hello Tony,
> >
> > to make smc ethernet working in n900 qemu I needed to apply
> > this patch:
> >
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts
> > b/arch/arm/boot/dts/omap3-n900.dts index ff36fbe..d96eeb8
> > 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -770,7 +770,8 @@
> >
> > compatible = "smsc,lan91c94";
> > interrupt-parent = <&gpio2>;
> > interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
> >
> > - reg = <1 0x300 0xf>;/* 16 byte IO range at offset
0x300
> > */ +// reg = <1 0x300 0xf>;/* 16 byte IO range at
offset
> > 0x300 */ + reg = <1 0x0 0xf>; /* 16 byte IO range
at
> > offset 0x300 */
> >
> > bank-width = <2>;
> > pinctrl-names = "default";
> > pinctrl-0 = <ðernet_pins>;
>
> Oh cool, the 0x300 offset is there mostly to suppress warnings
> about non-standard location.
>
> > With this patch I see in dmesg:
> >
> > [ 20.577911] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc91x: smc_probe [ 20.580535] smc91x
> > 200.ethernet (unnamed net_device) (uninitialized):
> > smc91x: bank signature probe returned 0x3300
> > [ 20.585327] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc91x: revision = 0x3391 [ 20.590087]
> > smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
> > [ 20.593627] smc91x 200.ethernet
> > (unnamed net_device) (uninitialized): smc_reset [
> > 20.596832] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc_phy_detect [ 20.611938] smc91x
> > 200.ethernet (unnamed net_device) (uninitialized):
> > smc91x: smc_shutdown [ 20.615875] smc91x 200.ethernet
> > eth0: SMC91C11xFD (rev 1) at d08be000 IRQ 166 [
> > 20.618682]
> > [ 20.621124] smc91x 200.ethernet eth0: Ethernet addr:
> > 52:54:00:12:34:56 [ 20.624938] smc91x 200.ethernet
> > eth0: No PHY found
> >
> > (and eth0 exists in ifconfig)
> >
> > If I do not apply my patch I got this error message:
> >
> > [ 22.134704] smc91x 2000300.ethernet (unnamed net_device)
> > (uninitialized): smc91x: bank signature probe returned
> > 0x
> > [ 22.140014] smc91x: not found (-19).
> >
> > and no ethernet device was registered.
> >
> > With 2.6.28 kernel with N900 patches (but smc91x is
> > unmodified!) ethernet device is working fine.
>
> OK that's good news. Care to do a patch to set the offset 0x0
> with added comment that qemu needs it? I'll test to make sure
> it works on the real hardware as well.
>
> Regards,
>
> Tony
Yes, I can send proper git format-patch, but first let me know if
that change does not break your HW...
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: Enabling DBGEN signal in GP OMAP3
On 18 February 2015 at 15:54, Tony Lindgren wrote:
> From memory.. I believe the issue was that for anything needing to
> set the counter and rely on the counter interrupt things would fail
> as the counter interrupts would not always happen.
Correct, but the interrupt is just used to indicate when counters
overflow, intended to be used to correctly keep track of the counters
when they exceed 2^32 (which can happen easily when measuring across a
timespan of more than a few seconds).
However, no performance counter can increment more than twice per cpu
cycle, which means it takes at least 2^31 cpu cycles to completely
wrap a counter around. If you make sure you update local copies
(untested code below) more often than once per 2^31 cycles they should
therefore keep accurate track.
void update_perf_counters( u64 ctr[4] )
{
for( int i = 0; i < 4; i++ ) {
u32 val;
asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
ctr[i] += (u32)( val - ctr[i] );
}
}
- Matthijs
--
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: Revert disabling of smc91x for n900
* Pali Rohár [150218 07:23]:
> On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
> > Revert "ARM: dts: Disable smc91x on n900 until bootloader
> > dependency is removed". We've now fixed the issues that
> > caused problems with uninitialized hardware depending on
> > the bootloader version. Mostly things got fixed with
> > the following commits:
> >
> > 9a894953a97b ("ARM: dts: Fix bootloader version dependencies
> > by muxing n900 smc91x pins") 7d2911c43815 ("net: smc91x: Fix
> > gpios for device tree based booting")
> >
> > Note that this only affects the early development boards
> > with Ethernet that we still have in a few automated boot
> > test systems.
> >
> > Signed-off-by: Tony Lindgren
> >
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -702,9 +702,6 @@
> >
> > ethernet@gpmc {
> > compatible = "smsc,lan91c94";
> > -
> > - status = "disabled";
> > -
> > interrupt-parent = <&gpio2>;
> > interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
> > reg = <1 0x300 0xf>;/* 16 byte IO range at offset
> > 0x300
> > */
>
> Hello Tony,
>
> to make smc ethernet working in n900 qemu I needed to apply this patch:
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index ff36fbe..d96eeb8 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -770,7 +770,8 @@
> compatible = "smsc,lan91c94";
> interrupt-parent = <&gpio2>;
> interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
> - reg = <1 0x300 0xf>;/* 16 byte IO range at offset
> 0x300 */
> +// reg = <1 0x300 0xf>;/* 16 byte IO range at offset
> 0x300 */
> + reg = <1 0x0 0xf>; /* 16 byte IO range at offset
> 0x300 */
> bank-width = <2>;
> pinctrl-names = "default";
> pinctrl-0 = <ðernet_pins>;
Oh cool, the 0x300 offset is there mostly to suppress warnings about
non-standard location.
> With this patch I see in dmesg:
>
> [ 20.577911] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: smc_probe
> [ 20.580535] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: bank signature probe
> returned 0x3300
> [ 20.585327] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: revision = 0x3391
> [ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
> [ 20.593627] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc_reset
> [ 20.596832] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc_phy_detect
> [ 20.611938] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: smc_shutdown
> [ 20.615875] smc91x 200.ethernet eth0: SMC91C11xFD (rev 1) at d08be000
> IRQ 166
> [ 20.618682]
> [ 20.621124] smc91x 200.ethernet eth0: Ethernet addr: 52:54:00:12:34:56
> [ 20.624938] smc91x 200.ethernet eth0: No PHY found
>
> (and eth0 exists in ifconfig)
>
> If I do not apply my patch I got this error message:
>
> [ 22.134704] smc91x 2000300.ethernet (unnamed net_device) (uninitialized):
> smc91x: bank signature probe
> returned 0x
> [ 22.140014] smc91x: not found (-19).
>
> and no ethernet device was registered.
>
> With 2.6.28 kernel with N900 patches (but smc91x is unmodified!) ethernet
> device is working fine.
OK that's good news. Care to do a patch to set the offset 0x0 with added
comment that qemu needs it? I'll test to make sure it works on the
real hardware as well.
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: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
> Revert "ARM: dts: Disable smc91x on n900 until bootloader
> dependency is removed". We've now fixed the issues that
> caused problems with uninitialized hardware depending on
> the bootloader version. Mostly things got fixed with
> the following commits:
>
> 9a894953a97b ("ARM: dts: Fix bootloader version dependencies
> by muxing n900 smc91x pins") 7d2911c43815 ("net: smc91x: Fix
> gpios for device tree based booting")
>
> Note that this only affects the early development boards
> with Ethernet that we still have in a few automated boot
> test systems.
>
> Signed-off-by: Tony Lindgren
>
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -702,9 +702,6 @@
>
> ethernet@gpmc {
> compatible = "smsc,lan91c94";
> -
> - status = "disabled";
> -
> interrupt-parent = <&gpio2>;
> interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
> reg = <1 0x300 0xf>;/* 16 byte IO range at offset
> 0x300
> */
Hello Tony,
to make smc ethernet working in n900 qemu I needed to apply this patch:
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index ff36fbe..d96eeb8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -770,7 +770,8 @@
compatible = "smsc,lan91c94";
interrupt-parent = <&gpio2>;
interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
- reg = <1 0x300 0xf>;/* 16 byte IO range at offset
0x300 */
+// reg = <1 0x300 0xf>;/* 16 byte IO range at offset
0x300 */
+ reg = <1 0x0 0xf>; /* 16 byte IO range at offset
0x300 */
bank-width = <2>;
pinctrl-names = "default";
pinctrl-0 = <ðernet_pins>;
With this patch I see in dmesg:
[ 20.577911] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: smc_probe
[ 20.580535] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: bank signature probe
returned 0x3300
[ 20.585327] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: revision = 0x3391
[ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
[ 20.593627] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc_reset
[ 20.596832] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc_phy_detect
[ 20.611938] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: smc_shutdown
[ 20.615875] smc91x 200.ethernet eth0: SMC91C11xFD (rev 1) at d08be000
IRQ 166
[ 20.618682]
[ 20.621124] smc91x 200.ethernet eth0: Ethernet addr: 52:54:00:12:34:56
[ 20.624938] smc91x 200.ethernet eth0: No PHY found
(and eth0 exists in ifconfig)
If I do not apply my patch I got this error message:
[ 22.134704] smc91x 2000300.ethernet (unnamed net_device) (uninitialized):
smc91x: bank signature probe
returned 0x
[ 22.140014] smc91x: not found (-19).
and no ethernet device was registered.
With 2.6.28 kernel with N900 patches (but smc91x is unmodified!) ethernet
device is working fine.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: Enabling DBGEN signal in GP OMAP3
* Matthijs van Duin [150216 12:12]: > On 16 February 2015 at 18:58, Tony Lindgren wrote: > > The perf counter on omap3 used to work, but is buggy at least on > > 3430 because it eventually stops producing interrupts because of > > some bug in the Cortex-A8 version being used. > > Of course the workaround of polling the counters at least once per > 2^31 clock cycles to detect when they wrap (or in general keep local > 64-bit copies up-to-date) is not really a huge burden. >From memory.. I believe the issue was that for anything needing to set the counter and rely on the counter interrupt things would fail as the counter interrupts would not always happen. 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 v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On Wed, Feb 18, 2015 at 10:39:53PM +0800, Sneeker Yeh wrote: > Hi, > 2015/2/18 下午10:34 於 "Felipe Balbi" 寫道： > > > > On Wed, Feb 18, 2015 at 10:47:45AM +0200, Mathias Nyman wrote: > > > Hi > > > > > > This looks correct, but if you are still going to make a new series > fixing > > > Felipe's comments then the following tiny nitpicks could be fixed as > well. > > > > > > Otherwise > > > > > > Acked-by: Mathias Nyman > > > > > > Felipe, Do you want to take this series through your tree? > > > > I can, no issues :-) > > > > > On 17.02.2015 07:41, Sneeker Yeh wrote: > > > > > > > > +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int > dev_port_num) > > > > > > Either add a function description explaining something like "Late > > > clearing of connect status. > > > Some quirky hardware will suspend the controller when CSC bit is > > > cleared and leave URBs unhandled" > > > > > > Or change the function name to something like > > > xhci_late_csc_clear_quirk() or xhci_deferred_csc_clear_quirk() > > > > I have a feeling xhci_late_csc_clear_quirk() is a better name, much more > > descriptive than xhci_try_to_clear_csc() :-) > > Hmm, I'll use this one, ^^ > Thanks for comment it. alright, either one is fine :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On Wed, Feb 18, 2015 at 10:47:45AM +0200, Mathias Nyman wrote: > Hi > > This looks correct, but if you are still going to make a new series fixing > Felipe's comments then the following tiny nitpicks could be fixed as well. > > Otherwise > > Acked-by: Mathias Nyman > > Felipe, Do you want to take this series through your tree? I can, no issues :-) > On 17.02.2015 07:41, Sneeker Yeh wrote: > > > > +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num) > > Either add a function description explaining something like "Late > clearing of connect status. > Some quirky hardware will suspend the controller when CSC bit is > cleared and leave URBs unhandled" > > Or change the function name to something like > xhci_late_csc_clear_quirk() or xhci_deferred_csc_clear_quirk() I have a feeling xhci_late_csc_clear_quirk() is a better name, much more descriptive than xhci_try_to_clear_csc() :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
hi Mathias,
thanks for reviewing these,
2015-02-18 16:47 GMT+08:00 Mathias Nyman :
> Hi
>
> This looks correct, but if you are still going to make a new series fixing
> Felipe's comments then the following tiny nitpicks could be fixed as well.
>
> Otherwise
>
> Acked-by: Mathias Nyman
>
> Felipe, Do you want to take this series through your tree?
>
> On 17.02.2015 07:41, Sneeker Yeh wrote:
>>
>> +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
>
> Either add a function description explaining something like "Late clearing of
> connect status.
> Some quirky hardware will suspend the controller when CSC bit is cleared and
> leave URBs unhandled"
>
> Or change the function name to something like xhci_late_csc_clear_quirk() or
> xhci_deferred_csc_clear_quirk()
>
> Maybe the name should be changed anyways.
> The "try to" makes it look like some non-blocking version of a csc clear
> function.
hm...thanks...it totally make sense,
i'd like to use xhci_deferred_csc_clear_quirk(), and will take it to
my next patches.
>
>> +{
>> + int max_ports;
>> + struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>> + __le32 __iomem **port_array;
>> + u32 status;
>> +
>> + /* print debug info */
>
> Remove this comment
okay, i see.
>
>> + if (hcd->speed == HCD_USB3) {
>> + max_ports = xhci->num_usb3_ports;
>> + port_array = xhci->usb3_ports;
>> + } else {
>> + max_ports = xhci->num_usb2_ports;
>> + port_array = xhci->usb2_ports;
>> + }
>> +
>> + if (dev_port_num > max_ports) {
>> + xhci_err(xhci, "%s() port number invalid", __func__);
>> + return;
>> + }
>> + status = readl(port_array[dev_port_num - 1]);
>> +
>> + /* write 1 to clear */
>
> Not really a helpful comment either, either remove or change to something like
> "clearing the connect status bit will now immediately suspend these quirky
> controllers"
okay, i got it ,
thanks.
Much appreciate,
Sneeker
>
> -Mathias
--
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 5/5] usb: dwc3: add Fujitsu Specific Glue layer
hi Felipe: thanks for the suggestion, 2015-02-18 3:26 GMT+08:00 Felipe Balbi : > On Tue, Feb 17, 2015 at 01:41:37PM +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 | 33 >> drivers/usb/dwc3/Kconfig | 11 ++ >> drivers/usb/dwc3/Makefile |1 + >> drivers/usb/dwc3/dwc3-mb86s70.c| 206 >> >> 4 files changed, 251 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt >> create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c > > what's the possibility that fujitsu will make another SoC with dwc3 in > it ? I wonder if we should use a slightly more generic name here: > > dwc3-fujitsu.c ? We did have several SoC that has dwc3 in it, "dwc3-fujitsu.c" looks fine, and I would like to take this to next patchset. Much appreciate, Sneeker > > -- > balbi -- 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
Nokia N900: omap aes is broken
Hello, I tried to test OMAP AES driver on Nokia N900 with special Nokia bootloader which enable L3 firewall for OMAP AES HW support. I modified arch/arm/boot/dts/omap34xx-hs.dtsi file and commented aes line which disable aes support in DT. Then I booted kernel and loaded omap-aes.ko module. And I got this output in dmesg: [0.222930] platform 480c5000.aes: Cannot lookup hwmod 'aes' [ 27.758148] omap-aes 480c5000.aes: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info [ 27.765960] omap-aes 480c5000.aes: omap_aes_probe: failed to get_sync(-19) [ 29.257690] omap-aes 480c5000.aes: initialization failed. So it looks like some initialization data are missing for Nokia N900 (omap3430 device). Can somebody look at it? I have patched 2.6.28 kernel were omap aes support on this N900 device (with special bootloader) is working. Maybe some other data are missing in DT or in hwmod? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
testing script for n900
When you are drowning in regressions ..then the first step is to stop more regressions. That's the situation with Nokia N900 kernel now: it has a lot of hardware, and there's kernel support for most of that, but userland support really is not mature enough. So I added test script to tui/ofone, which allows testing of battery, audio, LEDs, backlight, GPS, bluetooth and more. It is called "tefone". "ofone" script (with gtk gui) can be used to control modem, place calls and read SMSes. You'll need a library to actually get voice calls with audio. More at http://pavelmachek.livejournal.com/127317.html . 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 v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
Hi
This looks correct, but if you are still going to make a new series fixing
Felipe's comments then the following tiny nitpicks could be fixed as well.
Otherwise
Acked-by: Mathias Nyman
Felipe, Do you want to take this series through your tree?
On 17.02.2015 07:41, Sneeker Yeh wrote:
>
> +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
Either add a function description explaining something like "Late clearing of
connect status.
Some quirky hardware will suspend the controller when CSC bit is cleared and
leave URBs unhandled"
Or change the function name to something like xhci_late_csc_clear_quirk() or
xhci_deferred_csc_clear_quirk()
Maybe the name should be changed anyways.
The "try to" makes it look like some non-blocking version of a csc clear
function.
> +{
> + int max_ports;
> + struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + __le32 __iomem **port_array;
> + u32 status;
> +
> + /* print debug info */
Remove this comment
> + if (hcd->speed == HCD_USB3) {
> + max_ports = xhci->num_usb3_ports;
> + port_array = xhci->usb3_ports;
> + } else {
> + max_ports = xhci->num_usb2_ports;
> + port_array = xhci->usb2_ports;
> + }
> +
> + if (dev_port_num > max_ports) {
> + xhci_err(xhci, "%s() port number invalid", __func__);
> + return;
> + }
> + status = readl(port_array[dev_port_num - 1]);
> +
> + /* write 1 to clear */
Not really a helpful comment either, either remove or change to something like
"clearing the connect status bit will now immediately suspend these quirky
controllers"
-Mathias
--
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 0/4] phy: ti-pipe3: fixes for 3.19-rc
On 18/02/15 10:00, Roger Quadros wrote: > On 13/01/15 17:54, Tony Lindgren wrote: >> * Roger Quadros [150113 04:26]: >>> Hi, >>> >>> During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain >>> active on the DRA7 platform. This is because the pipe3 driver doesn't shut >>> them off as part of .suspend(). Patch 1 addresses this issue. >>> >>> SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a >>> system suspend/resume or if AHCI_PLATFORM driver is used as module. >>> Patches 2,3,4 fix it. >>> >>> Hope to get these patches in through the 3.19-rc cycle. >>> >>> Tony, >>> >>> Do you wish to take the DTS patches or let them go in through PHY tree? >> >> Those look ok to me to merge along with the fixes, will ack those two. >> > > Looks like this missed 3.19-rc. My bad for not following up. > > Kishon, can you please queue these for 3.20-rc? Thanks. Well the PHY patches (1 and 2) are already queued for v3.20-rc1 via Greg's usb-next tree. Tony can you please queue the DT side patches for v3.20? Thanks. 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 v3 0/4] phy: ti-pipe3: fixes for 3.19-rc
On 13/01/15 17:54, Tony Lindgren wrote: > * Roger Quadros [150113 04:26]: >> Hi, >> >> During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain >> active on the DRA7 platform. This is because the pipe3 driver doesn't shut >> them off as part of .suspend(). Patch 1 addresses this issue. >> >> SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a >> system suspend/resume or if AHCI_PLATFORM driver is used as module. >> Patches 2,3,4 fix it. >> >> Hope to get these patches in through the 3.19-rc cycle. >> >> Tony, >> >> Do you wish to take the DTS patches or let them go in through PHY tree? > > Those look ok to me to merge along with the fixes, will ack those two. > Looks like this missed 3.19-rc. My bad for not following up. Kishon, can you please queue these for 3.20-rc? Thanks. 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
