Re: DMA mapping on SCSI device? - Kernel

This is a discussion on Re: DMA mapping on SCSI device? - Kernel ; Luben Tuikov wrote: > --- On Mon, 1/28/08, Robert Han**** wrote: >> The trick is that if an ATAPI device is connected, we (as >> far as I'm >> aware) can't use ADMA mode, so we have to switch that ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: DMA mapping on SCSI device?

  1. Re: DMA mapping on SCSI device?

    Luben Tuikov wrote:
    > --- On Mon, 1/28/08, Robert Han**** wrote:
    >> The trick is that if an ATAPI device is connected, we (as
    >> far as I'm
    >> aware) can't use ADMA mode, so we have to switch that
    >> port into legacy
    >> mode.

    >
    > Can you double check this with the HW architect of the
    > HW DMA engine of the ASIC?


    Will do so. However, previous statements from NVIDIA fairly clearly
    indicate that this is the case.

    >
    >> This means it's only capable of 32-bit DMA.
    >> However the other port
    >> on the controller may be connected to a hard drive and
    >> therefore still
    >> capable of 64-bit DMA.

    >
    > If this is indeed the case as you've presented it here,
    > it sounds like a HW shortcoming. I cannot see how the device
    > type (or protocol) dictate how the DMA engine operates.
    > They live in two different domains.


    Well, there is an indirect link. The ADMA interface (which supports
    64-bit DMA) cannot be used to issue ATAPI commands, so if an ATAPI
    device is connected we have to go to legacy mode, which supports only
    32-bit DMA.

    I'm not sure why ADMA mode doesn't support ATAPI. The only reason I can
    think of is that there's issues since ATAPI commands can potentially be
    of unpredictable transfer size. The "real" ADMA spec that the NVIDIA
    implementation is loosely based on does have some special "ignore
    excess" controls that don't seem to be in the NVIDIA version (or at
    least not to the knowledge I have on this hardware).

    And yes, it is a rather unfortunate hardware shortcoming (presuming that
    it is entirely true).

    >
    >> The ideal solution would be to do mapping against a
    >> different struct
    >> device for each port, so that we could maintain the proper
    >> DMA mask for
    >> each of them at all times. However I'm not sure if
    >> that's possible. The
    >> thought of using the SCSI struct device for DMA mapping was
    >> brought up
    >> at one point.. any thoughts on that?

    >
    > The reason for this is that the object that a struct scsi_dev
    > represents has nothing to do with HW DMA engines.
    >
    > It looks like your current solution is correct and
    > x86_64's blk_queue_bounce_limit needs work.
    >
    > Luben
    >
    >

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

  2. Re: DMA mapping on SCSI device?

    Robert Han**** wrote:
    > Luben Tuikov wrote:
    >> --- On Mon, 1/28/08, Robert Han**** wrote:
    >>> The trick is that if an ATAPI device is connected, we (as
    >>> far as I'm aware) can't use ADMA mode, so we have to switch that
    >>> port into legacy mode.

    >>
    >> Can you double check this with the HW architect of the
    >> HW DMA engine of the ASIC?

    >
    > Will do so. However, previous statements from NVIDIA fairly clearly
    > indicate that this is the case.
    >
    >>
    >>> This means it's only capable of 32-bit DMA.
    >>> However the other port on the controller may be connected to a hard
    >>> drive and therefore still capable of 64-bit DMA.

    >>
    >> If this is indeed the case as you've presented it here,
    >> it sounds like a HW shortcoming. I cannot see how the device
    >> type (or protocol) dictate how the DMA engine operates.
    >> They live in two different domains.

    >
    > Well, there is an indirect link. The ADMA interface (which supports
    > 64-bit DMA) cannot be used to issue ATAPI commands, so if an ATAPI
    > device is connected we have to go to legacy mode, which supports only
    > 32-bit DMA.
    >
    > I'm not sure why ADMA mode doesn't support ATAPI. The only reason I can
    > think of is that there's issues since ATAPI commands can potentially be
    > of unpredictable transfer size. The "real" ADMA spec that the NVIDIA
    > implementation is loosely based on does have some special "ignore
    > excess" controls that don't seem to be in the NVIDIA version (or at
    > least not to the knowledge I have on this hardware).

    ...

    The original Pacific Digital ADMA cores *do* support most ATAPI commands
    in ADMA mode, including READ_CD, READ_10, etc.. With the caveat that if
    DSC completion state is required, the driver has to drop out of ADMA
    and poll for it after the ADMA command completes.

    Commands which were not ADMA compatible (eg. MODE_SENSE, TEST_UNIT_READY, ..)
    were simply handled with PIO (in the driver) rather than any form of DMA,
    which is okay because those commands are relatively infrequent.

    Note that Pacific Digital "officially" said "no ATAPI" for the ADMA design,
    but I implemented it regardless (for Linux) and it worked rather well.
    We could burn DVDs and back-up to tape simultaneously, with the burner
    and the tape unit sharing a single IDE cable/channel.

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

  3. Re: DMA mapping on SCSI device?

    Mark Lord wrote:
    > ..
    > Commands which were not ADMA compatible (eg. MODE_SENSE,
    > TEST_UNIT_READY, ..)
    > were simply handled with PIO (in the driver) rather than any form of DMA,
    > which is okay because those commands are relatively infrequent.

    ...

    A slight correction there: TEST_UNIT_READY was fine in ADMA mode as well.

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

  4. Re: DMA mapping on SCSI device?

    Mark Lord wrote:
    > Robert Han**** wrote:
    >> Luben Tuikov wrote:
    >>> --- On Mon, 1/28/08, Robert Han**** wrote:
    >>>> The trick is that if an ATAPI device is connected, we (as
    >>>> far as I'm aware) can't use ADMA mode, so we have to switch that
    >>>> port into legacy mode.
    >>>
    >>> Can you double check this with the HW architect of the
    >>> HW DMA engine of the ASIC?

    >>
    >> Will do so. However, previous statements from NVIDIA fairly clearly
    >> indicate that this is the case.
    >>
    >>>
    >>>> This means it's only capable of 32-bit DMA.
    >>>> However the other port on the controller may be connected to a hard
    >>>> drive and therefore still capable of 64-bit DMA.
    >>>
    >>> If this is indeed the case as you've presented it here,
    >>> it sounds like a HW shortcoming. I cannot see how the device
    >>> type (or protocol) dictate how the DMA engine operates.
    >>> They live in two different domains.

    >>
    >> Well, there is an indirect link. The ADMA interface (which supports
    >> 64-bit DMA) cannot be used to issue ATAPI commands, so if an ATAPI
    >> device is connected we have to go to legacy mode, which supports only
    >> 32-bit DMA.
    >>
    >> I'm not sure why ADMA mode doesn't support ATAPI. The only reason I
    >> can think of is that there's issues since ATAPI commands can
    >> potentially be of unpredictable transfer size. The "real" ADMA spec
    >> that the NVIDIA implementation is loosely based on does have some
    >> special "ignore excess" controls that don't seem to be in the NVIDIA
    >> version (or at least not to the knowledge I have on this hardware).

    > ..
    >
    > The original Pacific Digital ADMA cores *do* support most ATAPI commands
    > in ADMA mode, including READ_CD, READ_10, etc.. With the caveat that if
    > DSC completion state is required, the driver has to drop out of ADMA
    > and poll for it after the ADMA command completes.
    >
    > Commands which were not ADMA compatible (eg. MODE_SENSE,
    > TEST_UNIT_READY, ..)
    > were simply handled with PIO (in the driver) rather than any form of DMA,
    > which is okay because those commands are relatively infrequent.
    >
    > Note that Pacific Digital "officially" said "no ATAPI" for the ADMA design,
    > but I implemented it regardless (for Linux) and it worked rather well.
    > We could burn DVDs and back-up to tape simultaneously, with the burner
    > and the tape unit sharing a single IDE cable/channel.


    I'm told that the ADMA hardware does have some support for issuing ATAPI
    commands, however according to Allen Martin of NVIDIA, "The ATAPI
    support in the ADMA hardware had some serious problem that forced us to
    turn it off in the Windows driver." So it looks like ATAPI in ADMA mode
    is likely a non-starter.
    --
    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/

+ Reply to Thread