Re: [RFC][PATCH] bcmai: introduce AI driver

From: RafaÅ MiÅecki
Date: Wed Apr 06 2011 - 16:40:56 EST


2011/4/6 Arend van Spriel <arend@xxxxxxxxxxxx>:
> On Wed, 06 Apr 2011 20:02:20 +0200, RafaÅ MiÅecki <zajec5@xxxxxxxxx> wrote:
>
>> 2011/4/6 Arend van Spriel <arend@xxxxxxxxxxxx>:
>>>
>>> 1. Term Broadcom AI
>>>
>>
>> I'm still little confused with that, let me read old mails, google a
>> little, etc. I though AMBA AXI is AI on ARM host, give me some time
>> for this.
>
> It is the interconnect or backplane which the cores in the chip are hooked
> up to. See the ARM website for some more info:
> http://www.arm.com/products/system-ip/interconnect/axi/index.php
>
>>
>>> 2. Bus registration
>>>
>>
>> You should drop initialization (to do not perform it twice), but
>> ChipCommon ops are still allowed. See: bcmai_cc_read32,
>> bcmai_cc_write32, bcmai_cc_mask32, bcmai_cc_set32, bcmai_cc_maskset32.
>>
>> You can simply call:
>> bcmai_cc_read32(mydev->bus.drv_cc, CC_REGISTER);
>>
>> There is nothing stopping you from registering one driver for few
>> cores. We do this in b43 for old SSBs with 2 wireless cores. Of course
>> this is not possible to use 2 drivers for 1 core at the same time.
>
> So in theory 2 drivers for 2 separate cores can both call bcmai_cc_read32().
> 2 drivers for 1 core indeed seems a 'little awkward' ;-)

If we want to have two drivers working on two (different) cores
simultaneously, we will have to add trivial mutex to group core
switching with core operation (read/write).

We could also use the fact that [base + (2 * BCMAI_CORE_SIZE)] always
points to PCIe and [base + (3 * BCMAI_CORE_SIZE)] always points to
ChipCommon. For that cores we do not need core switching and so we do
not need mutexes. (Don't take my "always" too seriously, just wanted
to explain it easier, this can be not 100% always).

--
RafaÅ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/