* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Felipe Balbi @ 2016-11-17 11:27 UTC (permalink / raw)
To: John Youn; +Cc: Christian Lamparter, Stefan Wahren
In-Reply-To: <7fa1c1c4d703c435d698cdf140c9d43163347f1d.1479339900.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
Hi,
John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> Add the "snps,ahb-burst" binding and read it in.
>
> This property controls which burst type to perform on the AHB bus as a
> master in internal DMA mode. This overrides the legacy param value,
> which we need to keep around for now since several platforms use it.
>
> Some platforms may see better or worse performance based on this
> value. The HAPS platform is one example where all INCRx have worse
> performance than INCR.
>
> Other platforms (such as the Canyonlands board) report that the default
> value causes system hangs.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
it's getting rather late for this merge window. I still need an ack by
Rob or any of the devicetree folks.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH v5] PCI: qcom: add support to msm8996 PCIe controller
From: Srinivas Kandagatla @ 2016-11-17 11:12 UTC (permalink / raw)
To: svarbanov-NEYub+7Iv8PQT0dZR+AlfA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
This patch adds support to msm8996/apq8096 PCIe, MSM8996 supports
Gen 1/2, One lane, 3 PCIe root-complex with support to MSI and
legacy interrupts and it conforms to PCI Express Base 2.1 specification.
This patch adds post_init callback to qcom_pcie_ops, as this is PCIe
pipe clocks are only setup after the phy is powered on.
It also adds ltssm_enable callback as it is very much different to other
supported SOCs in the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Stanimir Varbanov <svarbanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
---
Changes since v5:
- No code changes.
- s/pcie/PCIe in change log based on Rob's comments.
.../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
drivers/pci/host/pcie-qcom.c | 175 ++++++++++++++++++++-
2 files changed, 236 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 4059a6f..141d8c3 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -7,6 +7,7 @@
- "qcom,pcie-ipq8064" for ipq8064
- "qcom,pcie-apq8064" for apq8064
- "qcom,pcie-apq8084" for apq8084
+ - "qcom,pcie-msm8996" for msm8996 or apq8096
- reg:
Usage: required
@@ -92,6 +93,17 @@
- "aux" Auxiliary (AUX) clock
- "bus_master" Master AXI clock
- "bus_slave" Slave AXI clock
+
+- clock-names:
+ Usage: required for msm8996/apq8096
+ Value type: <stringlist>
+ Definition: Should contain the following entries
+ - "pipe" Pipe Clock driving internal logic.
+ - "aux" Auxiliary (AUX) clock.
+ - "cfg" Configuration clk.
+ - "bus_master" Master AXI clock.
+ - "bus_slave" Slave AXI clock.
+
- resets:
Usage: required
Value type: <prop-encoded-array>
@@ -115,7 +127,7 @@
- "core" Core reset
- power-domains:
- Usage: required for apq8084
+ Usage: required for apq8084 and msm8996/apq8096
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pair to the
power domain which is responsible for collapsing
@@ -231,3 +243,56 @@
pinctrl-0 = <&pcie0_pins_default>;
pinctrl-names = "default";
};
+
+* Example for apq8096:
+
+ pcie@608000{
+ compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
+ power-domains = <&gcc PCIE1_GDSC>;
+ bus-range = <0x00 0xff>;
+ num-lanes = <1>;
+
+ reg = <0x00608000 0x2000>,
+ <0x0d000000 0xf1d>,
+ <0x0d000f20 0xa8>,
+ <0x0d100000 0x100000>;
+
+ reg-names = "parf", "dbi", "elbi", "config";
+
+ phys = <&pcie_phy 1>;
+ phy-names = "pciephy";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
+ <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
+
+ interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
+ pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
+
+ vdda-1p8-supply = <&pm8994_l12>;
+ vdda-supply = <&pm8994_l28>;
+ linux,pci-domain = <1>;
+
+ clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
+ <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
+
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave";
+ };
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index 3593640..25c5556 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -36,11 +36,17 @@
#include "pcie-designware.h"
+#define PCIE20_PARF_SYS_CTRL 0x00
#define PCIE20_PARF_PHY_CTRL 0x40
#define PCIE20_PARF_PHY_REFCLK 0x4C
#define PCIE20_PARF_DBI_BASE_ADDR 0x168
#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c
+#define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178
+#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1A8
+#define PCIE20_PARF_LTSSM 0x1B0
+#define PCIE20_PARF_SID_OFFSET 0x234
+#define PCIE20_PARF_BDF_TRANSLATE_CFG 0x24C
#define PCIE20_ELBI_SYS_CTRL 0x04
#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
@@ -72,9 +78,18 @@ struct qcom_pcie_resources_v1 {
struct regulator *vdda;
};
+struct qcom_pcie_resources_v2 {
+ struct clk *aux_clk;
+ struct clk *master_clk;
+ struct clk *slave_clk;
+ struct clk *cfg_clk;
+ struct clk *pipe_clk;
+};
+
union qcom_pcie_resources {
struct qcom_pcie_resources_v0 v0;
struct qcom_pcie_resources_v1 v1;
+ struct qcom_pcie_resources_v2 v2;
};
struct qcom_pcie;
@@ -82,7 +97,9 @@ struct qcom_pcie;
struct qcom_pcie_ops {
int (*get_resources)(struct qcom_pcie *pcie);
int (*init)(struct qcom_pcie *pcie);
+ int (*post_init)(struct qcom_pcie *pcie);
void (*deinit)(struct qcom_pcie *pcie);
+ void (*ltssm_enable)(struct qcom_pcie *pcie);
};
struct qcom_pcie {
@@ -116,17 +133,33 @@ static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg)
return dw_handle_msi_irq(pp);
}
-static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+static void qcom_pcie_v0_v1_ltssm_enable(struct qcom_pcie *pcie)
{
u32 val;
-
- if (dw_pcie_link_up(&pcie->pp))
- return 0;
-
/* enable link training */
val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
+}
+
+static void qcom_pcie_v2_ltssm_enable(struct qcom_pcie *pcie)
+{
+ u32 val;
+ /* enable link training */
+ val = readl(pcie->parf + PCIE20_PARF_LTSSM);
+ val |= BIT(8);
+ writel(val, pcie->parf + PCIE20_PARF_LTSSM);
+}
+
+static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+{
+
+ if (dw_pcie_link_up(&pcie->pp))
+ return 0;
+
+ /* Enable Link Training state machine */
+ if (pcie->ops->ltssm_enable)
+ pcie->ops->ltssm_enable(pcie);
return dw_pcie_wait_for_link(&pcie->pp);
}
@@ -421,6 +454,113 @@ static int qcom_pcie_init_v1(struct qcom_pcie *pcie)
return ret;
}
+static int qcom_pcie_get_resources_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+
+ res->aux_clk = devm_clk_get(dev, "aux");
+ if (IS_ERR(res->aux_clk))
+ return PTR_ERR(res->aux_clk);
+
+ res->cfg_clk = devm_clk_get(dev, "cfg");
+ if (IS_ERR(res->cfg_clk))
+ return PTR_ERR(res->cfg_clk);
+
+ res->master_clk = devm_clk_get(dev, "bus_master");
+ if (IS_ERR(res->master_clk))
+ return PTR_ERR(res->master_clk);
+
+ res->slave_clk = devm_clk_get(dev, "bus_slave");
+ if (IS_ERR(res->slave_clk))
+ return PTR_ERR(res->slave_clk);
+
+ res->pipe_clk = devm_clk_get(dev, "pipe");
+ if (IS_ERR(res->pipe_clk))
+ return PTR_ERR(res->pipe_clk);
+
+ return 0;
+}
+
+static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(res->aux_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable aux clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(res->cfg_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable cfg clock\n");
+ goto err_cfg_clk;
+ }
+
+ ret = clk_prepare_enable(res->master_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable master clock\n");
+ goto err_master_clk;
+ }
+
+ ret = clk_prepare_enable(res->slave_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable slave clock\n");
+ goto err_slave_clk;
+ }
+
+ /* enable PCIe clocks and resets */
+ val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
+ val &= ~BIT(0);
+ writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
+
+ /* change DBI base address */
+ writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
+
+ /* MAC PHY_POWERDOWN MUX DISABLE */
+ val = readl(pcie->parf + PCIE20_PARF_SYS_CTRL);
+ val &= ~BIT(29);
+ writel(val, pcie->parf + PCIE20_PARF_SYS_CTRL);
+
+ val = readl(pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+ val |= BIT(4);
+ writel(val, pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+
+ val = readl(pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2);
+ val |= BIT(31);
+ writel(val, pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2);
+
+ return 0;
+
+err_slave_clk:
+ clk_disable_unprepare(res->master_clk);
+err_master_clk:
+ clk_disable_unprepare(res->cfg_clk);
+err_cfg_clk:
+ clk_disable_unprepare(res->aux_clk);
+
+ return ret;
+}
+
+static int qcom_pcie_post_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ int ret;
+
+ ret = clk_prepare_enable(res->pipe_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable pipe clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static int qcom_pcie_link_up(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -429,6 +569,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
return !!(val & PCI_EXP_LNKSTA_DLLLA);
}
+static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+
+ clk_disable_unprepare(res->pipe_clk);
+ clk_disable_unprepare(res->slave_clk);
+ clk_disable_unprepare(res->master_clk);
+ clk_disable_unprepare(res->cfg_clk);
+ clk_disable_unprepare(res->aux_clk);
+}
+
static void qcom_pcie_host_init(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -444,6 +595,9 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
if (ret)
goto err_deinit;
+ if (pcie->ops->post_init)
+ pcie->ops->post_init(pcie);
+
dw_pcie_setup_rc(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
@@ -487,12 +641,22 @@ static const struct qcom_pcie_ops ops_v0 = {
.get_resources = qcom_pcie_get_resources_v0,
.init = qcom_pcie_init_v0,
.deinit = qcom_pcie_deinit_v0,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
};
static const struct qcom_pcie_ops ops_v1 = {
.get_resources = qcom_pcie_get_resources_v1,
.init = qcom_pcie_init_v1,
.deinit = qcom_pcie_deinit_v1,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
+};
+
+static const struct qcom_pcie_ops ops_v2 = {
+ .get_resources = qcom_pcie_get_resources_v2,
+ .init = qcom_pcie_init_v2,
+ .post_init = qcom_pcie_post_init_v2,
+ .deinit = qcom_pcie_deinit_v2,
+ .ltssm_enable = qcom_pcie_v2_ltssm_enable,
};
static int qcom_pcie_probe(struct platform_device *pdev)
@@ -572,6 +736,7 @@ static const struct of_device_id qcom_pcie_match[] = {
{ .compatible = "qcom,pcie-ipq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8084", .data = &ops_v1 },
+ { .compatible = "qcom,pcie-msm8996", .data = &ops_v2 },
{ }
};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/2] DT: i2c: W83793 is a trivial device
From: Florian Larysch @ 2016-11-17 10:23 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree, linuxppc-dev, Florian Larysch
In-Reply-To: <20161117102324.18319-1-fl@n621.de>
Signed-off-by: Florian Larysch <fl@n621.de>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index fbbad64..c65aff0 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -158,4 +158,5 @@ ti,tsc2003 I2C Touch-Screen Controller
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
ti,tmp275 Digital Temperature Sensor
+winbond,w83793 Winbond/Nuvoton H/W Monitor
winbond,wpct301 i2c trusted platform module (TPM)
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/dts: add device tree entry for W83793 on T4240RDB
From: Florian Larysch @ 2016-11-17 10:23 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree, linuxppc-dev, Florian Larysch
In-Reply-To: <20161117102324.18319-1-fl@n621.de>
The T4240RDB contains a W83793 hardware monitoring chip. Add a device
tree entry to make the driver attach to it, as the i2c-mpc bus driver
dropped support for class-based instantiation of devices a long time
ago.
Signed-off-by: Florian Larysch <fl@n621.de>
---
arch/powerpc/boot/dts/fsl/t4240rdb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
index cc0a264..8166c66 100644
--- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
@@ -125,6 +125,10 @@
};
i2c@118000 {
+ hwmon@2f {
+ compatible = "winbond,w83793";
+ reg = <0x2f>;
+ };
eeprom@52 {
compatible = "at24,24c256";
reg = <0x52>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/2] T4240RBD: add device tree entry for W83793
From: Florian Larysch @ 2016-11-17 10:23 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree, linuxppc-dev, Florian Larysch
v2:
- Ordered DT nodes by address
- Added an entry for the chip to the trivial-devices list
Florian Larysch (2):
powerpc/dts: add device tree entry for W83793 on T4240RDB
DT: i2c: W83793 is a trivial device
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
arch/powerpc/boot/dts/fsl/t4240rdb.dts | 4 ++++
2 files changed, 5 insertions(+)
--
2.10.2
^ permalink raw reply
* Re: [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Jeffery, Arnd Bergmann, Lee Jones, Benjamin Herrenschmidt,
Rob Herring, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CACRpkdazPEbU2gmDyke=GTYtjVp8aeauS+PVkp-zuiVoVz7kbw@mail.gmail.com>
Hey Linus,
On Thu, Nov 17, 2016 at 8:00 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>> +* Device tree bindings for the Aspeed LPC Controller
>
> We are going overboard with the lingo sometimes, to the point that we do not
> understand how terse things become.
>
> LPC = Low Pin Count, right?
> Explain that right here: it is a slow external bus, right?
Yep. 33MHz bus that generally connects a host CPU to other devices on
the same motherboard, such as management controllers.
https://en.wikipedia.org/wiki/Low_Pin_Count
Systems with Aspeed BMCs use the LPC to load the firmware from the BMC
into the host at boot, and send IPMI messages between the host and the
BMC.
BMC stands for Baseboard Management Controller. Back in the day it was
simple keyboard controller microcontroller, these days we use a 800MHz
ARM11 with half a gigabyte of RAM. It provides access to the boot
firmware for the host CPU, monitors the health of the system (fans,
temperature, error logging), and provides remote access for power
cycling and installation.
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller
Andrew and I work on an open source project that is creating a new BMC
software stack called OpenBMC. You've been merging the wonderful
Aspeed pinmux patches that Andrew wrote recently, which was a major
bit of kernel work required for that project.
>> +The Aspeed LPC controller contains registers for a variety of functions. Not
>> +all registers for a function are contiguous, and some registers are referenced
>> +by functions outside the LPC controller.
>> +
>> +Note that this is separate from the H8S/2168 compatible register set occupying
>> +the start of the LPC controller address space.
>> +
>> +Some significant functions in the LPC controller:
>> +
>> +* LPC Host Controller
>> +* Host Interface Controller
>
> Host interface to what?
Host in this case is the CPU on the motherboard to do the heavy
lifting. x86, ARM64, PowerPC. So this is the BMC's interface to the
host.
>
>> +* iBT Controller
>
> What is iBT?
IPMI Byte Transfer? Something like that. It's the transport that the
host uses to send IPMI messages to the BMC and back.
The host side has been upstream for a while. The BMC side has a driver
staged for v4.10:
https://patchwork.ozlabs.org/patch/674973/
If you're really bored you can read up on IPMI from the specificaiton:
http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
tl;dr is it's a protocol for communication to the BMC. There is
in-band IPMI, which is between the host and the BMC over the eg. the
BT interface. Or out of band IPMI, which is where you use ipmitool
from your laptop to talk to the BMC over the network.
>
>> +* SuperIO Scratch registers
>
> Again more context please.
The SuperIO name is legacy x86 terminology. These are a few bytes
worth of data that can be set from one side and read by the other in
order to convey firmware-specific information. In OpenPower systems,
we use them to tell the host where to send it's console output when it
is booting.
> With standards documents, either explain everything or provide
> pointers for the information.
If only we could give you the pleasure of reading the Aspeed reference
manual. It's only available from Aspeed under NDA at this point in
time though. If you want further details on anything else then Andrew,
Ben or myself can explain.
Cheers,
Joel
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-17 10:20 UTC (permalink / raw)
To: Anand Moon
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree, Florian Fainelli,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, Linux Kernel, Andre Roth,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <CANAwSgTjG8G0U+A1p7hOKND9rjY4BzZfPgyWWHAEryYkHj_UOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2016-11-16 at 22:36 +0530, Anand Moon wrote:
> Hi Jerome.
>
> On 15 November 2016 at 19:59, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> wrote:
> >
> > On some platforms, energy efficient ethernet with rtl8211 devices
> > is
> > causing issue, like throughput drop or broken link.
> >
> > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > issue root
> > cause is not fully understood yet, disabling EEE advertisement
> > prevent auto
> > negotiation from enabling EEE.
> >
> > This patch provides options to disable 1000T and 100TX EEE
> > advertisement
> > individually for the realtek phys supporting this feature.
> >
> > Reported-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23myhRSP0FMvGiw@public.gmane.org
> > m>
> > Cc: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
> > Cc: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> > Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > Tested-by: Andre Roth <neolynx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > drivers/net/phy/realtek.c | 65
> > ++++++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index aadd6e9f54ad..77235fd5faaf 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -15,6 +15,12 @@
> > */
> > #include <linux/phy.h>
> > #include <linux/module.h>
> > +#include <linux/of.h>
> > +
> > +struct rtl8211x_phy_priv {
> > + bool eee_1000t_disable;
> > + bool eee_100tx_disable;
> > +};
> >
> > #define RTL821x_PHYSR 0x11
> > #define RTL821x_PHYSR_DUPLEX 0x2000
> > @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct
> > phy_device *phydev)
> > return err;
> > }
> >
> > +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
> > +{
> > + struct rtl8211x_phy_priv *priv = phydev->priv;
> > + u16 val;
> > +
> > + if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
> > + val = phy_read_mmd_indirect(phydev,
> > MDIO_AN_EEE_ADV,
> > + MDIO_MMD_AN);
> > +
> > + if (priv->eee_1000t_disable)
> > + val &= ~MDIO_AN_EEE_ADV_1000T;
> > + if (priv->eee_100tx_disable)
> > + val &= ~MDIO_AN_EEE_ADV_100TX;
> > +
> > + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> > + MDIO_MMD_AN, val);
> > + }
> > +}
> > +
> > +static int rtl8211x_config_init(struct phy_device *phydev)
> > +{
> > + int ret;
> > +
> > + ret = genphy_config_init(phydev);
> > + if (ret < 0)
> > + return ret;
> > +
> > + rtl8211x_clear_eee_adv(phydev);
> > +
> > + return 0;
> > +}
> > +
> > static int rtl8211f_config_init(struct phy_device *phydev)
> > {
> > int ret;
> > u16 reg;
> >
> > - ret = genphy_config_init(phydev);
> > + ret = rtl8211x_config_init(phydev);
> > if (ret < 0)
> > return ret;
> >
> > @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct
> > phy_device *phydev)
> > return 0;
> > }
> >
> > +static int rtl8211x_phy_probe(struct phy_device *phydev)
> > +{
> > + struct device *dev = &phydev->mdio.dev;
> > + struct device_node *of_node = dev->of_node;
> > + struct rtl8211x_phy_priv *priv;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->eee_1000t_disable =
> > + of_property_read_bool(of_node, "realtek,disable-
> > eee-1000t");
> > + priv->eee_100tx_disable =
> > + of_property_read_bool(of_node, "realtek,disable-
> > eee-100tx");
> > +
> > + phydev->priv = priv;
> > +
> > + return 0;
> > +}
> > +
> > static struct phy_driver realtek_drvs[] = {
> > {
> > .phy_id = 0x00008201,
> > @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
> > .phy_id_mask = 0x001fffff,
> > .features = PHY_GBIT_FEATURES,
> > .flags = PHY_HAS_INTERRUPT,
> > + .probe = &rtl8211x_phy_probe,
> > .config_aneg = genphy_config_aneg,
> > + .config_init = &rtl8211x_config_init,
> > .read_status = genphy_read_status,
> > .ack_interrupt = rtl821x_ack_interrupt,
> > .config_intr = rtl8211e_config_intr,
> > @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
> > .phy_id_mask = 0x001fffff,
> > .features = PHY_GBIT_FEATURES,
> > .flags = PHY_HAS_INTERRUPT,
> > + .probe = &rtl8211x_phy_probe,
> > .config_aneg = &genphy_config_aneg,
> > + .config_init = &rtl8211x_config_init,
> > .read_status = &genphy_read_status,
> > .ack_interrupt = &rtl821x_ack_interrupt,
> > .config_intr = &rtl8211e_config_intr,
> > @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
> > .phy_id_mask = 0x001fffff,
> > .features = PHY_GBIT_FEATURES,
> > .flags = PHY_HAS_INTERRUPT,
> > + .probe = &rtl8211x_phy_probe,
> > .config_aneg = &genphy_config_aneg,
> > .config_init = &rtl8211f_config_init,
> > .read_status = &genphy_read_status,
> > --
> > 2.7.4
> >
>
> How about adding callback functionality for .soft_reset to handle
> BMCR
> where we update the Auto-Negotiation for the phy,
> as per the datasheet of the rtl8211f.
I'm not sure I understand how this would help with our issue (and EEE).
Am I missing something or is it something unrelated that you would like
to see happening on this driver ?
>
> -Best Regard
> Anand Moon
>
> >
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Jeffery, Lee Jones, Linus Walleij, Benjamin Herrenschmidt,
Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4751029.AudB7s5avo@wuerfel>
On Thu, Nov 17, 2016 at 7:46 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
>> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
>> ---
>>
>> I'd like to start a discussion about how to handle the LPC register space in
>> the Aspeed SoC. There are a number of issues, largely concerned with the layout
>> of the registers but also with the fact that LPC register state is used by the
>> pinmux to determine some pin functionality.
> ...
>>
>> What is the recommended approach to managing such hardware?
>
> Can you clarify which side of the LPC bus this is? We are currently having
> a discussion for how to integrate the LPC master on an ARM64 server that
> uses LPC to access an Aspeed LPC slave. For this one we want to use the
> traditional ISA DT binding.
This is from the perspective of the BMC.
On the machines we are talking to, most (all?) access is performed
through the system firmware (skiboot).
> I'm guessing that you are interesting in the other side here, for mapping
> the registers of the LPC slave on the Aspeed BMC, but that's not clear from
> your email, as I'm assuming that the same chip has both master and slave
> interfaces.
Yep, we come from the "other side".
The BMC itself can operate the bus in Master or Slave mode. We are
interested in the slave case, for when the host is requesting access
to its system firmware at boot time. This happens by mapping a region
of the BMC's AHB memory space into the LPC address space. After we
deal with pinmux, Andrew or I will be hacking on a driver to configure
that space, as the BMC needs to configure the window before the host
can boot. It's a pile of bits spread out over different parts of the
chip, and doesn't map nicely into any existing driver model we have in
the kernel.
Other functions include IPMI communication between the BMC and the
host via the LPC bus via the iBT interface. We have a driver for that
staged for 4.10. Then there's a mailbox, some "scratch" registers that
can be used by the firmware for whatever they see fit, and all kinds
of crazy legacy x86 stuff like POST code registers.
Cheers,
Joel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Vinod Koul @ 2016-11-17 9:52 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel, ohad,
patrice.chotard, lee.jones, dmaengine, devicetree,
linux-remoteproc
In-Reply-To: <20161117063646.GE28340@tuxbot>
On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
>
> > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > >
> > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > without providing Linus with a messy merge conflict.
> > > >
> > > > So the remoteproc parts now has to go through my tree.
> > >
> > > OK, I think the best approach is for Vinod to create an immutable
> > > branch with the entire fdma series on, and then both of you merge that branch into
> > > your respective trees.
> >
> > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > tag, please do let me know
> >
>
> Hi Vinod,
>
> It looks like you reverted the wrong Kconfig fix, the one I objected to
> was the change in drivers/remoteproc, not the one in drivers/dma.
>
> The ST_FMDA depends on functions exposed by REMOTEPROC and
> ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> guys made user selectable - and as such should not be selected - but I
> think we should move forward and get everything merged and then we can
> go back and figure out how this should be addressed (or left alone?).
>
> I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> now broken drivers/remoteproc/Kconfig.
>
> We do however both need to revert the revert or there will be link
> errors if you build the dma driver with remoteproc=n. If you do this I
> can merge the topic once more and we'll keep the set of changes in sync.
Oops my bad, thanks for letting me know. I have reverted this now and
pushing out. Please do let me know if this was fine
Thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Martin Sperl @ 2016-11-17 9:51 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Zhang Rui, Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Lee Jones, Eric Anholt, Russell King, Florian Fainelli,
Catalin Marinas, Will Deacon, linux-pm, devicetree,
linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <20161117021107.GA2647@localhost.localdomain>
On 17.11.2016 03:11, Eduardo Valentin wrote:
> Hey Martin,
>
> Very sorry for the late feedback. Not so sure if this one got queued
> already or not. Anyways, just minor questions as follows:
>
> On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel@martin.sperl.org wrote:
>> From: Martin Sperl <kernel@martin.sperl.org>
>>
>> Add basic thermal driver for bcm2835 SOC.
>>
>> This driver currently relies on the firmware setting up the
>> tsense HW block and does not set it up itself.
>>
>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> Acked-by: Eric Anholt <eric@anholt.net>
>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>>
...
>> +static int bcm2835_thermal_adc2temp(
>> + const struct bcm2835_thermal_info *info, u32 adc)
>> +{
>> + return info->offset + (adc * info->slope);
>
> Any specific reason we cannot use thermal_zone_params->slope and
> thermal_zone_params->offset?
You could - the patch was just rebased to 4.9 and those slope and
offset just got merged during this cycle.
Do we really need to modify it - the patch has been around since 4.6.
>> +
>> +static int bcm2835_thermal_get_trip_temp(
>> + struct thermal_zone_device *tz, int trip, int *temp)
>> +{
>> + struct bcm2835_thermal_data *data = tz->devdata;
>> + u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
>> +
>> + /* get the THOLD bits */
>> + val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
>> + val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
>> +
>> + /* if it is zero then use the info value */
>> + if (val)
>
> Is this a read only register or is this driver supposed to program it?
> In which scenario it would be 0? Can this be added as comments?
It is RW, but the Firmware typically sets up the thermal device with the
correct values already - this is just a fallback.
>> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
>> + int *temp)
>> +{
>> + struct bcm2835_thermal_data *data = tz->devdata;
>> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
>> +
>> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
>
> What cases you would get the valid bit not set? Do you need to wait for
> the conversion to finish?
I guess: if you have just enabled the HW-block (which the FW does much
in advance) and start to read the value immediately (before the first
sample period has finished), then this will not be valid.
So do you need another version of the patchset that uses that new API?
Thanks,
Martin
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Laurent Pinchart @ 2016-11-17 9:45 UTC (permalink / raw)
To: Jyri Sarha
Cc: Rob Herring, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, tomi.valkeinen-l0cyMroinI0,
robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <506ba969-d753-d026-5357-3329a750ceaf-l0cyMroinI0@public.gmane.org>
Hi Jyri,
On Wednesday 16 Nov 2016 16:39:28 Jyri Sarha wrote:
> On 11/16/16 15:33, Rob Herring wrote:
> >> +Optional properties
> >>
> >>> + - reg: I2C address. If and only if present the driver node
I assume you meant device node, not driver node ?
> >>> + should be placed into the i2c controller node where the
> >>> + tfp410 i2c is connected to (the current implementation does
> >>> + not yet support this).
> >
> > So this chip can work without programming I guess?
>
> Yes. Just powering it up is enough for most application.
>
> > reg should only be not present if I2C is not connected in the design. It
> > can't be a function of what the driver supports. In otherwords, you
> > can't be moving this node around based on when you add I2C control.
>
> Ok, I'll try to implement a dummy i2c driver at the same time too. I can
> not test anything related to it because I do not have a piece of HW with
> tfp410 i2c wires connected, but it should not matter as long as I am
> able to probe it as a i2c client.
I think that Rob's point was that whether the current implementation supports
this or not is irrelevant from a DT bindings point of view. It should not be
mentioned in the bindings document.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Chen-Yu Tsai @ 2016-11-17 9:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Linus Walleij, Klaus Goger,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In the past, all the MMC pins had
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
which was actually a no-op. We were relying on U-boot to set the bias
pull up for us. These properties were removed as part of the fix up to
actually support no bias on the pins. During the transition some boards
experienced regular MMC time-outs during normal operation, while others
completely failed to initialize the SD card.
Given that MMC starts in open-drain mode and the pull-ups are required,
it's best to enable it for all the pin settings.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
arch/arm/boot/dts/sun5i.dtsi | 1 +
arch/arm/boot/dts/sun6i-a31.dtsi | 4 ++++
arch/arm/boot/dts/sun7i-a20.dtsi | 2 ++
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 3 +++
arch/arm/boot/dts/sun8i-a83t.dtsi | 1 +
arch/arm/boot/dts/sun8i-h3.dtsi | 3 +++
arch/arm/boot/dts/sun9i-a80.dtsi | 3 +++
8 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index dae838e4dd9e..ba20b48c0702 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -1023,6 +1023,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 7ab6b336533e..54170147040f 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -582,6 +582,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_pins_a: mmc2@0 {
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 7ea1116c7c88..20a0331ddfb5 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -547,6 +547,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins_a: mmc1@0 {
@@ -554,6 +555,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_pins_a: mmc2@0 {
@@ -571,6 +573,7 @@
"PC24";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
mmc3_8bit_emmc_pins: mmc3@1 {
@@ -580,6 +583,7 @@
"PC24";
function = "mmc3";
drive-strength = <40>;
+ bias-pull-up;
};
uart0_pins_a: uart0@0 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 34d613b0dd73..a1ee4197129a 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1179,6 +1179,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
@@ -1200,6 +1201,7 @@
"PI7", "PI8", "PI9";
function = "mmc3";
drive-strength = <30>;
+ bias-pull-up;
};
ps20_pins_a: ps20@0 {
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index ecb49a5a7615..bc3e936edfcf 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -293,6 +293,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins_a: mmc1@0 {
@@ -300,6 +301,7 @@
"PG3", "PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -309,6 +311,7 @@
"PC15", "PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
pwm0_pins: pwm0 {
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 656cdb5f7a88..79eaa7139f43 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -171,6 +171,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
uart0_pins_a: uart0@0 {
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 416b825ddb9f..fca66bf2dec5 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -348,6 +348,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin: mmc0_cd_pin@0 {
@@ -361,6 +362,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -370,6 +372,7 @@
"PC15", "PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
spi0_pins: spi0 {
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index b97db1df0803..7231d2c90dde 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -696,6 +696,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins: mmc1 {
@@ -703,6 +704,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -712,6 +714,7 @@
"PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
uart0_pins_a: uart0@0 {
--
2.10.2
^ permalink raw reply related
* Re: [RFC PATCH 0/7] mux controller astraction and iio/i2c muxes
From: Peter Rosin @ 2016-11-17 9:33 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479340111-1259-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2016-11-17 00:48, Peter Rosin wrote:
> Hi!
>
> This is work in progress, I'm asking for early feedback.
Forgot to mention, sorry, but this series depends on some
stuff not in mainline yet (the _available work in iio [1]),
but it is in linux-next.
Cheers,
Peter
[1] Specifically these patches:
51239600074b "iio:core: add a callback to allow drivers to provide _available attributes"
00c5f80c2fad "iio: inkern: add helpers to query available values from channels"
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Linus Walleij @ 2016-11-17 9:30 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Arnd Bergmann, Lee Jones, Benjamin Herrenschmidt, Joel Stanley,
Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161117060633.3837-1-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> +* Device tree bindings for the Aspeed LPC Controller
We are going overboard with the lingo sometimes, to the point that we do not
understand how terse things become.
LPC = Low Pin Count, right?
Explain that right here: it is a slow external bus, right?
> +The Aspeed LPC controller contains registers for a variety of functions. Not
> +all registers for a function are contiguous, and some registers are referenced
> +by functions outside the LPC controller.
> +
> +Note that this is separate from the H8S/2168 compatible register set occupying
> +the start of the LPC controller address space.
> +
> +Some significant functions in the LPC controller:
> +
> +* LPC Host Controller
> +* Host Interface Controller
Host interface to what?
> +* iBT Controller
What is iBT?
> +* SuperIO Scratch registers
Again more context please.
With standards documents, either explain everything or provide
pointers for the information.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-17 9:17 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree, linux-kernel, dri-devel, linux-sunxi, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <CAGb2v668A-hFnWy22_DarSSZ6TkvH5=WH-UvaXOFQJBqyKzPXw@mail.gmail.com>
On 11/17/2016 01:25 PM, Chen-Yu Tsai wrote:
> On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>>
>> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>>
>>> Some dumb VGA DACs are active components which require external power.
>>> Add support for specifying a regulator as its power supply.
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
>>> ++++++++++++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> index 003bc246a270..164cbb15f04c 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> @@ -16,6 +16,8 @@ graph bindings specified in
>>> Documentation/devicetree/bindings/graph.txt.
>>> - Video port 0 for RGB input
>>> - Video port 1 for VGA output
>>>
>>> +Optional properties:
>>> +- vdd-supply: Power supply for DAC
>>>
>>> Example
>>> -------
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..15b549f94307 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -12,6 +12,7 @@
>>>
>>> #include <linux/module.h>
>>> #include <linux/of_graph.h>
>>> +#include <linux/regulator/consumer.h>
>>>
>>> #include <drm/drmP.h>
>>> #include <drm/drm_atomic_helper.h>
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>> struct drm_connector connector;
>>>
>>> struct i2c_adapter *ddc;
>>> + struct regulator *vdd;
>>> };
>>>
>>> static inline struct dumb_vga *
>>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>> return 0;
>>> }
>>>
>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> + int ret = 0;
>>> +
>>> + if (vga->vdd)
>>> + ret = regulator_enable(vga->vdd);
>>> +
>>> + if (ret) {
>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>>> + return;
>>
>>
>> We don't need this return for now. If you're okay with it, can I fix this
>> and queue to misc?
>
> Yes, please!
pushed to drm-misc.
Thanks,
Archit
>
> Thanks
> ChenYu
>
>>
>> Thanks,
>> Archit
>>
>>
>>> + }
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->vdd)
>>> + regulator_disable(vga->vdd);
>>> +}
>>> +
>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>> .attach = dumb_vga_attach,
>>> + .enable = dumb_vga_enable,
>>> + .disable = dumb_vga_disable,
>>> };
>>>
>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>>> *pdev)
>>> return -ENOMEM;
>>> platform_set_drvdata(pdev, vga);
>>>
>>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>>> + if (IS_ERR(vga->vdd)) {
>>> + ret = PTR_ERR(vga->vdd);
>>> + if (ret == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + vga->vdd = NULL;
>>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>>> + }
>>> +
>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>> if (IS_ERR(vga->ddc)) {
>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Arnd Bergmann @ 2016-11-17 9:16 UTC (permalink / raw)
To: Andrew Jeffery
Cc: devicetree, Benjamin Herrenschmidt, Linus Walleij, linux-kernel,
Rob Herring, Joel Stanley, Lee Jones, linux-arm-kernel
In-Reply-To: <20161117060633.3837-1-andrew@aj.id.au>
On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>
> I'd like to start a discussion about how to handle the LPC register space in
> the Aspeed SoC. There are a number of issues, largely concerned with the layout
> of the registers but also with the fact that LPC register state is used by the
> pinmux to determine some pin functionality.
...
>
> What is the recommended approach to managing such hardware?
Can you clarify which side of the LPC bus this is? We are currently having
a discussion for how to integrate the LPC master on an ARM64 server that
uses LPC to access an Aspeed LPC slave. For this one we want to use the
traditional ISA DT binding.
I'm guessing that you are interesting in the other side here, for mapping
the registers of the LPC slave on the Aspeed BMC, but that's not clear from
your email, as I'm assuming that the same chip has both master and slave
interfaces.
Arnd
^ permalink raw reply
* Re: [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stanimir Varbanov @ 2016-11-17 9:08 UTC (permalink / raw)
To: Stephen Boyd, Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Andy Gross, Rob Herring,
Mark Rutland, Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree
In-Reply-To: <20161114191641.GH5177@codeaurora.org>
Hi,
On 11/14/2016 09:16 PM, Stephen Boyd wrote:
> On 11/07, Stanimir Varbanov wrote:
>> +#include <linux/module.h>
>> +#include <linux/of_reserved_mem.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/qcom_scm.h>
>> +#include <linux/remoteproc.h>
>> +
>> +#include "qcom_mdt_loader.h"
>> +#include "remoteproc_internal.h"
>> +
>> +#define VENUS_CRASH_REASON_SMEM 425
>
> This is unused. Is there going to be some common smem API to get
> the crash reason?
This is leftover and never used, so I will delete it. About smem maybe
Bjorn have some idea?
>> +
>> +static const struct of_device_id venus_of_match[] = {
>> + { .compatible = "qcom,venus-pil" },
>> + { },
>> +};
>
> Add a MODULE_DEVICE_TABLE?
>
OK.
--
regards,
Stan
^ permalink raw reply
* [PATCH 2/2] arm64: dts: updated sata node on ls1046a dts
From: yuantian.tang @ 2016-11-17 7:59 UTC (permalink / raw)
To: tj
Cc: robh+dt, mark.rutland, catalin.marinas, will.deacon, shawnguo,
linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Tang Yuantian, Tang Yuantian
In-Reply-To: <1479369560-9188-1-git-send-email-yuantian.tang@nxp.com>
From: Tang Yuantian <Yuantian.Tang@nxp.com>
On ls1046a soc, sata ecc should be disabled. So added sata ecc
register address so that driver can get this information.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 38806ca..88aaaf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -507,7 +507,9 @@
sata: sata@3200000 {
compatible = "fsl,ls1046a-ahci";
- reg = <0x0 0x3200000 0x0 0x10000>;
+ reg = <0x0 0x3200000 0x0 0x10000>,
+ <0x0 0x20140520 0x0 0x4>;
+ reg-names = "ahci", "sata-ecc";
interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clockgen 4 1>;
};
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: ahci-fsl-qoriq: added explanation for reg-names
From: yuantian.tang @ 2016-11-17 7:59 UTC (permalink / raw)
To: tj
Cc: robh+dt, mark.rutland, catalin.marinas, will.deacon, shawnguo,
linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Tang Yuantian, Tang Yuantian
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Added explanation for reg-names to make it more clear.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index fc33ca0..80cf10c 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -10,6 +10,8 @@ Required properties:
Optional properties:
- dma-coherent: Enable AHCI coherent DMA operation.
- reg-names: register area names when there are more than 1 register area.
+ example: 'ahci' is for sata controller register.
+ 'sata-ecc' is for sata ecc register.
Examples:
sata@3200000 {
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Chen-Yu Tsai @ 2016-11-17 7:55 UTC (permalink / raw)
To: Archit Taneja
Cc: Chen-Yu Tsai, Maxime Ripard, David Airlie, dri-devel,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <31b8b5b9-9621-286a-7649-cc999ab020da-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja <architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> Hi,
>
> Thanks for the patch.
>
>
> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
>> ++++++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>> - Video port 0 for RGB input
>> - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>> Example
>> -------
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..15b549f94307 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>> #include <linux/module.h>
>> #include <linux/of_graph.h>
>> +#include <linux/regulator/consumer.h>
>>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connector connector;
>>
>> struct i2c_adapter *ddc;
>> + struct regulator *vdd;
>> };
>>
>> static inline struct dumb_vga *
>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>> }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret = 0;
>> +
>> + if (vga->vdd)
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>
>
> We don't need this return for now. If you're okay with it, can I fix this
> and queue to misc?
Yes, please!
Thanks
ChenYu
>
> Thanks,
> Archit
>
>
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (vga->vdd)
>> + regulator_disable(vga->vdd);
>> +}
>> +
>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable = dumb_vga_disable,
>> };
>>
>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + vga->vdd = NULL;
>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCHv2 05/10] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
From: Shawn Lin @ 2016-11-17 7:49 UTC (permalink / raw)
To: Jaehoon Chung, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, heiko-4mtYJXux2i+zQB+pC5nmwQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <868dbb62-4b0d-3492-0b13-093ce63c5cde-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
在 2016/11/17 13:05, Jaehoon Chung 写道:
> On 11/16/2016 06:16 PM, Shawn Lin wrote:
>> 在 2016/11/15 18:12, Jaehoon Chung 写道:
>>> stop_cmdr should be set to values relevant to stop command.
>>> It migth be assigned to values whatever there is mrq->stop or not.
>>> Then it doesn't need to use dw_mci_prepare_command().
>>> It's enough to use the prep_stop_abort for preparing stop command.
>>>
>>
>> Have you considered to clean up the logic of preparing abort cmd
>> within dw_mci_prepare_command?
>
> I have considered this..but i didn't check fully for this logic.
> I think it's possible to clean and make more simpler than now.
>
> how about thinking more after applying these patch-set? :)
it's okay :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>>
>> if (cmd->opcode == MMC_STOP_TRANSMISSION ||
>> cmd->opcode == MMC_GO_IDLE_STATE ||
>> cmd->opcode == MMC_GO_INACTIVE_STATE ||
>> (cmd->opcode == SD_IO_RW_DIRECT &&
>> ((cmd->arg >> 9) & 0x1FFFF) == SDIO_CCCR_ABORT))
>> cmdr |= SDMMC_CMD_STOP;
>>
>>
>>> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> Tested-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 15 +++++----------
>>> 1 file changed, 5 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 3cda68c..12e1107 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -385,7 +385,7 @@ static void dw_mci_start_command(struct dw_mci *host,
>>>
>>> static inline void send_stop_abort(struct dw_mci *host, struct mmc_data *data)
>>> {
>>> - struct mmc_command *stop = data->stop ? data->stop : &host->stop_abort;
>>> + struct mmc_command *stop = &host->stop_abort;
>>>
>>> dw_mci_start_command(host, stop, host->stop_cmdr);
>>> }
>>> @@ -1277,10 +1277,7 @@ static void __dw_mci_start_request(struct dw_mci *host,
>>> spin_unlock_irqrestore(&host->irq_lock, irqflags);
>>> }
>>>
>>> - if (mrq->stop)
>>> - host->stop_cmdr = dw_mci_prepare_command(slot->mmc, mrq->stop);
>>> - else
>>> - host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
>>> + host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
>>> }
>>>
>>> static void dw_mci_start_request(struct dw_mci *host,
>>> @@ -1890,8 +1887,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
>>> if (test_and_clear_bit(EVENT_DATA_ERROR,
>>> &host->pending_events)) {
>>> dw_mci_stop_dma(host);
>>> - if (data->stop ||
>>> - !(host->data_status & (SDMMC_INT_DRTO |
>>> + if (!(host->data_status & (SDMMC_INT_DRTO |
>>> SDMMC_INT_EBE)))
>>> send_stop_abort(host, data);
>>> state = STATE_DATA_ERROR;
>>> @@ -1927,8 +1923,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
>>> if (test_and_clear_bit(EVENT_DATA_ERROR,
>>> &host->pending_events)) {
>>> dw_mci_stop_dma(host);
>>> - if (data->stop ||
>>> - !(host->data_status & (SDMMC_INT_DRTO |
>>> + if (!(host->data_status & (SDMMC_INT_DRTO |
>>> SDMMC_INT_EBE)))
>>> send_stop_abort(host, data);
>>> state = STATE_DATA_ERROR;
>>> @@ -2004,7 +1999,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
>>> host->cmd = NULL;
>>> host->data = NULL;
>>>
>>> - if (mrq->stop)
>>> + if (!mrq->sbc && mrq->stop)
>>> dw_mci_command_complete(host, mrq->stop);
>>> else
>>> host->cmd_status = 0;
>>>
>>
>>
>
>
>
>
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-17 7:48 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, David Airlie
Cc: devicetree, linux-sunxi, linux-arm-kernel, dri-devel,
linux-kernel
In-Reply-To: <20161116154232.872-2-wens@csie.org>
Hi,
Thanks for the patch.
On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
> Some dumb VGA DACs are active components which require external power.
> Add support for specifying a regulator as its power supply.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> index 003bc246a270..164cbb15f04c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> - Video port 0 for RGB input
> - Video port 1 for VGA output
>
> +Optional properties:
> +- vdd-supply: Power supply for DAC
>
> Example
> -------
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232185a7..15b549f94307 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -12,6 +12,7 @@
>
> #include <linux/module.h>
> #include <linux/of_graph.h>
> +#include <linux/regulator/consumer.h>
>
> #include <drm/drmP.h>
> #include <drm/drm_atomic_helper.h>
> @@ -23,6 +24,7 @@ struct dumb_vga {
> struct drm_connector connector;
>
> struct i2c_adapter *ddc;
> + struct regulator *vdd;
> };
>
> static inline struct dumb_vga *
> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
> return 0;
> }
>
> +static void dumb_vga_enable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + int ret = 0;
> +
> + if (vga->vdd)
> + ret = regulator_enable(vga->vdd);
> +
> + if (ret) {
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + return;
We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?
Thanks,
Archit
> + }
> +}
> +
> +static void dumb_vga_disable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->vdd)
> + regulator_disable(vga->vdd);
> +}
> +
> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
> .attach = dumb_vga_attach,
> + .enable = dumb_vga_enable,
> + .disable = dumb_vga_disable,
> };
>
> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, vga);
>
> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
> + if (IS_ERR(vga->vdd)) {
> + ret = PTR_ERR(vga->vdd);
> + if (ret == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + vga->vdd = NULL;
> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
> + }
> +
> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
> if (IS_ERR(vga->ddc)) {
> if (PTR_ERR(vga->ddc) == -ENODEV) {
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v8 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-17 7:12 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A
Cc: tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Vineet.Gupta1-HKixBCOQz3hWk0Htik3J/w,
Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w, Noam Camus
From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Till now we used clockevent from generic ARC driver.
This was enough as long as we worked with simple multicore SoC.
When we are working with multithread SoC each HW thread can be
scheduled to receive timer interrupt using timer mask register.
This patch will provide a way to control clock events per HW thread.
The design idea is that for each core there is dedicated register
(TSI) serving all 16 HW threads.
The register is a bitmask with one bit for each HW thread.
When HW thread wants that next expiration of timer interrupt will
hit it then the proper bit should be set in this dedicated register.
When timer expires all HW threads within this core which their bit
is set at the TSI register will be interrupted.
Driver can be used from device tree by:
compatible = "ezchip,nps400-timer0" <-- for clocksource
compatible = "ezchip,nps400-timer1" <-- for clockevent
Note that name convention for timer0/timer1 was taken from legacy
ARC design. This design is our base before adding HW threads.
For backward compatibility we keep "ezchip,nps400-timer" for clocksource
Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Acked-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/timer/ezchip,nps400-timer.txt | 15 --
.../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
.../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
drivers/clocksource/timer-nps.c | 170 ++++++++++++++++++++
4 files changed, 202 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
deleted file mode 100644
index c8c03d7..0000000
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-NPS Network Processor
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-timer"
-
-Clocks required for compatible = "ezchip,nps400-timer":
-- clocks : Must contain a single entry describing the clock input
-
-Example:
-
-timer {
- compatible = "ezchip,nps400-timer";
- clocks = <&sysclk>;
-};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
new file mode 100644
index 0000000..e3cfce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
@@ -0,0 +1,17 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer0"
+
+Clocks required for compatible = "ezchip,nps400-timer0":
+- interrupts : The interrupt of the first timer
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+ compatible = "ezchip,nps400-timer0";
+ interrupts = <3>;
+ clocks = <&sysclk>;
+};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
new file mode 100644
index 0000000..c0ab419
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
@@ -0,0 +1,15 @@
+NPS Network Processor
+
+Required properties:
+
+- compatible : should be "ezchip,nps400-timer1"
+
+Clocks required for compatible = "ezchip,nps400-timer1":
+- clocks : Must contain a single entry describing the clock input
+
+Example:
+
+timer {
+ compatible = "ezchip,nps400-timer1";
+ clocks = <&sysclk>;
+};
diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
index 0c8e21f..b4c8a02 100644
--- a/drivers/clocksource/timer-nps.c
+++ b/drivers/clocksource/timer-nps.c
@@ -111,3 +111,173 @@ static int __init nps_setup_clocksource(struct device_node *node)
CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
nps_setup_clocksource);
+CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
+ nps_setup_clocksource);
+
+#ifdef CONFIG_EZNPS_MTM_EXT
+#include <soc/nps/mtm.h>
+
+/* Timer related Aux registers */
+#define NPS_REG_TIMER0_TSI 0xFFFFF850
+#define NPS_REG_TIMER0_LIMIT 0x23
+#define NPS_REG_TIMER0_CTRL 0x22
+#define NPS_REG_TIMER0_CNT 0x21
+
+/*
+ * Interrupt Enabled (IE) - re-arm the timer
+ * Not Halted (NH) - is cleared when working with JTAG (for debug)
+ */
+#define TIMER0_CTRL_IE BIT(0)
+#define TIMER0_CTRL_NH BIT(1)
+
+static unsigned long nps_timer0_freq;
+static unsigned long nps_timer0_irq;
+
+static void nps_clkevent_rm_thread(void)
+{
+ int thread;
+ unsigned int cflags, enabled_threads;
+
+ hw_schd_save(&cflags);
+
+ enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
+
+ /* remove thread from TSI1 */
+ thread = read_aux_reg(CTOP_AUX_THREAD_ID);
+ enabled_threads &= ~(1 << thread);
+ write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
+
+ /* Acknowledge and if needed re-arm the timer */
+ if (!enabled_threads)
+ write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
+ else
+ write_aux_reg(NPS_REG_TIMER0_CTRL,
+ TIMER0_CTRL_IE | TIMER0_CTRL_NH);
+
+ hw_schd_restore(cflags);
+}
+
+static void nps_clkevent_add_thread(unsigned long delta)
+{
+ int thread;
+ unsigned int cflags, enabled_threads;
+
+ hw_schd_save(&cflags);
+
+ /* add thread to TSI1 */
+ thread = read_aux_reg(CTOP_AUX_THREAD_ID);
+ enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
+ enabled_threads |= (1 << thread);
+ write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
+
+ /* set next timer event */
+ write_aux_reg(NPS_REG_TIMER0_LIMIT, delta);
+ write_aux_reg(NPS_REG_TIMER0_CNT, 0);
+ write_aux_reg(NPS_REG_TIMER0_CTRL,
+ TIMER0_CTRL_IE | TIMER0_CTRL_NH);
+
+ hw_schd_restore(cflags);
+}
+
+/*
+ * Whenever anyone tries to change modes, we just mask interrupts
+ * and wait for the next event to get set.
+ */
+static int nps_clkevent_set_state(struct clock_event_device *dev)
+{
+ nps_clkevent_rm_thread();
+ disable_percpu_irq(nps_timer0_irq);
+
+ return 0;
+}
+
+static int nps_clkevent_set_next_event(unsigned long delta,
+ struct clock_event_device *dev)
+{
+ nps_clkevent_add_thread(delta);
+ enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
+
+ return 0;
+}
+
+static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
+ .name = "NPS Timer0",
+ .features = CLOCK_EVT_FEAT_ONESHOT,
+ .rating = 300,
+ .set_next_event = nps_clkevent_set_next_event,
+ .set_state_oneshot = nps_clkevent_set_state,
+ .set_state_oneshot_stopped = nps_clkevent_set_state,
+ .set_state_shutdown = nps_clkevent_set_state,
+ .tick_resume = nps_clkevent_set_state,
+};
+
+static irqreturn_t timer_irq_handler(int irq, void *dev_id)
+{
+ struct clock_event_device *evt = dev_id;
+
+ nps_clkevent_rm_thread();
+ evt->event_handler(evt);
+
+ return IRQ_HANDLED;
+}
+
+static int nps_timer_starting_cpu(unsigned int cpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
+
+ evt->cpumask = cpumask_of(smp_processor_id());
+
+ clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
+ enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
+
+ return 0;
+}
+
+static int nps_timer_dying_cpu(unsigned int cpu)
+{
+ disable_percpu_irq(nps_timer0_irq);
+ return 0;
+}
+
+static int __init nps_setup_clockevent(struct device_node *node)
+{
+ struct clk *clk;
+ int ret;
+
+ nps_timer0_irq = irq_of_parse_and_map(node, 0);
+ if (nps_timer0_irq <= 0) {
+ pr_err("clockevent: missing irq");
+ return -EINVAL;
+ }
+
+ ret = nps_get_timer_clk(node, &nps_timer0_freq, &clk);
+ if (ret)
+ return ret;
+
+ /* Needs apriori irq_set_percpu_devid() done in intc map function */
+ ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
+ "Timer0 (per-cpu-tick)",
+ &nps_clockevent_device);
+ if (ret) {
+ pr_err("Couldn't request irq\n");
+ clk_disable_unprepare(clk);
+ return ret;
+ }
+
+ ret = cpuhp_setup_state(CPUHP_AP_ARC_TIMER_STARTING,
+ "clockevents/nps:starting",
+ nps_timer_starting_cpu,
+ nps_timer_dying_cpu);
+ if (ret) {
+ pr_err("Failed to setup hotplug state");
+ clk_disable_unprepare(clk);
+ free_percpu_irq(nps_timer0_irq, &nps_clockevent_device);
+ return ret;
+ }
+
+ return 0;
+}
+
+CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
+ nps_setup_clockevent);
+#endif /* CONFIG_EZNPS_MTM_EXT */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH v7 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-17 7:12 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161116134455.dv2fmuh4ot7yjiyc@rob-hp-laptop>
>From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
>Sent: Wednesday, November 16, 2016 3:45 PM
...
>Please add acks when reposting.
>Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Will post [PATCH v8 3/3] with your ack
Thanks
Noam
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Tomi Valkeinen @ 2016-11-17 7:07 UTC (permalink / raw)
To: Jyri Sarha, Rob Herring
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
laurent.pinchart
In-Reply-To: <506ba969-d753-d026-5357-3329a750ceaf@ti.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 729 bytes --]
On 16/11/16 16:39, Jyri Sarha wrote:
> On 11/16/16 15:33, Rob Herring wrote:
>>> +Optional properties
>>>> + - reg: I2C address. If and only if present the driver node
>>>> + should be placed into the i2c controller node where the
>>>> + tfp410 i2c is connected to (the current implementation does
>>>> + not yet support this).
>> So this chip can work without programming I guess?
>>
>
> Yes. Just powering it up is enough for most application.
Right, and not only that, but in all the TI boards I have seen TFP410's
i2c pins are not even connected. The data sheet says "[TFP410] can be
controlled in two ways: 1) configuration and state pins or 2) the
programmable I2C serial interface".
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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