keystone2: use appropriate HD field for destination port
Subsystems (3)
PATCH 1/1 keystone2: use appropriate HD field for destination port
K2L and L2E have different from K2HK EthSS version, which uses tag_info field for destination slave port. This commit adds the dest_port_info field to the struct pktdma_cfg, to configure which HD filed tag_info or pkt_info shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the direct_info of the currently using netcp.
--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)
arch/arm/include/asm/ti-common/keystone_nav.h +8 -1
@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */ };extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port);void *ksnav_recv (struct pktdma_cfg *pktdma,u32 **pkt,int *num_bytes);void ksnav_release_rxhd (struct pktdma_cfg *pktdma,void *hd);
drivers/dma/keystone_nav.c +10 -2
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push (hd, pktdma->tx_snd_q, pkt, num_bytes);
drivers/net/keystone_net.c +1 -2
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ; -return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
Signature · 1 line
1.9.1
PATCH 1/1 keystone2: use appropriate HD field for destination port
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field. Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields. It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field depending on h/w revision, using #if.
Quoted 99 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_infofield for destination slave port. This commit adds thedest_port_infofield to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_infoshall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that worked on K2HK devices, the correct field for K2HK is the
pkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +8
-1@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */ };extern struct pktdma_cfg netcp_pktdma;@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port);void *ksnav_recv (struct pktdma_cfg *pktdma,u32 **pkt,int *num_bytes);void ksnav_release_rxhd (struct pktdma_cfg *pktdma,void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push (hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +1
-2@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ; -return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
PATCH 1/1 keystone2: use appropriate HD field for destination port
Quoted 119 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field. Like in
drivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields. It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field depending on h/w revision, using #if.
Quoted 101 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_infofield for destination slave port. This commit adds thedest_port_infofield
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that worked on K2HK devices, the correct field for K2HK is the
pkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port);void *ksnav_recv (struct pktdma_cfg *pktdma,u32 **pkt,int *num_bytes);void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;
Quoted 8 lines
Quoted 7 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Thanks,
Vitaly
PATCH 1/1 keystone2: use appropriate HD field for destination port
Vitaly,
Quoted 132 lines · Vitaly Andrianov
Quoted 120 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field. Like in
drivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields. It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field depending on h/w revision, using #if.
Quoted 102 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_infofield for destination slave port. This commit adds thedest_port_infofield
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that worked on K2HK devices, the correct field for K2HK is the
pkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
Quoted 8 lines
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent. It's better to fix it in drivers/net/keystone_net.c
PATCH 1/1 keystone2: use appropriate HD field for destination port
Quoted 142 lines · Ivan Khoronzhuk
Vitaly,
Quoted 139 lines · Vitaly Andrianov
Quoted 121 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field. Like in
drivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields. It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field depending on h/w revision, using #if.
Quoted 103 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_infofield for destination slave port. This commit adds thedest_port_infofield
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is thepkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Quoted 7 lines
Quoted 2 lines
Thanks,
VitalySorry, I supposed that first msg was not sent. It's better to fix it in
drivers/net/keystone_net.c
Ivan,
I don't understand your proposal. The network driver doesn't know anything about CPPI DMA engine internals. That is the navigator's job to fill appropriate packet BD fields and it only takes care about HW version differences.
Thanks,
Vitaly
PATCH 1/1 keystone2: use appropriate HD field for destination port
Vitaly,
Quoted 156 lines · Vitaly Andrianov
Quoted 146 lines · Ivan Khoronzhuk
Vitaly,
Quoted 143 lines · Vitaly Andrianov
Quoted 125 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like indrivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you will rewrite this function again?It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.Quoted 104 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds thedest_port_infofield
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is thepkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Quoted 7 lines
Quoted 2 lines
Thanks,
VitalySorry, I supposed that first msg was not sent. It's better to fix it in
drivers/net/keystone_net.c
Quoted 6 lines
Ivan,
I don't understand your proposal. The network driver doesn't know anything about CPPI DMA engine internals. That is the navigator's job to fill appropriate packet BD fields and it only takes care about HW version differences.
You have Eth h/w, you have pktDMA engine to communicate through, you have network driver that knows how to use pktDMA to communicate with Ethernet switch.
CPII DMA engine can be used to communicate with different h/w, not only with Ethernet switch. This can be used to send packets to PA, to SA, to QMSS PDSPs, to PA PDSPs and others parts, I don't talk even about AIF, SRIO, FFTC and others IPs that have Pktdma on board.
Each of them can use swinfo for different purposes.
In the chain to communicate directly with Eth you use net driver in the way keystone_net -> keystone_nav -> h/w pktdma -> eht You can use it also like keystone_srio -> keystone_nav -> h/w pktdma -> srio.
etc.
pktdma engine it's like a bus used to communicate with a h/w. So, it's not correct to fix driver specific issues in the bus s/w, that is used by different drivers.
Quoted 7 lines
Thanks,
Vitaly
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 keystone2: use appropriate HD field for destination port
Quoted 184 lines · ivan.khoronzhuk
Vitaly,
Quoted 158 lines · Vitaly Andrianov
Quoted 148 lines · Ivan Khoronzhuk
Vitaly,
Quoted 145 lines · Vitaly Andrianov
Quoted 127 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like indrivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.Quoted 105 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds thedest_port_infofield
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is thepkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num);}/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Quoted 7 lines
Quoted 2 lines
Thanks,
VitalySorry, I supposed that first msg was not sent. It's better to fix it in
drivers/net/keystone_net.cQuoted 6 lines
Ivan,
I don't understand your proposal. The network driver doesn't know anything about CPPI DMA engine internals. That is the navigator's job to fill appropriate packet BD fields and it only takes care about HW version differences.
You have Eth h/w, you have pktDMA engine to communicate through, you have network driver that knows how to use pktDMA to communicate with Ethernet switch.
CPII DMA engine can be used to communicate with different h/w, not only with Ethernet switch. This can be used to send packets to PA, to SA, to QMSS PDSPs, to PA PDSPs and others parts, I don't talk even about AIF, SRIO, FFTC and others IPs that have Pktdma on board.Each of them can use swinfo for different purposes.
In the chain to communicate directly with Eth you use net driver in the way
keystone_net->keystone_nav-> h/w pktdma -> eht You can use it also likekeystone_srio->keystone_nav-> h/w pktdma -> srio.
etc.
Quoted 4 lines
pktdma engine it's like a bus used to communicate with a h/w. So, it's not correct to fix driver specific issues in the bus s/w, that is used by different drivers.
OK. What is your proposal? How to fix the issue in the keystone_net.c, which doesn't have any idea about structure of buffer descriptors. And actually doesn't have to know about it.
The proposed patch fixes the bug of existing upstreamed driver and allow K2E and K2L users to work. It is fully tested on all supported devices.
The PA PDSP and SA drivers currently doesn't exist in u-boot and I don't have any information whether anybody is going to develop them in the nearest future.
Quoted 7 lines
Quoted 7 lines
Thanks,
Vitaly
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 keystone2: use appropriate HD field for destination port
Vitaly,
Quoted 201 lines · Vitaly Andrianov
Quoted 190 lines · ivan.khoronzhuk
Vitaly,
Quoted 164 lines · Vitaly Andrianov
Quoted 154 lines · Ivan Khoronzhuk
Vitaly,
Quoted 151 lines · Vitaly Andrianov
Quoted 133 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like indrivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.Quoted 108 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds thedest_port_info
field
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is thepkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num);}/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal in future commits. This commit is to fix the bug, which is in existing driver.
Quoted 7 lines
Quoted 2 lines
Thanks,
VitalySorry, I supposed that first msg was not sent. It's better to fix it in
drivers/net/keystone_net.cQuoted 6 lines
Ivan,
I don't understand your proposal. The network driver doesn't know anything about CPPI DMA engine internals. That is the navigator's job to fill appropriate packet BD fields and it only takes care about HW version differences.
You have Eth h/w, you have pktDMA engine to communicate through, you have network driver that knows how to use pktDMA to communicate with Ethernet switch.
CPII DMA engine can be used to communicate with different h/w, not only with Ethernet switch. This can be used to send packets to PA, to SA, to QMSS PDSPs, to PA PDSPs and others parts, I don't talk even about AIF, SRIO, FFTC and others IPs that have Pktdma on board.Each of them can use swinfo for different purposes.
In the chain to communicate directly with Eth you use net driver in the way
keystone_net->keystone_nav-> h/w pktdma -> eht You can use it also likekeystone_srio->keystone_nav-> h/w pktdma -> srio.
etc.Quoted 4 lines
pktdma engine it's like a bus used to communicate with a h/w. So, it's not correct to fix driver specific issues in the bus s/w, that is used by different drivers.
OK. What is your proposal? How to fix the issue in the
keystone_net.c, which doesn't have any idea about structure of buffer descriptors. And actually doesn't have to know about it.
Quoted 7 lines
The proposed patch fixes the bug of existing upstreamed driver and allow K2E and K2L users to work. It is fully tested on all supported devices.
The PA PDSP and SA drivers currently doesn't exist in u-boot and I don't have any information whether anybody is going to develop them in the nearest future.
It doesn't matter exist those drivers or not. It's a structured model. If, for instance, you are going to fix some errata in I2C RTC, what will you do? fix it in I2C driver? But better place is RTC driver.
It's partly an API issue. It should be allowed to assign protocol specific flags field in packet_info and allow others to use swinfo in the same time.
It be better to add to pktdma_config field like protocol_flags.
in keystone_nav send function do:hd->packet_info = qm_cfg->qpool_num |
(qm_cfg->protocol_flags) & 0xf << 16;
and in keystone_net, statically:
#if (REVISION == REVISION_WITH_BUG)qm_cfg->protocol_flags = dest_port;
#elseqm_cfg->protocol_flags = 0;
But I'm not sure about one thing. Do you have revisions that use swinfo for port number and cannot use packet_info for this goal? In this case you should support version when software field is used also.
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines
Thanks,
Vitaly
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 keystone2: use appropriate HD field for destination port
Quoted 239 lines · ivan.khoronzhuk
Vitaly,
Quoted 207 lines · Vitaly Andrianov
Quoted 196 lines · ivan.khoronzhuk
Vitaly,
Quoted 169 lines · Vitaly Andrianov
Quoted 159 lines · Ivan Khoronzhuk
Vitaly,
Quoted 156 lines · Vitaly Andrianov
Quoted 136 lines · Ivan Khoronzhuk
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like indrivers/net/keystone_net.cThe keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.Quoted 111 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds thedest_port_info
field
to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_info
shall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is thepkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +6
-0@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};extern struct
pktdma_cfgnetcp_pktdma;arch/arm/include/asm/ti-common/keystone_nav.h +2
-1@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port); void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
voidksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push(hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +0
-0@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ;Quoted 9 lines
Quoted 8 lines
drivers/net/keystone_net.c +1
-2-return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num);}/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.Quoted 7 lines
Quoted 2 lines
Thanks,
VitalySorry, I supposed that first msg was not sent. It's better to fix it in
drivers/net/keystone_net.cQuoted 7 lines
Ivan,
I don't understand your proposal. The network driver doesn't know anything about CPPI DMA engine internals. That is the navigator's job to
fill appropriate packet BD fields and it only takes care about HW version differences.You have Eth h/w, you have pktDMA engine to communicate through, you have network driver that knows how to use pktDMA to communicate with Ethernet switch.
CPII DMA engine can be used to communicate with different h/w, not only with Ethernet switch. This can be used to send packets to PA, to SA, to QMSS PDSPs, to PA PDSPs and others parts, I don't talk even about AIF, SRIO, FFTC and others IPs that have Pktdma on board.Each of them can use swinfo for different purposes.
In the chain to communicate directly with Eth you use net driver in the way
keystone_net->keystone_nav-> h/w pktdma -> eht You can use it also likekeystone_srio->keystone_nav-> h/w pktdma -> srio.
etc.Quoted 4 lines
pktdma engine it's like a bus used to communicate with a h/w. So, it's not correct to fix driver specific issues in the bus s/w, that is used by different drivers.
OK. What is your proposal? How to fix the issue in the
keystone_net.c, which doesn't have any idea about structure of buffer descriptors. And actually doesn't have to know about it.Quoted 7 lines
The proposed patch fixes the bug of existing upstreamed driver and allow K2E and K2L users to work. It is fully tested on all supported devices.
The PA PDSP and SA drivers currently doesn't exist in u-boot and I don't have any information whether anybody is going to develop them in the nearest future.
It doesn't matter exist those drivers or not. It's a structured model. If, for instance, you are going to fix some errata in I2C RTC, what will you do? fix it in I2C driver? But better place is RTC driver.
It's partly an API issue. It should be allowed to assign protocol specific flags field in
packet_infoand allow others to use swinfo in the same time.It be better to add to
pktdma_configfield likeprotocol_flags.in
keystone_navsend function do:hd->packet_info=qm_cfg->qpool_num|(qm_cfg->protocol_flags) & 0xf << 16;and in
keystone_net, statically:
#if (REVISION ==REVISION_WITH_BUG)qm_cfg->protocol_flags=dest_port;
#elseqm_cfg->protocol_flags= 0;
Quoted 4 lines
But I'm not sure about one thing. Do you have revisions that use swinfo for port number and cannot use
packet_infofor this goal? In this case you should support version when software field is used also.
Or even better to add new structure like pkt_data with vars:
struct pkt_data {
int protocol_flags;
u32 tags;
u32 swinfo[2];
char *data; (that is pkt)
int num_bytes;
};and
int ksnav_send(struct pktdma_cfg *pktdma, struct pkt_data *pkt) {
....
hd->packet_info = qm_cfg->qpool_num |
((pkt->protocol_flags) & 0xf) << 16;
hd->tag_info = tags;
....
}
and in keystone_net, statically:
#if (REVISION == REVISION_WITH_BUG)
pkt->protocol_flags = dest_port;
#else
pkt->protocol_flags = 0;
pkt->tags = dest_port;
In this case each driver will be doing what it's allowed to. It can be done with two patches.
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines
Thanks,
Vitaly
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 keystone2: use appropriate HD field for destination port
In reply to Vitaly AndrianovHi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field. Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating between different IPs, and each of them decide how to use swinfo fields. It's protocol specific information and should be known only for sending parts. What if tomorrow will be decided to send some packet to PA?, rewrite this function again?
It's not the place for such kind information.
This is the h/w specific static decision and no need to check this for each sent packet. It be better to statically assign how to use this field depending on h/w revision, using macro configs, for instance:
CONFIG_SOC_K2HKCONFIG_KSNET_NETCP_V1_0CONFIG_KSNET_NETCP_V1_5
Quoted 99 lines · Vitaly Andrianov
K2L and L2E have different from K2HK EthSS version, which uses
tag_infofield for destination slave port. This commit adds thedest_port_infofield to the structpktdma_cfg, to configure which HD filedtag_infoorpkt_infoshall be used to configure descriptor.Before that commit the swinfo[2] was used for that purpose. Even if that worked on K2HK devices, the correct field for K2HK is the
pkt_info.The
netcp_send()configure appropriate HD info field depending on thedirect_infoof the currently using netcp.Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>--- arch/arm/include/asm/ti-common/keystone_nav.h | 9 ++++++++- drivers/dma/keystone_nav.c | 12 ++++++++++-- drivers/net/keystone_net.c | 3 +-- 3 files changed, 19 insertions(+), 5 deletions(-)arch/arm/include/asm/ti-common/keystone_nav.h +8
-1@@ -152,6 +152,11 @@ struct rx_flow_regs {u32 thresh[3 ]; }; +enum dest_port_info { +PKT_INFO , +TAG_INFO +}; +struct pktdma_cfg {struct global_ctl_regs *global;struct tx_chan_regs *tx_ch;@@ -167,6 +172,7 @@ struct pktdma_cfg {u32 tx_snd_q;u32 rx_flow;/* flow that is used for RX */ +enum dest_port_info dest_port_info;/* HD fiels for dest port bits */ };extern struct pktdma_cfg netcp_pktdma;@@ -184,7 +190,8 @@ struct rx_buff_desc {int ksnav_close (struct pktdma_cfg *pktdma);int ksnav_init (struct pktdma_cfg *pktdma,struct rx_buff_desc *rx_buffers); -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2); +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port);void *ksnav_recv (struct pktdma_cfg *pktdma,u32 **pkt,int *num_bytes);void ksnav_release_rxhd (struct pktdma_cfg *pktdma,void *hd);drivers/dma/keystone_nav.c +10
-2@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)return QM_OK ; } -int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes,u32 swinfo2) +int ksnav_send (struct pktdma_cfg *pktdma,u32 *pkt,int num_bytes, +u32 dest_port) {struct qm_host_desc *hd;@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)if (hd ==NULL )return QM_ERR ; + dest_port &=0xf ; hd->desc_info = num_bytes; - hd->swinfo[2 ] = swinfo2; +if (pktdma->dest_port_info ==PKT_INFO ) { + hd->packet_info = qm_cfg->qpool_num | (dest_port <<16 ); + }else { + hd->packet_info = qm_cfg->qpool_num; + hd->tag_info = dest_port; + } + hd->packet_info = qm_cfg->qpool_num;qm_buff_push (hd, pktdma->tx_snd_q, pkt, num_bytes);drivers/net/keystone_net.c +1
-2@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int slave_port_num)if (num_bytes <EMAC_MIN_ETHERNET_PKT_SIZE ) num_bytes =EMAC_MIN_ETHERNET_PKT_SIZE ; -return ksnav_send (&netcp_pktdma, buffer, - num_bytes, (slave_port_num) <<16 ); +return ksnav_send (&netcp_pktdma, buffer, num_bytes, slave_port_num); }/* Eth device open */