ed during instruction (x) and address/mode/dummy (y) clock cycles, DTR
> is used only during data (z) clock cycles of SPI x-y-z protocols.
>
> Signed-off-by: Cyrille Pitchen
Reviewed-by: Marek Vasut
--
Best regards,
Marek Vasut
On 04/26/2017 12:31 AM, Mark Brown wrote:
> On Tue, Apr 25, 2017 at 08:32:10PM +0200, Marek Vasut wrote:
>> Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC.
>> This block supports three voltage monitors, VD18, VD25, VD33 for the
>> 1V8, 2V5, 3V3 volta
return err;
> + }
> +
> + /* Select the Page Program command. */
> + err = spi_nor_select_pp(nor, params, shared_mask);
> + if (err) {
> + dev_err(nor->dev, "invalid page program\n");
> + return err;
> + }
> +
> + /* Select the Sector Erase command. */
> + err = spi_nor_select_erase(nor, info);
> + if (err) {
> + dev_err(nor->dev, "invalid sector/block erase\n");
> + return err;
> + }
> +
> + /* Enable Quad I/O if needed. */
> + enable_quad_io = (spi_nor_get_protocol_width(nor->read_proto) == 4 ||
> + spi_nor_get_protocol_width(nor->write_proto) == 4);
What if read_proto != write_proto ? Also, this is awful code ... fix it.
> + if (enable_quad_io && params->quad_enable)
> + nor->flash_quad_enable = params->quad_enable;
> + else
> + nor->flash_quad_enable = NULL;
> +
> + return 0;
> +}
> +
> +int spi_nor_scan(struct spi_nor *nor, const char *name,
> + const struct spi_nor_hwcaps *hwcaps)
> +{
> + struct spi_nor_flash_parameter params;
> const struct flash_info *info = NULL;
> struct device *dev = nor->dev;
> struct mtd_info *mtd = &nor->mtd;
> @@ -1548,6 +1824,11 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name, enum read_mode mode)
> if (ret)
> return ret;
>
> + /* Reset SPI protocol for all commands */
> + nor->reg_proto = SNOR_PROTO_1_1_1;
> + nor->read_proto = SNOR_PROTO_1_1_1;
> + nor->write_proto = SNOR_PROTO_1_1_1;
> +
> if (name)
> info = spi_nor_match_id(name);
> /* Try to auto-detect if chip name wasn't specified or not found */
[...]
--
Best regards,
Marek Vasut
m.actual_length - cmd_sz;
> if (ret < 0)
> return -EIO;
> return ret;
> @@ -223,11 +274,20 @@ static int m25p_probe(struct spi_device *spi)
> spi_set_drvdata(spi, flash);
> flash->spi = spi;
>
> - if (spi->mode & SPI_RX_QUAD)
> + if (spi->mode & SPI_RX_QUAD) {
> hwcaps.mask |= SNOR_HWCAPS_READ_1_1_4;
> - else if (spi->mode & SPI_RX_DUAL)
> +
> + if (spi->mode & SPI_TX_QUAD)
> + hwcaps.mask |= (SNOR_HWCAPS_READ_1_4_4 |
> + SNOR_HWCAPS_PP_1_1_4 |
> + SNOR_HWCAPS_PP_1_4_4);
> + } else if (spi->mode & SPI_RX_DUAL) {
> hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
>
> + if (spi->mode & SPI_TX_DUAL)
> + hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
> + }
> +
> if (data && data->name)
> nor->mtd.name = data->name;
>
>
--
Best regards,
Marek Vasut
er, the right value (mtd->size) can be set.
> + */
Is 25 the smallest value ? Use a macro for this ...
> + flash->fsize = 25;
> +
> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
> + if (ret) {
> + dev_err(qspi->dev, "device scan failed\n");
> + return ret;
> + }
> +
> + /* number of bytes in Flash memory = 2^[FSIZE+1] */
> + flash->fsize = __fls(mtd->size) - 1;
> +
> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
> +
> + ret = mtd_device_register(mtd, NULL, 0);
> + if (ret) {
> + dev_err(qspi->dev, "mtd device parse failed\n");
> + return ret;
> + }
> +
> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num, width);
> +
> + return 0;
> +}
[...]
--
Best regards,
Marek Vasut
On 04/09/2017 09:37 PM, Cyrille Pitchen wrote:
> Hi Marek,
>
> Le 07/04/2017 à 01:37, Marek Vasut a écrit :
>> On 03/23/2017 12:33 AM, Cyrille Pitchen wrote:
>>> Before this patch, m25p80_read() supported few SPI protocols:
>>> - regular SPI 1-1-1
>>> - S
tion tell me, as an end user ? If I see this error
>> message, what sort of conclusion can I derive from it ? I have
>> no idea ...
>>
>
> I agree, this could be improved.
Please do.
>>> + return err;
>>> + }
>>> +
>>> + /* Select the Page Program command. */
>>> + err = spi_nor_select_pp(nor, params, shared_mask);
>>> + if (err) {
>>> + dev_err(nor->dev, "invalid page program\n");
>>> + return err;
>>> + }
>>> +
>>> + /* Select the Sector Erase command. */
>>> + err = spi_nor_select_erase(nor, info);
>>> + if (err) {
>>> + dev_err(nor->dev, "invalid sector/block erase\n");
>>> + return err;
>>> + }
>>> +
>>> + /* Enable Quad I/O if needed. */
>>> + enable_quad_io = (spi_nor_get_protocol_width(nor->read_proto) == 4 ||
>>> + spi_nor_get_protocol_width(nor->write_proto) == 4);
>>
>> What if read_proto != write_proto ? Also, this is awful code ... fix it.
>>
>
> As explained earlier about the QE bit and the Quad Enable Requirement,
> this is indeed exactly what we want: we must set the QE bit, hence call
> nor->flash_quad_enable() whenever any Quad SPI protocol is used for any
> SPI flash command.
>
> Currently Fast Read and Page Program are the only commands selected by
> the spi-nor protocols, which can use one Quad SPI protocol.
>
> So this code works whether of not (read_proto == write_proto).
OK, then this should also be a separate patch .
>>> + if (enable_quad_io && params->quad_enable)
>>> + nor->flash_quad_enable = params->quad_enable;
>>> + else
>>> + nor->flash_quad_enable = NULL;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int spi_nor_scan(struct spi_nor *nor, const char *name,
>>> +const struct spi_nor_hwcaps *hwcaps)
>>> +{
>>> + struct spi_nor_flash_parameter params;
>>> const struct flash_info *info = NULL;
>>> struct device *dev = nor->dev;
>>> struct mtd_info *mtd = &nor->mtd;
>>> @@ -1548,6 +1824,11 @@ int spi_nor_scan(struct spi_nor *nor, const char
>>> *name, enum read_mode mode)
>>> if (ret)
>>> return ret;
>>>
>>> + /* Reset SPI protocol for all commands */
>>> + nor->reg_proto = SNOR_PROTO_1_1_1;
>>> + nor->read_proto = SNOR_PROTO_1_1_1;
>>> + nor->write_proto = SNOR_PROTO_1_1_1;
>>> +
>>> if (name)
>>> info = spi_nor_match_id(name);
>>> /* Try to auto-detect if chip name wasn't specified or not found */
>> [...]
>>
>
> Best regards,
>
> Cyrille
>
--
Best regards,
Marek Vasut
On 04/09/2017 11:30 PM, Cyrille Pitchen wrote:
> Le 09/04/2017 à 22:46, Marek Vasut a écrit :
>> On 04/09/2017 09:37 PM, Cyrille Pitchen wrote:
>>> Hi Marek,
>>>
>>> Le 07/04/2017 à 01:37, Marek Vasut a écrit :
>>>> On 03/23/2017 12:33 AM
On 04/10/2017 11:08 AM, Ludovic BARRE wrote:
>
> On 04/07/2017 01:55 AM, Marek Vasut wrote:
>> On 03/31/2017 07:02 PM, Ludovic Barre wrote:
>>> From: Ludovic Barre
>>>
>>> The quadspi is a specialized communication interface targeting single,
>>>
>
> Cc: cphe...@gmail.com
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Boris Brezillon
> Cc: Marek Vasut
> Cc: Richard Weinberger
> Cc: Cyrille Pitchen
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov
> ---
> drivers/mtd/devices/mtd
On 04/10/2017 06:52 PM, Ludovic BARRE wrote:
> hi Marek
>
> tomorrow, I send a v3 with your/Rob reviews.
Super, thanks! I'll be pretty busy till Friday, so please keep in mind
the final review might take a bit.
> BR
>
> Ludo
>
>
> On 04/10/2017 06:15 PM, Mar
AD then ? Who clears that bit when protocol
changes ? You probably want something like cqspi_set_protocol()
instead, which is invoked from {read,write}{,_reg}() and erase().
> default:
> ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL,
> 0);
> if (ret)
>
--
Best regards,
Marek Vasut
olutely need
> a very fast attach time and be very sure that the NAND works as
> expected.
So we should document this with a big fat warning and set fastmap to
default=n ?
--
Best regards,
Marek Vasut
it hits
mainline. I think the stm32 stuff looks pretty OK, so we can take that
before the SFDP stuff, no?
--
Best regards,
Marek Vasut
On 03/29/2017 06:38 PM, Ludovic BARRE wrote:
>
>
> On 03/29/2017 03:57 PM, Marek Vasut wrote:
>> On 03/29/2017 03:35 PM, Ludovic BARRE wrote:
>>
>> [...]
>>
>>>>>>> +writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN |
>>&g
s SPI 1-4-4).
>>
>>
>> IMHO, the first 3 patches of this series are ready to be merged into the
>> github/spi-nor tree. Marek, do you agree with that?
>
> Marek, if you have no comment on them, I will merge patches 1, 2, 3 in
> the spi-nor tree within the next few days. Hence, people like Cédric
> waiting for the series to merged could base their work on these patches.
Hm well, you could've at least poked me about this, I was so snowed
under that I didn't have any chance to take a look :(
--
Best regards,
Marek Vasut
On 04/12/2017 04:58 PM, Andrey Smirnov wrote:
> On Tue, Apr 11, 2017 at 11:29 AM, Marek Vasut wrote:
>> On 04/11/2017 06:17 PM, Andrey Smirnov wrote:
>>> In anticipation of supporting chips that need it, extend the size of
>>> struct flash_info's 'jedec_id&#
med using the quadspi
> registers
> -read memory-mapped mode: the external Flash memory is mapped to the
> microcontroller address space and is seen by the system as if it was
> an internal memory
>
> Signed-off-by: Ludovic Barre
Reviewed-by: Marek Vasut
--
Best regards,
Marek Vasut
he current feature set seems to work fine, I successfully run the MTD
> tests on a Colibri iMX7.
>
> --
> Stefan
>
> Changes since v1:
> - Make clks_count const
> - Introduce IS_IMX7D for i.MX 7 SoC's and make it part of GPMI_IS_MX6
Super, thanks.
--
Best regards,
Marek Vasut
On 04/24/2017 01:38 PM, Lee Jones wrote:
> On Sun, 16 Apr 2017, Marek Vasut wrote:
[...]
>> +static int bd9571mwv_identify(struct bd9571mwv *bd)
>> +{
>> +struct device *dev = bd->dev;
>> +unsigned int value;
>> +int ret;
>&
Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
entry. The MFD part only specifies the regmap bits for the PMIC and
binds the subdevs together.
Signed-off-by: Marek Vasut
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven
Cc: Lee Jones
---
V2: - Change
Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC.
This block supports three voltage monitors, VD18, VD25, VD33 for the
1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the
DVFS rail.
Signed-off-by: Marek Vasut
Cc: linux-kernel@vger.kernel.org
Cc: Liam Girdwood
; +
> +qspi: spi@a0001000 {
> + compatible = "altr,quadspi-v2";
> + reg = <0xa0001000 0x40>, <0xb000 0x400>;
> + reg-names = "avl_csr", "avl_mem";
> +
> + flash@0 {
> + reg = <0>;
> + label = "FPGA Image";
> + };
> +};
>
--
Best regards,
Marek Vasut
On 05/02/2017 02:18 PM, Marek Vasut wrote:
> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
> entry. The MFD part only specifies the regmap bits for the PMIC and
> binds the subdevs together.
>
> Signed-off-by: Marek Vasut
> Cc: linux-kernel@vger.kern
return 0;
> +error:
> + altera_quadspi_remove_banks(dev);
> + return -EIO;
> +}
> +
> +static int altera_quadspi_remove(struct platform_device *pdev)
> +{
> + return altera_quadspi_remove_banks(&pdev->dev);
> +}
> +
> +static const struct of_device_id altera_quadspi_id_table[] = {
> +
> + { .compatible = "altr,quadspi-v2",},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, altera_quadspi_id_table);
> +
> +static struct platform_driver altera_quadspi_driver = {
> + .driver = {
> + .name = "altera_quadspi_platform",
> + .of_match_table = altera_quadspi_id_table,
> + },
> + .probe = altera_quadspi_probe,
> + .remove = altera_quadspi_remove,
> +};
> +module_platform_driver(altera_quadspi_driver);
> +
> +MODULE_AUTHOR("Viet Nga Dao ");
> +MODULE_AUTHOR("Yong Sern Lau ");
> +MODULE_AUTHOR("Matthew Gerlach ");
> +MODULE_DESCRIPTION("Altera QuadSPI Version 2 Platform Driver");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Marek Vasut
patch, the description is
really tiny.
> ---
> drivers/mtd/spi-nor/spi-nor.c | 775
> +-
> include/linux/mtd/spi-nor.h | 6 +
> 2 files changed, 768 insertions(+), 13 deletions(-)
Otherwise,
Reviewed-by: Marek Vasut
--
Best regards,
Marek Vasut
rs to the 3Eh and 3Fh instruction op codes to write/read
> the Status Register 2 on some SPI NOR flash memories, the 35h op code
> still being used to read the Configuration Register/Status Register 2 on
> other memories.
>
> Signed-off-by: Cyrille Pitchen
Acked-by: Marek
= flags;
> +
> + dev_set_drvdata(dev, q);
> +
> + dev_dbg(dev, "%s SR=0x%x FSR=0x%x\n", __func__,
> + alt_qspi_readl(q->csr_base, QUADSPI_SR_REG),
> + alt_qspi_readl(q->csr_base, QUADSPI_FLAG_STATUS_REG));
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(altera_quadspi_create);
> +
> +int altera_qspi_add_bank(struct device *dev,
> + u32 bank, struct device_node *np)
> +{
> + struct altera_quadspi *q = dev_get_drvdata(dev);
> +
> + if (q->num_flashes >= ALTERA_QUADSPI_MAX_NUM_FLASH_CHIP)
> + return -ENOMEM;
> +
> + q->num_flashes++;
> +
> + return altera_quadspi_setup_banks(dev, bank, np);
> +}
> +EXPORT_SYMBOL_GPL(altera_qspi_add_bank);
> +
> +int altera_quadspi_remove_banks(struct device *dev)
> +{
> + struct altera_quadspi *q = dev_get_drvdata(dev);
> + struct altera_quadspi_flash *flash;
> + int i;
> + int ret = 0;
> +
> + /* clean up for all nor flash */
> + for (i = 0; i < q->num_flashes; i++) {
> + flash = q->flash[i];
> + if (!flash)
> + continue;
> +
> + /* clean up mtd stuff */
> + ret = mtd_device_unregister(&flash->nor.mtd);
> + if (ret) {
> + dev_err(dev, "error removing mtd\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(altera_quadspi_remove_banks);
> +
> +MODULE_AUTHOR("Viet Nga Dao ");
> +MODULE_AUTHOR("Yong Sern Lau ");
> +MODULE_AUTHOR("Matthew Gerlach ");
> +MODULE_DESCRIPTION("Altera QuadSPI Version 2 Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mtd/altera-quadspi.h
> b/include/linux/mtd/altera-quadspi.h
> new file mode 100644
> index 000..58f31ee
> --- /dev/null
> +++ b/include/linux/mtd/altera-quadspi.h
> @@ -0,0 +1,28 @@
> +/*
> + *
> + * Copyright 2017 Intel Corporation, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __ALTERA_QUADSPI_H
> +#define __ALTERA_QUADSPI_H
> +
> +#include
> +
> +#define ALTERA_QUADSPI_FL_BITREV_READ BIT(0)
> +#define ALTERA_QUADSPI_FL_BITREV_WRITE BIT(1)
> +
> +#define ALTERA_QUADSPI_MAX_NUM_FLASH_CHIP 3
> +
> +int altera_quadspi_create(struct device *dev, void __iomem *csr_base,
> + void __iomem *data_base, void __iomem *window_reg,
> + size_t window_size, u32 flags);
> +
> +int altera_qspi_add_bank(struct device *dev,
> + u32 bank, struct device_node *np);
> +
> +int altera_quadspi_remove_banks(struct device *dev);
Why is this header needed at all ?
> +#endif
>
--
Best regards,
Marek Vasut
On 06/27/2017 04:32 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 27 Jun 2017, Marek Vasut wrote:
>
> Hi Marek,
>
> Thanks for the feedback. See my comments below.
>
> Matthew Gerlach
>
>> On 06/26/2017 06:13 PM, matthew.gerl...@linux.intel.
const struct of_device_id const cqspi_dt_ids[] = {
> +static const struct of_device_id cqspi_dt_ids[] = {
> {.compatible = "cdns,qspi-nor",},
> { /* end of table */ }
> };
>
--
Best regards,
Marek Vasut
On 06/27/2017 05:57 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 27 Jun 2017, Marek Vasut wrote:
>
>> On 06/27/2017 04:32 PM, matthew.gerl...@linux.intel.com wrote:
>>>
>>>
>>> On Tue, 27 Jun 2017, Marek Vasut wrote:
>>>
On 06/27/2017 05:15 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 27 Jun 2017, Marek Vasut wrote:
>
>> On 06/26/2017 06:13 PM, matthew.gerl...@linux.intel.com wrote:
>>> From: Matthew Gerlach
>>
>> Just wrap it into the Altera QSPI driver ,
e, void __iomem *window_reg,
>>> + size_t window_size, u32 flags);
>>> +
>>> +int altera_qspi_add_bank(struct device *dev,
>>> + u32 bank, struct device_node *np);
>>> +
>>> +int altera_quadspi_remove_banks(struct device *dev);
>>
>> Why is this header needed at all ?
>
> This header is needed because of the very different ways
> FPGAs can be used with a processor running Linux. In the case of a
> soft processor in the FPGA or an ARM connected to a FPGA, this header
> is not necessary because device trees are used to probe the driver.
> However, if the FPGA is on a PCIe card connected to an x86, device trees
> are not generally used, and the pcie driver must enumerate the
> "sub-driver".
But we don't support that later part, do we ?
--
Best regards,
Marek Vasut
On 06/27/2017 07:18 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 27 Jun 2017, Marek Vasut wrote:
>
>> On 06/27/2017 05:57 PM, matthew.gerl...@linux.intel.com wrote:
>>>
>>>
>>> On Tue, 27 Jun 2017, Marek Vasut wrote:
>>>
>&g
on 2 of the Altera Quadspi
> controller.
It'd be real nice to mention that in the cover letter with a link to
that patchset , otherwise it's real hard to understand why you did this.
> This technique of separating core driver code from platform/device tree
> code has been reviewed and accepted for the Altera Partial
> Reconfiguration IP, Altera Freeze Bridge, and the fpga region.
--
Best regards,
Marek Vasut
On 06/27/2017 09:48 PM, Cyrille Pitchen wrote:
> Le 27/06/2017 à 18:11, Marek Vasut a écrit :
>> On 06/27/2017 05:34 PM, Arnd Bergmann wrote:
>>> The variable was already marked 'const' before the previous
>>> patch, but the qualifier was in an unusual place, a
ferent perspective. The FPGA looks at the data
>>>>> from one
>>>>> perspective on power up, and a processor trying to update the flash
>>>>> has
>>>>> a different perspective.
>>>>
>>>> Another thing I'd ask here is, is that bit-reverse a hardware property
>>>> or is that some software configuration thing ?
>>>
>>> I would say the bit reversal is a property of the FPGA that is reading
>>> the flash at power up.
>>
>> So it's not a property of the block, but rather of the bus somewhere ?
>
> You are correct, it is not a property of the Altera Quadspi component, but
> a property of the fpga and external hardware that access the flash on
> power up.
So yes, it's a property of that small thing which loads the bitstream
from the EPCS/EPCQ and programs the cells in the FPGA. This shouldn't be
in this driver nor it's bindings, see above.
--
Best regards,
Marek Vasut
On 06/27/2017 10:21 PM, Cyrille Pitchen wrote:
> Le 27/06/2017 à 21:51, Marek Vasut a écrit :
>> On 06/27/2017 09:48 PM, Cyrille Pitchen wrote:
>>> Le 27/06/2017 à 18:11, Marek Vasut a écrit :
>>>> On 06/27/2017 05:34 PM, Arnd Bergmann wrote:
>>>>> T
On 06/29/2017 01:09 AM, Rob Herring wrote:
> On Tue, Jun 27, 2017 at 08:57:14AM -0700, matthew.gerl...@linux.intel.com
> wrote:
>>
>>
>> On Tue, 27 Jun 2017, Marek Vasut wrote:
>>
>>> On 06/27/2017 04:32 PM, matthew.gerl...@linux.intel.com wrote:
>>
DC_ECC_MODES (ECC_RS_4BIT | ECC_BCH_8BIT)
>
> +static const struct qcom_nand_driver_data ebi2_nandc_data = {
> + .ecc_modes = (ECC_RS_4BIT | ECC_BCH_8BIT),
> + .dma_bam_enabled = false,
> +};
> +
> +static const struct qcom_nand_driver_data qpic_nandc_v1_4_0_data = {
> + .ecc_modes = (ECC_BCH_4BIT | ECC_BCH_8BIT),
> + .dma_bam_enabled = true,
> +};
> /*
> * data will hold a struct pointer containing more differences once we
> support
> * more controller variants
> */
> static const struct of_device_id qcom_nandc_of_match[] = {
> { .compatible = "qcom,ipq806x-nand",
> - .data = (void *)EBI2_NANDC_ECC_MODES,
> + .data = (void *)&ebi2_nandc_data,
> + },
> + { .compatible = "qcom,qpic-nandc-v1.4.0",
> + .data = (void *)&qpic_nandc_v1_4_0_data,
> },
> {}
> };
>
--
Best regards,
Marek Vasut
t; - }
> + if (!nandc->dma_bam_enabled) {
> + ret = of_property_read_u32(np, "qcom,cmd-crci",
> +&nandc->cmd_crci);
> + if (ret) {
> + dev_err(nandc->dev, "command CRCI unspecified\n");
> + return ret;
> + }
>
> - ret = of_property_read_u32(np, "qcom,data-crci", &nandc->data_crci);
> - if (ret) {
> - dev_err(nandc->dev, "data CRCI unspecified\n");
> - return ret;
> + ret = of_property_read_u32(np, "qcom,data-crci",
> +&nandc->data_crci);
> + if (ret) {
> + dev_err(nandc->dev, "data CRCI unspecified\n");
> + return ret;
> + }
> }
>
> return 0;
> @@ -2128,7 +2188,7 @@ static int qcom_nandc_probe(struct platform_device
> *pdev)
>
> ret = qcom_nandc_alloc(nandc);
> if (ret)
> - return ret;
> + goto err_core_clk;
>
> ret = clk_prepare_enable(nandc->core_clk);
> if (ret)
>
Can you please fix your mailer to stop adding "QUALCOMM INDIA, on behalf
of Qualcomm Innovation Center"... stuff at the bottom of the patches ?
--
Best regards,
Marek Vasut
SABLE
> + host->ecc_bch_cfg = !host->bch_enabled << ECC_CFG_ECC_DISABLE
> | 0 << ECC_SW_RESET
> | host->cw_data << ECC_NUM_DATA_BYTES
> | 1 << ECC_FORCE_CLK_OPEN
>
--
Best regards,
Marek Vasut
MEM;
> + }
> }
>
> INIT_LIST_HEAD(&nandc->desc_list);
> @@ -2153,6 +2258,17 @@ static int qcom_probe_nand_devices(struct
> qcom_nand_controller *nandc)
> if (list_empty(&nandc->host_list))
> return -ENODEV;
>
> + if (nandc->dma_bam_enabled) {
> + free_bam_transaction(nandc);
> + nandc->bam_txn = alloc_bam_transaction(nandc,
> +nandc->max_cwperpage);
> + if (!nandc->bam_txn) {
> + dev_err(nandc->dev,
> + "failed to allocate bam transaction\n");
> + return -ENOMEM;
> + }
> + }
> +
> list_for_each_entry_safe(host, tmp, &nandc->host_list, node) {
> ret = qcom_nand_mtd_register(nandc, host, child);
> if (ret) {
>
--
Best regards,
Marek Vasut
2);
> + write_data_dma(nandc, reg_off, oob_buf, oob_size2, 0);
> oob_buf += oob_size2;
>
> config_cw_write_post(nandc);
> @@ -1685,7 +1700,7 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd,
> struct nand_chip *chip,
>
> config_cw_write_pre(nandc);
> write_data_dma(nandc, FLASH_BUF_ACC, nandc->data_buffer,
> -data_size + oob_size);
> +data_size + oob_size, 0);
> config_cw_write_post(nandc);
>
> ret = submit_descs(nandc);
> @@ -1769,7 +1784,8 @@ static int qcom_nandc_block_markbad(struct mtd_info
> *mtd, loff_t ofs)
> update_rw_regs(host, 1, false);
>
> config_cw_write_pre(nandc);
> - write_data_dma(nandc, FLASH_BUF_ACC, nandc->data_buffer, host->cw_size);
> + write_data_dma(nandc, FLASH_BUF_ACC, nandc->data_buffer,
> +host->cw_size, 0);
> config_cw_write_post(nandc);
>
> ret = submit_descs(nandc);
>
--
Best regards,
Marek Vasut
On 06/29/2017 05:03 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Thu, 29 Jun 2017, Marek Vasut wrote:
>
>> On 06/29/2017 01:09 AM, Rob Herring wrote:
>>> On Tue, Jun 27, 2017 at 08:57:14AM -0700,
>>> matthew.gerl...@linux.intel.com wrote:
>>>
- 5p49v5925: (required) either or both of "xin", "clkin".
> - 5p49v5933 and
> - 5p49v5935: (optional) property not present or "clkin".
>
> @@ -37,6 +39,7 @@ clock specifier, the following mapping applies:
> 1 -- OUT1
> 2 -- OUT4
>
> +5P49V5925 and
> 5P49V5935:
> 0 -- OUT0_SEL_I2CB
> 1 -- OUT1
>
--
Best regards,
Marek Vasut
clock output at
> OUT0_SELB_I2C).
>
> Signed-off-by: Vladimir Barinov
Reviewed-by: Marek Vasut
> ---
> drivers/clk/clk-versaclock5.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
On 07/09/2017 07:38 PM, Vladimir Barinov wrote:
> On 09.07.2017 16:31, Marek Vasut wrote:
>> On 07/07/2017 03:57 AM, Vladimir Barinov wrote:
>>> From: Vladimir Barinov
>>>
>>> IDT VersaClock 5 5P49V5925 has 4 clock outputs
>> In 1/2 you said it has 4 FODs
On 07/09/2017 07:40 PM, Vladimir Barinov wrote:
> From: Vladimir Barinov
>
> IDT VersaClock 5 5P49V5925 has 5 clock outputs, 4 fractional dividers.
> Input clock source can be taken only from external reference clock.
>
> Signed-off-by: Vladimir Barinov
Review
Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
entry. The MFD part only specifies the regmap bits for the PMIC and
binds the subdevs together.
Signed-off-by: Marek Vasut
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven
Cc: Lee Jones
---
V2: - Change
On 07/10/2017 05:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, May 2, 2017 at 2:18 PM, Marek Vasut wrote:
>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
>> entry. The MFD part only specifies the regmap bits for the PMIC and
>>
without a valid match in
> vf610_nfc_dt_ids the dev wouldn't have been probed in the first place.
>
> I'll let Stefan decide whether he wants it or not, but I see no real
> reason for this extra check.
So how did you trigger the issue in the first place ?
--
Best regards,
Marek Vasut
Moving the checks out of
core seems like the wrong thing to do, rather you should enhance the
checks in core if they're insufficient in my opinion.
--
Best regards,
Marek Vasut
On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
>
>
> On 15.02.2018 17:27, Marek Vasut wrote:
>> On 02/15/2018 04:41 PM, Herbert Xu wrote:
>>> On Thu, Jan 18, 2018 at 07:33:59PM +0100, Kamil Konieczny wrote:
>>>> First four patches add empty hash export and i
On 02/15/2018 07:06 PM, Kamil Konieczny wrote:
>
>
> On 15.02.2018 18:06, Marek Vasut wrote:
>> On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
>>>
>>>
>>> On 15.02.2018 17:27, Marek Vasut wrote:
>>>> On 02/15/2018 04:41 PM, Herbert Xu wrote:
On 02/16/2018 10:16 AM, Kamil Konieczny wrote:
>
> On 15.02.2018 19:32, Marek Vasut wrote:
>> On 02/15/2018 07:06 PM, Kamil Konieczny wrote:
>>>
>>>
>>> On 15.02.2018 18:06, Marek Vasut wrote:
>>>> On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
RQpending register, the
>> driver had read.
>>
>> Signed-off-by: Heiko Schocher
>> Reviewed-by: Marek Vasut
>
> Applied both to linux-can.
Can you also apply them to stable, so they get into 4.9.x etc ?
Thanks!
--
Best regards,
Marek Vasut
On 02/08/2018 10:33 PM, Marc Kleine-Budde wrote:
> On 02/08/2018 08:22 PM, Marek Vasut wrote:
>> On 02/08/2018 03:46 PM, Marc Kleine-Budde wrote:
>>> On 02/08/2018 07:47 AM, Heiko Schocher wrote:
>>>> the driver reads in the ISR first the IRQpending register,
>>
On 02/12/2018 09:52 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
> but use drm_simple_kms_helpe's pipe callbacks instead.
>
> Signed-off-by: Oleksandr Andrushchenko
> Cc:
>
> In case it clears "TX message sent successfully", the driver
> never sends any Tx data, and buffers to userspace run over.
>
> Fixed this:
> clear only the bits in the IRQpending register, the
> driver had read.
>
> Signed-off-by: Heiko Schocher
Reviewed-by:
f (cf->can_id & CAN_RTR_FLAG)
> txdlc |= IFI_CANFD_TXFIFO_DLC_RTR;
>
> + /*
> + * set FNR to 1, so we get our Tx Message looped back
> + * into RxFIFO
> + */
Nit, you can make this into a single-line comment ;-)
Otherwise,
Reviewed-
On 12/17/2017 09:43 AM, Boris Brezillon wrote:
> Hi Marek,
>
> On Wed, 11 Oct 2017 23:34:33 +0200
> Marek Vasut wrote:
>
>> On 10/11/2017 03:54 PM, Arnd Bergmann wrote:
>>> The map_word_() functions, dating back to linux-2.6.8, try to perform
>>> bitwi
To clarify, this is a potential security issue, as it might be used to
> construct a stack overflow to cause privilege escalation when combined
> with some other vulnerabilities. I'd definitely want this backported to
> stable kernels as a precaution, and I'm preparing a patch to warn
> about this kind of problem again in 'allmodconfig' kernels that
> currently disable the warning on arm64 and x86.
Wouldn't it make more sense to fix the compiler instead ?
This still feels like we're fixing a bug at the wrong place ...
--
Best regards,
Marek Vasut
On 12/18/2017 11:29 AM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 10:18 AM, Marek Vasut wrote:
>> On 12/18/2017 10:16 AM, Arnd Bergmann wrote:
>>> On Sun, Dec 17, 2017 at 9:34 PM, Richard Weinberger wrote:
>>>> Am Mittwoch, 11. Oktober 2017, 15:54:10 CET sc
e, hence
> should use the "jedec,spi-nor" string alone as 'compatible' value.
>
> See the following link for more details:
> http://lists.infradead.org/pipermail/linux-mtd/2017-November/077425.html
>
> Signed-off-by: Cyrille Pitchen
Acked-by: Marek Vasut
>
tain IRQ, ret=%i\n" please . It's inobvious what the value
means otherwise.
> + return irq;
> }
>
> ret = clk_prepare_enable(cqspi->clk);
>
--
Best regards,
Marek Vasut
ory during boot. Limit accessible
> + * size to 16MiB.
> + */
> + nor->addr_width = 3;
> + mtd->size = 0x100;
> + dev_info(dev, "Force 3B addressing mode\n");
> + } else
> set_4byte(nor, info, 1);
> } else {
> nor->addr_width = 3;
>
--
Best regards,
Marek Vasut
->sregs = ispi->base + BXT_SSFSTS_CTL;
> ispi->pregs = ispi->base + BXT_PR;
> ispi->nregions = BXT_FREG_NUM;
> + ispi->pr_num = BXT_PR_NUM;
> ispi->erase_64k = true;
> break;
>
> @@ -652,7 +658,7 @@ static bool intel_spi_is_protected(const struct intel_spi
> *ispi,
> {
> int i;
>
> - for (i = 0; i < PR_NUM; i++) {
> + for (i = 0; i < ispi->pr_num; i++) {
> u32 pr_base, pr_limit, pr_value;
>
> pr_value = readl(ispi->pregs + PR(i));
>
--
Best regards,
Marek Vasut
On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
>
>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>>>
>>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>>>>
>>>> On 04/25/20
On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
>> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
>>>> 2) It actually fixes a problem with the vo
On 05/04/2017 11:42 AM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
>> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
>>>> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
>
On 05/04/2017 02:44 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>> On 05/04/2017 11:42 AM, Leonard Crestez wrote:
>>> I think there is a further misunderstanding here. I have a problem
>>> where imx6sx-sdb rev C boards crash on
On 05/04/2017 03:41 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 03:08:41PM +0200, Marek Vasut wrote:
>> On 05/04/2017 02:44 PM, Shawn Guo wrote:
>>> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>
>
>
>>>> Mind you, my patch is no
they need to get them
through Rob :) IMO for MX7, this should be "imx7-gpmi-nand" , unless
there's some incentive to discern the solo/dual chips and/or there
is a future imx7 coming up with different GPMI NAND block version.
>> Hi Guys,
>>
>> Yes, there should be a i.MX7 Solo version with one core fused out. IMO, can
>> we use QUIRK to distinguish them rather than SoC name. I know I also sent
>> some patch set with SoC Name but I prefer to use QUIRK now.
>
> Not sure what this means. Are you okay with Stefan's v2?
IMO the GPMI controller in solo and dual should be the same, so there's
no need to have quirks for it.
--
Best regards,
Marek Vasut
Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
entry. The MFD part only specifies the regmap bits for the PMIC and
binds the subdevs together.
Signed-off-by: Marek Vasut
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven
Cc: Lee Jones
---
V2: - Change
On 05/03/2017 03:57 PM, Shawn Guo wrote:
> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>>> Anyway, that version also sets the supply for reg_arm and reg_soc. It
>>> is not necessary for fixing the c
On 05/03/2017 04:26 PM, Marek Vasut wrote:
> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>>>> Anyway, that version also sets the supply for reg_arm and reg
On 05/03/2017 04:41 PM, Shawn Guo wrote:
> On Wed, May 03, 2017 at 04:32:06PM +0200, Marek Vasut wrote:
>> On 05/03/2017 04:26 PM, Marek Vasut wrote:
>>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>>>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>>
with mtd-utils.
>
> Signed-off-by: Matthew Gerlach
> ---
> v2:
> minor checkpatch fixing by Wu Hao
> Use read_dummy value as suggested by Cyrille Pitchen.
> Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).
> Fixed #define indenting as
On 10/11/2017 07:00 PM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 10 Oct 2017, Marek Vasut wrote:
>
>> On 09/20/2017 08:28 PM, matthew.gerl...@linux.intel.com wrote:
>>> From: Matthew Gerlach
>>>
>>> This patch adds support for a spi
gt; Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
Don't you lose type-checking with this conversion to macros ?
--
Best regards,
Marek Vasut
nly stuff starts here. */
> const char *name;
> int index;
>
>
--
Best regards,
Marek Vasut
name, cqspi);
> @@ -1284,7 +1302,14 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
> #endif
>
> static const struct of_device_id cqspi_dt_ids[] = {
> - {.compatible = "cdns,qspi-nor",},
> + {
> + .compatible = "cdns,qspi-nor",
> + .data = (void *)0,
> + },
> + {
> + .compatible = "ti,k2g-qspi",
> + .data = (void *)CQSPI_NEEDS_WR_DELAY,
> + },
> { /* end of table */ }
> };
>
>
--
Best regards,
Marek Vasut
cqspi->clk);
> if (ret) {
> dev_err(dev, "Cannot enable QSPI clock.\n");
> @@ -1275,6 +1283,9 @@ static int cqspi_remove(struct platform_device *pdev)
>
> clk_disable_unprepare(cqspi->clk);
>
> + pm_runtime_put_sync(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
> +
> return 0;
> }
>
>
--
Best regards,
Marek Vasut
On 09/24/2017 03:08 PM, Vignesh R wrote:
>
>
> On 9/24/2017 5:31 PM, Marek Vasut wrote:
>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>> Add pm_runtime* calls to cadence-quadspi driver. This is required to
>>> switch on QSPI power domain on TI 66AK2G SoC du
On 09/24/2017 02:33 PM, Vignesh R wrote:
>
>
> On 9/24/2017 5:29 PM, Marek Vasut wrote:
>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>> As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
>>> Controller programming sequence, a delay equal to couple
On 09/24/2017 03:27 PM, Vignesh R wrote:
>
>
> On 9/24/2017 6:42 PM, Marek Vasut wrote:
>> On 09/24/2017 03:08 PM, Vignesh R wrote:
>>>
>>>
>>> On 9/24/2017 5:31 PM, Marek Vasut wrote:
>>>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>
On 09/26/2017 12:41 AM, matthew.gerl...@linux.intel.com wrote:
>
>
> On Sun, 24 Sep 2017, Marek Vasut wrote:
>
>> On 09/24/2017 03:27 PM, Vignesh R wrote:
>>>
>>>
>>> On 9/24/2017 6:42 PM, Marek Vasut wrote:
>>>> On 09/24/2017 03:08 PM
r"
>> - depends on OF && (ARM || COMPILE_TEST)
>> + depends on OF && (ARM || ARM64 || COMPILE_TEST)
>> help
>> Enable support for the Cadence Quad SPI Flash controller.
>>
>
--
Best regards,
Marek Vasut
> + }
> + }
> +
> + return 0;
> +error:
> + altera_asmip2_remove_banks(dev);
> + return -EIO;
> +}
> +
> +static int altera_asmip2_remove(struct platform_device *pdev)
> +{
> + if (!pdev) {
> + dev_err(&pdev->dev, "%s NULL\n", __func__);
> + return -EINVAL;
Can this really happen ?
> + } else {
> + return altera_asmip2_remove_banks(&pdev->dev);
> + }
> +}
> +
> +static const struct of_device_id altera_asmip2_id_table[] = {
> +
> + { .compatible = "altr,asmi_parallel2",},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, altera_asmip2_id_table);
> +
> +static struct platform_driver altera_asmip2_driver = {
> + .driver = {
> + .name = ALTERA_ASMIP2_DRV_NAME,
> + .of_match_table = altera_asmip2_id_table,
> + },
> + .probe = altera_asmip2_probe,
> + .remove = altera_asmip2_remove,
> +};
> +module_platform_driver(altera_asmip2_driver);
> +
> +MODULE_AUTHOR("Matthew Gerlach ");
> +MODULE_DESCRIPTION("Altera ASMI Parallel II");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" ALTERA_ASMIP2_DRV_NAME);
> diff --git a/include/linux/mtd/altera-asmip2.h
> b/include/linux/mtd/altera-asmip2.h
> new file mode 100644
> index 000..580c43c
> --- /dev/null
> +++ b/include/linux/mtd/altera-asmip2.h
> @@ -0,0 +1,24 @@
> +/*
> + *
> + * Copyright 2017 Intel Corporation, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __ALTERA_QUADSPI_H
> +#define __ALTERA_QUADSPI_H
> +
> +#include
> +
> +#define ALTERA_ASMIP2_DRV_NAME "altr-asmip2"
> +#define ALTERA_ASMIP2_MAX_NUM_FLASH_CHIP 3
> +#define ALTERA_ASMIP2_RESOURCE_SIZE 0x10
> +
> +struct altera_asmip2_plat_data {
> + void __iomem *csr_base;
> + u32 num_chip_sel;
> +};
> +
> +#endif
>
--
Best regards,
Marek Vasut
SPI_NOR_NORMAL:
> + aspi->num_hi_z_clocks = nor->read_dummy;
> + aspi->xfer_mode_cmd = MODE_IO_X1;
> + aspi->xfer_mode_addr = MODE_IO_X1;
> + aspi->xfer_mode_data = MODE_IO_X1;
> + break;
> + case SPI_NOR_FAST:
> + aspi->num_hi_z_clocks = nor->read_dummy;
> + aspi->xfer_mode_cmd = MODE_IO_X1;
> + aspi->xfer_mode_addr = MODE_IO_X1;
> + aspi->xfer_mode_data = MODE_IO_X1;
> + break;
> + case SPI_NOR_DUAL:
> + aspi->num_hi_z_clocks = nor->read_dummy;
> + aspi->xfer_mode_cmd = MODE_IO_X1;
> + aspi->xfer_mode_addr = MODE_IO_X1;
> + aspi->xfer_mode_data = MODE_IO_X2;
> + break;
> + case SPI_NOR_QUAD:
> + aspi->num_hi_z_clocks = nor->read_dummy;
> + aspi->xfer_mode_cmd = MODE_IO_X1;
> + aspi->xfer_mode_addr = MODE_IO_X1;
> + aspi->xfer_mode_data = MODE_IO_X4;
> + break;
> + }
> +
> + aspi_setup_xip_read_chain(aspi, nor);
> +
> + mtd_device_register(&aspi->nor.mtd, NULL, 0);
> +
> + return 0;
> +}
> +
> +static int anarion_qspi_drv_remove(struct platform_device *pdev)
> +{
> + struct anarion_qspi *aspi = platform_get_drvdata(pdev);
> +
> + mtd_device_unregister(&aspi->nor.mtd);
> + return 0;
> +}
> +
> +static const struct of_device_id anarion_qspi_of_match[] = {
> + { .compatible = "adaptrum,anarion-qspi" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, anarion_qspi_of_match);
> +
> +static struct platform_driver anarion_qspi_driver = {
> + .driver = {
> + .name = "anarion-qspi",
> + .of_match_table = anarion_qspi_of_match,
> + },
> + .probe = anarion_qspi_drv_probe,
> + .remove = anarion_qspi_drv_remove,
> +};
> +module_platform_driver(anarion_qspi_driver);
> +
> +MODULE_DESCRIPTION("Adaptrum Anarion Quad SPI Controller Driver");
> +MODULE_AUTHOR("Alexandru Gagniuc ");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Marek Vasut
On 07/18/2017 11:23 AM, Lee Jones wrote:
> On Mon, 17 Jul 2017, Marek Vasut wrote:
>
>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
>> entry. The MFD part only specifies the regmap bits for the PMIC and
>> binds the subdevs together.
>>
clocks = nor->read_dummy;
>>> +aspi->xfer_mode_cmd = MODE_IO_X1;
>>> +aspi->xfer_mode_addr = MODE_IO_X1;
>>> +aspi->xfer_mode_data = MODE_IO_X1;
>>> +break;
>>> +case SPI_NOR_FAST:
>>> +aspi->num_hi_z_clocks = nor->read_dummy;
>>> +aspi->xfer_mode_cmd = MODE_IO_X1;
>>> +aspi->xfer_mode_addr = MODE_IO_X1;
>>> +aspi->xfer_mode_data = MODE_IO_X1;
>>> +break;
>>> +case SPI_NOR_DUAL:
>>> +aspi->num_hi_z_clocks = nor->read_dummy;
>>> +aspi->xfer_mode_cmd = MODE_IO_X1;
>>> +aspi->xfer_mode_addr = MODE_IO_X1;
>>> +aspi->xfer_mode_data = MODE_IO_X2;
>>> +break;
>>> +case SPI_NOR_QUAD:
>>> +aspi->num_hi_z_clocks = nor->read_dummy;
>>> +aspi->xfer_mode_cmd = MODE_IO_X1;
>>> +aspi->xfer_mode_addr = MODE_IO_X1;
>>> +aspi->xfer_mode_data = MODE_IO_X4;
>>> +break;
>>> +}
>>> +
>>> +aspi_setup_xip_read_chain(aspi, nor);
>>> +
>>> +mtd_device_register(&aspi->nor.mtd, NULL, 0);
>>> +
>>> +return 0;
>>> +}
>
> [snip]
--
Best regards,
Marek Vasut
On 07/31/2017 10:54 PM, Alexandru Gagniuc wrote:
> Hi Marek,
>
> Me again!
>
> On 07/29/2017 02:34 AM, Marek Vasut wrote:
>> On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote:
>>> +static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf,
>>> si
On 08/01/2017 12:20 AM, Alexandru Gagniuc wrote:
> On 07/31/2017 02:33 PM, Marek Vasut wrote:
>> On 07/31/2017 07:17 PM, Alexandru Gagniuc wrote:
>
> Hi Marek,
>
> Thank you again for your feedback. I've applied a majority of your
> suggestions, and I am very happy w
On 06/13/2017 09:46 PM, Cyrille Pitchen wrote:
> SPI NOR branches are now hosted on MTD repos, spi-nor/next is on l2-mtd
> and spi-nor/fixes is on linux-mtd.
>
> Signed-off-by: Cyrille Pitchen
Excellent.
Acked-by: Marek Vasut
> ---
>
> ChangeLog
>
> v1 -> v2
d const cqspi_dt_ids[] = {
> {.compatible = "cdns,qspi-nor",},
> { /* end of table */ }
> };
>
--
Best regards,
Marek Vasut
params;
> +
> + memcpy(&sfdp_params, params, sizeof(sfdp_params));
> + if (spi_nor_parse_sfdp(nor, &sfdp_params)) {
> + nor->addr_width = 0;
> + nor->mtd.erasesize = 0;
> + } else {
> + memcpy(params, &sfdp_params, sizeof(*params));
> + }
> + }
> +
> return 0;
> }
>
> @@ -1757,6 +2337,10 @@ static int spi_nor_select_erase(struct spi_nor *nor,
> {
> struct mtd_info *mtd = &nor->mtd;
>
> + /* Do nothing if already configured from SFDP. */
> + if (mtd->erasesize)
> + return 0;
> +
> #ifdef CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
> /* prefer "small sector" erase if possible */
> if (info->flags & SECT_4K) {
> @@ -1989,9 +2573,11 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> if (ret)
> return ret;
>
> - if (info->addr_width)
> + if (nor->addr_width) {
> + /* already configured by spi_nor_setup() */
> + } else if (info->addr_width) {
> nor->addr_width = info->addr_width;
> - else if (mtd->size > 0x100) {
> + } else if (mtd->size > 0x100) {
> /* enable 4-byte addressing if the device exceeds 16MiB */
> nor->addr_width = 4;
> if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 55faa2f07cca..0df3638ff0b8 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -41,6 +41,8 @@
> #define SPINOR_OP_WREN 0x06/* Write enable */
> #define SPINOR_OP_RDSR 0x05/* Read status register */
> #define SPINOR_OP_WRSR 0x01/* Write status register 1 byte
> */
> +#define SPINOR_OP_RDSR2 0x3f/* Read status register 2 */
> +#define SPINOR_OP_WRSR2 0x3e/* Write status register 2 */
> #define SPINOR_OP_READ 0x03/* Read data bytes (low
> frequency) */
> #define SPINOR_OP_READ_FAST 0x0b/* Read data bytes (high frequency) */
> #define SPINOR_OP_READ_1_1_2 0x3b/* Read data bytes (Dual Output SPI) */
> @@ -56,6 +58,7 @@
> #define SPINOR_OP_CHIP_ERASE 0xc7/* Erase whole flash chip */
> #define SPINOR_OP_SE 0xd8/* Sector erase (usually 64KiB) */
> #define SPINOR_OP_RDID 0x9f/* Read JEDEC ID */
> +#define SPINOR_OP_RDSFDP 0x5a/* Read SFDP */
> #define SPINOR_OP_RDCR 0x35/* Read configuration register
> */
> #define SPINOR_OP_RDFSR 0x70/* Read flag status register */
>
> @@ -128,6 +131,9 @@
> /* Configuration Register bits. */
> #define CR_QUAD_EN_SPAN BIT(1) /* Spansion Quad I/O */
>
> +/* Status Register 2 bits. */
> +#define SR2_QUAD_EN_BIT7 BIT(7)
> +
> /* Supported SPI protocols */
> #define SNOR_PROTO_INST_MASK GENMASK(23, 16)
> #define SNOR_PROTO_INST_SHIFT16
>
--
Best regards,
Marek Vasut
On 07/03/2017 01:55 PM, Lee Jones wrote:
> On Tue, 27 Jun 2017, Marek Vasut wrote:
>
>> On 05/02/2017 02:18 PM, Marek Vasut wrote:
>>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
>>> entry. The MFD part only specifies the regmap bits for the
On 07/03/2017 03:48 PM, Lee Jones wrote:
> On Mon, 03 Jul 2017, Marek Vasut wrote:
>
>> On 07/03/2017 01:55 PM, Lee Jones wrote:
>>> On Tue, 27 Jun 2017, Marek Vasut wrote:
>>>
>>>> On 05/02/2017 02:18 PM, Marek Vasut wrote:
>>>>>
801 - 900 of 910 matches
Mail list logo
