Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates: Just a bunch of bugfixes.
Heiko Carstens (4):
drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
s390/uaccess: fix clear_user_pt()
s390/uaccess: fix page table walk
s390/mm: provide emtpy check_pgt_cache() function
Martin Schwidefsky (1):
s390/3270: fix minor_start issue
Sebastian Ott (1):
s390/scm_block: fix printk format string
Wei Yongjun (1):
s390/scm_blk: fix error return code in scm_blk_init()
arch/s390/include/asm/pgtable.h | 4 +-
arch/s390/lib/uaccess_pt.c | 83 ++++++++++++++++++++++++++-------------
drivers/dma/Kconfig | 1 +
drivers/media/platform/Kconfig | 2 +-
drivers/s390/block/scm_blk.c | 11 ++++--
drivers/s390/block/scm_drv.c | 2 +-
drivers/s390/char/tty3270.c | 16 ++++----
drivers/spi/Kconfig | 3 +-
8 files changed, 79 insertions(+), 43 deletions(-)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 4a29308..4a54431 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -344,6 +344,7 @@ extern unsigned long MODULES_END;
#define _REGION3_ENTRY_CO 0x100 /* change-recording override */
/* Bits in the segment table entry */
+#define _SEGMENT_ENTRY_ORIGIN_LARGE ~0xfffffUL /* large page address */
#define _SEGMENT_ENTRY_ORIGIN ~0x7ffUL/* segment table origin */
#define _SEGMENT_ENTRY_RO 0x200 /* page protection bit */
#define _SEGMENT_ENTRY_INV 0x20 /* invalid segment table entry */
@@ -1531,7 +1532,8 @@ extern int s390_enable_sie(void);
/*
* No page table caches to initialise
*/
-#define pgtable_cache_init() do { } while (0)
+static inline void pgtable_cache_init(void) { }
+static inline void check_pgt_cache(void) { }
#include <asm-generic/pgtable.h>
diff --git a/arch/s390/lib/uaccess_pt.c b/arch/s390/lib/uaccess_pt.c
index dff631d..466fb33 100644
--- a/arch/s390/lib/uaccess_pt.c
+++ b/arch/s390/lib/uaccess_pt.c
@@ -77,42 +77,69 @@ static size_t copy_in_kernel(size_t count, void __user *to,
* >= -4095 (IS_ERR_VALUE(x) returns true), a fault has occured and the address
* contains the (negative) exception code.
*/
-static __always_inline unsigned long follow_table(struct mm_struct *mm,
- unsigned long addr, int write)
+#ifdef CONFIG_64BIT
+static unsigned long follow_table(struct mm_struct *mm,
+ unsigned long address, int write)
{
- pgd_t *pgd;
- pud_t *pud;
- pmd_t *pmd;
- pte_t *ptep;
+ unsigned long *table = (unsigned long *)__pa(mm->pgd);
+
+ switch (mm->context.asce_bits & _ASCE_TYPE_MASK) {
+ case _ASCE_TYPE_REGION1:
+ table = table + ((address >> 53) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x39UL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_REGION2:
+ table = table + ((address >> 42) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x3aUL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_REGION3:
+ table = table + ((address >> 31) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x3bUL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_SEGMENT:
+ table = table + ((address >> 20) & 0x7ff);
+ if (unlikely(*table & _SEGMENT_ENTRY_INV))
+ return -0x10UL;
+ if (unlikely(*table & _SEGMENT_ENTRY_LARGE)) {
+ if (write && (*table & _SEGMENT_ENTRY_RO))
+ return -0x04UL;
+ return (*table & _SEGMENT_ENTRY_ORIGIN_LARGE) +
+ (address & ~_SEGMENT_ENTRY_ORIGIN_LARGE);
+ }
+ table = (unsigned long *)(*table & _SEGMENT_ENTRY_ORIGIN);
+ }
+ table = table + ((address >> 12) & 0xff);
+ if (unlikely(*table & _PAGE_INVALID))
+ return -0x11UL;
+ if (write && (*table & _PAGE_RO))
+ return -0x04UL;
+ return (*table & PAGE_MASK) + (address & ~PAGE_MASK);
+}
- pgd = pgd_offset(mm, addr);
- if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
- return -0x3aUL;
+#else /* CONFIG_64BIT */
- pud = pud_offset(pgd, addr);
- if (pud_none(*pud) || unlikely(pud_bad(*pud)))
- return -0x3bUL;
+static unsigned long follow_table(struct mm_struct *mm,
+ unsigned long address, int write)
+{
+ unsigned long *table = (unsigned long *)__pa(mm->pgd);
- pmd = pmd_offset(pud, addr);
- if (pmd_none(*pmd))
+ table = table + ((address >> 20) & 0x7ff);
+ if (unlikely(*table & _SEGMENT_ENTRY_INV))
return -0x10UL;
- if (pmd_large(*pmd)) {
- if (write && (pmd_val(*pmd) & _SEGMENT_ENTRY_RO))
- return -0x04UL;
- return (pmd_val(*pmd) & HPAGE_MASK) + (addr & ~HPAGE_MASK);
- }
- if (unlikely(pmd_bad(*pmd)))
- return -0x10UL;
-
- ptep = pte_offset_map(pmd, addr);
- if (!pte_present(*ptep))
+ table = (unsigned long *)(*table & _SEGMENT_ENTRY_ORIGIN);
+ table = table + ((address >> 12) & 0xff);
+ if (unlikely(*table & _PAGE_INVALID))
return -0x11UL;
- if (write && (!pte_write(*ptep) || !pte_dirty(*ptep)))
+ if (write && (*table & _PAGE_RO))
return -0x04UL;
-
- return (pte_val(*ptep) & PAGE_MASK) + (addr & ~PAGE_MASK);
+ return (*table & PAGE_MASK) + (address & ~PAGE_MASK);
}
+#endif /* CONFIG_64BIT */
+
static __always_inline size_t __user_copy_pt(unsigned long uaddr, void *kptr,
size_t n, int write_user)
{
@@ -197,7 +224,7 @@ size_t copy_to_user_pt(size_t n, void __user *to, const void *from)
static size_t clear_user_pt(size_t n, void __user *to)
{
- void *zpage = &empty_zero_page;
+ void *zpage = (void *) empty_zero_page;
long done, size, ret;
done = 0;
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 80b6997..aeaea32 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -83,6 +83,7 @@ config INTEL_IOP_ADMA
config DW_DMAC
tristate "Synopsys DesignWare AHB DMA support"
+ depends on GENERIC_HARDIRQS
select DMA_ENGINE
default y if CPU_AT32AP7000
help
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 05d7b63..a0639e7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -204,7 +204,7 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
- depends on VIDEO_DEV && VIDEO_V4L2
+ depends on VIDEO_DEV && VIDEO_V4L2 && GENERIC_HARDIRQS
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 5ac9c93..e9b9c83 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -307,7 +307,7 @@ static void scm_blk_handle_error(struct scm_request *scmrq)
case EQC_WR_PROHIBIT:
spin_lock_irqsave(&bdev->lock, flags);
if (bdev->state != SCM_WR_PROHIBIT)
- pr_info("%lu: Write access to the SCM increment is suspended\n",
+ pr_info("%lx: Write access to the SCM increment is suspended\n",
(unsigned long) bdev->scmdev->address);
bdev->state = SCM_WR_PROHIBIT;
spin_unlock_irqrestore(&bdev->lock, flags);
@@ -445,7 +445,7 @@ void scm_blk_set_available(struct scm_blk_dev *bdev)
spin_lock_irqsave(&bdev->lock, flags);
if (bdev->state == SCM_WR_PROHIBIT)
- pr_info("%lu: Write access to the SCM increment is restored\n",
+ pr_info("%lx: Write access to the SCM increment is restored\n",
(unsigned long) bdev->scmdev->address);
bdev->state = SCM_OPER;
spin_unlock_irqrestore(&bdev->lock, flags);
@@ -463,12 +463,15 @@ static int __init scm_blk_init(void)
goto out;
scm_major = ret;
- if (scm_alloc_rqs(nr_requests))
+ ret = scm_alloc_rqs(nr_requests);
+ if (ret)
goto out_unreg;
scm_debug = debug_register("scm_log", 16, 1, 16);
- if (!scm_debug)
+ if (!scm_debug) {
+ ret = -ENOMEM;
goto out_free;
+ }
debug_register_view(scm_debug, &debug_hex_ascii_view);
debug_set_level(scm_debug, 2);
diff --git a/drivers/s390/block/scm_drv.c b/drivers/s390/block/scm_drv.c
index 5f6180d..c98cf52 100644
--- a/drivers/s390/block/scm_drv.c
+++ b/drivers/s390/block/scm_drv.c
@@ -19,7 +19,7 @@ static void scm_notify(struct scm_device *scmdev, enum scm_event event)
switch (event) {
case SCM_CHANGE:
- pr_info("%lu: The capabilities of the SCM increment changed\n",
+ pr_info("%lx: The capabilities of the SCM increment changed\n",
(unsigned long) scmdev->address);
SCM_LOG(2, "State changed");
SCM_LOG_STATE(2, scmdev);
diff --git a/drivers/s390/char/tty3270.c b/drivers/s390/char/tty3270.c
index b907dba..cee69da 100644
--- a/drivers/s390/char/tty3270.c
+++ b/drivers/s390/char/tty3270.c
@@ -915,7 +915,7 @@ static int tty3270_install(struct tty_driver *driver, struct tty_struct *tty)
int i, rc;
/* Check if the tty3270 is already there. */
- view = raw3270_find_view(&tty3270_fn, tty->index);
+ view = raw3270_find_view(&tty3270_fn, tty->index + RAW3270_FIRSTMINOR);
if (!IS_ERR(view)) {
tp = container_of(view, struct tty3270, view);
tty->driver_data = tp;
@@ -927,15 +927,16 @@ static int tty3270_install(struct tty_driver *driver, struct tty_struct *tty)
tp->inattr = TF_INPUT;
return tty_port_install(&tp->port, driver, tty);
}
- if (tty3270_max_index < tty->index)
- tty3270_max_index = tty->index;
+ if (tty3270_max_index < tty->index + 1)
+ tty3270_max_index = tty->index + 1;
/* Allocate tty3270 structure on first open. */
tp = tty3270_alloc_view();
if (IS_ERR(tp))
return PTR_ERR(tp);
- rc = raw3270_add_view(&tp->view, &tty3270_fn, tty->index);
+ rc = raw3270_add_view(&tp->view, &tty3270_fn,
+ tty->index + RAW3270_FIRSTMINOR);
if (rc) {
tty3270_free_view(tp);
return rc;
@@ -1846,12 +1847,12 @@ static const struct tty_operations tty3270_ops = {
void tty3270_create_cb(int minor)
{
- tty_register_device(tty3270_driver, minor, NULL);
+ tty_register_device(tty3270_driver, minor - RAW3270_FIRSTMINOR, NULL);
}
void tty3270_destroy_cb(int minor)
{
- tty_unregister_device(tty3270_driver, minor);
+ tty_unregister_device(tty3270_driver, minor - RAW3270_FIRSTMINOR);
}
struct raw3270_notifier tty3270_notifier =
@@ -1884,7 +1885,8 @@ static int __init tty3270_init(void)
driver->driver_name = "tty3270";
driver->name = "3270/tty";
driver->major = IBM_TTY3270_MAJOR;
- driver->minor_start = 0;
+ driver->minor_start = RAW3270_FIRSTMINOR;
+ driver->name_base = RAW3270_FIRSTMINOR;
driver->type = TTY_DRIVER_TYPE_SYSTEM;
driver->subtype = SYSTEM_TYPE_TTY;
driver->init_termios = tty_std_termios;
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f80eee7..2be0de9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -55,6 +55,7 @@ comment "SPI Master Controller Drivers"
config SPI_ALTERA
tristate "Altera SPI Controller"
+ depends on GENERIC_HARDIRQS
select SPI_BITBANG
help
This is the driver for the Altera SPI Controller.
@@ -310,7 +311,7 @@ config SPI_PXA2XX_DMA
config SPI_PXA2XX
tristate "PXA2xx SSP SPI master"
- depends on ARCH_PXA || PCI || ACPI
+ depends on (ARCH_PXA || PCI || ACPI) && GENERIC_HARDIRQS
select PXA_SSP if ARCH_PXA
help
This enables using a PXA2xx or Sodaville SSP port as a SPI master
On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
<[email protected]> wrote:
> Hi Linus,
>
> please pull from the 'for-linus' branch of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>
> to receive the following updates: Just a bunch of bugfixes.
>
> Heiko Carstens (4):
> drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
Is anyone currently working on fixing this? s390 is the only
architecture left that does not enable GENERIC_HARDIRQS. It's painful
to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
g.
On Tue, 25 Jun 2013 13:09:51 +0100
Grant Likely <[email protected]> wrote:
> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
> <[email protected]> wrote:
> > Hi Linus,
> >
> > please pull from the 'for-linus' branch of
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> >
> > to receive the following updates: Just a bunch of bugfixes.
> >
> > Heiko Carstens (4):
> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
>
> Is anyone currently working on fixing this? s390 is the only
> architecture left that does not enable GENERIC_HARDIRQS. It's painful
> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
I am working on it. The hardest part is MSI irqs for PCI. Chances are
that I get it done for the merge window of 3.12.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Tue, Jun 25, 2013 at 1:15 PM, Martin Schwidefsky
<[email protected]> wrote:
> On Tue, 25 Jun 2013 13:09:51 +0100
> Grant Likely <[email protected]> wrote:
>
>> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
>> <[email protected]> wrote:
>> > Hi Linus,
>> >
>> > please pull from the 'for-linus' branch of
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>> >
>> > to receive the following updates: Just a bunch of bugfixes.
>> >
>> > Heiko Carstens (4):
>> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
>>
>> Is anyone currently working on fixing this? s390 is the only
>> architecture left that does not enable GENERIC_HARDIRQS. It's painful
>> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
>
> I am working on it. The hardest part is MSI irqs for PCI. Chances are
> that I get it done for the merge window of 3.12.
How are you handling the MSIs? I've just been looking at some code for
irq_domain to handle MSI mapping. What's the part that is getting you
hung up?
I'd be happy to take a look if you want a hand.
g.
On Tue, 25 Jun 2013 13:42:23 +0100
Grant Likely <[email protected]> wrote:
> On Tue, Jun 25, 2013 at 1:15 PM, Martin Schwidefsky
> <[email protected]> wrote:
> > On Tue, 25 Jun 2013 13:09:51 +0100
> > Grant Likely <[email protected]> wrote:
> >
> >> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
> >> <[email protected]> wrote:
> >> > Hi Linus,
> >> >
> >> > please pull from the 'for-linus' branch of
> >> >
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> >> >
> >> > to receive the following updates: Just a bunch of bugfixes.
> >> >
> >> > Heiko Carstens (4):
> >> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
> >>
> >> Is anyone currently working on fixing this? s390 is the only
> >> architecture left that does not enable GENERIC_HARDIRQS. It's painful
> >> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
> >
> > I am working on it. The hardest part is MSI irqs for PCI. Chances are
> > that I get it done for the merge window of 3.12.
>
> How are you handling the MSIs? I've just been looking at some code for
> irq_domain to handle MSI mapping. What's the part that is getting you
> hung up?
Basically a name-space thing. The current code allocates 64 interrupts numbers
for each PCI device, starting at 0. With GENERIC_HARDIRQS=y irq #0 is used for
for external interrupts, irq #1 for I/O interrupts and irq #2 for adapter
interrupts. The adapter interrupt handler for PCI has to scan the interrupt
vectors and call generic_handle_irq for the MSI interrupts starting at irq #3.
As I don't want to create a huge irq_desc array the number of allocatable
interrupts for MSI will be limited and I can not simply assign 64 interrupts
numbers to each device anymore.
> I'd be happy to take a look if you want a hand.
Thanks for the offer, I might take you up on it if I hit a real problem.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Tue, Jun 25, 2013 at 2:11 PM, Martin Schwidefsky
<[email protected]> wrote:
> On Tue, 25 Jun 2013 13:42:23 +0100
> Grant Likely <[email protected]> wrote:
>
>> On Tue, Jun 25, 2013 at 1:15 PM, Martin Schwidefsky
>> <[email protected]> wrote:
>> > On Tue, 25 Jun 2013 13:09:51 +0100
>> > Grant Likely <[email protected]> wrote:
>> >
>> >> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
>> >> <[email protected]> wrote:
>> >> > Hi Linus,
>> >> >
>> >> > please pull from the 'for-linus' branch of
>> >> >
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>> >> >
>> >> > to receive the following updates: Just a bunch of bugfixes.
>> >> >
>> >> > Heiko Carstens (4):
>> >> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
>> >>
>> >> Is anyone currently working on fixing this? s390 is the only
>> >> architecture left that does not enable GENERIC_HARDIRQS. It's painful
>> >> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
>> >
>> > I am working on it. The hardest part is MSI irqs for PCI. Chances are
>> > that I get it done for the merge window of 3.12.
>>
>> How are you handling the MSIs? I've just been looking at some code for
>> irq_domain to handle MSI mapping. What's the part that is getting you
>> hung up?
>
> Basically a name-space thing. The current code allocates 64 interrupts numbers
> for each PCI device, starting at 0. With GENERIC_HARDIRQS=y irq #0 is used for
> for external interrupts, irq #1 for I/O interrupts and irq #2 for adapter
> interrupts. The adapter interrupt handler for PCI has to scan the interrupt
> vectors and call generic_handle_irq for the MSI interrupts starting at irq #3.
> As I don't want to create a huge irq_desc array the number of allocatable
> interrupts for MSI will be limited and I can not simply assign 64 interrupts
> numbers to each device anymore.
Have you looked at irq_domain? It was created to solve that exact
problem. irq_descs can get allocated dynamically as irqs are
requested.
g.
On Tue, 25 Jun 2013 14:30:20 +0100
Grant Likely <[email protected]> wrote:
> On Tue, Jun 25, 2013 at 2:11 PM, Martin Schwidefsky
> <[email protected]> wrote:
> > On Tue, 25 Jun 2013 13:42:23 +0100
> > Grant Likely <[email protected]> wrote:
> >
> >> On Tue, Jun 25, 2013 at 1:15 PM, Martin Schwidefsky
> >> <[email protected]> wrote:
> >> > On Tue, 25 Jun 2013 13:09:51 +0100
> >> > Grant Likely <[email protected]> wrote:
> >> >
> >> >> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
> >> >> <[email protected]> wrote:
> >> >> > Hi Linus,
> >> >> >
> >> >> > please pull from the 'for-linus' branch of
> >> >> >
> >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> >> >> >
> >> >> > to receive the following updates: Just a bunch of bugfixes.
> >> >> >
> >> >> > Heiko Carstens (4):
> >> >> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
> >> >>
> >> >> Is anyone currently working on fixing this? s390 is the only
> >> >> architecture left that does not enable GENERIC_HARDIRQS. It's painful
> >> >> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
> >> >
> >> > I am working on it. The hardest part is MSI irqs for PCI. Chances are
> >> > that I get it done for the merge window of 3.12.
> >>
> >> How are you handling the MSIs? I've just been looking at some code for
> >> irq_domain to handle MSI mapping. What's the part that is getting you
> >> hung up?
> >
> > Basically a name-space thing. The current code allocates 64 interrupts numbers
> > for each PCI device, starting at 0. With GENERIC_HARDIRQS=y irq #0 is used for
> > for external interrupts, irq #1 for I/O interrupts and irq #2 for adapter
> > interrupts. The adapter interrupt handler for PCI has to scan the interrupt
> > vectors and call generic_handle_irq for the MSI interrupts starting at irq #3.
> > As I don't want to create a huge irq_desc array the number of allocatable
> > interrupts for MSI will be limited and I can not simply assign 64 interrupts
> > numbers to each device anymore.
>
> Have you looked at irq_domain? It was created to solve that exact
> problem. irq_descs can get allocated dynamically as irqs are
> requested.
That is one option I am considering. The PCI support for System z can have multiple
PCI function groups, each with up to 2048 MSI interrupts. It is quite a good match.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Tue, Jun 25, 2013 at 3:12 PM, Martin Schwidefsky
<[email protected]> wrote:
> On Tue, 25 Jun 2013 14:30:20 +0100
> Grant Likely <[email protected]> wrote:
>
>> On Tue, Jun 25, 2013 at 2:11 PM, Martin Schwidefsky
>> <[email protected]> wrote:
>> > On Tue, 25 Jun 2013 13:42:23 +0100
>> > Grant Likely <[email protected]> wrote:
>> >
>> >> On Tue, Jun 25, 2013 at 1:15 PM, Martin Schwidefsky
>> >> <[email protected]> wrote:
>> >> > On Tue, 25 Jun 2013 13:09:51 +0100
>> >> > Grant Likely <[email protected]> wrote:
>> >> >
>> >> >> On Wed, Apr 3, 2013 at 4:25 PM, Martin Schwidefsky
>> >> >> <[email protected]> wrote:
>> >> >> > Hi Linus,
>> >> >> >
>> >> >> > please pull from the 'for-linus' branch of
>> >> >> >
>> >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>> >> >> >
>> >> >> > to receive the following updates: Just a bunch of bugfixes.
>> >> >> >
>> >> >> > Heiko Carstens (4):
>> >> >> > drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
>> >> >>
>> >> >> Is anyone currently working on fixing this? s390 is the only
>> >> >> architecture left that does not enable GENERIC_HARDIRQS. It's painful
>> >> >> to keep adding dependencies on GENERIC_HARDIRQS to driver configs.
>> >> >
>> >> > I am working on it. The hardest part is MSI irqs for PCI. Chances are
>> >> > that I get it done for the merge window of 3.12.
>> >>
>> >> How are you handling the MSIs? I've just been looking at some code for
>> >> irq_domain to handle MSI mapping. What's the part that is getting you
>> >> hung up?
>> >
>> > Basically a name-space thing. The current code allocates 64 interrupts numbers
>> > for each PCI device, starting at 0. With GENERIC_HARDIRQS=y irq #0 is used for
>> > for external interrupts, irq #1 for I/O interrupts and irq #2 for adapter
>> > interrupts. The adapter interrupt handler for PCI has to scan the interrupt
>> > vectors and call generic_handle_irq for the MSI interrupts starting at irq #3.
>> > As I don't want to create a huge irq_desc array the number of allocatable
>> > interrupts for MSI will be limited and I can not simply assign 64 interrupts
>> > numbers to each device anymore.
>>
>> Have you looked at irq_domain? It was created to solve that exact
>> problem. irq_descs can get allocated dynamically as irqs are
>> requested.
>
> That is one option I am considering. The PCI support for System z can have multiple
> PCI function groups, each with up to 2048 MSI interrupts. It is quite a good match.
:-) It was designed to support exactly that use-case on PowerPC.
g.
Hi Grant,
On Tue, 25 Jun 2013 15:18:21 +0100
Grant Likely <[email protected]> wrote:
> On Tue, Jun 25, 2013 at 3:12 PM, Martin Schwidefsky
> <[email protected]> wrote:
> > On Tue, 25 Jun 2013 14:30:20 +0100
> > Grant Likely <[email protected]> wrote:
> >
> >> Have you looked at irq_domain? It was created to solve that exact
> >> problem. irq_descs can get allocated dynamically as irqs are
> >> requested.
> >
> > That is one option I am considering. The PCI support for System z can have multiple
> > PCI function groups, each with up to 2048 MSI interrupts. It is quite a good match.
>
> :-) It was designed to support exactly that use-case on PowerPC.
I decided against irq_domains after all. The reason is that on s390 the same
MSI interrupt numbers are used for multiple devices but without actually
sharing them. The PCI root complex uses the adapter id and the MSI interrupt
number to set two indicators for the target device (adapter interrupt summary
bit and the MSI interrupt bit in the adapter interrupt vector). That would
give me two options for irq_domains: 1) allocate an irq_domain for each
device, or 2) encode the adapter id in the hwirq number and create a sparsely
populated irq_domain. It is simpler to just use the irq_alloc_desc and
irq_free_desc calls directly.
The preliminary result of this can be gawked at
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git genirq
Test and performance analysis is to-be-done and will take some time.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.