hould 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 <cyrille.pitc...@wedev4u.fr>
Acked-by: Mar
pci_device_id intel_spi_pci_ids[] = {
> { PCI_VDEVICE(INTEL, 0x19e0), (unsigned long)_info },
> + { PCI_VDEVICE(INTEL, 0xa1a4), (unsigned long)_info },
> + { PCI_VDEVICE(INTEL, 0xa224), (unsigned long)_info },
> { },
> };
> MODULE_DEVICE_TABLE(pci, intel_spi_pci_ids);
>
--
Best regards,
Marek Vasut
On 10/29/2017 11:16 AM, Mika Westerberg wrote:
> On Sun, Oct 29, 2017 at 11:09:50AM +0100, Marek Vasut wrote:
>> On 10/29/2017 10:57 AM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan
>>> <sathyanarayanan.kuppusw...@linux.inte
;, INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ)
> },
>
> + /* Microchip */
> + { "25lc256", CAT25_INFO(32 * 1024, 1, 64, 2, SPI_NOR_NO_ERASE |
> SPI_NOR_NO_FR) },
> +
> /* Micron */
> { "n25q016a", INFO(0x20bb15, 0, 64 * 1024, 32, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
> },
>
--
Best regards,
Marek Vasut
; much about that.
> When reading from flash, I found that handling large messages with
> multiple hardware transactions was 50% faster than breaking the
> read down into lots of 32 byte messages.
>
> So, I won't object if this patch is forgotten. Thanks for
> your time anyway.
Nice, which hardware is that ?
--
Best regards,
Marek Vasut
On 05/09/2018 06:40 PM, Tudor Ambarus wrote:
>
> On 05/07/2018 08:14 PM, Marek Vasut wrote:
>> But indeed there are -- to my knowledge -- no flashes with interleaved
>> erase blocks. And yes, there could be improvement in erasing exactly the
>> required chunk of fla
On 05/10/2018 01:57 PM, NeilBrown wrote:
> On Thu, May 10 2018, Marek Vasut wrote:
>
>> On 05/10/2018 12:28 AM, NeilBrown wrote:
>>> On Wed, May 09 2018, Boris Brezillon wrote:
>>>
>>>> On Fri, 27 Apr 2018 16:18:05 +1000
>>>> NeilBrown <n
exactly the
required chunk of flash with a fitting opcode :)
--
Best regards,
Marek Vasut
On 05/18/2018 11:50 AM, Radu Pirea wrote:
>
>
> On 05/16/2018 04:47 PM, Marek Vasut wrote:
>> On 05/16/2018 12:05 PM, Radu Pirea wrote:
>>> On Wed, 2018-05-16 at 00:17 +0200, Marek Vasut wrote:
>>>> On 05/15/2018 06:22 PM, Radu Pirea wrote:
>>&g
On 05/16/2018 12:05 PM, Radu Pirea wrote:
> On Wed, 2018-05-16 at 00:17 +0200, Marek Vasut wrote:
>> On 05/15/2018 06:22 PM, Radu Pirea wrote:
>>> On Fri, 2018-05-04 at 20:40 +0200, Boris Brezillon wrote:
>>>> On Fri, 4 May 2018 18:54:04 +0300
>>>> R
region_start = region->offset & ~SNOR_ERASE_FLAGS_MASK;
> + region_end = region_start + region->size;
> + }
> +
> + return region;
> +}
> +
> +static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32
> len)
> +{
> + const struct spi_nor_erase_map *map = >erase_map;
> + const struct spi_nor_erase_command *cmd;
> + const struct spi_nor_erase_region *region;
> + u64 region_end;
> + int ret;
> +
> + region = spi_nor_find_erase_region(map, addr, len);
> + if (IS_ERR(region))
> + return PTR_ERR(region);
> +
> + region_end = spi_nor_region_end(region);
> +
> + while (len) {
> + cmd = spi_nor_find_best_erase_cmd(map, region, addr, len);
> + if (!cmd)
> + return -EINVAL;
What would happen if you realize mid-way that you cannot erase some
sector , do you end up with partial erase ?
[...]
--
Best regards,
Marek Vasut
t; + /* 'addr' must be aligned to the erase size. */
>>> + spi_nor_div_by_erase_size(cmd, addr, );
>
> oh, I missed the if here, this should have been confusing.
> if (rem)
> continue;
> else
> return cmd;
> The else case can be merged with the one from below.
>
> Returning to your previous question. I iterate from the biggest erase
> command to the smallest, because bigger is preferred, it will minimize
> the amount of erase() calls. The biggest erase command that doesn't
> erase more that what the user has asked for, will do. If the region is
> not-overlaid the address must also be aligned with the erase size.
You can have a flash with 4k sectors which also supports 64k erase and
try to erase ie. 128k at offset +4k. That means you need to first erase
small chunks, then big chunk, then small chunks again. So I don't think
you can start with large chunk to see if you can erase it, since on such
a setup the erase will degrade to massive amount of 4k erase ops.
[...]
>>> + while (len) {
>>> + cmd = spi_nor_find_best_erase_cmd(map, region, addr, len);
>>> + if (!cmd)
>>> + return -EINVAL;
>>
>> What would happen if you realize mid-way that you cannot erase some
>> sector , do you end up with partial erase ?
>
> Is this possible? In non-overlaid regions, the address is aligned with
> at least one of the erase commands, else -EINVAL. For overlaid regions
> alignment doesn't matter. But yes, if this is possible, in this case,
> this proposal will do a partial erase.
Shouldn't we fail up front instead ?
--
Best regards,
Marek Vasut
The DA9063L does not contain RTC block, unlike the full DA9063.
Do not allow binding RTC driver on this variant of the chip.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc
.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc: Mark Brown <broo...@kernel.org>
Cc: Steve Twiss <stwiss.opensou...@diasemi.com>
Cc: Wolfram Sang <wsa+rene...@sang-e
e using DT or otherwise.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc: Mark Brown <broo...@kernel.org>
Cc: Steve Twiss <stwiss.opensou...@diasemi.com>
Cc: Wolfram Sa
Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc: Mark Brown <broo...@
On 05/22/2018 07:01 AM, Tudor Ambarus wrote:
> Hi, Marek,
Hi!
> On 05/21/2018 07:59 PM, Marek Vasut wrote:
>> On 05/21/2018 06:42 PM, Tudor Ambarus wrote:
>>> Hi, Marek,
>>
>> [...]
>>
>>>>> This is a transitional patch: non-uniform eras
Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee J
Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.
Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc: Mark Brown <broo...@
On 05/23/2018 01:55 PM, Geert Uytterhoeven wrote:
> On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.va...@gmail.com> wrote:
>> The model number stored in the struct da9063 is the same for all
>> variants of the da9063 since it is the chip ID, which is always
us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
> for-mfd-next
> confi
On 05/24/2018 02:32 PM, Steve Twiss wrote:
> Hi Marek,
>
> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>
>> To: Marek Vasut <marek.va...@gmail.com>; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut <marek.vasut+rene...@gmail.com>; Geert Uytterhoeven
>> &l
On 05/18/2018 03:00 PM, Radu Pirea wrote:
>
>
> On 05/18/2018 01:03 PM, Marek Vasut wrote:
>> On 05/18/2018 11:50 AM, Radu Pirea wrote:
>>>
>>>
>>> On 05/16/2018 04:47 PM, Marek Vasut wrote:
>>>> On 05/16/2018 12:05 PM, Radu Pirea wrote:
>
ework
> I added here 25lc256.
I think I must be reading the wrong datasheet, but can you show me how
does it support things like READID opcode ?
--
Best regards,
Marek Vasut
On 05/23/2018 02:52 PM, Tudor Ambarus wrote:
> Hi, Marek,
Hi,
> On 05/23/2018 12:56 PM, Marek Vasut wrote:
> [...]
>>>> [...]
>>>>
>>>>>>> + while (len) {
>>>>>>> + cmd = spi_nor_find_best_erase_cmd(map, region,
qspi_dt_ids[] = {
>> { .compatible = "atmel,sama5d2-qspi" },
>> @@ -749,6 +769,7 @@ static struct platform_driver atmel_qspi_driver = {
>> .driver = {
>> .name = "atmel_qspi",
>> .of_match_table = atmel_qspi_dt_ids,
>> +.pm = _qspi_pm_ops,
>> },
>> .probe = atmel_qspi_probe,
>> .remove = atmel_qspi_remove,
--
Best regards,
Marek Vasut
On 06/18/2018 02:00 PM, Claudiu Beznea wrote:
>
>
> On 18.06.2018 12:53, Marek Vasut wrote:
>> On 06/18/2018 11:49 AM, Boris Brezillon wrote:
>>> Hi Claudiu,
>>>
>>> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
>&
Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux
The DA9063L does not have an RTC. Add custom regmap for DA9063L to
prevent access into that register block.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-for-MFD-by: Lee Jones
Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-by: Mark Brown
Reviewed
The DA9063L does not contain RTC block, unlike the full DA9063.
Split the RTC block into separate mfd cell and register it only
on DA9063.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Replace DA9063_NUM_IRQ macro which is not used anywhere with
plain ARRAY_SIZE().
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
Use PLATFORM_DEVID_NONE instead of -1 in mfd_add_devices.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
---
V4: New patch
V5
The DA9063L does not have an RTC. Add custom IRQ map for DA9063L to
ignore the Alarm and Tick IRQs from the PMIC.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-for-MFD-by: Lee Jones
Convert the regmap_irq table to use REGMAP_IRQ_REG().
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-by: Steve Twiss
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
---
V2: Drop useless cast of id->driver_data
V3: Fix ker
Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Geert Uytterhoeven
Convert the regmap_range tables to use regmap_reg_range() macro.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
---
V5: New
e using DT or otherwise.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc: linux-renesas-...@vger.kernel.org
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
Acked-for-MFD-by: Lee Jones
Acked-by: Steve Twiss
---
V2: No
Use devm_regmap_add_irq_chip() instead of plain regmap_add_irq_chip(),
which removes the need for da9063_irq_exit() altogether and also
fixes a bug in da9063_device_init() where the da9063_irq_exit() was
not called in a failpath.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Use devm_mfd_add_devices() instead of plain mfd_add_devices(), which
removes the need for da9063_device_exit() altogether and also for the
.remove callback in da9063-i2c.c .
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Lee Jones
Cc: Mark Brown
Cc: Steve Twiss
Cc: Wolfram Sang
Cc
On 05/29/2018 09:46 AM, Lee Jones wrote:
> On Thu, 24 May 2018, Marek Vasut wrote:
>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>
> [...]
>
>>> static const struct regmap_irq da9063l_irqs[] =
On 05/24/2018 07:30 PM, Steve Twiss wrote:
> On 24 May 2018 15:51 Marek Vasut wrote:
>
> Hi Marek,
>
>> To: Steve Twiss ; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut ; Geert Uytterhoeven
>> ; Lee Jones ; Mark Brown
>> ; Wolfram Sang ;
>> linux-
On 05/31/2018 08:52 PM, Steve Longerbeam wrote:
>
>
> On 05/31/2018 11:35 AM, Marek Vasut wrote:
>> On 05/31/2018 08:32 PM, Steve Longerbeam wrote:
>>> Hi Marek,
>>>
>>>
>>> On 05/31/2018 11:25 AM, Marek Vasut wrote:
>>>> On 05/3
6 +509,10 @@ static long vc5_fod_round_rate(struct clk_hw *hw,
> unsigned long rate,
> u32 div_int;
> u64 div_frc;
>
> + /* prevent div-by-0 */
> + if (rate == 0)
> + return 0;
> +
> /* Determine integer part, which is 12 bit wide */
> div_int = f_in / rate;
> /*
>
Can this actually happen ?
--
Best regards,
Marek Vasut
On 05/31/2018 08:32 PM, Steve Longerbeam wrote:
> Hi Marek,
>
>
> On 05/31/2018 11:25 AM, Marek Vasut wrote:
>> On 05/31/2018 08:23 PM, Steve Longerbeam wrote:
>>> Just return zero for a rounded rate if requested rate is zero.
>>>
>>> This was caught
On 06/01/2018 03:46 AM, Steve Longerbeam wrote:
>
>
> On 05/31/2018 12:37 PM, Marek Vasut wrote:
>> On 05/31/2018 08:52 PM, Steve Longerbeam wrote:
>>>
>>> On 05/31/2018 11:35 AM, Marek Vasut wrote:
>>>> On 05/31/2018 08:32 PM, Steve Longerbeam wrot
On 06/04/2018 09:39 AM, Geert Uytterhoeven wrote:
> Hi Marek, Steve,
>
> On Sat, Jun 2, 2018 at 12:11 PM, Marek Vasut wrote:
>> While the datasheet for DA9063L (2v1, 23-Mar-2017) lists the RTC register
>> block, the DA9063L does not have an RTC. Add custom regmap for DA9063L
-mask = <0x>;
> - clocks = <_clk>;
> + clocks = <_clk>, <_x_clk>;
> + clock-names = "nand", "nand_x";
> status = "disabled";
> };
>
>
--
Best regards,
Marek Vasut
On 06/20/2018 07:27 AM, Richard Weinberger wrote:
> Marek,
>
> Am Mittwoch, 20. Juni 2018, 06:52:09 CEST schrieb Marek Vasut:
>> On 06/19/2018 02:07 PM, Richard Weinberger wrote:
>>> The denali NAND flash controller needs at least two clocks to operate,
>>> n
Add support for direct
> access mode")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vignesh R
Reviewed-by: Marek Vasut
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/c
be the case on correct designs, deasserting
the PGOOD signal will lead to system reset or shutdown, which is not
the expected behavior when changing PMIC buck converter voltage.
Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
Cc: Mark
?: ahash_def_finup;
> hash->digest = alg->digest;
> + hash->export = alg->export;
> + hash->import = alg->import;
>
> if (alg->setkey) {
> hash->setkey = alg->setkey;
> hash->has_setkey = true;
> }
> - if (alg->export)
> - hash->export = alg->export;
> - if (alg->import)
> - hash->import = alg->import;
>
> return 0;
> }
>
--
Best regards,
Marek Vasut
= {
> @@ -853,6 +865,8 @@ static struct ahash_alg dcp_sha256_alg = {
> .final = dcp_sha_final,
> .finup = dcp_sha_finup,
> .digest = dcp_sha_digest,
> + .import = dcp_sha_noimport,
> + .export = dcp_sha_noexport,
> .halg = {
> .digestsize = SHA256_DIGEST_SIZE,
> .base = {
>
--
Best regards,
Marek Vasut
On 01/19/2018 10:53 AM, Kamil Konieczny wrote:
> On 18.01.2018 22:31, Marek Vasut wrote:
>> On 01/18/2018 07:34 PM, Kamil Konieczny wrote:
>>> Export and import are mandatory in async hash. As drivers were
>>> rewritten, drop empty wrappers and correct init of ahash tr
ending register, the
>> driver had read.
>>
>> Signed-off-by: Heiko Schocher <h...@denx.de>
>> Reviewed-by: Marek Vasut <ma...@denx.de>
>
> 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,
>>
Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
> Cc: Marek Vasut <ma...@denx.de>
Reviewed-by: Marek Vasut <ma...@denx.de>
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 54
> ---
> 1 file changed, 28 insertions(+)
t; *skb,
> if (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 comm
..
>
> 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 <
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:
g 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:
!(ret & mask)) {
> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
> + return 0;
Is the dev_info() really needed ?
> + } else {
> + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
> + return -EINVAL;
> + }
> +}
[...]
--
Best regards,
Marek Vasut
mcr p15, 0, r0, c1, c0, 1
> +#endif
> __v7_ca17mp_setup:
> - mov r10, #0
> +2: mov r10, #0
> 1: adr r0, __v7_setup_stack_ptr
> ldr r12, [r0]
> add r12, r12, r0@ the local stack
>
--
Best regards,
Marek Vasut
;>> + return val;
>>> + if (!(val & mask))
>>> + return 0;
>>> +
>>> + write_enable(nor);
>>> +
>>> + write_sr(nor, val & ~mask);
>>> +
>>> + ret = spi_nor_wait_till_ready(nor);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = read_sr(nor);
>>> + if (ret > 0 && !(ret & mask)) {
>>> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
>>> + return 0;
>>
>> Is the dev_info() really needed ?
>
> Nope. I'll spin a v2 pending the above discussion.
>
>>> + } else {
>>> + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
>>> + return -EINVAL;
>>> + }
>>> +}
>>
>> [...]
>
> Thanks!
--
Best regards,
Marek Vasut
t;> + * @nor: pointer to a 'struct spi_nor'
>>>>> + *
>>>>> + * Bits [2345] of the Status Register are BP[0123].
>>>>> + * ISSI chips use a different block protection scheme than other
>>>>> chips.
>>>>> + * Just disable the write-protect unilaterally.
>>>>> + *
>>>>> + * Return: 0 on success, -errno otherwise.
>>>>> + */
>>>>> +static int issi_unlock(struct spi_nor *nor)
>>>>> +{
>>>>> + int ret, val;
>>>>> + u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3;
>>>>> +
>>>>> + val = read_sr(nor);
>>>>> + if (val < 0)
>>>>> + return val;
>>>>> + if (!(val & mask))
>>>>> + return 0;
>>>>> +
>>>>> + write_enable(nor);
>>>>> +
>>>>> + write_sr(nor, val & ~mask);
>>>>> +
>>>>> + ret = spi_nor_wait_till_ready(nor);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + ret = read_sr(nor);
>>>>> + if (ret > 0 && !(ret & mask)) {
>>>>> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
>>>>> + return 0;
>>>>
>>>> Is the dev_info() really needed ?
>>>
>>> Nope. I'll spin a v2 pending the above discussion.
>>>
>>>>> + } else {
>>>>> + dev_err(nor->dev, "ISSI Block Protection Bits not
>>>>> cleared\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +}
>>>>
>>>> [...]
>>>
>>> Thanks!
--
Best regards,
Marek Vasut
le = "samtec,vining", "altr,socfpga-cyclone5", "altr,socfpga";
>
> chosen {
> - bootargs = "console=ttyS0,115200";
> + bootargs = "earlyprintk";
Why this earlyprintk ?
> + stdout-path = "serial0:115200n8";
> };
>
> memory@0 {
>
--
Best regards,
Marek Vasut
On 08/08/2018 02:02 PM, Simon Goldschmidt wrote:
> On Wed, Aug 8, 2018 at 1:32 PM Marek Vasut wrote:
>>
>> On 08/08/2018 11:09 AM, Simon Goldschmidt wrote:
>>> Use stdout-path dts property for kernel console.
>>>
>>> There were two socfpga board
On 08/11/2018 03:58 PM, Marek Vasut wrote:
> On 06/08/2018 12:58 AM, Florian Fainelli wrote:
>> Per the ARM reference manual for the Cortex-A15, The ACTLR:
>>
>> Is a read/write register.
>>
>> Common to the Secure and Non-secure states.
>>
>> Is on
On 09/10/2018 12:18 PM, Tudor Ambarus wrote:
> Marek,
Hi,
> On 09/07/2018 11:31 PM, Marek Vasut wrote:
>> On 09/07/2018 10:51 AM, Tudor Ambarus wrote:
>>> Thanks Marek,
>>>
>>> On 09/03/2018 08:37 PM, Marek Vasut wrote:
>>&
samples. Moreover, when I check the
PMU interrupts, "grep pmu /proc/interrupts", it shows 0 interrupts from
the ARM PMU all the time.
Why am I not getting any PMU interrupts when using perf ?
--
Best regards,
Marek Vasut
as apparently intended, and with
> them the entries in the da90630_matches[] array.
>
> Fixes: 1c892e38ce59 ("regulator: da9063: Handle less LDOs on DA9063L")
> Signed-off-by: Philipp Zabel
> Cc: Marek Vasut
> Cc: Mark Brown
> Cc: Geert Uytterhoeven
> Cc: Lee Jon
On 09/07/2018 10:51 AM, Tudor Ambarus wrote:
> Thanks Marek,
>
> On 09/03/2018 08:37 PM, Marek Vasut wrote:
>> On 08/27/2018 12:26 PM, Tudor Ambarus wrote:
>> [...]
>>
>>> +/* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
>>> +sta
se you could share sunxi_reset_init if you pass it a struct
> reset_simple_devdata as an argument.
>
> regards
> Philipp
>
--
Best regards,
Marek Vasut
;
> Signed-off-by: Vignesh R <vigne...@ti.com>
Reviewed-by: Marek Vasut <marek.va...@gmail.com>
--
Best regards,
Marek Vasut
*/
> +#define SPINOR_OP_RDXA 0xc8/* Read Extended Address
> Register */
> +#define SPINOR_OP_WRXA 0xc5/* Write Extended Address
> Register */
>
> /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
> #define SPINOR_OP_READ_4B0x13/* Read data bytes (low frequency) */
>
--
Best regards,
Marek Vasut
On 04/10/2018 03:26 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut <marek.va...@gmail.com> wrote:
>> On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
>>> Currently add_mtd_device() failures are plainly ignored, which
ne SPINOR_OP_CLFSR 0x50/* Clear flag status register */
> +#define SPINOR_OP_RDXA 0xc8/* Read Extended Address
> Register */
> +#define SPINOR_OP_WRXA 0xc5/* Write Extended Address
> Register */
>
> /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
> #define SPINOR_OP_READ_4B0x13/* Read data bytes (low frequency) */
>
--
Best regards,
Marek Vasut
the conditions a
bit, maybe even pull it into separate function with some sensible name),
sorry for the noise.
I had to read up the datasheet and the discussion again, the behavior of
the flash is horrid.
[...]
--
Best regards,
Marek Vasut
On 04/11/2018 05:17 PM, Thor Thayer wrote:
> Hi. Any comments on this patch?
None other than
Reviewed-by: Marek Vasut <marek.va...@gmail.com>
sorry for the delay.
btw stop top-posting please.
> On 03/26/2018 09:12 AM, thor.tha...@linux.intel.com wrote:
>> From: Tho
e(>mtd);
> + ret = add_mtd_device(>mtd);
> + if (ret) {
> + mutex_lock(_partitions_mutex);
> + list_del(>list);
> + mutex_unlock(_partitions_mutex);
> + free_partition(slave);
> + continue;
> + }
Why is the partition even in the list in the first place ? Can we avoid
adding it rather than adding and removing it ?
> mtd_add_partition_attrs(slave);
> if (parts[i].types)
> mtd_parse_part(slave, parts[i].types);
>
--
Best regards,
Marek Vasut
here is no need to calculate
> the tolerance because PM divisor alone is enough to get the ratio.
>
> So a simple fix could be just to set PM directly instead of going
> into the loop-search.
>
> Reported-by: Marek Vasut <ma...@denx.de>
> Signed-off-by: Nicolin Chen <nicoleots..
On 04/08/2018 11:56 PM, NeilBrown wrote:
> On Sun, Apr 08 2018, Marek Vasut wrote:
>
>> On 04/08/2018 09:04 AM, NeilBrown wrote:
>>>
>>> According to section
>>>8.2.7 Write Extended Address Register (C5h)
>>>
>>> of the Winbond W25Q256F
shutdown, but didn't
> achieve the goal for all spi-nor chips. So this patch can be seen as
> fixing that one.
>
> Fixes: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when
> exiting")
> Cc: sta...@vger.kernel.org (v4.16)
> Signed-off-by
NTAINERS b/MAINTAINERS
> index 3bdc260e36b7..7892db9a9494 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9037,7 +9037,6 @@ M: Brian Norris <computersforpe...@gmail.com>
> M: Boris Brezillon <boris.brezil...@free-electrons.com>
> M: Marek Vasut <marek.va
On 03/18/2018 06:14 PM, Cyrille Pitchen wrote:
> Hi Marek,
Hi,
> Le 18/03/2018 à 00:41, Marek Vasut a écrit :
>> On 03/15/2018 08:04 PM, Cyrille Pitchen wrote:
>>> remove myself as MTD and SPI NOR maintainer.
>>>
>>> Signed-off-by: Cyrille Pitchen <cyril
code above where you always
check for trailing bytes can make the next read cycle do ioreaad32 into
unaligned memory address and thus cause slowdown. (consider the example
where the controller first reports it has 5 bytes ready, then reports it
has 7 bytes ready. If you read 4 bytes in the first cycle, wait a bit
and then check how much data the controller has in the next cycle, it
will be 8 bytes, all nicely aligned).
Does it make sense ?
--
Best regards,
Marek Vasut
On 09/29/2018 12:01 AM, Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
> 12496 RENESAS R-CAR GYROADC DRIVER
> 12497 M: Marek Vasut
> 12498 L: linux-...@vger.kernel.org
> 1
>> This patch is needed for systems where the bootloader has left the timer
>>>> not used in reset.
>>>>
>>>> - Trivial conflict with commit a74bd1ad7a:
>>>> "Convert to using %pOFn instead of device_node.name"
>>>&g
gt;offset & SNOR_LAST_REGION)
> +
> +static inline u64 spi_nor_region_end(const struct spi_nor_erase_region
> *region)
Get rid of the inlines, really.
> +{
> + return (region->offset & ~SNOR_ERASE_FLAGS_MASK) + region->size;
> +}
> +
> +static inline bool spi_nor_has_uniform_erase(const struct spi_nor *nor)
> +{
> + return !!nor->erase_map.uniform_erase_type;
> +}
> +
> static inline void spi_nor_set_flash_node(struct spi_nor *nor,
> struct device_node *np)
> {
>
General question, what happens if the multi-block erase fails mid-way ,
is that handled or reported somehow to the user ?
--
Best regards,
Marek Vasut
ruct spi_nor_erase_region *region;
> + u64 offset;
> + u32 region_count;
> + int i, j;
> + u8 erase_type;
> +
> + region_count = SMPT_MAP_REGION_COUNT(*smpt);
> + region = devm_kcalloc(nor->dev, region_count, sizeof(*region),
> + GFP_KERNEL);
Is this memory always correctly free'd ?
--
Best regards,
Marek Vasut
On 12/05/2018 07:56 PM, Sergei Shtylyov wrote:
> On 12/04/2018 09:19 PM, Marek Vasut wrote:
>
>>> Document the bindings used by the Renesas R-Car Gen3 RPC SPI controller.
>>
>> RPC is SPI and HF controller, it is not a pure SPI controller.
>>
>> How does th
[...]
>> +#define RPC_CMNCR 0x /* R/W */
>> +#define RPC_CMNCR_MDBIT(31)
>> +#define RPC_CMNCR_SFDE BIT(24)
>
>This bit is undocumented as of the gen3 manual v1.0. I'd like this to be
> reflected
> in a comment...
FYI, not even in v1.50 .
--
Best regards,
Marek Vasut
On 11/19/2018 04:21 PM, Boris Brezillon wrote:
> On Mon, 19 Nov 2018 16:12:41 +0100
> Marek Vasut wrote:
>
>> On 11/19/2018 03:43 PM, Boris Brezillon wrote:
>>> On Mon, 19 Nov 2018 15:14:07 +0100
>>> Marek Vasut wrote:
>>>
>>>> On 11/1
";
> + clocks = < CPG_MOD 917>;
> + clock-names = "clk_rpc";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
> + };
> + };
>
--
Best regards,
Marek Vasut
ster = spi_alloc_master(>dev, sizeof(struct rpc_spi));
> + if (!master)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, master);
> +
> + rpc = spi_master_get_devdata(master);
> +
> + master->dev.of_node = pdev->dev.of_node;
> +
> + rpc->clk_rpc = devm_clk_get(>dev, "clk_rpc");
> + if (IS_ERR(rpc->clk_rpc))
> + return PTR_ERR(rpc->clk_rpc);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rpc_regs");
> + rpc->regs = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(rpc->regs))
> + return PTR_ERR(rpc->regs);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
> + rpc->linear.map = devm_ioremap_resource(>dev, res);
> + if (!IS_ERR(rpc->linear.map)) {
> + rpc->linear.dma = res->start;
> + rpc->linear.size = resource_size(res);
> + } else {
> + rpc->linear.map = NULL;
> + }
> +
> + pm_runtime_enable(>dev);
> + master->auto_runtime_pm = true;
> +
> + master->num_chipselect = 1;
> + master->mem_ops = _spi_mem_ops;
> + master->transfer_one_message = rpc_spi_transfer_one_message;
> +
> + master->bits_per_word_mask = SPI_BPW_MASK(8);
> + master->mode_bits = SPI_CPOL | SPI_CPHA |
> + SPI_RX_DUAL | SPI_TX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD;
> +
> + rpc_spi_hw_init(rpc);
> +
> + ret = spi_register_master(master);
> + if (ret) {
> + dev_err(>dev, "spi_register_master failed\n");
> + goto err_put_master;
> + }
> + return 0;
> +
> +err_put_master:
> + spi_master_put(master);
> + pm_runtime_disable(>dev);
> +
> + return ret;
> +}
> +
> +static int rpc_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + spi_unregister_master(master);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id rpc_spi_of_ids[] = {
> + { .compatible = "renesas,rpc-r8a77995", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rpc_spi_of_ids);
> +
> +static struct platform_driver rpc_spi_driver = {
> + .probe = rpc_spi_probe,
> + .remove = rpc_spi_remove,
> + .driver = {
> + .name = "rpc-spi",
> + .of_match_table = rpc_spi_of_ids,
> + .pm = _spi_dev_pm_ops,
> + },
> +};
> +module_platform_driver(rpc_spi_driver);
> +
> +MODULE_AUTHOR("Mason Yang ");
> +MODULE_DESCRIPTION("Renesas R-Car D3 RPC SPI controller driver");
This is not D3 specific and not SPI-only controller btw.
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Marek Vasut
On 11/19/2018 03:10 PM, Boris Brezillon wrote:
> On Mon, 19 Nov 2018 14:49:31 +0100
> Marek Vasut wrote:
>
>> On 11/19/2018 11:01 AM, Mason Yang wrote:
>>> Document the bindings used by the Renesas R-Car D3 RPC controller.
>>>
>>> Signed-off-by: Mason
On 11/19/2018 03:43 PM, Boris Brezillon wrote:
> On Mon, 19 Nov 2018 15:14:07 +0100
> Marek Vasut wrote:
>
>> On 11/19/2018 03:10 PM, Boris Brezillon wrote:
>>> On Mon, 19 Nov 2018 14:49:31 +0100
>>> Marek Vasut wrote:
>>>
>>>> On 1
701 - 800 of 1712 matches
Mail list logo
