Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi,
On 09/07/2015 11:56 AM, vikas wrote:
> Hi,
>
> On 09/06/2015 08:16 AM, Marek Vasut wrote:
>> On Saturday, September 05, 2015 at 01:45:01 AM, vikas wrote:
>>> Hi,
>>>
>>> On 08/21/2015 02:20 AM, Marek Vasut wrote:
>>>> From: Graham Moore <grmo...@opensource.altera.com>
>>>>
>>>> Add support for the Cadence QSPI controller. This controller is
>>>> present in the Altera SoCFPGA SoCs and this driver has been tested
>>>> on the Cyclone V SoC.
>>>
>>> can we add info about the modes supported/not supported like direct mode,
>>> indirect etc.
>>
>> It's already part of the documentation.
>
> To be clear, add info for modes supported in the driver. e.g. Direct mode is
> not supported in the driver.
> Lets add this info to help users.
>
>>
>>>> Signed-off-by: Graham Moore <grmo...@opensource.altera.com>
>>>> Signed-off-by: Marek Vasut <ma...@denx.de>
>>>> Cc: Alan Tull <at...@opensource.altera.com>
>>>> Cc: Brian Norris <computersforpe...@gmail.com>
>>>> Cc: David Woodhouse <dw...@infradead.org>
>>>> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
>>>> Cc: Graham Moore <grmo...@opensource.altera.com>
>>>> Cc: Vikas MANOCHA <vikas.mano...@st.com>
>>>> Cc: Yves Vandervennet <yvand...@opensource.altera.com>
>>>> Cc: devicetree@vger.kernel.org
>>>> ---
>>
>> [...]
>>
>>>> +#define CQSPI_REG_CMDADDRESS 0x94
>>>> +#define CQSPI_REG_CMDREADDATALOWER 0xA0
>>>> +#define CQSPI_REG_CMDREADDATAUPPER 0xA4
>>>> +#define CQSPI_REG_CMDWRITEDATALOWER0xA8
>>>> +#define CQSPI_REG_CMDWRITEDATAUPPER0xAC
>>>> +
[...]
>>>> +
>>>> + /* Clear all interrupts. */
>>>> + writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS);
>>>> +
>>>> + writel(CQSPI_IRQ_MASK_RD, reg_base + CQSPI_REG_IRQMASK);
>>>
>>> I think there is no need for separate masks for read & write. Use one mask
>>> & configure it once in the init rather than configuring each time for
>>> every read/write. Then in the ISR, take action as per the interrupt
>>> source: read/write/error condition etc.
>>
>> Setting up the specific IRQ mask prevents spurious interrupts during the
>> particular IO operation, so this solution looks more precise to me.
>
> spurious interrupt ? like ?
>
> Configuring interrupt at one time for read/write (preferably in init) is
> better software design
> then breaking it in for every read/write.
just to clarify "preferably in init" not always but yes in this case.
Cheers,
Vikas
>
>>
>>>> +
>>>> + reinit_completion(>transfer_complete);
>>>> + writel(CQSPI_REG_INDIRECTRD_START_MASK,
>>>> + reg_base + CQSPI_REG_INDIRECTRD);
>>>> +
>>>> + while (remaining > 0) {
>>>> + ret =
[...]
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi,
On 09/06/2015 08:16 AM, Marek Vasut wrote:
> On Saturday, September 05, 2015 at 01:45:01 AM, vikas wrote:
>> Hi,
>>
>> On 08/21/2015 02:20 AM, Marek Vasut wrote:
>>> From: Graham Moore <grmo...@opensource.altera.com>
>>>
>>> Add support for the Cadence QSPI controller. This controller is
>>> present in the Altera SoCFPGA SoCs and this driver has been tested
>>> on the Cyclone V SoC.
>>
>> can we add info about the modes supported/not supported like direct mode,
>> indirect etc.
>
> It's already part of the documentation.
To be clear, add info for modes supported in the driver. e.g. Direct mode is
not supported in the driver.
Lets add this info to help users.
>
>>> Signed-off-by: Graham Moore <grmo...@opensource.altera.com>
>>> Signed-off-by: Marek Vasut <ma...@denx.de>
>>> Cc: Alan Tull <at...@opensource.altera.com>
>>> Cc: Brian Norris <computersforpe...@gmail.com>
>>> Cc: David Woodhouse <dw...@infradead.org>
>>> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
>>> Cc: Graham Moore <grmo...@opensource.altera.com>
>>> Cc: Vikas MANOCHA <vikas.mano...@st.com>
>>> Cc: Yves Vandervennet <yvand...@opensource.altera.com>
>>> Cc: devicetree@vger.kernel.org
>>> ---
>
> [...]
>
>>> +#define CQSPI_REG_CMDADDRESS 0x94
>>> +#define CQSPI_REG_CMDREADDATALOWER 0xA0
>>> +#define CQSPI_REG_CMDREADDATAUPPER 0xA4
>>> +#define CQSPI_REG_CMDWRITEDATALOWER0xA8
>>> +#define CQSPI_REG_CMDWRITEDATAUPPER0xAC
>>> +
>>> +/* Interrupt status bits */
>>> +#define CQSPI_REG_IRQ_MODE_ERR BIT(0)
>>> +#define CQSPI_REG_IRQ_UNDERFLOWBIT(1)
>>> +#define CQSPI_REG_IRQ_IND_COMP BIT(2)
>>> +#define CQSPI_REG_IRQ_IND_RD_REJECTBIT(3)
>>> +#define CQSPI_REG_IRQ_WR_PROTECTED_ERR BIT(4)
>>> +#define CQSPI_REG_IRQ_ILLEGAL_AHB_ERR BIT(5)
>>
>> remove unused MACROs.
>
> You mean you prefer to have incomplete definition of bits in the register
> instead of a complete one ? I cannot agree to this, sorry.
>
>>> +#define CQSPI_REG_IRQ_WATERMARKBIT(6)
>>> +#define CQSPI_REG_IRQ_IND_RD_OVERFLOW BIT(12)
>>
>> Correct this bit name to ..IND_RD_SRAM_FULL.
>
> Good catch.
>
> [...]
>
>>> +static int cqspi_wait_idle(struct cqspi_st *cqspi)
>>> +{
>>> + const unsigned int poll_idle_retry = 3;
>>> + unsigned int count = 0;
>>> + unsigned long timeout;
>>> +
>>> + timeout = jiffies + msecs_to_jiffies(CQSPI_TIMEOUT_MS);
>>> + while (1) {
>>> + /*
>>> +* Read few times in succession to ensure the controller
>>> +* is indeed idle, that is, the bit does not transition
>>> +* low again.
>>> +*/
>>> + if (cqspi_is_idle(cqspi))
>>> + count++;
>>> + else
>>> + count = 0;
>>> +
>>> + if (count >= poll_idle_retry)
>>> + return 0;
>>
>> why do we need to check it 3 times ?
>
> Please see the comment above.
don't use the comments to explain what code is doing. Add info why it is being
done & how this solution fixes it.
The point is if is some soc bug, it should be handled differently.
>
>>> +
>>> + if (time_after(jiffies, timeout)) {
>>> + /* Timeout, in busy mode. */
>>> + dev_err(>pdev->dev,
>>> + "QSPI is still busy after %dms
>>> timeout.\n", + CQSPI_TIMEOUT_MS);
>>> + return -ETIMEDOUT;
>>> + }
>>> +
>>> + cpu_relax();
>>> + }
>>> +}
>>> +
>>
>> [...]
>>
>>> +
>>> +static int cqspi_indirect_read_execute(struct spi_nor *nor,
>>> + u8 *rxbuf, const unsigned n_rx)
>>> +{
>>> + struct cqspi_flash_pdata *f_pdata = nor->priv;
>>> + struct cqspi_st *cqspi = f_pdata->cqspi;
>>> + void __iomem *reg_base = cqspi->iobase;
>>> + void __iomem *ahb_base = cqspi-&
Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi, On 08/21/2015 02:20 AM, Marek Vasut wrote: > From: Graham Moore <grmo...@opensource.altera.com> > > Add support for the Cadence QSPI controller. This controller is > present in the Altera SoCFPGA SoCs and this driver has been tested > on the Cyclone V SoC. can we add info about the modes supported/not supported like direct mode, indirect etc. > > Signed-off-by: Graham Moore <grmo...@opensource.altera.com> > Signed-off-by: Marek Vasut <ma...@denx.de> > Cc: Alan Tull <at...@opensource.altera.com> > Cc: Brian Norris <computersforpe...@gmail.com> > Cc: David Woodhouse <dw...@infradead.org> > Cc: Dinh Nguyen <dingu...@opensource.altera.com> > Cc: Graham Moore <grmo...@opensource.altera.com> > Cc: Vikas MANOCHA <vikas.mano...@st.com> > Cc: Yves Vandervennet <yvand...@opensource.altera.com> > Cc: devicetree@vger.kernel.org > --- > drivers/mtd/spi-nor/Kconfig | 11 + > drivers/mtd/spi-nor/Makefile |1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 1260 > + > 3 files changed, 1272 insertions(+) > create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c > > V2: use NULL instead of modalias in spi_nor_scan call > V3: Use existing property is-decoded-cs instead of creating duplicate. > V4: Support Micron quad mode by snooping command stream for EVCR command > and subsequently configuring Cadence controller for quad mode. > V5: Clean up sparse and smatch complaints. Remove snooping of Micron > quad mode. Add comment on XIP mode bit and dummy clock cycles. Set > up SRAM partition at 1:1 during init. > V6: Remove dts patch that was included by mistake. Incorporate Vikas's > comments regarding fifo width, SRAM partition setting, and trigger > address. Trigger address was added as an unsigned int, as it is not > an IO resource per se, and does not need to be mapped. Also add > Marek Vasut's workaround for picking up OF properties on subnodes. > V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*() > macros and replace them with functions. Get rid of unused variables. > - Implement support for nor->set_protocol() to handle Quad-command, > this patch now depends on the following patch: > mtd: spi-nor: notify (Q)SPI controller about protocol change > - Replace that cqspi_fifo_read() disaster with plain old readsl() > and cqspi_fifo_write() tentacle horror with pretty writesl(). > - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken. > - Get rid of cqspi_find_chipselect() mess, instead just place the > struct cqspi_st and chipselect number into struct cqspi_flash_pdata > and set nor->priv to the struct cqspi_flash_pdata of that particular > chip. > - Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP(). > - Make variables const where applicable. > V8: - Implement a function to wait for bit being set/unset for a given > period of time and use it to replace the ad-hoc bits of code. > - Configure the write underflow watermark to be 1/8 if FIFO size. > - Extract out the SPI NOR flash probing code into separate function > to clearly mark what will soon be considered a boilerplate code. > - Repair the handling of mode bits, which caused instability in V7. > - Clean up the interrupt handling > - Fix Kconfig help text and make the patch depend on OF and COMPILE_TEST. > > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 89bf4c1..ed253a2 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI > Flash. Enable this option if you have a device with a SPIFI > controller and want to access the Flash as a mtd device. > > +config SPI_CADENCE_QUADSPI > + tristate "Cadence Quad SPI controller" > + depends on OF && COMPILE_TEST > + help > + Enable support for the Cadence Quad SPI Flash controller. > + > + Cadence QSPI is a specialized controller for connecting an SPI > + Flash over 1/2/4-bit wide bus. Enable this option if you have a > + device with a Cadence QSPI controller and want to access the > + Flash as an MTD device. > + > endif # MTD_SPI_NOR > diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile > index e5e..446c6b9 100644 > --- a/drivers/mtd/spi-nor/Makefile > +++ b/drivers/mtd/spi-nor/Makefile > @@ -1,3 +1,4 @@ > obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o > +obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o > obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o
Re: [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi,
On 08/21/2015 02:20 AM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 56
++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
new file mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
still hooked up with Controller data area, it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
again, is it optional ? can the driver be used without these properties ?
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
again, add info what the decoder is for ?
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional
+custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+ mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+ de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+ transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+ and first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
flag value ?
Cheers,
Vikas
+ cdns,fifo-depth = 128;
+ cdns,fifo-width = 4;
+ cdns,trigger-address = 0x;
+
+ flash0: n25q00@0 {
+ ...
+ cdns,read-delay = 4;
+ cdns,tshsl-ns = 50;
+ cdns,tsd2d-ns = 50;
+ cdns,tchsh-ns = 4;
+ cdns,tslch-ns = 4;
+ };
+ };
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi,
On 08/27/2015 11:12 AM, Marek Vasut wrote:
On Thursday, August 27, 2015 at 07:44:34 PM, vikas wrote:
Hi,
On 08/21/2015 02:20 AM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 56
++ 1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt new file
mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
still hooked up with Controller data area, it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.
I have to disagree, I will call it whatever it is called in the datasheet
and it is called controller data area.
It is preferable to use terminology which readers understand that is the
purpose
of explaining it here otherwise we could have just pasted the doc link.
I have to stop here for this point.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
again, is it optional ? can the driver be used without these properties ?
Why wouldn't it be possible to use the driver with no SPI NOR attached to
it? It's a cornercase, but still a valid one.
that's not right, this controller is only spi flash controller.
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
again, add info what the decoder is for ?
This is something Graham has to clarify. Based on the code (I'm sure you did
check the code), it's a 4:16 demuxer.
Please clarify if possible add the info for others benefit. This part is not
common in other spi/nor controllers.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional +custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+ mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+ de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+ transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+ and first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
flag value ?
Sorry, I don't quite understand the question. If you mean why there is no
value, it's because this is a boolean OF node, which just does't need to
have a value ; it's either present or not.
you are right, thanks.
Cheers,
Vikas
Best regards,
Marek Vasut
.
--
To unsubscribe from this list: send the line
Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi, On 08/25/2015 11:19 PM, Marek Vasut wrote: On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote: Hi, On 08/21/2015 02:20 AM, Marek Vasut wrote: From: Graham Moore grmo...@opensource.altera.com Add support for the Cadence QSPI controller. This controller is present in the Altera SoCFPGA SoCs and this driver has been tested on the Cyclone V SoC. Signed-off-by: Graham Moore grmo...@opensource.altera.com Signed-off-by: Marek Vasut ma...@denx.de Cc: Alan Tull at...@opensource.altera.com Cc: Brian Norris computersforpe...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Dinh Nguyen dingu...@opensource.altera.com Cc: Graham Moore grmo...@opensource.altera.com Cc: Vikas MANOCHA vikas.mano...@st.com Cc: Yves Vandervennet yvand...@opensource.altera.com Cc: devicetree@vger.kernel.org --- drivers/mtd/spi-nor/Kconfig | 11 + drivers/mtd/spi-nor/Makefile |1 + drivers/mtd/spi-nor/cadence-quadspi.c | 1260 + 3 files changed, 1272 insertions(+) create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c V2: use NULL instead of modalias in spi_nor_scan call V3: Use existing property is-decoded-cs instead of creating duplicate. V4: Support Micron quad mode by snooping command stream for EVCR command and subsequently configuring Cadence controller for quad mode. V5: Clean up sparse and smatch complaints. Remove snooping of Micron quad mode. Add comment on XIP mode bit and dummy clock cycles. Set up SRAM partition at 1:1 during init. V6: Remove dts patch that was included by mistake. Incorporate Vikas's comments regarding fifo width, SRAM partition setting, and trigger address. Trigger address was added as an unsigned int, as it is not an IO resource per se, and does not need to be mapped. Also add Marek Vasut's workaround for picking up OF properties on subnodes. V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*() macros and replace them with functions. Get rid of unused variables. - Implement support for nor-set_protocol() to handle Quad-command, this patch now depends on the following patch: mtd: spi-nor: notify (Q)SPI controller about protocol change - Replace that cqspi_fifo_read() disaster with plain old readsl() and cqspi_fifo_write() tentacle horror with pretty writesl(). - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken. - Get rid of cqspi_find_chipselect() mess, instead just place the struct cqspi_st and chipselect number into struct cqspi_flash_pdata and set nor-priv to the struct cqspi_flash_pdata of that particular chip. - Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP(). - Make variables const where applicable. V8: - Implement a function to wait for bit being set/unset for a given period of time and use it to replace the ad-hoc bits of code. - Configure the write underflow watermark to be 1/8 if FIFO size. - Extract out the SPI NOR flash probing code into separate function to clearly mark what will soon be considered a boilerplate code. - Repair the handling of mode bits, which caused instability in V7. - Clean up the interrupt handling - Fix Kconfig help text and make the patch depend on OF and COMPILE_TEST. diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 89bf4c1..ed253a2 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_CADENCE_QUADSPI + tristate Cadence Quad SPI controller + depends on OF COMPILE_TEST + help + Enable support for the Cadence Quad SPI Flash controller. + + Cadence QSPI is a specialized controller for connecting an SPI + Flash over 1/2/4-bit wide bus. Enable this option if you have a + device with a Cadence QSPI controller and want to access the + Flash as an MTD device. + the patch failed to apply, please rebase it to master. it's based on -next, I'm sure you can fix trivial conflicts yourself if you need to apply it elsewhere. Do you have any other review comments ? Always rebase the patch on master. I will be reviewing the patchset this week but on a quick look it seems many review comments of v7 are not there. Cheers, Vikas . -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi, On 08/26/2015 11:06 AM, Brian Norris wrote: On Wed, Aug 26, 2015 at 08:47:37AM -0700, vikas wrote: On 08/25/2015 11:19 PM, Marek Vasut wrote: On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote: the patch failed to apply, please rebase it to master. it's based on -next, I'm sure you can fix trivial conflicts yourself if you need to apply it elsewhere. Do you have any other review comments ? Always rebase the patch on master. Development works against -next, not Linus' master: https://lwn.net/Articles/289013/ This is also noted here: https://www.kernel.org/doc/man-pages/linux-next.html Technically, you should work off of the respective subsystem tree (see entries in MAINTAINERS). For MTD, this is also documented here: http://linux-mtd.infradead.org/source.html In the end, most MTD patches get applied to l2-mtd.git, but l2-mtd.git and linux-next.git should provide pretty similar MTD patching experiences, as the former is included in the latter. Thanks Brian for these useful links, appreciate it. Rgds, Vikas Regards, Brian . -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi, On 08/21/2015 02:20 AM, Marek Vasut wrote: From: Graham Moore grmo...@opensource.altera.com Add support for the Cadence QSPI controller. This controller is present in the Altera SoCFPGA SoCs and this driver has been tested on the Cyclone V SoC. Signed-off-by: Graham Moore grmo...@opensource.altera.com Signed-off-by: Marek Vasut ma...@denx.de Cc: Alan Tull at...@opensource.altera.com Cc: Brian Norris computersforpe...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Dinh Nguyen dingu...@opensource.altera.com Cc: Graham Moore grmo...@opensource.altera.com Cc: Vikas MANOCHA vikas.mano...@st.com Cc: Yves Vandervennet yvand...@opensource.altera.com Cc: devicetree@vger.kernel.org --- drivers/mtd/spi-nor/Kconfig | 11 + drivers/mtd/spi-nor/Makefile |1 + drivers/mtd/spi-nor/cadence-quadspi.c | 1260 + 3 files changed, 1272 insertions(+) create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c V2: use NULL instead of modalias in spi_nor_scan call V3: Use existing property is-decoded-cs instead of creating duplicate. V4: Support Micron quad mode by snooping command stream for EVCR command and subsequently configuring Cadence controller for quad mode. V5: Clean up sparse and smatch complaints. Remove snooping of Micron quad mode. Add comment on XIP mode bit and dummy clock cycles. Set up SRAM partition at 1:1 during init. V6: Remove dts patch that was included by mistake. Incorporate Vikas's comments regarding fifo width, SRAM partition setting, and trigger address. Trigger address was added as an unsigned int, as it is not an IO resource per se, and does not need to be mapped. Also add Marek Vasut's workaround for picking up OF properties on subnodes. V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*() macros and replace them with functions. Get rid of unused variables. - Implement support for nor-set_protocol() to handle Quad-command, this patch now depends on the following patch: mtd: spi-nor: notify (Q)SPI controller about protocol change - Replace that cqspi_fifo_read() disaster with plain old readsl() and cqspi_fifo_write() tentacle horror with pretty writesl(). - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken. - Get rid of cqspi_find_chipselect() mess, instead just place the struct cqspi_st and chipselect number into struct cqspi_flash_pdata and set nor-priv to the struct cqspi_flash_pdata of that particular chip. - Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP(). - Make variables const where applicable. V8: - Implement a function to wait for bit being set/unset for a given period of time and use it to replace the ad-hoc bits of code. - Configure the write underflow watermark to be 1/8 if FIFO size. - Extract out the SPI NOR flash probing code into separate function to clearly mark what will soon be considered a boilerplate code. - Repair the handling of mode bits, which caused instability in V7. - Clean up the interrupt handling - Fix Kconfig help text and make the patch depend on OF and COMPILE_TEST. diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 89bf4c1..ed253a2 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_CADENCE_QUADSPI + tristate Cadence Quad SPI controller + depends on OF COMPILE_TEST + help + Enable support for the Cadence Quad SPI Flash controller. + + Cadence QSPI is a specialized controller for connecting an SPI + Flash over 1/2/4-bit wide bus. Enable this option if you have a + device with a Cadence QSPI controller and want to access the + Flash as an MTD device. + the patch failed to apply, please rebase it to master. Cheers, Vikas endif # MTD_SPI_NOR diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index e5e..446c6b9 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o +obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c new file mode 100644 index 000..8e024b8 --- /dev/null +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -0,0 +1,1260 @@ +/* + * Driver for Cadence QSPI Controller + * + * Copyright Altera Corporation (C) 2012-2014. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi, On Aug 20, 2015, at 10:20 PM, Marek Vasut ma...@denx.de wrote: On Thursday, August 20, 2015 at 06:06:49 PM, vikas wrote: Hi, Hi! [...] It's the location of the SRAM fifo. Also direct mode location I think, if that were ever used. Hmm...It is the base address of NOR flash. SRAM is not memory mapped. Huh ? I am inclined to trust Graham more -- I have seen memory mapped SRAM, but I have yet to see memory mapped SPI NOR. Well, SPI NOR flash in SOCs normally is memory mapped. I'm afraid you have some very disturbed views of how SPI NORs are operated most of the time. Just wondering what should I say, hoping you will sit back and try to correct your views. No, SPI NOR is most often hanging off of some sort of SPI controller just like any other SPI device. It is definitelly not common for a SPI NOR to be memory mapped. Definitely ? And what made you think like this ? Do you even know the spi peripheral you are sending patch for has memory mapped nor flash ? To give some mainline examples, all Spear family SOCs (spear300, 320, 1310, 1340). That's an exception, not a rule :) And there are many such exceptions starting from this cadence qspi :-) Also, the driver code clearly uses that area in a way one would use a memory mapped SRAM with FIFO on the other side. I think the above description is pretty much OK. that is the purpose of making NOR flash memory mapped. I'm not sure if you agree with me or not anymore. I am pretty sure the discussion went quite far for such a trivial matter though. I definitely disagree with you. I stop here now. Cheers, Vikas The size is determined by a configuration parameter during system design. On Altera Cyclone5 the size is really big compared to SRAM fifo. I don't know why, maybe some hw engineer thought it would be better to have a large size in case direct mode was used. my comment is about second parameter of property reg which is NOR flash address, so above explanation does not make sense for it. Also in direct mode, sram does not come into play. This is absolutelly not a SPI NOR address. Then i can only suggest to check out the controller literature. Think like this : what is the purpose of SRAM in all this flash access business, It can work without SRAM also, the only purpose of sram ( in fact indirect mode) is to access data from flash memory without AHB access to trigger it. Once the data is available in SRAM(in case of read), AHB Master can access it with low letency. Same is true for writes. SRAM is integral internal part of state machine in case of indirect mode, there is no need for it to memory mapped. If the controller does not support indirect mode, there is no need of sram in the system. Hope it is little bit more clear. It is, I understand what you're trying to convey now. Yes, this register area can be used in certain modes of the controller in such a way that it presents a window of the SPI NOR, which can be directly accessed. This register area can also be used as a FIFO, which is the way we used this area in the driver . We read/write the first four bytes when communicating with the flash. So I don't really see a problem with calling the second register a Controller data area, that's what the IP documentation also calls it. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi,
On Aug 20, 2015, at 10:20 PM, Marek Vasut ma...@denx.de wrote:
On Tuesday, August 18, 2015 at 04:34:53 AM, vikas wrote:
Hi Marek,
Hi,
[...]
+#define CQSPI_POLL_IDLE_RETRY 3
+
+#define CQSPI_REG_SRAM_RESV_WORDS 2
+#define CQSPI_REG_SRAM_PARTITION_WR1
remove unused macros.
+#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
the macro is used only for write sram watermark, something like
...WR_THRESH_BYTES would be better. Infact instead of magic number like
50, it should be based on sram_depth similar to read watermark
configuration.
I suppose if the fifo falls below 1/8, that might be a sensible time to
trigger an underflow interrupt.
+
+/* Instruction type */
+#define CQSPI_INST_TYPE_SINGLE 0
+#define CQSPI_INST_TYPE_DUAL 1
+#define CQSPI_INST_TYPE_QUAD 2
+
+#define CQSPI_DUMMY_CLKS_MAX 31
+
+#define CQSPI_STIG_DATA_LEN_MAX8
+
+/* Register map */
+#define CQSPI_REG_CONFIG 0x00
+#define CQSPI_REG_CONFIG_ENABLE_MASK BIT(0)
+#define CQSPI_REG_CONFIG_DECODE_MASK BIT(9)
+#define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
+#define CQSPI_REG_CONFIG_DMA_MASK BIT(15)
+#define CQSPI_REG_CONFIG_BAUD_LSB 19
+#define CQSPI_REG_CONFIG_IDLE_LSB 31
To be consistent, it would be good to use BIT(nr) for all bit positions.
You don't use BIT() macro for bitfields and the above are bitfields.
Thus, this is not applicable.
+#define CQSPI_REG_CONFIG_CHIPSELECT_MASK 0xF
+#define CQSPI_REG_CONFIG_BAUD_MASK 0xF
[...]
+#define CQSPI_REG_CMDADDRESS 0x94
+#define CQSPI_REG_CMDREADDATALOWER 0xA0
+#define CQSPI_REG_CMDREADDATAUPPER 0xA4
+#define CQSPI_REG_CMDWRITEDATALOWER0xA8
+#define CQSPI_REG_CMDWRITEDATAUPPER0xAC
I am not sure if there is any recommended way but instread of register
macros with offset, isn't it better to use something like struct cdns_qspi
{
u32 config,
u32 rd_instn,
};
then configuring the pointer to this structure to the peripheral's (qspi
controller in this case) base address.
U-Boot is slowly abolishing this practice as it turned out to be a horrible
mistake, which is annoying to deal with . No, I will not do this.
It helps in debugging also as you can have all registers under one
structure, easy/clean access of register like cdsn_qspi_ptr-config
instead of adding offset for every access also clean picture of all
peripheral registers.
Once you have three similar controllers with only one register mapped
elsewhere, you'd need three such structures. This approach does look
nice at first, but certainly does not scale.
+
+/* Interrupt status bits */
+#define CQSPI_REG_IRQ_MODE_ERR BIT(0)
+#define CQSPI_REG_IRQ_UNDERFLOW BIT(1)
+#define CQSPI_REG_IRQ_IND_COMP BIT(2)
+#define CQSPI_REG_IRQ_IND_RD_REJECTBIT(3)
+#define CQSPI_REG_IRQ_WR_PROTECTED_ERR BIT(4)
+#define CQSPI_REG_IRQ_ILLEGAL_AHB_ERR BIT(5)
+#define CQSPI_REG_IRQ_WATERMARKBIT(6)
+#define CQSPI_REG_IRQ_IND_RD_OVERFLOW BIT(12)
[...]
+
+static unsigned int cqspi_check_timeout(const unsigned long timeout)
+{
+ return time_before(jiffies, timeout);
+}
try to replace using blocking jiffies check using kernel timeout function.
What function do you refer to ?
[...]
+static int cqspi_indirect_read_execute(struct spi_nor *nor,
+ u8 *rxbuf, const unsigned n_rx)
+{
+ struct cqspi_flash_pdata *f_pdata = nor-priv;
+ struct cqspi_st *cqspi = f_pdata-cqspi;
+ void __iomem *reg_base = cqspi-iobase;
+ void __iomem *ahb_base = cqspi-ahb_base;
+ unsigned int remaining = n_rx;
+ unsigned int reg = 0;
+ unsigned int bytes_to_read = 0;
+ unsigned int timeout;
+ int ret = 0;
+
+ writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
+
+ /* Clear all interrupts. */
+ writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS);
+
+ cqspi-irq_mask = CQSPI_IRQ_MASK_RD;
+ writel(cqspi-irq_mask, reg_base + CQSPI_REG_IRQMASK);
here interrupt mask is being configured for every read, better would be to
move it in init.
It certainly would not, it is configured differently for READ and WRITE.
And what is blocking to configure read and write mask together at one time in
the register ?
+
+ reinit_completion(cqspi-transfer_complete);
+ writel(CQSPI_REG_INDIRECTRD_START_MASK,
+ reg_base + CQSPI_REG_INDIRECTRD);
+
+ while (remaining 0) {
+ ret =
[...]
+static void
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi, On 08/19/2015 09:03 PM, Marek Vasut wrote: On Tuesday, August 18, 2015 at 10:18:33 PM, vikas wrote: Hi, On 08/18/2015 12:03 PM, Graham Moore wrote: Hi all, On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: [...] +Required properties: +- compatible : Should be cdns,qspi-nor. +- reg : Contains two entries, each of which is a tuple consisting of a +physical address and length. The first entry is the address and +length of the controller register set. The second entry is the +address and length of the QSPI Controller data area. Controller data area, i think it means mapped NOR Flash address ? Probably ; Graham ? If yes, it would be more clear with Physical base address size of NOR Flash. This is the Direct mode thing, correct ? We don't support this, so I think we should drop this bit altogether and keep only one single address in this field. No it's not. It's the location of the SRAM fifo. Also direct mode location I think, if that were ever used. Hmm...It is the base address of NOR flash. SRAM is not memory mapped. Huh ? I am inclined to trust Graham more -- I have seen memory mapped SRAM, but I have yet to see memory mapped SPI NOR. Well, SPI NOR flash in SOCs normally is memory mapped. To give some mainline examples, all Spear family SOCs (spear300, 320, 1310, 1340). Also, the driver code clearly uses that area in a way one would use a memory mapped SRAM with FIFO on the other side. I think the above description is pretty much OK. that is the purpose of making NOR flash memory mapped. The size is determined by a configuration parameter during system design. On Altera Cyclone5 the size is really big compared to SRAM fifo. I don't know why, maybe some hw engineer thought it would be better to have a large size in case direct mode was used. my comment is about second parameter of property reg which is NOR flash address, so above explanation does not make sense for it. Also in direct mode, sram does not come into play. This is absolutelly not a SPI NOR address. Then i can only suggest to check out the controller literature. Think like this : what is the purpose of SRAM in all this flash access business, It can work without SRAM also, the only purpose of sram ( in fact indirect mode) is to access data from flash memory without AHB access to trigger it. Once the data is available in SRAM(in case of read), AHB Master can access it with low letency. Same is true for writes. SRAM is integral internal part of state machine in case of indirect mode, there is no need for it to memory mapped. If the controller does not support indirect mode, there is no need of sram in the system. Hope it is little bit more clear. Cheers, Vikas Best regards, Marek Vasut . -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi, On 08/18/2015 12:03 PM, Graham Moore wrote: Hi all, On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: [...] +Required properties: +- compatible : Should be cdns,qspi-nor. +- reg : Contains two entries, each of which is a tuple consisting of a +physical address and length. The first entry is the address and +length of the controller register set. The second entry is the +address and length of the QSPI Controller data area. Controller data area, i think it means mapped NOR Flash address ? Probably ; Graham ? If yes, it would be more clear with Physical base address size of NOR Flash. This is the Direct mode thing, correct ? We don't support this, so I think we should drop this bit altogether and keep only one single address in this field. No it's not. It's the location of the SRAM fifo. Also direct mode location I think, if that were ever used. Hmm...It is the base address of NOR flash. SRAM is not memory mapped. The size is determined by a configuration parameter during system design. On Altera Cyclone5 the size is really big compared to SRAM fifo. I don't know why, maybe some hw engineer thought it would be better to have a large size in case direct mode was used. my comment is about second parameter of property reg which is NOR flash address, so above explanation does not make sense for it. Also in direct mode, sram does not come into play. Rgds, Vikas BR, Graham . -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi, On 08/18/2015 12:17 PM, Graham Moore wrote: Hi Vikas, On 08/17/2015 09:34 PM, vikas wrote: Hi Marek, [...] + +/* Operation timeout value */ +#define CQSPI_TIMEOUT_MS 500 +#define CQSPI_READ_TIMEOUT_MS 10 please add some comment about the timeouts value selection. I wish I could comment, but I don't know the origin of these values. The 500 ms value is probably just a very long time. In my opinion we should have some logical value based on some worst timing like read/write sector. I let you decide on this point. [...] + + cqspi-irq_mask = CQSPI_IRQ_MASK_RD; + writel(cqspi-irq_mask, reg_base + CQSPI_REG_IRQMASK); here interrupt mask is being configured for every read, better would be to move it in init. [...] + + cqspi-irq_mask = CQSPI_IRQ_MASK_WR; + writel(cqspi-irq_mask, reg_base + CQSPI_REG_IRQMASK); same like read, it should be moved to init. It uses different masks for read and write Yeah i saw it but why not to OR these values configure for once in init. After that in ISR, check for the interrupt source take action accordingly. I think other drivers also use it this way. Rgds, Vikas [...] BR, Graham . -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi Marek, On 08/13/2015 08:28 PM, Marek Vasut wrote: From: Graham Moore grmo...@opensource.altera.com Add support for the Cadence QSPI controller. This controller is present in the Altera SoCFPGA SoCs and this driver has been tested on the Cyclone V SoC. Signed-off-by: Graham Moore grmo...@opensource.altera.com Signed-off-by: Marek Vasut ma...@denx.de Cc: Alan Tull at...@opensource.altera.com Cc: Brian Norris computersforpe...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Dinh Nguyen dingu...@opensource.altera.com Cc: Graham Moore grmo...@opensource.altera.com Cc: Vikas MANOCHA vikas.mano...@st.com Cc: Yves Vandervennet yvand...@opensource.altera.com Cc: devicetree@vger.kernel.org --- drivers/mtd/spi-nor/Kconfig |6 + drivers/mtd/spi-nor/Makefile |1 + drivers/mtd/spi-nor/cadence-quadspi.c | 1266 + 3 files changed, 1273 insertions(+) create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c V2: use NULL instead of modalias in spi_nor_scan call V3: Use existing property is-decoded-cs instead of creating duplicate. V4: Support Micron quad mode by snooping command stream for EVCR command and subsequently configuring Cadence controller for quad mode. V5: Clean up sparse and smatch complaints. Remove snooping of Micron quad mode. Add comment on XIP mode bit and dummy clock cycles. Set up SRAM partition at 1:1 during init. V6: Remove dts patch that was included by mistake. Incorporate Vikas's comments regarding fifo width, SRAM partition setting, and trigger address. Trigger address was added as an unsigned int, as it is not an IO resource per se, and does not need to be mapped. Also add Marek Vasut's workaround for picking up OF properties on subnodes. V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*() macros and replace them with functions. Get rid of unused variables. - Implement support for nor-set_protocol() to handle Quad-command, this patch now depends on the following patch: mtd: spi-nor: notify (Q)SPI controller about protocol change - Replace that cqspi_fifo_read() disaster with plain old readsl() and cqspi_fifo_write() tentacle horror with pretty writesl(). - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken. - Get rid of cqspi_find_chipselect() mess, instead just place the struct cqspi_st and chipselect number into struct cqspi_flash_pdata and set nor-priv to the struct cqspi_flash_pdata of that particular chip. - Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP(). - Make variables const where applicable. diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 64a4f0e..9485481 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI This enables support for the Quad SPI controller in master mode. We only connect the NOR to this controller now. +config SPI_CADENCE_QUADSPI + tristate Cadence Quad SPI controller + depends on ARCH_SOCFPGA Remove the dependency on SOCFPGA. + help + This enables support for the Cadence Quad SPI controller and NOR flash. + endif # MTD_SPI_NOR diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index 6a7ce14..372628c 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o +obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c new file mode 100644 index 000..f59e286 --- /dev/null +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -0,0 +1,1266 @@ +/* + * Driver for Cadence QSPI Controller + * + * Copyright Altera Corporation (C) 2012-2014. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see http://www.gnu.org/licenses/. + */ +#include linux/clk.h +#include linux/completion.h +#include linux/delay.h +#include linux/err.h +#include linux/errno.h +#include linux/interrupt.h +#include linux/io.h +#include linux/jiffies.h +#include linux/kernel.h +#include linux/module.h +#include linux/mtd/mtd.h +#include linux/mtd/partitions.h +#include linux/mtd/spi
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi Marek,
On 08/13/2015 08:28 PM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence_quadspi.txt| 50
++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
new file mode 100644
index 000..ebaf1fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
@@ -0,0 +1,50 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
Controller data area, i think it means mapped NOR Flash address ?
If yes, it would be more clear with Physical base address size of NOR Flash.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
It actually is sram-depth, better would be sram-depth to avoid confusion.
+- cdns,fifo-width: Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
we might make trigger-address also part of property reg.
+
+Optional properties:
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
Not clear about the usage of decoder, if it does not make sense we might remove
it from driver.
+
+Optional subnodes:
I think flash subnode is mandatory.
Rgds,
Vikas
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional
+custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master mode
chip select outputs are de-asserted between transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
transaction and deasserting the device chip select (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low and
first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
+ cdns,fifo-depth = 128;
+ cdns,fifo-width = 4;
+ cdns,trigger-address = 0x;
+
+ flash0: n25q00@0 {
+ ...
+ cdns,read-delay = 4;
+ cdns,tshsl-ns = 50;
+ cdns,tsd2d-ns = 50;
+ cdns,tchsh-ns = 4;
+ cdns,tslch-ns = 4;
+ };
+ };
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Ho Marek, On Aug 17, 2015, at 9:48 PM, Marek Vasut ma...@denx.de wrote: On Tuesday, August 18, 2015 at 04:35:55 AM, vikas wrote: Hi Marek, On 08/13/2015 08:28 PM, Marek Vasut wrote: From: Graham Moore grmo...@opensource.altera.com Add binding document for the Cadence QSPI controller. Signed-off-by: Graham Moore grmo...@opensource.altera.com Signed-off-by: Marek Vasut ma...@denx.de Cc: Alan Tull at...@opensource.altera.com Cc: Brian Norris computersforpe...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Dinh Nguyen dingu...@opensource.altera.com Cc: Graham Moore grmo...@opensource.altera.com Cc: Vikas MANOCHA vikas.mano...@st.com Cc: Yves Vandervennet yvand...@opensource.altera.com Cc: devicetree@vger.kernel.org --- .../devicetree/bindings/mtd/cadence_quadspi.txt| 50 ++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt V2: Add cdns prefix to driver-specific bindings. V3: Use existing property is-decoded-cs instead of creating a duplicate, ext-decoder. Timing parameters are in nanoseconds, not master reference clocks. Remove bus-num completely. V4: Add new properties fifo-width and trigger-address V7: - Prefix all of the Cadence-specific properties with cdns prefix, those are in particular cdns,is-decoded-cs, cdns,fifo-depth, cdns,fifo-width, cdns,trigger-address. - Drop bogus properties which were not used and were incorrect. diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt new file mode 100644 index 000..ebaf1fd --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt @@ -0,0 +1,50 @@ +* Cadence Quad SPI controller + +Required properties: +- compatible : Should be cdns,qspi-nor. +- reg : Contains two entries, each of which is a tuple consisting of a +physical address and length. The first entry is the address and +length of the controller register set. The second entry is the +address and length of the QSPI Controller data area. Controller data area, i think it means mapped NOR Flash address ? Probably ; Graham ? If yes, it would be more clear with Physical base address size of NOR Flash. This is the Direct mode thing, correct ? We don't support this, so I think we should drop this bit altogether and keep only one single address in this field. No it's not. +- interrupts : Unit interrupt specifier for the controller interrupt. +- clocks : phandle to the Quad SPI clock. +- cdns,fifo-depth : Size of the data FIFO in words. It actually is sram-depth, better would be sram-depth to avoid confusion. Is there any documentation for this piece to which you can point me ? It's on the controller data sheet , should also be part of socfpga doc, let me know the document you have access to, I will point to the relevant part. +- cdns,fifo-width: Bus width of the data FIFO in bytes. +- cdns,trigger-address : 32-bit indirect AHB trigger address. we might make trigger-address also part of property reg. No, we cannot, it's not part of the controller's base address, is it ? Ok. + +Optional properties: +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. Not clear about the usage of decoder, if it does not make sense we might remove it from driver. Graham ? SoCFPGA uses this decoded-cs thing, so we absolutely can not remove it from the driver. +Optional subnodes: I think flash subnode is mandatory. You can have a controller with no SPI NORs on it. Without spi nor this controller/driver can't be used for anything. Rgds, Vikas -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/4] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
From: Vivek Gautam gautam.vi...@samsung.com
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
[vikas.saj...@samsung.com: updated the binding document]
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
.../devicetree/bindings/arm/samsung/sysreg.txt | 11 +--
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..4fced6e 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -1,8 +1,10 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- - compatible : should contain samsung,chip name-sysreg, syscon;
- For Exynos4 SoC series it should be samsung,exynos4-sysreg, syscon;
+ - compatible : should contain two values. First value must be one from
following list:
+ - samsung,exynos4-sysreg - for Exynos4 based SoCs,
+ - samsung,exynos5-sysreg - for Exynos5 based SoCs.
+ second value must be always syscon.
- reg : offset and length of the register set.
Example:
@@ -10,3 +12,8 @@ Example:
compatible = samsung,exynos4-sysreg, syscon;
reg = 0x1001 0x400;
};
+
+ syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
+ reg = 0x1005 0x5000;
+ };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 68a3e6f..8e9b9a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -193,6 +193,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
+ reg = 0x1005 0x5000;
+ };
+
watchdog@101D {
compatible = samsung,exynos5250-wdt;
reg = 0x101D 0x100;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 13a083e..f9b051b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -725,6 +725,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
+ reg = 0x1005 0x5000;
+ };
+
tmu_cpu0: tmu@1006 {
compatible = samsung,exynos5420-tmu;
reg = 0x1006 0x100;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/4] dts: Add usb2phy to Exynos 5250/5420
Based on 'for-next' branch of Kgene's linux-samsung tree. These patches are as per discussions on the driver side patches which have already been acked. [1] Changes from v2: - Addressed kukjin's comments to update DT binding documentation for sysreg. - removed the version for each patch. Made all patches version as same. Changes from v1: - Rebase on 'for-next' branch. - Removed 'phy-names' property as per discuusion in the driver patches. [1] V1 of this series was the next version for earlier patch-series: [PATCH v7 0/2] dts: Add usb2phy to Exynos 5250 [2] Changes from v7 series: - Added patches to enable usb 2.0 support on exynos5420; which include dt nodes for usb2phy as well as ehci and ohci controllers. Changes from v6: - Splitted the patch into two: adding syscon nodes to Exynos5250 and Exynos5420 in first; and phy entry change in the second. - Changed the name of phandle for usb2phy from 'usb2_phy_new' to 'usb2_phy_gen' indicating generic phy. - Using clock macros in dt entries. [1] http://www.spinics.net/lists/linux-usb/msg106908.html http://www.spinics.net/lists/linux-usb/msg106837.html [2] http://www.spinics.net/lists/linux-usb/msg106427.html Kamil Debski (1): ARM: dts: Add usb2phy to Exynos 5250 Vivek Gautam (3): ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420 ARM: dts: Add usb2phy support on exynos5420 ARM: dts: Add usb 2.0 support on exynos5420 .../devicetree/bindings/arm/samsung/sysreg.txt | 11 - arch/arm/boot/dts/exynos5250.dtsi | 27 arch/arm/boot/dts/exynos5420.dtsi | 45 3 files changed, 81 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/4] ARM: dts: Add usb2phy support on exynos5420
From: Vivek Gautam gautam.vi...@samsung.com
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f9b051b..2eb00cb 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -838,4 +838,14 @@
samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 1;
};
+
+ usb2_phy: phy@1213 {
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USBH20, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/4] ARM: dts: Add usb2phy to Exynos 5250
From: Kamil Debski k.deb...@samsung.com
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 8e9b9a3..cb29642 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -577,6 +577,12 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ };
};
usb@1212 {
@@ -586,6 +592,12 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ };
};
usb2_phy: usbphy@1213 {
@@ -603,6 +615,16 @@
};
};
+ usb2_phy_gen: phy@1213 {
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USB2, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
+
pwm: pwm@12dd {
compatible = samsung,exynos4210-pwm;
reg = 0x12dd 0x100;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: exynos4: add PMU syscon node
Hi,
On Thu, Apr 24, 2014 at 9:37 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Chanho,
On 14.04.2014 14:48, Chanho Park wrote:
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};
+ pmu_reg: syscon@1002 {
+ compatible = samsung,exynos4-pmureg, syscon;
Assume a case where exynos PMU is made as platform driver [1] and we
need use the compatible samsung,exynos4-pmureg in the driver.
But since syscon driver uses compatible syscon and once the syscon
driver is probed, the exynos PMU platform driver [1] will NEVER be
probed.
So my question is, can we have 2 compatible strings for a DT node, and
both the compatible strings are used for probing purpose?
Recently I faced this issue on exynos5250, where i was testing PMU
driver [1] and I noticed that PMU driver [1] was NEVER probed, if I
enable syscon driver in menuconfig.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg28038.html
This compatible string doesn't seem to be defined in [1], please add it
there,
[1] Documentation/devicetree/bindings/arm/samsung/pmu.txt
Otherwise looks good, so after fixing that you may add my
Reviewed-by: Tomasz Figa t.f...@samsung.com
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210
+Tomasz
On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..0a2c0fe 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,11 @@
interrupts = 2 2, 3 2;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu, syscon;
+ reg = 0x1002 0x5000;
Can we have 2 strings as compatible and these 2 strings are used by
2 different driver?
Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.
The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled System Controller
Register R/W Based on Regmap in menuconfig, I could see PMU driver
[1] is NEVER probed.
Let me know, if I am missing something.
[1] http://www.spinics.net/lists/arm-kernel/msg319750.html
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
--
1.7.10.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210
Hi Pankaj,
On Thu, Apr 24, 2014 at 6:27 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi Vikas,
On 04/24/2014 08:59 PM, Vikas Sajjan wrote:
+Tomasz
On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey pankaj.du...@samsung.com
wrote:
This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..0a2c0fe 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,11 @@
interrupts = 2 2, 3 2;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu, syscon;
+ reg = 0x1002 0x5000;
Can we have 2 strings as compatible and these 2 strings are used by
2 different driver?
Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.
The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled System Controller
Register R/W Based on Regmap in menuconfig, I could see PMU driver
[1] is NEVER probed.
Let me know, if I am missing something.
[1] http://www.spinics.net/lists/arm-kernel/msg319750.html
You are correct. We also missed this because SYSCON option was
not enabled in exynos_defconfig.
I noticed this during preparation of V2 when I planned to use
early_syscon_init [1] as suggested by Sylwester here [2].
OK.
In V2 I will take care of this. I hope soon I will be able to post second
So in your V2, will you be adding new DT node altogether for PMU?
Because with existing DT node pmu_system_controller (which is
already present in mailine for exynos 5250) and SYSCON driver enable,
exynos PMU driver will NEVER probed.
version of this series, just waiting for testing and internal code review.
[1] https://lkml.org/lkml/2014/4/8/239
[2] https://lkml.org/lkml/2014/4/2/171
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
--
1.7.10.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards,
Pankaj Dubey
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
Hi, On Tue, Apr 15, 2014 at 2:02 PM, Chanwoo Choi cw00.c...@samsung.com wrote: Hi, On 04/15/2014 05:11 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: This patch add memory mapping for PMU (Power Management Unit) which is used for power control of Exynos3250. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patch related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. You are right. Sachin's patch only included the solution of SYSRAM memory mapping. I set out the plan that I would implment proper driver for PMU memory mapping instead of static method after merged Sachin's patch for SYSRAM. But, If you'd like me to implment PMU memory mapping instead of static mapping right now, I'll implement it for PMU such as Sachin's patch on next posting(v3). I have already posted patch[1] for mapping PMU through DT as part of my PMU series for exynos5260. You can rebase on the same. [1] http://www.spinics.net/lists/arm-kernel/msg316013.html Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: EXYNOS: Add initial support of PMU for Exynos5260
Hi Tomasz,
On Wed, Apr 16, 2014 at 12:04 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Adds PMU support of PMU for Exynos5260. Suspend-to-RAM can be built on
top this.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h| 26
arch/arm/mach-exynos/pm.c| 34 +++--
arch/arm/mach-exynos/pmu.c | 238
++
arch/arm/mach-exynos/regs-pmu.h | 232
+
arch/arm/plat-samsung/include/plat/cpu.h |8 +
5 files changed, 529 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index aba6a2a..a17f701 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -56,6 +56,32 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
+enum running_cpu {
+ EXYNOS5_KFC,
+ EXYNOS5_ARM,
+};
+
+enum reg_op {
+ REG_INIT, /* write new value */
+ REG_RESET, /* clear with zero */
+ REG_SET,/* bit set */
+ REG_CLEAR, /* bit clear */
+};
+
+/* reg/value set */
+#define EXYNOS_PMU_REG(REG, VAL, OP) \
+{ \
+ .reg= (void __iomem *)REG,\
+ .val= VAL,\
+ .op = OP, \
+}
+
+struct exynos_pmu_init_reg {
+ void __iomem *reg;
+ unsigned int val;
+ enum reg_op op;
+};
+
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
void __iomem *reg;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..dbe9670 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -109,7 +109,7 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5260())
flush_cache_all();
I think it's the right time for this code to be restructured. Adding more
and more SoCs over this cruft is making this code worse and worse.
I recently came across RFC [1] posted by pankaj on similar lines, did
you get a chance to have look at this series.
[1] https://lkml.org/lkml/2014/4/2/69
I believe this should be done as follows:
- a generic struct describing particular PMU variant should be defined,
with things like
bool flush_cache_on_suspend;
struct exynos_pmu_conf *pmu_conf;
or even function pointers, like
void (*cpu_suspend)(unsigned long arg);
to handle things done currently using soc_is_*() macros, which we should get
rid of.
- a DT match table would bind particular compatible strings with respective
PMU variants structs,
- in general, this code should be made more like a normal driver, e.g. bind
to a DT node and map registers dynamically.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Add initial support of PMU for exynos5260
Hi, Any comments on this series. On Mon, Mar 17, 2014 at 6:39 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: From: Vikas Sajjan vikas.saj...@linaro.org 1) Added initial PMU support for exynos5260 2) Added S2R(single CPU) support on exynos5260 3) Added PMU mapping via DT. rebased on 1) kgene tree for-next branch https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2) Rahul's patches for basic support of exynos5260 http://www.spinics.net/lists/linux-samsung-soc/msg27282.html 3) Rahul's clk patches http://www.spinics.net/lists/linux-samsung-soc/msg27275.html 4) Tomasz Figa's http://permalink.gmane.org/gmane.linux.ports.arm.kernel/299340 Changes since v1: -- Addressed Tomasz Figa's comments. -- removed CMU patch -- Added PMU mapping via DT Vikas Sajjan (3): ARM: EXYNOS: Map PMU address through DT ARM: EXYNOS: Add initial support of PMU for Exynos5260 arm: exynos5260: add support for S2R .../devicetree/bindings/arm/samsung/pmu.txt|5 +- arch/arm/boot/dts/exynos4.dtsi |5 + arch/arm/boot/dts/exynos5260.dtsi |5 + arch/arm/mach-exynos/common.c | 51 ++-- arch/arm/mach-exynos/common.h | 26 +++ arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exynos/pm.c | 96 ++-- arch/arm/mach-exynos/pmu.c | 238 +++ arch/arm/mach-exynos/regs-pmu.h| 244 arch/arm/plat-samsung/include/plat/cpu.h |8 + 10 files changed, 637 insertions(+), 44 deletions(-) -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] arm: exynos5260: add support for S2R
Adds Suspend to RAM (S2R) support to exynos5260.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c | 62 +++
arch/arm/mach-exynos/regs-pmu.h | 12
2 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index dbe9670..12cc241 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -77,12 +77,20 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] =
{
{ /* sentinel */ },
};
+static const struct exynos_wkup_irq exynos5260_wkup_irq[] = {
+ { 105, BIT(1) }, /* RTC alarm */
+ { 106, BIT(2) }, /* RTC tick */
+ { /* sentinel */ },
+};
+
static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
if (soc_is_exynos5250())
wkup_irq = exynos5250_wkup_irq;
+ else if (soc_is_exynos5260())
+ wkup_irq = exynos5260_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
@@ -124,10 +132,20 @@ static void exynos_pm_prepare(void)
unsigned int tmp;
/* Set wake-up mask registers */
- __raw_writel(exynos_get_eint_wake_mask(), S5P_EINT_WAKEUP_MASK);
- __raw_writel(exynos_irqwake_intmask ~(1 31), S5P_WAKEUP_MASK);
+ if (soc_is_exynos5260()) {
+ __raw_writel(exynos_get_eint_wake_mask(),
+ EXYNOS5260_EINT_WAKEUP_MASK);
+ __raw_writel(exynos_irqwake_intmask ~(1 31),
+ EXYNOS5260_WAKEUP_MASK);
+ } else {
+ __raw_writel(exynos_get_eint_wake_mask(),
+ S5P_EINT_WAKEUP_MASK);
+ __raw_writel(exynos_irqwake_intmask ~(1 31),
+ S5P_WAKEUP_MASK);
+ }
- s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+ if (!soc_is_exynos5260())
+ s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
if (soc_is_exynos5250()) {
s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
@@ -221,21 +239,39 @@ static void exynos_pm_resume(void)
: cc);
}
- /* For release retention */
-
- __raw_writel((1 28), S5P_PAD_RET_MAUDIO_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_GPIO_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_UART_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_MMCA_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_MMCB_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_EBIA_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_EBIB_OPTION);
+ if (soc_is_exynos5250()) {
+ /* For release retention */
+
+ __raw_writel((1 28), S5P_PAD_RET_MAUDIO_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_GPIO_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_UART_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_MMCA_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_MMCB_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_EBIA_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_EBIB_OPTION);
+ } else if (soc_is_exynos5260()) {
+ /* For release retention */
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_LPDDR3_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RET_MAUDIO_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RET_JTAG_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC2_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_TOP_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_UART_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC0_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC1_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_SPI_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MIF_OPTION);
+ __raw_writel((1 28),
+ EXYNOS5260_PAD_RETENTION_BOOTLDO_OPTION);
+ }
if (soc_is_exynos5250())
s3c_pm_do_restore(exynos5_sys_save,
ARRAY_SIZE(exynos5_sys_save));
- s3c_pm_do_restore_core(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+ if (!soc_is_exynos5260())
+ s3c_pm_do_restore_core(exynos_core_save,
+ ARRAY_SIZE(exynos_core_save));
if (IS_ENABLED(CONFIG_SMP) !soc_is_exynos5250())
scu_enable(S5P_VA_SCU);
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index a81926b..906dc1e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
[PATCH v2 0/3] Add initial support of PMU for exynos5260
From: Vikas Sajjan vikas.saj...@linaro.org 1) Added initial PMU support for exynos5260 2) Added S2R(single CPU) support on exynos5260 3) Added PMU mapping via DT. rebased on 1) kgene tree for-next branch https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2) Rahul's patches for basic support of exynos5260 http://www.spinics.net/lists/linux-samsung-soc/msg27282.html 3) Rahul's clk patches http://www.spinics.net/lists/linux-samsung-soc/msg27275.html 4) Tomasz Figa's http://permalink.gmane.org/gmane.linux.ports.arm.kernel/299340 Changes since v1: -- Addressed Tomasz Figa's comments. -- removed CMU patch -- Added PMU mapping via DT Vikas Sajjan (3): ARM: EXYNOS: Map PMU address through DT ARM: EXYNOS: Add initial support of PMU for Exynos5260 arm: exynos5260: add support for S2R .../devicetree/bindings/arm/samsung/pmu.txt|5 +- arch/arm/boot/dts/exynos4.dtsi |5 + arch/arm/boot/dts/exynos5260.dtsi |5 + arch/arm/mach-exynos/common.c | 51 ++-- arch/arm/mach-exynos/common.h | 26 +++ arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exynos/pm.c | 96 ++-- arch/arm/mach-exynos/pmu.c | 238 +++ arch/arm/mach-exynos/regs-pmu.h| 244 arch/arm/plat-samsung/include/plat/cpu.h |8 + 10 files changed, 637 insertions(+), 44 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: EXYNOS: Add initial support of PMU for Exynos5260
Adds PMU support of PMU for Exynos5260. Suspend-to-RAM can be built on
top this.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h| 26
arch/arm/mach-exynos/pm.c| 34 +++--
arch/arm/mach-exynos/pmu.c | 238 ++
arch/arm/mach-exynos/regs-pmu.h | 232 +
arch/arm/plat-samsung/include/plat/cpu.h |8 +
5 files changed, 529 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index aba6a2a..a17f701 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -56,6 +56,32 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
+enum running_cpu {
+ EXYNOS5_KFC,
+ EXYNOS5_ARM,
+};
+
+enum reg_op {
+ REG_INIT, /* write new value */
+ REG_RESET, /* clear with zero */
+ REG_SET,/* bit set */
+ REG_CLEAR, /* bit clear */
+};
+
+/* reg/value set */
+#define EXYNOS_PMU_REG(REG, VAL, OP) \
+{ \
+ .reg= (void __iomem *)REG,\
+ .val= VAL,\
+ .op = OP, \
+}
+
+struct exynos_pmu_init_reg {
+ void __iomem *reg;
+ unsigned int val;
+ enum reg_op op;
+};
+
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
void __iomem *reg;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..dbe9670 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -109,7 +109,7 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5260())
flush_cache_all();
/* issue the standby signal into the pm unit. */
@@ -150,6 +150,7 @@ static void exynos_pm_prepare(void)
static int exynos_pm_suspend(void)
{
unsigned long tmp;
+ unsigned int cluster_id;
/* Setting Central Sequence Register for power down mode */
@@ -158,11 +159,21 @@ static int exynos_pm_suspend(void)
__raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
/* Setting SEQ_OPTION register */
+ if (soc_is_exynos5250()) {
+ tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+ } else if (soc_is_exynos5260()) {
+ cluster_id = (read_cpuid(CPUID_MPIDR) 8) 0xf;
+ if (!cluster_id)
+ __raw_writel(EXYNOS5260_ARM_USE_STANDBY_WFI0,
+S5P_CENTRAL_SEQ_OPTION);
+ else
+ __raw_writel(EXYNOS5260_KFC_USE_STANDBY_WFI0,
+S5P_CENTRAL_SEQ_OPTION);
- tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
- __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+ }
- if (!soc_is_exynos5250()) {
+ if (!soc_is_exynos5250() !soc_is_exynos5260()) {
/* Save Power control register */
asm (mrc p15, 0, %0, c15, c0, 0
: =r (tmp) : : cc);
@@ -196,7 +207,7 @@ static void exynos_pm_resume(void)
/* No need to perform below restore code */
goto early_wakeup;
}
- if (!soc_is_exynos5250()) {
+ if (!soc_is_exynos5250() !soc_is_exynos5260()) {
/* Restore Power control register */
tmp = save_arm_register[0];
asm volatile (mcr p15, 0, %0, c15, c0, 0
@@ -312,10 +323,15 @@ void __init exynos_pm_init(void)
gic_arch_extn.irq_set_wake = exynos_irq_set_wake;
/* All wakeup disable */
- tmp = __raw_readl(S5P_WAKEUP_MASK);
- tmp |= ((0xFF 8) | (0x1F 1));
- __raw_writel(tmp, S5P_WAKEUP_MASK);
-
+ if (soc_is_exynos5260()) {
+ tmp = __raw_readl(EXYNOS5260_WAKEUP_MASK);
+ tmp |= ((0xE 12) | (0xE 8) | (0x3 1));
+ __raw_writel(tmp, EXYNOS5260_WAKEUP_MASK);
+ } else {
+ tmp = __raw_readl(S5P_WAKEUP_MASK);
+ tmp |= ((0xFF 8) | (0x1F 1));
+ __raw_writel(tmp, S5P_WAKEUP_MASK);
+ }
register_syscore_ops(exynos_pm_syscore_ops);
suspend_set_ops(exynos_suspend_ops);
}
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 05c7ce1..7a3412d 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -18,6 +18,13 @@
#include common.h
#include regs-pmu.h
+#define EXYNOS5260_USE_STANDBY_WFI_ALL (EXYNOS5260_ARM_USE_STANDBY_WFI0 \
+ | EXYNOS5260_ARM_USE_STANDBY_WFI1 \
+ | EXYNOS5260_KFC_USE_STANDBY_WFI0
[PATCH v2 1/3] ARM: EXYNOS: Map PMU address through DT
Instead of hardcoding the PMU details for each SoC, pass this information
through device tree (DT).
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
.../devicetree/bindings/arm/samsung/pmu.txt|5 +-
arch/arm/boot/dts/exynos4.dtsi |5 ++
arch/arm/boot/dts/exynos5260.dtsi |5 ++
arch/arm/mach-exynos/common.c | 51 +---
arch/arm/mach-exynos/include/mach/map.h|3 --
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f1552..667a7f0 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,14 +2,15 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+ - samsung,exynos4210-pmu - for Exynos4210 and Exynos4x12
SoC,
- samsung,exynos5250-pmu - for Exynos5250 SoC,
- - samsung,exynos5420-pmu - for Exynos5420 SoC.
+ - samsung,exynos5420-pmu - for Exynos5420 and Exynos5260
SoC.
second value must be always syscon.
- reg : offset and length of the register set.
Example :
pmu_system_controller: system-controller@1004 {
- compatible = samsung,exynos5250-pmu, syscon;
+ compatible = samsung,exynos5250-pmu;
reg = 0x1004 0x5000;
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..94cbafa 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -55,6 +55,11 @@
#phy-cells = 1;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu;
+ reg = 0x1002 0x4000;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C40 0x20;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index a93fea8..2a4dace 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -264,6 +264,11 @@
};
};
+ pmu_system_controller: system-controller@10D5 {
+ compatible = samsung,exynos5420-pmu;
+ reg = 0x10D5 0x5000;
+ };
+
pinctrl_0: pinctrl@1160 {
compatible = samsung,exynos5260-pinctrl;
reg = 0x1160 0x1000;
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1df81ff..c75733b 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -79,11 +79,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -157,11 +152,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -243,12 +233,12 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
-struct __sysram_desc {
+struct __exynos_reg_desc {
char name[32];
unsigned long addr;
};
-static struct __sysram_desc sysram_desc[] __initdata = {
+static struct __exynos_reg_desc exynos_sysram_desc[] __initdata = {
{
.name = samsung,exynos4210-sysram,
.addr = (unsigned long)S5P_VA_SYSRAM,
@@ -258,7 +248,20 @@ static struct __sysram_desc sysram_desc[] __initdata = {
},
};
-static int __init exynos_fdt_map_sysram(unsigned long node, const char *uname,
+static struct __exynos_reg_desc exynos_pmu_desc[] __initdata = {
+ {
+ .name = samsung,exynos4210-pmu,
+ .addr = (unsigned long)S5P_VA_PMU,
+ }, {
+ .name = samsung,exynos5250-pmu,
+ .addr = (unsigned long)S5P_VA_PMU,
+ }, {
+ .name = samsung,exynos5420-pmu
