0

I am going through realtek r8169 driver and but kind of stuck in this line

    tp->RxDescArray = dma_alloc_coherent(&pdev->dev, R8169_RX_RING_BYTES,
                     &tp->RxPhyAddr, GFP_KERNEL);

From the book Linux device driver, it just says it is ...Function handles both the allocation and the mapping of the buffer, ...arguments are device structure and the size of buffer needed

What does that mean: allocation I could understanding but what is it mean by mapping

does this mean that what ever I have in pdev represented device's rx descriptor that same I will have in what returns from dma_alloc_coherent which is tp->RxDescArray a descriptor as a software object? tp->RxDescArray is of type RxDesc in the driver which is like following

    struct RxDesc {
        __le32 opts1;
        __le32 opts2;
        __le64 addr;
     };

if this is what mapping is: means whatever I have in pdev represented device rx decriptor on physical device that same I will have in software object tp->RxDescArray is that what mapping means. then who define the structure of RxDesc, is this something included in datasheet. If it does then under which section? There are numerous sections in a datasheet. should it be more clearer `

Update Also like to know what does this line does

  tp->RxDescArray[NUM_RX_DESC - 1].opts1 |= cpu_to_le32(RingEnd);

tp->RxDescArray is of type RxDesc (not array of RxDesc) does this statement mark the end of variable RxDescArray means what every next will happen will after that end address

Update 2

I need info on if I have a datasheet lets say from intel E1000E driver, or r8169 driver from RealTek, then how I create create Rx Descrptor structure, in above code it does something like this

    struct RxDesc {
    __le32 opts1;
    __le32 opts2;
    __le64 addr;
     }

what is opts1, opts2 and addr? how author of this driver got this idea of creating this structure. Only he had was datasheet with many hex values

user786
  • 3,902
  • 4
  • 40
  • 72

2 Answers2

3

DMA accesses are translated by the IOMMU, which on Intel systems is described in the Intel® Virtualization Technology for Directed I/O (VT-d) specification.

The function dma_alloc_coherent allocates memory and introduces a mapping into the DMA page tables so that the memory is accessible to the device. The address returned is not the virtual or physical address of the memory, but is a I/O virtual address (IOVA), which the device can use to access memory. The IOVA is translated by the IOMMU into the physical memory address when the device performs DMA.

The IOMMU prevents any device from accessing physical memory that hasn't been mapped into that specific device's I/O address space.

prl
  • 11,716
  • 2
  • 13
  • 31
  • So for IOMMU do I need to enable physical layer in RTL r8169 driver it register `mdio: phy in mac` and initializes physical layer by assigning `mii_bus->read=someting_function` ns `mii_bis->write=something_write_function`. and in initialize phy function it simply does `phy_write_paged` and `writel`,etc. So Do I need to register and initialize phy to began with MMIO/DMA/ or any interaction with device – user786 Feb 14 '21 at 06:33
  • Initializing the phy doesn’t have anything to do with DMA. But you have to initialize the phy before you can send or receive anything on the network. – prl Feb 14 '21 at 14:12
  • So is that mean I can not write data or values to nic register using `writel` if I have not register or initialized phy – user786 Feb 14 '21 at 14:31
  • 1
    The phy has **nothing** to do with CPU accesses to the NIC registers. You seem to be **very** confused about how a NIC works and continuing to ask questions here isn’t the best way for you to gain an understanding. Also your question continues to expand from the original question about DMA mappings into completely unrelated areas about how a NIC works. Stack overflow tries to keep each question on a single topic. – prl Feb 14 '21 at 14:34
  • ok I think I am getting it, so mdio/media access controller/phy (from OSI model) have to be in driver to make driver connect to a network from `you have to initialize the phy before you can send or receive anything on the network` for this, I also see it need to configured to NIC device register. it is simply done this using writing to device like using `writel/writeb/writew` family of functions. There is mdio implemented and that requires I/O writing/configuring to device for `phy/mdio`. This is from code of drivers like `E1000E`/`r8169` drivers. – user786 Feb 15 '21 at 06:11
  • final question. So in `init_phy` from r8169 it uses these functions: , `phy_write_paged` so there are phy registers as well. Are these phy registers exists for implementing OSI physical layer and functions like `phy_write_paged` after execution they write to where? these function calls are in phy_init and called when device go up in open function of netdev_ops – user786 Feb 15 '21 at 06:17
0

RingEnd marks the end of the ring buffer for the NIC. So that NIC DMA engine knows where to jump to the start of the ring buffer.

hkall
  • 26
  • 1
  • Why end of ring buffer had to be recorded? do u means NIC card can have no idea about the software object `struct RxDesc` which variable starts where and ends where,Please clarify – user786 Feb 09 '21 at 08:47
  • How's the NIC supposed to know the size of the ring buffer you set up in the driver? That's what the ring end marker is good for. – hkall Feb 10 '21 at 09:06
  • Does every RxDesc element pointed in tp->RxDescArray pointer has to be marked by ring end marker like `tp->RxDescArray[NUM_RX_DESC - 1].opts1 |= cpu_to_le32(RingEnd);` ? – user786 Feb 10 '21 at 15:06
  • Of course not. How many ends can a ring buffer have? You ask a number of low-level questions that show you miss the basics. Therefore I'd recommend you first understand the big picture and concepts like DMA descriptor ring buffers. Instead of asking what a function does, look at the code and where and in which context the function is used. – hkall Feb 11 '21 at 16:21