[U-Boot] [PATCH 1/4] macb: initial support for Cadence GEM

Dave Aldridge fovsoft at gmail.com
Thu Aug 18 17:26:11 CEST 2011


On 18/08/11 15:03, Andreas Bießmann wrote:
> Dear Dave Aldrige,
> 
> Am 18.08.2011 15:32, schrieb Dave Aldridge:
>> The Cadence GEM is based on the MACB Ethernet controller but has a few
>> small changes with regards to register and bitfield placement.  This
>> patch detects the presence of a GEM by reading the module ID register
>> and setting a flag appropriately.
>>
>> This handles the new HW address, USRIO and hash register base register
>> locations in GEM.
>>
>> Signed-off-by: Dave Aldridge <fovsoft at gmail.com>
>> ---
>>  drivers/net/macb.c |   18 +++++++++++-----
>>  drivers/net/macb.h |   55 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 67 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index c63eea9..d52dda0 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -88,6 +88,7 @@ struct macb_dma_desc {
>>  
>>  struct macb_device {
>>  	void			*regs;
>> +        int                     is_gem;
> 
> is it required to have a runtime distinction here?
> I mean is it possible to have a Cadence GEM type and a old style MACB
> type of HW on the same device?
> If not I would prefer a compile time differentiation here to avoid the
> macb_or_gem_(read|write) macros (but lets wait for some comments from
> the custodians)
> 
> regards
> 
> Andreas Bießmann

You would either have a macb or a gem implementation (don't think it makes
sense to have both types of mac in the same SoC). However at the programmers
model level the differences between the two are actually quite small that is
the reason for sorting out the differences at run time rather than compile time.

Thanks for adding to the cc list. I did do a trawl before submitting this patch
set but was unsure who the most appropriate people were.

Cheers

Dave




More information about the U-Boot mailing list