hd controller

hd controller

[horseriver]

hi:)

   I am curious about how hd controller work .
   When user am reaing/writing hd ,it was implemented by sending command
   to hd controller's special port.Then ,how does the controller know
   a new command has received?

   In this procedure , what work does the hd driver do ?

thanks!

hd controller

[Valdis.Kletnieks at vt.edu]

On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
> hi:)
>
>    I am curious about how hd controller work .
>    When user am reaing/writing hd ,it was implemented by sending command
>    to hd controller's special port.Then ,how does the controller know
>    a new command has received?
>
>    In this procedure , what work does the hd driver do ?

You may wish to get a copy of 'Linux Device Drivers, 3rd Edition'
and read it before posting lots of questions here.

A free version is available online, and last I checked it was the very
first hit if you google for 'Linux device drivers".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/c385d343/attachment.bin 

hd controller

[Greg Freemyer]

On Thu, Feb 7, 2013 at 1:13 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
> > hi:)
> >
> >    I am curious about how hd controller work .
> >    When user am reaing/writing hd ,it was implemented by sending command
> >    to hd controller's special port.Then ,how does the controller know
> >    a new command has received?
> >
> >    In this procedure , what work does the hd driver do ?
>
> You may wish to get a copy of 'Linux Device Drivers, 3rd Edition'
> and read it before posting lots of questions here.
>
> A free version is available online, and last I checked it was the very
> first hit if you google for 'Linux device drivers".
>
>
Be sure to read about scatter/gather list processing at the disk controller
level.  I believe most hd controllers these days can accept an array of
pointers that tells it where to find (place) date for writes (reads).  It
would be the drivers responsibility to build the scatter/gather meta
information to be compatible with what the controller specs call for.

There is a little info about that here:
http://www.makelinux.net/books/ulk3/understandlk-CHP-14-SECT-1

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/c436d5a1/attachment.html 

hd controller

[Anuz Pratap Singh Tomar]

On Thu, Feb 7, 2013 at 6:13 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
> > hi:)
> >
> >    I am curious about how hd controller work .
> >    When user am reaing/writing hd ,it was implemented by sending command
> >    to hd controller's special port.Then ,how does the controller know
> >    a new command has received?
> >
> >    In this procedure , what work does the hd driver do ?
>
> You may wish to get a copy of 'Linux Device Drivers, 3rd Edition'
> and read it before posting lots of questions here.
>
> A free version is available online, and last I checked it was the very
> first hit if you google for 'Linux device drivers".
>
> This!
Please read LDD, LKD and ULK fully before asking questions.

> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/2fb2e6f3/attachment.html 

hd controller

[Peter Teoh]

at the lowest level, SCSI/IDE/SATA all shared a common command base
(perhaps with variations) - which is ATA command (because in
drivers/ata/*.c u can find the symbol ATA_XXX_CMD in all the three
different hardware architecture):

Below is a an example specified by standard body (these command are OS
agnostic):

https://github.com/gcastigl/SO2C2011TP2/blob/master/doc/ATA%20-%20ATAPI%20Command%20Set.pdf

Look at all the "ATA_CMD_*" command here:

https://github.com/Scorpiion/Renux_u-boot/blob/master/include/ata.h

So the drivers just literally concatenate these command into a string and
send it over to the device.

for example in drivers/ata/libata-core.c:

static int ata_read_native_max_address(struct ata_device *dev, u64
*max_sectors)
{
        unsigned int err_mask;
        struct ata_taskfile tf;
        int lba48 = ata_id_has_lba48(dev->id);

        ata_tf_init(dev, &tf);

        /* always clear all address registers */
        tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;

        if (lba48) {
                tf.command = ATA_CMD_READ_NATIVE_MAX_EXT;
                tf.flags |= ATA_TFLAG_LBA48;
        } else
                tf.command = ATA_CMD_READ_NATIVE_MAX;

the tf.command data within is ultimately send by port I/O operation.
BUT.....not sure of details, corrections welcome :-).

On Thu, Feb 7, 2013 at 4:19 PM, horseriver <horserivers@gmail.com> wrote:

> hi:)
>
>    I am curious about how hd controller work .
>    When user am reaing/writing hd ,it was implemented by sending command
>    to hd controller's special port.Then ,how does the controller know
>    a new command has received?
>
>    In this procedure , what work does the hd driver do ?
>
> thanks!
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130208/87b049e2/attachment-0001.html 

hd controller

[Valdis.Kletnieks at vt.edu]

On Fri, 08 Feb 2013 07:48:39 +0800, Peter Teoh said:

> So the drivers just literally concatenate these command into a string and
> send it over to the device.

The reason that good disk drivers are hard to write is because it isn't
*just* literally concatenating the commands - it also has to do memory
management (make sure that everybody's data ends up in the right buffers),
command queue management, elevator management (if there's multiple I/O
requests pending from userspace, what order do we issue them in?), error
recovery, power management, and a ton of other stuff...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/4cba76c7/attachment.bin 

hd controller

[Peter Teoh]

good sharing.   following up on your comments:

in the kernel source:

block/*.c are the files for block I/O related stuff - the layer just before
ATA, implementing stuff like elevator I/O etc.
drivers/block/*.c:  hardware-specific files that understand how to talk to
each type of harddisk.
drivers/scsi/*.c:   generally SCSI protocol related stuff (lib*.c), but may
contain device specific stuff.
drivers/ide/*.c:
drivers/ata/*.c:   among the lowest level just before sending out port I/O
operation.

On Fri, Feb 8, 2013 at 8:26 AM, <Valdis.Kletnieks@vt.edu> wrote:

> On Fri, 08 Feb 2013 07:48:39 +0800, Peter Teoh said:
>
> > So the drivers just literally concatenate these command into a string and
> > send it over to the device.
>
> The reason that good disk drivers are hard to write is because it isn't
> *just* literally concatenating the commands - it also has to do memory
> management (make sure that everybody's data ends up in the right buffers),
> command queue management, elevator management (if there's multiple I/O
> requests pending from userspace, what order do we issue them in?), error
> recovery, power management, and a ton of other stuff...
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130208/4281ba0b/attachment.html