* [PATCH net-next v6 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/phy_device.c | 68 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 4 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..611d4e68e3c6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -31,6 +31,7 @@
#include <linux/mdio.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/property.h>
MODULE_DESCRIPTION("PHY library");
MODULE_AUTHOR("Andy Fleming");
@@ -2657,6 +2658,73 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @dev: pointer to the devices device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @is_rx: boolean to indicate to get the rx internal delay
+ *
+ * Returns the index within the array of internal delay passed in.
+ * Or if size == 0 then the delay read from the firmware is returned.
+ * The array must be in ascending order.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx)
+{
+ int ret;
+ int i;
+ s32 delay;
+
+ if (is_rx)
+ ret = device_property_read_u32(dev, "rx-internal-delay-ps",
+ &delay);
+ else
+ ret = device_property_read_u32(dev, "tx-internal-delay-ps",
+ &delay);
+ if (ret) {
+ phydev_err(phydev, "internal delay not defined\n");
+ return -EINVAL;
+ }
+
+ if (delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return delay;
+
+ if (delay < delay_values[0] || delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", delay);
+ return -EINVAL;
+ }
+
+ if (delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (delay > delay_values[i - 1] &&
+ delay < delay_values[i]) {
+ if (delay - delay_values[i - 1] <
+ delay_values[i] - delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ delay);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(phy_get_internal_delay);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8c05d0fb5c00..917bfd422e06 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1430,6 +1430,10 @@ void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx);
+
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ethernet-phy.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 9b1f1147ca36..edd0245d132b 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -162,6 +162,19 @@ properties:
description:
Specifies a reference to a node representing a SFP cage.
+
+ rx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable RX internal delays.
+
+ tx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable TX internal delays.
+
required:
- reg
--
2.26.2
^ permalink raw reply related
* Re: [PATCH V1 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: ppvk @ 2020-06-04 11:13 UTC (permalink / raw)
To: Sibi Sankar
Cc: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka, linux-mmc, linux-kernel, linux-arm-msm,
devicetree, linux-mmc-owner, rnayak, matthias,
linux-arm-msm-owner
In-Reply-To: <29826613b412e4f4db4289e292a1fe57@codeaurora.org>
Hi Sibi,
Thanks for the review!!
On 2020-06-03 17:22, Sibi Sankar wrote:
> Hey Pradeep,
> Thanks for the patch.
>
> On 2020-06-03 14:39, Pradeep P V K wrote:
>> Interconnect bandwidth scaling support is now added as a
>> part of OPP [1]. So, make sure interconnect driver is ready
>> before handling interconnect scaling.
>>
>> This change is based on
>> [1] [Patch v8] Introduce OPP bandwidth bindings
>> (https://lkml.org/lkml/2020/5/12/493)
>>
>> [2] [Patch v3] mmc: sdhci-msm: Fix error handling
>> for dev_pm_opp_of_add_table()
>> (https://lkml.org/lkml/2020/5/5/491)
>>
>> Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
>> ---
>> drivers/mmc/host/sdhci-msm.c | 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);
>
> ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
>
> since there are multiple paths
> described in the bindings you
> should use ^^ instead and you
> can drop temporary path as well.
>
Ok. of_icc_get() used above is only to test if ICC driver is ready or
not. I'm not
really using the multiple paths here. Anyhow i will use
dev_pm_opp_of_find_icc_paths()
to get rid of some extra lines of code.
>> +
>> 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);
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
From: Mark Brown @ 2020-06-04 11:13 UTC (permalink / raw)
To: Lukas Wunner
Cc: Florian Fainelli, linux-kernel, Rob Herring,
Nicolas Saenz Julienne, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:SPI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl
In-Reply-To: <20200604042038.jzolu6k7q3d6bsvq@wunner.de>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Thu, Jun 04, 2020 at 06:20:38AM +0200, Lukas Wunner wrote:
> On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> > The BCM2711 SoC features 5 SPI controllers which all share the same
> > interrupt line, the SPI driver needs to support interrupt sharing,
> > therefore use the chip specific compatible string to help with that.
> You're saying above that the 5 controllers all share the interrupt
> but below you're only changing the compatible string of 4 controllers.
> So I assume spi0 still has its own interrupt and only the additional
> 4 controllers present on the BCM2711/BCM7211 share their interrupt?
Regardless of what's going on with the interrupts the compatible string
should reflect the IP version so unless for some reason someone taped
out two different versions of the IP it seems odd that the compatible
strings would vary within a given SoC.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx pin
From: Mark Brown @ 2020-06-04 11:07 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Liam Girdwood, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-2-luca@lucaceresoli.net>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
On Wed, Jun 03, 2020 at 10:03:16PM +0200, Luca Ceresoli wrote:
> I suspect the only solution that allows to configure the EN_PIN_CTRLn bits
> correctly in all the possible hardware setups would be to tell in device
> tree / board info whether each enable pin is connected or not (which is a
> hardware _fact_) and which ENx pin should control which regulator output
> (which is a policy). But it would make this simple driver considerably more
> complex.
> Any suggestion about the correct way to handle this situation would be
> greatly appreciated.
We can tell if we've got a software controlled GPIO connected, if we
have then we should ensure that it continues to take effect. That
should just be a single register write at startup from the sounds of it.
Otherwise yeah, just ignoring that there's a possibility of a GPIO we
don't know about seems sensible.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Sai Prakash Ranjan @ 2020-06-04 11:07 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel, devicetree-owner
In-Reply-To: <20200604004331.669936-7-dmitry.baryshkov@linaro.org>
On 2020-06-04 06:13, Dmitry Baryshkov wrote:
> Add on-SoC watchdog device node.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 972d8e04c8a2..f1641c6fe203 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -1662,6 +1662,12 @@ config {
> };
> };
>
> + watchdog@17c10000 {
> + compatible = "qcom,apss-wdt-sm8250", "qcom,kpss-wdt";
Need to add this compatible to bindings.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Vinod Koul @ 2020-06-04 10:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-7-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Add on-SoC watchdog device node.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: pm8150: enable rtc device
From: Vinod Koul @ 2020-06-04 10:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-6-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Enable rtc device provided by the pmic.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/pm8150.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> index fee2db42f4cb..762fb902db81 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> @@ -71,8 +71,6 @@ rtc@6000 {
> reg = <0x6000>;
> reg-names = "rtc", "alarm";
> interrupts = <0x0 0x61 0x1 IRQ_TYPE_NONE>;
> -
> - status = "disabled";
Again, pls enable in your board dts...
Thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: pm8150x: add thermal alarms and thermal zones
From: Vinod Koul @ 2020-06-04 10:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-5-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Add temperature alarm and thermal zone configuration to all three
> pm8150 instances. Configuration is largely based on the msm-4.19 tree.
> These alarms use main adc of the pmic. Separate temperature adc is not
> supported yet.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/pm8150.dtsi | 41 +++++++++++++++++++++++--
> arch/arm64/boot/dts/qcom/pm8150b.dtsi | 43 +++++++++++++++++++++++++--
> arch/arm64/boot/dts/qcom/pm8150l.dtsi | 43 +++++++++++++++++++++++++--
> 3 files changed, 119 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> index c0b197458665..fee2db42f4cb 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> @@ -30,6 +30,15 @@ pwrkey {
> };
> };
>
> + pm8150_temp: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
> + io-channels = <&pm8150_adc ADC5_DIE_TEMP>;
> + io-channel-names = "thermal";
> + #thermal-sensor-cells = <0>;
> + };
> +
> pm8150_adc: adc@3100 {
> compatible = "qcom,spmi-adc5";
> reg = <0x3100>;
> @@ -38,8 +47,6 @@ pm8150_adc: adc@3100 {
> #io-channel-cells = <1>;
> interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
>
> - status = "disabled";
> -
This should not be removed, rather than this please add enabled in you
board dts file
> ref-gnd@0 {
> reg = <ADC5_REF_GND>;
> qcom,pre-scaling = <1 1>;
> @@ -85,3 +92,33 @@ pmic@1 {
> #size-cells = <0>;
> };
> };
> +
> +&thermal_zones {
> + pm8150_temp {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> +
> + thermal-sensors = <&pm8150_temp>;
> +
> + trips {
> + trip0 {
> + temperature = <95000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + trip1 {
> + temperature = <115000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + trip2 {
> + temperature = <145000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> + };
> +
> + };
Not sure about this, Amit..? Should this also not be in board dts?
Similar comments on similar ones for rest of the patch as well..
--
~Vinod
^ permalink raw reply
* [v2] drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
From: Harigovindan P @ 2020-06-04 10:34 UTC (permalink / raw)
To: dri-devel, linux-arm-msm, freedreno, devicetree
Cc: Harigovindan P, linux-kernel, robdclark, seanpaul, hoegsberg,
kalyan_t, nganji, sam
ti-sn65dsi86 bridge is enumerated as a runtime device.
Adding sleep ops to force runtime_suspend when PM suspend is
requested on the device.
Signed-off-by: Harigovindan P <harigovi@codeaurora.org>
---
Changes in v2:
- Include bridge name in the commit message and
remove dependent patchwork link from the commit
text as bridge is independent of OEM(Stephen Boyd)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..2eef755b2917 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -159,6 +159,8 @@ static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
static const struct dev_pm_ops ti_sn_bridge_pm_ops = {
SET_RUNTIME_PM_OPS(ti_sn_bridge_suspend, ti_sn_bridge_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static int status_show(struct seq_file *s, void *data)
--
2.27.0
^ permalink raw reply related
* [PATCH v7 5/5] drivers/tty/serial: add LiteUART driver
From: Mateusz Holenko @ 2020-06-04 10:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
This commit adds driver for the FPGA-based LiteUART serial controller
from LiteX SoC builder.
The current implementation supports LiteUART configured
for 32 bit data width and 8 bit CSR bus width.
It does not support IRQ.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
---
Notes:
Changed in v7:
- added missing include directive
Changes in v6:
- LiteUART ports now stored in xArray
- removed PORT_LITEUART
- fixed formatting
- removed some unnecessary defines
No changes in v5.
Changes in v4:
- fixed copyright header
- removed a wrong dependency on UARTLITE from Kconfig
- added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig
Changes in v3:
- aliases made optional
- used litex_get_reg/litex_set_reg functions instead of macros
- SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS
- PORT_LITEUART changed from 122 to 123
- added dependency on LITEX_SOC_CONTROLLER
- patch number changed from 4 to 5
No changes in v2.
MAINTAINERS | 1 +
drivers/tty/serial/Kconfig | 31 +++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 405 ++++++++++++++++++++++++++++++++++
4 files changed, 438 insertions(+)
create mode 100644 drivers/tty/serial/liteuart.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b6d926a6ed04..d06d099aa56f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9924,6 +9924,7 @@ M: Mateusz Holenko <mholenko@antmicro.com>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
F: drivers/soc/litex/litex_soc_ctrl.c
+F: drivers/tty/serial/liteuart.c
F: include/linux/litex.h
LIVE PATCHING
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index adf9e80e7dc9..17aaf0afb27a 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1562,6 +1562,37 @@ config SERIAL_MILBEAUT_USIO_CONSOLE
receives all kernel messages and warnings and which allows logins in
single user mode).
+config SERIAL_LITEUART
+ tristate "LiteUART serial port support"
+ depends on HAS_IOMEM
+ depends on OF || COMPILE_TEST
+ depends on LITEX_SOC_CONTROLLER
+ select SERIAL_CORE
+ help
+ This driver is for the FPGA-based LiteUART serial controller from LiteX
+ SoC builder.
+
+ Say 'Y' here if you wish to use the LiteUART serial controller.
+ Otherwise, say 'N'.
+
+config SERIAL_LITEUART_MAX_PORTS
+ int "Maximum number of LiteUART ports"
+ depends on SERIAL_LITEUART
+ default "1"
+ help
+ Set this to the maximum number of serial ports you want the driver
+ to support.
+
+config SERIAL_LITEUART_CONSOLE
+ bool "LiteUART serial port console support"
+ depends on SERIAL_LITEUART=y
+ select SERIAL_CORE_CONSOLE
+ help
+ Say 'Y' here if you wish to use the FPGA-based LiteUART serial controller
+ from LiteX SoC builder as the system console (the system console is the
+ device which receives all kernel messages and warnings and which allows
+ logins in single user mode). Otherwise, say 'N'.
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index d056ee6cca33..9f8ba419ff3b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
obj-$(CONFIG_SERIAL_RDA) += rda-uart.o
obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o
obj-$(CONFIG_SERIAL_SIFIVE) += sifive.o
+obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o
# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c
new file mode 100644
index 000000000000..b90e51fad281
--- /dev/null
+++ b/drivers/tty/serial/liteuart.c
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteUART serial controller (LiteX) Driver
+ *
+ * Copyright (C) 2019-2020 Antmicro <www.antmicro.com>
+ */
+
+#include <linux/console.h>
+#include <linux/litex.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/tty_flip.h>
+#include <linux/xarray.h>
+
+/*
+ * CSRs definitions (base address offsets + width)
+ *
+ * The definitions below are true for LiteX SoC configured for 8-bit CSR Bus,
+ * 32-bit aligned.
+ *
+ * Supporting other configurations might require new definitions or a more
+ * generic way of indexing the LiteX CSRs.
+ *
+ * For more details on how CSRs are defined and handled in LiteX, see comments
+ * in the LiteX SoC Driver: drivers/soc/litex/litex_soc_ctrl.c
+ */
+#define OFF_RXTX 0x00
+#define OFF_TXFULL 0x04
+#define OFF_RXEMPTY 0x08
+#define OFF_EV_STATUS 0x0c
+#define OFF_EV_PENDING 0x10
+#define OFF_EV_ENABLE 0x14
+
+/* events */
+#define EV_TX 0x1
+#define EV_RX 0x2
+
+struct liteuart_port {
+ struct uart_port port;
+ struct timer_list timer;
+};
+
+#define to_liteuart_port(port) container_of(port, struct liteuart_port, port)
+
+static DEFINE_XARRAY_FLAGS(liteuart_array, XA_FLAGS_ALLOC);
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+static struct console liteuart_console;
+#endif
+
+static struct uart_driver liteuart_driver = {
+ .owner = THIS_MODULE,
+ .driver_name = "liteuart",
+ .dev_name = "ttyLXU",
+ .major = 0,
+ .minor = 0,
+ .nr = CONFIG_SERIAL_LITEUART_MAX_PORTS,
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+ .cons = &liteuart_console,
+#endif
+};
+
+static void liteuart_timer(struct timer_list *t)
+{
+ struct liteuart_port *uart = from_timer(uart, t, timer);
+ struct uart_port *port = &uart->port;
+ unsigned char __iomem *membase = port->membase;
+ unsigned int flg = TTY_NORMAL;
+ int ch;
+ unsigned long status;
+
+ while ((status = !litex_get_reg(membase + OFF_RXEMPTY, 1)) == 1) {
+ ch = litex_get_reg(membase + OFF_RXTX, 1);
+ port->icount.rx++;
+
+ /* necessary for RXEMPTY to refresh its value */
+ litex_set_reg(membase + OFF_EV_PENDING, 1, EV_TX | EV_RX);
+
+ /* no overflow bits in status */
+ if (!(uart_handle_sysrq_char(port, ch)))
+ uart_insert_char(port, status, 0, ch, flg);
+
+ tty_flip_buffer_push(&port->state->port);
+ }
+
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+}
+
+static void liteuart_putchar(struct uart_port *port, int ch)
+{
+ while (litex_get_reg(port->membase + OFF_TXFULL, 1))
+ cpu_relax();
+
+ litex_set_reg(port->membase + OFF_RXTX, 1, ch);
+}
+
+static unsigned int liteuart_tx_empty(struct uart_port *port)
+{
+ /* not really tx empty, just checking if tx is not full */
+ if (!litex_get_reg(port->membase + OFF_TXFULL, 1))
+ return TIOCSER_TEMT;
+
+ return 0;
+}
+
+static void liteuart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ /* modem control register is not present in LiteUART */
+}
+
+static unsigned int liteuart_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void liteuart_stop_tx(struct uart_port *port)
+{
+}
+
+static void liteuart_start_tx(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+ unsigned char ch;
+
+ if (unlikely(port->x_char)) {
+ litex_set_reg(port->membase + OFF_RXTX, 1, port->x_char);
+ port->icount.tx++;
+ port->x_char = 0;
+ } else if (!uart_circ_empty(xmit)) {
+ while (xmit->head != xmit->tail) {
+ ch = xmit->buf[xmit->tail];
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
+ liteuart_putchar(port, ch);
+ }
+ }
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+}
+
+static void liteuart_stop_rx(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* just delete timer */
+ del_timer(&uart->timer);
+}
+
+static void liteuart_break_ctl(struct uart_port *port, int break_state)
+{
+ /* LiteUART doesn't support sending break signal */
+}
+
+static int liteuart_startup(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* disable events */
+ litex_set_reg(port->membase + OFF_EV_ENABLE, 1, 0);
+
+ /* prepare timer for polling */
+ timer_setup(&uart->timer, liteuart_timer, 0);
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+
+ return 0;
+}
+
+static void liteuart_shutdown(struct uart_port *port)
+{
+}
+
+static void liteuart_set_termios(struct uart_port *port, struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* update baudrate */
+ baud = uart_get_baud_rate(port, new, old, 0, 460800);
+ uart_update_timeout(port, new->c_cflag, baud);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *liteuart_type(struct uart_port *port)
+{
+ return "liteuart";
+}
+
+static void liteuart_release_port(struct uart_port *port)
+{
+}
+
+static int liteuart_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+static void liteuart_config_port(struct uart_port *port, int flags)
+{
+ /*
+ * Driver core for serial ports forces a non-zero value for port type.
+ * Write an arbitrary value here to accommodate the serial core driver,
+ * as ID part of UAPI is redundant.
+ */
+ port->type = 1;
+}
+
+static int liteuart_verify_port(struct uart_port *port,
+ struct serial_struct *ser)
+{
+ if (port->type != PORT_UNKNOWN && ser->type != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct uart_ops liteuart_ops = {
+ .tx_empty = liteuart_tx_empty,
+ .set_mctrl = liteuart_set_mctrl,
+ .get_mctrl = liteuart_get_mctrl,
+ .stop_tx = liteuart_stop_tx,
+ .start_tx = liteuart_start_tx,
+ .stop_rx = liteuart_stop_rx,
+ .break_ctl = liteuart_break_ctl,
+ .startup = liteuart_startup,
+ .shutdown = liteuart_shutdown,
+ .set_termios = liteuart_set_termios,
+ .type = liteuart_type,
+ .release_port = liteuart_release_port,
+ .request_port = liteuart_request_port,
+ .config_port = liteuart_config_port,
+ .verify_port = liteuart_verify_port,
+};
+
+static int liteuart_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ struct xa_limit limit;
+ int dev_id, ret;
+
+ /* no device tree */
+ if (!np)
+ return -ENODEV;
+
+ if (!litex_check_accessors())
+ return -EPROBE_DEFER;
+
+ /* look for aliases; auto-enumerate for free index if not found */
+ dev_id = of_alias_get_id(np, "serial");
+ if (dev_id < 0)
+ limit = XA_LIMIT(0, CONFIG_SERIAL_LITEUART_MAX_PORTS);
+ else
+ limit = XA_LIMIT(dev_id, dev_id);
+
+ uart = kzalloc(sizeof(struct liteuart_port), GFP_KERNEL);
+ if (!uart)
+ return -ENOMEM;
+
+ ret = xa_alloc(&liteuart_array, &dev_id, uart, limit, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ port = &uart->port;
+
+ /* get membase */
+ port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+ if (!port->membase)
+ return -ENXIO;
+
+ /* values not from device tree */
+ port->dev = &pdev->dev;
+ port->iotype = UPIO_MEM;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->ops = &liteuart_ops;
+ port->regshift = 2;
+ port->fifosize = 16;
+ port->iobase = 1;
+ port->type = PORT_UNKNOWN;
+ port->line = dev_id;
+ spin_lock_init(&port->lock);
+
+ return uart_add_one_port(&liteuart_driver, &uart->port);
+}
+
+static int liteuart_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id liteuart_of_match[] = {
+ { .compatible = "litex,liteuart" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, liteuart_of_match);
+
+static struct platform_driver liteuart_platform_driver = {
+ .probe = liteuart_probe,
+ .remove = liteuart_remove,
+ .driver = {
+ .name = "liteuart",
+ .of_match_table = liteuart_of_match,
+ },
+};
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+
+static void liteuart_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ unsigned long flags;
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ port = &uart->port;
+
+ spin_lock_irqsave(&port->lock, flags);
+ uart_console_write(port, s, count, liteuart_putchar);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int liteuart_console_setup(struct console *co, char *options)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ int baud = 115200;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ if (!uart)
+ return -ENODEV;
+
+ port = &uart->port;
+ if (!port->membase)
+ return -ENODEV;
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct console liteuart_console = {
+ .name = "liteuart",
+ .write = liteuart_console_write,
+ .device = uart_console_device,
+ .setup = liteuart_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &liteuart_driver,
+};
+
+static int __init liteuart_console_init(void)
+{
+ register_console(&liteuart_console);
+
+ return 0;
+}
+console_initcall(liteuart_console_init);
+#endif /* CONFIG_SERIAL_LITEUART_CONSOLE */
+
+static int __init liteuart_init(void)
+{
+ int res;
+
+ res = uart_register_driver(&liteuart_driver);
+ if (res)
+ return res;
+
+ res = platform_driver_register(&liteuart_platform_driver);
+ if (res) {
+ uart_unregister_driver(&liteuart_driver);
+ return res;
+ }
+
+ return 0;
+}
+
+static void __exit liteuart_exit(void)
+{
+ platform_driver_unregister(&liteuart_platform_driver);
+ uart_unregister_driver(&liteuart_driver);
+}
+
+module_init(liteuart_init);
+module_exit(liteuart_exit);
+
+MODULE_AUTHOR("Antmicro <www.antmicro.com>");
+MODULE_DESCRIPTION("LiteUART serial driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform: liteuart");
--
2.20.1
^ permalink raw reply related
* [PATCH v7 4/5] dt-bindings: serial: document LiteUART bindings
From: Mateusz Holenko @ 2020-06-04 10:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
Add documentation for LiteUART devicetree bindings.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
Changes in v6:
- fixed license header
No changes in v5.
No changes in v4.
Changes in v3:
- added Reviewed-by tag
- patch number changed from 3 to 4
- removed changes in MAINTAINERS file (moved to patch #2)
Changes in v2:
- binding description rewritten to a yaml schema file
- added interrupt line
- fixed unit address
- patch number changed from 2 to 3
.../bindings/serial/litex,liteuart.yaml | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
new file mode 100644
index 000000000000..87bf846b170a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LiteUART serial controller
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+description: |
+ LiteUART serial controller is a part of LiteX FPGA SoC builder. It supports
+ multiple CPU architectures, currently including e.g. OpenRISC and RISC-V.
+
+properties:
+ compatible:
+ const: litex,liteuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ uart0: serial@e0001800 {
+ compatible = "litex,liteuart";
+ reg = <0xe0001800 0x100>;
+ interrupts = <2>;
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v7 3/5] drivers/soc/litex: add LiteX SoC Controller driver
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
This commit adds driver for the FPGA-based LiteX SoC
Controller from LiteX SoC builder.
Co-developed-by: Mateusz Holenko <mholenko@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Signed-off-by: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
---
Notes:
No changes in v7.
Changes in v6:
- added dependency on OF || COMPILE_TEST
- used le32_to_cpu(readl(addr)) instead of __raw_readl
and writel(cpu_to_le32(value), addr) instead of __raw_writel
to take advantage of memory barriers provided by readl/writel
Changes in v5:
- removed helper accessors and used __raw_readl/__raw_writel instead
- fixed checking for errors in litex_soc_ctrl_probe
Changes in v4:
- fixed indent in Kconfig's help section
- fixed copyright header
- changed compatible to "litex,soc-controller"
- simplified litex_soc_ctrl_probe
- removed unnecessary litex_soc_ctrl_remove
This commit has been introduced in v3 of the patchset.
It includes a simplified version of common 'litex.h'
header introduced in v2 of the patchset.
MAINTAINERS | 2 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 15 +++
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 197 +++++++++++++++++++++++++++++
include/linux/litex.h | 45 +++++++
7 files changed, 264 insertions(+)
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 include/linux/litex.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e3f8804c08d7..b6d926a6ed04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9923,6 +9923,8 @@ M: Karol Gugala <kgugala@antmicro.com>
M: Mateusz Holenko <mholenko@antmicro.com>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
+F: drivers/soc/litex/litex_soc_ctrl.c
+F: include/linux/litex.h
LIVE PATCHING
M: Josh Poimboeuf <jpoimboe@redhat.com>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..d097d070f579 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -9,6 +9,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/imx/Kconfig"
source "drivers/soc/ixp4xx/Kconfig"
+source "drivers/soc/litex/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/renesas/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..0b16108823ef 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-y += imx/
obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/
obj-y += mediatek/
obj-y += amlogic/
obj-y += qcom/
diff --git a/drivers/soc/litex/Kconfig b/drivers/soc/litex/Kconfig
new file mode 100644
index 000000000000..c974ec3846bc
--- /dev/null
+++ b/drivers/soc/litex/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License_Identifier: GPL-2.0
+
+menu "Enable LiteX SoC Builder specific drivers"
+
+config LITEX_SOC_CONTROLLER
+ tristate "Enable LiteX SoC Controller driver"
+ depends on OF || COMPILE_TEST
+ help
+ This option enables the SoC Controller Driver which verifies
+ LiteX CSR access and provides common litex_get_reg/litex_set_reg
+ accessors.
+ All drivers that use functions from litex.h must depend on
+ LITEX_SOC_CONTROLLER.
+
+endmenu
diff --git a/drivers/soc/litex/Makefile b/drivers/soc/litex/Makefile
new file mode 100644
index 000000000000..98ff7325b1c0
--- /dev/null
+++ b/drivers/soc/litex/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License_Identifier: GPL-2.0
+
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex_soc_ctrl.o
diff --git a/drivers/soc/litex/litex_soc_ctrl.c b/drivers/soc/litex/litex_soc_ctrl.c
new file mode 100644
index 000000000000..319be92fc63f
--- /dev/null
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteX SoC Controller Driver
+ *
+ * Copyright (C) 2020 Antmicro <www.antmicro.com>
+ *
+ */
+
+#include <linux/litex.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+
+/*
+ * The parameters below are true for LiteX SoC
+ * configured for 8-bit CSR Bus, 32-bit aligned.
+ *
+ * Supporting other configurations will require
+ * extending the logic in this header.
+ */
+#define LITEX_REG_SIZE 0x4
+#define LITEX_SUBREG_SIZE 0x1
+#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8)
+
+static DEFINE_SPINLOCK(csr_lock);
+
+/*
+ * LiteX SoC Generator, depending on the configuration,
+ * can split a single logical CSR (Control & Status Register)
+ * into a series of consecutive physical registers.
+ *
+ * For example, in the configuration with 8-bit CSR Bus,
+ * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit
+ * logical CSR will be generated as four 32-bit physical registers,
+ * each one containing one byte of meaningful data.
+ *
+ * For details see: https://github.com/enjoy-digital/litex/wiki/CSR-Bus
+ *
+ * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
+ * the logic of writing to/reading from the LiteX CSR in a single
+ * place that can be then reused by all LiteX drivers.
+ */
+void litex_set_reg(void __iomem *reg, unsigned long reg_size,
+ unsigned long val)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ shifted_data = val >> shift;
+
+ writel(cpu_to_le32(shifted_data), reg + (LITEX_REG_SIZE * i));
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+}
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_size)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long result = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shifted_data = le32_to_cpu(readl(reg + (LITEX_REG_SIZE * i)));
+
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ result |= (shifted_data << shift);
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+
+ return result;
+}
+
+static int accessors_ok;
+
+/*
+ * Check if accessors are safe to be used by other drivers
+ * returns true if yes - false if not
+ */
+int litex_check_accessors(void)
+{
+ return accessors_ok;
+}
+
+#define SCRATCH_REG_OFF 0x04
+#define SCRATCH_REG_SIZE 4
+#define SCRATCH_REG_VALUE 0x12345678
+#define SCRATCH_TEST_VALUE 0xdeadbeef
+
+/*
+ * Check LiteX CSR read/write access
+ *
+ * This function reads and writes a scratch register in order
+ * to verify if CSR access works.
+ *
+ * In case any problems are detected, the driver should panic
+ * and not set `accessors_ok` flag. As a result no other
+ * LiteX driver should access CSR bus.
+ *
+ * Access to the LiteX CSR is, by design, done in CPU native
+ * endianness. The driver should not dynamically configure
+ * access functions when the endianness mismatch is detected.
+ * Such situation indicates problems in the soft SoC design
+ * and should be solved at the LiteX generator level,
+ * not in the software.
+ */
+static int litex_check_csr_access(void __iomem *reg_addr)
+{
+ unsigned long reg;
+
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_REG_VALUE) {
+ panic("Scratch register read error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_REG_VALUE, reg);
+ return -EINVAL;
+ }
+
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE);
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_TEST_VALUE) {
+ panic("Scratch register write error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_TEST_VALUE, reg);
+ return -EINVAL;
+ }
+
+ /* restore original value of the SCRATCH register */
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_REG_VALUE);
+
+ /* Set flag for other drivers */
+ accessors_ok = 1;
+ pr_info("LiteX SoC Controller driver initialized");
+
+ return 0;
+}
+
+struct litex_soc_ctrl_device {
+ void __iomem *base;
+};
+
+static const struct of_device_id litex_soc_ctrl_of_match[] = {
+ {.compatible = "litex,soc-controller"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match);
+
+static int litex_soc_ctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev;
+ struct device_node *node;
+ struct litex_soc_ctrl_device *soc_ctrl_dev;
+
+ dev = &pdev->dev;
+ node = dev->of_node;
+ if (!node)
+ return -ENODEV;
+
+ soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
+ if (!soc_ctrl_dev)
+ return -ENOMEM;
+
+ soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(soc_ctrl_dev->base))
+ return PTR_ERR(soc_ctrl_dev->base);
+
+ return litex_check_csr_access(soc_ctrl_dev->base);
+}
+
+static struct platform_driver litex_soc_ctrl_driver = {
+ .driver = {
+ .name = "litex-soc-controller",
+ .of_match_table = of_match_ptr(litex_soc_ctrl_of_match)
+ },
+ .probe = litex_soc_ctrl_probe,
+};
+
+module_platform_driver(litex_soc_ctrl_driver);
+MODULE_DESCRIPTION("LiteX SoC Controller driver");
+MODULE_AUTHOR("Antmicro <www.antmicro.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/litex.h b/include/linux/litex.h
new file mode 100644
index 000000000000..f31062436273
--- /dev/null
+++ b/include/linux/litex.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Common LiteX header providing
+ * helper functions for accessing CSRs.
+ *
+ * Implementation of the functions is provided by
+ * the LiteX SoC Controller driver.
+ *
+ * Copyright (C) 2019-2020 Antmicro <www.antmicro.com>
+ */
+
+#ifndef _LINUX_LITEX_H
+#define _LINUX_LITEX_H
+
+#include <linux/io.h>
+#include <linux/types.h>
+#include <linux/compiler_types.h>
+
+/*
+ * litex_check_accessors is a function implemented in
+ * drivers/soc/litex/litex_soc_controller.c
+ * checking if the common LiteX CSR accessors
+ * are safe to be used by the drivers;
+ * returns true (1) if yes - false (0) if not
+ *
+ * Important: All drivers that use litex_set_reg/litex_get_reg
+ * functions should make sure that LiteX SoC Controller driver
+ * has verified LiteX CSRs read and write operations before
+ * issuing any read/writes to the LiteX peripherals.
+ *
+ * Exemplary snippet that can be used at the beginning
+ * of the driver's probe() function to ensure that LiteX
+ * SoC Controller driver is properely initialized:
+ *
+ * if (!litex_check_accessors())
+ * return -EPROBE_DEFER;
+ */
+int litex_check_accessors(void);
+
+void litex_set_reg(void __iomem *reg, unsigned long reg_sz, unsigned long val);
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_sz);
+
+
+#endif /* _LINUX_LITEX_H */
--
2.25.1
^ permalink raw reply related
* [PATCH v7 2/5] dt-bindings: soc: document LiteX SoC Controller bindings
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
Add documentation for LiteX SoC Controller bindings.
Signed-off-by: Pawel Czarnecki <pczarnecki@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
Changes in v6:
- fixed license header
Changes in v5:
- added reviewed-by tag
Changes in v4:
- changes compatible to "litex,soc-controller"
- fixed yaml's header
- removed unnecessary sections from yaml
- fixed indentation in yaml
This commit has been introduced in v3 of the patchset.
.../soc/litex/litex,soc-controller.yaml | 39 +++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
new file mode 100644
index 000000000000..53121c1fbe4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright 2020 Antmicro <www.antmicro.com>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: LiteX SoC Controller driver
+
+description: |
+ This is the SoC Controller driver for the LiteX SoC Builder.
+ It's purpose is to verify LiteX CSR (Control&Status Register) access
+ operations and provide function for other drivers to read/write CSRs
+ and to check if those accessors are ready to use.
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+properties:
+ compatible:
+ const: litex,soc-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ soc_ctrl0: soc-controller@f0000000 {
+ compatible = "litex,soc-controller";
+ reg = <0x0 0xf0000000 0x0 0xC>;
+ status = "okay";
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc1dc7e535e..e3f8804c08d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9918,6 +9918,12 @@ L: kunit-dev@googlegroups.com
S: Maintained
F: lib/list-test.c
+LITEX PLATFORM
+M: Karol Gugala <kgugala@antmicro.com>
+M: Mateusz Holenko <mholenko@antmicro.com>
+S: Maintained
+F: Documentation/devicetree/bindings/*/litex,*.yaml
+
LIVE PATCHING
M: Josh Poimboeuf <jpoimboe@redhat.com>
M: Jiri Kosina <jikos@kernel.org>
--
2.25.1
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: vendor: add vendor prefix for LiteX
From: Mateusz Holenko @ 2020-06-04 10:13 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
In-Reply-To: <20200604121142.2964437-0-mholenko@antmicro.com>
From: Filip Kokosinski <fkokosinski@antmicro.com>
Add vendor prefix for LiteX SoC builder.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Notes:
No changes in v7.
No changes in v6.
No changes in v5.
No changes in v4.
Changes in v3:
- added Acked-by tag
No changes in v2.
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 997934c58f9a..d2eaddc473ac 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -575,6 +575,8 @@ patternProperties:
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
+ "^litex,.*":
+ description: LiteX SoC builder
"^lltc,.*":
description: Linear Technology Corporation
"^logicpd,.*":
--
2.25.1
^ permalink raw reply related
* [PATCH v7 0/5] LiteX SoC controller and LiteUART serial driver
From: Mateusz Holenko @ 2020-06-04 10:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-serial
Cc: Stafford Horne, Karol Gugala, Mateusz Holenko,
Mauro Carvalho Chehab, David S. Miller, Paul E. McKenney,
Filip Kokosinski, Pawel Czarnecki, Joel Stanley, Jonathan Cameron,
Maxime Ripard, Shawn Guo, Heiko Stuebner, Sam Ravnborg,
Icenowy Zheng, Laurent Pinchart, linux-kernel, Gabriel L. Somlo
This patchset introduces support for LiteX SoC Controller
and LiteUART - serial device from LiteX SoC builder
(https://github.com/enjoy-digital/litex).
In the following patchset I will add
a new mor1kx-based (OpenRISC) platform that
uses this device.
Later I plan to extend this platform by
adding support for more devices from LiteX suite.
Changes in v7:
- added missing include directive in UART's driver
Changes in v6:
- changed accessors in SoC Controller's driver
- reworked UART driver
Changes in v5:
- added Reviewed-by tag
- removed custom accessors from SoC Controller's driver
- fixed error checking in SoC Controller's driver
Changes in v4:
- fixed copyright headers
- fixed SoC Controller's yaml
- simplified SoC Controller's driver
Changes in v3:
- added Acked-by and Reviewed-by tags
- introduced LiteX SoC Controller driver
- removed endianness detection (handled now by LiteX SoC Controller driver)
- modified litex.h header
- DTS aliases for LiteUART made optional
- renamed SERIAL_LITEUART_NR_PORTS to SERIAL_LITEUART_MAX_PORTS
- changed PORT_LITEUART from 122 to 123
Changes in v2:
- binding description rewritten to a yaml schema file
- added litex.h header with common register access functions
Filip Kokosinski (3):
dt-bindings: vendor: add vendor prefix for LiteX
dt-bindings: serial: document LiteUART bindings
drivers/tty/serial: add LiteUART driver
Pawel Czarnecki (2):
dt-bindings: soc: document LiteX SoC Controller bindings
drivers/soc/litex: add LiteX SoC Controller driver
.../bindings/serial/litex,liteuart.yaml | 38 ++
.../soc/litex/litex,soc-controller.yaml | 39 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 9 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 15 +
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 197 +++++++++
drivers/tty/serial/Kconfig | 31 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 405 ++++++++++++++++++
include/linux/litex.h | 45 ++
13 files changed, 787 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 drivers/tty/serial/liteuart.c
create mode 100644 include/linux/litex.h
--
2.25.1
^ permalink raw reply
* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Marc Zyngier @ 2020-06-04 10:11 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: <2e07d3d3-515b-57e1-0a36-8892bc38bb7b@socionext.com>
On 2020-06-04 10:43, Kunihiko Hayashi wrote:
[...]
>>> -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()) {
>>
>> This checks whether the kernel supports MSIs. Not that they are
>> enabled in your controller. Is that really what you want to do?
>
> The below two status bits are valid when the interrupt for MSI is
> asserted.
> That is, pci_msi_enabled() is wrong.
>
> I'll modify the function to check the two bits only if this function is
> called from MSI handler.
>
>>
>>> + 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);
>>> + }
>>
>> These two cases do the exact same thing, calling the same interrupt.
>> What is the point of dealing with them independently?
>
> Both PME and AER are asserted from MSI-0, and each handler checks its
> own
> status bit in the PCIe register (aer_irq() in pcie/aer.c and
> pcie_pme_irq()
> in pcie/pme.c).
> So I think this handler calls generic_handle_irq() for the same MSI-0.
So what is wrong with
if (val & (PCL_CFG_AER_RC_ERR_MSI_STATUS |
PCL_CFG_PME_MSI_STATUS)) {
// handle interrupt
}
?
If you have two handlers for the same interrupt, this is a shared
interrupt and each handler will be called in turn.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-04 9:43 UTC (permalink / raw)
To: Marc Zyngier
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: <78af3b11de9c513f9be2a1f42f273f27@kernel.org>
Hi Marc,
On 2020/06/03 20:22, Marc Zyngier wrote:
> On 2020-06-03 09:54, Kunihiko Hayashi 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.
>
> interrupts
Okay, I'll fix it.
>> 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.
>>
>> 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-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()) {
>
> This checks whether the kernel supports MSIs. Not that they are
> enabled in your controller. Is that really what you want to do?
The below two status bits are valid when the interrupt for MSI is asserted.
That is, pci_msi_enabled() is wrong.
I'll modify the function to check the two bits only if this function is
called from MSI handler.
>
>> + 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);
>> + }
>
> These two cases do the exact same thing, calling the same interrupt.
> What is the point of dealing with them independently?
Both PME and AER are asserted from MSI-0, and each handler checks its own
status bit in the PCIe register (aer_irq() in pcie/aer.c and pcie_pme_irq()
in pcie/pme.c).
So I think this handler calls generic_handle_irq() for the same MSI-0.
>
>> + }
>>
>> 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);
>
> This is a chained handler called outside of a chained_irq_enter/exit
> block. It isn't acceptable.
I got it.
This call should be called in the block.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH v7 2/4] usb: dwc3: qcom: Add interconnect support in dwc3 driver
From: Sandeep Maheswaram (Temp) @ 2020-06-04 9:43 UTC (permalink / raw)
To: Stephen Boyd, Andy Gross, Bjorn Andersson, Doug Anderson,
Felipe Balbi, Greg Kroah-Hartman, Mark Rutland, Matthias Kaehlcke,
Rob Herring
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Chandana Kishori Chiluveru
In-Reply-To: <159120577830.69627.13288547914742515702@swboyd.mtv.corp.google.com>
On 6/3/2020 11:06 PM, Stephen Boyd wrote:
> Quoting Sandeep Maheswaram (2020-03-31 22:15:43)
>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>> index 1dfd024..d33ae86 100644
>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>> @@ -76,8 +85,13 @@ struct dwc3_qcom {
>> enum usb_dr_mode mode;
>> bool is_suspended;
>> bool pm_suspended;
>> + struct icc_path *usb_ddr_icc_path;
>> + struct icc_path *apps_usb_icc_path;
>> };
>>
>> +static int dwc3_qcom_interconnect_enable(struct dwc3_qcom *qcom);
>> +static int dwc3_qcom_interconnect_disable(struct dwc3_qcom *qcom);
> Please get rid of these. We shouldn't need forward declarations.
Will do in next version.
>
>> +
>> static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
>> {
>> u32 reg;
>> @@ -285,6 +307,101 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
>> return 0;
>> }
>>
>> +
>> +/**
>> + * dwc3_qcom_interconnect_init() - Get interconnect path handles
>> + * @qcom: Pointer to the concerned usb core.
>> + *
>> + */
>> +static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
>> +{
>> + struct device *dev = qcom->dev;
>> + int ret;
>> +
>> + if (!device_is_bound(&qcom->dwc3->dev))
>> + return -EPROBE_DEFER;
> How is this supposed to work? I see that this was added in an earlier
> revision of this patch series but there isn't any mention of why
> device_is_bound() is used here. It would be great if there was a comment
> detailing why this is necessary. It sounds like maximum_speed is
> important?
>
> Furthermore, dwc3_qcom_interconnect_init() is called by
> dwc3_qcom_probe() which is the function that registers the device for
> qcom->dwc3->dev. If that device doesn't probe between the time it is
> registered by dwc3_qcom_probe() and this function is called then we'll
> fail dwc3_qcom_probe() with -EPROBE_DEFER. And that will remove the
> qcom->dwc3->dev device from the platform bus because we call
> of_platform_depopulate() on the error path of dwc3_qcom_probe().
>
> So isn't this whole thing racy and can potentially lead us to a driver
> probe loop where the wrapper (dwc3_qcom) and the core (dwc3) are probing
> and we're trying to time it just right so that driver for dwc3 binds
> before we setup interconnects? I don't know if dwc3 can communicate to
> the wrapper but that would be more of a direct way to do this. Or maybe
> the wrapper should try to read the DT property for maximum speed and
> fallback to a worst case high bandwidth value if it can't figure it out
> itself without help from dwc3 core.
>
This was added in V4 to address comments from Matthias in V3
https://patchwork.kernel.org/patch/11148587/
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v3 1/6] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-06-04 9:43 UTC (permalink / raw)
To: Marc Zyngier
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: <95bb3ffbfab4923854e20266c6b0b098@kernel.org>
Hi Marc,
On 2020/06/03 20:15, Marc Zyngier wrote:
> 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?
I assume that the msi_host_isr() contains chained interrupts in
the second patch and no need to treat as the standard handler,
so this should be called in the guards.
I'll move this call to the top of dw_chained_msi_isr().
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
From: Sakari Ailus @ 2020-06-04 9:26 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, tfiga, matthias.bgg, bingbu.cao,
srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang
In-Reply-To: <1591236845.8804.547.camel@mhfsdcap03>
Hi Dongchun,
On Thu, Jun 04, 2020 at 10:14:05AM +0800, Dongchun Zhu wrote:
> Hi Tomasz, Sakari, and sirs,
>
> Could anyone help to review this patch?
>
> On Sat, 2020-05-23 at 16:41 +0800, Dongchun Zhu wrote:
> > Add a V4L2 sub-device driver for OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/media/i2c/Kconfig | 13 +
> > drivers/media/i2c/Makefile | 1 +
> > drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 1040 insertions(+)
> > create mode 100644 drivers/media/i2c/ov02a10.c
> >
>
> [snip]
>
> > +static int ov02a10_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct ov02a10 *ov02a10;
> > + unsigned int rotation;
> > + unsigned int clock_lane_tx_speed;
> > + unsigned int i;
> > + int ret;
> > +
> > + ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
> > + if (!ov02a10)
> > + return -ENOMEM;
> > +
> > + ret = ov02a10_check_hwcfg(dev, ov02a10);
> > + if (ret) {
> > + dev_err(dev, "failed to check HW configuration: %d", ret);
> > + return ret;
> > + }
> > +
> > + v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
> > + ov02a10->mipi_clock_tx_speed = OV02A10_MIPI_TX_SPEED_DEFAULT;
> > + ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
> > +
> > + /* Optional indication of physical rotation of sensor */
> > + ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
> > + if (!ret && rotation == 180) {
> > + ov02a10->upside_down = true;
> > + ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
> > + }
> > +
> > + /* Optional indication of mipi TX speed */
> > + ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
> > + &clock_lane_tx_speed);
> > +
> > + if (!ret)
> > + ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
> > +
> > + /* Get system clock (eclk) */
> > + ov02a10->eclk = devm_clk_get(dev, "eclk");
> > + if (IS_ERR(ov02a10->eclk)) {
> > + ret = PTR_ERR(ov02a10->eclk);
> > + dev_err(dev, "failed to get eclk %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
> > + &ov02a10->eclk_freq);
> > + if (ret) {
> > + dev_err(dev, "failed to get eclk frequency\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
> > + if (ret) {
> > + dev_err(dev, "failed to set eclk frequency (24MHz)\n");
> > + return ret;
> > + }
> > +
> > + if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
> > + dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
> > + ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
> > + return -EINVAL;
> > + }
> > +
> > + ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
> > + if (IS_ERR(ov02a10->pd_gpio)) {
> > + ret = PTR_ERR(ov02a10->pd_gpio);
> > + dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > + if (IS_ERR(ov02a10->n_rst_gpio)) {
> > + ret = PTR_ERR(ov02a10->n_rst_gpio);
> > + dev_err(dev, "failed to get reset-gpios %d\n", ret);
> > + return ret;
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(ov02a10_supply_names); i++)
> > + ov02a10->supplies[i].supply = ov02a10_supply_names[i];
> > +
> > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ov02a10_supply_names),
> > + ov02a10->supplies);
> > + if (ret) {
> > + dev_err(dev, "failed to get regulators\n");
> > + return ret;
> > + }
> > +
> > + mutex_init(&ov02a10->mutex);
> > + ov02a10->cur_mode = &supported_modes[0];
> > + ret = ov02a10_initialize_controls(ov02a10);
> > + if (ret) {
> > + dev_err(dev, "failed to initialize controls\n");
> > + goto err_destroy_mutex;
> > + }
> > +
> > + ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > + ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
> > + ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> > + ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
> > + ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to init entity pads: %d", ret);
> > + goto err_free_handler;
> > + }
> > +
> > + pm_runtime_enable(dev);
> > + if (!pm_runtime_enabled(dev)) {
> > + ret = ov02a10_power_on(dev);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to power on: %d\n", ret);
> > + goto err_free_handler;
> > + }
> > + }
> > +
> > + ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > + if (ret) {
> > + dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > + if (!pm_runtime_enabled(dev))
> > + ov02a10_power_off(dev);
This should be moved to error handling section below.
> > + goto err_clean_entity;
> > + }
>
> Tomasz, Sakari, is this ok?
> or coding like this:
>
> ret = v4l2_async_register_subdev(&ov02a10->subdev);
> if (!pm_runtime_enabled(dev))
> ov02a10_power_off(dev);
> if (ret) {
> dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> goto err_clean_entity;
> }
>
> What's your opinions about the change?
This turns power off if runtime PM is disabled. I'd keep it as-is, as it'd
require re-implementing what runtime PM is used for now --- and that's not
a sensor driver's job.
>
> > +
> > + return 0;
> > +
> > +err_clean_entity:
> > + media_entity_cleanup(&ov02a10->subdev.entity);
> > +err_free_handler:
> > + v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> > +err_destroy_mutex:
> > + mutex_destroy(&ov02a10->mutex);
> > +
> > + return ret;
> > +}
> > +
> > +static int ov02a10_remove(struct i2c_client *client)
> > +{
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > +
> > + v4l2_async_unregister_subdev(sd);
> > + media_entity_cleanup(&sd->entity);
> > + v4l2_ctrl_handler_free(sd->ctrl_handler);
> > + pm_runtime_disable(&client->dev);
> > + if (!pm_runtime_status_suspended(&client->dev))
> > + ov02a10_power_off(&client->dev);
> > + pm_runtime_set_suspended(&client->dev);
> > + mutex_destroy(&ov02a10->mutex);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ov02a10_of_match[] = {
> > + { .compatible = "ovti,ov02a10" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, ov02a10_of_match);
> > +
> > +static struct i2c_driver ov02a10_i2c_driver = {
> > + .driver = {
> > + .name = "ov02a10",
> > + .pm = &ov02a10_pm_ops,
> > + .of_match_table = ov02a10_of_match,
> > + },
> > + .probe_new = &ov02a10_probe,
> > + .remove = &ov02a10_remove,
> > +};
> > +
> > +module_i2c_driver(ov02a10_i2c_driver);
> > +
> > +MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
> > +MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
> > +MODULE_LICENSE("GPL v2");
> > +
>
--
Sakari Ailus
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-04 9:20 UTC (permalink / raw)
To: Jassi Brar
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <CABb+yY0cW1GZHVmwEr19JRdJTmsAxw9uq83QV_aq-tdPJO5_Fg@mail.gmail.com>
On Wed, Jun 03, 2020 at 01:32:42PM -0500, Jassi Brar wrote:
> On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > > On 28-05-20, 13:20, Rob Herring wrote:
> > > > Whether Linux
> > > > requires serializing mailbox accesses is a separate issue. On that side,
> > > > it seems silly to not allow driving the h/w in the most efficient way
> > > > possible.
> > >
> > > That's exactly what we are trying to say. The hardware allows us to
> > > write all 32 bits in parallel, without any hardware issues, why
> > > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > > facing issues with hardware access because of lockdown right now)
> >
> > OK, I was able to access the setup today. I couldn't reach a point
> > where I can do measurements as the system just became unusable with
> > one physical channel instead of 2 virtual channels as in my patches.
> >
> > My test was simple. Switch to schedutil and read sensors periodically
> > via sysfs.
> >
> > arm-scmi firmware:scmi: message for 1 is not expected!
> >
> This sounds like you are not serialising requests on a shared channel.
> Can you please also share the patch?
OK, I did try with a small patch initially and then realised we must hit
issue with mainline as is. Tried and the behaviour is exact same. All
I did is removed my patches and use bit[0] as the signal. It doesn't
matter as writes to the register are now serialised. Oh, the above
message comes when OS times out in advance while firmware continues to
process the old request and respond.
The trace I sent gives much better view of what's going on.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/7] arm64: dts: qcom: pm8009: Add base dts file
From: Vinod Koul @ 2020-06-04 9:10 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-1-dmitry.baryshkov@linaro.org>
On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> Add base DTS file for pm8009 along with GPIOs and power-on nodes.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/pm8009.dtsi | 40 ++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/pm8009.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8009.dtsi b/arch/arm64/boot/dts/qcom/pm8009.dtsi
> new file mode 100644
> index 000000000000..9f3e19b5bd00
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/pm8009.dtsi
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2019, Linaro Limited
We are in 2020 :)
> + */
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
DO you need these headers for base patch, we should add them when adding
uses of this file
> +#include <dt-bindings/spmi/spmi.h>
> +#include <dt-bindings/iio/qcom,spmi-vadc.h>
This one too
> +
> +&spmi_bus {
> + pmic@a {
> + compatible = "qcom,pm8009", "qcom,spmi-pmic";
> + reg = <0xa SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + power-on@800 {
> + compatible = "qcom,pm8916-pon";
> + reg = <0x0800>;
> + };
> +
> + pm8009_gpios: gpio@c000 {
> + compatible = "qcom,pm8005-gpio";
> + reg = <0xc000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> + pmic@b {
> + compatible = "qcom,pm8009", "qcom,spmi-pmic";
> + reg = <0xb SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +};
> --
> 2.26.2
--
~Vinod
^ permalink raw reply
* [PATCH RESEND v9 02/18] media: platform: Improve queue set up flow for bug fixing
From: Xia Jiang @ 2020-06-04 9:05 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Marek Szyprowski, Tomasz Figa, srv_heupstream,
senozhatsky, mojahsu, drinkcat, maoguang.meng, sj.huang,
Xia Jiang
In-Reply-To: <20200604090553.10861-1-xia.jiang@mediatek.com>
Add checking created buffer size follow in mtk_jpeg_queue_setup().
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 4ad4a4b30a0e..67a022d04df7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -571,6 +571,13 @@ static int mtk_jpeg_queue_setup(struct vb2_queue *q,
if (!q_data)
return -EINVAL;
+ if (*num_planes) {
+ for (i = 0; i < *num_planes; i++)
+ if (sizes[i] < q_data->sizeimage[i])
+ return -EINVAL;
+ return 0;
+ }
+
*num_planes = q_data->fmt->colplanes;
for (i = 0; i < q_data->fmt->colplanes; i++) {
sizes[i] = q_data->sizeimage[i];
--
2.18.0
^ permalink raw reply related
* [PATCH RESEND v9 03/18] media: platform: Improve getting and requesting irq flow for bug fixing
From: Xia Jiang @ 2020-06-04 9:05 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Marek Szyprowski, Tomasz Figa, srv_heupstream,
senozhatsky, mojahsu, drinkcat, maoguang.meng, sj.huang,
Xia Jiang
In-Reply-To: <20200604090553.10861-1-xia.jiang@mediatek.com>
Delete platform_get_resource operation for irq.
Return actual value rather than EINVAL when fail to get and request
irq.
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 67a022d04df7..2677580941b0 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1103,12 +1103,10 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
return ret;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
dec_irq = platform_get_irq(pdev, 0);
- if (!res || dec_irq < 0) {
+ if (dec_irq < 0) {
dev_err(&pdev->dev, "Failed to get dec_irq %d.\n", dec_irq);
- ret = -EINVAL;
- return ret;
+ return dec_irq;
}
ret = devm_request_irq(&pdev->dev, dec_irq, mtk_jpeg_dec_irq, 0,
@@ -1116,7 +1114,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Failed to request dec_irq %d (%d)\n",
dec_irq, ret);
- ret = -EINVAL;
goto err_req_irq;
}
--
2.18.0
^ 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