From: Frieder Schrempf
Now that we have moved the information to the chip level, let's
remove all the unused flags and fields.
Signed-off-by: Frieder Schrempf
Reviewed-by: Miquel Raynal
---
include/linux/mtd/bbm.h | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --gi
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to the chip struct,
as we did it for rawnand.
Signed-off-by: Frieder Schrempf
Reviewed-by: Miquel Ra
From: Frieder Schrempf
It is known that some ESMT SLC NANDs have been shipped
with the factory bad block markers in the first or last page
of the block, instead of the first or second page. To be on
the safe side, let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Bor
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first
From: Frieder Schrempf
According to the datasheet of some Cypress SLC NANDs, the bad
block markers can be in the first, second or last page of a block.
So let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
Reviewed-by: Miquel Raynal
---
drivers/mtd/
Please forget about this, I forgot to squash the fixes for patch 5.
I will send a new version. Sorry!
On 17.04.19 14:15, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> Currently supported bad block marker positions within the block are:
> * in first page only
> * in last p
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
After some cleanup and preparation in patches 1 to 4 we make it
possible to set NAND_BBM_FIRSTPAGE, NAND_BBM_SECONDPAGE and
NAND_BBM_LAST
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to nand_chip.options
and nand_chip.badblockpos.
As this chip-specific information is not directly rel
From: Frieder Schrempf
To be able to check and set bad block markers in the first and
second page of a block independently of each other, we create
separate flags for both cases.
Previously NAND_BBM_SECONDPAGE meant, that both, the first and the
second page were used. With this patch NAND_BBM_FI
From: Frieder Schrempf
According to the datasheet of some Cypress SLC NANDs, the bad
block markers can be in the first, second or last page of a block.
So let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
Reviewed-by: Miquel Raynal
---
drivers/mtd/
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first
From: Frieder Schrempf
Now that we have moved the information to the chip level, let's
remove all the unused flags and fields.
Signed-off-by: Frieder Schrempf
Reviewed-by: Miquel Raynal
---
include/linux/mtd/bbm.h | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --gi
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to the chip struct,
as we did it for rawnand.
Signed-off-by: Frieder Schrempf
Reviewed-by: Miquel Ra
From: Frieder Schrempf
It is known that some ESMT SLC NANDs have been shipped
with the factory bad block markers in the first or last page
of the block, instead of the first or second page. To be on
the safe side, let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Bor
From: Frieder Schrempf
By default the PCA9450 doesn't handle the assertion of the WDOG_B
signal, but this is required to guarantee that things like software
resets triggered by the watchdog work reliably.
As we don't want to rely on the bootloader to enable this, we tell
the PMIC to issue a cold
From: Frieder Schrempf
Add the binding documentation for the optional sd-vsel GPIO.
Signed-off-by: Frieder Schrempf
---
.../devicetree/bindings/regulator/nxp,pca9450-regulator.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/regulator/nxp,pca9450
From: Frieder Schrempf
LDO5 has two separate control registers. LDO5CTRL_L is used if the
input signal SD_VSEL is low and LDO5CTRL_H if it is high.
The current driver implementation only uses LDO5CTRL_H. To make this
work on boards that have SD_VSEL connected to a GPIO, we add support
for specify
From: Frieder Schrempf
The driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to set the
voltage for the buck regulators 1, 2 and 3. This has no effect as the
PRESET_EN bit is set by default. This causes the preset values to be
used instead, which are set to 850 mV by default.
To fix this w
From: Frieder Schrempf
The driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to set the
voltage for the buck regulators 1, 2 and 3. This has no effect as the
PRESET_EN bit is set by default and therefore the preset values are used
instead, which are set to 850 mV.
To fix this we clear the
From: Frieder Schrempf
This fixes the return value of pca9450_i2c_probe() to use the correct
error code when getting the sd-vsel GPIO fails.
Signed-off-by: Frieder Schrempf
---
drivers/regulator/pca9450-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/reg
From: Frieder Schrempf
There are other NXP NCI compatible NFC controllers such as the PN7150
that use an integrated firmware and therefore do not have a GPIO to
select firmware downloading mode. To support these kind of chips,
let's make the firmware GPIO optional.
Signed-off-by: Frieder Schremp
From: Frieder Schrempf
There are other NXP NCI compatible NFC controllers such as the PN7150
that use an integrated firmware and therefore do not have a GPIO to
select firmware downloading mode. To support these kind of chips,
let's make the firmware GPIO optional.
Signed-off-by: Frieder Schremp
From: Frieder Schrempf
There are other NXP NCI compatible NFC controllers such as the PN7150
that use an integrated firmware and therefore do not have a GPIO to
select firmware downloading mode. To support this kind of controller,
let's make the firmware GPIO optional.
Signed-off-by: Frieder Sch
Make the driver accept different volume levels via sysfs.
This can be helpful if the beep/bell sound intensity needs
to be adapted to the environment of the device.
The number of volume levels available and their values can
be specified via device tree (similar to pwm-backlight).
This patch was t
From: Frieder Schrempf
After switching to the new FSL QSPI driver the properties
'fsl,qspi-has-second-chip' and 'big-endian' are not used anymore.
The driver now uses the 'reg' property to determine the bus and
the chipselect. The endianness is selected by the driver depending
on which SoC is us
From: Frieder Schrempf
After switching to the new FSL QSPI driver the properties
'fsl,qspi-has-second-chip' and 'big-endian' are not used anymore.
The driver now uses the 'reg' property to determine the bus and
the chipselect. The endianness is selected by the driver depending
on which SoC is us
On 26.08.19 14:40, Boris Brezillon wrote:
> On Mon, 26 Aug 2019 12:08:58 +
> wrote:
>
>> From: Tudor Ambarus
>>
>> nor->params.setup() configures the SPI NOR memory. Useful for SPI NOR
>> flashes that have peculiarities to the SPI NOR standard, e.g.
>> different opcodes, specific address cal
On 26.08.19 16:02, Boris Brezillon wrote:
> On Mon, 26 Aug 2019 13:38:48 +
> Schrempf Frieder wrote:
>
>> On 26.08.19 14:40, Boris Brezillon wrote:
>>> On Mon, 26 Aug 2019 12:08:58 +
>>> wrote:
>>>
>>>> From: Tudor Ambarus
>&
From: Frieder Schrempf
Later versions of the QSPI controller (e.g. in i.MX6UL/ULL and i.MX7)
seem to have an additional TDH setting in the FLSHCR register, that
needs to be set in accordance with the access mode that is used (DDR
or SDR).
Previous bootstages such as BootROM or bootloader might h
Hi Anson,
I have a question, that is not directly related to this patch.
I see that for the usdhc1 and usdhc3 nodes, there is an 'assigned-clock'
and 'assigned-clock-rates' property but not for usdhc2. The same applies
to the mx8mq and mx8mn dtsi file.
Is there any reason for this? If not can y
Hi,
I wonder why imx8mq.dtsi, imx8mm.dtsi and imx8mn.dtsi have
'assigned-clocks' and 'assigned-clock-rates' set for all usdhc nodes,
except for usdhc2.
Is this on purpose? Is it a flaw?
Thanks,
Frieder
Extract from imx8mm.dtsi:
usdhc1: mmc@30b4 {
[...]
assigned-clocks = <
Hi Anson,
On 19.09.19 11:31, Anson Huang wrote:
> Hi, Schrempf
>
>> Hi Anson,
>>
>> I have a question, that is not directly related to this patch.
>> I see that for the usdhc1 and usdhc3 nodes, there is an 'assigned-clock'
>> and 'assigned-clock-rates' property but not for usdhc2. The same applie
On 19.09.19 14:58, Miquel Raynal wrote:
> Hi Piotr,
>
> Piotr Sroka wrote on Thu, 19 Sep 2019 13:41:35
> +0100:
>
>> Change calculating of position page containing BBM
>>
>> If none of BBM flags is set then function nand_bbm_get_next_page
>> reports EINVAL. It causes that BBM is not read at all
On 19.09.19 15:18, Miquel Raynal wrote:
> Hello,
>
> Schrempf Frieder wrote on Thu, 19 Sep
> 2019 13:15:08 +:
>
>> On 19.09.19 14:58, Miquel Raynal wrote:
>>> Hi Piotr,
>>>
>>> Piotr Sroka wrote on Thu, 19 Sep 2019 13:41:35
>>>
Hi Robin,
> From: Robin Gong
>
> Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
> check ignore such special case without dma channel enabled, which caused
> ecspi1 rx works failed. Actually, no need to check event_id0/event_id1
> and replace checking 'event_id1' with 'DMA_D
On 25.09.19 13:26, Robin Gong wrote:
> On 2019-9-24 21:28 Schrempf Frieder wrote:
>>
>> Hi Robin,
>>
>>> From: Robin Gong
>>>
>>> Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
>>> check ignore such special case wi
On 16.07.19 09:50, Krzysztof Kozlowski wrote:
> On Fri, 12 Jul 2019 at 17:21, Schrempf Frieder
> wrote:
>>
>> Hi Krzysztof,
>>
>> On 12.07.19 16:12, Krzysztof Kozlowski wrote:
>>> Add support for iMX6-UL2 modules from Kontron Electronics GmbH (before
&
Hi Krzysztof,
On 12.07.19 16:12, Krzysztof Kozlowski wrote:
> Add support for iMX6-UL2 modules from Kontron Electronics GmbH (before
> acquisition: Exceet Electronics) and evalkit boards based on it:
>
> 1. i.MX6 UL System-on-Module, a 25x25 mm solderable module (LGA pads and
> pin castellati
From: Frieder Schrempf
On i.MX8MM there is an interrupt getting triggered immediately after
requesting the IRQ, which leads to a stall as the handler accesses
the GPU registers whithout the clock being enabled.
Enabling the clocks briefly seems to clear the IRQ state, so we do
this before reques
From: Frieder Schrempf
This series contains patches to enable GPU support for the i.MX8MM.
There is currently no upstream support for the display subsystem of
the i.MX8MM, but I have a 5.4-based tree with some ported drivers for
LCDIF, DSIM bridge, etc. (see [1]) which I used to test the GPU with
From: Frieder Schrempf
In case enabling of the bus clock fails etnaviv_gpu_clk_enable()
returns without disabling the already enabled reg clock. Fix this.
Fixes: 65f037e8e908 ("drm/etnaviv: add support for slave interface clock")
Signed-off-by: Frieder Schrempf
---
drivers/gpu/drm/etnaviv/etna
From: Frieder Schrempf
On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
Changing the order of clock initalization to
core -> shader -> bus -> reg
fixes the issue. This is the same order used in the imx platform code
of the downstream GPU driver in the NXP kernel [1]. For the
From: Frieder Schrempf
According to the documents, the i.MX8M-Mini features a GC320 and a
GCNanoUltra GPU core. Etnaviv detects them as:
etnaviv-gpu 3800.gpu: model: GC600, revision: 4653
etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
This seems to work fine more or
On 30.04.20 16:23, Daniel Baluta wrote:
> On 4/30/20 3:46 PM, Schrempf Frieder wrote:
>> + /*
>> + * On i.MX8MM there is an interrupt getting triggered immediately
>> + * after requesting the IRQ, which leads to a stall as the handler
>> + * accesses the
Hi Lucas,
On 30.04.20 16:32, Lucas Stach wrote:
> Hi Frieder,
>
> Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
>> From: Frieder Schrempf
>>
>> On i.MX8MM there is an interrupt getting triggered immediately after
>> requesting the I
On 30.04.20 16:35, Lucas Stach wrote:
> Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
>> From: Frieder Schrempf
>>
>> On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
>> Changing the order of clock initalization to
>>
From: Frieder Schrempf
In order to support more of the i.MX6UL/ULL-based SoMs and boards by
Kontron Electronics GmbH, we restructure the devicetrees to share common
parts and add new devicetrees for the missing boards.
Currently there are the following SoM flavors:
* N6310: SoM with i.MX6UL-2,
From: Frieder Schrempf
The Kontron N6311 and N6411 SoMs are very similar to N6310. In
preparation to add support for them, we move the common nodes to a
separate file imx6ul-kontron-n6x1x-som-common.dtsi.
Signed-off-by: Frieder Schrempf
---
.../boot/dts/imx6ul-kontron-n6310-som.dtsi| 95 +
From: Frieder Schrempf
The N6311 and the N6411 SoM are similar to the Kontron N6310 SoM.
They are pin-compatible, but feature a larger RAM and NAND flash
(512MiB instead of 256MiB). Further, the N6411 has an i.MX6ULL SoC,
instead of an i.MX6UL.
Signed-off-by: Frieder Schrempf
---
.../boot/dts/
From: Frieder Schrempf
Add the compatibles for Kontron i.MX6UL N6311 SoM and boards and
the compatibles for Kontron i.MX6ULL N6411 SoM and boards.
Signed-off-by: Frieder Schrempf
---
Documentation/devicetree/bindings/arm/fsl.yaml | 14 ++
1 file changed, 14 insertions(+)
diff --gi
From: Frieder Schrempf
The Kontron N6x1x SoMs all use uart4 as a debug serial interface.
Therefore we set in the 'chosen' node.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts
From: Frieder Schrempf
The ECSPI1 is not used for a FRAM chip, so remove the comment.
While at it, also change some whitespaces to tabs to comply with the
indentation style of the rest of the file.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 13 ++---
From: Frieder Schrempf
The baseboard for the Kontron N6310 SoM is also used for other SoMs
such as N6311 and N6411. In order to share the code, we move the
definitions of the baseboard to a separate dtsi file.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts |
From: Frieder Schrempf
The 'N6311 S' and the 'N6411 S' are similar to the Kontron 'N6310 S'
evaluation kit boards. Instead of the N6310 SoM, they feature a N6311
or N6411 SoM.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6311-s.dts | 16
arch/arm/boot
From: Frieder Schrempf
Both, the SD card and the eMMC are connected to the usdhc controller
by four data lines. Therefore we set 'bus-width = <4>' for both
interfaces.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 2 ++
1 file changed, 2 insertions(+)
dif
From: Frieder Schrempf
To silence the warnings shown by the driver at boot time, we add a
fixed regulator for the 5V supply of usbotg2 and specify the polarity
of the overcurrent signal for usbotg1.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 9 +
From: Frieder Schrempf
Kontron Electronics GmbH produces several ARM boards, that are
planned to be upstreamed eventually. For now we have some
i.MX6UL/ULL based SoMs and boards, that are already available
in the kernel.
Signed-off-by: Frieder Schrempf
---
MAINTAINERS | 6 ++
1 file change
Hi Marco,
On 17.10.19 10:14, Marco Felsch wrote:
> Hi Frieder,
>
> On 19-10-16 15:06, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> In order to support more of the i.MX6UL/ULL-based SoMs and boards by
>> Kontron Electronics GmbH, we restructure the dev
Hi Marco,
On 21.10.19 13:43, Marco Felsch wrote:
> Hi Frieder,
>
> On 19-10-17 08:24, Schrempf Frieder wrote:
>> Hi Marco,
>>
>> On 17.10.19 10:14, Marco Felsch wrote:
>>> Hi Frieder,
>>>
>>> On 19-10-16 15:06, Schrempf Frieder wrote:
>
Hi Krzysztof,
On 21.10.19 12:38, k...@kernel.org wrote:
> On Wed, Oct 16, 2019 at 03:07:25PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> The baseboard for the Kontron N6310 SoM is also used for other SoMs
>> such as N6311 and N6411. In order to
On 21.10.19 12:28, k...@kernel.org wrote:
> On Wed, Oct 16, 2019 at 03:07:19PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> The Kontron N6311 and N6411 SoMs are very similar to N6310. In
>> preparation to add support for them, we move the common
Hi Tudor,
On 03.02.19 14:33, tudor.amba...@microchip.com wrote:
> Hi, Frieder,
>
> On 01/23/2019 09:56 AM, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> This adds support for the EON EN25Q80A, a 8Mb SPI NOR chip.
>
> I would suggest to specify who is
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to nand_chip.options
and nand_chip.badblockpos.
As this chip-specific information is not directly rel
From: Frieder Schrempf
It is known that some ESMT SLC NANDs have been shipped
with the factory bad block markers in the first or last page
of the block, instead of the first or second page. To be on
the safe side, let's check all three locations.
Signed-off-by: Frieder Schrempf
---
drivers/mtd
From: Frieder Schrempf
According to the datasheet of some Cypress SLC NANDs, the bad
block markers can be in the first, second or last page of a block.
So let's check all three locations.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/raw/nand_amd.c | 8 +++-
1 file changed, 7 insert
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first
On 22.01.19 12:22, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> Currently supported bad block marker positions within the block are:
> * in first page only
> * in last page only
> * in first or second page
>
> Some ESMT NANDs are known to have been shipped by the
On 22.01.19 12:22, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> The information about where the manufacturer puts the bad block
> markers inside the bad block and in the OOB data is stored in
> different places. Let's move this information to nand_chip.options
> an
On 22.01.19 14:18, Boris Brezillon wrote:
> On Tue, 22 Jan 2019 11:23:29 +
> Schrempf Frieder wrote:
>
>> From: Frieder Schrempf
>>
>> The information about where the manufacturer puts the bad block
>> markers inside the bad block and in the OOB data is sto
From: Frieder Schrempf
This adds support for the EON EN25Q80A, a 8Mb SPI NOR chip.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6e13bbd1aaa5..aa8a04293
From: Frieder Schrempf
This adds support for the Macronix MX25V8035F, a 8Mb SPI NOR chip.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index aa8a04293a25..f0
On 29.01.19 07:57, Yogesh Narayan Gaur wrote:
> Hi,
>
>> -Original Message-
>> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
>> Sent: Tuesday, January 29, 2019 7:33 AM
>> To: Mark Brown
>> Cc: Linux Next Mailing List ; Linux Kernel
>> Mailing
>> List ; Yogesh Narayan Gaur
>> ; Fr
On 29.01.19 09:31, Yogesh Narayan Gaur wrote:
> Add MODULE_LICENSE info to fix below warning:
> WARNING: modpost: missing MODULE_LICENSE() in drivers/spi/spi-nxp-fspi.o
>
> Signed-off-by: Yogesh Narayan Gaur
> ---
> drivers/spi/spi-nxp-fspi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to nand_chip.options
and nand_chip.badblockpos.
As this chip-specific information is not directly rel
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first
From: Frieder Schrempf
It is known that some ESMT SLC NANDs have been shipped
with the factory bad block markers in the first or last page
of the block, instead of the first or second page. To be on
the safe side, let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Bor
From: Frieder Schrempf
According to the datasheet of some Cypress SLC NANDs, the bad
block markers can be in the first, second or last page of a block.
So let's check all three locations.
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
---
drivers/mtd/nand/raw/nand_amd.c | 8
From: Frieder Schrempf
To be able to check and set bad block markers in the first and
second page of a block independently of each other, we create
separate flags for both cases.
Previously NAND_BBM_SECONDPAGE meant, that both, the first and the
second page were used. With this patch NAND_BBM_FI
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
After some cleanup and preparation in patch 1 and 2, we make it
possible to set NAND_BBM_FIRSTPAGE, NAND_BBM_SECONDPAGE and
NAND_BBM_LAST
Hi Boris,
Thanks for reviewing.
On 30.01.19 14:28, Boris Brezillon wrote:
> On Wed, 30 Jan 2019 13:01:44 +
> Schrempf Frieder wrote:
>
>> From: Frieder Schrempf
>>
>> The information about where the manufacturer puts the bad block
>> markers inside the
Hi Yoshio,
On 16.01.19 06:53, Yoshio Furuyama wrote:
> Add device table for Toshiba Memory products.
> Also, generalize OOB layout structure and function names.
>
> Signed-off-by: Yoshio Furuyama
>
> ---
> drivers/mtd/nand/spi/toshiba.c | 79
> +---
> 1
On 16.01.19 11:42, Frieder Schrempf wrote:
> Hi Yoshio,
>
> On 16.01.19 06:53, Yoshio Furuyama wrote:
>> Add device table for Toshiba Memory products.
>> Also, generalize OOB layout structure and function names.
>>
>> Signed-off-by: Yoshio Furuyama
>>
>> ---
>> drivers/mtd/nand/spi/toshiba.c |
On 16.01.19 06:53, Yoshio Furuyama wrote:
> Add device table for Toshiba Memory products.
> Also, generalize OOB layout structure and function names.
>
> Signed-off-by: Yoshio Furuyama
Reviewed-by: Frieder Schrempf
>
> ---
> drivers/mtd/nand/spi/toshiba.c | 79
> +
Hi Shawn,
On 13.01.19 04:31, Shawn Guo wrote:
> On Mon, Jan 07, 2019 at 09:29:54AM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> After switching to the new FSL QSPI driver the property
>> 'fsl,qspi-has-second-chip' is not needed anymor
Hi Yogesh,
On 15.01.19 10:50, Yogesh Narayan Gaur wrote:
> - Add driver for NXP FlexSPI host controller
>
> (0) What is the FlexSPI controller?
> FlexSPI is a flexsible SPI host controller which supports two SPI
> channels and up to 4 external devices. Each channel supports
> Single/Dual/Qu
On 15.01.19 16:18, Shawn Guo wrote:
> On Mon, Jan 14, 2019 at 08:18:49AM +0000, Schrempf Frieder wrote:
>> Hi Shawn,
>>
>> On 13.01.19 04:31, Shawn Guo wrote:
>>> On Mon, Jan 07, 2019 at 09:29:54AM +, Schrempf Frieder wrote:
>>>> From: Frieder Schrempf
On 23.05.19 00:05, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> The GigaDevice GD5F1GQ4UFxxG SPI NAND is in current production devices
> and, while it has the same logical layout as the E-series devices,
> it differs in the SPI interfacing in significant ways.
>
> This support is contingent on p
or GigaDevice GD5F1GQ4UFxxG
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=108868
>
>
>
> Jeff
>
>
>
> Cc: Miquel Raynal
> Cc: Schrempf Frieder
> Cc: Boris Brezillon
> Cc: Richard Weinberger
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Marek Vasut
> Cc: linux-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kbuild-...@01.org
>
>
>
Hi Kamal,
On 20.05.19 21:05, Kamal Dasu wrote:
> nand-ecc-strength and nand-ecc-step-size can be made optional as
> brcmnand driver can support using raw NAND layer detected values.
>
> Signed-off-by: Kamal Dasu
> ---
> Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt | 4 ++--
> 1 fil
Hi Jeff,
On 24.05.19 02:12, Jeff Kletsky wrote:
> (reduced direct addressees, though still on lists)
>
> On 5/22/19 11:42 PM, Schrempf Frieder wrote:
>
>> On 23.05.19 00:05, Jeff Kletsky wrote:
>>> From: Jeff Kletsky
>>>
>>> The GigaDevice GD
Hi Jeff,
I just noticed I hit the wrong button and my previous reply was only
sent to the MTD list, so I'm resending with fixed recipients...
On 10.05.19 14:17, l...@allycomm.com wrote:
> From: Jeff Kletsky
>
> The GigaDevice GD5F1GQ4UFxxG SPI NAND is in current production devices
> and, while
Hi Jeff,
On 14.05.19 17:42, Jeff Kletsky wrote:
> On 5/13/19 6:56 AM, Schrempf Frieder wrote:
>
>> Hi Jeff,
>>
>> I just noticed I hit the wrong button and my previous reply was only
>> sent to the MTD list, so I'm resending with fixed recipients...
>&g
On 15.05.19 08:17, Marek Vasut wrote:
> On 5/14/19 11:53 PM, Jeff Kletsky wrote:
>> From: Jeff Kletsky
>
> That #define in $subject is called a macro.
>
> Seems this patch adds a lot of almost duplicate code, can it be somehow
> de-duplicated ?
We could add another parameter naddr or addrlen to
On 14.05.19 23:53, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes three-byte addresses
> for its page-read ops.
>
> http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/
>
> Signed-off-by: Jeff Kletsky
Reviewed-by: Frieder Schrempf
> ---
> include
On 14.05.19 23:53, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes two-byte device IDs.
>
> http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/
>
> Signed-off-by: Jeff Kletsky
Reviewed-by: Frieder Schrempf
> ---
> drivers/mtd/nand/spi/core.c | 2
On 14.05.19 23:53, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> The GigaDevice GD5F1GQ4UFxxG SPI NAND is in current production devices
> and, while it has the same logical layout as the E-series devices,
> it differs in the SPI interfacing in significant ways.
>
> This support is contingent on p
Hi Krzysztof,
On 12.07.19 16:12, Krzysztof Kozlowski wrote:
> Add support for iMX6-UL2 modules from Kontron Electronics GmbH (before
> acquisition: Exceet Electronics) and evalkit boards based on it:
>
> 1. i.MX6 UL System-on-Module, a 25x25 mm solderable module (LGA pads and
> pin castellati
From: Frieder Schrempf
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
-ENOSYS and cause the probing of the imx UART to fail. As the
GPIOs are optional, we should continue probing in this case.
Signed-off-by: Frieder Schrempf
---
drivers/tty/serial/imx.c | 4 +++-
1 file change
Hi Uwe,
On 01.08.19 10:48, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 08:18:05AM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
>> -ENOSYS and cause the probing of the imx UART t
101 - 200 of 279 matches
Mail list logo
