| Message ID | cover.1581497860.git.michal.simek@xilinx.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Hi, | expand |
On Wed, Feb 12, 2020 at 9:58 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > I am sending this series as before SMP support. > Most of these patches are clean ups and should be easy to review them. I > expect there will be more discussions about SMP support. Agreed. I had one question about a detail, other than that: Reviewed-by: Arnd Bergmann <arnd@arndb.de>
On 12. 02. 20 14:02, Arnd Bergmann wrote: > On Wed, Feb 12, 2020 at 9:58 AM Michal Simek <michal.simek@xilinx.com> wrote: >> >> >> I am sending this series as before SMP support. >> Most of these patches are clean ups and should be easy to review them. I >> expect there will be more discussions about SMP support. > > Agreed. > > I had one question about a detail, other than that: > > Reviewed-by: Arnd Bergmann <arnd@arndb.de> Thanks, Michal
On Wed, Feb 12, 2020 at 2:58 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > I am sending this series as before SMP support. > Most of these patches are clean ups and should be easy to review them. I > expect there will be more discussions about SMP support. While not really related to adding SMP, any chance you or someone could look at moving microblaze PCI support to drivers/pci/? I suspect much of the code should drop out as we have common helpers for much of it now. That would leave only powerpc and mips for DT+PCI platforms. Rob
Hi Rob, On 14. 02. 20 0:47, Rob Herring wrote: > On Wed, Feb 12, 2020 at 2:58 AM Michal Simek <michal.simek@xilinx.com> wrote: >> >> >> I am sending this series as before SMP support. >> Most of these patches are clean ups and should be easy to review them. I >> expect there will be more discussions about SMP support. > > While not really related to adding SMP, any chance you or someone > could look at moving microblaze PCI support to drivers/pci/? I suspect > much of the code should drop out as we have common helpers for much of > it now. That would leave only powerpc and mips for DT+PCI platforms. can you please suggest changes which could be done? I have CC Bharat and he could look at it. Thanks, Michal
On 12. 02. 20 9:57, Michal Simek wrote: > > I am sending this series as before SMP support. > Most of these patches are clean ups and should be easy to review them. I > expect there will be more discussions about SMP support. > > There could be some optimization added based on > https://lkml.org/lkml/2020/2/10/1528 > > Thanks, > Michal > > > Michal Simek (6): > microblaze: Convert headers to SPDX license > microblaze: Remove architecture tlb.h and use generic one > microblaze: Remove early printk setup > microblaze: Remove empty headers > microblaze: Remove unused boot_cpuid variable > microblaze: Use asm generic cmpxchg.h for !SMP case > > Stefan Asserhall (4): > microblaze: Define microblaze barrier > microblaze: Add sync to tlb operations > microblaze: Add missing irqflags.h header > microblaze: Define percpu sestion in linker file > > arch/microblaze/include/asm/Kbuild | 4 +- > arch/microblaze/include/asm/barrier.h | 13 ++++++ > arch/microblaze/include/asm/cache.h | 5 +-- > arch/microblaze/include/asm/cacheflush.h | 6 +-- > arch/microblaze/include/asm/checksum.h | 5 +-- > arch/microblaze/include/asm/cmpxchg.h | 40 ++----------------- > arch/microblaze/include/asm/cpuinfo.h | 5 +-- > arch/microblaze/include/asm/cputable.h | 1 - > arch/microblaze/include/asm/current.h | 5 +-- > arch/microblaze/include/asm/delay.h | 7 +--- > arch/microblaze/include/asm/dma.h | 5 +-- > arch/microblaze/include/asm/elf.h | 5 +-- > arch/microblaze/include/asm/entry.h | 5 +-- > arch/microblaze/include/asm/exceptions.h | 5 +-- > arch/microblaze/include/asm/fixmap.h | 5 +-- > arch/microblaze/include/asm/flat.h | 5 +-- > arch/microblaze/include/asm/hw_irq.h | 1 - > arch/microblaze/include/asm/io.h | 5 +-- > arch/microblaze/include/asm/irq.h | 5 +-- > arch/microblaze/include/asm/irqflags.h | 5 +-- > arch/microblaze/include/asm/mmu.h | 5 +-- > arch/microblaze/include/asm/mmu_context_mm.h | 5 +-- > arch/microblaze/include/asm/module.h | 5 +-- > arch/microblaze/include/asm/page.h | 5 +-- > arch/microblaze/include/asm/pgalloc.h | 5 +-- > arch/microblaze/include/asm/pgtable.h | 5 +-- > arch/microblaze/include/asm/processor.h | 5 +-- > arch/microblaze/include/asm/ptrace.h | 5 +-- > arch/microblaze/include/asm/pvr.h | 5 +-- > arch/microblaze/include/asm/registers.h | 5 +-- > arch/microblaze/include/asm/sections.h | 5 +-- > arch/microblaze/include/asm/setup.h | 7 +--- > arch/microblaze/include/asm/string.h | 5 +-- > arch/microblaze/include/asm/switch_to.h | 5 +-- > arch/microblaze/include/asm/thread_info.h | 5 +-- > arch/microblaze/include/asm/timex.h | 5 +-- > arch/microblaze/include/asm/tlb.h | 17 -------- > arch/microblaze/include/asm/tlbflush.h | 5 +-- > arch/microblaze/include/asm/uaccess.h | 5 +-- > arch/microblaze/include/asm/unaligned.h | 5 +-- > arch/microblaze/include/asm/unistd.h | 5 +-- > arch/microblaze/include/asm/unwind.h | 5 +-- > arch/microblaze/include/asm/user.h | 1 - > arch/microblaze/kernel/cpu/cpuinfo-pvr-full.c | 7 +--- > arch/microblaze/kernel/cpu/pvr.c | 1 + > arch/microblaze/kernel/misc.S | 3 +- > arch/microblaze/kernel/setup.c | 1 - > arch/microblaze/kernel/vmlinux.lds.S | 3 ++ > 48 files changed, 62 insertions(+), 215 deletions(-) > create mode 100644 arch/microblaze/include/asm/barrier.h > delete mode 100644 arch/microblaze/include/asm/cputable.h > delete mode 100644 arch/microblaze/include/asm/hw_irq.h > delete mode 100644 arch/microblaze/include/asm/tlb.h > delete mode 100644 arch/microblaze/include/asm/user.h > applied all. M
On Mon, Feb 17, 2020 at 8:28 AM Michal Simek <michal.simek@xilinx.com> wrote: > > Hi Rob, > > On 14. 02. 20 0:47, Rob Herring wrote: > > On Wed, Feb 12, 2020 at 2:58 AM Michal Simek <michal.simek@xilinx.com> wrote: > >> > >> > >> I am sending this series as before SMP support. > >> Most of these patches are clean ups and should be easy to review them. I > >> expect there will be more discussions about SMP support. > > > > While not really related to adding SMP, any chance you or someone > > could look at moving microblaze PCI support to drivers/pci/? I suspect > > much of the code should drop out as we have common helpers for much of > > it now. That would leave only powerpc and mips for DT+PCI platforms. > > can you please suggest changes which could be done? > I have CC Bharat and he could look at it. Look at the host controller drivers in drivers/pci/controller/. pci-host-{generic,common}.c is a good template to start with as that's a controller with standard config space accesses and no h/w setup needed. Essentially you need to call devm_pci_alloc_host_bridge(), pci_parse_request_of_pci_ranges() and pci_host_probe() with whatever h/w setup you need in between those calls. Looking at the microblaze PCI code, looks like you may need custom config space accessors which is quite common. Probably all the resource and device scanning can be removed. If you look at arm64, all the arch PCI code is just for ACPI. Rob
On 25. 02. 20 17:32, Rob Herring wrote: > On Mon, Feb 17, 2020 at 8:28 AM Michal Simek <michal.simek@xilinx.com> wrote: >> >> Hi Rob, >> >> On 14. 02. 20 0:47, Rob Herring wrote: >>> On Wed, Feb 12, 2020 at 2:58 AM Michal Simek <michal.simek@xilinx.com> wrote: >>>> >>>> >>>> I am sending this series as before SMP support. >>>> Most of these patches are clean ups and should be easy to review them. I >>>> expect there will be more discussions about SMP support. >>> >>> While not really related to adding SMP, any chance you or someone >>> could look at moving microblaze PCI support to drivers/pci/? I suspect >>> much of the code should drop out as we have common helpers for much of >>> it now. That would leave only powerpc and mips for DT+PCI platforms. >> >> can you please suggest changes which could be done? >> I have CC Bharat and he could look at it. > > Look at the host controller drivers in drivers/pci/controller/. > pci-host-{generic,common}.c is a good template to start with as that's > a controller with standard config space accesses and no h/w setup > needed. Essentially you need to call devm_pci_alloc_host_bridge(), > pci_parse_request_of_pci_ranges() and pci_host_probe() with whatever > h/w setup you need in between those calls. > > Looking at the microblaze PCI code, looks like you may need custom > config space accessors which is quite common. Probably all the > resource and device scanning can be removed. If you look at arm64, all > the arch PCI code is just for ACPI. Thanks Rob. Bharat: Can you please take a look? Thanks, Michal
> On 25. 02. 20 17:32, Rob Herring wrote: > > On Mon, Feb 17, 2020 at 8:28 AM Michal Simek <michal.simek@xilinx.com> > wrote: > >> > >> Hi Rob, > >> > >> On 14. 02. 20 0:47, Rob Herring wrote: > >>> On Wed, Feb 12, 2020 at 2:58 AM Michal Simek > <michal.simek@xilinx.com> wrote: > >>>> > >>>> > >>>> I am sending this series as before SMP support. > >>>> Most of these patches are clean ups and should be easy to review > >>>> them. I expect there will be more discussions about SMP support. > >>> > >>> While not really related to adding SMP, any chance you or someone > >>> could look at moving microblaze PCI support to drivers/pci/? I > >>> suspect much of the code should drop out as we have common helpers > >>> for much of it now. That would leave only powerpc and mips for DT+PCI > platforms. > >> > >> can you please suggest changes which could be done? > >> I have CC Bharat and he could look at it. > > > > Look at the host controller drivers in drivers/pci/controller/. > > pci-host-{generic,common}.c is a good template to start with as that's > > a controller with standard config space accesses and no h/w setup > > needed. Essentially you need to call devm_pci_alloc_host_bridge(), > > pci_parse_request_of_pci_ranges() and pci_host_probe() with whatever > > h/w setup you need in between those calls. > > > > Looking at the microblaze PCI code, looks like you may need custom > > config space accessors which is quite common. Probably all the > > resource and device scanning can be removed. If you look at arm64, all > > the arch PCI code is just for ACPI. Hi Rob, Can you please let us know why we might need custom config space accessors ? We tested pci_generic_config_read/write accessors on microblaze, and we did not see any issues. Regards, Bharat
On Sun, May 31, 2020 at 10:22 PM Bharat Kumar Gogada <bharatku@xilinx.com> wrote: > > > On 25. 02. 20 17:32, Rob Herring wrote: > > > On Mon, Feb 17, 2020 at 8:28 AM Michal Simek <michal.simek@xilinx.com> > > wrote: > > >> > > >> Hi Rob, > > >> > > >> On 14. 02. 20 0:47, Rob Herring wrote: > > >>> On Wed, Feb 12, 2020 at 2:58 AM Michal Simek > > <michal.simek@xilinx.com> wrote: > > >>>> > > >>>> > > >>>> I am sending this series as before SMP support. > > >>>> Most of these patches are clean ups and should be easy to review > > >>>> them. I expect there will be more discussions about SMP support. > > >>> > > >>> While not really related to adding SMP, any chance you or someone > > >>> could look at moving microblaze PCI support to drivers/pci/? I > > >>> suspect much of the code should drop out as we have common helpers > > >>> for much of it now. That would leave only powerpc and mips for DT+PCI > > platforms. > > >> > > >> can you please suggest changes which could be done? > > >> I have CC Bharat and he could look at it. > > > > > > Look at the host controller drivers in drivers/pci/controller/. > > > pci-host-{generic,common}.c is a good template to start with as that's > > > a controller with standard config space accesses and no h/w setup > > > needed. Essentially you need to call devm_pci_alloc_host_bridge(), > > > pci_parse_request_of_pci_ranges() and pci_host_probe() with whatever > > > h/w setup you need in between those calls. > > > > > > Looking at the microblaze PCI code, looks like you may need custom > > > config space accessors which is quite common. Probably all the > > > resource and device scanning can be removed. If you look at arm64, all > > > the arch PCI code is just for ACPI. > Hi Rob, > > Can you please let us know why we might need custom config space accessors ? > We tested pci_generic_config_read/write accessors on microblaze, and we > did not see any issues. I was thinking maybe the indirect code might have to be custom, but maybe everything can be handled in .map_bus(). Rob