* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: André Przywara @ 2020-06-03 11:20 UTC (permalink / raw)
To: Rob Herring
Cc: Guenter Roeck, Sudeep Holla, Liviu Dudau, Lorenzo Pieralisi,
Mark Rutland, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqLgNDd-+rrYD=Y0Hm=NaV7f0NbBFb9uhhYhzM6LjxnXZg@mail.gmail.com>
On 02/06/2020 00:12, Rob Herring wrote:
Hi,
> On Mon, Jun 1, 2020 at 4:15 AM André Przywara <andre.przywara@arm.com> wrote:
>>
>> On 28/05/2020 14:30, André Przywara wrote:
>>
>> Hi,
>>
>>> On 28/05/2020 03:48, Guenter Roeck wrote:
>>>
>>> Hi Guenter,
>>>
>>>> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
>>>>> The devicetree compiler complains when DT nodes without a reg property
>>>>> live inside a (simple) bus node:
>>>>> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
>>>>> missing or empty reg/ranges property
>>>>>
>>>>> Move the fixed clocks, the fixed regulator, the leds and the config bus
>>>>> subtree to the root node, since they do not depend on any busses.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>
>>>> This patch results in tracebacks when booting the vexpress-a15 machine
>>>> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
>>>> as the subsequent patches affecting the same file (to avoid revert
>>>> conflicts) fixes the problem.
>>>
>>> Many thanks for the heads up! I was able to reproduce it here. On the
>>> first glance it looks like the UART is probed before the clocks now,
>>> because the traversal of the changed DT leads to a different probe
>>> order. I will look into how to fix this.
>>
>> Turned out to be a bit more complicated:
>> The arm,vexpress,config-bus driver walks up the device tree to find a
>> arm,vexpress,site property [1]. With this patch the first parent node
>> with that property it finds is now the root node, with the wrong site ID
>> (0xf instead of 0x0). So it queries the wrong clocks (those IDs are
>> actually reserved there), and QEMU reports back "0", consequently [2].
>> Finding a clock frequency in the range of [0, 0] won't get very far.
>>
>> Possible solutions are:
>> 1) Just keep the mcc and its children at where it is in mainline right
>> now, so *partly* reverting this patch. This has the problem of still
>> producing a dtc warning, so kind of defeats the purpose of this patch.
>>
>> 2) Add a "arm,vexpress,site = <0>;" line to the "mcc" node itself.
>> Works, but looks somewhat dodgy, as the mcc node should really be a
>> child of the motherboard node, and we should not hack around this.
>>
>> 3) Dig deeper and fix the DT in a way that makes dtc happy. Might
>> involve (dummy?) ranges or reg properties. My gut feeling is that
>> arm,vexpress-sysreg,func should really have been "reg" in the first
>> place, but that's too late to change now, anyway.
>>
>> I will post 2) as a fix if 3) turns out to be not feasible.
>
> I would just do 1).
>
> To some extent, the warnings are for avoiding poor design on new
> bindings. We need a way to distinguish between existing boards and new
> ones. Maybe dts needs to learn some warning disable annotations or we
> need per target warning settings (DTC_FLAGS_foo.dtb ?). Or maybe this
> check is just too strict.
So I was always wondering about this check, actually. A simple-bus
describes a bus which is mapped into the CPU address space (in contrast
to say an I2C bus, for instance). So children of this bus node typically
have a reg property.
Now also those simple-bus nodes seem to be used to logically group
hardware in a DT (see this "motherboard" node here). *If* we go with
this, we should also allow other subnodes, for instance fixed-clocks:
after all there is probably an actual fixed crystal oscillator on the
motherboard, so it would also belong in there.
I see that (ab)using simple-bus for *just* grouping nodes is probably
not a good design, but I don't see why *every* child must be mapped into
the address space.
Maybe dtc's simple-bus check should indeed be relaxed, to just require
*at least one* child with a reg or ranges property, but also allow other
nodes?
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v3 1/6] PCI: dwc: Add msi_host_isr() callback
From: Marc Zyngier @ 2020-06-03 11:15 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, linux-pci, devicetree,
linux-arm-kernel, linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1591174481-13975-2-git-send-email-hayashi.kunihiko@socionext.com>
On 2020-06-03 09:54, Kunihiko Hayashi wrote:
> This adds msi_host_isr() callback function support to describe
> SoC-dependent service triggered by MSI.
>
> For example, when AER interrupt is triggered by MSI, the callback
> function
> reads SoC-dependent registers and detects that the interrupt is from
> AER,
> and invoke AER interrupts related to MSI.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 0a4a5aa..9b628a2 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -112,13 +112,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port
> *pp)
> static void dw_chained_msi_isr(struct irq_desc *desc)
> {
> struct irq_chip *chip = irq_desc_get_chip(desc);
> - struct pcie_port *pp;
> + struct pcie_port *pp = irq_desc_get_handler_data(desc);
>
> - chained_irq_enter(chip, desc);
> + if (pp->ops->msi_host_isr)
> + pp->ops->msi_host_isr(pp);
Why is this call outside of the enter/exit guards?
Do you still need to execute the standard handler?
>
> - pp = irq_desc_get_handler_data(desc);
> + chained_irq_enter(chip, desc);
> dw_handle_msi_irq(pp);
> -
> chained_irq_exit(chip, desc);
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 656e00f..e741967 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
> void (*scan_bus)(struct pcie_port *pp);
> void (*set_num_vectors)(struct pcie_port *pp);
> int (*msi_host_init)(struct pcie_port *pp);
> + void (*msi_host_isr)(struct pcie_port *pp);
> };
>
> struct pcie_port {
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: Security Random Number Generator support
From: Marc Zyngier @ 2020-06-03 11:12 UTC (permalink / raw)
To: Neal Liu
Cc: Julius Werner, Ard Biesheuvel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Sean Wang,
linux-mediatek, lkml, wsd_upstream, Rob Herring,
Linux Crypto Mailing List, Matt Mackall, Matthias Brugger,
Crystal Guo (郭晶), Linux ARM, mark.rutland,
Jose.Marinho
In-Reply-To: <1591170857.19414.5.camel@mtkswgap22>
On 2020-06-03 08:54, Neal Liu wrote:
> On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
>> On 2020-06-03 08:29, Neal Liu wrote:
[...]
>> > 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.
>>
>> There is zero benefit in having a platform-dependent ID. It just
>> pointlessly increases complexity, and means we cannot use the RNG
>> before the firmware tables are available (yes, we need it that
>> early).
>>
>> M.
>
> Do you know which ARM expert could edict this standard?
> Or is there any chance that we can make one? And be reviewed by
> maintainers?
Sudeep already mentioned Jose's effort to offer a standard.
Hopefully he will *soon* be able to give us something that can be
implemented everywhere (firmware, kernel, but also hypervisors),
as the need exists across the whole stack.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] ASoC: wm8960: Support headphone jack detection function
From: Shengjiu Wang @ 2020-06-03 10:26 UTC (permalink / raw)
To: perex, tiwai, lgirdwood, broonie, ckeepax, allison, info, tglx,
patches, alsa-devel, linux-kernel, robh+dt, devicetree
In-Reply-To: <1591180013-12416-1-git-send-email-shengjiu.wang@nxp.com>
Add two platform variables for headphone jack detection.
"hp_cfg" is for configuration of heaphone jack detection.
"gpio_cfg" is for configuration of gpio, the gpio is used
for plug & unplug interrupt on SoC.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
include/sound/wm8960.h | 17 +++++++++++++++++
sound/soc/codecs/wm8960.c | 20 ++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/include/sound/wm8960.h b/include/sound/wm8960.h
index d22e84805025..275fd5b201ce 100644
--- a/include/sound/wm8960.h
+++ b/include/sound/wm8960.h
@@ -16,6 +16,23 @@ struct wm8960_data {
bool capless; /* Headphone outputs configured in capless mode */
bool shared_lrclk; /* DAC and ADC LRCLKs are wired together */
+
+ /*
+ * Setup for headphone detection
+ *
+ * hp_cfg[0]: HPSEL[1:0] of R48 (Additional Control 4)
+ * hp_cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2).
+ * hp_cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1).
+ */
+ u32 hp_cfg[3];
+
+ /*
+ * Setup for gpio configuration
+ *
+ * gpio_cfg[0]: ALRCGPIO of R9 (Audio interface)
+ * gpio_cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4).
+ */
+ u32 gpio_cfg[2];
};
#endif
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 6cf0f6612bda..2f7f0493144a 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -1389,6 +1389,12 @@ static void wm8960_set_pdata_from_of(struct i2c_client *i2c,
if (of_property_read_bool(np, "wlf,shared-lrclk"))
pdata->shared_lrclk = true;
+
+ of_property_read_u32_array(np, "wlf,gpio-cfg", pdata->gpio_cfg,
+ ARRAY_SIZE(pdata->gpio_cfg));
+
+ of_property_read_u32_array(np, "wlf,hp-cfg", pdata->hp_cfg,
+ ARRAY_SIZE(pdata->hp_cfg));
}
static int wm8960_i2c_probe(struct i2c_client *i2c,
@@ -1446,6 +1452,20 @@ static int wm8960_i2c_probe(struct i2c_client *i2c,
regmap_update_bits(wm8960->regmap, WM8960_LOUT2, 0x100, 0x100);
regmap_update_bits(wm8960->regmap, WM8960_ROUT2, 0x100, 0x100);
+ /* ADCLRC pin configured as GPIO. */
+ regmap_update_bits(wm8960->regmap, WM8960_IFACE2, 1 << 6,
+ wm8960->pdata.gpio_cfg[0] << 6);
+ regmap_update_bits(wm8960->regmap, WM8960_ADDCTL4, 0xF << 4,
+ wm8960->pdata.gpio_cfg[1] << 4);
+
+ /* Enable headphone jack detect */
+ regmap_update_bits(wm8960->regmap, WM8960_ADDCTL4, 3 << 2,
+ wm8960->pdata.hp_cfg[0] << 2);
+ regmap_update_bits(wm8960->regmap, WM8960_ADDCTL2, 3 << 5,
+ wm8960->pdata.hp_cfg[1] << 5);
+ regmap_update_bits(wm8960->regmap, WM8960_ADDCTL1, 3,
+ wm8960->pdata.hp_cfg[2]);
+
i2c_set_clientdata(i2c, wm8960);
ret = devm_snd_soc_register_component(&i2c->dev,
--
2.21.0
^ permalink raw reply related
* [PATCH 1/2] ASoC: bindings: wm8960: Add property for headphone detection
From: Shengjiu Wang @ 2020-06-03 10:26 UTC (permalink / raw)
To: perex, tiwai, lgirdwood, broonie, ckeepax, allison, info, tglx,
patches, alsa-devel, linux-kernel, robh+dt, devicetree
Add two properties for headphone detection.
wlf,hp-cfg: A list of headphone jack detect configuration register values
wlf,gpio-cfg: A list of GPIO configuration register values
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
Documentation/devicetree/bindings/sound/wm8960.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/wm8960.txt b/Documentation/devicetree/bindings/sound/wm8960.txt
index 6d29ac3750ee..85d3b287108c 100644
--- a/Documentation/devicetree/bindings/sound/wm8960.txt
+++ b/Documentation/devicetree/bindings/sound/wm8960.txt
@@ -21,6 +21,17 @@ Optional properties:
enabled and disabled together with HP_L and HP_R pins in response to jack
detect events.
+ - wlf,hp-cfg: A list of headphone jack detect configuration register values.
+ The list must be 3 entries long.
+ hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4).
+ hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2).
+ hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1).
+
+ - wlf,gpio-cfg: A list of GPIO configuration register values.
+ The list must be 2 entries long.
+ gpio-cfg[0]: ALRCGPIO of R9 (Audio interface)
+ gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4).
+
Example:
wm8960: codec@1a {
--
2.21.0
^ permalink raw reply related
* Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
From: Adrian Ratiu @ 2020-06-03 10:28 UTC (permalink / raw)
To: Emil Velikov, Adrian Ratiu
Cc: devicetree@vger.kernel.org, Jernej Skrabec, Benjamin GAIGNARD,
Adrian Pop, Jonas Karlman, Philippe CORNU,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Yannick FERTRE, linux-rockchip@lists.infradead.org, Andrzej Hajda,
Laurent Pinchart, Arnaud Ferraris, kernel@collabora.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com
In-Reply-To: <CACvgo51QyzEa8LFpGq5zjYV-0TifQRtNh4WhMYy8jNtaswxd7Q@mail.gmail.com>
On Tue, 02 Jun 2020, Emil Velikov <emil.l.velikov@gmail.com>
wrote:
> Hi Adrian,
Hi Email,
>
> On Mon, 1 Jun 2020 at 10:14, Adrian Ratiu
> <adrian.ratiu@collabora.com> wrote:
>>
>> On Fri, 29 May 2020, Philippe CORNU <philippe.cornu@st.com>
>> wrote:
>> > Hi Adrian, and thank you very much for the patchset. Thank
>> > you also for having tested it on STM32F769 and STM32MP1.
>> > Sorry for the late response, Yannick and I will review it as
>> > soon as possible and we will keep you posted. Note: Do not
>> > hesitate to put us in copy for the next version
>> > (philippe.cornu@st.com, yannick.fertre@st.com) Regards,
>> > Philippe :-)
>>
>> Hi Philippe,
>>
>> Thank you very much for your previous and future STM testing,
>> really appreciate it! I've CC'd Yannick until now but I'll also
>> CC you sure :)
>>
>> It's been over a month since I posted v8 and I was just gearing
>> up to address all feedback, rebase & retest to prepare v9 but
>> I'll wait a little longer, no problem, it's no rush.
>>
> Small idea, pardon for joining so late:
>
> Might be a good idea to add inline comment, why the clocks are
> disabled so late. Effectively a 2 line version of the commit
> summary.
>
> Feel free to make that a separate/follow-up patch.
Thanks, I'll add the comment to this patch in v9.
>
> -Emil
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCHv3 1/7] dt-bindings: crypto: Add TI SA2UL crypto accelerator documentation
From: Tero Kristo @ 2020-06-03 10:01 UTC (permalink / raw)
To: Rob Herring; +Cc: herbert, davem, Keerthy, devicetree, linux-crypto
In-Reply-To: <20200528152341.GA103581@bogus>
On 28/05/2020 18:23, Rob Herring wrote:
> On Thu, 14 May 2020 15:50:05 +0300, Tero Kristo wrote:
>> From: Keerthy <j-keerthy@ti.com>
>>
>> The Security Accelerator Ultra Lite (SA2UL) subsystem provides hardware
>> cryptographic acceleration for the following use cases:
>>
>> * Encryption and authentication for secure boot
>> * Encryption and authentication of content in applications
>> requiring DRM (digital rights management) and
>> content/asset protection
>>
>> SA2UL provides support for number of different cryptographic algorithms
>> including SHA1, SHA256, SHA512, AES, 3DES, and various combinations of
>> the previous for AEAD use.
>>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> [t-kristo@ti.com: converted documentation to yaml]
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> v3:
>> - fixed a typo in rng child node regex
>>
>> .../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++++++++++++++++++
>> 1 file changed, 76 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
>>
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks Rob,
Herbert, whats the plan with the rest of the series? Do you want me to
re-post it? It shows deferred under crypto patchwork currently.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* RE: (EXT) [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Robin Gong @ 2020-06-03 9:50 UTC (permalink / raw)
To: Matthias Schiffer
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: <5d246dd81607bb6e5cb9af86ad4e53f7a7a99c50.camel@ew.tq-group.com>
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?
^ permalink raw reply
* Re: [PATCH 1/4] clk: sunxi-ng: add support for the Allwinner A100 CCU
From: Chen-Yu Tsai @ 2020-06-03 9:48 UTC (permalink / raw)
To: 李扬韬
Cc: Maxime Ripard, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
黄烁生, tiny.windzz, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, linux-gpio
In-Reply-To: <d7d6ee84-bfbb-4fef-9ed8-1f7045494594.frank@allwinnertech.com>
On Wed, Jun 3, 2020 at 5:42 PM 李扬韬 <frank@allwinnertech.com> wrote:
>
> >> + /* Enable the lock bits on all PLLs */
> >> + for (i = 0; i < ARRAY_SIZE(pll_regs); i++) {
> >> + val = readl(reg + pll_regs[i]);
> >> + val |= BIT(29);
> >
> >Having a define for that would be nice here
> >
> >> + writel(val, reg + pll_regs[i]);
> >> + }
> >> +
> >> + /*
> >> + * In order to pass the EMI certification, the SDM function of
> >> + * the peripheral 1 bus is enabled, and the frequency is still
> >> + * calculated using the previous division factor.
> >> + */
> >> + writel(0xd1303333, reg + SUN50I_A100_PLL_PERIPH1_PATTERN0_REG);
> >
> >Same here
>
> Having a define? I don’t quite understand what you mean,
> can you give me an example?
What Maxime means is that 0xd1303333 is a magic number.
It is better to make a properly named macro, or many macros
that you then bitwise-OR together. So you should make macros
for each bitfield in that register, which would likely include
the SDM calculation factors, the enable bit, and any other fields.
ChenYu
> MBR,
> Yangtao
^ permalink raw reply
* Re: Security Random Number Generator support
From: Sudeep Holla @ 2020-06-03 9:48 UTC (permalink / raw)
To: Neal Liu
Cc: Marc Zyngier, Julius Werner, Ard Biesheuvel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Sean Wang,
linux-mediatek, lkml, wsd_upstream, Rob Herring,
Linux Crypto Mailing List, Matt Mackall, Sudeep Holla,
Jose Marinho, Matthias Brugger, Crystal Guo (郭晶),
Linux ARM
In-Reply-To: <1591170857.19414.5.camel@mtkswgap22>
+ Jose
On Wed, Jun 03, 2020 at 03:54:17PM +0800, Neal Liu wrote:
> On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
[...]
> > 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.
> >
> > There is zero benefit in having a platform-dependent ID. It just
> > pointlessly increases complexity, and means we cannot use the RNG
> > before the firmware tables are available (yes, we need it that
> > early).
> >
>
> Do you know which ARM expert could edict this standard?
> Or is there any chance that we can make one? And be reviewed by
> maintainers?
>
Jose Marinho is working on the spec, may be he has more updates on the
timeline.
--
Regards,
Sudeep
^ permalink raw reply
* 回复：[PATCH 2/4] pinctrl: sunxi: add support for the Allwinner A100 pin controller
From: 李扬韬 @ 2020-06-03 9:44 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
黄烁生, tiny.windzz, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522152803.twvfvuhd6ztunvll@gilmour.lan>
>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
>> + SUNXI_FUNCTION(0x0, "gpio_in"),
>> + SUNXI_FUNCTION(0x1, "gpio_out"),
>> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
>> + SUNXI_FUNCTION(0x3, "jtag"), /* MS1 */
>> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
>
>We should use another name here, since the code will just pick the first one and
>ignore the second. What about jtag-gpu?
The underscores are used in front, so changing it to jtag_gpu may be more consistent.
>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
>> + SUNXI_FUNCTION(0x0, "gpio_in"),
>> + SUNXI_FUNCTION(0x1, "gpio_out"),
>> + SUNXI_FUNCTION(0x2, "spdif"), /* DIN */
>> + SUNXI_FUNCTION(0x3, "i2s0"), /* DOUT0 */
>> + SUNXI_FUNCTION(0x4, "i2s0"), /* DIN1 */
>
>I guess the second one would be i2s1?
No, each i2s may have many inputs and outputs.
SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "cir0"), /* IN */
SUNXI_FUNCTION(0x3, "i2s3_dout3"), /* DOUT3 */
SUNXI_FUNCTION(0x4, "i2s3_din3"), /* DIN3 */
SUNXI_FUNCTION(0x5, "ledc"),
SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 19)),
Considering that the same pin has multiple same functions,
so add a suffix, like i2s3_dout3 and i2s3_din3?
Or specify muxsel in the device tree may be another solution.
>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
>> + SUNXI_FUNCTION(0x0, "gpio_in"),
>> + SUNXI_FUNCTION(0x1, "gpio_out"),
>> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
>> + SUNXI_FUNCTION(0x3, "cpu"), /* CUR_W */
>
>What is "cpu" supposed to be?
As far as I know, this is a function that has never been used.
The hardware guy said that it can be used to control the CPU to reduce the current.
Thx,
Yangtao
^ permalink raw reply
* 回复：[PATCH 1/4] clk: sunxi-ng: add support for the Allwinner A100 CCU
From: 李扬韬 @ 2020-06-03 9:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
黄烁生, tiny.windzz, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522151403.7ovbdza2o3cjrb7a@gilmour.lan>
>> + /* Enable the lock bits on all PLLs */
>> + for (i = 0; i < ARRAY_SIZE(pll_regs); i++) {
>> + val = readl(reg + pll_regs[i]);
>> + val |= BIT(29);
>
>Having a define for that would be nice here
>
>> + writel(val, reg + pll_regs[i]);
>> + }
>> +
>> + /*
>> + * In order to pass the EMI certification, the SDM function of
>> + * the peripheral 1 bus is enabled, and the frequency is still
>> + * calculated using the previous division factor.
>> + */
>> + writel(0xd1303333, reg + SUN50I_A100_PLL_PERIPH1_PATTERN0_REG);
>
>Same here
Having a define? I don’t quite understand what you mean,
can you give me an example?
MBR,
Yangtao
^ permalink raw reply
* Re: Security Random Number Generator support
From: Russell King - ARM Linux admin @ 2020-06-03 9:34 UTC (permalink / raw)
To: 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, Rob Herring, linux-mediatek,
Linux Crypto Mailing List, Matt Mackall, Matthias Brugger,
Crystal Guo (郭晶), Ard Biesheuvel, Linux ARM
In-Reply-To: <fcbe37f6f9cbcde24f9c28bc504f1f0e@kernel.org>
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.
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
^ permalink raw reply
* [PATCH v1] ARM: dts: aspeed: mihawk: add aliases for i2c and add thermal sensor
From: Ben Pai @ 2020-06-03 9:26 UTC (permalink / raw)
To: robh+dt, mark.rutland, joel, andrew, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
Cc: claire_ku, Ben Pai
1.Set the bus id for each mux channel to avoid switching channels
multiple times
2.Set smbus_en of IO expander to 1 in order to be able to read tmp401
sensor
3.Add 8 tmp401 thermal sensors
Signed-off-by: Ben Pai <Ben_Pai@wistron.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 449 +++++++++++++++++++-
1 file changed, 444 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
index f7e935ede919..78451b283d93 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
@@ -7,7 +7,52 @@
/ {
model = "Mihawk BMC";
compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
-
+ aliases {
+ i2c215 = &bus6_mux215;
+ i2c216 = &bus6_mux216;
+ i2c217 = &bus6_mux217;
+ i2c218 = &bus6_mux218;
+ i2c219 = &bus6_mux219;
+ i2c220 = &bus6_mux220;
+ i2c221 = &bus6_mux221;
+ i2c222 = &bus6_mux222;
+ i2c223 = &bus7_mux223;
+ i2c224 = &bus7_mux224;
+ i2c225 = &bus7_mux225;
+ i2c226 = &bus7_mux226;
+ i2c227 = &bus7_mux227;
+ i2c228 = &bus7_mux228;
+ i2c229 = &bus7_mux229;
+ i2c230 = &bus7_mux230;
+ i2c231 = &bus9_mux231;
+ i2c232 = &bus9_mux232;
+ i2c233 = &bus9_mux233;
+ i2c234 = &bus9_mux234;
+ i2c235 = &bus9_mux235;
+ i2c236 = &bus9_mux236;
+ i2c237 = &bus9_mux237;
+ i2c238 = &bus9_mux238;
+ i2c239 = &bus10_mux239;
+ i2c240 = &bus10_mux240;
+ i2c241 = &bus10_mux241;
+ i2c242 = &bus10_mux242;
+ i2c243 = &bus10_mux243;
+ i2c244 = &bus10_mux244;
+ i2c245 = &bus10_mux245;
+ i2c246 = &bus10_mux246;
+ i2c247 = &bus12_mux247;
+ i2c248 = &bus12_mux248;
+ i2c249 = &bus12_mux249;
+ i2c250 = &bus12_mux250;
+ i2c251 = &bus13_mux251;
+ i2c252 = &bus13_mux252;
+ i2c253 = &bus13_mux253;
+ i2c254 = &bus13_mux254;
+ i2c255 = &bus13_mux255;
+ i2c256 = &bus13_mux256;
+ i2c257 = &bus13_mux257;
+ i2c258 = &bus13_mux258;
+ };
chosen {
stdout-path = &uart5;
@@ -630,6 +675,55 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+
+ bus6_mux215: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ bus6_mux216: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ bus6_mux217: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus6_mux218: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ bus6_mux219: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ bus6_mux220: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ bus6_mux221: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ bus6_mux222: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+
};
};
@@ -644,6 +738,55 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+
+ bus7_mux223: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ bus7_mux224: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ bus7_mux225: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus7_mux226: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ bus7_mux227: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ bus7_mux228: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ bus7_mux229: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ bus7_mux230: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+
};
};
@@ -684,6 +827,68 @@
i2c-mux-idle-disconnect;
interrupt-controller;
#interrupt-cells = <2>;
+
+ bus9_mux231: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus0 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus0";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus9_mux232: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus1 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus1";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus9_mux233: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus9_mux234: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
};
pca9545@71 {
@@ -695,6 +900,68 @@
i2c-mux-idle-disconnect;
interrupt-controller;
#interrupt-cells = <2>;
+
+ bus9_mux235: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus2 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus2";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus9_mux236: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus3 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus3";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus9_mux237: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus9_mux238: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
};
};
@@ -725,6 +992,68 @@
i2c-mux-idle-disconnect;
interrupt-controller;
#interrupt-cells = <2>;
+
+ bus10_mux239: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus4 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus4";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus10_mux240: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus5 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus5";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus10_mux241: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus10_mux242: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
};
pca9545@71 {
@@ -736,6 +1065,68 @@
i2c-mux-idle-disconnect;
interrupt-controller;
#interrupt-cells = <2>;
+
+ bus10_mux243: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus6 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus6";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus10_mux244: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tca9554@39 {
+ compatible = "ti,tca9554";
+ reg = <0x39>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ smbus7 {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "smbus7";
+ };
+ };
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
+ };
+
+ bus10_mux245: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus10_mux246: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
};
};
@@ -796,7 +1187,7 @@
interrupt-controller;
#interrupt-cells = <2>;
- i2c@0 {
+ bus12_mux247: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
@@ -807,7 +1198,7 @@
};
};
- i2c@1 {
+ bus12_mux248: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
@@ -818,7 +1209,7 @@
};
};
- i2c@2 {
+ bus12_mux249: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
@@ -829,7 +1220,7 @@
};
};
- i2c@3 {
+ bus12_mux250: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
@@ -857,6 +1248,54 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+
+ bus13_mux251: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ bus13_mux252: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ bus13_mux253: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ bus13_mux254: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ bus13_mux255: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ bus13_mux256: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ bus13_mux257: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ bus13_mux258: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
};
};
--
2.17.1
---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient.
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply related
* [PATCH v1] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-06-03 9:15 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy, Rob Herring
Cc: linux-leds, devicetree, linux-kernel, Flavio Suligoi
The documentation reports the wrong macro names
related to the pca9532 instead of the pca955x
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Acked-by: Rob Herring <robh@kernel.org>
---
v1: add "Acked-by: Rob Herring <robh@kernel.org>"
Documentation/devicetree/bindings/leds/leds-pca955x.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
index 7984efb767b4..7a5830f8d5ab 100644
--- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
@@ -26,9 +26,9 @@ LED sub-node properties:
from 0 to 15 for the pca9552
from 0 to 3 for the pca9553
- type: (optional) either
- PCA9532_TYPE_NONE
- PCA9532_TYPE_LED
- PCA9532_TYPE_GPIO
+ PCA955X_TYPE_NONE
+ PCA955X_TYPE_LED
+ PCA955X_TYPE_GPIO
see dt-bindings/leds/leds-pca955x.h (default to LED)
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
--
2.17.1
^ permalink raw reply related
* [PATCH V1 0/2] Add SDHC interconnect bandwidth scaling
From: Pradeep P V K @ 2020-06-03 9:09 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
Add interconnect bandwidths for SDHC driver using OPP framework that
is required by SDHC driver based on the clock frequency and bus width
of the card. Otherwise, the system clocks may run at minimum clock
speed and thus affecting the performance.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3 09/17] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
[3] [RFC v6 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW
scaling strings
(https://lkml.org/lkml/2020/3/23/409)
as there were no extra changes made on [3], retaining the Acked-by and
Reviewed-by sign-off from [3].
Pradeep P V K (2):
mmc: sdhci-msm: Add interconnect bandwidth scaling support
dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
drivers/mmc/host/sdhci-msm.c | 16 ++++++++++++++++
2 files changed, 34 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH V1 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: Pradeep P V K @ 2020-06-03 9:09 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591175376-2374-1-git-send-email-ppvk@codeaurora.org>
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 | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index b277dd7..bf95484 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"
@@ -1999,6 +2000,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_msm_host *msm_host;
struct clk *clk;
+ struct icc_path *sdhc_path;
int ret;
u16 host_version, core_minor;
u32 core_version, config;
@@ -2070,6 +2072,20 @@ 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.
+ */
+ sdhc_path = of_icc_get(&pdev->dev, NULL);
+ ret = PTR_ERR_OR_ZERO(sdhc_path);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ dev_info(&pdev->dev, "defer icc path: %d\n", ret);
+ else
+ dev_err(&pdev->dev, "failed to get icc path:%d\n", ret);
+ goto bus_clk_disable;
+ }
+ icc_put(sdhc_path);
+
msm_host->opp_table = dev_pm_opp_set_clkname(&pdev->dev, "core");
if (IS_ERR(msm_host->opp_table)) {
ret = PTR_ERR(msm_host->opp_table);
--
1.9.1
^ permalink raw reply related
* [PATCH V1 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
From: Pradeep P V K @ 2020-06-03 9:09 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591175376-2374-1-git-send-email-ppvk@codeaurora.org>
Add interconnect bandwidth scaling supported strings for qcom-sdhci
controller.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index b8e1d2b..3b602fd 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -54,6 +54,21 @@ Required properties:
- qcom,dll-config: Chipset and Platform specific value. Use this field to
specify the DLL_CONFIG register value as per Hardware Programming Guide.
+Optional Properties:
+* Following bus parameters are required for interconnect bandwidth scaling:
+- interconnects: Pairs of phandles and interconnect provider specifier
+ to denote the edge source and destination ports of
+ the interconnect path.
+
+- interconnect-names: For sdhc, we have two main paths.
+ 1. Data path : sdhc to ddr
+ 2. Config path : cpu to sdhc
+ For Data interconnect path the name supposed to be
+ is "sdhc-ddr" and for config interconnect path it is
+ "cpu-sdhc".
+ Please refer to Documentation/devicetree/bindings/
+ interconnect/ for more details.
+
Example:
sdhc_1: sdhci@f9824900 {
@@ -71,6 +86,9 @@ Example:
clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
+ interconnects = <&qnoc MASTER_SDCC_ID &qnoc SLAVE_DDR_ID>,
+ <&qnoc MASTER_CPU_ID &qnoc SLAVE_SDCC_ID>;
+ interconnect-names = "sdhc-ddr","cpu-sdhc";
qcom,dll-config = <0x000f642c>;
qcom,ddr-config = <0x80040868>;
--
1.9.1
^ permalink raw reply related
* [PATCH] usb: dwc3: Add support for VBUS power control
From: Mike Looijmans @ 2020-06-03 8:59 UTC (permalink / raw)
To: linux-usb
Cc: devicetree, linux-kernel, gregkh, robh+dt, balbi, Mike Looijmans
Support VBUS power control using regulator framework. Enables the regulator
while the port is in host mode.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
.../devicetree/bindings/usb/dwc3.txt | 1 +
drivers/usb/dwc3/core.c | 30 ++++++++++++++-----
drivers/usb/dwc3/core.h | 4 +++
drivers/usb/dwc3/drd.c | 6 ++--
4 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9ba735..56bc3f238e2d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,7 @@ Optional properties:
- phys: from the *Generic PHY* bindings
- phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
or "usb3-phy".
+ - vbus-supply: Regulator handle that provides the VBUS power.
- resets: set of phandle and reset specifier pairs
- snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- snps,usb3_lpm_capable: determines if platform is USB3 LPM capable
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc17155cb2b..a9e58a301446 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -25,6 +25,7 @@
#include <linux/of.h>
#include <linux/acpi.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/regulator/consumer.h>
#include <linux/reset.h>
#include <linux/usb/ch9.h>
@@ -112,6 +113,23 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
}
+void dwc3_set_vbus(struct dwc3 *dwc, bool enable)
+{
+ int ret;
+
+ if (enable != dwc->vbus_reg_enabled) {
+ if (enable)
+ ret = regulator_enable(dwc->vbus_reg);
+ else
+ ret = regulator_disable(dwc->vbus_reg);
+ if (!ret)
+ dwc->vbus_reg_enabled = enable;
+ }
+
+ if (dwc->usb2_phy)
+ otg_set_vbus(dwc->usb2_phy->otg, enable);
+}
+
static void __dwc3_set_mode(struct work_struct *work)
{
struct dwc3 *dwc = work_to_dwc(work);
@@ -164,8 +182,7 @@ static void __dwc3_set_mode(struct work_struct *work)
if (ret) {
dev_err(dwc->dev, "failed to initialize host\n");
} else {
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, true);
+ dwc3_set_vbus(dwc, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
}
@@ -173,8 +190,7 @@ static void __dwc3_set_mode(struct work_struct *work)
case DWC3_GCTL_PRTCAP_DEVICE:
dwc3_event_buffers_setup(dwc);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
@@ -1183,8 +1199,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
case USB_DR_MODE_PERIPHERAL:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
@@ -1198,8 +1213,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
case USB_DR_MODE_HOST:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, true);
+ dwc3_set_vbus(dwc, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8e215f..cee2574d7bf4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1085,6 +1085,9 @@ struct dwc3 {
bool phys_ready;
+ struct regulator *vbus_reg;
+ bool vbus_reg_enabled;
+
struct ulpi *ulpi;
bool ulpi_ready;
@@ -1397,6 +1400,7 @@ struct dwc3_gadget_ep_cmd_params {
/* prototypes */
void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode);
+void dwc3_set_vbus(struct dwc3 *dwc, bool enable);
void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type);
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 7db1ffc92bbd..45fdec2d128d 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -384,8 +384,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
if (ret) {
dev_err(dwc->dev, "failed to initialize host\n");
} else {
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, true);
+ dwc3_set_vbus(dwc, true);
if (dwc->usb2_generic_phy)
phy_set_mode(dwc->usb2_generic_phy,
PHY_MODE_USB_HOST);
@@ -398,8 +397,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
dwc3_event_buffers_setup(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
if (dwc->usb2_generic_phy)
phy_set_mode(dwc->usb2_generic_phy,
PHY_MODE_USB_DEVICE);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] usb/phy-generic: Add support for OTG VBUS supply control
From: Mike Looijmans @ 2020-06-03 9:00 UTC (permalink / raw)
To: Rob Herring; +Cc: linux-usb, gregkh, balbi, devicetree, linux-kernel
In-Reply-To: <20200529210816.GA2952126@bogus>
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 29-05-2020 23:08, Rob Herring wrote:
> On Fri, May 29, 2020 at 08:00:45AM +0200, Mike Looijmans wrote:
>> This enables support for VBUS on boards where the power is supplied
>> by a regulator. The regulator is enabled when the USB port enters
>> HOST mode.
>>
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>> ---
>> v2: Added missing "return 0;" in set_vbus method
>>
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
>> drivers/usb/phy/phy-generic.c | 46 ++++++++++++++++++-
>> drivers/usb/phy/phy-generic.h | 2 +
>> 3 files changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> index 4dc6a8ee3071..775a19fdb613 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -16,6 +16,9 @@ Optional properties:
>>
>> - vcc-supply: phandle to the regulator that provides power to the PHY.
>>
>> +- vbus-supply: phandle to the regulator that provides the VBUS power for when
>> + the device is in HOST mode.
>> +
> I'm going to say no to expanding this binding...
>
> First, there sure are a lot of controls on a NOP tranceiver.
>
> Second, unless Vbus is supplying the PHY, then this belongs in a
> connector node for which this is already supported.
Clear, I moved the implementation to the DWC3 driver and will submit a
new patch for that.
>
>> - reset-gpios: Should specify the GPIO for reset.
>>
>> - vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
--
Mike Looijmans
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: PCI: uniphier: Add iATU register description
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar, Kunihiko Hayashi
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsys DWC version 4.80 or later.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
"dbi" - controller configuration registers
"link" - SoC-specific glue layer registers
"config" - PCIe configuration space
+ "atu" - iATU registers for DWC version 4.80 or later
- clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
- resets: A phandle to the reset line for PCIe glue layer including
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar, Kunihiko Hayashi
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
This gets iATU register area from reg property. In Synopsys DWC version
4.80 or later, since iATU register area is separated from core register
area, this area is necessary to get from DT independently.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a8dda39..ad14e67 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -447,6 +447,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.dbi_base))
return PTR_ERR(priv->pci.dbi_base);
+ priv->pci.atu_base =
+ devm_platform_ioremap_resource_byname(pdev, "atu");
+ if (IS_ERR(priv->pci.atu_base))
+ priv->pci.atu_base = NULL;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/6] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar, Kunihiko Hayashi
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
Even if phy driver doesn't probe, the error message can't be distinguished
from other errors. This displays error message caused by the phy driver
explicitly.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index ad14e67..3b51561 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -466,8 +466,12 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
return PTR_ERR(priv->rst);
priv->phy = devm_phy_optional_get(dev, "pcie-phy");
- if (IS_ERR(priv->phy))
- return PTR_ERR(priv->phy);
+ if (IS_ERR(priv->phy)) {
+ ret = PTR_ERR(priv->phy);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get phy (%d)\n", ret);
+ return ret;
+ }
platform_set_drvdata(pdev, priv);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/6] PCI: uniphier: Use devm_platform_ioremap_resource_byname()
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar, Kunihiko Hayashi
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
Use devm_platform_ioremap_resource_byname() to simplify the code a bit.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 3b51561..ce47622 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -452,8 +452,7 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.atu_base))
priv->pci.atu_base = NULL;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
- priv->base = devm_ioremap_resource(dev, res);
+ priv->base = devm_platform_ioremap_resource_byname(pdev, "link");
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/6] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: linux-pci, devicetree, linux-arm-kernel, linux-kernel,
Masami Hiramatsu, Jassi Brar, Kunihiko Hayashi, Marc Zyngier
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.
For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 0a4a5aa..9b628a2 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -112,13 +112,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
static void dw_chained_msi_isr(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
- struct pcie_port *pp;
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
- chained_irq_enter(chip, desc);
+ if (pp->ops->msi_host_isr)
+ pp->ops->msi_host_isr(pp);
- pp = irq_desc_get_handler_data(desc);
+ chained_irq_enter(chip, desc);
dw_handle_msi_irq(pp);
-
chained_irq_exit(chip, desc);
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 656e00f..e741967 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
void (*scan_bus)(struct pcie_port *pp);
void (*set_num_vectors)(struct pcie_port *pp);
int (*msi_host_init)(struct pcie_port *pp);
+ void (*msi_host_isr)(struct pcie_port *pp);
};
struct pcie_port {
--
2.7.4
^ permalink raw reply related
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