linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liviu Dudau <Liviu.Dudau@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"'Jingoo Han'" <jg1.han@samsung.com>,
	"'Byungho An'" <bh74.an@samsung.com>,
	"'linux-pci'" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ilho215.lee@samsung.com" <ilho215.lee@samsung.com>,
	"'Bjorn Helgaas'" <bhelgaas@google.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC
Date: Wed, 23 Apr 2014 15:23:16 +0100	[thread overview]
Message-ID: <20140423142315.GO865@e106497-lin.cambridge.arm.com> (raw)
In-Reply-To: <4565008.ZECF3eWqge@wuerfel>

On Wed, Apr 23, 2014 at 12:03:47PM +0100, Arnd Bergmann wrote:
> On Wednesday 23 April 2014 18:19:30 Kukjin Kim wrote:
> > 
> 
> > Basically, ARMv8 based GH7 has same PCIe hardware IP with previous ARMv7
> > based exynos5440, several features in PCIe are different though. In other
> > words, basic functionalities for PCIe are same. So I think, would be nice if
> > we could use one PCIe device driver for both SoCs.
> 
> Ok, I see. I was just trying to get a feeling for how much is shared
> or SoC specific between your variants. If they are different enough,
> it may be easier to have two drivers.
> 
> > However, if we need to support the PCIe with each own device driver because
> > of difference of 32bit and 64bit, please kindly let us know. Honestly, I'm
> > not sure about that right now.
> 
> We are working already on ideas to minimize the differences between
> arm32 and arm64 PCI support, it will just take more work.
> 
> > > Also, if gh7 is expected to run a full firmware, I think you should
> > > do all the setup in the firmware before booting Linux, and just
> > > do the required run-time operations in the driver itself.
> > > 
> > Well, we're expecting that all the setup should be done by the device driver
> > in kernel not firmware.
> 
> Ok, just make sure this hardware never shows up in servers then.

Not necessarily, as long as the setup will always happen in the kernel?

> 
> Unfortunately we are in a tricky situation on arm64 because we have
> to support both server-type SoCs and embedded-type SoCs. In an
> embedded system, you can't trust the boot loader to do a proper
> setup of all the hardware, so the kernel needs full control over
> all the initialization. In a server, the initialization is the
> responsibility of the firmware, and we don't want the kernel to
> even know about those registers.
> 
> My hope is that all server chips use an SBSA compliant PCIe
> implementation, but we already have X-Gene, which is doing server
> workloads with a nonstandard PCIe, and it's possible that there
> will also be server-like systems with a DesignWare PCIe block
> instead of an SBSA compliant one. We can still support those, but
> I don't want to see more than one implementation of dw-pcie
> on servers. Just like we have the generic PCIe support that Will
> is doing for virtual machines and SBSA compliant systems, we
> would do one dw-pcie variant for all systems that come with a
> host firmware and rely on it being set up already.

There is nothing in the SBSA that mandates firmware setup. All it requires
is that hardware is setup in a way that is not specific to a board
or a particular OEM. Surely if the setup being done for GH7 is always
the same it should fit the bill?

Kind regards,
Liviu


> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯


  reply	other threads:[~2014-04-23 14:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16  4:41 [RFC PATCH 0/2] Add support for Samsung GH7 PCIe controller Jingoo Han
2014-04-16  4:42 ` [RFC PATCH 1/2] PCI: designware: Add ARM64 PCI support Jingoo Han
2014-04-16 16:57   ` Liviu Dudau
2014-04-16 18:26     ` Arnd Bergmann
2014-04-21  1:54       ` Jingoo Han
2014-04-21  9:58         ` Jingoo Han
2014-04-22 13:01           ` Liviu Dudau
2014-04-22 15:39           ` Rob Herring
2014-04-22 12:59         ` Liviu Dudau
2014-04-22 12:54       ` Liviu Dudau
2014-04-16  4:43 ` [RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC Jingoo Han
2014-04-22 14:11   ` Arnd Bergmann
2014-04-23  9:19     ` Kukjin Kim
2014-04-23 11:03       ` Arnd Bergmann
2014-04-23 14:23         ` Liviu Dudau [this message]
2014-04-23 16:20           ` Arnd Bergmann
2014-04-24  4:53             ` Kukjin Kim
2014-04-24  9:49               ` Arnd Bergmann
2014-04-23 13:00       ` Liviu Dudau
2014-04-24 12:25         ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140423142315.GO865@e106497-lin.cambridge.arm.com \
    --to=liviu.dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=bh74.an@samsung.com \
    --cc=bhelgaas@google.com \
    --cc=ilho215.lee@samsung.com \
    --cc=jg1.han@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).