* [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC
From: Neil Armstrong @ 2016-11-03 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103153647.GD25852@remoulade>
On 11/03/2016 04:36 PM, Mark Rutland wrote:
> On Thu, Nov 03, 2016 at 03:29:24PM +0100, Neil Armstrong wrote:
>> The Amlogic Meson GX SoCs uses a special register to store the
>> time in seconds to wakeup after a system suspend.
>
> Where does this register live, exactly? What IP block is it part of?
It's part of the Always-ON APB registers, there is no clear IP block here,
but it seems to be like a scratch register shared with the BL3 FW.
>
>> In order to be able to reuse the RTC wakealarm feature, this
>> driver implements a fake RTC device which uses the system time
>> to deduce a suspend delay.
>
> This sounds like an always-on oneshot timer device, not an RTC.
The register seems to never change, and it seems to be an indication for the
FW when it enters the suspend mode.
>
>> +static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
>> +{
>> + unsigned long local_time;
>> + struct timeval time;
>> +
>> + do_gettimeofday(&time);
>> + local_time = time.tv_sec - (sys_tz.tz_minuteswest * 60);
>> + rtc_time_to_tm(local_time, tm);
>> +
>> + return 0;
>> +}
>
> ... if this were a timer, you wouldn't need this hack.
Actually the vendor tree uses a 64bit running counter to provide this
but with a fixed start date.
>
>> +static int meson_vrtc_probe(struct platform_device *pdev)
>> +{
>> + struct meson_vrtc_data *vrtc;
>> + struct resource *res;
>> +
>> + vrtc = devm_kzalloc(&pdev->dev, sizeof(*vrtc), GFP_KERNEL);
>> + if (!vrtc)
>> + return -ENOMEM;
>> +
>> + vrtc->pdev = pdev;
>> +
>> + /* Alarm registers */
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + vrtc->io_alarm = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(vrtc->io_alarm))
>> + return PTR_ERR(vrtc->io_alarm);
>> +
>> + device_init_wakeup(&pdev->dev, 1);
>> +
>> + platform_set_drvdata(pdev, vrtc);
>> +
>> + vrtc->rtc = devm_rtc_device_register(&pdev->dev, "meson-vrtc",
>> + &meson_vrtc_ops, THIS_MODULE);
>> + if (IS_ERR(vrtc->rtc))
>> + return PTR_ERR(vrtc->rtc);
>> +
>> + return 0;
>> +}
>
> I see that no interrupt is described. How exactly does this wake the system
> from suspend? Is there some interrupt managed by FW for this, for example?
It seems to be managed by the BL3 FW. We have no details on the underlying implementation.
>
>> +static const struct of_device_id meson_vrtc_dt_match[] = {
>> + { .compatible = "amlogic,meson-vrtc"},
>
> There was no binding documentation in this patch series.
>
> Thanks,
> Mark.
>
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Mark Rutland @ 2016-11-03 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3724ea58-3c04-1248-8359-e2927da03aaf@redhat.com>
On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> On 11/02/2016 04:52 PM, Mark Rutland wrote:
> >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> >>
> >>__pa_symbol is technically the marco that should be used for kernel
> >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> >
> >Nit: s/marco/macro/
> >
> >I see there are some other uses of __pa() that look like they could/should be
> >__pa_symbol(), e.g. in mark_rodata_ro().
> >
> >I guess strictly speaking those need to be updated to? Or is there a reason
> >that we should not?
>
> If the concept of __pa_symbol is okay then yes I think all uses of __pa
> should eventually be converted for consistency and debugging.
I have no strong feelings either way about __pa_symbol(); I'm not clear on what
the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
for consistency with other architectures.
However, if we use it I think that we should (attempt to) use it consistently
from the outset.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/6] pinctrl: rockchip: add support for rk1108
From: Heiko Stübner @ 2016-11-03 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478176470-11956-1-git-send-email-andy.yan@rock-chips.com>
Am Donnerstag, 3. November 2016, 20:34:30 schrieb Andy Yan:
> Add basic support for rk1108 soc
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
nice when support for a new soc is that easy in a driver :-)
There are two small issues below and with those fixed
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
>
> drivers/pinctrl/pinctrl-rockchip.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
missing devicetree binding update for the new compatible
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index 49bf7dc..9f324b1 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
[...]
> +static struct rockchip_pin_ctrl rk1108_pin_ctrl = {
> + .pin_banks = rk1108_pin_banks,
> + .nr_banks = ARRAY_SIZE(rk1108_pin_banks),
> + .label = "RK1108-GPIO",
> + .type = RK1108,
> + .grf_mux_offset = 0x10,
> + .pmu_mux_offset = 0x0,
> + .pull_calc_reg = rk3288_calc_pull_reg_and_bit,
this last line has spaces instead of tabs between .pull_calc_reg and the "="
Heiko
^ permalink raw reply
* [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Mark Rutland @ 2016-11-03 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a77c2162-6eb9-09c8-e84f-03a207b59c6b@redhat.com>
On Wed, Nov 02, 2016 at 06:05:38PM -0600, Laura Abbott wrote:
> On 11/02/2016 05:06 PM, Mark Rutland wrote:
> >On Wed, Nov 02, 2016 at 03:00:54PM -0600, Laura Abbott wrote:
> >>+CFLAGS_physaddr.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> >>+obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> >>+ /*
> >>+ * This is intentionally different than above to be a tighter check
> >>+ * for symbols.
> >>+ */
> >>+ VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
> >
> >Can't we use _text instead of kimage_vaddr + TEXT_OFFSET? That way we don't
> >need CFLAGS_physaddr.o.
> >
> >Or KERNEL_START / KERNEL_END from <asm/memory.h>?
> >
> >Otherwise, this looks good to me (though I haven't grokked the need for
> >__pa_symbol() yet).
>
> I guess it's a question of what's clearer. I like kimage_vaddr +
> TEXT_OFFSET because it clearly states we are checking from the
> start of the kernel image vs. _text only shows the start of the
> text region. Yes, it's technically the same but a little less
> obvious. I suppose that could be solved with some more elaboration
> in the comment.
Sure, it's arguable either way.
I do think that KERNEL_START/KERNEL_END are a better choice, with the comment
you suggest, and/or renamed to KERNEL_IMAGE_*. They already describe the bounds
of the image (though the naming doesn't make that entirely clear).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 0/4] Add DT support for DA8xx
From: Alexandre Bailon @ 2016-11-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Change in v4:
* Fix a nit
Alexandre Bailon (1):
ARM: dts: da850: Add the usb otg device node
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 6 +++
6 files changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH v4 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
From: Alexandre Bailon @ 2016-11-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478188752-22447-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v4 2/4] usb: musb: core: added helper function for parsing DT
From: Alexandre Bailon @ 2016-11-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478188752-22447-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy <petr@barix.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
drivers/usb/musb/musb_core.h | 6 ++++++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/usb.h>
+#include <linux/usb/of.h>
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-------------------------------------------------------------------------*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..76f00f6 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,10 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/*
+ * gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
^ permalink raw reply related
* [PATCH v4 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-11-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478188752-22447-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..51ae3b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 510000)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -486,6 +511,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power = get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +571,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478188752-22447-1-git-send-email-abailon@baylibre.com>
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..9f5040c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+ };
+
+&usb0 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..322a31a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.3
^ permalink raw reply related
* [GIT PULL] iommu/arm-smmu: Fixes for 4.9
From: Will Deacon @ 2016-11-03 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103153303.GA837@8bytes.org>
Hi Joerg,
On Thu, Nov 03, 2016 at 09:33:04AM -0600, Joerg Roedel wrote:
> On Fri, Oct 28, 2016 at 05:01:48PM +0100, Will Deacon wrote:
> > iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
>
> Hmm, this patch is pretty ugly. Wouldn't it be better to have
> hardware-independent init-routine in the arm-smmu-v3 driver that checks
> DT whether there is an SMMU at all and if yes, sets the per-bus
> iommu-ops?
We're basically doing that already, since the bus_set_iommu call happens in
the probe routine, which won't run unless an SMMUv3 has been found in the
DT. The issue we're trying to avoid is failing the probe of a second SMMUv3
in the system, because the bus will already have the iommu ops set by the
first SMMUv3 that probed.
I suppose we could go and compare bus->iommu_ops with &arm_smmu_ops, but
given that we can't support different IOMMU types on a single bus, I don't
think we gain anything from that.
Will
^ permalink raw reply
* [PATCH v2 0/3] davinci: ohci: fix usb ohci device name
From: Axel Haslam @ 2016-11-03 16:03 UTC (permalink / raw)
To: linux-arm-kernel
The usb ohci clock match is not working because the usb clock
is registered as "ohci" instead of "ohci.0"
But since there is only a single ohci instance, lets pass -1 to
the platform data id parameter and avoid the extra ".0" matching.
while we are fixing this, rename the driver from "ohci" to
"ohci-da8xx" which is less generic and consistent with other
usb drivers.
changes form v1 -> v2
*Reword commit messages (David Lechner)
Because of the recently accepted patches on the ARM-davinci side,
This patch series is based on:
branch: /v4.10/soc of the linux-davinci tree.
It Depends on two accepted usb patches missing on that branch:
6c21caa USB: OHCI: make ohci-da8xx a separate driver (in next-usb)
6110c42 usb: ohci-da8xx: Remove code that references mach (in linux-next)
A branch with both patches applied + this series can be found here:
https://github.com/axelhaslamx/linux-axel/commits/ti-davinci-ohci-rename
Axel Haslam (3):
ARM: davinci: da8xx: Fix ohci device name
phy: da8xx-usb: rename the ohci device to ohci-da8xx
usb: ohci-da8xx: rename driver to ohci-da8xx
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 4 ++--
drivers/phy/phy-da8xx-usb.c | 5 +++--
drivers/usb/host/ohci-da8xx.c | 2 +-
6 files changed, 9 insertions(+), 8 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v2 1/3] ARM: davinci: da8xx: Fix ohci device name
From: Axel Haslam @ 2016-11-03 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-1-ahaslam@baylibre.com>
While the clk lookup table is making reference to "ohci"
other subsystems (such as phy) are trying to match "ohci.0"
Since there is a single ohci instance, instead of changing
the clk name, change the dev id to -1, and add the "-da8xx"
postfix to match the driver name that will also be changed
in a subsequent patch.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 41459bd..073c458 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -420,7 +420,7 @@ static struct clk_lookup da830_clks[] = {
CLK("davinci_mdio.0", "fck", &emac_clk),
CLK(NULL, "gpio", &gpio_clk),
CLK("i2c_davinci.2", NULL, &i2c1_clk),
- CLK("ohci", "usb11", &usb11_clk),
+ CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK(NULL, "emif3", &emif3_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "rmii", &rmii_clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 196e262..3961556 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -503,7 +503,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
CLK(NULL, "aemif", &aemif_clk),
- CLK("ohci", "usb11", &usb11_clk),
+ CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
CLK("spi_davinci.1", NULL, &spi1_clk),
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 92ae093..2afb067 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -39,7 +39,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
- OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci", NULL),
+ OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
{}
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index b010e5f..c6feecf 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -109,8 +109,8 @@ static struct resource da8xx_usb11_resources[] = {
static u64 da8xx_usb11_dma_mask = DMA_BIT_MASK(32);
static struct platform_device da8xx_usb11_device = {
- .name = "ohci",
- .id = 0,
+ .name = "ohci-da8xx",
+ .id = -1,
.dev = {
.dma_mask = &da8xx_usb11_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx
From: Axel Haslam @ 2016-11-03 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-1-ahaslam@baylibre.com>
The ohci device name has changed in the board configuraion files,
hence, change the phy lookup table to match the new name.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
drivers/phy/phy-da8xx-usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
index 32ae78c..c85fb0b 100644
--- a/drivers/phy/phy-da8xx-usb.c
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device *pdev)
} else {
int ret;
- ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
+ ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
+ "ohci-da8xx");
if (ret)
dev_warn(dev, "Failed to create usb11 phy lookup\n");
ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
@@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device *pdev)
if (!pdev->dev.of_node) {
phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
- phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
+ phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
}
return 0;
--
2.10.1
^ permalink raw reply related
* [PATCH v2 3/3] usb: ohci-da8xx: rename driver to ohci-da8xx
From: Axel Haslam @ 2016-11-03 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-1-ahaslam@baylibre.com>
The davinci ohci driver name (currently "ohci") is too generic.
To be consistent with other usb dirvers, append the "-da8xx" postfix
to the name.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
drivers/usb/host/ohci-da8xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 30c4878..429d58b 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -27,7 +27,7 @@
#include "ohci.h"
#define DRIVER_DESC "DA8XX"
-#define DRV_NAME "ohci"
+#define DRV_NAME "ohci-da8xx"
static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
--
2.10.1
^ permalink raw reply related
* [GIT PULL] iommu/arm-smmu: Fixes for 4.9
From: Joerg Roedel @ 2016-11-03 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160006.GS22791@arm.com>
On Thu, Nov 03, 2016 at 04:00:06PM +0000, Will Deacon wrote:
> We're basically doing that already, since the bus_set_iommu call happens in
> the probe routine, which won't run unless an SMMUv3 has been found in the
> DT. The issue we're trying to avoid is failing the probe of a second SMMUv3
> in the system, because the bus will already have the iommu ops set by the
> first SMMUv3 that probed.
>
> I suppose we could go and compare bus->iommu_ops with &arm_smmu_ops, but
> given that we can't support different IOMMU types on a single bus, I don't
> think we gain anything from that.
Can you instead check whether there is already another smmu probed and
skip the bus_set_iommu call then?
Joerg
^ permalink raw reply
* [GIT PULL] iommu/arm-smmu: Fixes for 4.9
From: Robin Murphy @ 2016-11-03 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103161407.GR3541@8bytes.org>
On 03/11/16 16:14, Joerg Roedel wrote:
> On Thu, Nov 03, 2016 at 04:00:06PM +0000, Will Deacon wrote:
>> We're basically doing that already, since the bus_set_iommu call happens in
>> the probe routine, which won't run unless an SMMUv3 has been found in the
>> DT. The issue we're trying to avoid is failing the probe of a second SMMUv3
>> in the system, because the bus will already have the iommu ops set by the
>> first SMMUv3 that probed.
>>
>> I suppose we could go and compare bus->iommu_ops with &arm_smmu_ops, but
>> given that we can't support different IOMMU types on a single bus, I don't
>> think we gain anything from that.
>
> Can you instead check whether there is already another smmu probed and
> skip the bus_set_iommu call then?
But bus_set_iommu() is already checking whether another SMMU (in this
case) has probed, by virtue of bus->iommu_ops being non-NULL, and
returning without doing anything if so. What's the value of adding a
whole bunch more code to effectively duplicate that in a less elegant
manner?
Robin.
>
>
> Joerg
>
^ permalink raw reply
* [PATCH] ASoC: sun4i-i2s: Implement capture support
From: Maxime Ripard @ 2016-11-03 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103153218.fibbz7y7pqwqyo7r@sirena.org.uk>
On Thu, Nov 03, 2016 at 09:32:18AM -0600, Mark Brown wrote:
> On Thu, Nov 03, 2016 at 11:20:48AM +0100, Maxime Ripard wrote:
> > The i2s driver was only implementing playback for now. Implement capture to
> > make sure that's not a limitation anymore.
>
> This doesn't apply against current code, please check and resend.
Argh, yes, sorry.
I'll send a new version.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/4a5d247c/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] ASoC: sun4i-i2s: Implement capture support
From: Maxime Ripard @ 2016-11-03 16:27 UTC (permalink / raw)
To: linux-arm-kernel
The i2s driver was only implementing playback for now. Implement capture to
make sure that's not a limitation anymore.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Changes from v1:
- Rebased on top of asoc's topic/sunxi branch
sound/soc/sunxi/sun4i-i2s.c | 52 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 687a8f83dbe5..a7653114e895 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -93,6 +93,7 @@ struct sun4i_i2s {
struct clk *mod_clk;
struct regmap *regmap;
+ struct snd_dmaengine_dai_dma_data capture_dma_data;
struct snd_dmaengine_dai_dma_data playback_dma_data;
};
@@ -341,6 +342,27 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
return 0;
}
+static void sun4i_i2s_start_capture(struct sun4i_i2s *i2s)
+{
+ /* Flush RX FIFO */
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
+ SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
+ SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
+
+ /* Clear RX counter */
+ regmap_write(i2s->regmap, SUN4I_I2S_RX_CNT_REG, 0);
+
+ /* Enable RX Block */
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
+ SUN4I_I2S_CTRL_RX_EN,
+ SUN4I_I2S_CTRL_RX_EN);
+
+ /* Enable RX DRQ */
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_DMA_INT_CTRL_REG,
+ SUN4I_I2S_DMA_INT_CTRL_RX_DRQ_EN,
+ SUN4I_I2S_DMA_INT_CTRL_RX_DRQ_EN);
+}
+
static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
{
/* Flush TX FIFO */
@@ -362,6 +384,18 @@ static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
SUN4I_I2S_DMA_INT_CTRL_TX_DRQ_EN);
}
+static void sun4i_i2s_stop_capture(struct sun4i_i2s *i2s)
+{
+ /* Disable RX Block */
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
+ SUN4I_I2S_CTRL_RX_EN,
+ 0);
+
+ /* Disable RX DRQ */
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_DMA_INT_CTRL_REG,
+ SUN4I_I2S_DMA_INT_CTRL_RX_DRQ_EN,
+ 0);
+}
static void sun4i_i2s_stop_playback(struct sun4i_i2s *i2s)
{
@@ -388,7 +422,7 @@ static int sun4i_i2s_trigger(struct snd_pcm_substream *substream, int cmd,
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
sun4i_i2s_start_playback(i2s);
else
- return -EINVAL;
+ sun4i_i2s_start_capture(i2s);
break;
case SNDRV_PCM_TRIGGER_STOP:
@@ -397,7 +431,7 @@ static int sun4i_i2s_trigger(struct snd_pcm_substream *substream, int cmd,
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
sun4i_i2s_stop_playback(i2s);
else
- return -EINVAL;
+ sun4i_i2s_stop_capture(i2s);
break;
default:
@@ -459,7 +493,9 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
- snd_soc_dai_init_dma_data(dai, &i2s->playback_dma_data, NULL);
+ snd_soc_dai_init_dma_data(dai,
+ &i2s->playback_dma_data,
+ &i2s->capture_dma_data);
snd_soc_dai_set_drvdata(dai, i2s);
@@ -468,6 +504,13 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
static struct snd_soc_dai_driver sun4i_i2s_dai = {
.probe = sun4i_i2s_dai_probe,
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 2,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ },
.playback = {
.stream_name = "Playback",
.channels_min = 2,
@@ -630,6 +673,9 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
i2s->playback_dma_data.maxburst = 4;
+ i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
+ i2s->capture_dma_data.maxburst = 4;
+
pm_runtime_enable(&pdev->dev);
if (!pm_runtime_enabled(&pdev->dev)) {
ret = sun4i_i2s_runtime_resume(&pdev->dev);
--
2.10.1
^ permalink raw reply related
* [GIT PULL] iommu/arm-smmu: Fixes for 4.9
From: Joerg Roedel @ 2016-11-03 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0dbf2665-4292-d49a-b9e7-688bcdf29c6e@arm.com>
On Thu, Nov 03, 2016 at 04:22:04PM +0000, Robin Murphy wrote:
> But bus_set_iommu() is already checking whether another SMMU (in this
> case) has probed, by virtue of bus->iommu_ops being non-NULL, and
> returning without doing anything if so. What's the value of adding a
> whole bunch more code to effectively duplicate that in a less elegant
> manner?
No, bus_set_iommu() checks whether there is _any_ other IOMMU already
registered. This doesn't need to be an smmu. So I think the return value
of bus_set_iommu shouldn't be generally ignored.
Joerg
^ permalink raw reply
* [PATCH v2 6/6] ARM: dts: stm32f429: Add QSPI clock
From: Alexandre Torgue @ 2016-11-03 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476436699-21879-7-git-send-email-gabriel.fernandez@st.com>
Hi Gabriel,
On 10/14/2016 11:18 AM, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds the QSPI clock for stm32f469 discovery board.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index e911af8..4052023 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -66,6 +66,10 @@
> };
> };
>
> +&rcc {
> + compatible = "st,stm32f469-rcc", "st,stm32-rcc";
> +};
> +
With this patch, stm32f469-disco doesn't boot if clk drivers patch are
not applied.
Can you please send a new version to keep compatibility with older clk
driver.
&rcc {
> + compatible = "st,stm32f469-rcc", "st,stm32-rcc";
-> compatible = "st,stm32f469-rcc", "st,stm32f42xx-rcc", "st,stm32-rcc";
> +};
> +
I will take it in next pull request round.
Regards
Alex
> &clk_hse {
> clock-frequency = <8000000>;
> };
>
^ permalink raw reply
* [PATCH v5 5/7] net: ethernet: bgmac: device tree phy enablement
From: Jon Mason @ 2016-11-03 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35b16640-8600-8c48-2f04-886dc925229d@milecki.pl>
On Thu, Nov 03, 2016 at 09:31:21AM +0100, Rafal Milecki wrote:
> On 11/02/2016 06:08 PM, Jon Mason wrote:
> >Change the bgmac driver to allow for phy's defined by the device tree
>
> This is a late review, I know, sorry... :(
>
>
> >+static int bcma_phy_direct_connect(struct bgmac *bgmac)
> >+{
> >+ struct fixed_phy_status fphy_status = {
> >+ .link = 1,
> >+ .speed = SPEED_1000,
> >+ .duplex = DUPLEX_FULL,
> >+ };
> >+ struct phy_device *phy_dev;
> >+ int err;
> >+
> >+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> >+ if (!phy_dev || IS_ERR(phy_dev)) {
> >+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> >+ return -ENODEV;
> >+ }
> >+
> >+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> >+ PHY_INTERFACE_MODE_MII);
> >+ if (err) {
> >+ dev_err(bgmac->dev, "Connecting PHY failed\n");
> >+ return err;
> >+ }
> >+
> >+ return err;
> >+}
>
> This bcma specific function looks exactly the same as...
>
>
> >+static int platform_phy_direct_connect(struct bgmac *bgmac)
> >+{
> >+ struct fixed_phy_status fphy_status = {
> >+ .link = 1,
> >+ .speed = SPEED_1000,
> >+ .duplex = DUPLEX_FULL,
> >+ };
> >+ struct phy_device *phy_dev;
> >+ int err;
> >+
> >+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> >+ if (!phy_dev || IS_ERR(phy_dev)) {
> >+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> >+ return -ENODEV;
> >+ }
> >+
> >+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> >+ PHY_INTERFACE_MODE_MII);
> >+ if (err) {
> >+ dev_err(bgmac->dev, "Connecting PHY failed\n");
> >+ return err;
> >+ }
> >+
> >+ return err;
> >+}
>
> This one.
>
> Would that make sense to keep bgmac_phy_connect_direct and just use it in
> bcma/platform code?
Yes, I was having the same internal debate. I hate the duplication of
code, but I really wanted to keep the PHY logic out of the bgmac.c
file. Do you think it is acceptable to make this an inline function
in bgmac.h?
Thanks,
Jon
^ permalink raw reply
* [PATCH v2 0/3] davinci: ohci: fix usb ohci device name
From: David Lechner @ 2016-11-03 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-1-ahaslam@baylibre.com>
On 11/03/2016 11:03 AM, Axel Haslam wrote:
> The usb ohci clock match is not working because the usb clock
> is registered as "ohci" instead of "ohci.0"
>
> But since there is only a single ohci instance, lets pass -1 to
> the platform data id parameter and avoid the extra ".0" matching.
>
> while we are fixing this, rename the driver from "ohci" to
> "ohci-da8xx" which is less generic and consistent with other
> usb drivers.
>
> changes form v1 -> v2
> *Reword commit messages (David Lechner)
>
> Because of the recently accepted patches on the ARM-davinci side,
> This patch series is based on:
> branch: /v4.10/soc of the linux-davinci tree.
>
> It Depends on two accepted usb patches missing on that branch:
> 6c21caa USB: OHCI: make ohci-da8xx a separate driver (in next-usb)
> 6110c42 usb: ohci-da8xx: Remove code that references mach (in linux-next)
>
> A branch with both patches applied + this series can be found here:
> https://github.com/axelhaslamx/linux-axel/commits/ti-davinci-ohci-rename
>
>
> Axel Haslam (3):
> ARM: davinci: da8xx: Fix ohci device name
> phy: da8xx-usb: rename the ohci device to ohci-da8xx
> usb: ohci-da8xx: rename driver to ohci-da8xx
>
> arch/arm/mach-davinci/da830.c | 2 +-
> arch/arm/mach-davinci/da850.c | 2 +-
> arch/arm/mach-davinci/da8xx-dt.c | 2 +-
> arch/arm/mach-davinci/usb-da8xx.c | 4 ++--
> drivers/phy/phy-da8xx-usb.c | 5 +++--
> drivers/usb/host/ohci-da8xx.c | 2 +-
> 6 files changed, 9 insertions(+), 8 deletions(-)
>
Thanks for making the changes. The commit messages make better sense to
me now. :-)
^ permalink raw reply
* [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx
From: Kishon Vijay Abraham I @ 2016-11-03 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102124435.31777-3-ahaslam@baylibre.com>
On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
> There is only one ohci on the da8xx series of chips,
> so remove the ".0" when creating the phy. Also add
> the "-da8xx" postfix to be consistent across davinci
> usb drivers.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/phy/phy-da8xx-usb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..c85fb0b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device *pdev)
> } else {
> int ret;
>
> - ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
> + "ohci-da8xx");
> if (ret)
> dev_warn(dev, "Failed to create usb11 phy lookup\n");
> ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
> @@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device *pdev)
>
> if (!pdev->dev.of_node) {
> phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
> - phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
> }
>
> return 0;
>
^ permalink raw reply
* [GIT PULL] iommu/arm-smmu: Fixes for 4.9
From: Robin Murphy @ 2016-11-03 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103162943.GS3541@8bytes.org>
On 03/11/16 16:29, Joerg Roedel wrote:
> On Thu, Nov 03, 2016 at 04:22:04PM +0000, Robin Murphy wrote:
>> But bus_set_iommu() is already checking whether another SMMU (in this
>> case) has probed, by virtue of bus->iommu_ops being non-NULL, and
>> returning without doing anything if so. What's the value of adding a
>> whole bunch more code to effectively duplicate that in a less elegant
>> manner?
>
> No, bus_set_iommu() checks whether there is _any_ other IOMMU already
> registered. This doesn't need to be an smmu. So I think the return value
> of bus_set_iommu shouldn't be generally ignored.
But if it is someone else's ops, then all that means is that the SMMU
driver isn't going to get notified about devices on that bus, or get
called with them later, so I still don't see where the problem is. If
there are devices on that bus which the SMMU *is* supposed to be
managing, then that system can't be supported with the current API anyway.
Robin.
^ permalink raw reply
* [PATCH] ARM: DTS: r8a7794: alt: Fix PCF names for DU
From: Sergei Shtylyov @ 2016-11-03 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478180574-15464-1-git-send-email-jacopo@jmondi.org>
Hello.
On 11/03/2016 04:42 PM, Jacopo Mondi wrote:
> Update the PCF pin groups and function names of DU interface for
PFC maybe?
> r8a7794 ALT board.
>
> The currently specified pin groups and function names prevented PCF and
> DU interfaces from being correctly configured:
>
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> sh-pfc e6060000.pin-controller: function 'du' not supported
> sh-pfc e6060000.pin-controller: invalid function du in map table
> rcar-du: probe of feb00000.display failed with error -22
>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> ---
>
> Patch applied against Simon Horman's renesas/master branch.
> The PCF pin groups and function renaming was introduced by commit 56ed4bb9 and
> DTS for ALT board has never been update accordingly.
We didn't care about Alt at the time, the patch was done in the interests
of the SILK board. I didn't realize the DU pin groups were used for Alt before
the actual support was added for them. Thank you for finally fixing this!
> Tested displaying frames on VGA interface: the rcar-du driver loads correctly.
MBR, Sergei
^ 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