* [PATCH net-next 1/2] drivers: net: xgene: fix: Disable coalescing on v1 hardware
From: Iyappan Subramanian @ 2016-10-31 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477954827-9951-1-git-send-email-isubramanian@apm.com>
Since ethernet v1 hardware has a bug related to coalescing, disabling
this feature.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Toan Le <toanle@apm.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 12 ------------
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 3 ++-
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index c481f10..5390ae8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -204,17 +204,6 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
return num_msgs;
}
-static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
-{
- u32 data = 0x7777;
-
- xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
- xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
- xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
-}
-
void xgene_enet_parse_error(struct xgene_enet_desc_ring *ring,
struct xgene_enet_pdata *pdata,
enum xgene_enet_err_code status)
@@ -929,5 +918,4 @@ struct xgene_ring_ops xgene_ring1_ops = {
.clear = xgene_enet_clear_ring,
.wr_cmd = xgene_enet_wr_cmd,
.len = xgene_enet_ring_len,
- .coalesce = xgene_enet_setup_coalescing,
};
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 3fc7b0d..1352b52 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1188,7 +1188,8 @@ static int xgene_enet_create_desc_rings(struct net_device *ndev)
tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
}
- pdata->ring_ops->coalesce(pdata->tx_ring[0]);
+ if (pdata->ring_ops->coalesce)
+ pdata->ring_ops->coalesce(pdata->tx_ring[0]);
pdata->tx_qcnt_hi = pdata->tx_ring[0]->slots - 128;
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/2] drivers: net: xgene: Fix coalescing bugs
From: Iyappan Subramanian @ 2016-10-31 23:00 UTC (permalink / raw)
To: linux-arm-kernel
This patch set fixes the following,
1. Since ethernet v1 hardware has a bug related to coalescing,
disabling this feature
2. Fixing ethernet v2 hardware, interrupt trigger region
id to 2, to kickoff coalescing
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
---
Iyappan Subramanian (2):
drivers: net: xgene: fix: Disable coalescing on v1 hardware
drivers: net: xgene: fix: Coalescing values for v2 hardware
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 12 ------------
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 2 ++
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 3 ++-
drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c | 12 +++++++-----
4 files changed, 11 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Olof Johansson @ 2016-10-31 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024140622.GM30578@tiger>
Fabio,
I've got multi_v7 booting now, but imx_v6_v7 is still broken on both
hummingboard and wandboard.
Hummingboard doesn't even output anything on serial during boot, bug
with DEBUG_LL I got some more info
(No output boot at
http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3/hummingboard-arm-imx_v6_v7_defconfig.html,
not very useful).
This one seems to be due to CONFIG_PCI_IMX6, which is off on
multi_v7_defconfig. Hard hang(?), last output is:
[ 0.490643] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
[ 0.496540] OF: PCI: No bus range found for /soc/pcie at 0x01000000,
using [bus 00-ff]
[ 0.504512] OF: PCI: IO 0x01f80000..0x01f8ffff -> 0x00000000
[ 0.510559] OF: PCI: MEM 0x01000000..0x01efffff -> 0x01000000
Wandboard, has a peculiar MMC error. First I thought it was just the
card going bad, but now I'm not so sure since multi_v7 boots just fine
on the same hardware:
http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3/wandboard-arm-imx_v6_v7_defconfig.html
Not sure what's going on here, since bisecting between two configs is
a pain. When I disabled CONFIG_PCI, the error seems to be less likely
to happen (some boots succeed, sometimes it happens later during
boot).
-Olof
On Mon, Oct 24, 2016 at 7:06 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.9
>
> for you to fetch changes up to 4edd601c5a9c5094daa714e65063e623826f3bcc:
>
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031 (2016-10-24 21:26:01 +0800)
>
> ----------------------------------------------------------------
> The i.MX fixes for 4.9:
> - A couple of patches from Fabio to fix the GPC power domain regression
> which is caused by PM Domain core change 0159ec670763dd
> ("PM / Domains: Verify the PM domain is present when adding a
> provider"), and a related kernel crash seen with multi_v7_defconfig
> build.
> - Correct the PHY ID mask for AR8031 to match phy driver code.
> - Apply new added timer erratum A008585 for LS1043A and LS2080A SoC.
> - Correct vf610 global timer IRQ flag to avoid warning from gic driver
> after commit 992345a58e0c ("irqchip/gic: WARN if setting the
> interrupt type for a PPI fails").
>
> ----------------------------------------------------------------
> Fabio Estevam (3):
> ARM: imx: gpc: Initialize all power domains
> ARM: imx: gpc: Fix the imx_gpc_genpd_init() error path
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031
>
> Scott Wood (1):
> arm64: dts: Add timer erratum property for LS2080A and LS1043A
>
> Stefan Agner (1):
> ARM: dts: vf610: fix IRQ flag of global timer
>
> arch/arm/boot/dts/vf500.dtsi | 2 +-
> arch/arm/mach-imx/gpc.c | 15 ++++++++++++---
> arch/arm/mach-imx/mach-imx6q.c | 2 +-
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> 5 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Baicar, Tyler @ 2016-10-31 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031100206.GX1041@n2100.armlinux.org.uk>
Hello Russell,
On 10/31/2016 4:02 AM, Russell King - ARM Linux wrote:
> The subject line on this patch is misleading - it's not only ARM64
> specific...
Thank you for the feedback!
I only put ARM64 in the subject line because this patch only really adds
guest SEA support for the ARM64 KVM code. The ARM code had to be edited
since both the ARM and ARM64 KVM code use arch/arm/kvm/mmu.c. I can
change the subject line to "arm/arm64: KVM: add guest SEA support" if
you think that is better.
> On Fri, Oct 21, 2016 at 11:30:13AM -0600, Tyler Baicar wrote:
>> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
>> index a3d61ad..86e1faa 100644
>> --- a/arch/arm/include/asm/system_misc.h
>> +++ b/arch/arm/include/asm/system_misc.h
>> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>>
>> #endif /* !__ASSEMBLY__ */
>>
>> +inline int handle_guest_sea(unsigned long addr, unsigned int esr)
> This needs to be static.
I'll make this static.
Thanks,
Tyler
>> +{
>> + return -1;
>> +}
>> +
>> #endif /* __ASM_ARM_SYSTEM_MISC_H */
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: msm8974: Remove "unused" reserved region
From: Bjorn Andersson @ 2016-10-31 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027232306.13653-1-sboyd@codeaurora.org>
On Thu 27 Oct 16:23 PDT 2016, Stephen Boyd wrote:
> From what I can tell by looking at the android 3.10 kernel
> sources for msm8974, this isn't actually a reserved region.
> Instead it's marked as "unused" for reserved regions. Let's
> remove it so we get back a good chunk of memory.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-msm8974.dtsi | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d136762..5f4752696171 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -58,11 +58,6 @@
> reg = <0x0fd80000 0x180000>;
> no-map;
> };
> -
> - unused at 0ff00000 {
> - reg = <0x0ff00000 0x10100000>;
> - no-map;
> - };
> };
>
> cpus {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: Thor Thayer @ 2016-10-31 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031080222.GM13127@dell>
Hi Lee,
On 10/31/2016 03:02 AM, Lee Jones wrote:
> On Thu, 27 Oct 2016, tthayer at opensource.altera.com wrote:
>
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> Add the Altera Arria10 DevKit System Resource Monitor functionality
>> to the MFD device.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> v2 Change from -mon to -monitor for clarity
>> ---
>> drivers/mfd/altera-a10sr.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
>> index 06e1f7f..30de652 100644
>> --- a/drivers/mfd/altera-a10sr.c
>> +++ b/drivers/mfd/altera-a10sr.c
>> @@ -33,6 +33,10 @@
>> .name = "altr_a10sr_gpio",
>> .of_compatible = "altr,a10sr-gpio",
>> },
>> + {
>> + .name = "altr_a10sr_monitor",
>> + .of_compatible = "altr,a10sr-monitor",
>
> So long as you use whichever compatible you agree on with Rob:
>
> For my own reference:
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>
I'm getting a "Non-standard signature" warning for this (even if I make
everything lower-case).
Would you prefer I submit it with the warning or should I change it to
"Acked-by"?
Thanks for reviewing!
Thor
>> + },
>> };
>>
>> static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Ray Jui @ 2016-10-31 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6ryMbF8kVUYOfhre4qtZp5haa2Shijcv40AXsjL_jZL=JQ@mail.gmail.com>
Hi Rafal,
On 10/31/2016 3:16 PM, Rafa? Mi?ecki wrote:
> On 31 October 2016 at 23:05, Scott Branden <scott.branden@broadcom.com> wrote:
>> On 16-10-31 02:56 PM, Florian Fainelli wrote:
>>> - fixups the aborts in the kernel, look where they come from, by using
>>> some bit of magic, looking at PCIe registers and whatnot (provided that
>>> is even possible), not too hard, but can take a while, and is error prone
>>
>> Option 4 sounds like the proper solution - check the range the abort is due
>> to the PCI device enumeration and only ignore those aborts.
>
> This was already suggested by Arnd:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422873.html
> and Ray was checking some internal datasheets, but I'm afraid he never
> found info on checking if error was caused by PCIe controller.
>
Correct. Based on response from our ASIC team, on Northstar, 1) we
cannot distinguish between various external imprecise aborts; 2) nor can
we use the internal PCIe controller register to disable unsupported
request from being forwarded as APB bus error (and therefore causes the
abort).
All subsequent iProc SoCs can disable this error forwarding from the
iProc PCIe controller.
> Maybe we could think about some BCM5301X API (extra symbol exported by
> arch code) for starting ignoring aborts and stopping that. We could
> ignore aborts during scanning only but honestly it sounds like a bit
> hacky solution to me.
>
>
Correct, one possible solution is to only ignoring the aborts during
condiguration space register access of an endpoint device. Below is the
logic how I only disable the APB bus error forwarding during these
accesses (for all other iProc SoCs):
+/**
+ * APB error forwarding can be disabled during access of configuration
+ * registers of the endpoint device, to prevent unsupported requests
+ * (typically seen during enumeration with multi-function devices) from
+ * triggering a system exception
+ */
+static inline void iproc_pcie_apb_err_disable(struct pci_bus *bus,
+ bool disable)
+{
+ struct iproc_pcie *pcie = iproc_data(bus);
+ u32 val;
+
+ if (bus->number && pcie->has_apb_err_disable) {
+ val = iproc_pcie_read_reg(pcie, IPROC_PCIE_APB_ERR_EN);
+ if (disable)
+ val &= ~APB_ERR_EN;
+ else
+ val |= APB_ERR_EN;
+ iproc_pcie_write_reg(pcie, IPROC_PCIE_APB_ERR_EN, val);
+ }
+}
+
[...]
+static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int
devfn,
+ int where, int size, u32 *val)
+{
+ int ret;
+
+ iproc_pcie_apb_err_disable(bus, true);
+ ret = pci_generic_config_read32(bus, devfn, where, size, val);
+ iproc_pcie_apb_err_disable(bus, false);
+
+ return ret;
+}
+
+static int iproc_pcie_config_write32(struct pci_bus *bus, unsigned int
devfn,
+ int where, int size, u32 val)
+{
+ int ret;
+
+ iproc_pcie_apb_err_disable(bus, true);
+ ret = pci_generic_config_write32(bus, devfn, where, size, val);
+ iproc_pcie_apb_err_disable(bus, false);
+
+ return ret;
+}
+
static struct pci_ops iproc_pcie_ops = {
.map_bus = iproc_pcie_map_cfg_bus,
- .read = pci_generic_config_read32,
- .write = pci_generic_config_write32,
+ .read = iproc_pcie_config_read32,
+ .write = iproc_pcie_config_write32,
};
>>> I can certainly advocate that option 3 is the one that gives a working
>>> device, and this is what matters from a distribution perspective like
>>> LEDE/OpenWrt.
>>>
>> Since I don't use BCM5301x option 3 is fine by me.
>
> So for it seems like the best solution to me, but I'm open for changes
> if someone points another that is clean & better one.
>
I agree with that option 3 is probably the best solution for now, from a
distribution's perspective.
Thanks,
Ray
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Bjorn Andersson @ 2016-10-31 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477473794-26030-1-git-send-email-linus.walleij@linaro.org>
On Wed 26 Oct 02:23 PDT 2016, Linus Walleij wrote:
> This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
> the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
> MPU-3050 and appear as a subdevice beyond it. We set up the
> required GPIO and interrupt lines to make the devices work.
>
I'm concerned about the interrupt below, but apart from that
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Should be fine to apply now: all bindings and requirements are
> merged.
> ChangeLog v1->v2:
> - Use the new I2C mux gate bindings from Peter Rosin (merged to
> the I2C subsystem)
> ---
> arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
[..]
> + mpu3050 at 68 {
> + compatible = "invensense,mpu3050";
> + reg = <0x68>;
> + /*
> + * GPIO17 has interrupt 208 on the
> + * PM8058, it is pulled high by a 10k
> + * resistor to VLOGIC so needs to be
> + * active low/falling edge.
> + */
> + interrupt-parent = <&pm8058_gpio>;
> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
To remove the need of resetting the interrupt-parent in each child you
can use the following form:
interrupts-extended = <&pm8058_gpio 208 IRQ_TYPE_EDGE_FALLING>;
But, if we correct the ssbi gpio driver then this would no longer be
interrupt 208 in this parent, right?. I believe that if you say
<&pmicintc 208 IRQ_TYPE_EDGE_FALLING> instead, which should work even
after we correct the gpio translation.
(Which probably means we need to get that redesigned, before we
introduce to many of these)
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_mpu3050_gpios>;
> + vlogic-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> +
> + /*
> + * The MPU-3050 acts as a hub for the
> + * accelerometer.
> + */
> + i2c-gate {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + kxsd9 at 18 {
> + compatible = "kionix,kxsd9";
> + reg = <0x18>;
> + interrupt-parent = <&tlmm>;
> + interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_kxsd9_gpios>;
> + iovdd-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> + };
> + };
> + };
Regards,
Bjorn
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Rafał Miłecki @ 2016-10-31 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3847db9f-a8e1-b7fe-c2fa-19ea893bae5f@broadcom.com>
On 31 October 2016 at 23:05, Scott Branden <scott.branden@broadcom.com> wrote:
> On 16-10-31 02:56 PM, Florian Fainelli wrote:
>> - fixups the aborts in the kernel, look where they come from, by using
>> some bit of magic, looking at PCIe registers and whatnot (provided that
>> is even possible), not too hard, but can take a while, and is error prone
>
> Option 4 sounds like the proper solution - check the range the abort is due
> to the PCI device enumeration and only ignore those aborts.
This was already suggested by Arnd:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422873.html
and Ray was checking some internal datasheets, but I'm afraid he never
found info on checking if error was caused by PCIe controller.
Maybe we could think about some BCM5301X API (extra symbol exported by
arch code) for starting ignoring aborts and stopping that. We could
ignore aborts during scanning only but honestly it sounds like a bit
hacky solution to me.
>> I can certainly advocate that option 3 is the one that gives a working
>> device, and this is what matters from a distribution perspective like
>> LEDE/OpenWrt.
>>
> Since I don't use BCM5301x option 3 is fine by me.
So for it seems like the best solution to me, but I'm open for changes
if someone points another that is clean & better one.
--
Rafa?
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com>
On 16-10-31 02:56 PM, Florian Fainelli wrote:
> On 10/31/2016 02:46 PM, Scott Branden wrote:
>>
>>
>> On 16-10-31 02:01 PM, Florian Fainelli wrote:
>>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>>>
>>>>
>>>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>>>> Hi Rafal,
>>>>>
>>>>>
>>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>>
>>>>>> Since early BCM5301X days we got abort handler that was removed by
>>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise
>>>>>> abort
>>>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>>>
>>>>>> When probing PCI config space (device enumeration) it is expected to
>>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>>>> Northstar (BCM5301X) one.
>>>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>>>
>>>> I think all the supported northstar devices have a PCIe controller. We
>>>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>>>
>>> Actually, I do see a couple disadvantages if we gate this with
>>> CONFIG_PCI: if this problem shows up irrespective of your kernel
>>> configuration, you want the error handler to clear it, not rely on
>>> CONFIG_PCI to be enabled for the error to go away and also, without an
>>> additional ifdef, additional compiler coverage.
>>>
>> A problem with reintroducing this change is that all imprecise data
>> aborts are ignored, not just PCI. So if you don't actually use PCI in
>> your system and want to debug other aborts you are unable to. I don't
>> know if we care about such situation.
>
> Considering that any abort is pretty much fatal, the options are:
>
> - update the freaking bootloader to a version where there are no such
> aborts generated, not an option on consumer devices, unclear which
> version (if any) fixes that
>
> - fixups the aborts externally, via a boot wrapper, which is going to
> take some time to develop, causes additional burden on the distributors
> to provide instructions/build images on how to do it
I think the abort is already fixed in the kernel now on boot so option 1
and 2 were not needed - and abort handler was removed as detailed by
Rafal in the commit. Only outstanding issue is now this new PCI
enumeration issue.
>
> - fixups the aborts in the kernel, irrespective of where they come from,
> simple and easy
>
> - fixups the aborts in the kernel, look where they come from, by using
> some bit of magic, looking at PCIe registers and whatnot (provided that
> is even possible), not too hard, but can take a while, and is error prone
Option 4 sounds like the proper solution - check the range the abort is
due to the PCI device enumeration and only ignore those aborts.
>
> I can certainly advocate that option 3 is the one that gives a working
> device, and this is what matters from a distribution perspective like
> LEDE/OpenWrt.
>
Since I don't use BCM5301x option 3 is fine by me.
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Rafał Miłecki @ 2016-10-31 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com>
On 31 October 2016 at 22:56, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/31/2016 02:46 PM, Scott Branden wrote:
>> A problem with reintroducing this change is that all imprecise data
>> aborts are ignored, not just PCI. So if you don't actually use PCI in
>> your system and want to debug other aborts you are unable to. I don't
>> know if we care about such situation.
>
> Considering that any abort is pretty much fatal, the options are:
>
> - update the freaking bootloader to a version where there are no such
> aborts generated, not an option on consumer devices, unclear which
> version (if any) fixes that
>
> - fixups the aborts externally, via a boot wrapper, which is going to
> take some time to develop, causes additional burden on the distributors
> to provide instructions/build images on how to do it
In practice updating bootloader is not possible (as you noticed) but I
don't think it's even possible to fix this problem at bootloader /
extra loader level. If this was a matter of hardware setup, we could
handle it in kernel as well I believe. Ray actually verified it's
controller limitation on Northstar platform.
It sounds a bit like you're thinking about MMU and Dcache Northstar
problem when writing that e-mail.
> - fixups the aborts in the kernel, irrespective of where they come from,
> simple and easy
>
> - fixups the aborts in the kernel, look where they come from, by using
> some bit of magic, looking at PCIe registers and whatnot (provided that
> is even possible), not too hard, but can take a while, and is error prone
>
> I can certainly advocate that option 3 is the one that gives a working
> device, and this is what matters from a distribution perspective like
> LEDE/OpenWrt.
--
Rafa?
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dcb21fe4-672f-4545-5b47-d764f390e741@broadcom.com>
On 10/31/2016 02:46 PM, Scott Branden wrote:
>
>
> On 16-10-31 02:01 PM, Florian Fainelli wrote:
>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>>
>>>
>>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>>> Hi Rafal,
>>>>
>>>>
>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>
>>>>> Since early BCM5301X days we got abort handler that was removed by
>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise
>>>>> abort
>>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>>
>>>>> When probing PCI config space (device enumeration) it is expected to
>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>>> Northstar (BCM5301X) one.
>>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>>
>>> I think all the supported northstar devices have a PCIe controller. We
>>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>>
>> Actually, I do see a couple disadvantages if we gate this with
>> CONFIG_PCI: if this problem shows up irrespective of your kernel
>> configuration, you want the error handler to clear it, not rely on
>> CONFIG_PCI to be enabled for the error to go away and also, without an
>> additional ifdef, additional compiler coverage.
>>
> A problem with reintroducing this change is that all imprecise data
> aborts are ignored, not just PCI. So if you don't actually use PCI in
> your system and want to debug other aborts you are unable to. I don't
> know if we care about such situation.
Considering that any abort is pretty much fatal, the options are:
- update the freaking bootloader to a version where there are no such
aborts generated, not an option on consumer devices, unclear which
version (if any) fixes that
- fixups the aborts externally, via a boot wrapper, which is going to
take some time to develop, causes additional burden on the distributors
to provide instructions/build images on how to do it
- fixups the aborts in the kernel, irrespective of where they come from,
simple and easy
- fixups the aborts in the kernel, look where they come from, by using
some bit of magic, looking at PCIe registers and whatnot (provided that
is even possible), not too hard, but can take a while, and is error prone
I can certainly advocate that option 3 is the one that gives a working
device, and this is what matters from a distribution perspective like
LEDE/OpenWrt.
--
Florian
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Bjorn Helgaas @ 2016-10-31 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921223805.21652-1-cov@codeaurora.org>
On Wed, Sep 21, 2016 at 06:38:05PM -0400, Christopher Covington wrote:
> The Qualcomm Technologies QDF2432 SoC does not support accesses smaller
> than 32 bits to the PCI configuration space. Register the appropriate
> quirk.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
Hi Christopher,
Can you rebase this against v4.9-rc1? It no longer applies to my tree.
Note that this hardware is not spec-compliant since it doesn't support
sub-32 bit config writes. I just proposed a patch to warn about that
[1], so if/when we merge that patch and this one, you'll start seeing
those warnings.
[1] http://lkml.kernel.org/r/20161031213902.6340.96123.stgit at bhelgaas-glaptop.roam.corp.google.com
> ---
> drivers/acpi/pci_mcfg.c | 8 ++++++++
> drivers/pci/ecam.c | 10 ++++++++++
> include/linux/pci-ecam.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 245b79f..212334f 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -96,6 +96,14 @@ static struct mcfg_fixup mcfg_quirks[] = {
> THUNDER_ECAM_MCFG(2, 12),
> THUNDER_ECAM_MCFG(2, 13),
> #endif
> + { "QCOM ", "QDF2432 ", 1, 0, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 1, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 2, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 3, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 4, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> };
>
> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
> index 43ed08d..c3b3063 100644
> --- a/drivers/pci/ecam.c
> +++ b/drivers/pci/ecam.c
> @@ -162,3 +162,13 @@ struct pci_ecam_ops pci_generic_ecam_ops = {
> .write = pci_generic_config_write,
> }
> };
> +
> +/* ops for 32 bit config space access quirk */
> +struct pci_ecam_ops pci_32b_ops = {
> + .bus_shift = 20,
> + .pci_ops = {
> + .map_bus = pci_ecam_map_bus,
> + .read = pci_generic_config_read32,
> + .write = pci_generic_config_write32,
> + }
> +};
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index 35f0e81..a6cffb8 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -65,6 +65,7 @@ extern struct pci_ecam_ops pci_thunder_pem_ops;
> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> extern struct pci_ecam_ops pci_thunder_ecam_ops;
> #endif
> +extern struct pci_ecam_ops pci_32b_ops;
>
> #ifdef CONFIG_PCI_HOST_GENERIC
> /* for DT-based PCI controllers that support ECAM */
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
> Forum, a Linux Foundation Collaborative Project.
>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb2c36cb-6f85-1a6d-160a-c50e22d6c46b@gmail.com>
On 16-10-31 02:01 PM, Florian Fainelli wrote:
> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>
>>
>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>> Hi Rafal,
>>>
>>>
>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>
>>>> Since early BCM5301X days we got abort handler that was removed by
>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>
>>>> When probing PCI config space (device enumeration) it is expected to
>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>> Northstar (BCM5301X) one.
>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>
>> I think all the supported northstar devices have a PCIe controller. We
>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>
> Actually, I do see a couple disadvantages if we gate this with
> CONFIG_PCI: if this problem shows up irrespective of your kernel
> configuration, you want the error handler to clear it, not rely on
> CONFIG_PCI to be enabled for the error to go away and also, without an
> additional ifdef, additional compiler coverage.
>
A problem with reintroducing this change is that all imprecise data
aborts are ignored, not just PCI. So if you don't actually use PCI in
your system and want to debug other aborts you are unable to. I don't
know if we care about such situation.
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-10-31 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ_EiSRzmQHLP2PTfzsLF4uWgYgCiRGsSk=MHbtOC5rgXnnFpw@mail.gmail.com>
On Mon 2016-10-31 13:22:18, Matt Ranostay wrote:
> On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay <mranostay@gmail.com> wrote:
> > On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
> >>> Pavel + Sebastian this is the patchset that need I some input on :)
> >>
> >> Better then previous one.
> >>
> >> But my version of bq27xxx_battery.c already contains this:
> >
> > This is for allowing udev rule to set the properties as well.
> > otherwise a kinda crude RUN = " echo value >
> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> Any thoughts on this?
I'd say echo value >
/sys/module/bq27xxx_battery/parameters/poll_interval .. is quite
adequate solution...?
Alternatively, convince us that something else is useful for everyone,
and we can do the right thing (poll more often when battery is nearly
empty), automatically...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/bb28809e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: mediatek: clean up mach-mediatek/Makefile
From: Matthias Brugger @ 2016-10-31 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQbaQ38RZqgmJJW+BHOthrK5tPZ5JPPh9N9ry58YZ=kdg@mail.gmail.com>
On 10/31/2016 07:15 AM, Masahiro Yamada wrote:
> Hi Matthias,
>
>
> Can you pick up this for your next pull request?
>
Sure, pushed to v4.9-next/kconfig
Next time please don't forget to send your patches to the mediatek
mailinglist:
linux-mediatek at lists.infradead.org
This makes it easier for me to track the patches.
Thanks,
Matthias
>
>
> 2016-09-19 3:11 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> Kbuild descends into arch/arm/mach-mediatek/Makefile only when
>> CONFIG_ARCH_MEDIATEK is enabled. So, obj-$(CONFIG_ARCH_MEDIATEK)
>> is always equivalent to obj-y in this Makefile.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> arch/arm/mach-mediatek/Makefile | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
>> index 2116460..dadae67 100644
>> --- a/arch/arm/mach-mediatek/Makefile
>> +++ b/arch/arm/mach-mediatek/Makefile
>> @@ -1,4 +1,2 @@
>> -ifeq ($(CONFIG_SMP),y)
>> -obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
>> -endif
>> -obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
>> +obj-$(CONFIG_SMP) += platsmp.o
>> +obj-y += mediatek.o
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
^ permalink raw reply
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eric Anholt @ 2016-10-31 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477363675.2298.2.camel@intel.com>
Zhang Rui <rui.zhang@intel.com> writes:
> On Mon, 2016-10-24 at 20:25 +0200, Stefan Wahren wrote:
>> >
>> > Eric Anholt <eric@anholt.net> hat am 24. Oktober 2016 um 18:38
>> > geschrieben:
>> >
>> >
>> > Stefan Wahren <stefan.wahren@i2se.com> writes:
>> >
>> > >
>> > > Hi Martin,
>> > >
>> > > Am 28.09.2016 um 23:10 schrieb Eric Anholt:
>> > > >
>> > > > kernel at martin.sperl.org writes:
>> > > >
>> > > > >
>> > > > > 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>
>> > > > What's the status of merging this one???I'd like to merge the
>> > > > other
>> > > > patches.
>> > > i think it's necessary to rebase the whole series. Maybe we could
>> > > get it
>> > > into 4.10.
>> > Why would it need to be rebased???The status, as far as I know, is
>> > that
>> > we're still waiting for the subsystem maintainer to respond.
>> Since at least this patch won't apply anymore, but feedback from
>> maintainer is
>> still good :-)
>>
>> Sorry for this impatience, but i'm afraid that we possibly miss 4.10.
>
> Eduardo,
>
> any comments on this patchset?
It's been a month on v7 of this patch. Can we please merge it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/4847b7b1/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Dave Gerlach @ 2016-10-31 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028040507.GJ10423@vireshk-i7>
On 10/27/2016 11:05 PM, Viresh Kumar wrote:
> On 27-10-16, 16:41, Dave Gerlach wrote:
>> Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
>> dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
>> OPP and cpufreq drivers, to make use of it.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> drivers/base/power/opp/of.c | 8 ++++----
>> drivers/base/power/opp/opp.h | 1 -
>> include/linux/pm_opp.h | 6 ++++++
>> 3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
>> index 5552211e6fcd..215f5a538c78 100644
>> --- a/drivers/base/power/opp/of.c
>> +++ b/drivers/base/power/opp/of.c
>> @@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
>> EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>>
>> /* Returns opp descriptor node for a device, caller must do of_node_put() */
>> -struct device_node *_of_get_opp_desc_node(struct device *dev)
>> +struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
>
> Export as well ?
>
Whoops, yes will need to do that. I'll give some time for comments on
any other patches before sending v3.
Thanks,
Dave
^ permalink raw reply
* [PATCH v2] staging: vc04_services: setup DMA and coherent mask
From: Michael Zoran @ 2016-10-31 21:02 UTC (permalink / raw)
To: linux-arm-kernel
VCHI messages between the CPU and firmware use 32-bit
bus addresses. Explicitly set the DMA mask and coherent
on all platforms.
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index a5afcc5..ba77fd8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -97,6 +97,15 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
int slot_mem_size, frag_mem_size;
int err, irq, i;
+ /*
+ * VCHI messages between the CPU and firmware use
+ * 32-bit bus addresses.
+ */
+ err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+
+ if (err < 0)
+ return err;
+
(void)of_property_read_u32(dev->of_node, "cache-line-size",
&g_cache_line_size);
g_fragments_size = 2 * g_cache_line_size;
--
2.10.1
^ permalink raw reply related
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e252703-0010-83ae-fa14-57352add007a@hauke-m.de>
On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>
>
> On 10/31/2016 07:08 PM, Scott Branden wrote:
>> Hi Rafal,
>>
>>
>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> Since early BCM5301X days we got abort handler that was removed by
>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>> fault handler"). It assumed we need to deal only with pending aborts
>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>
>>> When probing PCI config space (device enumeration) it is expected to
>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>> Northstar (BCM5301X) one.
>> Should we only add this workaround code if CONFIG_PCI is on then?
>
> I think all the supported northstar devices have a PCIe controller. We
> could add such a CONFIG_PCI check, but I do not see a big advantage.
Actually, I do see a couple disadvantages if we gate this with
CONFIG_PCI: if this problem shows up irrespective of your kernel
configuration, you want the error handler to clear it, not rely on
CONFIG_PCI to be enabled for the error to go away and also, without an
additional ifdef, additional compiler coverage.
--
Florian
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Hauke Mehrtens @ 2016-10-31 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a491509e-5cfc-fc7d-0011-dfcab3c884ea@broadcom.com>
On 10/31/2016 07:08 PM, Scott Branden wrote:
> Hi Rafal,
>
>
> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> Since early BCM5301X days we got abort handler that was removed by
>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>> fault handler"). It assumed we need to deal only with pending aborts
>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>
>> When probing PCI config space (device enumeration) it is expected to
>> have master aborts on the PCI bus. Most bridges don't forward (or they
>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>> Northstar (BCM5301X) one.
> Should we only add this workaround code if CONFIG_PCI is on then?
I think all the supported northstar devices have a PCIe controller. We
could add such a CONFIG_PCI check, but I do not see a big advantage.
>> iProc PCIe controller on Northstar seems to be some older one, without
>> a control register for errors forwarding. It means we need to workaround
>> this at platform level. All newer platforms are not affected by this
>> issue.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>> arch/arm/mach-bcm/bcm_5301x.c | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm/bcm_5301x.c
>> b/arch/arm/mach-bcm/bcm_5301x.c
>> index c8830a2..fe067f6 100644
>> --- a/arch/arm/mach-bcm/bcm_5301x.c
>> +++ b/arch/arm/mach-bcm/bcm_5301x.c
>> @@ -9,14 +9,42 @@
>> #include <asm/hardware/cache-l2x0.h>
>>
>> #include <asm/mach/arch.h>
>> +#include <asm/siginfo.h>
>> +#include <asm/signal.h>
>> +
>> +#define FSR_EXTERNAL (1 << 12)
>> +#define FSR_READ (0 << 10)
>> +#define FSR_IMPRECISE 0x0406
>>
>> static const char *const bcm5301x_dt_compat[] __initconst = {
>> "brcm,bcm4708",
>> NULL,
>> };
>>
>> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
>> + struct pt_regs *regs)
>> +{
>> + /*
>> + * We want to ignore aborts forwarded from the PCIe bus that are
>> + * expected and shouldn't really be passed by the PCIe controller.
>> + * The biggest disadvantage is the same FSR code may be reported
>> when
>> + * reading non-existing APB register and we shouldn't ignore that.
>> + */
>> + if (fsr == (FSR_EXTERNAL | FSR_READ | FSR_IMPRECISE))
>> + return 0;
How often does this happen? Would it be useful to add a log message here?
>> +
>> + return 1;
>> +}
>> +
>> +static void __init bcm5301x_init_early(void)
>> +{
>> + hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
>> + "imprecise external abort");
>> +}
>> +
>> DT_MACHINE_START(BCM5301X, "BCM5301X")
>> .l2c_aux_val = 0,
>> .l2c_aux_mask = ~0,
>> .dt_compat = bcm5301x_dt_compat,
>> + .init_early = bcm5301x_init_early,
>> MACHINE_END
>>
>
> Regards,
> Scott
^ permalink raw reply
* [PATCH v8 3/3] ARM: davinci: da8xx: register USB PHY clocks in the DT file
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
From: Axel Haslam <ahaslam@baylibre.com>
The usb20_phy clock needs to be registered for the driver to be able
to get and enable a clock. Currently the usb phy clocks are registered
form board files, which will not be called during a device tree based
boot.
To be able to probe correctly usb form a device tree boot, register
the usb phy clocks form the DT specific init.
Unfourtunatly, davinci does not have proper clock support on device tree
yet, so by registering the clock form de DT specific file we are
forced to hardcode the parent clock, and cannot select refclkin as
parent for any of the phy clocks of the da850 family.
As none of the current da850 based boards currently in mainline use
refclkin as source. I guess we can live with this limitation until clocks
are correctly represented through CCF/device tree.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
[Added error checking]
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 20fa842..230c151 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -49,6 +49,17 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
+ int ret;
+
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: registering USB 2.0 PHY clock failed: %d",
+ __func__, ret);
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
+ __func__, ret);
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v8 2/3] ARM: davinci: da8xx: add usb phy clocks
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replaced with the new clock registration functions.
This also removes the #if IS_ENABLED(CONFIG_USB_MUSB_HDRC) around the musb
declaration and renames the musb platform device so that we can reference
it from the usb20 clock even if the musb device is not used.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 31 +---
arch/arm/mach-davinci/board-omapl138-hawk.c | 15 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
arch/arm/mach-davinci/usb-da8xx.c | 267 ++++++++++++++++++++++++++--
4 files changed, 274 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 53172ad..5db0901 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -18,7 +18,6 @@
#include <linux/i2c.h>
#include <linux/i2c/pcf857x.h>
#include <linux/platform_data/at24.h>
-#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -108,30 +107,18 @@ static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
static __init void da830_evm_usb_init(void)
{
- u32 cfgchip2;
int ret;
- /*
- * Set up USB clock in the CFGCHIP2 register.
- * FYI: CFGCHIP2 is 0x0000ef00 initially.
- */
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
- /* USB2.0 PHY reference clock is 24 MHz */
- cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
-
- /*
- * Select internal reference clock for USB 2.0 PHY
- * and use it as a clock source for USB 1.1 PHY
- * (this is the default setting anyway).
- */
- cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
- cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
-
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
/* USB_REFCLKIN is not used. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
+
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
ret = da8xx_register_usb_phy();
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 67477ca..a4e8726 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,7 +13,6 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/gpio.h>
-#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/regulator/machine.h>
@@ -245,7 +244,6 @@ static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
static __init void omapl138_hawk_usb_init(void)
{
int ret;
- u32 cfgchip2;
ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
if (ret) {
@@ -253,12 +251,15 @@ static __init void omapl138_hawk_usb_init(void)
return;
}
- /* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
ret = da8xx_register_usb_phy();
if (ret)
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 5e07d06..43322be 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -92,6 +92,9 @@ int da8xx_register_watchdog(void);
int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
+int da8xx_register_usb_refclkin(int rate);
+int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
+int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
int da8xx_register_emac(void);
int da8xx_register_uio_pruss(void);
int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index 4bb1903..b010e5f 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -1,24 +1,38 @@
/*
* DA8xx USB
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/init.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/phy/phy.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_device.h>
#include <linux/usb/musb.h>
+#include <mach/clock.h>
#include <mach/common.h>
#include <mach/cputype.h>
#include <mach/da8xx.h>
#include <mach/irqs.h>
+#include "clock.h"
+
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
.id = -1,
+ .dev = {
+ /*
+ * Setting init_name so that clock lookup will work in
+ * da8xx_register_usb11_phy_clk() even if this device is not
+ * registered yet.
+ */
+ .init_name = "da8xx-usb-phy",
+ },
};
int __init da8xx_register_usb_phy(void)
@@ -26,8 +40,6 @@ int __init da8xx_register_usb_phy(void)
return platform_device_register(&da8xx_usb_phy);
}
-#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
-
static struct musb_hdrc_config musb_config = {
.multipoint = true,
.num_eps = 5,
@@ -56,10 +68,15 @@ static struct resource da8xx_usb20_resources[] = {
static u64 usb_dmamask = DMA_BIT_MASK(32);
-static struct platform_device usb_dev = {
+static struct platform_device da8xx_usb20_dev = {
.name = "musb-da8xx",
.id = -1,
.dev = {
+ /*
+ * Setting init_name so that clock lookup will work in
+ * usb20_phy_clk_enable() even if this device is not registered.
+ */
+ .init_name = "musb-da8xx",
.platform_data = &usb_data,
.dma_mask = &usb_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
@@ -73,18 +90,9 @@ int __init da8xx_register_usb20(unsigned int mA, unsigned int potpgt)
usb_data.power = mA > 510 ? 255 : mA / 2;
usb_data.potpgt = (potpgt + 1) / 2;
- return platform_device_register(&usb_dev);
-}
-
-#else
-
-int __init da8xx_register_usb20(unsigned int mA, unsigned int potpgt)
-{
- return 0;
+ return platform_device_register(&da8xx_usb20_dev);
}
-#endif /* CONFIG_USB_MUSB_HDRC */
-
static struct resource da8xx_usb11_resources[] = {
[0] = {
.start = DA8XX_USB1_BASE,
@@ -116,3 +124,236 @@ int __init da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata)
da8xx_usb11_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_usb11_device);
}
+
+static struct clk usb_refclkin = {
+ .name = "usb_refclkin",
+ .set_rate = davinci_simple_set_rate,
+};
+
+static struct clk_lookup usb_refclkin_lookup =
+ CLK(NULL, "usb_refclkin", &usb_refclkin);
+
+/**
+ * da8xx_register_usb_refclkin - register USB_REFCLKIN clock
+ *
+ * @rate: The clock rate in Hz
+ *
+ * This clock is only needed if the board provides an external USB_REFCLKIN
+ * signal, in which case it will be used as the parent of usb20_phy_clk and/or
+ * usb11_phy_clk.
+ */
+int __init da8xx_register_usb_refclkin(int rate)
+{
+ int ret;
+
+ usb_refclkin.rate = rate;
+ ret = clk_register(&usb_refclkin);
+ if (ret)
+ return ret;
+
+ clkdev_add(&usb_refclkin_lookup);
+
+ return 0;
+}
+
+static void usb20_phy_clk_enable(struct clk *clk)
+{
+ struct clk *usb20_clk;
+ int err;
+ u32 val;
+ u32 timeout = 500000; /* 500 msec */
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
+ if (IS_ERR(usb20_clk)) {
+ pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
+ return;
+ }
+
+ /* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
+ err = clk_prepare_enable(usb20_clk);
+ if (err) {
+ pr_err("failed to enable usb20 clk: %d\n", err);
+ clk_put(usb20_clk);
+ return;
+ }
+
+ /*
+ * Turn on the USB 2.0 PHY, but just the PLL, and not OTG. The USB 1.1
+ * host may use the PLL clock without USB 2.0 OTG being used.
+ */
+ val &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
+ val |= CFGCHIP2_PHY_PLLON;
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ while (--timeout) {
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ if (val & CFGCHIP2_PHYCLKGD)
+ goto done;
+ udelay(1);
+ }
+
+ pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
+done:
+ clk_disable_unprepare(usb20_clk);
+ clk_put(usb20_clk);
+}
+
+static void usb20_phy_clk_disable(struct clk *clk)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ val |= CFGCHIP2_PHYPWRDN;
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+}
+
+static int usb20_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the mux depending on the parent clock. */
+ if (parent == &usb_refclkin) {
+ val &= ~CFGCHIP2_USB2PHYCLKMUX;
+ } else if (strcmp(parent->name, "pll0_aux_clk") == 0) {
+ val |= CFGCHIP2_USB2PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 2.0 PHY clock\n");
+ return -EINVAL;
+ }
+
+ /* reference frequency also comes from parent clock */
+ val &= ~CFGCHIP2_REFFREQ_MASK;
+ switch (clk_get_rate(parent)) {
+ case 12000000:
+ val |= CFGCHIP2_REFFREQ_12MHZ;
+ break;
+ case 13000000:
+ val |= CFGCHIP2_REFFREQ_13MHZ;
+ break;
+ case 19200000:
+ val |= CFGCHIP2_REFFREQ_19_2MHZ;
+ break;
+ case 20000000:
+ val |= CFGCHIP2_REFFREQ_20MHZ;
+ break;
+ case 24000000:
+ val |= CFGCHIP2_REFFREQ_24MHZ;
+ break;
+ case 26000000:
+ val |= CFGCHIP2_REFFREQ_26MHZ;
+ break;
+ case 38400000:
+ val |= CFGCHIP2_REFFREQ_38_4MHZ;
+ break;
+ case 40000000:
+ val |= CFGCHIP2_REFFREQ_40MHZ;
+ break;
+ case 48000000:
+ val |= CFGCHIP2_REFFREQ_48MHZ;
+ break;
+ default:
+ pr_err("Bad parent clock rate on USB 2.0 PHY clock\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb20_phy_clk = {
+ .name = "usb20_phy",
+ .clk_enable = usb20_phy_clk_enable,
+ .clk_disable = usb20_phy_clk_disable,
+ .set_parent = usb20_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb20_phy_clk_lookup =
+ CLK("da8xx-usb-phy", "usb20_phy", &usb20_phy_clk);
+
+/**
+ * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "pll0_aux" if false.
+ */
+int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb20_phy_clk.parent = parent;
+ ret = clk_register(&usb20_phy_clk);
+ if (!ret)
+ clkdev_add(&usb20_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
+
+static int usb11_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the USB 1.1 PHY clock mux based on the parent clock. */
+ if (parent == &usb20_phy_clk) {
+ val &= ~CFGCHIP2_USB1PHYCLKMUX;
+ } else if (parent == &usb_refclkin) {
+ val |= CFGCHIP2_USB1PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 1.1 PHY clock\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb11_phy_clk = {
+ .name = "usb11_phy",
+ .set_parent = usb11_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb11_phy_clk_lookup =
+ CLK("da8xx-usb-phy", "usb11_phy", &usb11_phy_clk);
+
+/**
+ * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "usb20_phy" if false.
+ */
+int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ if (use_usb_refclkin)
+ parent = clk_get(NULL, "usb_refclkin");
+ else
+ parent = clk_get(&da8xx_usb_phy.dev, "usb20_phy");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb11_phy_clk.parent = parent;
+ ret = clk_register(&usb11_phy_clk);
+ if (!ret)
+ clkdev_add(&usb11_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
--
2.7.4
^ permalink raw reply related
* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
for the USB PHY that is part of this range of registers.
Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
the the USB PHY driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
arch/arm/mach-davinci/da8xx-dt.c | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4c83613..2534aab 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -209,6 +209,16 @@
};
};
+ cfgchip: chip-controller at 1417c {
+ compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+ reg = <0x1417c 0x14>;
+
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ };
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index aec569f9..20fa842 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
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-musb", 0x01e00000, "musb-da8xx", NULL),
+ OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH v8 0/3] da8xx USB PHY platform devices and clocks
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
I reworked the "[PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node" and
"[PATCH v6 5/5] ARM: DTS: da850: Add usb phy node" patches that were dropped
from linux-davinci into the new "ARM: dts: da850: Add cfgchip syscon node"
patch. This should be OK unless it is decided that the BayLibre guys should
rework it so that the entire SYSCFG0 is a single syscon device. I don't see
any compelling reason to do that though.
v8 changes:
* Dropped v7 patches that have been accepted into linux-davinci already
* New patch for CFGCHIP syscon/USB PHY DT node
* Rebased other patches
v7 changes:
* Dropped v6 patches that have been accepted into linux-davinci already
* New patch for adding device names to clock lookup tables
* Picked up related patch from Axel Haslam for registering USB PHY clocks on
device tree boards and added error checking to to that patch
* Rebased on latest linux-davinci + linux-next
* Added devices instead of NULL in clk_get() where appropriate usb-da8xx.c
* Re-ordered patches so that they apply/build cleanly
v6 changes:
* Combine "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from the "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx" series with
the "ARM: davinci: da8xx: add usb phy clocks" patch in this series.
* Change the syscon and da8xx-usb-phy device ids to -1.
v5 changes: renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate
v4 changes: fix strict checkpatch complaint
v3 changes:
* Fixed the davinci device tree declarations to use the preferred DT address
convention so that the items I have added can be correct too.
* Moved that davinci clock init so that we don't have to call ioremap in the
clock mux functions.
* Added a new "syscon" device for the CFGCHIP registers. This is used by the
USB PHY driver and will be used in the future in common clock framework
drivers.
* USB clocks are moved to a common file instead of having duplicated code.
* PHY driver uses syscon for CFGCHIP registers instead of using them directly.
Axel Haslam (1):
ARM: davinci: da8xx: register USB PHY clocks in the DT file
David Lechner (2):
ARM: dts: da850: Add cfgchip syscon node
ARM: davinci: da8xx: add usb phy clocks
arch/arm/boot/dts/da850.dtsi | 10 ++
arch/arm/mach-davinci/board-da830-evm.c | 31 +---
arch/arm/mach-davinci/board-omapl138-hawk.c | 15 +-
arch/arm/mach-davinci/da8xx-dt.c | 12 ++
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
arch/arm/mach-davinci/usb-da8xx.c | 267 ++++++++++++++++++++++++++--
6 files changed, 296 insertions(+), 42 deletions(-)
--
2.7.4
^ 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