Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Sebastian, On Friday 24 of March 2023 11:43:02 Sebastian Huber wrote: > it seems we have two different MDIO services: not not nice to have two different APIs... In general it would be great to have actual MDIO PHY chips drivers in a separate folder(s) and actual NIC driver should provide only MDIO access routines through some unified API. > cpsw/src/include/mdio.h:extern unsigned int MDIOPhyRegRead(unsigned int > baseAddr, unsigned int phyAddr, > > uLan/ports/driver/tms570_emac/ti_drv_mdio.h:MDIOPhyRegRead(volatile > tms570_mdio_t *baseAddr, uint32_t phyAddr, > None of these two definitions is ideal uint32_t MDIOPhyRegRead(volatile tms570_mdio_t *baseAddr, uint32_t phyAddr, uint32_t regNum, volatile unsigned short *dataPtr) extern unsigned int MDIOPhyRegRead(unsigned int baseAddr, unsigned int phyAddr, unsigned int regNum, volatile unsigned short *dataPtr); Same for write etc... If the generic mdio.h and PHY chip drivers should be used for multiple NICs, then some prototype like uint32_t MDIOPhyRegRead(mdiophy_state_t *mdiophyst, uint32_t phyAddr, uint32_t regNum, volatile unsigned short *dataPtr) should be used and and mdiophy_state_t should provide actual pointers to the routines specific for given NIC as well as base address. That way multiple instances of even different MDIO interfaces can be supported. I would like to see something like Linux struct mdio_if_info https://elixir.bootlin.com/linux/latest/source/include/linux/mdio.h#L133 or some BSD equivalent. I see that in BSD based RTEMS TCP/IP stack is struct rtems_mdio_info defined https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/rtems/rtems_mii_ioctl.h May it be it could be reused there even that I do not like that pointer to struct rtems_mdio_info structure is not passed into rtems_mdio_read_func() and rtems_mdio_write_func() functions. So generally it would be great if this part can be sorted and cleaned... I hope to have more time during winter term... On Wednesday 29 of March 2023 13:43:28 Sebastian Huber wrote: > > up. I would like to test code on TMS570LS3137 when I find > > time and on TMS570LC43 one day... > > I work currently with these chips. Nice to know, I have EDKs for both at home... We have developed really advanced solution to combine N2HET, DMAs and integrated D-CAN controllers to achieve time triggered CAN operation with these with maximal CPU offloading. So if there is interrest we can try to port that solution to RTEMS... We have Matlab/Simulink target for that TMS570LS3137 built as well and lot can be ported to RTEMS. We have even done design of experimental ECU based on TMS570LS3137 with my colleague from PiKRON company for Porsche... So we can share knowledge... TMS570LC4357 is even more interesting, becase it has more RAM which could allow better TCP/IP experience even without external RAM. Best wishes, Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Pavel, thanks for your information. On 29.03.23 13:40, Pavel Pisa wrote: We need to resolve license update in the files and get rid of uLAN directory and I hope that it can be cleaned up. I would like to test code on TMS570LS3137 when I find time and on TMS570LC43 one day... I work currently with these chips. Kind regards, Sebastian -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Sebastian,
On Friday 24 of March 2023 11:21:57 Sebastian Huber wrote:
> Hello Pavel,
>
> On 18.03.23 01:04, Pavel Pisa wrote:
> > As for
> >
> > +static inline void
> > +tms570_data_sync_barier(void)
> > +{
> > +#ifdef __arm__
> > + _ARM_Data_synchronization_barrier();
> > +#endif
> > +}
> >
> > it is OK but may it be not ideal, because more drivers could require
> > write buffers and instructions memory access order synchronization.
> > We have added that definition to ports/os/rtems/arch/sys_arch.h
> >
> > #ifndef __rtems__
> > static inline sys_prot_t
> > sys_arch_protect(void)
> > {
> >sys_prot_t pval;
> >
> >rtems_interrupt_disable(pval);
> >return pval;
> > }
> >
> > static inline void
> > sys_arch_unprotect(sys_prot_t pval)
> > {
> >rtems_interrupt_enable(pval);
> > }
> >
> > static inline void
> > sys_arch_data_sync_barier(void){
> >_ARM_Data_synchronization_barrier();
> > }
> > #else
> >
> > as the generic solution when to allow same drivers to be used
> > with different architectures. There can be more drivers requiring
> > such protection.
>
> ok, I will keep the sys_arch_data_sync_barier(). What I don't understand
> is why this stuff is under #ifndef __rtems__ (NOT defined __rtems__).
this is more complex, I need to refresh my memory. We have been using
uLAN OMK fork of LwIP code code in system less, RTEMS and FreeRTOS
setup.
On simple setups, as is FreeRTOS, the sys_arch_protect()
and sys_arch_unprotect() enables and disables interrupts
https://gitlab.com/pikron/sw-base/lwip/-/blob/omk-devel/ports/os/freertos/arch/sys_arch.h#L103
The same change has been made done for RTEMS by bulk change
https://gitlab.com/pikron/sw-base/lwip/-/blob/omk-devel/ports/os/rtems/arch/sys_arch.h#L103
But solution with IRQ disable only could not work on SMP system.
https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c#n371
There is patch by Kinsey Moore which correct code to be safe for SMP
and switches rtems_interrupt_disable() to
pval = _Thread_Dispatch_disable();
+ rtems_recursive_mutex_lock( _arch_lock );
https://git.rtems.org/rtems-lwip/commit/uLan/ports/os/rtems/arch/sys_arch.c?id=c3b8ce71c4897be9984e555d8f1042e273edaa35
and later to
rtems_recursive_mutex_lock( _arch_lock );
which are correct if the interrupt is never called directly into LwIP
driver but only through worker thread wakeup.
So in actual header file, the part which is under #ifndef __rtems__
should read as use interrupt disable on generic system
but on RTEMS define declare functions prototypes and actual
implementation is in os/rtems/arch/sys_arch.c and for case of
use of the drivers over worker thread is correct.
But if I remember well then actual protect mechanism
should be used minimally if the driver uses thread
model..
So generally, the part in #ifndef __rtems__ in header file
can be moved away, the decalartions without functions body
are enough.
We need to resolve license update in the files and get
rid of uLAN directory and I hope that it can be cleaned
up. I would like to test code on TMS570LS3137 when I find
time and on TMS570LC43 one day...
Best wishes,
Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Pavel,
it seems we have two different MDIO services:
cpsw/src/include/mdio.h:extern unsigned int MDIOPhyRegRead(unsigned int
baseAddr, unsigned int phyAddr,
uLan/ports/driver/tms570_emac/ti_drv_mdio.h:MDIOPhyRegRead(volatile
tms570_mdio_t *baseAddr, uint32_t phyAddr,
I get these warnings currently:
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c: In function 'PHY_reset':
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:61:19: warning:
passing argument 1 of 'MDIOPhyRegWrite' makes integer from pointer
without a cast [-Wint-conversion]
61 | MDIOPhyRegWrite(mdioBaseAddr, phyAddr, PHY_BMCR, PHY_RESET_m);
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:68:42: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
68 | extern void MDIOPhyRegWrite(unsigned int baseAddr, unsigned int
phyAddr,
| ~^~~~
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:62:25: warning:
passing argument 1 of 'MDIOPhyRegRead' makes integer from pointer
without a cast [-Wint-conversion]
62 | while (MDIOPhyRegRead(mdioBaseAddr, phyAddr, PHY_BMCR,
) & PHY_RESET_m);
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:66:49: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
66 | extern unsigned int MDIOPhyRegRead(unsigned int baseAddr,
unsigned int phyAddr,
|~^~~~
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c: In function
'PHY_partner_ability_get':
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:68:26: warning:
passing argument 1 of 'MDIOPhyRegRead' makes integer from pointer
without a cast [-Wint-conversion]
68 | return (MDIOPhyRegRead(mdioBaseAddr, phyAddr, PHY_ANLPAR,
regContent));
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:66:49: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
66 | extern unsigned int MDIOPhyRegRead(unsigned int baseAddr,
unsigned int phyAddr,
|~^~~~
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c: In function
'PHY_start_auto_negotiate':
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:77:22: warning:
passing argument 1 of 'MDIOPhyRegRead' makes integer from pointer
without a cast [-Wint-conversion]
77 | if (MDIOPhyRegRead(mdioBaseAddr, phyAddr, PHY_BMCR,
) != TRUE) {
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:66:49: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
66 | extern unsigned int MDIOPhyRegRead(unsigned int baseAddr,
unsigned int phyAddr,
|~^~~~
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:81:19: warning:
passing argument 1 of 'MDIOPhyRegWrite' makes integer from pointer
without a cast [-Wint-conversion]
81 | MDIOPhyRegWrite(mdioBaseAddr, phyAddr, PHY_BMCR, regContent);
/* originally ...HY_BMCR, PHY_RESET_m | PHY_AUTONEG_EN_m); */
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:68:42: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
68 | extern void MDIOPhyRegWrite(unsigned int baseAddr, unsigned int
phyAddr,
| ~^~~~
../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:84:22: warning:
passing argument 1 of 'MDIOPhyRegRead' makes integer from pointer
without a cast [-Wint-conversion]
84 | if (MDIOPhyRegRead(mdioBaseAddr, phyAddr, PHY_ANAR,
) != TRUE) {
| ^~~~
| |
| volatile tms570_mdio_t *
In file included from ../../uLan/ports/driver/tms570_emac/phy_dp83848h.c:38:
../../cpsw/src/include/mdio.h:66:49: note: expected 'unsigned int' but
argument is of type 'volatile tms570_mdio_t *'
66 | extern unsigned int MDIOPhyRegRead(unsigned int baseAddr,
unsigned int phyAddr,
|~^~~~
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Pavel,
On 18.03.23 01:04, Pavel Pisa wrote:
As for
+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+ _ARM_Data_synchronization_barrier();
+#endif
+}
it is OK but may it be not ideal, because more drivers could require
write buffers and instructions memory access order synchronization.
We have added that definition to ports/os/rtems/arch/sys_arch.h
#ifndef __rtems__
static inline sys_prot_t
sys_arch_protect(void)
{
sys_prot_t pval;
rtems_interrupt_disable(pval);
return pval;
}
static inline void
sys_arch_unprotect(sys_prot_t pval)
{
rtems_interrupt_enable(pval);
}
static inline void
sys_arch_data_sync_barier(void){
_ARM_Data_synchronization_barrier();
}
#else
as the generic solution when to allow same drivers to be used
with different architectures. There can be more drivers requiring
such protection.
ok, I will keep the sys_arch_data_sync_barier(). What I don't understand
is why this stuff is under #ifndef __rtems__ (NOT defined __rtems__).
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Hello Kinsey and Sebastian,
On Thursday 09 of March 2023 14:46:28 Kinsey Moore wrote:
> Normally with rtems-lwip I would complain that this doesn't follow the
> convention of using #ifdef __rtems__ to modify files from upstream sources
> (each root directory except rtemslwip has an upstream source), but the uLan
> authors have given permission to fully integrate this code into the
> rtemslwip directory where possible (the TI code will go into its own
> directory). This patch looks good.
driver has no upstream, it has been designed for RTEMS and then
used even on FreeRTOS and it except for headers from Ti mainly
used for MDIO, it has been designed from scratch at CTU.
We have originally started and tried to fix Ti HalCoGen
code to work with Ti provided FreeRTOS and it newer worked
reliably. Then we have thrown away all that stuff and started
from scratch with some inspiration from similar BSD drivers.
I have call with Premek and we both agree on relicense to RTEMS
BSD variant. I can prepare commit when I have some while (I am
loaded by lectures, students support now). Next step is to move
code to
rtemslwip/tms570
As for
+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+ _ARM_Data_synchronization_barrier();
+#endif
+}
it is OK but may it be not ideal, because more drivers could require
write buffers and instructions memory access order synchronization.
We have added that definition to ports/os/rtems/arch/sys_arch.h
#ifndef __rtems__
static inline sys_prot_t
sys_arch_protect(void)
{
sys_prot_t pval;
rtems_interrupt_disable(pval);
return pval;
}
static inline void
sys_arch_unprotect(sys_prot_t pval)
{
rtems_interrupt_enable(pval);
}
static inline void
sys_arch_data_sync_barier(void){
_ARM_Data_synchronization_barrier();
}
#else
as the generic solution when to allow same drivers to be used
with different architectures. There can be more drivers requiring
such protection.
In the fact tms570_emac is similar or equivalent to some other
ETHERNET NICs, I do not remember which one at the moment, I would
need to search. But I think that I have seen same/similar registers
organization on other targets.
If I prepare changes of license, should I sent patches
only to the mailing list or should I try to create branch
and try to push it to rtems-lwip or fork some GitHub
matching repo?
...
It seems that my SSH key for pp...@dispatch.rtems.org has
expired?
Best wishes,
Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
On Thu, Mar 9, 2023 at 7:48 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 09.03.23 14:46, Kinsey Moore wrote: > > Normally with rtems-lwip I would complain that this doesn't follow the > > convention of using #ifdef __rtems__ to modify files from upstream > > sources (each root directory except rtemslwip has an upstream source), > > but the uLan authors have given permission to fully integrate this code > > into the rtemslwip directory where possible (the TI code will go into > > its own directory). This patch looks good. > > Ok, does this mean this driver as an active upstream? > The non-TI portions of the uLan upstream are not active and will be integrated sometime soon. The person doing the integrating needs to evaluate the source of the TI portions and we can see how active it is. As of now, I don't know how active the TI portions are. > > I still have some issues with this driver since the MDIO interfaces seem > to be duplicated. > Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
On 09.03.23 14:46, Kinsey Moore wrote: Normally with rtems-lwip I would complain that this doesn't follow the convention of using #ifdef __rtems__ to modify files from upstream sources (each root directory except rtemslwip has an upstream source), but the uLan authors have given permission to fully integrate this code into the rtemslwip directory where possible (the TI code will go into its own directory). This patch looks good. Ok, does this mean this driver as an active upstream? I still have some issues with this driver since the MDIO interfaces seem to be duplicated. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()
Normally with rtems-lwip I would complain that this doesn't follow the
convention of using #ifdef __rtems__ to modify files from upstream sources
(each root directory except rtemslwip has an upstream source), but the uLan
authors have given permission to fully integrate this code into the
rtemslwip directory where possible (the TI code will go into its own
directory). This patch looks good.
On Thu, Mar 9, 2023 at 6:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> This function is not present in the lwIP mainline. Move it to the only
> user and rename it to tms570__data_sync_barier().
> ---
> uLan/ports/driver/tms570_emac/tms570_netif.c | 16
> uLan/ports/os/rtems/arch/sys_arch.h | 5 -
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/uLan/ports/driver/tms570_emac/tms570_netif.c
> b/uLan/ports/driver/tms570_emac/tms570_netif.c
> index 8d14687..e166869 100644
> --- a/uLan/ports/driver/tms570_emac/tms570_netif.c
> +++ b/uLan/ports/driver/tms570_emac/tms570_netif.c
> @@ -151,6 +151,14 @@ static void tms570_eth_init_netif_fill(struct netif
> *netif);
> static void tms570_eth_init_buffer_descriptors(struct tms570_netif_state
> *nf_state);
> static void tms570_eth_init_set_pinmux();
>
> +static inline void
> +tms570_data_sync_barier(void)
> +{
> +#ifdef __arm__
> + _ARM_Data_synchronization_barrier();
> +#endif
> +}
> +
> /* initializing functions
> **/
>
>
> @@ -685,7 +693,7 @@ tms570_eth_send_raw(struct netif *netif, struct pbuf
> *pbuf)
>if (curr_bd == NULL)
> txch->inactive_tail = curr_bd;
>
> - sys_arch_data_sync_barier();
> + tms570_data_sync_barier();
>
>if (txch->active_tail == NULL) {
> txch->active_head = packet_head;
> @@ -767,7 +775,7 @@ tms570_eth_process_irq_rx(void *arg)
> unsigned int processed_rx_len = 0;
> int corrupt_fl = 0;
>
> -sys_arch_data_sync_barier();
> +tms570_data_sync_barier();
>
> pbuf = curr_bd->pbuf;
> total_rx_len = curr_bd->flags_pktlen & 0x;
> @@ -1086,7 +1094,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
> *nf_state, int single_fl)
>rxch->inactive_head = curr_bd->next;
>
>curr_bd->next = NULL;
> - sys_arch_data_sync_barier();
> + tms570_data_sync_barier();
>
>if (rxch->active_head == NULL) {
> rxch->active_head = curr_head;
> @@ -1094,7 +1102,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
> *nf_state, int single_fl)
> tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
>} else {
> rxch->active_tail->next = curr_head;
> -sys_arch_data_sync_barier();
> +tms570_data_sync_barier();
> if ((rxch->active_tail->flags_pktlen & EMAC_DSC_FLAG_EOQ) != 0)
>tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
> rxch->active_tail = curr_bd;
> diff --git a/uLan/ports/os/rtems/arch/sys_arch.h
> b/uLan/ports/os/rtems/arch/sys_arch.h
> index 6ec578b..eb85e3b 100644
> --- a/uLan/ports/os/rtems/arch/sys_arch.h
> +++ b/uLan/ports/os/rtems/arch/sys_arch.h
> @@ -124,11 +124,6 @@ sys_arch_unprotect(sys_prot_t pval)
> {
>rtems_interrupt_enable(pval);
> }
> -
> -static inline void
> -sys_arch_data_sync_barier(void){
> - _ARM_Data_synchronization_barrier();
> -}
> #else
> sys_prot_t sys_arch_protect();
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[lwip 2/2] Move and rename sys_arch_data_sync_barier()
This function is not present in the lwIP mainline. Move it to the only
user and rename it to tms570__data_sync_barier().
---
uLan/ports/driver/tms570_emac/tms570_netif.c | 16
uLan/ports/os/rtems/arch/sys_arch.h | 5 -
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/uLan/ports/driver/tms570_emac/tms570_netif.c
b/uLan/ports/driver/tms570_emac/tms570_netif.c
index 8d14687..e166869 100644
--- a/uLan/ports/driver/tms570_emac/tms570_netif.c
+++ b/uLan/ports/driver/tms570_emac/tms570_netif.c
@@ -151,6 +151,14 @@ static void tms570_eth_init_netif_fill(struct netif
*netif);
static void tms570_eth_init_buffer_descriptors(struct tms570_netif_state
*nf_state);
static void tms570_eth_init_set_pinmux();
+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+ _ARM_Data_synchronization_barrier();
+#endif
+}
+
/* initializing functions **/
@@ -685,7 +693,7 @@ tms570_eth_send_raw(struct netif *netif, struct pbuf *pbuf)
if (curr_bd == NULL)
txch->inactive_tail = curr_bd;
- sys_arch_data_sync_barier();
+ tms570_data_sync_barier();
if (txch->active_tail == NULL) {
txch->active_head = packet_head;
@@ -767,7 +775,7 @@ tms570_eth_process_irq_rx(void *arg)
unsigned int processed_rx_len = 0;
int corrupt_fl = 0;
-sys_arch_data_sync_barier();
+tms570_data_sync_barier();
pbuf = curr_bd->pbuf;
total_rx_len = curr_bd->flags_pktlen & 0x;
@@ -1086,7 +1094,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
*nf_state, int single_fl)
rxch->inactive_head = curr_bd->next;
curr_bd->next = NULL;
- sys_arch_data_sync_barier();
+ tms570_data_sync_barier();
if (rxch->active_head == NULL) {
rxch->active_head = curr_head;
@@ -1094,7 +1102,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
*nf_state, int single_fl)
tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
} else {
rxch->active_tail->next = curr_head;
-sys_arch_data_sync_barier();
+tms570_data_sync_barier();
if ((rxch->active_tail->flags_pktlen & EMAC_DSC_FLAG_EOQ) != 0)
tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
rxch->active_tail = curr_bd;
diff --git a/uLan/ports/os/rtems/arch/sys_arch.h
b/uLan/ports/os/rtems/arch/sys_arch.h
index 6ec578b..eb85e3b 100644
--- a/uLan/ports/os/rtems/arch/sys_arch.h
+++ b/uLan/ports/os/rtems/arch/sys_arch.h
@@ -124,11 +124,6 @@ sys_arch_unprotect(sys_prot_t pval)
{
rtems_interrupt_enable(pval);
}
-
-static inline void
-sys_arch_data_sync_barier(void){
- _ARM_Data_synchronization_barrier();
-}
#else
sys_prot_t sys_arch_protect();
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
