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
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
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
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
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
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