[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551ED345.1000702@gmail.com>
Date: Fri, 03 Apr 2015 10:52:05 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Jonathan Richardson <jonathar@...adcom.com>
CC: Mark Brown <broonie@...nel.org>, Dmitry Torokhov <dtor@...gle.com>,
Anatol Pomazau <anatol@...gle.com>,
Scott Branden <sbranden@...adcom.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-spi@...r.kernel.org,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
devicetree <devicetree@...r.kernel.org>,
Rafal Milecki <zajec5@...il.com>
Subject: Re: [PATCH 3/4] spi: bcm-mspi: Make BCMA optional to support non-BCMA
chips
On 03/04/15 06:38, Andy Shevchenko wrote:
> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
> <jonathar@...adcom.com> wrote:
>> The Broadcom MSPI controller is used on various chips. The driver only
>> supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
>> refactored to make BCMA optional and provides a new config for non BCMA
>> systems.
>
>> struct bcm_mspi {
>> + #ifdef CONFIG_SPI_BCMA_MSPI
>> struct bcma_device *core;
>> - struct spi_master *master;
>> + #endif
>>
>> + void __iomem *base;
>> + struct spi_master *master;
>> size_t read_offset;
>
>> + void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
>> + u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
>> +};
>
> To avoid ugly ifdefs I think better to split driver to core part and
> the actual driver part, at the end you will have something like
> mspi-core.c mspi-53xx.c mspi-whatever.c. Check for example spi-dw*.c
>
Actually, I am really curious whether we need the special BCMA I/O
accessors in the first place, cannot we just access the MSPI core on
BCM53xx chips using regular MMIO? That would probably solve the
"problem" entirely. Rafal, did you try this before?
As for splitting the driver into a "library" driver which is mostly
independent from the bus and a bus-specific wrapper, I think BCMA is
really the only special case here, which is why I suggested earlier to
Jonathan that we might just prefer ifdefing things out instead of
creating a separate layer just for BCMA.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists