* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
From: Andy Shevchenko @ 2020-06-05 8:07 UTC (permalink / raw)
To: Michael Walle
Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
Andy Shevchenko
In-Reply-To: <20200604211039.12689-4-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:13 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the interrupt controller inside the sl28 CPLD management
> controller.
>
> The interrupt controller can handle at most 8 interrupts and is really
> simplistic and consists only of an interrupt mask and an interrupt
> pending register.
...
> +config SL28CPLD_INTC
> + bool
Same Q: Why not module?
...
> +static const struct of_device_id sl28cpld_intc_of_match[] = {
> + { .compatible = "kontron,sl28cpld-intc" },
> + {},
There is no point to have comma in terminator line.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: ppvk @ 2020-06-05 8:06 UTC (permalink / raw)
To: Sibi Sankar
Cc: Matthias Kaehlcke, bjorn.andersson, adrian.hunter, robh+dt,
ulf.hansson, vbadigan, sboyd, georgi.djakov, linux-mmc,
linux-kernel, linux-arm-msm, devicetree, linux-mmc-owner, rnayak,
matthias
In-Reply-To: <23d6da79d604ce5113d90a2adab17483@codeaurora.org>
On 2020-06-05 00:04, Sibi Sankar wrote:
> On 2020-06-04 22:39, Matthias Kaehlcke wrote:
>> On Thu, Jun 04, 2020 at 04:44:42PM +0530, Pradeep P V K wrote:
>>> Interconnect bandwidth scaling support is now added as a
>>> part of OPP [1]. So, make sure interconnect driver is ready
>>> before handling interconnect scaling.
>>>
>>> This change is based on
>>> [1] [Patch v8] Introduce OPP bandwidth bindings
>>> (https://lkml.org/lkml/2020/5/12/493)
>>>
>>> [2] [Patch v3] mmc: sdhci-msm: Fix error handling
>>> for dev_pm_opp_of_add_table()
>>> (https://lkml.org/lkml/2020/5/5/491)
>>>
>>> Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
>>> ---
>>> drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-msm.c
>>> b/drivers/mmc/host/sdhci-msm.c
>>> index b277dd7..a13ff1b 100644
>>> --- a/drivers/mmc/host/sdhci-msm.c
>>> +++ b/drivers/mmc/host/sdhci-msm.c
>>> @@ -14,6 +14,7 @@
>>> #include <linux/slab.h>
>>> #include <linux/iopoll.h>
>>> #include <linux/regulator/consumer.h>
>>> +#include <linux/interconnect.h>
>>>
>>> #include "sdhci-pltfm.h"
>>> #include "cqhci.h"
>>> @@ -2070,6 +2071,18 @@ static int sdhci_msm_probe(struct
>>> platform_device *pdev)
>>> }
>>> msm_host->bulk_clks[0].clk = clk;
>>>
>>> + /* Make sure that ICC driver is ready for interconnect bandwdith
>>> + * scaling before registering the device for OPP.
>>> + */
>>> + ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
>>> + if (ret) {
>>> + if (ret == -EPROBE_DEFER)
>>> + dev_info(&pdev->dev, "defer icc path: %d\n", ret);
>>
>> I already commented on this on v1:
>>
>> This log seems to add little more than noise, or are there
>> particular reasons
>> why it is useful in this driver? Most drivers just return silently
>> in case of
>> deferred probing.
>>
>> If you think the log is really needed please explain why.
>
Sorry. i forget to remove this print on V2. i will address this in my
next patch set.
> Both the err logs seem redundant.
> EPROBE_DEFERS are rather readily
> noticeable through the return val.
> dev_.._find_icc_paths already prints
> err messages when we fail to get icc
> paths.
True. i will remove this too in my next patch set.
^ permalink raw reply
* Re: [PATCH v8 08/14] media: platform: Change case for improving code quality
From: Xia Jiang @ 2020-06-05 8:04 UTC (permalink / raw)
To: Hans Verkuil
Cc: Mauro Carvalho Chehab, Rob Herring, Matthias Brugger, Rick Chang,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Marek Szyprowski, Tomasz Figa, srv_heupstream,
senozhatsky, mojahsu, drinkcat, maoguang.meng, sj.huang
In-Reply-To: <4b8cc41e-5171-0d48-f588-96e4212ab22c@xs4all.nl>
On Mon, 2020-05-11 at 10:37 +0200, Hans Verkuil wrote:
> On 03/04/2020 11:40, Xia Jiang wrote:
> > Change register offset hex numberals from upercase to lowercase.
>
> Typos:
>
> numberals -> numerals
>
> upercase -> uppercase
Done.
>
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 18 +++++++++---------
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > index 94db04e9cdb6..2945da842dfa 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > @@ -20,29 +20,29 @@
> > #define BIT_INQST_MASK_ALLIRQ 0x37
> >
> > #define JPGDEC_REG_RESET 0x0090
> > -#define JPGDEC_REG_BRZ_FACTOR 0x00F8
> > -#define JPGDEC_REG_DU_NUM 0x00FC
> > +#define JPGDEC_REG_BRZ_FACTOR 0x00f8
> > +#define JPGDEC_REG_DU_NUM 0x00fc
> > #define JPGDEC_REG_DEST_ADDR0_Y 0x0140
> > #define JPGDEC_REG_DEST_ADDR0_U 0x0144
> > #define JPGDEC_REG_DEST_ADDR0_V 0x0148
> > -#define JPGDEC_REG_DEST_ADDR1_Y 0x014C
> > +#define JPGDEC_REG_DEST_ADDR1_Y 0x014c
> > #define JPGDEC_REG_DEST_ADDR1_U 0x0150
> > #define JPGDEC_REG_DEST_ADDR1_V 0x0154
> > #define JPGDEC_REG_STRIDE_Y 0x0158
> > -#define JPGDEC_REG_STRIDE_UV 0x015C
> > +#define JPGDEC_REG_STRIDE_UV 0x015c
> > #define JPGDEC_REG_IMG_STRIDE_Y 0x0160
> > #define JPGDEC_REG_IMG_STRIDE_UV 0x0164
> > -#define JPGDEC_REG_WDMA_CTRL 0x016C
> > +#define JPGDEC_REG_WDMA_CTRL 0x016c
> > #define JPGDEC_REG_PAUSE_MCU_NUM 0x0170
> > -#define JPGDEC_REG_OPERATION_MODE 0x017C
> > +#define JPGDEC_REG_OPERATION_MODE 0x017c
> > #define JPGDEC_REG_FILE_ADDR 0x0200
> > -#define JPGDEC_REG_COMP_ID 0x020C
> > +#define JPGDEC_REG_COMP_ID 0x020c
> > #define JPGDEC_REG_TOTAL_MCU_NUM 0x0210
> > #define JPGDEC_REG_COMP0_DATA_UNIT_NUM 0x0224
> > -#define JPGDEC_REG_DU_CTRL 0x023C
> > +#define JPGDEC_REG_DU_CTRL 0x023c
> > #define JPGDEC_REG_TRIG 0x0240
> > #define JPGDEC_REG_FILE_BRP 0x0248
> > -#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024C
> > +#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024c
> > #define JPGDEC_REG_QT_ID 0x0270
> > #define JPGDEC_REG_INTERRUPT_STATUS 0x0274
> > #define JPGDEC_REG_STATUS 0x0278
> >
>
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Andy Shevchenko @ 2020-06-05 8:02 UTC (permalink / raw)
To: Michael Walle
Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
Andy Shevchenko
In-Reply-To: <CAHp75Vd-R3yqhq88-whY6vdDhESpzvFCsbi-ygSTjfXfUzOrtg@mail.gmail.com>
On Fri, Jun 5, 2020 at 11:01 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
...
> > Please note that the MFD driver is defined as bool in the Kconfig
> > because the next patch will add interrupt support.
> > + bool "Kontron sl28 core driver"
> > + depends on I2C=y
>
> Why not module?
To be clear, I have read above, but it didn't shed a light.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Andy Shevchenko @ 2020-06-05 8:01 UTC (permalink / raw)
To: Michael Walle
Cc: open list:GPIO SUBSYSTEM, devicetree, Linux Kernel Mailing List,
linux-hwmon, linux-pwm, linux-watchdog, linux-arm Mailing List,
Linus Walleij, Bartosz Golaszewski, Rob Herring, Jean Delvare,
Guenter Roeck, Lee Jones, Thierry Reding, Uwe Kleine-König,
Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
Andy Shevchenko
In-Reply-To: <20200604211039.12689-3-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
> - watchdog
> - GPIO controller
> - PWM controller
> - fan sensor
> - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
...
> +config MFD_SL28CPLD
> + bool "Kontron sl28 core driver"
> + depends on I2C=y
Why not module?
> + depends on OF
I didn't find an evidence this is needed.
No Compile Test?
> + select REGMAP_I2C
> + select MFD_CORE
...
> +#include <linux/of_platform.h>
No evidence of user of this.
I think you meant mod_devicetable.h.
...
> +static struct i2c_driver sl28cpld_driver = {
> + .probe_new = sl28cpld_probe,
> + .driver = {
> + .name = "sl28cpld",
> + .of_match_table = of_match_ptr(sl28cpld_of_match),
Drop of_match_ptr(). It has a little sense in this context (depends OF).
It will have a little sense even if you drop depends OF b/c you will
introduce a compiler warning.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx pin
From: Luca Ceresoli @ 2020-06-05 7:57 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200604110759.GB6644@sirena.org.uk>
Hi Mark,
On 04/06/20 13:07, Mark Brown wrote:
> On Wed, Jun 03, 2020 at 10:03:16PM +0200, Luca Ceresoli wrote:
>
>> I suspect the only solution that allows to configure the EN_PIN_CTRLn bits
>> correctly in all the possible hardware setups would be to tell in device
>> tree / board info whether each enable pin is connected or not (which is a
>> hardware _fact_) and which ENx pin should control which regulator output
>> (which is a policy). But it would make this simple driver considerably more
>> complex.
>
>> Any suggestion about the correct way to handle this situation would be
>> greatly appreciated.
>
> We can tell if we've got a software controlled GPIO connected, if we
> have then we should ensure that it continues to take effect.
Ideally yes, but it would be made more complex by the chip flexibility:
it's possible to choose which enable pin should drive each output.
For example this configuration is supported by the chip:
- BUCK0 is on if EN_BUCK0 high AND pin EN0 is active
- BUCK1 is on if EN_BUCK1 high AND pin EN0 is active
- BUCK2 is on if EN_BUCK2 high AND pin EN1 is active
- BUCK3 is on if EN_BUCK3 high (no pin used)
- pin EN2 is used as a GPIO (LP875xx acts as an I2C GPIO expander)
So it would be absolutely OK to describe in DT that EN0 and EN1 connect
the SoC to the LP875xx and that EN2 is connected to something else.
But describing in DT the association between enable pins and buck
outputs would be more a configuration than hardware description IMO.
And I'm not even considering the case where the enable pins are be
connected to something else, out of the SoC control, but still meant to
be used to control the buck output.
> That
> should just be a single register write at startup from the sounds of it.
Exactly, each buck output has a register containing the bits involved in
this discussion.
> Otherwise yeah, just ignoring that there's a possibility of a GPIO we
> don't know about seems sensible.
Thanks,
--
Luca
^ permalink raw reply
* Re: (EXT) RE: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Matthias Schiffer @ 2020-06-05 7:57 UTC (permalink / raw)
To: Robin Gong
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
broonie@kernel.org, robh+dt@kernel.org, catalin.marinas@arm.com,
vkoul@kernel.org, will.deacon@arm.com, shawnguo@kernel.org,
festevam@gmail.com, s.hauer@pengutronix.de,
martin.fuzzey@flowbird.group, u.kleine-koenig@pengutronix.de,
dan.j.williams@intel.com, Markus Niebel
In-Reply-To: <VE1PR04MB6638463E7E6577E84F8D1FF589860@VE1PR04MB6638.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]
On Fri, 2020-06-05 at 02:45 +0000, Robin Gong wrote:
> On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> wrote:
> > On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > > On 2020/06/03 Matthias Schiffer <
> > > matthias.schiffer@ew.tq-group.com>
> > > wrote:
> > > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause
> > > > > FIFO
> > > > > transfer to be send twice in DMA mode. Please get more
> > > > > information
> > > > > from:
> > > > >
> >
> >
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > > > > .
> > > > >
> > > >
> > > >
> >
> > nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> > > > yibin.g
> > > > >
> > > >
> > > >
> >
> > ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> > > > 4c6fa92
> > > > >
> > > >
> > > >
> >
> > cd99c5c301635%7C0%7C1%7C637267698912634476&sdata=hR66H1hP%
> > > > 2Fqb6OXe
> > > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&reserved=0. The
> > > > > workaround
> >
> > is
> > > > > adding new sdma ram script which works in XCH mode as PIO
> > > > > inside
> > > > > sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be
> > > > > 0.
> > > > > The issue
> > > >
> > > > should be exist on all legacy i.mx6/7 soc family before
> > > > i.mx6ul.
> > > > > NXP fix this design issue from i.mx6ul, so newer chips
> > > > > including
> > > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All
> > > > > other
> > > > > i.mx6/7/8 chips still need this workaroud. This patch set add
> > > > > new
> > > > > 'fsl,imx6ul-ecspi'
> > > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose
> > > > > if
> > > > > need errata or not.
> > > > > The first two reverted patches should be the same issue,
> > > > > though,
> > > > > it seems 'fixed' by changing to other shp script. Hope Sean
> > > > > or
> > > > > Sascha could have the chance to test this patch set if could
> > > > > fix
> > > > > their issues.
> > > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1
> > > > > not
> > > > > work on i.mx8mm because the event id is zero.
> > > > >
> > > > > PS:
> > > > > Please get sdma firmware from below linux-firmware and
> > > > > copy it
> > > > > to your local rootfs /lib/firmware/imx/sdma.
> > > >
> > > >
> > > > Hello Robin,
> > > >
> > > > we have tried out this series, and there seems to be an issue
> > > > with
> > > > the
> > > > PIO fallback. We are testing on an i.MX6Q board, and our kernel
> > > > is
> > > > a
> > > > mostly-unmodified 5.4, on which we backported all SDMA patches
> > > > from
> > > > next-20200602 (imx-sdma.c is identical to next-20200602
> > > > version),
> > > > and
> > > > then applied this whole series.
> > > >
> > > > We build the SDMA driver as a kernel module, which is loaded by
> > > > udev,
> > > > so the root filesystem is ready and the SDMA firmware can be
> > > > loaded.
> > > > The behaviour we're seeing is the following:
> > > >
> > > > 1. As long as the SDMA driver is not loaded, initializing
> > > > spi_imx
> > > > will
> > > > be deferred
> > > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at
> > > > this
> > > > point
> > > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To
> > > > load
> > > > the
> > > > BFPT, the driver will attempt to use DMA; this will fail with
> > > > EINVAL as
> > > > long as the SDMA firmware is not ready, so the fallback to PIO
> > > > happens
> > > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> > > >
> > > > The problem happens in step 3: Whenever the driver falls back
> > > > to
> > > > PIO,
> > > > the received data is corrupt. The behaviour is specific to the
> > > > fallback: When I disable DMA completely via spi_imx.use_dma, or
> > > > when
> > > > the timing is lucky and the SDMA firmware gets loaded before
> > > > the
> > > > flash
> > > > is probed, no corruption can be observed.
> > >
> > > Thanks Matthias, would you like post log?
> > >
> >
> > I have attached the following log files:
> > - pio.log: DMA disabled via module parameter
> > - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR
> > probe
> > - fallback.log: DMA->PIO fallback
> >
> > The logs include some additional log messages:
> > - Return value of spi_imx_dma_transfer() before PIO fallback
> > - SPI-NOR SFPT dump
> >
> > It can be seen that the BFPT data is identical in pio.log and
> > dma.log,
> > and differs almost completely in fallback.log. The corrupted data
> > seems
> > to be random, or uninitialized memory; it differs with every boot.
>
> Would you please have a try with the attached patch? Thanks.
Thank you, this fixes the issue we're seeing.
Kind regards,
Matthias
[-- Attachment #2: fixed.log --]
[-- Type: text/x-log, Size: 33368 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.39 (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Fri Jun 5 07:23:40 UTC 2020
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TQ TQMa6Q on MBa6x
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 160 MiB at 0x46000000
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] Normal zone: 2048 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 262144 pages, LIFO batch:63
[ 0.000000] percpu: Embedded 20 pages/cpu s50664 r8192 d23064 u81920
[ 0.000000] pcpu-alloc: s50664 r8192 d23064 u81920 alloc=20*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260096
[ 0.000000] Kernel command line: root=/dev/mmcblk1p2 ro rootwait console=ttymxc1,115200 spi_imx.dyndbg=+p consoleblank=0 cma=160M
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 850004K/1048576K available (12288K kernel code, 942K rwdata, 3656K rodata, 1024K init, 6554K bss, 34732K reserved, 163840K cma-reserved, 0K highmem)
[ 0.000000] random: get_random_u32 called from __kmem_cache_create+0x20/0x2b8 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 34625 entries in 68 pages
[ 0.000000] Running RCU self tests
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU lockdep checking is enabled.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000009] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000040] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[ 0.001629] Console: colour dummy device 80x30
[ 0.001665] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.001687] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.001711] ... MAX_LOCK_DEPTH: 48
[ 0.001731] ... MAX_LOCKDEP_KEYS: 8192
[ 0.001753] ... CLASSHASH_SIZE: 4096
[ 0.001774] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.001795] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.001816] ... CHAINHASH_SIZE: 32768
[ 0.001836] memory used by lock dependency info: 3997 kB
[ 0.001856] memory used for stack traces: 2112 kB
[ 0.001878] per task-struct memory footprint: 1536 bytes
[ 0.001953] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[ 0.001988] pid_max: default: 32768 minimum: 301
[ 0.002526] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.002572] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.005083] CPU: Testing write buffer coherency: ok
[ 0.005169] CPU0: Spectre v2: using BPIALL workaround
[ 0.006459] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.059678] Setting up static identity map for 0x10100000 - 0x10100060
[ 0.079539] rcu: Hierarchical SRCU implementation.
[ 0.129550] smp: Bringing up secondary CPUs ...
[ 0.210001] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.210016] CPU1: Spectre v2: using BPIALL workaround
[ 0.289894] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.289910] CPU2: Spectre v2: using BPIALL workaround
[ 0.369888] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.369903] CPU3: Spectre v2: using BPIALL workaround
[ 0.370513] smp: Brought up 1 node, 4 CPUs
[ 0.370547] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[ 0.370573] CPU: All CPU(s) started in SVC mode.
[ 0.372564] devtmpfs: initialized
[ 0.411117] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.413270] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.413334] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.421673] pinctrl core: initialized pinctrl subsystem
[ 0.426412] NET: Registered protocol family 16
[ 0.433920] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.437726] cpuidle: using governor ladder
[ 0.438009] CPU identified as i.MX6Q, silicon rev 1.5
[ 0.471621] vdd1p1: supplied by regulator-dummy
[ 0.473787] vdd3p0: supplied by regulator-dummy
[ 0.475680] vdd2p5: supplied by regulator-dummy
[ 0.477536] vddarm: supplied by regulator-dummy
[ 0.479670] vddpu: supplied by regulator-dummy
[ 0.481530] vddsoc: supplied by regulator-dummy
[ 0.521081] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.521146] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.524299] imx6q-pinctrl 20e0000.iomuxc: initialized IMX pinctrl driver
[ 0.644216] mxs-dma 110000.dma-apbh: initialized
[ 0.653222] vgaarb: loaded
[ 0.654666] SCSI subsystem initialized
[ 0.655483] libata version 3.00 loaded.
[ 0.656501] usbcore: registered new interface driver usbfs
[ 0.656737] usbcore: registered new interface driver hub
[ 0.657080] usbcore: registered new device driver usb
[ 0.657588] usb_phy_generic usbphynop1: usbphynop1 supply vcc not found, using dummy regulator
[ 0.658449] usb_phy_generic usbphynop2: usbphynop2 supply vcc not found, using dummy regulator
[ 0.665470] i2c i2c-0: IMX I2C adapter registered
[ 0.666320] pps_core: LinuxPPS API ver. 1 registered
[ 0.666349] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.666430] PTP clock support registered
[ 0.674652] clocksource: Switched to clocksource mxc_timer1
[ 1.740208] thermal_sys: Registered thermal governor 'fair_share'
[ 1.740222] thermal_sys: Registered thermal governor 'step_wise'
[ 1.740260] thermal_sys: Registered thermal governor 'user_space'
[ 1.741160] NET: Registered protocol family 2
[ 1.743061] tcp_listen_portaddr_hash hash table entries: 512 (order: 2, 20480 bytes, linear)
[ 1.743196] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.743432] TCP bind hash table entries: 8192 (order: 6, 294912 bytes, linear)
[ 1.744897] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.745528] UDP hash table entries: 512 (order: 3, 40960 bytes, linear)
[ 1.745768] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes, linear)
[ 1.746564] NET: Registered protocol family 1
[ 1.748943] RPC: Registered named UNIX socket transport module.
[ 1.749009] RPC: Registered udp transport module.
[ 1.749037] RPC: Registered tcp transport module.
[ 1.749064] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.760424] PCI: CLS 0 bytes, default 64
[ 1.761389] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[ 1.762261] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 1.768318] Initialise system trusted keyrings
[ 1.769028] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[ 1.792661] NFS: Registering the id_resolver key type
[ 1.792800] Key type id_resolver registered
[ 1.792870] Key type id_legacy registered
[ 1.792932] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.793719] fuse: init (API version 7.31)
[ 1.796020] NILFS version 2 loaded
[ 1.838986] Key type asymmetric registered
[ 1.839100] Asymmetric key parser 'x509' registered
[ 1.839275] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.839367] io scheduler mq-deadline registered
[ 1.839401] io scheduler kyber registered
[ 1.847454] imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges:
[ 1.847675] imx6q-pcie 1ffc000.pcie: IO 0x01f80000..0x01f8ffff -> 0x00000000
[ 1.847866] imx6q-pcie 1ffc000.pcie: MEM 0x01000000..0x01efffff -> 0x01000000
[ 1.859118] pfuze100-regulator 0-0008: Full layer: 2, Metal layer: 1
[ 1.860092] pfuze100-regulator 0-0008: FAB: 0, FIN: 0
[ 1.860126] pfuze100-regulator 0-0008: pfuze100 found.
[ 1.891216] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 66, base_baud = 5000000) is a IMX
[ 2.678656] printk: console [ttymxc1] enabled
[ 2.685153] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 67, base_baud = 5000000) is a IMX
[ 2.695707] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 68, base_baud = 5000000) is a IMX
[ 2.706224] 21f4000.serial: ttymxc4 at MMIO 0x21f4000 (irq = 69, base_baud = 5000000) is a IMX
[ 2.739808] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[ 2.746264] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[ 2.752620] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[ 2.758410] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[ 2.765556] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[ 2.771816] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[ 2.778030] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[ 2.787199] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
[ 2.799546] imx-ipuv3 2400000.ipu: IPUv3H probed
[ 2.807632] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.814322] [drm] No driver support for vblank timestamp query.
[ 2.821418] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
[ 2.829349] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
[ 2.837354] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops)
[ 2.845276] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops)
[ 2.854389] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1
[ 2.862675] imx-ipuv3 2800000.ipu: IPUv3H probed
[ 2.912586] loop: module loaded
[ 2.918439] at24 0-0050: 8192 byte 24c64 EEPROM, writable, 32 bytes/write
[ 2.927616] at24 0-0057: 8192 byte 24c64 EEPROM, writable, 32 bytes/write
[ 2.937469] ahci-imx 2200000.sata: fsl,transmit-level-mV not specified, using 00000024
[ 2.945500] ahci-imx 2200000.sata: fsl,transmit-boost-mdB not specified, using 00000480
[ 2.953544] ahci-imx 2200000.sata: fsl,transmit-atten-16ths not specified, using 00002000
[ 2.961821] ahci-imx 2200000.sata: fsl,receive-eq-mdB not specified, using 05000000
[ 2.969862] ahci-imx 2200000.sata: 2200000.sata supply ahci not found, using dummy regulator
[ 2.974678] imx6q-pcie 1ffc000.pcie: Phy link never came up
[ 2.978838] ahci-imx 2200000.sata: 2200000.sata supply phy not found, using dummy regulator
[ 2.987906] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[ 2.993159] ahci-imx 2200000.sata: 2200000.sata supply target not found, using dummy regulator
[ 2.998671] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 2.998699] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.011182] ahci-imx 2200000.sata: SSS flag set, parallel bus scan disabled
[ 3.012881] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[ 3.019183] ahci-imx 2200000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[ 3.026411] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[ 3.033056] ahci-imx 2200000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst
[ 3.041992] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[ 3.063650] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 3.067674] scsi host0: ahci-imx
[ 3.070548] pci 0000:00:00.0: Limiting cfg_size to 512
[ 3.075295] ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 72
[ 3.079130] pci 0000:00:00.0: supports D1
[ 3.089282] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 3.090799] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[ 3.092133] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 3.099384] libphy: Fixed MDIO Bus: probed
[ 3.102695] PCI: bus0: Fast back to back transfers disabled
[ 3.105356] CAN device driver interface
[ 3.113649] PCI: bus1: Fast back to back transfers enabled
[ 3.114285] flexcan 2090000.flexcan: 2090000.flexcan supply xceiver not found, using dummy regulator
[ 3.119291] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[ 3.131705] flexcan 2094000.flexcan: 2094000.flexcan supply xceiver not found, using dummy regulator
[ 3.135310] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[ 3.151786] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 3.153541] pps pps0: new PPS source ptp0
[ 3.159151] pcieport 0000:00:00.0: PME: Signaling with IRQ 306
[ 3.168741] pcieport 0000:00:00.0: AER: enabled with IRQ 306
[ 3.169048] libphy: fec_enet_mii_bus: probed
[ 3.183769] fec 2188000.ethernet eth0: registered PHC device 0
[ 3.190548] usbcore: registered new interface driver cdc_ether
[ 3.196665] usbcore: registered new interface driver smsc95xx
[ 3.202461] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.209144] ehci-pci: EHCI PCI platform driver
[ 3.219204] imx_usb 2184000.usb: No over current polarity defined
[ 3.230025] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 3.235495] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 3.264720] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 3.271845] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 3.280322] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.287654] usb usb1: Product: EHCI Host Controller
[ 3.292565] usb usb1: Manufacturer: Linux 5.4.39 ehci_hcd
[ 3.298056] usb usb1: SerialNumber: ci_hdrc.0
[ 3.305485] hub 1-0:1.0: USB hub found
[ 3.309555] hub 1-0:1.0: 1 port detected
[ 3.317484] imx_usb 2184200.usb: 2184200.usb supply vbus not found, using dummy regulator
[ 3.330416] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 3.335501] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[ 3.364702] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 3.371209] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 3.379600] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.386918] usb usb2: Product: EHCI Host Controller
[ 3.391831] usb usb2: Manufacturer: Linux 5.4.39 ehci_hcd
[ 3.397322] usb usb2: SerialNumber: ci_hdrc.1
[ 3.403588] hub 2-0:1.0: USB hub found
[ 3.407620] hub 2-0:1.0: 1 port detected
[ 3.416582] mousedev: PS/2 mouse device common for all mice
[ 3.426923] ata1: SATA link down (SStatus 0 SControl 300)
[ 3.432599] ahci-imx 2200000.sata: no device found, disabling link.
[ 3.434404] rtc-ds1307 0-0068: registered as rtc0
[ 3.438995] ahci-imx 2200000.sata: pass ahci_imx..hotplug=1 to enable hotplug
[ 3.445882] i2c /dev entries driver
[ 3.455954] IR NEC protocol handler initialized
[ 3.460526] IR RC5(x/sz) protocol handler initialized
[ 3.465704] IR RC6 protocol handler initialized
[ 3.470272] IR JVC protocol handler initialized
[ 3.474914] IR Sony protocol handler initialized
[ 3.479565] IR SANYO protocol handler initialized
[ 3.484300] IR Sharp protocol handler initialized
[ 3.489093] IR MCE Keyboard/mouse protocol handler initialized
[ 3.495017] IR XMP protocol handler initialized
[ 3.506346] lm75 0-0048: hwmon0: sensor 'lm75'
[ 3.513239] lm75 0-0049: hwmon1: sensor 'lm75'
[ 3.523672] imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
[ 3.532392] sdhci: Secure Digital Host Controller Interface driver
[ 3.538672] sdhci: Copyright(c) Pierre Ossman
[ 3.543062] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.550780] sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
[ 3.556135] sdhci-esdhc-imx 2194000.usdhc: Got WP GPIO
[ 3.598990] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[ 3.651070] mmc1: new high speed SD card at address 1234
[ 3.657883] mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
[ 3.670288] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.671305] mmcblk1: mmc1:1234 SA02G 1.84 GiB
[ 3.681554] caam 2100000.caam: Entropy delay = 3200
[ 3.703274] mmcblk1: p1 p2
[ 3.747319] caam 2100000.caam: Instantiated RNG4 SH0
[ 3.774779] usb 2-1: new high-speed USB device number 2 using ci_hdrc
[ 3.787144] mmc0: new DDR MMC card at address 0001
[ 3.794197] mmcblk0: mmc0:0001 MMC04G 3.52 GiB
[ 3.799884] mmcblk0boot0: mmc0:0001 MMC04G partition 1 16.0 MiB
[ 3.806963] mmcblk0boot1: mmc0:0001 MMC04G partition 2 16.0 MiB
[ 3.808082] caam 2100000.caam: Instantiated RNG4 SH1
[ 3.813829] mmcblk0rpmb: mmc0:0001 MMC04G partition 3 128 KiB, chardev (248:0)
[ 3.817956] caam 2100000.caam: device ID = 0x0a16010000000000 (Era 4)
[ 3.817974] caam 2100000.caam: job rings = 2, qi = 0
[ 3.892098] caam algorithms registered in /proc/crypto
[ 3.912582] caam_jr 2101000.jr0: registering rng-caam
[ 3.919891] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.930853] NET: Registered protocol family 10
[ 3.939894] Segment Routing with IPv6
[ 3.943729] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 3.952463] NET: Registered protocol family 17
[ 3.957050] can: controller area network core (rev 20170425 abi 9)
[ 3.963506] NET: Registered protocol family 29
[ 3.968053] can: raw protocol (rev 20170425)
[ 3.972458] can: broadcast manager protocol (rev 20170425 t)
[ 3.975864] usb 2-1: New USB device found, idVendor=0424, idProduct=2517, bcdDevice= 0.02
[ 3.978267] can: netlink gateway (rev 20190810) max_hops=1
[ 3.986497] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.992533] Key type dns_resolver registered
[ 4.001775] hub 2-1:1.0: USB hub found
[ 4.007726] hub 2-1:1.0: 7 ports detected
[ 4.019922] Registering SWP/SWPB emulation handler
[ 4.026940] Loading compiled-in X.509 certificates
[ 4.033765] Key type ._fscrypt registered
[ 4.038061] Key type .fscrypt registered
[ 4.197921] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.199984] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.203694] imx_thermal tempmon: Industrial CPU temperature grade - max:105C critical:100C passive:95C
[ 4.215406] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.217246] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.219297] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.221081] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.225245] random: fast init done
[ 4.229248] rtc-ds1307 0-0068: setting system clock to 2000-01-01T00:01:08 UTC (946684868)
[ 4.238084] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.258979] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4.267092] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 4.276176] cfg80211: failed to load regulatory.db
[ 4.301827] EXT4-fs (mmcblk1p2): INFO: recovery required on readonly filesystem
[ 4.309472] EXT4-fs (mmcblk1p2): write access will be enabled during recovery
[ 4.334800] usb 2-1.1: new high-speed USB device number 3 using ci_hdrc
[ 4.496212] usb 2-1.1: New USB device found, idVendor=0424, idProduct=9e00, bcdDevice= 3.00
[ 4.504886] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.517379] smsc95xx v1.0.6
[ 4.648480] smsc95xx 2-1.1:1.0 eth1: register 'smsc95xx' at usb-ci_hdrc.1-1.1, smsc95xx USB 2.0 Ethernet, f2:78:83:43:d1:7b
[ 4.662389] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.664256] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.967482] EXT4-fs (mmcblk1p2): recovery complete
[ 4.986706] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.996436] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 5.007139] devtmpfs: mounted
[ 5.028362] Freeing unused kernel memory: 1024K
[ 5.034564] Run /sbin/init as init process
[ 5.606188] systemd[1]: System time before build time, advancing clock.
[ 5.710605] systemd[1]: systemd 243.2+ running in system mode. (-PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=hybrid)
[ 5.736335] systemd[1]: Detected architecture arm.
[ 5.799308] systemd[1]: Set hostname to <tqma6q-mba6x>.
[ 6.675645] systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket \xe2\x86\x92 /run/dbus/system_bus_socket; please update the unit file accordingly.
[ 7.024418] systemd[1]: /lib/systemd/system/rpcbind.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/rpcbind.sock \xe2\x86\x92 /run/rpcbind.sock; please update the unit file accordingly.
[ 7.088772] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.100144] systemd[1]: Created slice system-getty.slice.
[ 7.135611] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.146536] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 7.195582] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.206267] systemd[1]: Created slice User and Session Slice.
[ 7.247801] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ 7.287818] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 8.148199] random: crng init done
[ 8.151661] random: 7 urandom warning(s) missed due to ratelimiting
[ 8.613147] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[ 8.619572] ext4 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
[ 9.101979] systemd[297]: systemd-udevd.service: ProtectHostname=yes is configured, but the kernel does not support UTS namespaces, ignoring namespace setup.
[ 9.267307] systemd-journald[279]: Received client request to flush runtime journal.
[ 11.123314] input: gpio-buttons as /devices/soc0/gpio-buttons/input/input0
[ 11.127794] input: gpio-beeper as /devices/soc0/gpio-beeper/input/input1
[ 11.157434] mc: Linux media interface: v0.10
[ 11.172601] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.174915] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.176776] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.178815] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.219686] videodev: Linux video capture interface: v2.00
[ 11.401520] imx_media_common: module is from the staging directory, the quality is unknown, you have been warned.
[ 11.457916] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.460009] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.470667] imx6_media: module is from the staging directory, the quality is unknown, you have been warned.
[ 11.650219] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
[ 11.860185] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.869667] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.871503] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
[ 11.968879] spi spi0.0: spi_imx_setup: mode 0, 8 bpw, 50000000 hz
[ 11.972130] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 11.972637] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.016379] spi-nor spi0.0: n25q128a13
[ 12.020443] spi-nor spi0.0: spi_nor_info_init_params: 03
[ 12.035872] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.035951] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036037] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036102] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036459] spi-nor spi0.0: Header: 53
[ 12.040355] spi-nor spi0.0: Header: 46
[ 12.044198] spi-nor spi0.0: Header: 44
[ 12.073621] spi-nor spi0.0: Header: 50
[ 12.077592] spi-nor spi0.0: Header: 05
[ 12.081414] spi-nor spi0.0: Header: 01
[ 12.112231] spi-nor spi0.0: Header: 01
[ 12.134785] spi-nor spi0.0: Header: ff
[ 12.139506] spi-nor spi0.0: Header: 00
[ 12.143317] spi-nor spi0.0: Header: 05
[ 12.159246] spi-nor spi0.0: Header: 01
[ 12.163108] spi-nor spi0.0: Header: 10
[ 12.184776] spi-nor spi0.0: Header: 30
[ 12.188615] spi-nor spi0.0: Header: 00
[ 12.221040] spi-nor spi0.0: Header: 00
[ 12.244702] spi-nor spi0.0: Header: ff
[ 12.266541] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266706] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266788] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266866] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.267190] spi-nor spi0.0: bfpt addr=30 len=40
[ 12.285142] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285246] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285534] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285658] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.286591] spi-nor spi0.0: DMA transfer: -22
[ 12.286630] spi-nor spi0.0: Fallback to PIO mode
[ 12.296534] spi-nor spi0.0: bfpt: e5
[ 12.314782] spi-nor spi0.0: bfpt: 20
[ 12.344792] spi-nor spi0.0: bfpt: f1
[ 12.348426] spi-nor spi0.0: bfpt: ff
[ 12.352037] spi-nor spi0.0: bfpt: ff
[ 12.397380] spi-nor spi0.0: bfpt: ff
[ 12.416917] spi-nor spi0.0: bfpt: ff
[ 12.420597] spi-nor spi0.0: bfpt: 07
[ 12.424267] spi-nor spi0.0: bfpt: 29
[ 12.442571] spi-nor spi0.0: bfpt: eb
[ 12.458160] spi-nor spi0.0: bfpt: 27
[ 12.462405] Micrel KSZ9031 Gigabit PHY 2188000.ethernet-1:03: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:03, irq=104)
[ 12.467943] spi-nor spi0.0: bfpt: 6b
[ 12.510726] spi-nor spi0.0: bfpt: 27
[ 12.514394] spi-nor spi0.0: bfpt: 3b
[ 12.518667] spi-nor spi0.0: bfpt: 27
[ 12.534799] spi-nor spi0.0: bfpt: bb
[ 12.538425] spi-nor spi0.0: bfpt: ff
[ 12.542035] spi-nor spi0.0: bfpt: ff
[ 12.550887] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.554781] spi-nor spi0.0: bfpt: ff
[ 12.561370] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.574772] spi-nor spi0.0: bfpt: ff
[ 12.578560] spi-nor spi0.0: bfpt: ff
[ 12.582176] spi-nor spi0.0: bfpt: ff
[ 12.583566] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.585889] spi-nor spi0.0: bfpt: 27
[ 12.585908] spi-nor spi0.0: bfpt: bb
[ 12.585923] spi-nor spi0.0: bfpt: ff
[ 12.585938] spi-nor spi0.0: bfpt: ff
[ 12.585953] spi-nor spi0.0: bfpt: 29
[ 12.626081] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.656095] ipu1_csi0: Registered ipu1_csi0 capture as /dev/video0
[ 12.675198] ipu1_ic_prpenc: Registered ipu1_ic_prpenc capture as /dev/video1
[ 12.683695] spi-nor spi0.0: bfpt: eb
[ 12.687574] spi-nor spi0.0: bfpt: 0c
[ 12.691231] spi-nor spi0.0: bfpt: 20
[ 12.705004] ipu1_ic_prpvf: Registered ipu1_ic_prpvf capture as /dev/video2
[ 12.712086] imx-media: ipu1_csi0:1 -> ipu1_ic_prp:0
[ 12.717491] spi-nor spi0.0: bfpt: 10
[ 12.721154] spi-nor spi0.0: bfpt: d8
[ 12.734691] spi-nor spi0.0: bfpt: 00
[ 12.738348] spi-nor spi0.0: bfpt: 00
[ 12.741995] spi-nor spi0.0: bfpt: 00
[ 12.745946] imx-media: ipu1_csi0:1 -> ipu1_vdic:0
[ 12.750739] imx-media: ipu1_vdic:2 -> ipu1_ic_prp:0
[ 12.764770] spi-nor spi0.0: bfpt: 00
[ 12.768433] spi-nor spi0.0: bfpt: 35
[ 12.772076] spi-nor spi0.0: bfpt: 8a
[ 12.775953] imx-media: ipu1_ic_prp:1 -> ipu1_ic_prpenc:0
[ 12.781355] imx-media: ipu1_ic_prp:2 -> ipu1_ic_prpvf:0
[ 12.804725] spi-nor spi0.0: bfpt: 01
[ 12.808484] spi-nor spi0.0: bfpt: 00
[ 12.812131] spi-nor spi0.0: bfpt: 82
[ 12.816051] imx-media: subdev ipu1_csi0 bound
[ 12.822311] ipu1_csi1: Registered ipu1_csi1 capture as /dev/video3
[ 12.844770] spi-nor spi0.0: bfpt: a3
[ 12.848570] imx-media: ipu1_csi1:1 -> ipu1_ic_prp:0
[ 12.853600] imx-media: ipu1_csi1:1 -> ipu1_vdic:0
[ 12.858512] spi-nor spi0.0: bfpt: 03
[ 12.862158] spi-nor spi0.0: bfpt: cb
[ 12.865986] spi-nor spi0.0: bfpt: ac
[ 12.869667] spi-nor spi0.0: bfpt: c1
[ 12.873309] spi-nor spi0.0: bfpt: 04
[ 12.877400] imx-media: subdev ipu1_csi1 bound
[ 12.894954] ipu2_csi0: Registered ipu2_csi0 capture as /dev/video4
[ 12.902306] spi-nor spi0.0: bfpt: 2e
[ 12.906067] spi-nor spi0.0: bfpt: 7a
[ 12.909718] spi-nor spi0.0: bfpt: 75
[ 12.913391] spi-nor spi0.0: bfpt: 7a
[ 12.922719] ipu2_ic_prpenc: Registered ipu2_ic_prpenc capture as /dev/video5
[ 12.936367] ipu2_ic_prpvf: Registered ipu2_ic_prpvf capture as /dev/video6
[ 12.943584] imx-media: ipu2_csi0:1 -> ipu2_ic_prp:0
[ 12.954793] spi-nor spi0.0: bfpt: 75
[ 12.958625] spi-nor spi0.0: bfpt: fb
[ 12.962308] spi-nor spi0.0: bfpt: 00
[ 12.974773] imx-media: ipu2_csi0:1 -> ipu2_vdic:0
[ 12.994794] spi-nor spi0.0: bfpt: 00
[ 12.998462] spi-nor spi0.0: bfpt: 80
[ 13.002103] spi-nor spi0.0: bfpt: 08
[ 13.006025] imx-media: ipu2_vdic:2 -> ipu2_ic_prp:0
[ 13.010994] imx-media: ipu2_ic_prp:1 -> ipu2_ic_prpenc:0
[ 13.016510] spi-nor spi0.0: bfpt: 0f
[ 13.020173] spi-nor spi0.0: bfpt: 82
[ 13.023833] spi-nor spi0.0: bfpt: ff
[ 13.027699] imx-media: ipu2_ic_prp:2 -> ipu2_ic_prpvf:0
[ 13.032998] imx-media: subdev ipu2_csi0 bound
[ 13.054705] spi-nor spi0.0: bfpt: 81
[ 13.058330] spi-nor spi0.0: bfpt: 3d
[ 13.064247] ipu2_csi1: Registered ipu2_csi1 capture as /dev/video7
[ 13.071092] spi-nor spi0.0: bfpt: 00
[ 13.084715] imx-media: ipu2_csi1:1 -> ipu2_ic_prp:0
[ 13.089898] spi-nor spi0.0: bfpt: 00
[ 13.093519] spi-nor spi0.0: spi_nor_parse_bfpt: 03
[ 13.098731] imx-media: ipu2_csi1:1 -> ipu2_vdic:0
[ 13.103489] imx-media: subdev ipu2_csi1 bound
[ 13.114805] spi-nor spi0.0: spi_nor_parse_bfpt: 0c
[ 13.121796] spi-nor spi0.0: param headers: 03
[ 13.132542] spi-nor spi0.0: param headers: 00
[ 13.148607] spi-nor spi0.0: param headers: 01
[ 13.153245] spi-nor spi0.0: param headers: 02
[ 13.174355] spi-nor spi0.0: param headers: 00
[ 13.178882] spi-nor spi0.0: param headers: 01
[ 13.183279] spi-nor spi0.0: param headers: 00
[ 13.204795] spi-nor spi0.0: param headers: ff
[ 13.224825] spi-nor spi0.0: has uniform erase
[ 13.229237] spi-nor spi0.0: spi_nor_select_erase: 08
[ 13.234241] spi-nor spi0.0: n25q128a13 (16384 Kbytes)
[ 13.316374] coda 2040000.vpu: Direct firmware load for vpu_fw_imx6q.bin failed with error -2
[ 13.331434] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 13.355143] coda 2040000.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[ 13.383312] spi spi0.1: spi_imx_setup: mode 0, 8 bpw, 1000000 hz
[ 13.414032] spi_imx 2008000.spi: probed
[ 13.514940] spi spi4.0: spi_imx_setup: mode 0, 8 bpw, 1000000 hz
[ 13.517232] spi_imx 2018000.spi: probed
[ 13.680184] imx-tlv320aic32x4 sound: tlv320aic32x4-hifi <-> 2028000.ssi mapping ok
[ 13.693001] coda 2040000.vpu: Firmware code revision: 570363
[ 13.715442] coda 2040000.vpu: Initialized CODA960.
[ 13.720303] coda 2040000.vpu: Firmware version: 3.1.1
[ 13.746657] coda 2040000.vpu: encoder registered as video8
[ 13.757458] coda 2040000.vpu: decoder registered as video9
[ 14.365520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[ 14.373301] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[ 14.473634] smsc95xx 2-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
^ permalink raw reply
* [PATCH v2] dt-bindings: usb: ti,keystone-dwc3.yaml: Improve schema
From: Roger Quadros @ 2020-06-05 7:52 UTC (permalink / raw)
To: balbi; +Cc: robh+dt, devicetree, linux-kernel
In-Reply-To: <20200602124055.1680-1-rogerq@ti.com>
There were some review comments after the patch was integrated.
Address those.
Fixes: 1883a934e156 ("dt-bindings: usb: convert keystone-usb.txt to YAML")
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Changelog:
v2
- don't use quotes for enum/const string
- use phandle instead of phandle-array for phys
- add maxItems for phy-names
.../bindings/usb/ti,keystone-dwc3.yaml | 50 ++++++++++++++-----
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
index f127535feb0b..394e47d2f5d7 100644
--- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
@@ -11,64 +11,88 @@ maintainers:
properties:
compatible:
- oneOf:
- - const: "ti,keystone-dwc3"
- - const: "ti,am654-dwc3"
+ items:
+ - enum:
+ - ti,keystone-dwc3
+ - ti,am654-dwc3
reg:
maxItems: 1
- description: Address and length of the register set for the USB subsystem on
- the SOC.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
interrupts:
maxItems: 1
- description: The irq number of this device that is used to interrupt the MPU.
-
clocks:
+ $ref: /schemas/types.yaml#definitions/phandle-array
description: Clock ID for USB functional clock.
+ assigned-clocks:
+ $ref: /schemas/types.yaml#definitions/phandle-array
+
+ assigned-clock-parents:
+ $ref: /schemas/types.yaml#definitions/phandle-array
+
power-domains:
+ $ref: /schemas/types.yaml#definitions/phandle-array
description: Should contain a phandle to a PM domain provider node
and an args specifier containing the USB device id
value. This property is as per the binding,
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
phys:
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
PHY specifier for the USB3.0 PHY. Some SoCs need the USB3.0 PHY
to be turned on before the controller.
Documentation/devicetree/bindings/phy/phy-bindings.txt
phy-names:
+ maxItems: 1
items:
- - const: "usb3-phy"
+ - const: usb3-phy
+
+ dma-coherent: true
- dwc3:
+ dma-ranges: true
+
+patternProperties:
+ "usb@[a-f0-9]+$":
+ type: object
description: This is the node representing the DWC3 controller instance
Documentation/devicetree/bindings/usb/dwc3.txt
required:
- compatible
- reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
- interrupts
- - clocks
+
+additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- usb: usb@2680000 {
+ dwc3@2680000 {
compatible = "ti,keystone-dwc3";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x2680000 0x10000>;
clocks = <&clkusb>;
- clock-names = "usb";
interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>;
ranges;
- dwc3@2690000 {
+ usb@2690000 {
compatible = "synopsys,dwc3";
reg = <0x2690000 0x70000>;
interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>;
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* Re: Security Random Number Generator support
From: Neal Liu @ 2020-06-05 7:19 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Marc Zyngier
Cc: Neal Liu,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Sean Wang, lkml, wsd_upstream, Crystal Guo (郭晶),
Rob Herring, Linux Crypto Mailing List, Matt Mackall,
Matthias Brugger, linux-mediatek@lists.infradead.org,
Ard Biesheuvel, Linux ARM
In-Reply-To: <20200603093416.GY1551@shell.armlinux.org.uk>
On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> On Wed, Jun 03, 2020 at 08:40:58AM +0100, Marc Zyngier wrote:
> > On 2020-06-03 08:29, Neal Liu wrote:
> > > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> > > > On 2020-06-02 13:14, Ard Biesheuvel wrote:
> > > > > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@mediatek.com> wrote:
> > > > >>
> > > > >> These patch series introduce a security random number generator
> > > > >> which provides a generic interface to get hardware rnd from Secure
> > > > >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
> > > > >> Execution Environment(TEE), or even EL2 hypervisor.
> > > > >>
> > > > >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
> > > > >> For security awareness SoCs on ARMv8 with TrustZone enabled,
> > > > >> peripherals like entropy sources is not accessible from normal world
> > > > >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only.
> > > > >> This driver aims to provide a generic interface to Arm Trusted
> > > > >> Firmware or Hypervisor rng service.
> > > > >>
> > > > >>
> > > > >> changes since v1:
> > > > >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can
> > > > >> reuse
> > > > >> this driver.
> > > > >> - refine coding style and unnecessary check.
> > > > >>
> > > > >> changes since v2:
> > > > >> - remove unused comments.
> > > > >> - remove redundant variable.
> > > > >>
> > > > >> changes since v3:
> > > > >> - add dt-bindings for MediaTek rng with TrustZone enabled.
> > > > >> - revise HWRNG SMC call fid.
> > > > >>
> > > > >> changes since v4:
> > > > >> - move bindings to the arm/firmware directory.
> > > > >> - revise driver init flow to check more property.
> > > > >>
> > > > >> changes since v5:
> > > > >> - refactor to more generic security rng driver which
> > > > >> is not platform specific.
> > > > >>
> > > > >> *** BLURB HERE ***
> > > > >>
> > > > >> Neal Liu (2):
> > > > >> dt-bindings: rng: add bindings for sec-rng
> > > > >> hwrng: add sec-rng driver
> > > > >>
> > > > >
> > > > > There is no reason to model a SMC call as a driver, and represent it
> > > > > via a DT node like this.
> > > >
> > > > +1.
> > > >
> > > > > It would be much better if this SMC interface is made truly generic,
> > > > > and wired into the arch_get_random() interface, which can be used much
> > > > > earlier.
> > > >
> > > > Wasn't there a plan to standardize a SMC call to rule them all?
> > > >
> > > > M.
> > >
> > > Could you give us a hint how to make this SMC interface more generic in
> > > addition to my approach?
> > > There is no (easy) way to get platform-independent SMC function ID,
> > > which is why we encode it into device tree, and provide a generic
> > > driver. In this way, different devices can be mapped and then get
> > > different function ID internally.
> >
> > The idea is simply to have *one* single ID that caters for all
> > implementations, just like we did for PSCI at the time. This
> > requires ARM to edict a standard, which is what I was referring
> > to above.
>
> This sounds all too familiar.
>
> This kind of thing is something that ARM have seems to shy away from
> doing - it's a point I brought up many years ago when the whole
> trustzone thing first appeared with its SMC call. Those around the
> conference table were not interested - ARM seemed to prefer every
> vendor to do off and do their own thing with the SMC interface.
Does that mean it make sense to model a sec-rng driver, and get each
vendor's SMC function id by DT node?
>
> Then OMAP came along with its SMC interfaces, and so did the pain of
> not having a standardised way to configure the L2C when Linux was
> running in the non-secure world, resulting in stuff like l2c_configure
> etc, where each and every implementation has to supply a function to
> call its platform specific SMC interfaces to configure a piece of
> hardware common across many different platforms.
>
> ARM have seemed reluctant to standardise on stuff like this, so
> unless someone pushes hard for it from inside ARM, I doubt it will
> ever happen.
>
^ permalink raw reply
* Re: [PATCH v10 07/20] dt-bindings: mtd: Document boolean NAND ECC properties
From: Miquel Raynal @ 2020-06-05 7:18 UTC (permalink / raw)
To: Rob Herring
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Boris Brezillon, Thomas Petazzoni, linux-arm-kernel, Mason Yang,
Julien Su, Mark Rutland, devicetree
In-Reply-To: <20200604230804.GA13821@bogus>
Hi Rob,
Rob Herring <robh@kernel.org> wrote on Thu, 4 Jun 2020 17:08:04 -0600:
> On Wed, Jun 03, 2020 at 07:57:46PM +0200, Miquel Raynal wrote:
> > Document nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
> > The former is here to force software correction, the latter prevents
> > any correction to happen.
> >
> > These properties (along with nand-ecc-engine) are supposed to be more
> > accurate than the current nand-ecc-modes wich is very misleading and
> > very often people think it is mandatory while the core should be
> > relied upon to decide which correction to handle.
> >
> > nand-ecc-mode was already inacurate, but it becomes totally
> > problematic with setups where there are several hardware engines.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/mtd/nand-controller.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > index 0969d2e6720b..a3750978ebb8 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > @@ -68,6 +68,12 @@ patternProperties:
> > 3/ The ECC engine is external, in this case the phandle should
> > reference the specific ECC engine node.
> >
> > + nand-use-soft-ecc-engine: true
> > + description: Use a software ECC engine.
>
> Humm, I'm surprised this is valid YAML. nand-use-soft-ecc-engine can't
> be both a boolean and a map (aka schema, aka dict).
>
> nand-use-soft-ecc-engine:
> type: boolean
> description: ...
>
Ok, I might have been inspired from this line in example-schema.yaml:
interrupt-controller: true
# The core checks this is a boolean, so just have to list it here to be
# valid for this binding.
Thanks for the review, I'll correct it.
Cheers,
Miquèl
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Lee Jones @ 2020-06-05 6:57 UTC (permalink / raw)
To: Michael Walle, broonie
Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Mark Brown, Greg Kroah-Hartman, Andy Shevchenko
In-Reply-To: <20200604211039.12689-3-michael@walle.cc>
Mark, what do you think?
On Thu, 04 Jun 2020, Michael Walle wrote:
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
> - watchdog
> - GPIO controller
> - PWM controller
> - fan sensor
> - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> drivers/mfd/Kconfig | 19 ++++++++++
> drivers/mfd/Makefile | 2 ++
> drivers/mfd/sl28cpld.c | 79 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 100 insertions(+)
> create mode 100644 drivers/mfd/sl28cpld.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4f8b73d92df3..5c0cd514d197 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
> If you have an SGI Origin, Octane, or a PCI IOC3 card,
> then say Y. Otherwise say N.
>
> +config MFD_SL28CPLD
> + bool "Kontron sl28 core driver"
"Kontron SL28 Core Driver"
> + depends on I2C=y
> + depends on OF
> + select REGMAP_I2C
> + select MFD_CORE
> + help
> + This option enables support for the board management controller
> + found on the Kontron sl28 CPLD. You have to select individual
I can't find any reference to the "Kontron sl28 CPLD" online.
Is there a datasheet?
> + functions, such as watchdog, GPIO, etc, under the corresponding menus
> + in order to enable them.
> +
> + Currently supported boards are:
> +
> + Kontron SMARC-sAL28
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sl28cpld.
> +
> endmenu
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a..be59fb40aa28 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> +
> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o
> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
> new file mode 100644
> index 000000000000..a23194bb6efa
> --- /dev/null
> +++ b/drivers/mfd/sl28cpld.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD core for the sl28cpld.
Ideally this would match the Kconfig subject line.
> + * Copyright 2019 Kontron Europe GmbH
This is out of date.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#define SL28CPLD_VERSION 0x03
> +#define SL28CPLD_MIN_REQ_VERSION 14
> +
> +struct sl28cpld {
> + struct device *dev;
> + struct regmap *regmap;
> +};
Why do you need this structure?
> +static const struct regmap_config sl28cpld_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .reg_stride = 1,
> +};
> +
> +static int sl28cpld_probe(struct i2c_client *i2c)
> +{
> + struct sl28cpld *sl28cpld;
> + struct device *dev = &i2c->dev;
> + unsigned int cpld_version;
> + int ret;
> +
> + sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
> + if (!sl28cpld)
> + return -ENOMEM;
> +
> + sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
> + if (IS_ERR(sl28cpld->regmap))
> + return PTR_ERR(sl28cpld->regmap);
This is now a shared memory allocator and not an MFD at all.
I'm clamping down on these type of drivers!
Please find a better way to accomplish this.
Potentially using "simple-mfd" and "simple-regmap".
The former already exists and does what you want. The latter doesn't
yet exist, but could solve your and lots of other contributor's
issues.
Heck maybe I'll implement it myself if this keeps happening.
> + ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, &cpld_version);
> + if (ret)
> + return ret;
> +
> + if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
> + dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
> + return -ENODEV;
> + }
> +
> + sl28cpld->dev = dev;
> + i2c_set_clientdata(i2c, sl28cpld);
If the struct definition is in here, how do you use it elsewhere?
> + dev_info(dev, "successfully probed. CPLD version %d\n", cpld_version);
> +
> + return devm_of_platform_populate(&i2c->dev);
> +}
> +
> +static const struct of_device_id sl28cpld_of_match[] = {
> + { .compatible = "kontron,sl28cpld-r1", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
> +
> +static struct i2c_driver sl28cpld_driver = {
> + .probe_new = sl28cpld_probe,
> + .driver = {
> + .name = "sl28cpld",
> + .of_match_table = of_match_ptr(sl28cpld_of_match),
> + },
> +};
> +module_i2c_driver(sl28cpld_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] dt-bindings: clock: Add a missing include to MMP Audio Clock binding
From: Lubomir Rintel @ 2020-06-05 6:52 UTC (permalink / raw)
To: Stephen Boyd
Cc: Michael Turquette, Rob Herring, linux-clk, devicetree,
linux-kernel, Lubomir Rintel
The include file for input clock in the example was missing, breaking the
validation.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reported-by: Rob Herring <robh+dt@kernel.org>
---
.../devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
index ab6e82d1d3a9e..dffa73402da93 100644
--- a/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
@@ -59,6 +59,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/marvell,mmp2-audio.h>
+ #include <dt-bindings/clock/marvell,mmp2.h>
#include <dt-bindings/power/marvell,mmp2.h>
clock-controller@d42a0c30 {
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v8 10/14] media: platform: Delete redundant code for improving code quality
From: Xia Jiang @ 2020-06-05 6:41 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521154958.GI209565@chromium.org>
On Thu, 2020-05-21 at 15:49 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:29PM +0800, Xia Jiang wrote:
> > Delete unused member variables annotation.
> > Delete unused variable definition.
> > Delete redundant log print, because V4L2 debug logs already print it.
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 16 ++--------------
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 5 +++--
> > 2 files changed, 5 insertions(+), 16 deletions(-)
> >
>
> Thank you for the patch. Please see my comments inline.
>
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index 4e64046a6854..9e59b9a51ef0 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -182,7 +182,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > struct mtk_jpeg_ctx *ctx, int q_type)
> > {
> > struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> > - struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > int i;
> >
> > memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
> > @@ -190,7 +189,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> >
> > if (ctx->state != MTK_JPEG_INIT) {
> > mtk_jpeg_adjust_fmt_mplane(ctx, f);
> > - goto end;
> > + return 0;
> > }
> >
> > pix_mp->num_planes = fmt->colplanes;
> > @@ -210,7 +209,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
> > if (pfmt->sizeimage == 0)
> > pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
> > - goto end;
> > + return 0;
> > }
> >
> > /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
> > @@ -224,20 +223,9 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
> > u32 h = pix_mp->height * fmt->v_sample[i] / 4;
> >
> > - memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
>
> This change is not mentioned in the description. I'd suggest moving it
> to a separate patch, because it's a functional change.
>
> > pfmt->bytesperline = stride;
> > pfmt->sizeimage = stride * h;
> > }
> > -end:
> > - v4l2_dbg(2, debug, &jpeg->v4l2_dev, "wxh:%ux%u\n",
> > - pix_mp->width, pix_mp->height);
> > - for (i = 0; i < pix_mp->num_planes; i++) {
> > - v4l2_dbg(2, debug, &jpeg->v4l2_dev,
> > - "plane[%d] bpl=%u, size=%u\n",
> > - i,
> > - pix_mp->plane_fmt[i].bytesperline,
> > - pix_mp->plane_fmt[i].sizeimage);
> > - }
> > return 0;
> > }
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > index 64a731261214..9bbd615b1067 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > @@ -30,6 +30,9 @@
> >
> > #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
> >
> > +/**
> > + * enum mtk_jpeg_ctx_state - contex state of jpeg
>
> typo: s/contex/context/
>
> But I'd rephrase it to "states of the context state machine".
>
> > + */
>
> Not mentioned in the description. Also, the documentation of an enum
> should have descriptions for the values.
Done.
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v8 07/14] media: platform: Use kernel native functions for improving code quality
From: Xia Jiang @ 2020-06-05 6:41 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521154137.GG209565@chromium.org>
On Thu, 2020-05-21 at 15:41 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:26PM +0800, Xia Jiang wrote:
>
> Thank you for the patch. Please see my comments inline.
>
> nit: I'd remove "for improving code quality" from the subject, as it's
> obvious that we don't intend to make the code quality worse. ;)
> On the contrary, I'd make it more specific, e.g.
>
> media: mtk-jpeg: Use generic rounding helpers
>
> WDYT?
Done
>
> > Use clamp() to replace mtk_jpeg_bound_align_image() and round() to
> > replace mtk_jpeg_align().
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 41 +++++--------------
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 ++--
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 8 ++--
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 5 ---
> > 4 files changed, 19 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index 2fa3711fdc9b..4e64046a6854 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -157,25 +157,6 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct mtk_jpeg_ctx *ctx,
> > return NULL;
> > }
> >
> > -static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
> > - unsigned int wmax, unsigned int walign,
> > - u32 *h, unsigned int hmin,
> > - unsigned int hmax, unsigned int halign)
> > -{
> > - int width, height, w_step, h_step;
> > -
> > - width = *w;
> > - height = *h;
> > - w_step = 1 << walign;
> > - h_step = 1 << halign;
> > -
> > - v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
> > - if (*w < width && (*w + w_step) <= wmax)
> > - *w += w_step;
> > - if (*h < height && (*h + h_step) <= hmax)
> > - *h += h_step;
> > -}
> > -
> > static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
> > struct v4l2_format *f)
> > {
> > @@ -218,25 +199,25 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
> > struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[0];
> >
> > - mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > - MTK_JPEG_MAX_WIDTH, 0,
> > - &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > - MTK_JPEG_MAX_HEIGHT, 0);
> > + pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > + MTK_JPEG_MAX_HEIGHT);
> > + pix_mp->width = clamp(pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > + MTK_JPEG_MAX_WIDTH);
> >
> > memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
> > pfmt->bytesperline = 0;
> > /* Source size must be aligned to 128 */
> > - pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
> > + pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
> > if (pfmt->sizeimage == 0)
> > pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
> > goto end;
> > }
> >
> > /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
> > - mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > - MTK_JPEG_MAX_WIDTH, fmt->h_align,
> > - &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > - MTK_JPEG_MAX_HEIGHT, fmt->v_align);
> > + pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
> > + MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
> > + pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
> > + MTK_JPEG_MIN_WIDTH, MTK_JPEG_MAX_WIDTH);
> >
> > for (i = 0; i < fmt->colplanes; i++) {
> > struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[i];
> > @@ -751,8 +732,8 @@ static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
> > {
> > bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
> > bs->end_addr = bs->str_addr +
> > - mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
> > - bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
> > + round_up(vb2_get_plane_payload(src_buf, 0), 16);
> > + bs->size = round_up(vb2_plane_size(src_buf, 0), 128);
> > }
> >
> > static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > index 999bd1427809..28e9b30ad5c3 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > @@ -21,10 +21,10 @@
> > #define MTK_JPEG_FMT_TYPE_OUTPUT 1
> > #define MTK_JPEG_FMT_TYPE_CAPTURE 2
> >
> > -#define MTK_JPEG_MIN_WIDTH 32
> > -#define MTK_JPEG_MIN_HEIGHT 32
> > -#define MTK_JPEG_MAX_WIDTH 8192
> > -#define MTK_JPEG_MAX_HEIGHT 8192
> > +#define MTK_JPEG_MIN_WIDTH 32U
> > +#define MTK_JPEG_MIN_HEIGHT 32U
> > +#define MTK_JPEG_MAX_WIDTH 8192U
> > +#define MTK_JPEG_MAX_HEIGHT 8192U
>
> This change is not mentioned in the commit message. It should go to a
> separate patch, possibly merged with other really minor stylistic changes
> like this, e.g. patch 08/14.
Done
>
> Otherwise the patch looks good, so after addressing the above minor changes
> please feel free to add
>
> Reviewed-by: Tomasz Figa <tfiga@chromium.org>
>
> Best regards,
> Tomasz
>
^ permalink raw reply
* RE: [PATCH v3 10/10] net: eth: altera: update devicetree bindings documentation
From: Ooi, Joyce @ 2020-06-05 6:36 UTC (permalink / raw)
To: Rob Herring
Cc: David S . Miller, Jakub Kicinski, Thor Thayer,
netdev@vger.kernel.org, Rob Herring, See, Chin Liang,
linux-kernel@vger.kernel.org, Nguyen, Dinh, Westergreen, Dalon,
devicetree@vger.kernel.org, Dalon Westergreen, Tan, Ley Foon
In-Reply-To: <20200604222311.GA4151468@bogus>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Friday, June 5, 2020 6:23 AM
> To: Ooi, Joyce <joyce.ooi@intel.com>
> Cc: David S . Miller <davem@davemloft.net>; Jakub Kicinski
> <kuba@kernel.org>; Thor Thayer <thor.thayer@linux.intel.com>;
> netdev@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; See, Chin
> Liang <chin.liang.see@intel.com>; linux-kernel@vger.kernel.org; Nguyen,
> Dinh <dinh.nguyen@intel.com>; Westergreen, Dalon
> <dalon.westergreen@intel.com>; devicetree@vger.kernel.org; Dalon
> Westergreen <dalon.westergreen@linux.intel.com>; Tan, Ley Foon
> <ley.foon.tan@intel.com>
> Subject: Re: [PATCH v3 10/10] net: eth: altera: update devicetree bindings
> documentation
>
> On Thu, 04 Jun 2020 15:32:56 +0800, Ooi, Joyce wrote:
> > From: Dalon Westergreen <dalon.westergreen@intel.com>
> >
> > Update devicetree bindings documentation to include msgdma prefetcher
> > and ptp bindings.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dalon Westergreen <dalon.westergreen@intel.com>
> > Signed-off-by: Joyce Ooi <joyce.ooi@intel.com>
> > ---
> > v2: no change
> > v3: no change
> > ---
> > .../devicetree/bindings/net/altera_tse.txt | 103
> +++++++++++++++++----
> > 1 file changed, 84 insertions(+), 19 deletions(-)
> >
>
>
> Please add Acked-by/Reviewed-by tags when posting new versions.
> However, there's no need to repost patches *only* to add the tags. The
> upstream maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Noted, will do that next time.
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-05 6:30 UTC (permalink / raw)
To: Sudeep Holla
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <20200605045645.GD12397@bogus>
On Thu, Jun 4, 2020 at 11:56 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > >> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> > >> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> > >
> > Here another request is started before the first is finished.
>
> Ah, the prints are when the client requested. It is not when the mailbox
> started it. So this just indicates the beginning of the transfer from the
> client.
>
There maybe condition on a sensor read to finish within 1ms, but there
is no condition for the read to _start_ at this very moment (usually
there are sleeps in the path to sensor requests).
> > If you want this to work you have to serialise access to the single
> > physical channel and/or run the remote firmware in asynchronous mode -
> > that is, the firmware ack the bit as soon as it sees and starts
> > working in the background, so that we return in ~3usec always, while
> > the data returns whenever it is ready.
>
> Yes it does that for few requests like DVFS while it uses synchronous
> mode for few others. While ideally I agree everything in asynchronous
> most is better, I don't know there may be reasons for such design.
>
The reason is that, if the firmware works asynchronously, every call
would return in ~3usec and you won't think you need virtual channels.
You have shared only 'bad' log without serialising access. Please
share log after serialising access to the channel and the 'good' log
with virtual channels. That should put the topic to rest.
thanks.
^ permalink raw reply
* Re: [PATCH v4 00/11] Add support for Kontron sl28cpld
From: Lee Jones @ 2020-06-05 6:13 UTC (permalink / raw)
To: Michael Walle
Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Mark Brown, Greg Kroah-Hartman, Andy Shevchenko
In-Reply-To: <20200604211039.12689-1-michael@walle.cc>
On Thu, 04 Jun 2020, Michael Walle wrote:
> The Kontron sl28cpld is a board management chip providing gpio, pwm, fan
> monitoring and an interrupt controller. For now this controller is used on
> the Kontron SMARC-sAL28 board. But because of its flexible nature, it
> might also be used on other boards in the future. The individual blocks
> (like gpio, pwm, etc) are kept intentionally small. The MFD core driver
> then instantiates different (or multiple of the same) blocks. It also
> provides the register layout so it might be updated in the future without a
> device tree change; and support other boards with a different layout or
> functionalities.
>
> See also [1] for more information.
>
> This is my first take of a MFD driver. I don't know whether the subsystem
> maintainers should only be CCed on the patches which affect the subsystem
> or on all patches for this series. I've chosen the latter so you can get a
> more complete picture.
You chose wisely. :)
> [1] https://lore.kernel.org/linux-devicetree/0e3e8204ab992d75aa07fc36af7e4ab2@walle.cc/
>
> Changes since v3:
> - use of_platform_populate() to populate internal devices using the
> internal register offsets as unit-addresses
> - because we don't use mfd_cells anymore, we cannot use IORESOURCE_REG,
> but instead parse the reg property in each individual driver
> - dropped the following patches because they were already merged:
> gpiolib: Introduce gpiochip_irqchip_add_domain()
> gpio: add a reusable generic gpio_chip using regmap
> - dropped the following patches because they are no longer needed:
> include/linux/ioport.h: add helper to define REG resource constructs
> mfd: mfd-core: Don't overwrite the dma_mask of the child device
> mfd: mfd-core: match device tree node against reg property
> - rephrase commit messages, as suggested by Thomas Gleixner
It's great to have this changelog overview.
However it's equally, if not arguably more important to have a more
fine grained changelog in each of the patches, usually placed between
the '---' and the diff stat.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v8 05/14] media: platform: Improve power on and power off flow
From: Xia Jiang @ 2020-06-05 6:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521152253.GE209565@chromium.org>
On Thu, 2020-05-21 at 15:22 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:24PM +0800, Xia Jiang wrote:
> > Call pm_runtime_get_sync() before starting a frame and then
> > pm_runtime_put() after completing it. This can save power for the time
> > between processing two frames.
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 27 +++++--------------
> > 1 file changed, 6 insertions(+), 21 deletions(-)
> >
>
> Thank you for the patch. Please see my comments inline.
>
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index a536fa95b3d6..dd5cadd101ef 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
> > return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > }
> >
> > -static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
> > -{
> > - struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> > - struct vb2_v4l2_buffer *vb;
> > - int ret = 0;
> > -
> > - ret = pm_runtime_get_sync(ctx->jpeg->dev);
> > - if (ret < 0)
> > - goto err;
> > -
> > - return 0;
> > -err:
> > - while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> > - v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
> > - return ret;
> > -}
> > -
> > static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> > {
> > struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> > @@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> >
> > while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> > -
> > - pm_runtime_put_sync(ctx->jpeg->dev);
> > }
> >
> > static const struct vb2_ops mtk_jpeg_qops = {
> > @@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
> > .buf_queue = mtk_jpeg_buf_queue,
> > .wait_prepare = vb2_ops_wait_prepare,
> > .wait_finish = vb2_ops_wait_finish,
> > - .start_streaming = mtk_jpeg_start_streaming,
> > .stop_streaming = mtk_jpeg_stop_streaming,
> > };
> >
> > @@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
> > struct mtk_jpeg_src_buf *jpeg_src_buf;
> > struct mtk_jpeg_bs bs;
> > struct mtk_jpeg_fb fb;
> > - int i;
> > + int i, ret;
> >
> > src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > @@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
> > return;
> > }
> >
> > + ret = pm_runtime_get_sync(jpeg->dev);
> > + if (ret < 0)
> > + goto dec_end;
> > +
> > mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs);
> > if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb))
> > goto dec_end;
> > @@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> > v4l2_m2m_buf_done(src_buf, buf_state);
> > v4l2_m2m_buf_done(dst_buf, buf_state);
> > v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > + pm_runtime_put_sync(ctx->jpeg->dev);
>
> The _sync variant explicitly waits until the asynchronous PM operation
> completes. This is usually undesired, because the CPU stays blocked for
> no good reason. In this context it is actually a bug, because this is an
> interrupt handler and it's not allowed to sleep. I wonder why this
> actually didn't crash in your testing. Please change to the regular
> pm_runtime_put().
Done.
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v8 04/14] media: platform: Change the fixed device node number to unfixed value
From: Xia Jiang @ 2020-06-05 6:02 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521135937.GD209565@chromium.org>
On Thu, 2020-05-21 at 13:59 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:23PM +0800, Xia Jiang wrote:
> > Change device node number from 3 to -1 because that the driver will
> > also support jpeg encoder.
> >
>
> Thanks for the patch. The change is correct, but I think the commit
> message doesn't really explain the real reason for it. Perhaps something
> like
>
> "The driver can be instantiated multiple times, e.g. for a decoder and
> an encoder. Moreover, other drivers could coexist on the same system.
> This makes the static video node number assignment pointless, so switch
> to automatic assignment instead."
>
> WDYT?
Dear Tomasz,
Thanks for your advice.I have changed it in new v9 .
Best Regards,
Xia Jiang
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-05 4:56 UTC (permalink / raw)
To: Jassi Brar
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, Sudeep Holla, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <CABb+yY27Ngb0C-onkU2qyt=uKgG4iVrcv8hGkC+anypQbTRA1w@mail.gmail.com>
On Thu, Jun 04, 2020 at 10:15:55AM -0500, Jassi Brar wrote:
> On Thu, Jun 4, 2020 at 4:20 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Jun 03, 2020 at 01:32:42PM -0500, Jassi Brar wrote:
> > > On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > >
> > > > On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > > > > On 28-05-20, 13:20, Rob Herring wrote:
> > > > > > Whether Linux
> > > > > > requires serializing mailbox accesses is a separate issue. On that side,
> > > > > > it seems silly to not allow driving the h/w in the most efficient way
> > > > > > possible.
> > > > >
> > > > > That's exactly what we are trying to say. The hardware allows us to
> > > > > write all 32 bits in parallel, without any hardware issues, why
> > > > > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > > > > facing issues with hardware access because of lockdown right now)
> > > >
> > > > OK, I was able to access the setup today. I couldn't reach a point
> > > > where I can do measurements as the system just became unusable with
> > > > one physical channel instead of 2 virtual channels as in my patches.
> > > >
> > > > My test was simple. Switch to schedutil and read sensors periodically
> > > > via sysfs.
> > > >
> > > > arm-scmi firmware:scmi: message for 1 is not expected!
> > > >
> > > This sounds like you are not serialising requests on a shared channel.
> > > Can you please also share the patch?
> >
> > OK, I did try with a small patch initially and then realised we must hit
> > issue with mainline as is. Tried and the behaviour is exact same. All
> > I did is removed my patches and use bit[0] as the signal. It doesn't
> > matter as writes to the register are now serialised. Oh, the above
> > message comes when OS times out in advance while firmware continues to
> > process the old request and respond.
> >
> > The trace I sent gives much better view of what's going on.
> >
> BTW, you didn't even share 'good' vs 'bad' log for me to actually see
> if the api lacks.
>
> Let us look closely ...
>
> >> bash-1019 [005] 1149.452340: scmi_xfer_begin:
> transfer_id=1537 msg_id=7 protocol_id=19 seq=0 poll=1
> >> bash-1019 [005] 1149.452407: scmi_xfer_end:
> transfer_id=1537 msg_id=7 protocol_id=19 seq=0 status=0
> >
> This round trip took 67usecs. (log shows some at even 3usecs)
> That includes mailbox api overhead, memcpy and the time taken by
> remote to respond.
This is DVFS request which firmware acknowledges quickly and expected
to at most 100us.
> So the api is definitely capable of much faster transfers than you require.
>
I am not complaining about that. The delay is mostly due to the load on
the mailbox and parallelising helps is the focus here.
> >> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> >> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> >
> Here another request is started before the first is finished.
Ah, the prints are when the client requested. It is not when the mailbox
started it. So this just indicates the beginning of the transfer from the
client. I must have mentioned that earlier. Some request timeout before
being picked up by mailbox if the previous request is not acknowledge
quickly. E.g. Say a sensor command started which may take upto 1ms,
almost 5-6 DVFS request after that will timeout.
> If you want this to work you have to serialise access to the single
> physical channel and/or run the remote firmware in asynchronous mode -
> that is, the firmware ack the bit as soon as it sees and starts
> working in the background, so that we return in ~3usec always, while
> the data returns whenever it is ready.
Yes it does that for few requests like DVFS while it uses synchronous
mode for few others. While ideally I agree everything in asynchronous
most is better, I don't know there may be reasons for such design. Also
the solution given is to use different bits as independent channels
which hardware allows. Anyways it's open source SCP project[1].
--
Regards,
Sudeep
[1] https://github.com/ARM-software/SCP-firmware
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: pm8150x: add thermal alarms and thermal zones
From: Vinod Koul @ 2020-06-05 4:39 UTC (permalink / raw)
To: Dmitry Baryshkov, Amit Kucheria
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <8df3fe11-867f-b6a3-fe29-5a8ab988e006@linaro.org>
Sorry missed ccing Amit, done now.
On 04-06-20, 18:03, Dmitry Baryshkov wrote:
> On 04/06/2020 13:47, Vinod Koul wrote:
> > On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> > > pm8150_adc: adc@3100 {
> > > compatible = "qcom,spmi-adc5";
> > > reg = <0x3100>;
> > > @@ -38,8 +47,6 @@ pm8150_adc: adc@3100 {
> > > #io-channel-cells = <1>;
> > > interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> > > - status = "disabled";
> > > -
> >
> > This should not be removed, rather than this please add enabled in you
> > board dts file
...
> > > +&thermal_zones {
> > > + pm8150_temp {
> > > + polling-delay-passive = <0>;
> > > + polling-delay = <0>;
> > > +
> > > + thermal-sensors = <&pm8150_temp>;
> > > +
> > > + trips {
> > > + trip0 {
> > > + temperature = <95000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > +
> > > + trip1 {
> > > + temperature = <115000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > +
> > > + trip2 {
> > > + temperature = <145000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > + };
> > > +
> > > + };
> >
> > Not sure about this, Amit..? Should this also not be in board dts?
> >
> > Similar comments on similar ones for rest of the patch as well..
>
> I'm not so sure. This part of the configuration seems generic to me. Unlike
> adc-tm config, which definitely goes to the board file.
I think the temperature values may be board specific, Amit can confirm
that. If that is the case then this belongs to board dts, otherwise here :)
> I can split this into a separate pm8150-temp.dtsi file. Does that sound
> better?
That might make it worse, we don't do splitting.
--
~Vinod
^ permalink raw reply
* [PATCH 2/2] ASoC: dt-bindings: add compatible string for MAX98360A
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
In-Reply-To: <20200605034931.107713-1-tzungbi@google.com>
Maxim MAX98360A audio amplifier is functionally identical to MAX98357A.
Adds compatible string "maxim,max98360a" for driver reuse.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
---
.../devicetree/bindings/sound/max98357a.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/max98357a.txt b/Documentation/devicetree/bindings/sound/max98357a.txt
index 4bce14ce806f..75db84d06240 100644
--- a/Documentation/devicetree/bindings/sound/max98357a.txt
+++ b/Documentation/devicetree/bindings/sound/max98357a.txt
@@ -1,9 +1,10 @@
-Maxim MAX98357A audio DAC
+Maxim MAX98357A/MAX98360A audio DAC
-This node models the Maxim MAX98357A DAC.
+This node models the Maxim MAX98357A/MAX98360A DAC.
Required properties:
-- compatible : "maxim,max98357a"
+- compatible : "maxim,max98357a" for MAX98357A.
+ "maxim,max98360a" for MAX98360A.
Optional properties:
- sdmode-gpios : GPIO specifier for the chip's SD_MODE pin.
@@ -20,3 +21,8 @@ max98357a {
compatible = "maxim,max98357a";
sdmode-gpios = <&qcom_pinmux 25 0>;
};
+
+max98360a {
+ compatible = "maxim,max98360a";
+ sdmode-gpios = <&qcom_pinmux 25 0>;
+};
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply related
* [PATCH 1/2] ASoC: max98357a: add compatible string for MAX98360A
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
In-Reply-To: <20200605034931.107713-1-tzungbi@google.com>
Maxim MAX98360A audio amplifier is functionally identical to MAX98357A.
Adds compatible string "maxim,max98360a" for driver reuse.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
---
sound/soc/codecs/max98357a.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index a8bd793a7867..4f431133d0bb 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -125,6 +125,7 @@ static int max98357a_platform_probe(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id max98357a_device_id[] = {
{ .compatible = "maxim,max98357a" },
+ { .compatible = "maxim,max98360a" },
{}
};
MODULE_DEVICE_TABLE(of, max98357a_device_id);
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply related
* [PATCH 0/2] ASoC: max98357a: support MAX98360A in OF
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
Commit 1a0f2433d738 ("ASoC: max98357a: Add ACPI HID MAX98360A") supports
MAX98360A in ACPI world. This series supports MAX98360A in OF world.
Tzung-Bi Shih (2):
ASoC: max98357a: add compatible string for MAX98360A
ASoC: dt-bindings: add compatible string for MAX98360A
.../devicetree/bindings/sound/max98357a.txt | 12 +++++++++---
sound/soc/codecs/max98357a.c | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply
* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2020-06-05 3:28 UTC (permalink / raw)
To: Sakari Ailus
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男), dongchun.zhu
In-Reply-To: <20200604081032.GG16711@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-06-04 at 11:10 +0300, Sakari Ailus wrote:
> On Thu, Jun 04, 2020 at 10:33:38AM +0800, Dongchun Zhu wrote:
> > Hi Tomasz,
> >
> > On Mon, 2020-06-01 at 20:47 +0200, Tomasz Figa wrote:
> > > On Wed, May 27, 2020 at 11:03 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On Mon, 2020-05-25 at 13:45 +0200, Tomasz Figa wrote:
> > > > > On Fri, May 22, 2020 at 11:27 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Tomasz,
> > > > > >
> > > > > > Thanks for the review. My replies are as below.
> > > > > >
> > > > > > On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> > > > > > > Hi Dongchun, Sakari,
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > > > > [snip]
> > > > > > > > + pm_runtime_enable(dev);
> > > > > > > > + if (!pm_runtime_enabled(dev)) {
> > > > > > > > + ret = dw9768_runtime_resume(dev);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > > > > > > + goto entity_cleanup;
> > > > > > > > + }
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > > > > > > > + if (ret < 0)
> > > > > > > > + goto entity_cleanup;
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +
> > > > > > > > +entity_cleanup:
> > > > > > >
> > > > > > > Need to power off if the code above powered on.
> > > > > > >
> > > > > >
> > > > > > Thanks for the reminder.
> > > > > > If there is something wrong with runtime PM, actuator is to be powered
> > > > > > on via dw9768_runtime_resume() API.
> > > > > > When actuator sub-device is powered on completely and async registered
> > > > > > successfully, we shall power off it afterwards.
> > > > > >
> > > > >
> > > > > The code above calls dw9768_runtime_resume() if
> > > > > !pm_runtime_enabled(dev), but the clean-up code below the
> > > > > entity_cleanup label doesn't have the corresponding
> > > > > dw9768_runtime_suspend() call.
> > > > >
> > > >
> > > > Did you mean the 'entity_cleanup' after v4l2_async_register_subdev()?
> > >
> > > Yes.
> > >
> > > > Actually I made some changes for OV02A V9, according to this comment.
> > > > Could you help review that change? Thanks.
> > >
> > > Sure, I will take a look.
> > >
> >
> > Thanks.
> > Sorry, I just wanna make sure the change is okay for next release.
> > May we use the check like OV02A V9 did?
> > ret = v4l2_async_register_subdev(&dw9768->sd);
> > if (ret < 0) {
> > if (!pm_runtime_enabled(dev))
> > dw9768_runtime_suspend(dev);
>
> Please do this part where you're jumping to, if possible.
>
Fine.
Fixed in next release.
> > goto entity_cleanup;
> > }
> >
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox