[RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC
Liviu.Dudau at arm.com
Wed Apr 23 06:00:12 PDT 2014
On Wed, Apr 23, 2014 at 10:19:30AM +0100, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> > On Wednesday 16 April 2014, Jingoo Han wrote:
> > > Samsung GH7 has four PCIe controllers which can be used as root
> > > complex for PCIe interface.
> > >
> > > Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> > > ---
> > > drivers/pci/host/Kconfig | 2 +-
> > > drivers/pci/host/pci-exynos.c | 135
> > ++++++++++++++++++++++++++++++++++++++---
> > > 2 files changed, 126 insertions(+), 11 deletions(-)
> + Byungho An, Ilho Lee
> Hi Arnd,
> > Can you explain how much the GH7 and Exynos front-ends actually have in
> > common? Would it make sense to have a separate driver for gh7?
> 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.
> 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.
I will let Arnd offer his view as a maintainer of DT enabled platforms for
arch/arm, but in my understanding the goal is to convert individual host
bridge drivers to use my patch series directly, as they intentionally don't
depend on any arch specific code and then leave the existing bios32 code
for the non-DT platforms and the ones that do not see the need to convert
to the framework.
Rob Herring has posted an example on how he can add support for a host
bridge running under arm32 that uses my framework, so it is not an impossible
task and can be used as an example for future conversions.
Does that make sense?
> > 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.
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
More information about the linux-arm-kernel