[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