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
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
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
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
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
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
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
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
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes for v5:
* None
Changes for v4:
* Rebase on next-20201001
* Enhance SoM and board description
Changes for v3:
* None
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
S
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
S
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes for v4:
* Rebase on next-20201001
* Enhance SoM and board description
Changes for v3:
* None
Changes for v2:
* Merge
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
In order to use ultra high speed modes (UHS) on the SD card slot, we
add matching pinctrls and fix the voltage switching for LDO5 of the
PMIC, by providing the SD_VSEL pin as GPIO to the PMIC driver.
Signed-off-by: Frieder Schrempf
---
.../dts/freescale/imx8mm-kontron-n8
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
S
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes for v3:
* None
Changes for v2:
* Merge the SoMs and baseboards N8010 and N8011 into a single
configuration (N801X).
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes for v2:
* Merge the SoMs and baseboards N8010 and N8011 into a single
configuration (N801X).
* Add Rob's R-b tag
---
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
Currently there are two SoM models:
* SL i.MX8MM N8010 with 1GB RAM and 8 GB eMMC
* SL i.MX8MM N8011 with 2GB RAM and 8 GB eMMC
The match
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
S
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
---
Documentation/devicetree/bindings/arm/fsl.yaml | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/ar
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8MM including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
SD card,
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8MM including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
Currently there are two SoM models:
* SL i.MX8MM N8010 with 1GB RAM and 8 GB eMMC
* SL i.MX8MM N8011 with 2GB RAM and 8 GB eMMC
The matching base
From: Frieder Schrempf
Allow external SPI ports on Kontron boards to use the spidev driver.
Signed-off-by: Frieder Schrempf
---
drivers/spi/spidev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 59e07675ef86..058b08a3767d 100644
--- a/dri
From: Frieder Schrempf
The MX25R1635F is the smaller sibling of the MX25R3235F that is
already supported. It's only half the size (16Mb).
It was tested on the Kontron Electronics i.MX8MM SoM (N8010)
using raw read and write from and to the mtd device and
the 'flash_erase' command.
Signed-off-by
Hi Robin,
On 20.05.20 00:05, Robin Gong wrote:
> Add NXP pca9450 pmic driver.
>
> Signed-off-by: Robin Gong
I rebased and applied on v5.8-rc3 an tested this with our i.MX8MM board
with PCA9450A. It seems to work fine. Below you can find some comments.
Thanks,
Frieder
> ---
> drivers/regula
On 09.06.20 09:23, Schrempf Frieder wrote:
> From: Uwe Kleine-König
>
> commit 1866541492641c02874bf51f9d8712b5510f2c64 upstream
>
> When using RS485 half duplex the Transmitter Complete irq is needed to
> determine the moment when the transmitter can be disabled. When using
&
From: Uwe Kleine-König
commit 1866541492641c02874bf51f9d8712b5510f2c64 upstream
When using RS485 half duplex the Transmitter Complete irq is needed to
determine the moment when the transmitter can be disabled. When using
DMA this irq must only be enabled when DMA has completed to transfer all
da
On 08.06.20 17:57, Fabio Estevam wrote:
> On Mon, Jun 8, 2020 at 12:51 PM Fabio Estevam wrote:
>>
>> On Mon, Jun 8, 2020 at 12:12 PM Schrempf Frieder
>> wrote:
>>
>>> if (port->rs485.flags & SER_RS485_ENABLED) {
>>>
From: Uwe Kleine-König
commit 1866541492641c02874bf51f9d8712b5510f2c64 upstream
When using RS485 half duplex the Transmitter Complete irq is needed to
determine the moment when the transmitter can be disabled. When using
DMA this irq must only be enabled when DMA has completed to transfer all
da
From: Frieder Schrempf
The WDOG_ANY signal is connected to the RESET_IN signal of the SoM
and baseboard. It is currently configured as push-pull, which means
that if some external device like a programmer wants to assert the
RESET_IN signal by pulling it to ground, it drives against the high
leve
From: Frieder Schrempf
The watchdog's WDOG_ANY signal is used to trigger a POR of the SoC,
if a soft reset is issued. As the SoM hardware connects the WDOG_ANY
and the POR signals, the watchdog node itself and the pin
configuration should be part of the common SoM devicetree.
Let's move it from t
On 27.05.20 13:53, Russell King - ARM Linux admin wrote:
> On Wed, May 27, 2020 at 10:39:12AM +0000, Schrempf Frieder wrote:
>> Hi,
>>
>> on our i.MX6UL/ULL boards running mainline kernels, we see an issue with
>> RS485 collisions on the bus. These are caused by the res
Hi,
on our i.MX6UL/ULL boards running mainline kernels, we see an issue with
RS485 collisions on the bus. These are caused by the resetting of the
RTS signal being delayed after each transmission. The TXDC interrupt
takes several milliseconds to trigger and the slave on the bus already
starts
On 06.05.20 13:45, Frieder Schrempf wrote:
> On 03.05.20 16:49, Adam Ford wrote:
>> On Thu, Apr 30, 2020 at 7:46 AM Schrempf Frieder
>> wrote:
>>>
>>> From: Frieder Schrempf
>>>
>>> According to the documents, the i.MX8M-Mini features a GC320 a
On 03.05.20 16:49, Adam Ford wrote:
> On Thu, Apr 30, 2020 at 7:46 AM Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> According to the documents, the i.MX8M-Mini features a GC320 and a
>> GCNanoUltra GPU core. Etnaviv detects them as:
>>
&
Hi Peng,
On 01.05.20 14:36, Peng Fan wrote:
>> Subject: Re: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to
>> fix boot on i.MX8MM
>>
>> On 30.04.20 16:35, Lucas Stach wrote:
>>> Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Fri
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
>>
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: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
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
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
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 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
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 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
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 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
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
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
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
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
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 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 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
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 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
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
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
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
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
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 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
>>>
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
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
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,
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
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
>&
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 08.08.19 19:26, Krzysztof Kozlowski wrote:
> Document the compatible for ANV32E61W EEPROM chip.
This chip is actually not an EEPROM, but a SPI nvSRAM. It can be
interfaced by the at25 driver similar to an EEPROM. This is not the
ideal solution, but it works until there's a proper driver for s
On 07.08.19 14:09, Alexander Stein wrote:
> On Wednesday, August 7, 2019, 1:44:06 PM CEST Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> The imx I2C controller is used in some ARM64 SoCs such as i.MX8M.
>> To make use of it, append ARM64 to the list of depend
On 07.08.19 14:20, Fabio Estevam wrote:
> Hi Frieder,
>
> On Wed, Aug 7, 2019 at 9:04 AM Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> The FEC ethernet controller is used in some ARM64 SoCs such as i.MX8.
>> To make use of it
From: Frieder Schrempf
The FEC ethernet controller is used in some ARM64 SoCs such as i.MX8.
To make use of it, append ARM64 to the list of dependencies.
Signed-off-by: Frieder Schrempf
---
drivers/net/ethernet/freescale/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Frieder Schrempf
The imx I2C controller is used in some ARM64 SoCs such as i.MX8M.
To make use of it, append ARM64 to the list of dependencies.
Signed-off-by: Frieder Schrempf
---
drivers/i2c/busses/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/b
On 06.08.19 09:45, Uwe Kleine-König wrote:
> Hello Frieder,
>
> On Mon, Aug 05, 2019 at 09:01:39AM +, Schrempf Frieder wrote:
>> On 02.08.19 14:12, Uwe Kleine-König wrote:
>>> On Fri, Aug 02, 2019 at 10:04:10AM +, Schrempf Frieder wrote:
>>>> From:
On 02.08.19 14:12, Uwe Kleine-König wrote:
> On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> As it is allowed to use the mctrl_gpio_* functions before
>> initialization (as the 8250 driver does according to 434be0a
From: Frieder Schrempf
As it is allowed to use the mctrl_gpio_* functions before
initialization (as the 8250 driver does according to 434be0ae7aa7),
it seems appropriate to have a NULL check in all of the functions.
Otherwise the mctrl_gpio_to_gpiod() function is prone to be used
in a context tha
From: Frieder Schrempf
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
mctrl_gpio_init_noauto() will currently return an error pointer with
-ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
check for this condition to allow continue probing.
To avoid the need for this che
From: Frieder Schrempf
Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
if CONFIG_GPIOLIB is disabled, we can safely remove this check.
Signed-off-by: Frieder Schrempf
---
Changes in v3
=
* Adjust the commit message and subject line
Changes in v2
=
From: Frieder Schrempf
Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
if CONFIG_GPIOLIB is disabled, we can safely remove this check.
Signed-off-by: Frieder Schrempf
---
Changes in v3
=
* Adjust the commit message and subject line
Changes in v2
=
On 01.08.19 22:39, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 06:45:24PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
>> in cases when CONFIG_GPIOLIB is disabled, we can
On 01.08.19 22:33, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 06:45:21PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
>> mctrl_gpio_init_noauto() will currently return an error pointer wi
From: Frieder Schrempf
Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
in cases when CONFIG_GPIOLIB is disabled, we can safely remove this
check.
Signed-off-by: Frieder Schrempf
---
drivers/tty/serial/8250/8250_core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletio
From: Frieder Schrempf
Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
in cases when CONFIG_GPIOLIB is disabled, we can safely remove this
check.
Signed-off-by: Frieder Schrempf
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
From: Frieder Schrempf
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
mctrl_gpio_init_noauto() will currently return an error pointer with
-ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
check for this condition to allow continue probing.
To avoid the need for this che
From: Frieder Schrempf
If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
mctrl_gpio_init_noauto() will currently return an error pointer with
-ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
check for this condition to allow continue probing.
To avoid the need for this che
On 01.08.19 11:55, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 09:28:33AM +0000, Schrempf Frieder wrote:
>> Hi Uwe,
>>
>> On 01.08.19 10:48, Uwe Kleine-König wrote:
>>> On Thu, Aug 01, 2019 at 08:18:05AM +, Schrempf Frieder wrote:
>>>> From: Fri
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
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
On 29.07.19 19:20, Krzysztof Kozlowski wrote:
> Add support for i.MX6UL modules from Kontron Electronics GmbH (before
> acquisition: Exceet Electronics) and evalkit boards based on it:
>
> 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
> (LGA pads and pin castellations)
On 26.07.19 12:02, Krzysztof Kozlowski wrote:
> On Fri, 26 Jul 2019 at 11:48, Schrempf Frieder
> wrote:
>>
>> On 26.07.19 08:17, Krzysztof Kozlowski wrote:
>>> Add vendor prefix for Admatec AG.
>>
>> We get the displays used with the Kontron eval kits
On 26.07.19 08:17, Krzysztof Kozlowski wrote:
> Add vendor prefix for Admatec AG.
We get the displays used with the Kontron eval kits from "admatec GmbH"
in Hamburg, not "Admatec AG" in Switzerland. I think we have to
differentiate here.
I will review patch 2/2 soon...
>
> Signed-off-by: Krzy
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
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
On 18.06.19 19:08, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> Add initial support for Paragon Technology
> PN26G01Ax and PN26G02Ax SPI NAND
>
> Datasheets available at
> http://www.xtxtech.com/upfile/2016082517274590.pdf
> http://www.xtxtech.com/upfile/2016082517282329.pdf
>
> Signed-
On 25.06.19 13:56, liaoweixiong wrote:
> Oh, i am sorry that i had misunderstanded your letter.
No problem ;)
> Thank you for your document and guidance.
You're welcome!
> On 2019/6/25 PM 3:04, Schrempf Frieder wrote:
>> Hi liaoweixiong,
>>
>> On 25.06.19 05:08
Hi Jeff,
On 18.06.19 19:08, Jeff Kletsky wrote:
> From: Jeff Kletsky
>
> Add initial support for Paragon Technology
> PN26G01Ax and PN26G02Ax SPI NAND
>
> Datasheets available at
> http://www.xtxtech.com/upfile/2016082517274590.pdf
> http://www.xtxtech.com/upfile/2016082517282329.pdf
>
Hi liaoweixiong,
On 25.06.19 05:08, Greg KH wrote:
> On Tue, Jun 25, 2019 at 09:02:29AM +0800, liaoweixiong wrote:
>> In case of the last page containing bitflips (ret > 0),
>> spinand_mtd_read() will return that number of bitflips for the last
>> page. But to me it looks like it should instead re
1 - 100 of 279 matches
Mail list logo
