* Re: PCI device not working
From: Davide Viti @ 2012-09-24 20:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nk-5zz2zht6suNx+BVCQtkxPFPL33uZFSuGpxT8YFFqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6633 bytes --]
Here are the settings for PCI we currently have in uboot:
#define CONFIG_PCI 1 /* Enable PCI/PCIE */
#define CONFIG_PCIE1 1 /* PCIE controler 1
(slot 1) */
#define CONFIG_PCIE2 1 /* PCIE controler 2
(slot 2) */
#define CONFIG_FSL_PCI_INIT 1 /* Use common FSL init code
*/
#define CONFIG_FSL_PCIE_RESET 1 /* need PCIe reset errata */
#define CONFIG_FSL_LAW 1 /* Use common FSL init code
*/
#define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0x9000)
#define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0xa000)
/*
* General PCI
*/
#define CONFIG_SYS_PCIE1_MEM_VIRT 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_BUS 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_PHYS 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_SIZE 0x10000000
#define CONFIG_SYS_PCIE1_IO_VIRT 0xFFC10000
#define CONFIG_SYS_PCIE1_IO_BUS 0x00000000
#define CONFIG_SYS_PCIE1_IO_PHYS 0xFFC10000
#define CONFIG_SYS_PCIE1_IO_SIZE 0x00010000 /* 64k */
#define CONFIG_SYS_PCIE2_MEM_VIRT 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_BUS 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_PHYS 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_SIZE 0x10000000
#define CONFIG_SYS_PCIE2_IO_VIRT 0xFFC00000
#define CONFIG_SYS_PCIE2_IO_BUS 0x00000000
#define CONFIG_SYS_PCIE2_IO_PHYS 0xFFC00000
#define CONFIG_SYS_PCIE2_IO_SIZE 0x00010000 /* 64k */
I'd really appreciate I you could take a look at it
Thanx alot in advance
Davide
2012/9/24 Davide Viti <zinosat@tiscali.it>
> Hi,
> does the output I've included show anything wrong or should I post
> something else to help identifying the cause of the problem?
>
> thank you in advance,
> Davide
>
> 2012/9/21 Davide Viti <zinosat@tiscali.it>
>
>> I mean there are two controllers and both of them have a device
>> "subtended" (both 0x1b65:0xabba).
>> u-boot can see both devices, linux detects only the device attached to
>> the first controller.
>>
>> Here's the output of lspci and /proc/iomem :
>>
>> root@(none):/# lspci -v
>>
>> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>>
>> Flags: bus master, fast devsel, latency 0
>>
>> Memory at <ignored> (32-bit, non-prefetchable)
>>
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>
>> I/O behind bridge: 00000000-00000fff
>>
>> Memory behind bridge: a0000000-afffffff
>>
>> Capabilities: [44] Power Management version 2
>>
>> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>>
>> Capabilities: [100] Advanced Error Reporting
>>
>>
>>
>> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>>
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>>
>> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>>
>> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>>
>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>> Capabilities: [78] Power Management version 3
>>
>> Capabilities: [80] Express Endpoint, MSI 00
>>
>> Capabilities: [100] Virtual Channel <?>
>>
>> Capabilities: [800] Advanced Error Reporting
>>
>>
>>
>> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>>
>> Flags: bus master, fast devsel, latency 0
>>
>> Memory at <ignored> (32-bit, non-prefetchable)
>>
>> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>>
>> I/O behind bridge: 00000000-00000fff
>>
>> Memory behind bridge: b0000000-bfffffff
>>
>> Capabilities: [44] Power Management version 2
>>
>> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>>
>> Capabilities: [100] Advanced Error Reporting
>>
>>
>> root@(none):/# cat /proc/iomem
>>
>> a0000000-afffffff : /pcie@ffe09000
>>
>> a0000000-afffffff : PCI Bus 0000:01
>>
>> a0000000-a00003ff : 0000:01:00.0
>>
>> a0010000-a001ffff : 0000:01:00.0
>>
>> b0000000-bfffffff : /pcie@ffe0a000
>>
>> b0000000-bfffffff : PCI Bus 0001:03
>>
>> ef000000-efffffff : ef000000.nor
>>
>> ffe04500-ffe04507 : serial
>>
>> ffe04600-ffe04607 : serial
>>
>>
>> thanx for your help,
>>
>> Davide
>>
>>
>> I mean that the kernel detects the first controller and the device
>> attached to it, plus the second controller: the device on the second
>> controller is not detected (same device as the one detected on the first
>> controller)
>>
>> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>>
>>>
>>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>>
>>> > Hi,
>>> > I'm working on a custom board based on P1020 with two (identical) PCI
>>> devices attached;
>>> > The work is derived from another board with a single instance of that
>>> device.
>>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>>> >
>>> > The "pci" command on u-boot, shows me both the PCI controllers and
>>> > the attached devices:
>>> >
>>> > Scanning PCI devices on bus 0
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 00.00.00 0x1957 0x0100 Processor 0x20
>>> >
>>> > Scanning PCI devices on bus 1
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>>> >
>>> > Scanning PCI devices on bus 2
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 02.00.00 0x1957 0x0100 Processor 0x20
>>> >
>>> > Scanning PCI devices on bus 3
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>>> >
>>> > The kernel detects only the first instance of the device.
>>>
>>> What do you mean by first instance of the device ?
>>>
>>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>>> > asking for some help on narrowing down the problem.
>>> >
>>> > I'm wondering if I can assume that the problem is restricted to
>>> > kernel/dts and avoid concentrating on uboot.
>>> > I can provide any log (didn't want to post tons of details on the first
>>> > message)
>>>
>>> Probably a dts issue.
>>>
>>> What does lspci in linux say?
>>>
>>> - k
>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 12562 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
From: Greg KH @ 2012-09-24 17:27 UTC (permalink / raw)
To: Liu Shengzhou-B36685
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F453DDFF675A64A89321A1F352810217FFC51@039-SN1MPN1-004.039d.mgd.msft.net>
On Mon, Sep 24, 2012 at 02:44:19PM +0000, Liu Shengzhou-B36685 wrote:
>
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: 2012年9月22日 22:49
> > To: Kumar Gala
> > Cc: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org; linux-
> > usb@vger.kernel.org
> > Subject: Re: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing
> > USB PHY clock
> >
> > On Sat, Sep 22, 2012 at 09:39:15AM -0500, Kumar Gala wrote:
> > >
> > > On Sep 21, 2012, at 11:43 AM, Greg KH wrote:
> > >
> > > > On Tue, Sep 18, 2012 at 04:52:39PM +0800, Shengzhou Liu wrote:
> > > >> when missing USB PHY clock, kernel booting up will hang during USB
> > > >> initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
> > > >> CPU hanging in this case.
> > > >>
> > > >> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > > >> ---
> > > >> v3 change: no check for UTMI PHY.
> > > >> v2 change: use spin_event_timeout() instead.
> > > >>
> > > >> drivers/usb/host/ehci-fsl.c | 57 +++++++++++++++++++++++++++++--
> > -----------
> > > >> drivers/usb/host/ehci-fsl.h | 1 +
> > > >> include/linux/fsl_devices.h | 1 +
> > > >> 3 files changed, 41 insertions(+), 18 deletions(-)
> > > >
> > > > This is already applied, right?
> > > >
> > > > greg k-h
> > >
> > > It appears that v2 of the patch is applied to your usb-next branch.
> > >
> > > in drivers/usb/host/ehci-fsl.c
> > >
> > > V2:
> > > @@ -262,23 +266,34 @@ static void ehci_fsl_setup_phy(struct usb_hcd
> > *hcd,
> > > case FSL_USB2_PHY_NONE:
> > > break;
> > > }
> > > +
> > > + if ((pdata->controller_ver) && ((phy_mode ==
> > FSL_USB2_PHY_ULPI) ||
> > > + (phy_mode == FSL_USB2_PHY_UTMI))) {
> > >
> > > V3:
> > >
> > > @@ -262,23 +266,33 @@ static void ehci_fsl_setup_phy(struct usb_hcd
> > *hcd,
> > >
> > > case FSL_USB2_PHY_NONE:
> > > break;
> > > }
> > >
> > > +
> > > + if (pdata->controller_ver && (phy_mode == FSL_USB2_PHY_ULPI)) {
> > > + /* check PHY_CLK_VALID to get phy clk valid */
> >
> > Ok, can someone please make the incremental patch that I need to apply
> > here and send it to me?
> >
> > thanks,
> >
> > greg k-h
>
> Hi greg,
>
> I have sent the below incremental patch to you, please squash it into the previous patch v2, which had been applied in your usb-next branch.
> http://patchwork.ozlabs.org/patch/186443/
Given that this is a git tree, "squashing" patches does not work at all.
I'll just apply it as-is.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-24 15:48 UTC (permalink / raw)
To: key
Cc: rcj, linux-kernel, James Morris, linux-security-module,
tpmdd-devel, adlai, Ashley Lai, linuxppc-dev
In-Reply-To: <20120924141041.GA2741@ennui.austin.ibm.com>
On Mon, Sep 24, 2012 at 09:10:41AM -0500, key@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > On Wed, 12 Sep 2012, Ashley Lai wrote:
> >
> > > This patch removed the tasklet and moved the wait queue into the
> > > private structure. It also cleaned up the response CRQ path.
> > >
> > > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
> >
> >
> > Kent: any comment on this? You should probably push this to me via your
> > tree.
>
> Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> this to you today.
Ashley tells me Ben's review is in the works, so I'll send once we
have it.
Kent
>
> Kent
>
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-09-24 14:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben,
please pull mpc5xxx patches for next. Thanks!
Anatolij
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
Anatolij Gustschin (3):
powerpc/mpc5200: add dts files for ifm camera machines
dt/misc: add bindings documentation for ifm camera sensor interface
powerpc/mpc52xx_lpbfifo: optionally defer fifo transfer start
Paul Gortmaker (1):
powerpc: Option FB_FSL_DIU is not really optional for mpc512x
Richard Weinberger (1):
powerpc: 512x: Fix mpc5121_clk_get()
Documentation/devicetree/bindings/misc/ifm-csi.txt | 41 ++++++
arch/powerpc/boot/dts/o2d.dts | 47 +++++++
arch/powerpc/boot/dts/o2d.dtsi | 139 ++++++++++++++++++++
arch/powerpc/boot/dts/o2d300.dts | 52 ++++++++
arch/powerpc/boot/dts/o2dnt2.dts | 48 +++++++
arch/powerpc/boot/dts/o2i.dts | 33 +++++
arch/powerpc/boot/dts/o2mnt.dts | 33 +++++
arch/powerpc/boot/dts/o3dnt.dts | 48 +++++++
arch/powerpc/include/asm/mpc52xx.h | 2 +
arch/powerpc/platforms/512x/Kconfig | 1 +
arch/powerpc/platforms/512x/clock.c | 6 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 6 -
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 35 +++++-
14 files changed, 483 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/ifm-csi.txt
create mode 100644 arch/powerpc/boot/dts/o2d.dts
create mode 100644 arch/powerpc/boot/dts/o2d.dtsi
create mode 100644 arch/powerpc/boot/dts/o2d300.dts
create mode 100644 arch/powerpc/boot/dts/o2dnt2.dts
create mode 100644 arch/powerpc/boot/dts/o2i.dts
create mode 100644 arch/powerpc/boot/dts/o2mnt.dts
create mode 100644 arch/powerpc/boot/dts/o3dnt.dts
^ permalink raw reply
* RE: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
From: Liu Shengzhou-B36685 @ 2012-09-24 14:44 UTC (permalink / raw)
To: Greg KH, Kumar Gala
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120922144853.GA10935@kroah.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdyZWcgS0ggW21haWx0bzpn
cmVnQGtyb2FoLmNvbV0NCj4gU2VudDogMjAxMsTqOdTCMjLI1SAyMjo0OQ0KPiBUbzogS3VtYXIg
R2FsYQ0KPiBDYzogTGl1IFNoZW5nemhvdS1CMzY2ODU7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxh
YnMub3JnOyBsaW51eC0NCj4gdXNiQHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIHYzXSBwb3dlcnBjL3VzYjogZml4IGJ1ZyBvZiBDUFUgaGFuZyB3aGVuIG1pc3NpbmcNCj4g
VVNCIFBIWSBjbG9jaw0KPiANCj4gT24gU2F0LCBTZXAgMjIsIDIwMTIgYXQgMDk6Mzk6MTVBTSAt
MDUwMCwgS3VtYXIgR2FsYSB3cm90ZToNCj4gPg0KPiA+IE9uIFNlcCAyMSwgMjAxMiwgYXQgMTE6
NDMgQU0sIEdyZWcgS0ggd3JvdGU6DQo+ID4NCj4gPiA+IE9uIFR1ZSwgU2VwIDE4LCAyMDEyIGF0
IDA0OjUyOjM5UE0gKzA4MDAsIFNoZW5nemhvdSBMaXUgd3JvdGU6DQo+ID4gPj4gd2hlbiBtaXNz
aW5nIFVTQiBQSFkgY2xvY2ssIGtlcm5lbCBib290aW5nIHVwIHdpbGwgaGFuZyBkdXJpbmcgVVNC
DQo+ID4gPj4gaW5pdGlhbGl6YXRpb24uIFdlIHNob3VsZCBjaGVjayBVU0JHUFtQSFlfQ0xLX1ZB
TElEXSBiaXQgdG8gYXZvaWQNCj4gPiA+PiBDUFUgaGFuZ2luZyBpbiB0aGlzIGNhc2UuDQo+ID4g
Pj4NCj4gPiA+PiBTaWduZWQtb2ZmLWJ5OiBTaGVuZ3pob3UgTGl1IDxTaGVuZ3pob3UuTGl1QGZy
ZWVzY2FsZS5jb20+DQo+ID4gPj4gLS0tDQo+ID4gPj4gdjMgY2hhbmdlOiBubyBjaGVjayBmb3Ig
VVRNSSBQSFkuDQo+ID4gPj4gdjIgY2hhbmdlOiB1c2Ugc3Bpbl9ldmVudF90aW1lb3V0KCkgaW5z
dGVhZC4NCj4gPiA+Pg0KPiA+ID4+IGRyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYyB8ICAgNTcg
KysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPiAtLS0tLS0tLS0tLQ0KPiA+ID4+IGRy
aXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuaCB8ICAgIDEgKw0KPiA+ID4+IGluY2x1ZGUvbGludXgv
ZnNsX2RldmljZXMuaCB8ICAgIDEgKw0KPiA+ID4+IDMgZmlsZXMgY2hhbmdlZCwgNDEgaW5zZXJ0
aW9ucygrKSwgMTggZGVsZXRpb25zKC0pDQo+ID4gPg0KPiA+ID4gVGhpcyBpcyBhbHJlYWR5IGFw
cGxpZWQsIHJpZ2h0Pw0KPiA+ID4NCj4gPiA+IGdyZWcgay1oDQo+ID4NCj4gPiBJdCBhcHBlYXJz
IHRoYXQgdjIgb2YgdGhlIHBhdGNoIGlzIGFwcGxpZWQgdG8geW91ciB1c2ItbmV4dCBicmFuY2gu
DQo+ID4NCj4gPiBpbiBkcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNsLmMNCj4gPg0KPiA+IFYyOg0K
PiA+IEBAIC0yNjIsMjMgKzI2NiwzNCBAQCBzdGF0aWMgdm9pZCBlaGNpX2ZzbF9zZXR1cF9waHko
c3RydWN0IHVzYl9oY2QNCj4gKmhjZCwNCj4gPiAgICAgICAgIGNhc2UgRlNMX1VTQjJfUEhZX05P
TkU6DQo+ID4gICAgICAgICAgICAgICAgIGJyZWFrOw0KPiA+ICAgICAgICAgfQ0KPiA+ICsNCj4g
PiArICAgICAgIGlmICgocGRhdGEtPmNvbnRyb2xsZXJfdmVyKSAmJiAoKHBoeV9tb2RlID09DQo+
IEZTTF9VU0IyX1BIWV9VTFBJKSB8fA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIChwaHlf
bW9kZSA9PSBGU0xfVVNCMl9QSFlfVVRNSSkpKSB7DQo+ID4NCj4gPiBWMzoNCj4gPg0KPiA+IEBA
IC0yNjIsMjMgKzI2NiwzMyBAQCAgc3RhdGljIHZvaWQgZWhjaV9mc2xfc2V0dXBfcGh5KHN0cnVj
dCB1c2JfaGNkDQo+ICpoY2QsDQo+ID4NCj4gPiAgCWNhc2UgRlNMX1VTQjJfUEhZX05PTkU6DQo+
ID4gIAkJYnJlYWs7DQo+ID4gIAl9DQo+ID4NCj4gPiArDQo+ID4gKwlpZiAocGRhdGEtPmNvbnRy
b2xsZXJfdmVyICYmIChwaHlfbW9kZSA9PSBGU0xfVVNCMl9QSFlfVUxQSSkpIHsNCj4gPiArCQkv
KiBjaGVjayBQSFlfQ0xLX1ZBTElEIHRvIGdldCBwaHkgY2xrIHZhbGlkICovDQo+IA0KPiBPaywg
Y2FuIHNvbWVvbmUgcGxlYXNlIG1ha2UgdGhlIGluY3JlbWVudGFsIHBhdGNoIHRoYXQgSSBuZWVk
IHRvIGFwcGx5DQo+IGhlcmUgYW5kIHNlbmQgaXQgdG8gbWU/DQo+IA0KPiB0aGFua3MsDQo+IA0K
PiBncmVnIGstaA0KDQpIaSBncmVnLA0KDQpJIGhhdmUgc2VudCB0aGUgYmVsb3cgaW5jcmVtZW50
YWwgcGF0Y2ggdG8geW91LCBwbGVhc2Ugc3F1YXNoIGl0IGludG8gdGhlIHByZXZpb3VzIHBhdGNo
IHYyLCB3aGljaCBoYWQgYmVlbiBhcHBsaWVkIGluIHlvdXIgdXNiLW5leHQgYnJhbmNoLiANCmh0
dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wYXRjaC8xODY0NDMvDQoNClRoYW5rcywNClNoZW5n
emhvdQ0KDQo=
^ permalink raw reply
* Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Tabi Timur-B04825 @ 2012-09-24 14:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lan Chunhe-B25806, linuxppc-dev@lists.ozlabs.org,
Gala Kumar-B11780, cjb@laptop.org, linux-mmc@vger.kernel.org
In-Reply-To: <201209241317.32425.arnd@arndb.de>
On Mon, Sep 24, 2012 at 8:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> static inline void mmc_delay(unsigned int ms)
>> {
>> msleep(ms);
>> }
>
> That would be my preferred choice, unless someone has specific issues wit=
h this.
If we're going to do that, then just get rid of mmc_delay and replace
all calls to it with msleep(). Why bother with the inline function?
There's nothing really MMC-specific about it.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] powerpc/usb: remove checking PHY_CLK_VALID for UTMI PHY
From: Shengzhou Liu @ 2012-09-24 14:01 UTC (permalink / raw)
To: linuxppc-dev, greg; +Cc: linux-usb, Shengzhou Liu
PHY_CLK_VALID bit doesn't work properly with UTMI PHY.
e.g. This bit is always zero on P5040, etc.
There is no need to check this bit for UTMI PHY, just keep
checking for ULPI PHY to prevent system hanging.
This patch should be squashed into previous commit 3735ba8db8e6e
"powerpc/usb: fix bug of CPU hang when missing USB PHY clock"
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 3 +--
include/linux/fsl_devices.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 11ff4b4..9bfde82 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -267,8 +267,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
break;
}
- if ((pdata->controller_ver) && ((phy_mode == FSL_USB2_PHY_ULPI) ||
- (phy_mode == FSL_USB2_PHY_UTMI))) {
+ if (pdata->controller_ver && (phy_mode == FSL_USB2_PHY_ULPI)) {
/* check PHY_CLK_VALID to get phy clk valid */
if (!spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0)) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index ccfc4bb..700bf31 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -19,7 +19,7 @@
#define FSL_UTMI_PHY_DLY 10 /*As per P1010RM, delay for UTMI
PHY CLK to become stable - 10ms*/
-#define FSL_USB_PHY_CLK_TIMEOUT 1000 /* uSec */
+#define FSL_USB_PHY_CLK_TIMEOUT 10000 /* uSec */
#define FSL_USB_VER_OLD 0
#define FSL_USB_VER_1_6 1
#define FSL_USB_VER_2_2 2
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-24 14:10 UTC (permalink / raw)
To: James Morris
Cc: key, linux-kernel, Ashley Lai, linux-security-module, tpmdd-devel,
adlai, rcj, linuxppc-dev
In-Reply-To: <alpine.LRH.2.02.1209241225230.678@tundra.namei.org>
On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> On Wed, 12 Sep 2012, Ashley Lai wrote:
>
> > This patch removed the tasklet and moved the wait queue into the
> > private structure. It also cleaned up the response CRQ path.
> >
> > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
>
>
> Kent: any comment on this? You should probably push this to me via your
> tree.
Oh, I thought we were waiting on Ben. This looks good to me, I'll get
this to you today.
Kent
>
>
> > ---
> > James,
> >
> > This patch is based on your "next" branch.
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> >
> > Thanks,
> > Ashley Lai
> > ---
> > drivers/char/tpm/tpm_ibmvtpm.c | 81 +++++++++++++++---------------------------
> > drivers/char/tpm/tpm_ibmvtpm.h | 5 ++-
> > 2 files changed, 30 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> > index efc4ab3..88a95ea 100644
> > --- a/drivers/char/tpm/tpm_ibmvtpm.c
> > +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> > @@ -38,8 +38,6 @@ static struct vio_device_id tpm_ibmvtpm_device_table[] __devinitdata = {
> > };
> > MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
> >
> > -DECLARE_WAIT_QUEUE_HEAD(wq);
> > -
> > /**
> > * ibmvtpm_send_crq - Send a CRQ request
> > * @vdev: vio device struct
> > @@ -83,6 +81,7 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > {
> > struct ibmvtpm_dev *ibmvtpm;
> > u16 len;
> > + int sig;
> >
> > ibmvtpm = (struct ibmvtpm_dev *)chip->vendor.data;
> >
> > @@ -91,22 +90,23 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > return 0;
> > }
> >
> > - wait_event_interruptible(wq, ibmvtpm->crq_res.len != 0);
> > + sig = wait_event_interruptible(ibmvtpm->wq, ibmvtpm->res_len != 0);
> > + if (sig)
> > + return -EINTR;
> > +
> > + len = ibmvtpm->res_len;
> >
> > - if (count < ibmvtpm->crq_res.len) {
> > + if (count < len) {
> > dev_err(ibmvtpm->dev,
> > "Invalid size in recv: count=%ld, crq_size=%d\n",
> > - count, ibmvtpm->crq_res.len);
> > + count, len);
> > return -EIO;
> > }
> >
> > spin_lock(&ibmvtpm->rtce_lock);
> > - memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, ibmvtpm->crq_res.len);
> > - memset(ibmvtpm->rtce_buf, 0, ibmvtpm->crq_res.len);
> > - ibmvtpm->crq_res.valid = 0;
> > - ibmvtpm->crq_res.msg = 0;
> > - len = ibmvtpm->crq_res.len;
> > - ibmvtpm->crq_res.len = 0;
> > + memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, len);
> > + memset(ibmvtpm->rtce_buf, 0, len);
> > + ibmvtpm->res_len = 0;
> > spin_unlock(&ibmvtpm->rtce_lock);
> > return len;
> > }
> > @@ -273,7 +273,6 @@ static int __devexit tpm_ibmvtpm_remove(struct vio_dev *vdev)
> > int rc = 0;
> >
> > free_irq(vdev->irq, ibmvtpm);
> > - tasklet_kill(&ibmvtpm->tasklet);
> >
> > do {
> > if (rc)
> > @@ -372,7 +371,6 @@ static int ibmvtpm_reset_crq(struct ibmvtpm_dev *ibmvtpm)
> > static int tpm_ibmvtpm_resume(struct device *dev)
> > {
> > struct ibmvtpm_dev *ibmvtpm = ibmvtpm_get_data(dev);
> > - unsigned long flags;
> > int rc = 0;
> >
> > do {
> > @@ -387,10 +385,11 @@ static int tpm_ibmvtpm_resume(struct device *dev)
> > return rc;
> > }
> >
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > - vio_disable_interrupts(ibmvtpm->vdev);
> > - tasklet_schedule(&ibmvtpm->tasklet);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > + rc = vio_enable_interrupts(ibmvtpm->vdev);
> > + if (rc) {
> > + dev_err(dev, "Error vio_enable_interrupts rc=%d\n", rc);
> > + return rc;
> > + }
> >
> > rc = ibmvtpm_crq_send_init(ibmvtpm);
> > if (rc)
> > @@ -467,7 +466,7 @@ static struct ibmvtpm_crq *ibmvtpm_crq_get_next(struct ibmvtpm_dev *ibmvtpm)
> > if (crq->valid & VTPM_MSG_RES) {
> > if (++crq_q->index == crq_q->num_entry)
> > crq_q->index = 0;
> > - rmb();
> > + smp_rmb();
> > } else
> > crq = NULL;
> > return crq;
> > @@ -535,11 +534,9 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> > ibmvtpm->vtpm_version = crq->data;
> > return;
> > case VTPM_TPM_COMMAND_RES:
> > - ibmvtpm->crq_res.valid = crq->valid;
> > - ibmvtpm->crq_res.msg = crq->msg;
> > - ibmvtpm->crq_res.len = crq->len;
> > - ibmvtpm->crq_res.data = crq->data;
> > - wake_up_interruptible(&wq);
> > + /* len of the data in rtce buffer */
> > + ibmvtpm->res_len = crq->len;
> > + wake_up_interruptible(&ibmvtpm->wq);
> > return;
> > default:
> > return;
> > @@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> > static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
> > {
> > struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
> > - unsigned long flags;
> > -
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > - vio_disable_interrupts(ibmvtpm->vdev);
> > - tasklet_schedule(&ibmvtpm->tasklet);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > -
> > - return IRQ_HANDLED;
> > -}
> > -
> > -/**
> > - * ibmvtpm_tasklet - Interrupt handler tasklet
> > - * @data: ibm vtpm device struct
> > - *
> > - * Returns:
> > - * Nothing
> > - **/
> > -static void ibmvtpm_tasklet(void *data)
> > -{
> > - struct ibmvtpm_dev *ibmvtpm = data;
> > struct ibmvtpm_crq *crq;
> > - unsigned long flags;
> >
> > - spin_lock_irqsave(&ibmvtpm->lock, flags);
> > + /* while loop is needed for initial setup (get version and
> > + * get rtce_size). There should be only one tpm request at any
> > + * given time.
> > + */
> > while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
> > ibmvtpm_crq_process(crq, ibmvtpm);
> > crq->valid = 0;
> > - wmb();
> > + smp_wmb();
> > }
> >
> > - vio_enable_interrupts(ibmvtpm->vdev);
> > - spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > + return IRQ_HANDLED;
> > }
> >
> > /**
> > @@ -650,9 +628,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> > goto reg_crq_cleanup;
> > }
> >
> > - tasklet_init(&ibmvtpm->tasklet, (void *)ibmvtpm_tasklet,
> > - (unsigned long)ibmvtpm);
> > -
> > rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
> > tpm_ibmvtpm_driver_name, ibmvtpm);
> > if (rc) {
> > @@ -666,13 +641,14 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> > goto init_irq_cleanup;
> > }
> >
> > + init_waitqueue_head(&ibmvtpm->wq);
> > +
> > crq_q->index = 0;
> >
> > ibmvtpm->dev = dev;
> > ibmvtpm->vdev = vio_dev;
> > chip->vendor.data = (void *)ibmvtpm;
> >
> > - spin_lock_init(&ibmvtpm->lock);
> > spin_lock_init(&ibmvtpm->rtce_lock);
> >
> > rc = ibmvtpm_crq_send_init(ibmvtpm);
> > @@ -689,7 +665,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> >
> > return rc;
> > init_irq_cleanup:
> > - tasklet_kill(&ibmvtpm->tasklet);
> > do {
> > rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address);
> > } while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1));
> > diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
> > index 4296eb4..bd82a79 100644
> > --- a/drivers/char/tpm/tpm_ibmvtpm.h
> > +++ b/drivers/char/tpm/tpm_ibmvtpm.h
> > @@ -38,13 +38,12 @@ struct ibmvtpm_dev {
> > struct vio_dev *vdev;
> > struct ibmvtpm_crq_queue crq_queue;
> > dma_addr_t crq_dma_handle;
> > - spinlock_t lock;
> > - struct tasklet_struct tasklet;
> > u32 rtce_size;
> > void __iomem *rtce_buf;
> > dma_addr_t rtce_dma_handle;
> > spinlock_t rtce_lock;
> > - struct ibmvtpm_crq crq_res;
> > + wait_queue_head_t wq;
> > + u16 res_len;
> > u32 vtpm_version;
> > };
> >
> > --
> > 1.7.11.2
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> James Morris
> <jmorris@namei.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-24 13:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nTu9XXFgz7i5-1LmetrV05qfQcdf1zGxqHzODgQ7xjKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4724 bytes --]
Hi,
does the output I've included show anything wrong or should I post
something else to help identifying the cause of the problem?
thank you in advance,
Davide
2012/9/21 Davide Viti <zinosat@tiscali.it>
> I mean there are two controllers and both of them have a device
> "subtended" (both 0x1b65:0xabba).
> u-boot can see both devices, linux detects only the device attached to the
> first controller.
>
> Here's the output of lspci and /proc/iomem :
>
> root@(none):/# lspci -v
>
> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: a0000000-afffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
>
> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>
> Flags: bus master, fast devsel, latency 0, IRQ 16
>
> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>
> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>
> Capabilities: [78] Power Management version 3
>
> Capabilities: [80] Express Endpoint, MSI 00
>
> Capabilities: [100] Virtual Channel <?>
>
> Capabilities: [800] Advanced Error Reporting
>
>
>
> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: b0000000-bfffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
> root@(none):/# cat /proc/iomem
>
> a0000000-afffffff : /pcie@ffe09000
>
> a0000000-afffffff : PCI Bus 0000:01
>
> a0000000-a00003ff : 0000:01:00.0
>
> a0010000-a001ffff : 0000:01:00.0
>
> b0000000-bfffffff : /pcie@ffe0a000
>
> b0000000-bfffffff : PCI Bus 0001:03
>
> ef000000-efffffff : ef000000.nor
>
> ffe04500-ffe04507 : serial
>
> ffe04600-ffe04607 : serial
>
>
> thanx for your help,
>
> Davide
>
>
> I mean that the kernel detects the first controller and the device
> attached to it, plus the second controller: the device on the second
> controller is not detected (same device as the one detected on the first
> controller)
>
> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>
>>
>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>
>> > Hi,
>> > I'm working on a custom board based on P1020 with two (identical) PCI
>> devices attached;
>> > The work is derived from another board with a single instance of that
>> device.
>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>> >
>> > The "pci" command on u-boot, shows me both the PCI controllers and
>> > the attached devices:
>> >
>> > Scanning PCI devices on bus 0
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 00.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 1
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > Scanning PCI devices on bus 2
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 02.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 3
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > The kernel detects only the first instance of the device.
>>
>> What do you mean by first instance of the device ?
>>
>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>> > asking for some help on narrowing down the problem.
>> >
>> > I'm wondering if I can assume that the problem is restricted to
>> > kernel/dts and avoid concentrating on uboot.
>> > I can provide any log (didn't want to post tons of details on the first
>> > message)
>>
>> Probably a dts issue.
>>
>> What does lspci in linux say?
>>
>> - k
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 10282 bytes --]
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-24 13:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nTu9XXFgz7i5-1LmetrV05qfQcdf1zGxqHzODgQ7xjKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]
2012/9/21 Davide Viti <zinosat@tiscali.it>
> I mean there are two controllers and both of them have a device
> "subtended" (both 0x1b65:0xabba).
> u-boot can see both devices, linux detects only the device attached to the
> first controller.
>
> Here's the output of lspci and /proc/iomem :
>
> root@(none):/# lspci -v
>
> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: a0000000-afffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
>
> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>
> Flags: bus master, fast devsel, latency 0, IRQ 16
>
> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>
> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>
> Capabilities: [78] Power Management version 3
>
> Capabilities: [80] Express Endpoint, MSI 00
>
> Capabilities: [100] Virtual Channel <?>
>
> Capabilities: [800] Advanced Error Reporting
>
>
>
> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>
> Flags: bus master, fast devsel, latency 0
>
> Memory at <ignored> (32-bit, non-prefetchable)
>
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>
> I/O behind bridge: 00000000-00000fff
>
> Memory behind bridge: b0000000-bfffffff
>
> Capabilities: [44] Power Management version 2
>
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>
> Capabilities: [100] Advanced Error Reporting
>
>
> root@(none):/# cat /proc/iomem
>
> a0000000-afffffff : /pcie@ffe09000
>
> a0000000-afffffff : PCI Bus 0000:01
>
> a0000000-a00003ff : 0000:01:00.0
>
> a0010000-a001ffff : 0000:01:00.0
>
> b0000000-bfffffff : /pcie@ffe0a000
>
> b0000000-bfffffff : PCI Bus 0001:03
>
> ef000000-efffffff : ef000000.nor
>
> ffe04500-ffe04507 : serial
>
> ffe04600-ffe04607 : serial
>
>
> thanx for your help,
>
> Davide
>
>
> I mean that the kernel detects the first controller and the device
> attached to it, plus the second controller: the device on the second
> controller is not detected (same device as the one detected on the first
> controller)
>
> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>
>>
>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>
>> > Hi,
>> > I'm working on a custom board based on P1020 with two (identical) PCI
>> devices attached;
>> > The work is derived from another board with a single instance of that
>> device.
>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>> >
>> > The "pci" command on u-boot, shows me both the PCI controllers and
>> > the attached devices:
>> >
>> > Scanning PCI devices on bus 0
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 00.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 1
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > Scanning PCI devices on bus 2
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 02.00.00 0x1957 0x0100 Processor 0x20
>> >
>> > Scanning PCI devices on bus 3
>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>> > _____________________________________________________________
>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>> >
>> > The kernel detects only the first instance of the device.
>>
>> What do you mean by first instance of the device ?
>>
>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>> > asking for some help on narrowing down the problem.
>> >
>> > I'm wondering if I can assume that the problem is restricted to
>> > kernel/dts and avoid concentrating on uboot.
>> > I can provide any log (didn't want to post tons of details on the first
>> > message)
>>
>> Probably a dts issue.
>>
>> What does lspci in linux say?
>>
>> - k
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 9528 bytes --]
^ permalink raw reply
* Re: [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Alan Cox @ 2012-09-24 13:21 UTC (permalink / raw)
To: Christophe Leroy
Cc: Marcelo Tosatti, linuxppc-dev, linux-kernel, linux-serial
In-Reply-To: <201209240639.q8O6di6f029596@localhost.localdomain>
On Mon, 24 Sep 2012 08:39:44 +0200
Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> MAXIDL is the timeout after which a receive buffer is closed when not
> full if no more characters are received. We calculate it from the
> baudrate so that the duration is always the same at standard rates:
> about 4ms. At 9600 bauds it gives a timeout of 4 characters, which is
> the timeout on the 8250 UART.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Looks good tome - series Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Arnd Bergmann @ 2012-09-24 13:17 UTC (permalink / raw)
To: Chunhe Lan; +Cc: kumar.gala, linux-mmc, cjb, linuxppc-dev, Chunhe Lan
In-Reply-To: <50607A5A.3060103@freescale.com>
On Monday 24 September 2012, Chunhe Lan wrote:
> OK. As you have mentioned, it would been modified to such:
>
> static inline void mmc_delay(unsigned int ms)
> {
> if (ms < 1000 / HZ) {
> cond_resched();
> msleep(ms);
> } else {
> msleep(ms);
> }
> }
This version would be rather broken, because it compares times
in two different units (ms and jiffies), and because it
does a cond_resched() directly before an msleep: both of which
end up calling schedule() and being away for some time,
cond_resched() for an unknown time, and msleep for a minimum
time on top of that.
> OR such:
>
> static inline void mmc_delay(unsigned int ms)
> {
> msleep(ms);
> }
That would be my preferred choice, unless someone has specific issues with this.
> OR other code?
Well, in principle, you could implement something like
static inline void mmc_delay(unsigned int ms)
{
ktime_t end = ktime_add_us(ktime_get(), ms * 1000);
while (1) {
s64 remaining;
cond_resched();
remaining = ktime_to_us(ktime_sub(end, ktime_get()));
if (remaining < 0)
break;
udelay(min_t(u32, remaining, 100));
}
}
Arnd
^ permalink raw reply
* Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Kumar Gala @ 2012-09-24 12:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org list, Hu Mingkai-B21284,
Chen Yuanquan-B41889, Xie Shaohui-B21989
In-Reply-To: <B042FA91-05A5-4AE8-BCCE-74F843491F50@kernel.crashing.org>
On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
>=20
> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>=20
>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>=20
>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>> greater than the device's DMA capability and device uses
>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>=20
>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>> __GFP_DMA &
>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>> total memory size. By doing this, devices which cannot DMA all =
the
>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>> all
>>>> the memory will not be affected by this limitation.
>>>>>>=20
>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>>> ---
>>>>>> changes for v2:
>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>=20
>>>>=20
>>>> There must have been a misunderstanding. I think this should be a
>>>> runtime choice, possibly by the platform code. Any reason that =
can't be
>>> done ?
>>>>=20
>>> [S.H] Do you mean this:
>>>=20
>>> phys_addr_t platform_dma_size (maybe a default value should be used, =
then
>>> platform code will change it)
>>>=20
>>> if (top_of_ram > platform_dma_size)
>>> max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>>> max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>>> Also how does Intel do it ?
>>> [S.H] below are codes in Intel:
>>>=20
>>> 403 void __init zone_sizes_init(void)
>>> 404 {
>>> 405 unsigned long max_zone_pfns[MAX_NR_ZONES];
>>> 406
>>> 407 memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>> 408
>>> 409 #ifdef CONFIG_ZONE_DMA
>>> 410 max_zone_pfns[ZONE_DMA] =3D MAX_DMA_PFN;
>>> 411 #endif
>>> 412 #ifdef CONFIG_ZONE_DMA32
>>> 413 max_zone_pfns[ZONE_DMA32] =3D MAX_DMA32_PFN;
>>> 414 #endif
>>> 415 max_zone_pfns[ZONE_NORMAL] =3D max_low_pfn;
>>> 416 #ifdef CONFIG_HIGHMEM
>>> 417 max_zone_pfns[ZONE_HIGHMEM] =3D max_pfn;
>>> 418 #endif
>>> 419
>>>=20
>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three =
zones:
>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>=20
>> [S.H] Hello, Ben,
>>=20
>> I have some questions, though I'm still expecting your comments.
>> PPC does not have ZONE_DMA32 by default, if we want to use it, we =
need to add "config ZONE_DMA32" in Kconfig first.
>> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>> Then what the size should be set for them respectively?
>>=20
>> Please comment, Thanks!
>=20
> I think Ben is saying that Kconfig would enable ZONE_DMA32 for all =
PPC64, but make it runtime/per platform how we setup the zone's such =
that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value =
as ZONE_DMA.
>=20
> However that's just a guess.
Ben,
Can you help clarify your thoughts here.
thanks
- k=
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-24 9:41 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <20120924080633.GA8127@visitor2.iram.es>
On Mon, 2012-09-24 at 10:06 +0200, Gabriel Paubert wrote:
> > Which we do. mfpvr is available as a fallback (essentially because if we
> > don't do it somebody's going to parse /proc/cpuinfo which is arguably
> > worse :-)
>
> Fine. But I believe that mfpvr emulation came first, which is the point
> I object to (see the mess that the fact that CPUID is available to
> applications made to x86 when SSE registers were added).
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
> Bottom line, the mappin between PVR and capabilities offered to
> applications should happen in one place, and this place is the kernel.
Yes, we all agree here.
> >
> > We should definitely advertise the availability of isel.
>
> Agreed.
If somebody has 5mn, patch welcome :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Gabriel Paubert @ 2012-09-24 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348473517.1132.87.camel@pasglop>
On Mon, Sep 24, 2012 at 05:58:37PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
> > On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> > > Why does the kernel emulate this, btw? I can see emulation is useful
> > > for running older binaries, for instructions that have been removed
> > > from the architecture; but for newly added instructions, or optional
> > > instructions, it hurts more than it helps?
> >
> > Indeed. I also don't understand why mfpvr is emulated. That's the kind
> > of information that should be passed to the executables through auxiliary
> > vectors. After all, you can (or could at least) compile a kernel without
> > Altivec support and run it on a processor with Altivec.
> >
> > Therefore, whether Altivec is supported or not, is a matter of
> > processor and kernel options. Provide this information through
> > the auxiliary vector and the problem is solved.
>
> Which we do. mfpvr is available as a fallback (essentially because if we
> don't do it somebody's going to parse /proc/cpuinfo which is arguably
> worse :-)
Fine. But I believe that mfpvr emulation came first, which is the point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Bottom line, the mappin between PVR and capabilities offered to
applications should happen in one place, and this place is the kernel.
>
> We should definitely advertise the availability of isel.
Agreed.
Cheers,
Gabriel
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-24 7:58 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <20120924075546.GA4263@visitor2.iram.es>
On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
> On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> > Why does the kernel emulate this, btw? I can see emulation is useful
> > for running older binaries, for instructions that have been removed
> > from the architecture; but for newly added instructions, or optional
> > instructions, it hurts more than it helps?
>
> Indeed. I also don't understand why mfpvr is emulated. That's the kind
> of information that should be passed to the executables through auxiliary
> vectors. After all, you can (or could at least) compile a kernel without
> Altivec support and run it on a processor with Altivec.
>
> Therefore, whether Altivec is supported or not, is a matter of
> processor and kernel options. Provide this information through
> the auxiliary vector and the problem is solved.
Which we do. mfpvr is available as a fallback (essentially because if we
don't do it somebody's going to parse /proc/cpuinfo which is arguably
worse :-)
We should definitely advertise the availability of isel.
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Gabriel Paubert @ 2012-09-24 7:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <35A5B006-1E4E-4355-A6A4-CA5F7371D21C@kernel.crashing.org>
On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
> Why does the kernel emulate this, btw? I can see emulation is useful
> for running older binaries, for instructions that have been removed
> from the architecture; but for newly added instructions, or optional
> instructions, it hurts more than it helps?
Indeed. I also don't understand why mfpvr is emulated. That's the kind
of information that should be passed to the executables through auxiliary
vectors. After all, you can (or could at least) compile a kernel without
Altivec support and run it on a processor with Altivec.
Therefore, whether Altivec is supported or not, is a matter of
processor and kernel options. Provide this information through
the auxiliary vector and the problem is solved.
Gabriel
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Li Zhong @ 2012-09-24 6:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1348464657.1132.86.camel@pasglop>
On Mon, 2012-09-24 at 15:30 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 11:56 +0800, Li Zhong wrote:
> > This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
> >
> > The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
> > cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
> > the processor. After the hv call returns, the MSR_EE is enabled, while
> > the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
> >
> > Then when the cpu is put online again, the warning is reported when
> > start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
> > that's because when we come to local_irq_enable(), there might already have been
> > some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
> >
> > The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
> > returns, and before calling start_secondary_resume().
>
Hi Ben,
> Is that enough ? Do we know for sure we won't get a stray IPI or
> interrupt which then will reach us with an inconsistent HW/SW enable
> state ?
I thought when coming to here, there should be no IPI or interrupt for
this cpu ...
> We might need to "sanitize" the enable state in the PACA before we
> actually enter NAP or in the return from NAP code, like we do for normal
> idle code...
Do you mean something like this in extended_cede_processor() to make
sure HW/SW enable state consistent?
+ prep_irq_for_idle();
rc = cede_processor();
+#ifdef CONFIG_TRACE_IRQFLAGS
+ /* Ensure that H_CEDE returns with IRQs on */
+ if (WARN_ON(!(mfmsr() & MSR_EE)))
+ __hard_irq_enable();
+#endif
So, normally, we will have irqs SW/HW enabled consistently. But if the
above happens (some missing IPI/interrupt ), I'm not sure whether we can
leave it to be handled after cpu online again?
Please correct me if I misunderstood something.
Thanks, Zhong
> Cheers,
> Ben.
>
> > [ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
> > [ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
> > [ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
> > [ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
> > [ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
> > [ 56.618913] SOFTE: 1
> > [ 56.618916] CFAR: c00000000067a5dc
> > [ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
> > GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
> > GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
> > GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
> > GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
> > GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
> > [ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
> > [ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619025] Call Trace:
> > [ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
> > [ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
> > [ 56.619052] Instruction dump:
> > [ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
> > [ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
> > [ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
> >
> > Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > index 64c97d8..8de539a 100644
> > --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > @@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
> > if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
> > unregister_slb_shadow(hwcpu);
> >
> > + __hard_irq_disable();
> > +
> > /*
> > * Call to start_secondary_resume() will not return.
> > * Kernel stack will be reset and start_secondary()
>
>
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Christophe Leroy @ 2012-09-24 6:39 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
MAXIDL is the timeout after which a receive buffer is closed when not full if
no more characters are received. We calculate it from the baudrate so that the
duration is always the same at standard rates: about 4ms. At 9600 bauds it gives
a timeout of 4 characters, which is the timeout on the 8250 UART.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -501,6 +501,7 @@
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
smc_t __iomem *smcp = pinfo->smcp;
scc_t __iomem *sccp = pinfo->sccp;
+ int maxidl;
pr_debug("CPM uart[%d]:set_termios\n", port->line);
@@ -511,6 +512,17 @@
else
pinfo->rx_fifosize = RX_BUF_SIZE;
+ /* MAXIDL is the timeout after which a receive buffer is closed
+ * when not full if no more characters are received.
+ * We calculate it from the baudrate so that the duration is
+ * always the same at standard rates: about 4ms.
+ */
+ maxidl = baud / 2400;
+ if (maxidl < 1)
+ maxidl = 1;
+ if (maxidl > 0x10)
+ maxidl = 0x10;
+
/* Character length programmed into the mode register is the
* sum of: 1 start bit, number of data bits, 0 or 1 parity bit,
* 1 or 2 stop bits, minus 1.
@@ -611,6 +623,7 @@
* SMC/SCC receiver is disabled.
*/
out_be16(&pinfo->smcup->smc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->smcup->smc_maxidl, maxidl);
/* Set the mode register. We want to keep a copy of the
* enables, because we want to put them back if they were
@@ -623,6 +636,7 @@
SMCMR_SM_UART | prev_mode);
} else {
out_be16(&pinfo->sccup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->sccup->scc_maxidl, maxidl);
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART maxidl should not depend on fifo size
From: Christophe Leroy @ 2012-09-24 6:20 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
maxidl register was set to fifo size. There is no reason to set this
register to same value as fifo size. Setting it now to 0x10 by default
as in the UCC UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -799,7 +799,7 @@
cpm_set_scc_fcr(sup);
out_be16(&sup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
- out_be16(&sup->scc_maxidl, pinfo->rx_fifosize);
+ out_be16(&sup->scc_maxidl, 0x10);
out_be16(&sup->scc_brkcr, 1);
out_be16(&sup->scc_parec, 0);
out_be16(&sup->scc_frmec, 0);
@@ -873,7 +873,7 @@
/* Using idle character time requires some additional tuning. */
out_be16(&up->smc_mrblr, pinfo->rx_fifosize);
- out_be16(&up->smc_maxidl, pinfo->rx_fifosize);
+ out_be16(&up->smc_maxidl, 0x10);
out_be16(&up->smc_brklen, 0);
out_be16(&up->smc_brkec, 0);
out_be16(&up->smc_brkcr, 1);
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART too many interrupts
From: Christophe Leroy @ 2012-09-24 6:19 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
Setting the fifo to only 1 byte generates one interrupt every 1ms at 9600 bauds.
This is too much. This patch reduces the threshold to speeds below 2400 bauds
like in the 8250 UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -71,7 +71,7 @@
/**************************************************************/
-#define HW_BUF_SPD_THRESHOLD 9600
+#define HW_BUF_SPD_THRESHOLD 2400
/*
* Check, if transmit buffers are processed
@@ -505,7 +505,7 @@
pr_debug("CPM uart[%d]:set_termios\n", port->line);
baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
- if (baud <= HW_BUF_SPD_THRESHOLD ||
+ if (baud < HW_BUF_SPD_THRESHOLD ||
(pinfo->port.state && pinfo->port.state->port.tty->low_latency))
pinfo->rx_fifosize = 1;
else
^ permalink raw reply
* [PATCH v2] Powerpc 8xx CPM_UART desynchronisation
From: Christophe Leroy @ 2012-09-24 6:17 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linuxppc-dev, linux-kernel, linux-serial
This patch fixes a desynchronisation problem with CPM UART driver on
Powerpc MPC8xx. The problem happens if data is received before the device
is open by the user application.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -417,6 +417,7 @@
clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR);
clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
}
+ cpm_uart_initbd(pinfo);
cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
}
/* Install interrupt handler. */
^ permalink raw reply
* [PATCH][v2] powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
From: Minghuan Lian @ 2012-09-24 5:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Minghuan Lian
The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this functionality.
According to PCIE specification, 'Header Type' offset 0x0e is used to
indicate header type, so change code to use 'Header Type' field to
judge PCIE mode. Because FSL PCI controller does not support 'Header Type',
patch still uses 'Programming Interface' to identify PCI mode.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Change log:
v2 -
keep the original PCI initialization order according to kumar's recommendations.
arch/powerpc/sysdev/fsl_pci.c | 37 ++++++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c37f461..468e76c 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -38,15 +38,15 @@ static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
static void __devinit quirk_fsl_pcie_header(struct pci_dev *dev)
{
- u8 progif;
+ u8 hdr_type;
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return;
/* if we aren't in host mode don't bother */
- pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
- if (progif & 0x1)
+ pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type);
+ if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
return;
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
@@ -425,7 +425,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- u8 progif;
+ u8 hdr_type, progif;
if (!of_device_is_available(dev)) {
pr_warning("%s: disabled\n", dev->full_name);
@@ -457,15 +457,17 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
PPC_INDIRECT_TYPE_BIG_ENDIAN);
- early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
- if ((progif & 1) == 1) {
- /* unmap cfg_data & cfg_addr separately if not on same page */
- if (((unsigned long)hose->cfg_data & PAGE_MASK) !=
- ((unsigned long)hose->cfg_addr & PAGE_MASK))
- iounmap(hose->cfg_data);
- iounmap(hose->cfg_addr);
- pcibios_free_controller(hose);
- return -ENODEV;
+ if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ /* For PCIE read HEADER_TYPE to identify controler mode */
+ early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, &hdr_type);
+ if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ goto no_bridge;
+
+ } else {
+ /* For PCI read PROG to identify controller mode */
+ early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
+ if ((progif & 1) == 1)
+ goto no_bridge;
}
setup_pci_cmd(hose);
@@ -494,6 +496,15 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
setup_pci_atmu(hose, &rsrc);
return 0;
+
+no_bridge:
+ /* unmap cfg_data & cfg_addr separately if not on same page */
+ if (((unsigned long)hose->cfg_data & PAGE_MASK) !=
+ ((unsigned long)hose->cfg_addr & PAGE_MASK))
+ iounmap(hose->cfg_data);
+ iounmap(hose->cfg_addr);
+ pcibios_free_controller(hose);
+ return -ENODEV;
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Benjamin Herrenschmidt @ 2012-09-24 5:30 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1348458962.2475.8.camel@ThinkPad-T420>
On Mon, 2012-09-24 at 11:56 +0800, Li Zhong wrote:
> This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
>
> The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
> cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
> the processor. After the hv call returns, the MSR_EE is enabled, while
> the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
>
> Then when the cpu is put online again, the warning is reported when
> start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
> that's because when we come to local_irq_enable(), there might already have been
> some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
>
> The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
> returns, and before calling start_secondary_resume().
Is that enough ? Do we know for sure we won't get a stray IPI or
interrupt which then will reach us with an inconsistent HW/SW enable
state ?
We might need to "sanitize" the enable state in the PACA before we
actually enter NAP or in the return from NAP code, like we do for normal
idle code...
Cheers,
Ben.
> [ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
> [ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
> [ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
> [ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
> [ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
> [ 56.618913] SOFTE: 1
> [ 56.618916] CFAR: c00000000067a5dc
> [ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
> GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
> GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
> GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
> GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
> GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
> [ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
> [ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
> [ 56.619025] Call Trace:
> [ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
> [ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
> [ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
> [ 56.619052] Instruction dump:
> [ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
> [ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
> [ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 64c97d8..8de539a 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
> if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
> unregister_slb_shadow(hwcpu);
>
> + __hard_irq_disable();
> +
> /*
> * Call to start_secondary_resume() will not return.
> * Kernel stack will be reset and start_secondary()
^ permalink raw reply
* [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Li Zhong @ 2012-09-24 3:56 UTC (permalink / raw)
To: PowerPC email list; +Cc: Paul E. McKenney, Paul Mackerras
This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
the processor. After the hv call returns, the MSR_EE is enabled, while
the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
Then when the cpu is put online again, the warning is reported when
start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
that's because when we come to local_irq_enable(), there might already have been
some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
returns, and before calling start_secondary_resume().
[ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
[ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
[ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
[ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
[ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
[ 56.618913] SOFTE: 1
[ 56.618916] CFAR: c00000000067a5dc
[ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
[ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
[ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
[ 56.619025] Call Trace:
[ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
[ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
[ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
[ 56.619052] Instruction dump:
[ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
[ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
[ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 64c97d8..8de539a 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
unregister_slb_shadow(hwcpu);
+ __hard_irq_disable();
+
/*
* Call to start_secondary_resume() will not return.
* Kernel stack will be reset and start_secondary()
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox