* [RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
This will be handled via the mux-input-bridge.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
drivers/gpu/drm/bridge/Kconfig | 1 -
drivers/gpu/drm/bridge/nwl-dsi.c | 61 --------------------------------
2 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3886c0f41bdd..11444f841e35 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
select DRM_PANEL_BRIDGE
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
- select MULTIPLEXER
select REGMAP_MMIO
help
This enables the Northwest Logic MIPI DSI Host controller as
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index b14d725bf609..8839f333f39c 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -12,7 +12,6 @@
#include <linux/math64.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
-#include <linux/mux/consumer.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/phy/phy.h>
@@ -44,9 +43,6 @@ enum transfer_direction {
DSI_PACKET_RECEIVE,
};
-#define NWL_DSI_ENDPOINT_LCDIF 0
-#define NWL_DSI_ENDPOINT_DCSS 1
-
struct nwl_dsi_plat_clk_config {
const char *id;
struct clk *clk;
@@ -94,7 +90,6 @@ struct nwl_dsi {
struct reset_control *rst_esc;
struct reset_control *rst_dpi;
struct reset_control *rst_pclk;
- struct mux_control *mux;
/* DSI clocks */
struct clk *phy_ref_clk;
@@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
}
dsi->tx_esc_clk = clk;
- dsi->mux = devm_mux_control_get(dsi->dev, NULL);
- if (IS_ERR(dsi->mux)) {
- ret = PTR_ERR(dsi->mux);
- if (ret != -EPROBE_DEFER)
- DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
- return ret;
- }
-
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
return 0;
}
-static int nwl_dsi_select_input(struct nwl_dsi *dsi)
-{
- struct device_node *remote;
- u32 use_dcss = 1;
- int ret;
-
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_LCDIF);
- if (remote) {
- use_dcss = 0;
- } else {
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_DCSS);
- if (!remote) {
- DRM_DEV_ERROR(dsi->dev,
- "No valid input endpoint found\n");
- return -EINVAL;
- }
- }
-
- DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
- (use_dcss) ? "DCSS" : "LCDIF");
- ret = mux_control_try_select(dsi->mux, use_dcss);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
-
- of_node_put(remote);
- return ret;
-}
-
-static int nwl_dsi_deselect_input(struct nwl_dsi *dsi)
-{
- int ret;
-
- ret = mux_control_deselect(dsi->mux);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to deselect input: %d\n", ret);
-
- return ret;
-}
-
static const struct drm_bridge_timings nwl_dsi_timings = {
.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
};
@@ -1175,12 +1121,6 @@ static int nwl_dsi_probe(struct platform_device *pdev)
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
- ret = nwl_dsi_select_input(dsi);
- if (ret < 0) {
- mipi_dsi_host_unregister(&dsi->dsi_host);
- return ret;
- }
-
drm_bridge_add(&dsi->bridge);
return 0;
}
@@ -1189,7 +1129,6 @@ static int nwl_dsi_remove(struct platform_device *pdev)
{
struct nwl_dsi *dsi = platform_get_drvdata(pdev);
- nwl_dsi_deselect_input(dsi);
mipi_dsi_host_unregister(&dsi->dsi_host);
drm_bridge_remove(&dsi->bridge);
pm_runtime_disable(&pdev->dev);
--
2.26.1
^ permalink raw reply related
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Andrew Lunn @ 2020-05-15 13:14 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Arnd Bergmann, Edwin Peer, DTML, Bartosz Golaszewski,
Stephane Le Provost, Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAMRc=MeypzZBHo6dJGKm4JujYyejqHxtdo7Ts95DXuL0VuMYCw@mail.gmail.com>
On Fri, May 15, 2020 at 09:11:14AM +0200, Bartosz Golaszewski wrote:
> czw., 14 maj 2020 o 18:19 Arnd Bergmann <arnd@arndb.de> napisał(a):
> >
> > On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > > family. For now we only support full-duplex.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Looks very nice overall. Just a few things I noticed, and some ideas
> > that may or may not make sense:
> >
> > > +/* This is defined to 0 on arm64 in arch/arm64/include/asm/processor.h but
> > > + * this IP doesn't work without this alignment being equal to 2.
> > > + */
> > > +#ifdef NET_IP_ALIGN
> > > +#undef NET_IP_ALIGN
> > > +#endif
> > > +#define NET_IP_ALIGN 2
> >
> > Maybe you should just define your own macro instead of replacing
> > the normal one then?
> >
>
> I did in an earlier version and was told to use NET_IP_ALIGN but then
> found out its value on arm64 doesn't work for me so I did the thing
> that won't make anybody happy - redefine the existing constant. :)
Hi Bartosz
I did not realise ARM64 set it to 0. As Arnd suggested, please define
your own macro.
Andrew
^ permalink raw reply
* RE: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Gustavo Pimentel @ 2020-05-15 13:16 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-5-git-send-email-hayashi.kunihiko@socionext.com>
Hi Kunihiko,
On Fri, May 15, 2020 at 10:59:2, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> This gets iATU register area from reg property. In Synopsis DWC version
s/Synopsis/Synopsys
in all patches
> 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 | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a8dda39..493f105 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(priv->pci.dbi_base))
> return PTR_ERR(priv->pci.dbi_base);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> + if (res) {
> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
> + 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
* RE: [PATCH v2 1/5] PCI: dwc: Add msi_host_isr() callback
From: Gustavo Pimentel @ 2020-05-15 13:20 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-2-git-send-email-hayashi.kunihiko@socionext.com>
[+cc Marc; IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) maintainer]
On Fri, May 15, 2020 at 10:58:59, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> 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.
>
> 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 42fbfe2..7dd1021 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
* RE: [PATCH v2 2/5] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Gustavo Pimentel @ 2020-05-15 13:21 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-3-git-send-email-hayashi.kunihiko@socionext.com>
[+cc Marc; IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) maintainer]
On Fri, May 15, 2020 at 10:59:0, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> The misc interrupts consisting of PME, AER, and Link event, is handled
> by INTx handler, however, these interrupts should be also handled by
> MSI handler.
>
> This adds the function uniphier_pcie_misc_isr() that handles misc
> intterupts, which is called from both INTx and MSI handlers.
> This function detects PME and AER interrupts with the status register,
> and invoke PME and AER drivers related to INTx or MSI.
>
> And this sets the mask for misc interrupts from INTx if MSI is enabled
> and sets the mask for misc interrupts from MSI if MSI is disabled.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 53 +++++++++++++++++++++++-------
> 1 file changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a5401a0..a8dda39 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -44,7 +44,9 @@
> #define PCL_SYS_AUX_PWR_DET BIT(8)
>
> #define PCL_RCV_INT 0x8108
> +#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
> #define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
> +#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
> #define PCL_CFG_BW_MGT_STATUS BIT(4)
> #define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
> #define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
> @@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
>
> static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
> {
> - writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
> + u32 val;
> +
> + val = PCL_RCV_INT_ALL_ENABLE;
> + if (pci_msi_enabled())
> + val |= PCL_RCV_INT_ALL_INT_MASK;
> + else
> + val |= PCL_RCV_INT_ALL_MSI_MASK;
> +
> + writel(val, priv->base + PCL_RCV_INT);
> writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
> }
>
> @@ -231,28 +241,48 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
> .map = uniphier_pcie_intx_map,
> };
>
> -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
> +static void uniphier_pcie_misc_isr(struct pcie_port *pp)
> {
> - struct pcie_port *pp = irq_desc_get_handler_data(desc);
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
> - struct irq_chip *chip = irq_desc_get_chip(desc);
> - unsigned long reg;
> - u32 val, bit, virq;
> + u32 val, virq;
>
> - /* INT for debug */
> val = readl(priv->base + PCL_RCV_INT);
>
> if (val & PCL_CFG_BW_MGT_STATUS)
> dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
> +
> if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
> dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
> - if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
> - dev_dbg(pci->dev, "Root Error\n");
> - if (val & PCL_CFG_PME_MSI_STATUS)
> - dev_dbg(pci->dev, "PME Interrupt\n");
> +
> + if (pci_msi_enabled()) {
> + if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
> + dev_dbg(pci->dev, "Root Error Status\n");
> + virq = irq_linear_revmap(pp->irq_domain, 0);
> + generic_handle_irq(virq);
> + }
> +
> + if (val & PCL_CFG_PME_MSI_STATUS) {
> + dev_dbg(pci->dev, "PME Interrupt\n");
> + virq = irq_linear_revmap(pp->irq_domain, 0);
> + generic_handle_irq(virq);
> + }
> + }
>
> writel(val, priv->base + PCL_RCV_INT);
> +}
> +
> +static void uniphier_pcie_irq_handler(struct irq_desc *desc)
> +{
> + struct pcie_port *pp = irq_desc_get_handler_data(desc);
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + unsigned long reg;
> + u32 val, bit, virq;
> +
> + /* misc interrupt */
> + uniphier_pcie_misc_isr(pp);
>
> /* INTx */
> chained_irq_enter(chip, desc);
> @@ -330,6 +360,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
>
> static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
> .host_init = uniphier_pcie_host_init,
> + .msi_host_isr = uniphier_pcie_misc_isr,
> };
>
> static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCHv1 1/2] power: supply: gpio-charger: add charge-current-limit feature
From: Emil Velikov @ 2020-05-15 13:24 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Rob Herring, linux-pm, devicetree,
linux-kernel, kernel
In-Reply-To: <20200513115601.360642-1-sebastian.reichel@collabora.com>
Hi Sebastian,
I've left a few trivial suggestions, although I suspect only one of them
really matters. Namely - I think as-is the code changes the legacy behaviour
when OF is missing.
Mind you, this is my third time skimming through power/supply, so take it with
a grain of salt.
On 2020/05/13, Sebastian Reichel wrote:
> Add new charge-current-limit feature to gpio-charger. This also
> makes the online status GPIO optional, since hardware might only
> expose the charge-current-limit feature and there is no good reason
> to have it mandatory now that different GPIOs are supported.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> .../bindings/power/supply/gpio-charger.txt | 11 +-
> drivers/power/supply/gpio-charger.c | 176 ++++++++++++++++--
> 2 files changed, 174 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
> index 0fb33b2c62a6..dbfd29029f69 100644
> --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
> +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
> @@ -2,8 +2,6 @@ gpio-charger
>
> Required properties :
> - compatible : "gpio-charger"
> - - gpios : GPIO indicating the charger presence.
> - See GPIO binding in bindings/gpio/gpio.txt .
> - charger-type : power supply type, one of
> unknown
> battery
> @@ -15,7 +13,13 @@ Required properties :
> usb-aca (USB accessory charger adapter)
>
> Optional properties:
> + - gpios : GPIO indicating the charger presence.
> + See GPIO binding in bindings/gpio/gpio.txt .
> - charge-status-gpios: GPIO indicating whether a battery is charging.
> + - charge-current-limit-gpios: Output GPIOs specifiers for limiting the charge current
> + - charge-current-limit-mapping: List of touples with current in uA and a GPIO bitmap (in this order).
> + The GPIOs are encoded in the same order as specified in charge-current-limit-gpios.
> + The touples must be provided in descending order of the current limit.
Minor tweaks:
List of tuples with current in uA and a GPIO bitmap.
Tuples must be sorted in descending order of the current limit.
GPIOs are encoded in the order as specified in charge-current-limit-gpios.
> +static int init_charge_current_limit(struct device *dev,
> + struct gpio_charger *gpio_charger)
> +{
> + int i, len;
> + u32 cur_limit = U32_MAX;
> +
> + gpio_charger->current_limit_gpios = devm_gpiod_get_array_optional(dev,
> + "charge-current-limit", GPIOD_OUT_LOW);
> + if (IS_ERR(gpio_charger->current_limit_gpios)) {
> + dev_err(dev, "error getting current-limit GPIOs\n");
> + return PTR_ERR(gpio_charger->current_limit_gpios);
> + }
> +
> + if (!gpio_charger->current_limit_gpios)
> + return 0;
> +
> + len = device_property_read_u32_array(dev, "charge-current-limit-mapping",
> + NULL, 0);
> + if (len < 0)
The properly is optional, although I'm not sure if having an 'empty' properly
(len == 0) should be considered an error as indicated by -ENOMEM below or not.
Worth documenting that, unless it's covered already.
> + return len;
> +
> + if (len % 2) {
> + dev_err(dev, "invalid charge-current-limit-mapping length\n");
> + return -EINVAL;
> + }
> +
> + gpio_charger->current_limit_map = devm_kmalloc_array(dev,
> + len / 2, sizeof(*gpio_charger->current_limit_map), GFP_KERNEL);
> + if (!gpio_charger->current_limit_map)
> + return -ENOMEM;
> +
> + gpio_charger->current_limit_map_size = len / 2;
> +
> + len = device_property_read_u32_array(dev, "charge-current-limit-mapping",
> + (u32*) gpio_charger->current_limit_map, len);
> + if (len < 0)
> + return len;
> +
> + for (i=0; i < gpio_charger->current_limit_map_size; i++) {
> + if (gpio_charger->current_limit_map[i].limit_ua > cur_limit) {
> + dev_err(dev, "invalid charge-current-limit-mapping\n");
Would make sense to use something more descriptive than "invalid". Say "not
sorted by current descending order"?
> @@ -137,18 +270,19 @@ static int gpio_charger_probe(struct platform_device *pdev)
> /*
> * If this fails and we're not using device tree, try the
> * legacy platform data method.
> */
> - if (IS_ERR(gpio_charger->gpiod) && !dev->of_node) {
> + if (!gpio_charger->gpiod && !dev->of_node) {
The original code will attempt the legacy code for ... (from the doc)
* ..., -ENOENT if no GPIO has been assigned to the requested function, or
* another IS_ERR() code if an error occurred while trying to acquire the GPIO.
While the new code will only consider -ENOENT.
Using IS_ERR_OR_NULL(gpio_charger->gpiod) should preserve the original
behaviour.
> /* Non-DT: use legacy GPIO numbers */
> if (!gpio_is_valid(pdata->gpio)) {
> dev_err(dev, "Invalid gpio pin in pdata\n");
> @@ -173,18 +307,38 @@ static int gpio_charger_probe(struct platform_device *pdev)
> return PTR_ERR(gpio_charger->gpiod);
> }
>
> + if (gpio_charger->gpiod &&
> + num_props < ARRAY_SIZE(gpio_charger_properties)) {
> + gpio_charger_properties[num_props] = POWER_SUPPLY_PROP_ONLINE;
The ARRAY_SIZE() check here (and below) are always true, albeit not dead code.
IMHO the beefy comment above gpio_charger_properties, plus review process is
enough to catch these issues, so it can be dropped.
> charger_desc = &gpio_charger->charger_desc;
> charger_desc->properties = gpio_charger_properties;
Aside: any particular reason why power_supply_desc::properties isn't const?
-Emil
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-15 13:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Rob Herring, David S . Miller, Matthias Brugger,
John Crispin, Sean Wang, Mark Lee, Jakub Kicinski, Fabien Parent,
Heiner Kallweit, Edwin Peer, DTML, linux-kernel@vger.kernel.org,
Networking, Linux ARM, moderated list:ARM/Mediatek SoC...,
Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200514075942.10136-11-brgl@bgdev.pl>
On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> +static int mtk_mac_ring_pop_tail(struct mtk_mac_ring *ring,
> + struct mtk_mac_ring_desc_data *desc_data)
I took another look at this function because of your comment on the locking
the descriptor updates, which seemed suspicious as the device side does not
actually use the locks to access them
> +{
> + struct mtk_mac_ring_desc *desc = &ring->descs[ring->tail];
> + unsigned int status;
> +
> + /* Let the device release the descriptor. */
> + dma_rmb();
> + status = desc->status;
> + if (!(status & MTK_MAC_DESC_BIT_COWN))
> + return -1;
The dma_rmb() seems odd here, as I don't see which prior read
is being protected by this.
> + desc_data->len = status & MTK_MAC_DESC_MSK_LEN;
> + desc_data->flags = status & ~MTK_MAC_DESC_MSK_LEN;
> + desc_data->dma_addr = ring->dma_addrs[ring->tail];
> + desc_data->skb = ring->skbs[ring->tail];
> +
> + desc->data_ptr = 0;
> + desc->status = MTK_MAC_DESC_BIT_COWN;
> + if (status & MTK_MAC_DESC_BIT_EOR)
> + desc->status |= MTK_MAC_DESC_BIT_EOR;
> +
> + /* Flush writes to descriptor memory. */
> + dma_wmb();
The comment and the barrier here seem odd as well. I would have expected
a barrier after the update to the data pointer, and only a single store
but no read of the status flag instead of the read-modify-write,
something like
desc->data_ptr = 0;
dma_wmb(); /* make pointer update visible before status update */
desc->status = MTK_MAC_DESC_BIT_COWN | (status & MTK_MAC_DESC_BIT_EOR);
> + ring->tail = (ring->tail + 1) % MTK_MAC_RING_NUM_DESCS;
> + ring->count--;
I would get rid of the 'count' here, as it duplicates the information
that is already known from the difference between head and tail, and you
can't update it atomically without holding a lock around the access to
the ring. The way I'd do this is to have the head and tail pointers
in separate cache lines, and then use READ_ONCE/WRITE_ONCE
and smp barriers to access them, with each one updated on one
thread but read by the other.
Arnd
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: kbuild test robot @ 2020-05-15 13:43 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX, linux-kernel, linux-mtd, devicetree
Cc: kbuild-all, miquel.raynal, richard, vigneshr, arnd,
brendanhiggins, tglx, boris.brezillon, anders.roxell, masonccyang
In-Reply-To: <20200515105537.4876-3-vadivel.muruganx.ramuthevar@linux.intel.com>
Hi "Ramuthevar,Vadivel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on arm-soc/for-next linus/master linux/master v5.7-rc5 next-20200514]
[cannot apply to mtd/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Ramuthevar-Vadivel-MuruganX/mtd-rawnand-Add-NAND-controller-support-on-Intel-LGM-SoC/20200515-185904
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-193-gb8fad4bc-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: expected unsigned int val
>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: got restricted __be32 [assigned] [usertype] reg
drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: expected unsigned int val
drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: got restricted __be32 [assigned] [usertype] reg
vim +441 drivers/mtd/nand/raw/intel-nand-controller.c
420
421 static int ebu_nand_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
422 int oob_required, int page)
423 {
424 struct mtd_info *mtd = nand_to_mtd(chip);
425 struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
426 void __iomem *int_sta = ebu_host->hsnand + HSNAND_INT_STA;
427 int ret, val, x;
428 __be32 reg;
429
430 ebu_nand_trigger(ebu_host, page, NAND_CMD_SEQIN);
431
432 ret = ebu_dma_start(ebu_host, DMA_MEM_TO_DEV, buf, mtd->writesize);
433 if (ret)
434 return ret;
435
436 if (oob_required) {
437 const u8 *pdata;
438
439 pdata = chip->oob_poi;
440 reg = cpu_to_be32(*pdata++);
> 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0);
442
443 reg = cpu_to_be32(*pdata);
444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1);
445 }
446
447 ret = readl_poll_timeout_atomic(int_sta, val,
448 !(val & HSNAND_INT_STA_WR_C), 10, 1000);
449 if (ret)
450 return -EIO;
451
452 x = readl(ebu_host->hsnand + HSNAND_CTL);
453 x &= ~HSNAND_CTL_GO;
454 writel(x, ebu_host->hsnand + HSNAND_CTL);
455
456 return 0;
457 }
458
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 08/19] spi: dw: Discard dma_width member of the dw_spi structure
From: Andy Shevchenko @ 2020-05-15 13:49 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Mark Brown, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Allison Randal, Gareth Williams, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, Jarkko Nikula, Wan Ahmad Zainie,
Thomas Gleixner, Clement Leger, Xinwei Kong, wuxu.wu,
Phil Edworthy, Linus Walleij, linux-spi, linux-kernel
In-Reply-To: <20200515130559.psq2zwfhovt6rzhl@mobilestation>
On Fri, May 15, 2020 at 04:05:59PM +0300, Serge Semin wrote:
> On Fri, May 15, 2020 at 04:03:05PM +0300, Andy Shevchenko wrote:
> > On Fri, May 15, 2020 at 01:47:47PM +0300, Serge Semin wrote:
> > > This member has exactly the same value as n_bytes of the DW SPI private
> > > data object, it's calculated at the same point of the transfer method,
> > > n_bytes isn't changed during the whole transfer, and they even serve for
> > > the same purpose - keep number of bytes per transfer word, though the
> > > dma_width is used only to calculate the DMA source/destination addresses
> > > width, which n_bytes could be also utilized for. Taking all of these
> > > into account let's replace the dma_width member usage with n_bytes one
> > > and remove the former.
> >
> > I've no strong opinion about this.
> > So, after addressing one issue below,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
> > > -static enum dma_slave_buswidth convert_dma_width(u32 dma_width) {
> > > - if (dma_width == 1)
> >
> > > +static enum dma_slave_buswidth convert_dma_width(u8 n_bytes) {
> >
> > It seems somebody (maybe even me) at some point messed up between enum
> > definition and function that returns an enum.
> >
> > For what said, { should be on the separate line.
>
> See the patch 16/19: "spi: dw: Cleanup generic DW DMA code namings"
> in this series.
Since you are touching that line here, it makes sense to do it here rather than
ping-pong to other patch in very same series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ARM: dts: at91: Configure I2C SCL gpio as open drain
From: Codrin Ciubotariu @ 2020-05-15 14:00 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-kernel
Cc: robh+dt, nicolas.ferre, alexandre.belloni, ludovic.desroches,
Codrin Ciubotariu
The SCL gpio pin used by I2C bus for recovery needs to be configured as
open drain.
Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
Fixes: a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
Fixes: 8fb82f050cf6 ("ARM: dts: at91: sama5d4: add i2c gpio pinctrl")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 6 +++---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +++---
arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
arch/arm/boot/dts/sama5d4.dtsi | 6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 32435ce1dab2..be33483013e7 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -182,7 +182,7 @@ i2c0: i2c@f8028000 {
pinctrl-0 = <&pinctrl_i2c0_default>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA PIN_PD21 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD22 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
};
@@ -203,7 +203,7 @@ i2c2: i2c@600 {
pinctrl-0 = <&pinctrl_flx0_default>;
pinctrl-1 = <&pinctrl_flx0_gpio>;
sda-gpios = <&pioA PIN_PB28 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PB29 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PB29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
atmel,fifo-size = <16>;
status = "okay";
};
@@ -234,7 +234,7 @@ i2c1: i2c@fc028000 {
pinctrl-0 = <&pinctrl_i2c1_default>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioA PIN_PC6 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PC7 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PC7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
at24@50 {
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e0c6cff1a312..862bf54376f1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -185,7 +185,7 @@ i2c0: i2c@f8028000 {
pinctrl-0 = <&pinctrl_i2c0_default>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA PIN_PD21 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD22 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
i2c-sda-hold-time-ns = <350>;
status = "okay";
@@ -390,7 +390,7 @@ i2c2: i2c@600 {
pinctrl-0 = <&pinctrl_flx4_default>;
pinctrl-1 = <&pinctrl_flx4_gpio>;
sda-gpios = <&pioA PIN_PD12 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD13 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
atmel,fifo-size = <16>;
i2c-analog-filter;
i2c-digital-filter;
@@ -408,7 +408,7 @@ i2c1: i2c@fc028000 {
i2c-digital-filter-width-ns = <35>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioA PIN_PD4 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD5 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
at24@54 {
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index f3ce561b46ab..c53e48445e4d 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -163,7 +163,7 @@ i2c0: i2c@f0014000 {
pinctrl-0 = <&pinctrl_i2c0>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 18>;
@@ -181,7 +181,7 @@ i2c1: i2c@f0018000 {
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioC 26 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioC 27 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioC 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
@@ -367,7 +367,7 @@ i2c2: i2c@f801c000 {
pinctrl-0 = <&pinctrl_i2c2>;
pinctrl-1 = <&pinctrl_i2c2_gpio>;
sda-gpios = <&pioA 18 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 19 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 20>;
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index c9c0316b5b0e..fff679734c9c 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -462,7 +462,7 @@ i2c0: i2c@f8014000 {
pinctrl-0 = <&pinctrl_i2c0>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 32>;
@@ -484,7 +484,7 @@ i2c1: i2c@f8018000 {
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioE 30 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioE 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 33>;
@@ -529,7 +529,7 @@ i2c2: i2c@f8024000 {
pinctrl-0 = <&pinctrl_i2c2>;
pinctrl-1 = <&pinctrl_i2c2_gpio>;
sda-gpios = <&pioB 29 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioB 30 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioB 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 34>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 09/19] spi: dw: Parameterize the DMA Rx/Tx burst length
From: Andy Shevchenko @ 2020-05-15 14:01 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Thomas Gleixner, Wan Ahmad Zainie,
Jarkko Nikula, linux-spi, linux-kernel
In-Reply-To: <20200515104758.6934-10-Sergey.Semin@baikalelectronics.ru>
On Fri, May 15, 2020 at 01:47:48PM +0300, Serge Semin wrote:
> It isn't good to have numeric literals in the code especially if there
> are multiple of them and they are related. Moreover in current
> implementation the Tx DMA transfer activation level isn't optimal,
> since it's hardwired to be at 16-32 bytes level, while it's better
> to keep the SPI FIFO buffer as full as possible until all available
> data is submitted. So lets introduce the DMA burst level
> parametrization macros with optimal values - issue Rx transfer if at
> least 16 bytes are available in the buffer and execute Tx transaction
> if at least 16 bytes room is opened in SPI Tx FIFO.
> - dw_writel(dws, DW_SPI_DMARDLR, 0xf);
> - dw_writel(dws, DW_SPI_DMATDLR, 0x10);
> + dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
> + dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - TX_BURST_LEVEL);
...and if FIFO length is less than TX_BURST_LEVEL?
For the patch that introduces definitions, i.e. keeping the last line here as
dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
I'm good. You may put your tag in that case. For fifo_len case we need to
discuss in separate patch, perhaps.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Fail to configure interrupt for new device
From: Jacko Dirks @ 2020-05-15 14:05 UTC (permalink / raw)
To: devicetree
Hello,
I am working on implementing a new device on the raspberry pi 4, an I2C
slave. The interrupt is not working, and I think I did something wrong
with the DTS. But I cannot quite figure out what it is.
Here is what I have so far:
In bcm2711-rpi-4-b.dts
i2c_slave0_pins: i2cs0 {
brcm,pins = <10 11>;
brcm,function = <BCM2835_FSEL_ALT3>;
};
In bcm2711.dtsi
i2cs0: i2c_slave@7e214000 {
compatible = "brcm,bcm2711-i2c-slave";
reg = <0x7e214000 0x200>;
interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clocks BCM2835_CLOCK_VPU>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};
Interrupt number 107 here is a guess. The guess goes as follows: In the
bcm2711 ARM periphials file there is a table on page 108. This table
shows my interrupt (SPI/BSC slave) to be at place 43. This table also
shows all I2C master interrupts to be at place 53. A I2C master
interrupt uses number 117. 117 - (53 - 43) = 107. So, that approach
might be an issue.
Moreover, I have never specifed that I want that interrupt to be
attached to pin 11. There was a large renovation somewhat recently, but
before that I could drop a line like
interrupts = <2 11>;
Somewhere.
To be complete: here is the overlay:
/dts-v1/;
/plugin/;
/{
compatible = "brcm,bcm2711";
fragment@0 {
target = <&i2cs0>;
frag0: __overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c_slave0_pins>;
};
};
};
Any feedback or input would be very welcome.
Jacko Dirks
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-15 14:25 UTC (permalink / raw)
To: kbuild test robot
Cc: Ramuthevar,Vadivel MuruganX, Linux Kernel Mailing List,
open list:MEMORY TECHNOLOGY..., devicetree, kbuild-all,
Miquel Raynal, Richard Weinberger, Vignesh R, Arnd Bergmann,
Brendan Higgins, Thomas Gleixner, Boris Brezillon, Anders Roxell,
masonccyang
In-Reply-To: <202005152142.AWvx4xc5%lkp@intel.com>
On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
> sparse warnings: (new ones prefixed by >>)
>
> >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
> >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: expected unsigned int val
> >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: got restricted __be32 [assigned] [usertype] reg
> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: expected unsigned int val
> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: got restricted __be32 [assigned] [usertype] reg
>
> 440 reg = cpu_to_be32(*pdata++);
> > 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0);
> 442
> 443 reg = cpu_to_be32(*pdata);
> 444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1);
On BE:
cpu_to_be32 -> no-op
writel() -> converts reg to LE
On LE:
cpu_to_be32 -> converts to BE
writel() -> no-op (in terms of conversion)
Seems to me that the proper API (if above is intended) should be swab32().
But something tells me that above is broken (or my understanding is wrong).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-15 14:27 UTC (permalink / raw)
To: kbuild test robot
Cc: Ramuthevar,Vadivel MuruganX, Linux Kernel Mailing List,
open list:MEMORY TECHNOLOGY..., devicetree, kbuild-all,
Miquel Raynal, Richard Weinberger, Vignesh R, Arnd Bergmann,
Brendan Higgins, Thomas Gleixner, Boris Brezillon, Anders Roxell,
masonccyang
In-Reply-To: <CAHp75Ven9q-6dDYtP_uXigeS_r2uvpUZVR5Mh0RdEd36MbTG+Q@mail.gmail.com>
On Fri, May 15, 2020 at 5:25 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
> > 440 reg = cpu_to_be32(*pdata++);
> > > 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0);
> > 442
> > 443 reg = cpu_to_be32(*pdata);
> > 444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1);
>
> On BE:
> cpu_to_be32 -> no-op
> writel() -> converts reg to LE
>
> On LE:
> cpu_to_be32 -> converts to BE
> writel() -> no-op (in terms of conversion)
>
> Seems to me that the proper API (if above is intended) should be swab32().
> But something tells me that above is broken (or my understanding is wrong).
And perhaps it should use lo_hi_writeq() or something like that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Arnd Bergmann @ 2020-05-15 14:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: kbuild test robot, Ramuthevar,Vadivel MuruganX,
Linux Kernel Mailing List, open list:MEMORY TECHNOLOGY...,
devicetree, kbuild-all, Miquel Raynal, Richard Weinberger,
Vignesh R, Brendan Higgins, Thomas Gleixner, Boris Brezillon,
Anders Roxell, masonccyang
In-Reply-To: <CAHp75Ven9q-6dDYtP_uXigeS_r2uvpUZVR5Mh0RdEd36MbTG+Q@mail.gmail.com>
On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
>
> > sparse warnings: (new ones prefixed by >>)
> >
> > >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
> > >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: expected unsigned int val
> > >> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: got restricted __be32 [assigned] [usertype] reg
> > drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
> > drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: expected unsigned int val
> > drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: got restricted __be32 [assigned] [usertype] reg
> >
> > 440 reg = cpu_to_be32(*pdata++);
> > > 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0);
> > 442
> > 443 reg = cpu_to_be32(*pdata);
> > 444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1);
>
> On BE:
> cpu_to_be32 -> no-op
> writel() -> converts reg to LE
>
> On LE:
> cpu_to_be32 -> converts to BE
> writel() -> no-op (in terms of conversion)
>
> Seems to me that the proper API (if above is intended) should be swab32().
> But something tells me that above is broken (or my understanding is wrong).
iowrite_be32() is the correct way to store word into a big-endian mmio register,
if that is the intention here.
Arnd
^ permalink raw reply
* Re: [PATCH v1 0/4] Optimize fw_devlink parsing
From: Greg Kroah-Hartman @ 2020-05-15 14:36 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rafael J. Wysocki, Rob Herring, Frank Rowand, Len Brown,
Android Kernel Team, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
ACPI Devel Maling List, Ji Luo
In-Reply-To: <CAGETcx-7qnNXug4PGssdXciy0BZrspXP0njJG+GFGFgie_Dwnw@mail.gmail.com>
On Fri, May 15, 2020 at 01:52:37AM -0700, Saravana Kannan wrote:
> On Thu, May 14, 2020 at 10:35 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > When fw_devlink is enabled on hardware with a large number of device
> > tree nodes, the initial device addition done in
> > of_platform_default_populate_init() can be very inefficient. This is
> > because most devices will fail to find all their suppliers when they are
> > added and will keep trying to parse their device tree nodes and link to
> > any newly added devices
> >
> > This was an item on my TODO list that I'm finally getting around to. On
> > hardware I'm testing on, this saved 1.216 _seconds_!
>
> Correction. It went from 1.216 _seconds_ to 61 _milliseconds_! So
> about 95% reduction in time.
Nice speedups! All now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds
From: Andy Shevchenko @ 2020-05-15 14:38 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Arnd Bergmann, Allison Randal,
Gareth Williams, Rob Herring, linux-mips, devicetree,
Georgy Vlasov, Ramil Zaripov, Jarkko Nikula, Thomas Gleixner,
Wan Ahmad Zainie, Linus Walleij, Clement Leger, linux-spi,
linux-kernel
In-Reply-To: <20200515104758.6934-11-Sergey.Semin@baikalelectronics.ru>
On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote:
> Each channel of DMA controller may have a limited length of burst
> transaction (number of IO operations performed at ones in a single
> DMA client request). This parameter can be used to setup the most
> optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer
> overrun we can set the DMA Tx level to be of FIFO depth minus the
> maximum burst transactions length. To prevent the Rx buffer underflow
> the DMA Rx level should be set to the maximum burst transactions length.
> This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels
> in accordance with these rules.
It's good one, but see my comments.
I think this patch should go before previous one.
(and without changes regarding FIFO length)
> +static void mid_spi_maxburst_init(struct dw_spi *dws)
> +{
> + struct dma_slave_caps caps;
> + u32 max_burst, def_burst;
> + int ret;
> +
> + def_burst = dws->fifo_len / 2;
> +
> + ret = dma_get_slave_caps(dws->rxchan, &caps);
> + if (!ret && caps.max_burst)
> + max_burst = caps.max_burst;
> + else
> + max_burst = RX_BURST_LEVEL;
> +
> + dws->rxburst = (def_burst > max_burst) ? max_burst : def_burst;
min() ?
> +
> + ret = dma_get_slave_caps(dws->txchan, &caps);
> + if (!ret && caps.max_burst)
> + max_burst = caps.max_burst;
> + else
> + max_burst = TX_BURST_LEVEL;
> +
> + dws->txburst = (def_burst > max_burst) ? max_burst : def_burst;
Ditto.
> +}
> +
> static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
> {
> struct dw_dma_slave slave = {0};
> @@ -67,6 +92,8 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
> dws->master->dma_rx = dws->rxchan;
> dws->master->dma_tx = dws->txchan;
>
> + mid_spi_maxburst_init(dws);
> +
> return 0;
>
> free_rxchan:
> @@ -92,6 +119,8 @@ static int mid_spi_dma_init_generic(struct device *dev, struct dw_spi *dws)
> dws->master->dma_rx = dws->rxchan;
> dws->master->dma_tx = dws->txchan;
>
> + mid_spi_maxburst_init(dws);
> +
> return 0;
> }
>
> @@ -195,7 +224,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
> memset(&txconf, 0, sizeof(txconf));
> txconf.direction = DMA_MEM_TO_DEV;
> txconf.dst_addr = dws->dma_addr;
> - txconf.dst_maxburst = TX_BURST_LEVEL;
> + txconf.dst_maxburst = dws->txburst;
> txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
> txconf.device_fc = false;
> @@ -268,7 +297,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
> memset(&rxconf, 0, sizeof(rxconf));
> rxconf.direction = DMA_DEV_TO_MEM;
> rxconf.src_addr = dws->dma_addr;
> - rxconf.src_maxburst = RX_BURST_LEVEL;
> + rxconf.src_maxburst = dws->rxburst;
> rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
> rxconf.device_fc = false;
> @@ -293,8 +322,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct spi_transfer *xfer)
> {
> u16 imr = 0, dma_ctrl = 0;
>
> - dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
> - dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - TX_BURST_LEVEL);
> + dw_writel(dws, DW_SPI_DMARDLR, dws->rxburst - 1);
> + dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - dws->txburst);
>
> if (xfer->tx_buf) {
> dma_ctrl |= SPI_DMA_TDMAE;
...
> /* DMA info */
> struct dma_chan *txchan;
> + u32 txburst;
> struct dma_chan *rxchan;
> + u32 rxburst;
Leave u32 together, it may be optimal on 64-bit architectures where ABIs require padding.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 11/19] spi: dw: Initialize paddr in DW SPI MMIO private data
From: Andy Shevchenko @ 2020-05-15 14:39 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Wan Ahmad Zainie, Jarkko Nikula, Jay Fang,
Thomas Gleixner, YueHaibing, Stephen Boyd, linux-spi,
linux-kernel
In-Reply-To: <20200515104758.6934-12-Sergey.Semin@baikalelectronics.ru>
On Fri, May 15, 2020 at 01:47:50PM +0300, Serge Semin wrote:
> This field is used only for the DW SPI DMA code initialization, that's
> why there were no problems with it being uninitialized in Dw SPI MMIO
> driver. Since in a further patch we are going to introduce the DW SPI DMA
> support in the MMIO version of the driver, lets set the field with the
> physical address of the DW SPI controller registers region.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Gareth Williams <gareth.williams.jx@renesas.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> ---
> drivers/spi/spi-dw-mmio.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 398f7926cf92..0894b4c09496 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -184,6 +184,7 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
> int (*init_func)(struct platform_device *pdev,
> struct dw_spi_mmio *dwsmmio);
> struct dw_spi_mmio *dwsmmio;
> + struct resource *mem;
> struct dw_spi *dws;
> int ret;
> int num_cs;
> @@ -196,10 +197,12 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
> dws = &dwsmmio->dws;
>
> /* Get basic io resource and map it */
> - dws->regs = devm_platform_ioremap_resource(pdev, 0);
> + dws->regs = devm_platform_get_and_ioremap_resource(pdev, 0, &mem);
> if (IS_ERR(dws->regs))
> return PTR_ERR(dws->regs);
>
> + dws->paddr = mem->start;
> +
> dws->irq = platform_get_irq(pdev, 0);
> if (dws->irq < 0)
> return dws->irq; /* -ENXIO */
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 12/19] spi: dw: Fix Rx-only DMA transfers
From: Andy Shevchenko @ 2020-05-15 14:40 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Wan Ahmad Zainie, Clement Leger,
Charles Keepax, wuxu.wu, Phil Edworthy, Thomas Gleixner,
linux-spi, linux-kernel
In-Reply-To: <20200515104758.6934-13-Sergey.Semin@baikalelectronics.ru>
On Fri, May 15, 2020 at 01:47:51PM +0300, Serge Semin wrote:
> Tx-only DMA transfers are working perfectly fine since in this case
> the code just ignores the Rx FIFO overflow interrupts. But it turns
> out the SPI Rx-only transfers are broken since nothing pushing any
> data to the shift registers, so the Rx FIFO is left empty and the
> SPI core subsystems just returns a timeout error. Since DW DMAC
> driver doesn't support something like cyclic write operations of
> a single byte to a device register, the only way to support the
> Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
> This is what we intend to fix in this commit by setting the
> SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.
I'm fine with this if Mark considers this right thing to do.
So, conditionally
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Gareth Williams <gareth.williams.jx@renesas.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> ---
> drivers/spi/spi-dw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index 1edb8cdd11ee..31607b40147d 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -517,6 +517,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
> dev_warn(dev, "DMA init failed\n");
> } else {
> master->can_dma = dws->dma_ops->can_dma;
> + master->flags |= SPI_CONTROLLER_MUST_TX;
> }
> }
>
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCHv1 01/19] kobject: increase allowed number of uevent variables
From: Emil Velikov @ 2020-05-15 14:45 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Rob Herring, Greg Kroah-Hartman,
Rafael J . Wysocki, linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-2-sebastian.reichel@collabora.com>
On 2020/05/13, Sebastian Reichel wrote:
> SBS battery driver exposes 32 power supply properties now,
> which will result in uevent failure on (un)plugging the
> battery. Other drivers (e.g. bq27xxx) are also coming close
> to this limit, so increase it.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> include/linux/kobject.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index e2ca0a292e21..75e822569e39 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -29,7 +29,7 @@
> #include <linux/uidgid.h>
>
> #define UEVENT_HELPER_PATH_LEN 256
> -#define UEVENT_NUM_ENVP 32 /* number of env pointers */
> +#define UEVENT_NUM_ENVP 64 /* number of env pointers */
To be on the safe side I've checked systemd/udev. It's using ordered hashmap,
so it's perfectly capable of handling the extra entries.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: i2c: Document I2C controller binding for MT6797 SoC
From: Matthias Brugger @ 2020-05-15 14:48 UTC (permalink / raw)
To: Rob Herring, Manivannan Sadhasivam, Wolfram Sang
Cc: robh+dt, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, adamboardman
In-Reply-To: <20200226222330.GA9392@bogus>
Hi Wolfram,
On 26/02/2020 23:23, Rob Herring wrote:
> On Sat, 22 Feb 2020 21:54:41 +0530, Manivannan Sadhasivam wrote:
>> I2C controller driver for MT6577 SoC is reused for MT6797 SoC. Hence,
>> document that in DT binding.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>
> Acked-by: Rob Herring <robh@kernel.org>
>
Do you want to take this thorough your tree or are you OK if I take it thorough
mine?
Regards,
Matthias
^ permalink raw reply
* Re: [PATCHv1 03/19] power: supply: core: add manufacture date properties
From: Emil Velikov @ 2020-05-15 14:47 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Rob Herring, Greg Kroah-Hartman,
Rafael J . Wysocki, linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-4-sebastian.reichel@collabora.com>
Hi Sebastian,
On 2020/05/13, Sebastian Reichel wrote:
> Some smart batteries store their manufacture date, which is
> useful to identify the battery and/or to know about the cell
> quality.
>
Have you considered exposing this as a single file? Say following the ISO8601
format - YYYY-MM-DD.
-Emil
^ permalink raw reply
* Re: [PATCH 00/16] ARM: dts: at91: sama5d2: Rework Flexcom definitions
From: Alexandre Belloni @ 2020-05-15 14:51 UTC (permalink / raw)
To: Tudor.Ambarus
Cc: Ludovic.Desroches, Nicolas.Ferre, robh+dt, devicetree,
linux-arm-kernel, linux-kernel, Codrin.Ciubotariu
In-Reply-To: <20200514050301.147442-1-tudor.ambarus@microchip.com>
On 14/05/2020 05:03:06+0000, Tudor.Ambarus@microchip.com wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> Rework the sama5d2 SoC flexcom definitions. The Flexcom IPs are
> in the SoC. Move all the flexcom nodes together with their function
> definitions in the SoC dtsi. Boards will just fill the pins and enable
> the desired functions. With this we remove the duplication of the
> flexcom definitions across the sama5d2 boards.
>
> Round the flexcom support and add the missing flexcom definitions.
> All the flexcom functions are now defined.
>
> Apart of the aliases and the new flx0 i2c function on sama5d2_xplained,
> the only functional change that this patch set adds, is that it uart5,
> uart6 and uart7 inherit the atmel,fifo-size = <32>; optional property.
> These nodes have both the FIFO size described and the DMA enabled.
> uart5 was tested on sama5d27-wlsom1-ek. On uart6 and uart7 a
> Bluetooth module can be connected. Tested BT uart7 on sama5d2-icp.
>
> Tudor Ambarus (16):
> ARM: dts: at91: sama5d2: Fix the label numbering for flexcom functions
> ARM: dts: at91: sama5d2: Move flx4 definitions in the SoC dtsi
> ARM: dts: at91: sama5d2: Move flx3 definitions in the SoC dtsi
> ARM: dts: at91: sama5d2: Move flx2 definitions in the SoC dtsi
> ARM: dts: at91: sama5d2: Move flx1 definitions in the SoC dtsi
> ARM: dts: at91: sama5d2: Move flx0 definitions in the SoC dtsi
> ARM: dts: at91: sama5d2: Specify the FIFO size for the Flexcom UART
> ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4
> functions
> ARM: dts: at91: sama5d2: Add DMA bindings for the flx3 SPI function
> ARM: dts: at91: sama5d2: Add DMA bindings for the flx1 I2C function
> ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and I2C flx0
> functions
> ARM: dts: at91: sama5d2: Add missing flexcom definitions
> ARM: dts: at91: sama5d2: Remove i2s and tcb aliases from SoC dtsi
> ARM: dts: at91: sama5d2_xplained: Add alias for DBGU
> ARM: dts: at91: sama5d2_xplained: Describe the flx0 I2C function
> ARM: dts: at91: sama5d2_ptc_ek: Add comments to describe the aliases
>
Applied, thanks.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 13/19] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver
From: Andy Shevchenko @ 2020-05-15 14:51 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Rob Herring, Arnd Bergmann, Allison Randal, Gareth Williams,
linux-mips, devicetree, John Garry, Chuanhong Guo, Joe Perches,
Gregory CLEMENT, Chris Packham, Tomer Maimon, Masahisa Kojima,
Krzysztof Kozlowski, Eddie James, Thomas Gleixner,
Wan Ahmad Zainie, Jarkko Nikula, Chuhong Yuan, Felipe Balbi,
Raymond Tan, wuxu.wu, Clement Leger, linux-spi, linux-kernel
In-Reply-To: <20200515104758.6934-14-Sergey.Semin@baikalelectronics.ru>
On Fri, May 15, 2020 at 01:47:52PM +0300, Serge Semin wrote:
> This is a preparation patch before adding the DW DMA support into the
> DW SPI MMIO driver. We need to unpin the Non-DMA-specific code from the
> intended to be generic DW APB SSI DMA code. This isn't that hard,
> since the most part of the spi-dw-mid.c driver in fact implements a
> generic DMA interface for the DW SPI controller driver. The only Intel
> MID specifics concern getting the max frequency from the MRST Clock
> Control Unit and fetching the DMA controller channels from
> corresponding PCIe DMA controller. Since first one is related with the
> SPI interface configuration we moved it' implementation into the
> DW PCIe-SPI driver module. After that former spi-dw-mid.c file
> can be just renamed to be the DW SPI DMA module optionally compiled in to
> the DW APB SSI core driver.
Cc list here is huge!
I think this patch should go immediately after bunch of fixes.
...
> -obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
> +obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw-core.o
> +spi-dw-core-y := spi-dw.o
> +spi-dw-core-$(CONFIG_SPI_DW_DMA) += spi-dw-dma.o
We may leave module name the same, right?
obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
spi-dw-y := spi-dw-core.o
spi-dw-$(CONFIG_SPI_DW_DMA) += spi-dw-dma.o
> obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o
> -obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o
> -spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
> +obj-$(CONFIG_SPI_DW_PCI) += spi-dw-pci.o
> -/* Some specific info for SPI0 controller on Intel MID */
> -
> -/* HW info for MRST Clk Control Unit, 32b reg per controller */
> -#define MRST_SPI_CLK_BASE 100000000 /* 100m */
> -#define MRST_CLK_SPI_REG 0xff11d86c
> -#define CLK_SPI_BDIV_OFFSET 0
> -#define CLK_SPI_BDIV_MASK 0x00000007
> -#define CLK_SPI_CDIV_OFFSET 9
> -#define CLK_SPI_CDIV_MASK 0x00000e00
> -#define CLK_SPI_DISABLE_OFFSET 8
> -
> -int dw_spi_mid_init_mfld(struct dw_spi *dws)
> -{
> - void __iomem *clk_reg;
> - u32 clk_cdiv;
> -
> - clk_reg = ioremap(MRST_CLK_SPI_REG, 16);
> - if (!clk_reg)
> - return -ENOMEM;
> -
> - /* Get SPI controller operating freq info */
> - clk_cdiv = readl(clk_reg + dws->bus_num * sizeof(u32));
> - clk_cdiv &= CLK_SPI_CDIV_MASK;
> - clk_cdiv >>= CLK_SPI_CDIV_OFFSET;
> - dws->max_freq = MRST_SPI_CLK_BASE / (clk_cdiv + 1);
> -
> - iounmap(clk_reg);
> -
> - /* Register hook to configure CTRLR0 */
> - dws->update_cr0 = dw_spi_update_cr0;
> -
> - dw_spi_mid_setup_dma_mfld(dws);
> - return 0;
> -}
> -
> -int dw_spi_mid_init_generic(struct dw_spi *dws)
> -{
> - /* Register hook to configure CTRLR0 */
> - dws->update_cr0 = dw_spi_update_cr0;
> -
> - dw_spi_mid_setup_dma_generic(dws);
> - return 0;
> -}
> +EXPORT_SYMBOL_GPL(dw_spi_mid_setup_dma_generic);
> diff --git a/drivers/spi/spi-dw-pci.c b/drivers/spi/spi-dw-pci.c
> index dde54a918b5d..c13707b8493e 100644
> --- a/drivers/spi/spi-dw-pci.c
> +++ b/drivers/spi/spi-dw-pci.c
> @@ -15,6 +15,15 @@
>
> #define DRIVER_NAME "dw_spi_pci"
>
> +/* HW info for MRST Clk Control Unit, 32b reg per controller */
> +#define MRST_SPI_CLK_BASE 100000000 /* 100m */
> +#define MRST_CLK_SPI_REG 0xff11d86c
> +#define CLK_SPI_BDIV_OFFSET 0
> +#define CLK_SPI_BDIV_MASK 0x00000007
> +#define CLK_SPI_CDIV_OFFSET 9
> +#define CLK_SPI_CDIV_MASK 0x00000e00
> +#define CLK_SPI_DISABLE_OFFSET 8
> +
> struct spi_pci_desc {
> int (*setup)(struct dw_spi *);
> u16 num_cs;
> @@ -22,20 +31,55 @@ struct spi_pci_desc {
> u32 max_freq;
> };
>
> +static int spi_mid_init(struct dw_spi *dws)
> +{
> + void __iomem *clk_reg;
> + u32 clk_cdiv;
> +
> + clk_reg = ioremap(MRST_CLK_SPI_REG, 16);
> + if (!clk_reg)
> + return -ENOMEM;
> +
> + /* Get SPI controller operating freq info */
> + clk_cdiv = readl(clk_reg + dws->bus_num * sizeof(u32));
> + clk_cdiv &= CLK_SPI_CDIV_MASK;
> + clk_cdiv >>= CLK_SPI_CDIV_OFFSET;
> + dws->max_freq = MRST_SPI_CLK_BASE / (clk_cdiv + 1);
> +
> + iounmap(clk_reg);
> +
> + /* Register hook to configure CTRLR0 */
> + dws->update_cr0 = dw_spi_update_cr0;
> +
> + dw_spi_mid_setup_dma_mfld(dws);
> +
> + return 0;
> +}
> +
> +static int spi_generic_init(struct dw_spi *dws)
> +{
> + /* Register hook to configure CTRLR0 */
> + dws->update_cr0 = dw_spi_update_cr0;
> +
> + dw_spi_mid_setup_dma_generic(dws);
> +
> + return 0;
> +}
> +
> static struct spi_pci_desc spi_pci_mid_desc_1 = {
> - .setup = dw_spi_mid_init_mfld,
> + .setup = spi_mid_init,
> .num_cs = 5,
> .bus_num = 0,
> };
>
> static struct spi_pci_desc spi_pci_mid_desc_2 = {
> - .setup = dw_spi_mid_init_mfld,
> + .setup = spi_mid_init,
> .num_cs = 2,
> .bus_num = 1,
> };
>
> static struct spi_pci_desc spi_pci_ehl_desc = {
> - .setup = dw_spi_mid_init_generic,
> + .setup = spi_generic_init,
> .num_cs = 2,
> .bus_num = -1,
> .max_freq = 100000000,
> diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
> index d0c8b7d3a5d2..75fdcc5e7642 100644
> --- a/drivers/spi/spi-dw.h
> +++ b/drivers/spi/spi-dw.h
> @@ -265,8 +265,16 @@ extern u32 dw_spi_update_cr0_v1_01a(struct spi_controller *master,
> struct spi_device *spi,
> struct spi_transfer *transfer);
>
> -/* platform related setup */
> -extern int dw_spi_mid_init_mfld(struct dw_spi *dws);
> -extern int dw_spi_mid_init_generic(struct dw_spi *dws);
> +#ifdef CONFIG_SPI_DW_DMA
> +
> +extern void dw_spi_mid_setup_dma_mfld(struct dw_spi *dws);
> +extern void dw_spi_mid_setup_dma_generic(struct dw_spi *dws);
> +
I would drop blank lines and extern keywords.
> +#else
> +
> +static inline void dw_spi_mid_setup_dma_mfld(struct dw_spi *dws) {}
> +static inline void dw_spi_mid_setup_dma_generic(struct dw_spi *dws) {}
> +
Ditto for blank lines.
> +#endif /* !CONFIG_SPI_DW_DMA */
>
> #endif /* DW_SPI_HEADER_H */
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: Configure I2C SCL gpio as open drain
From: Alexandre Belloni @ 2020-05-15 14:58 UTC (permalink / raw)
To: Codrin Ciubotariu
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt,
nicolas.ferre, ludovic.desroches
In-Reply-To: <20200515140001.287932-1-codrin.ciubotariu@microchip.com>
On 15/05/2020 17:00:01+0300, Codrin Ciubotariu wrote:
> The SCL gpio pin used by I2C bus for recovery needs to be configured as
> open drain.
>
> Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
> Fixes: a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
> Fixes: 8fb82f050cf6 ("ARM: dts: at91: sama5d4: add i2c gpio pinctrl")
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 6 +++---
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +++---
> arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
> arch/arm/boot/dts/sama5d4.dtsi | 6 +++---
> 4 files changed, 12 insertions(+), 12 deletions(-)
>
Applied, thanks. There was a small conflict in the sama5d2 board dts,
please check.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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