From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752279AbdGEAA1 (ORCPT ); Tue, 4 Jul 2017 20:00:27 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:32883 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752204AbdGEAAZ (ORCPT ); Tue, 4 Jul 2017 20:00:25 -0400 Subject: Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support To: Russell King - ARM Linux , Bjorn Helgaas Cc: Marc Gonzalez , Mark Rutland , Marc Zyngier , linux-pci , Thibaud Cornic , Ard Biesheuvel , LKML , Greg Kroah-Hartman , Thomas Gleixner , Linux ARM References: <987fac41-80dc-f1d0-ec0b-91ae57b91bfd@sigmadesigns.com> <20170702231811.GJ18324@bhelgaas-glaptop.roam.corp.google.com> <79382219-c730-da78-3e5f-5abf3173d7ac@sigmadesigns.com> <20170703134031.GG13824@bhelgaas-glaptop.roam.corp.google.com> <20170703181128.GD4902@n2100.armlinux.org.uk> From: Mason Message-ID: <0cd65cda-9a3d-8c1b-1ee9-c48f63959140@free.fr> Date: Wed, 5 Jul 2017 01:59:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 In-Reply-To: <20170703181128.GD4902@n2100.armlinux.org.uk> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2017 20:11, Russell King - ARM Linux wrote: > I don't think there's an easy solution to this problem - and I'm not > sure that stop_machine() can be made to work in this path (which > needs a process context). I have a suspicion that the Sigma Designs > PCI implementation is just soo insane that it's never going to work > reliably in a multi-SoC kernel without introducing severe performance > issues for everyone else. If I remember correctly, this is the second HW block from tango that has been deemed "too insane for Linux". The first one was the DMA engine, which doesn't interrupt when a transfer is done, but when a new transfer may be programmed. (Though there is a simple work-around for this one, if we give up command pipelining.) Do larger SoC vendors have HW devs working closely with Linux devs, to avoid these design bloopers? Regards.