Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1265723 > unrolled thread

Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-11-09 15:40 +0100
    Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem Ralf Baechle <ralf@linux-mips.org> - 2015-11-09 15:50 +0100
      Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-11-09 17:20 +0100
        Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2015-11-09 18:40 +0100
          Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem "Maciej W. Rozycki" <macro@linux-mips.org> - 2015-11-09 20:00 +0100
            Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2015-11-09 20:10 +0100

#1265723 — Re: [PATCH] mips: sb1250_swarm_defconfig: disable IDE subsystem

On Mon, 14 Sep 2015, Bartlomiej Zolnierkiewicz wrote:

> This patch disables deprecated IDE subsystem in sb1250_swarm_defconfig
> (no IDE host drivers are selected in this config so there is no valid
> reason to enable IDE subsystem itself).

 Someone forgot to enable BLK_DEV_PLATFORM, it would seem, at the time the 
host driver was converted to a PATA platform device (back in 2008, commit 
2fef357c).  Frankly I don't think this config file has been recently (as 
in "since 2008") properly maintained, the last time I revalidated it was 
shortly before the conversion and nobody else bothered since then.  I'll 
give it a shot to modernise it at the earliest opportunity, I have other 
stuff to sort out with this system outstanding.

 For the record, I have this in .config I've most recently used (with
3.19.0):

CONFIG_HAVE_IDE=y
CONFIG_IDE=y
CONFIG_IDE_ATAPI=y
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_IDE_PROC_FS=y
CONFIG_BLK_DEV_PLATFORM=y
CONFIG_HAVE_PATA_PLATFORM=y

and the driver does register and sees the devices there:

[...]
pata-swarm: PATA interface at GenBus slot 4
futex hash table entries: 512 (order: 1, 49152 bytes)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
duart0 at MMIO 0x10060100 (irq = 8, base_baud = 5000000) is a SB1250 DUART
duart1 at MMIO 0x10060200 (irq = 9, base_baud = 5000000) is a SB1250 DUART
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
Probing IDE interface ide0...
hda: TOSHIBA MK2016GAP, ATA DISK drive
hdb: ST380011A, ATA DISK drive
ide0 at 0x90000000100b3e00-0x90000000100b3ee0,0x90000000100b7ec0 on irq 36
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB), CHS=38760/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 >
hdb: max request size: 1024KiB
hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63
hdb: cache flushes supported
 hdb: hdb1 hdb2 hdb3 < hdb5 hdb6 hdb7 hdb8 hdb9 > hdb4
[...]

I can check if things still work correctly when routed through libata, 
although it'll have to wait a couple of weeks yet at the least as I have 
wired my SWARM for hardware debugging, making it not immediately bootable 
and I'll be departing soon (i.e. I have no time for complicated fiddling).  
The host driver itself is actually in arch/mips/sibyte/swarm/platform.c 
BTW.

 Note to self: it would be nice if physical rather than virtual MMIO 
addresses were reported too.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1265738

On Mon, Nov 09, 2015 at 02:33:19PM +0000, Maciej W. Rozycki wrote:

> On Mon, 14 Sep 2015, Bartlomiej Zolnierkiewicz wrote:
> 
> > This patch disables deprecated IDE subsystem in sb1250_swarm_defconfig
> > (no IDE host drivers are selected in this config so there is no valid
> > reason to enable IDE subsystem itself).
> 
>  Someone forgot to enable BLK_DEV_PLATFORM, it would seem, at the time the 
> host driver was converted to a PATA platform device (back in 2008, commit 
> 2fef357c).  Frankly I don't think this config file has been recently (as 
> in "since 2008") properly maintained, the last time I revalidated it was 
> shortly before the conversion and nobody else bothered since then.  I'll 
> give it a shot to modernise it at the earliest opportunity, I have other 
> stuff to sort out with this system outstanding.
> 
>  For the record, I have this in .config I've most recently used (with
> 3.19.0):
> 
> CONFIG_HAVE_IDE=y
> CONFIG_IDE=y
> CONFIG_IDE_ATAPI=y
> CONFIG_IDE_GD=y
> CONFIG_IDE_GD_ATA=y
> CONFIG_BLK_DEV_IDECD=y
> CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
> CONFIG_IDE_TASK_IOCTL=y
> CONFIG_IDE_PROC_FS=y
> CONFIG_BLK_DEV_PLATFORM=y
> CONFIG_HAVE_PATA_PLATFORM=y
> 
> and the driver does register and sees the devices there:
> 
> [...]
> pata-swarm: PATA interface at GenBus slot 4
> futex hash table entries: 512 (order: 1, 49152 bytes)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> duart0 at MMIO 0x10060100 (irq = 8, base_baud = 5000000) is a SB1250 DUART
> duart1 at MMIO 0x10060200 (irq = 9, base_baud = 5000000) is a SB1250 DUART
> brd: module loaded
> loop: module loaded
> Uniform Multi-Platform E-IDE driver
> ide-gd driver 1.18
> ide-cd driver 5.00
> Probing IDE interface ide0...
> hda: TOSHIBA MK2016GAP, ATA DISK drive
> hdb: ST380011A, ATA DISK drive
> ide0 at 0x90000000100b3e00-0x90000000100b3ee0,0x90000000100b7ec0 on irq 36
> hda: max request size: 128KiB
> hda: 39070080 sectors (20003 MB), CHS=38760/16/63
> hda: cache flushes not supported
>  hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 >
> hdb: max request size: 1024KiB
> hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63
> hdb: cache flushes supported
>  hdb: hdb1 hdb2 hdb3 < hdb5 hdb6 hdb7 hdb8 hdb9 > hdb4
> [...]
> 
> I can check if things still work correctly when routed through libata, 
> although it'll have to wait a couple of weeks yet at the least as I have 
> wired my SWARM for hardware debugging, making it not immediately bootable 
> and I'll be departing soon (i.e. I have no time for complicated fiddling).  
> The host driver itself is actually in arch/mips/sibyte/swarm/platform.c 
> BTW.
> 
>  Note to self: it would be nice if physical rather than virtual MMIO 
> addresses were reported too.

Part of the problem is that everybody who is serious about using a Swarm
is using PCI PATA/SATA card, so this part receives very little TLC.  I
btw. can't test because the controller on my Pass 2 board is broken ...

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265793

On Mon, 9 Nov 2015, Ralf Baechle wrote:

> > I can check if things still work correctly when routed through libata, 
> > although it'll have to wait a couple of weeks yet at the least as I have 
> > wired my SWARM for hardware debugging, making it not immediately bootable 
> > and I'll be departing soon (i.e. I have no time for complicated fiddling).  
> > The host driver itself is actually in arch/mips/sibyte/swarm/platform.c 
> > BTW.
> > 
> >  Note to self: it would be nice if physical rather than virtual MMIO 
> > addresses were reported too.
> 
> Part of the problem is that everybody who is serious about using a Swarm
> is using PCI PATA/SATA card, so this part receives very little TLC.  I
> btw. can't test because the controller on my Pass 2 board is broken ...

 I think I've been reasonably serious about my SWARM and despite issues 
elsewhere the onboard PATA interface is a part of the system I've never 
had any with.  Yes, it's limited to PIO 3, but it's not a big deal, that's 
still 11MB/s (and one of the 4 generic data movers present in the SoC 
could be used as a DMA engine to offload the CPU if anyone bothered 
implementing that in the HBA driver).  I used it for stuff like native GCC 
bootstraps, some regression testing.  Maybe I'm just lucky, I've read 
people's horror stories.  Besides I'm out of free PCI slots, I'd have to 
use an expansion box.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265895

Hello.

On 11/09/2015 07:18 PM, Maciej W. Rozycki wrote:

>>> I can check if things still work correctly when routed through libata,
>>> although it'll have to wait a couple of weeks yet at the least as I have
>>> wired my SWARM for hardware debugging, making it not immediately bootable
>>> and I'll be departing soon (i.e. I have no time for complicated fiddling).
>>> The host driver itself is actually in arch/mips/sibyte/swarm/platform.c
>>> BTW.
>>>
>>>   Note to self: it would be nice if physical rather than virtual MMIO
>>> addresses were reported too.
>>
>> Part of the problem is that everybody who is serious about using a Swarm
>> is using PCI PATA/SATA card, so this part receives very little TLC.  I
>> btw. can't test because the controller on my Pass 2 board is broken ...
>
>   I think I've been reasonably serious about my SWARM and despite issues
> elsewhere the onboard PATA interface is a part of the system I've never
> had any with.  Yes, it's limited to PIO 3, but it's not a big deal, that's
> still 11MB/s (and one of the 4 generic data movers present in the SoC

    If you measure it with something like 'hdparm -t', the real speed figures 
in the PIO modes would disappoint you. It's usually more like 3 MB/s even in 
PIO4...

> could be used as a DMA engine to offload the CPU if anyone bothered
> implementing that in the HBA driver).

    Oh, that's nice!

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265948

On Mon, 9 Nov 2015, Sergei Shtylyov wrote:

> >   I think I've been reasonably serious about my SWARM and despite issues
> > elsewhere the onboard PATA interface is a part of the system I've never
> > had any with.  Yes, it's limited to PIO 3, but it's not a big deal, that's
> > still 11MB/s (and one of the 4 generic data movers present in the SoC
> 
>    If you measure it with something like 'hdparm -t', the real speed figures
> in the PIO modes would disappoint you. It's usually more like 3 MB/s even in
> PIO4...

 Well, various factors contribute to actual figures possible to achieve, 
the physical medium transfer speed being an important one.  That 11MB/s 
throughput is the maximum you can ever get on the wire in PIO 3, assuming 
data is already available to transfer and IORDY is asserted right away 
every cycle.

 As I say my SWARM is currently in flux, so I can't get any benchmarking 
done right now, but as a matter of interest I'll check that when I get to 
looking at this piece.

> > could be used as a DMA engine to offload the CPU if anyone bothered
> > implementing that in the HBA driver).
> 
>    Oh, that's nice!

 Indeed, I've been told the generic bus interface the PATA inferface has 
been cooked up on in this system has been specifically designed such as to 
make it work with the data mover.  There's still lot of silicon treasure 
left in this system unexplored!

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265951

On 11/09/2015 09:54 PM, Maciej W. Rozycki wrote:

>>>    I think I've been reasonably serious about my SWARM and despite issues
>>> elsewhere the onboard PATA interface is a part of the system I've never
>>> had any with.  Yes, it's limited to PIO 3, but it's not a big deal, that's
>>> still 11MB/s (and one of the 4 generic data movers present in the SoC
>>
>>     If you measure it with something like 'hdparm -t', the real speed figures
>> in the PIO modes would disappoint you. It's usually more like 3 MB/s even in
>> PIO4...

>   Well, various factors contribute to actual figures possible to achieve,
> the physical medium transfer speed being an important one.

    Yes, of course. Yet even with MWDMA2 (same wire speed as PIO4) hdparm 
shows about an order of magnitude higher speeds, IIRC. With the UltraDMA modes 
it becomes even higher...

> That 11MB/s
> throughput is the maximum you can ever get on the wire in PIO 3, assuming
> data is already available to transfer and IORDY is asserted right away
> every cycle.

    Yes, I figured.

[...]

>    Maciej

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web