From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752380AbcE0Kbg (ORCPT ); Fri, 27 May 2016 06:31:36 -0400 Received: from regular1.263xmail.com ([211.150.99.138]:51226 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbcE0Kbe (ORCPT ); Fri, 27 May 2016 06:31:34 -0400 X-Greylist: delayed 13367 seconds by postgrey-1.27 at vger.kernel.org; Fri, 27 May 2016 06:31:31 EDT X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: wenrui.li@rock-chips.com X-FST-TO: linux-kernel@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: wenrui.li@rock-chips.com X-UNIQUE-TAG: <38c217b12fe2ee3c479283a25ee3e722> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 2/2] pci: Add PCIe driver for Rockchip Soc To: Bharat Kumar Gogada , Arnd Bergmann , Shawn Lin References: <1463740105-7061-1-git-send-email-shawn.lin@rock-chips.com> <1463740156-7148-1-git-send-email-shawn.lin@rock-chips.com> <9836736.6VjP1ug4kE@wuerfel> <5747EDC9.2080603@rock-chips.com> <8520D5D51A55D047800579B094147198258AF22F@XAP-PVEXMBX01.xlnx.xilinx.com> Cc: Bjorn Helgaas , Heiko Stuebner , Rob Herring , "devicetree@vger.kernel.org" , Doug Anderson , "linux-pci@vger.kernel.org" , "linux-rockchip@lists.infradead.org" , "linux-kernel@vger.kernel.org" From: Wenrui Li Message-ID: <57482200.9090008@rock-chips.com> Date: Fri, 27 May 2016 18:31:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8520D5D51A55D047800579B094147198258AF22F@XAP-PVEXMBX01.xlnx.xilinx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2016/5/27 15:13, Bharat Kumar Gogada wrote: >>> >>>> + >>>> +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp, >>>> + struct pci_bus *bus, u32 devfn, >>>> + int where, int size, u32 *val) >>>> +{ >>>> + u32 busdev; >>>> + >>>> + busdev = PCIE_ECAM_ADDR(bus->number, PCI_SLOT(devfn), >>>> + PCI_FUNC(devfn), where); >>>> + >>>> + if (busdev & (size - 1)) { >>>> + *val = 0; >>>> + return PCIBIOS_BAD_REGISTER_NUMBER; >>>> + } >>>> + >>>> + if (size == 4) { >>>> + *val = readl(pp->reg_base + busdev); >>>> + } else if (size == 2) { >>>> + *val = readw(pp->reg_base + busdev); >>>> + } else if (size == 1) { >>>> + *val = readb(pp->reg_base + busdev); >>>> + } else { >>>> + *val = 0; >>>> + return PCIBIOS_BAD_REGISTER_NUMBER; >>>> + } >>>> + return PCIBIOS_SUCCESSFUL; >>>> +} >>>> + >>> >>> This looks like the normal ECAM operations, you could just call those. >> >> I read ECAM reference code, I found it not support ioremap config space >> for each bus individually on 64-bit systems. Our soc is 64-bit system, >> and bus0 config space base address is 0xfda00000, bus1 base address is >> 0xf8100000. So I think it is not normal ECAM operations, I do not know >> if I have understood correctly? >> > Hi, > > I think Arnd was suggesting to use generic config read/write calls, pci_generic_config_read/pci_generic_config_write > which does above functionality. Yeah, I seem the pci_generic_config_write use writew/writeb for byte and word write. but our SOC not support byte and word write in RC config spcace. So I redefine the the pci_ops.write > > Bharat > > >