* [PATCH v3 4/6] usb: phy: qcom-8x16-usb: Replace the extcon API
From: Chanwoo Choi @ 2017-01-16 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484570222-30522-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c b/drivers/usb/phy/phy-qcom-8x16-usb.c
index d8593adb3621..fdf686398772 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -187,7 +187,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
- state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB);
+ state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -316,23 +316,20 @@ static int phy_8x16_probe(struct platform_device *pdev)
goto off_clks;
qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
- ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
+ ret = devm_extcon_register_notifier(&pdev->dev, qphy->vbus_edev,
+ EXTCON_USB, &qphy->vbus_notify);
if (ret < 0)
goto off_power;
ret = usb_add_phy_dev(&qphy->phy);
if (ret)
- goto off_extcon;
+ goto off_power;
qphy->reboot_notify.notifier_call = phy_8x16_reboot_notify;
register_reboot_notifier(&qphy->reboot_notify);
return 0;
-off_extcon:
- extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
off_power:
regulator_bulk_disable(ARRAY_SIZE(qphy->regulator), qphy->regulator);
off_clks:
@@ -347,8 +344,6 @@ static int phy_8x16_remove(struct platform_device *pdev)
struct phy_8x16 *qphy = platform_get_drvdata(pdev);
unregister_reboot_notifier(&qphy->reboot_notify);
- extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
/*
* Ensure that D+/D- lines are routed to uB connector, so
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/6] usb: phy: omap-otg: Replace the extcon API
From: Chanwoo Choi @ 2017-01-16 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484570222-30522-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Cc: linux-omap at vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/phy/phy-omap-otg.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 6523af4f8f93..800d1d90753d 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -118,19 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
- ret = extcon_register_notifier(extcon, EXTCON_USB_HOST, &otg_dev->id_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB_HOST, &otg_dev->id_nb);
if (ret)
return ret;
- ret = extcon_register_notifier(extcon, EXTCON_USB, &otg_dev->vbus_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB, &otg_dev->vbus_nb);
if (ret) {
- extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
- &otg_dev->id_nb);
return ret;
}
- otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
- otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
+ otg_dev->id = extcon_get_state(extcon, EXTCON_USB_HOST);
+ otg_dev->vbus = extcon_get_state(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
rev = readl(otg_dev->base);
@@ -145,20 +145,8 @@ static int omap_otg_probe(struct platform_device *pdev)
return 0;
}
-static int omap_otg_remove(struct platform_device *pdev)
-{
- struct otg_device *otg_dev = platform_get_drvdata(pdev);
- struct extcon_dev *edev = otg_dev->extcon;
-
- extcon_unregister_notifier(edev, EXTCON_USB_HOST, &otg_dev->id_nb);
- extcon_unregister_notifier(edev, EXTCON_USB, &otg_dev->vbus_nb);
-
- return 0;
-}
-
static struct platform_driver omap_otg_driver = {
.probe = omap_otg_probe,
- .remove = omap_otg_remove,
.driver = {
.name = "omap_otg",
},
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/6] usb: phy: msm: Replace the extcon API
From: Chanwoo Choi @ 2017-01-16 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484570222-30522-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/phy/phy-msm-usb.c | 33 +++++++++++----------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8a34759727bb..a15a89d4235d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1742,14 +1742,14 @@ static int msm_otg_read_dt(struct platform_device *pdev, struct msm_otg *motg)
if (!IS_ERR(ext_vbus)) {
motg->vbus.extcon = ext_vbus;
motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
- ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
- &motg->vbus.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, ext_vbus,
+ EXTCON_USB, &motg->vbus.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register VBUS notifier failed\n");
return ret;
}
- ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
+ ret = extcon_get_state(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, &motg->inputs);
else
@@ -1759,16 +1759,14 @@ static int msm_otg_read_dt(struct platform_device *pdev, struct msm_otg *motg)
if (!IS_ERR(ext_id)) {
motg->id.extcon = ext_id;
motg->id.nb.notifier_call = msm_otg_id_notifier;
- ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
- &motg->id.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, ext_id,
+ EXTCON_USB_HOST, &motg->id.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register ID notifier failed\n");
- extcon_unregister_notifier(motg->vbus.extcon,
- EXTCON_USB, &motg->vbus.nb);
return ret;
}
- ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
+ ret = extcon_get_state(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, &motg->inputs);
else
@@ -1883,10 +1881,9 @@ static int msm_otg_probe(struct platform_device *pdev)
*/
if (motg->phy_number) {
phy_select = devm_ioremap_nocache(&pdev->dev, USB2_PHY_SEL, 4);
- if (!phy_select) {
- ret = -ENOMEM;
- goto unregister_extcon;
- }
+ if (!phy_select)
+ return -ENOMEM;
+
/* Enable second PHY with the OTG port */
writel(0x1, phy_select);
}
@@ -1897,7 +1894,7 @@ static int msm_otg_probe(struct platform_device *pdev)
if (motg->irq < 0) {
dev_err(&pdev->dev, "platform_get_irq failed\n");
ret = motg->irq;
- goto unregister_extcon;
+ return motg->irq;
}
regs[0].supply = "vddcx";
@@ -1906,7 +1903,7 @@ static int msm_otg_probe(struct platform_device *pdev)
ret = devm_regulator_bulk_get(motg->phy.dev, ARRAY_SIZE(regs), regs);
if (ret)
- goto unregister_extcon;
+ return ret;
motg->vddcx = regs[0].consumer;
motg->v3p3 = regs[1].consumer;
@@ -2003,11 +2000,6 @@ static int msm_otg_probe(struct platform_device *pdev)
clk_disable_unprepare(motg->clk);
if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
-unregister_extcon:
- extcon_unregister_notifier(motg->id.extcon,
- EXTCON_USB_HOST, &motg->id.nb);
- extcon_unregister_notifier(motg->vbus.extcon,
- EXTCON_USB, &motg->vbus.nb);
return ret;
}
@@ -2029,9 +2021,6 @@ static int msm_otg_remove(struct platform_device *pdev)
*/
gpiod_set_value_cansleep(motg->switch_gpio, 0);
- extcon_unregister_notifier(motg->id.extcon, EXTCON_USB_HOST, &motg->id.nb);
- extcon_unregister_notifier(motg->vbus.extcon, EXTCON_USB, &motg->vbus.nb);
-
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(&motg->chg_work);
cancel_work_sync(&motg->sm_work);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/6] usb: dwc3: omap: Replace the extcon API
From: Chanwoo Choi @ 2017-01-16 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484570222-30522-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Cc: linux-omap at vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/dwc3/dwc3-omap.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index eb1b9cb3f9d1..2092e46b1380 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -426,20 +426,20 @@ static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
}
omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
- ret = extcon_register_notifier(edev, EXTCON_USB,
- &omap->vbus_nb);
+ ret = devm_extcon_register_notifier(omap->dev, edev,
+ EXTCON_USB, &omap->vbus_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for USB\n");
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
- ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
- &omap->id_nb);
+ ret = devm_extcon_register_notifier(omap->dev, edev,
+ EXTCON_USB_HOST, &omap->id_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for USB-HOST\n");
- if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
+ if (extcon_get_state(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
+ if (extcon_get_state(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
omap->edev = edev;
@@ -528,17 +528,13 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(&pdev->dev, "failed to create dwc3 core\n");
- goto err2;
+ goto err1;
}
dwc3_omap_enable_irqs(omap);
enable_irq(omap->irq);
return 0;
-err2:
- extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
- extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
-
err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -550,8 +546,6 @@ static int dwc3_omap_remove(struct platform_device *pdev)
{
struct dwc3_omap *omap = platform_get_drvdata(pdev);
- extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
- extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
disable_irq(omap->irq);
of_platform_depopulate(omap->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/6] usb: Replace the deprecated extcon API
From: Chanwoo Choi @ 2017-01-16 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170116123713epcas1p1d9f40f277e83cb46b9a9333fe2704fb9@epcas1p1.samsung.com>
This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().
The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extcon_get_state();
Changes from v2:
- Rebase these patches based on usb.git[1] (testing/next branch)
Changes from v1:
- Rebase these patches based on v4.10-rc1.
- Add acked-by tag from usb maintainer and reviewer.
- Drop the phy/power-supply/chipidea patches.
[1] https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing/next
Chanwoo Choi (6):
usb: dwc3: omap: Replace the extcon API
usb: phy: msm: Replace the extcon API
usb: phy: omap-otg: Replace the extcon API
usb: phy: qcom-8x16-usb: Replace the extcon API
usb: phy: tahvo: Replace the deprecated extcon API
usb: renesas_usbhs: Replace the deprecated extcon API
drivers/usb/dwc3/dwc3-omap.c | 20 +++++++-------------
drivers/usb/phy/phy-msm-usb.c | 33 +++++++++++----------------------
drivers/usb/phy/phy-omap-otg.c | 24 ++++++------------------
drivers/usb/phy/phy-qcom-8x16-usb.c | 13 ++++---------
drivers/usb/phy/phy-tahvo.c | 10 +++++-----
drivers/usb/renesas_usbhs/common.c | 2 +-
6 files changed, 34 insertions(+), 68 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Afzal Mohammed @ 2017-01-16 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83be771e-b432-0950-202b-afb09f125865@arm.com>
Hi,
On Mon, Jan 16, 2017 at 09:53:41AM +0000, Vladimir Murzin wrote:
> On 15/01/17 11:47, Afzal Mohammed wrote:
> > mpu_setup_region() in arch/arm/mm/nommu.c that takes care of
> > MPU_RAM_REGION only. And that seems to be a kind of redundant as it is
> > also done in asm at __setup_mpu(). Git blames asm & C to consecutive
> > commits, that makes me a little shaky about the conclusion on it being
> > redundant.
>
> It is not redundant. MPU setup is done it two steps. The first step done in
> asm to enable caches, there only kernel image is covered; the second step takes
> care on the whole RAM given via dt or "mem=" parameter.
Okay, thanks for the details.
> > Thinking of invoking mpu_setup() from secondary_start_kernel() in
> > arch/arm/kernel/smp.c, with mpu_setup() being slightly modified to
> > avoid storing region details again when invoked by secondary cpu's.
>
> I have wip patches on reworking MPU setup code. The idea is to start using
> mpu_rgn_info[] actively, so asm part for secondariness would just sync-up
> content of that array. Additionally, it seems that we can reuse free MPU slots
> to cover memory which is discarded due to MPU alignment restrictions...
>
> > Vladimir, once changes are done after a revisit, i would need your
> > help to test on Cortex-R.
>
> I'm more than happy to help, but currently I have limited bandwidth, so if it
> can wait till the next dev cycle I'd try to make MPU rework finished by that
> time.
Okay, please feel free to do MPU rework the way you were planning, you
know more details & have the platform to achieve it with much higher
efficiency than me.
Regards
afzal
^ permalink raw reply
* [PATCH 04/10] sata: hardreset: retry if phys link is down
From: Bartosz Golaszewski @ 2017-01-16 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115231049.GC14446@mtj.duckdns.org>
2017-01-16 0:10 GMT+01:00 Tejun Heo <tj@kernel.org>:
> Hello,
>
> On Fri, Jan 13, 2017 at 01:37:58PM +0100, Bartosz Golaszewski wrote:
>> The sata core driver already retries to resume the link because some
>> controllers ignore writes to the SControl register.
>>
>> We have a use case with the da850 SATA controller where at PLL0
>> frequency of 456MHz (needed to properly service the LCD controller)
>> the chip becomes unstable and the hardreset operation is ignored the
>> first time 50% of times.
>>
>> Retrying just the resume operation doesn't work - we need to issue
>> the phy/wake reset again to make it work.
>>
>> If ata_phys_link_offline() returns true in sata_link_hardreset(),
>> retry a couple times before really giving up.
>
> I think it'd be better to implement the driver specific implementation
> rather than changing the behavior for everybody.
>
> Thanks.
>
For v2 I created a new ahci-locally exported function:
ahci_do_hardreset() that allows to retrieve the online state of the
link and used it in the da850-specific hardreset implementation.
Hope that'll be good.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control
From: Yao Qi @ 2017-01-16 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484220369-23970-8-git-send-email-Dave.Martin@arm.com>
On 17-01-12 11:26:06, Dave Martin wrote:
> Currently the vector length is inherited across both fork() and
> exec().
>
> Inheritance across fork() is desirable both for creating a copy of
> a process (traditional fork) or creating a thread (where we want
> all threads to share the same VL by default).
>
> Inheritance across exec() is less desirable, because of the ABI
> impact of large vector lengths on the size of the signal frame --
> when running a new binary, there is no guarantee that the new
> binary is compatible with these ABI changes.
>
> This flag makes the vector length non-inherited by default.
Can we make vector length inherited across fork but non-inherited
across exec by default?
> Instead, the vector length is reset to a system default value,
> unless the THREAD_VL_INHERIT flag has been set for the thread.
>
> THREAD_VL_INHERIT is currently sticky: i.e., if set, it gets
> inherited too. This behaviour may be refined in future if it is
> not flexible enough.
>
--
Yao (??)
^ permalink raw reply
* [PATCH v3 2/4] PM / devfreq: exynos-ppmu: Show the registred device for ppmu device
From: Chanwoo Choi @ 2017-01-16 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484569567-29810-1-git-send-email-cw00.choi@samsung.com>
This patch just adds the simple log to show the PPMU device's registration
during the kernel booting.
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/devfreq/event/exynos-ppmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/devfreq/event/exynos-ppmu.c b/drivers/devfreq/event/exynos-ppmu.c
index fb3706faf5bd..9b7350935b73 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -643,6 +643,9 @@ static int exynos_ppmu_probe(struct platform_device *pdev)
"failed to add devfreq-event device\n");
return PTR_ERR(edev[i]);
}
+
+ pr_info("exynos-ppmu: new PPMU device registered %s (%s)\n",
+ dev_name(&pdev->dev), desc[i].name);
}
clk_prepare_enable(info->ppmu.clk);
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default
From: Dave Martin @ 2017-01-16 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116113439.GF28060@E107787-LIN>
On Mon, Jan 16, 2017 at 11:34:39AM +0000, Yao Qi wrote:
> On 17-01-12 11:26:05, Dave Martin wrote:
> > General-purpose code in userspace is not expected to work correctly
> > if multiple threads are allowed to run concurrently with different
> > vector lengths in a single process.
> >
> > This patch adds an explicit flag PR_SVE_SET_VL_THREAD to request
> > this behaviour. Without the flag, vector length setting is
> > permitted only for a single-threaded process (which matches the
> > expected usage model of setting the vector length at process
> > startup).
To be clear, PR_SVE_SET_VL_THREAD is not persistent, it just overrides
the default one-thread-per-process restriction for this prctl call.
The idea is that if someone writes some code to set the VL and then
moves the code to a multithreaded environment, by default it will stop
working. This is a hint that some actual work is likely needed to
port their code to work with multiple threads.
> Hi Dave,
> PR_SVE_SET_VL_THREAD can be arch-independent, IMO, because prctl
> needs a scope. Looks some of them are system-wide, some of them are
> about threads within the same process (like, PR_MPX_ENABLE_MANAGEMENT).
> IOW, PR_SVE_SET_VL_THREAD can be general flag, to indicate the scope
> of each new ptrcl command is per-thread.
This can't be backported to the existing prctls because that would
change their behaviour. Rather, what each prctl applies (thread or
process) is part of the definition of that particular prctl.
Since there are no other prctl() calls that can apply per-thread or
per-process, or that differ only in this regard, is seems a bit esoteric
to try to apply this concept across all prctls... ?
Which prctl()s are system-wide? I didn't see any, but I may have missed
something.
> I happen to see PR_SET_FP_MODE in man pages, which is about setting
> FP register modes in runtime. It is a little similar to setting VL in
> this patch. However the doc doesn't mention the effect or the scope
> of this command.
The various FP/SIMD twiddling prctls() all seem to be arch-specific.
PR_SET_FP_MODE only exists for mips.
Unless the semantics are really the same, I'm not too keen on an arm64
prctl with the same name.
Putting "ARM64" in the name of the new prctls might be clearer, but
nobody seemed to care so far...
Cheers
---Dave
^ permalink raw reply
* [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
From: Yao Qi @ 2017-01-16 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484220369-23970-9-git-send-email-Dave.Martin@arm.com>
On 17-01-12 11:26:07, Dave Martin wrote:
> This patch adds support for manipulating a task's vector length at
> runtime via ptrace.
>
I hope kernel doesn't provide such interface to ptracer to change vector
length. The vector length is sort of a read-only property of thread/process/
program to debugger, unless we really have a clear requirement to modify
vector length in debugging. I may miss something because I haven't debug
SVE code yet.
> As a simplification, we turn the task back into an FPSIMD-only task
> when changing the vector length. If the register data is written
> too, we then turn the task back into an SVE task, with changed
> task_struct layout for the SVE data, before the actual data writing
> is done.
>
> Because the vector length is now variable, sve_get() now needs to
> return the real maximum for user_sve_header.max_vl, since .vl may
> be less than this (that's the whole point).
>
--
Yao (??)
^ permalink raw reply
* [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver
From: Philipp Zabel @ 2017-01-16 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e609fd03-a546-330c-ec89-de1844d1b46f@gmail.com>
On Fri, 2017-01-13 at 11:03 -0800, Steve Longerbeam wrote:
>
> On 01/13/2017 03:55 AM, Philipp Zabel wrote:
> > Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> >> Add bindings documentation for the i.MX media driver.
> >>
> >> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> >> ---
> >> Documentation/devicetree/bindings/media/imx.txt | 57 +++++++++++++++++++++++++
> >> 1 file changed, 57 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> >> new file mode 100644
> >> index 0000000..254b64a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/imx.txt
> >> @@ -0,0 +1,57 @@
> >> +Freescale i.MX Media Video Devices
> >> +
> >> +Video Media Controller node
> >> +---------------------------
> >> +
> >> +This is the parent media controller node for video capture support.
> >> +
> >> +Required properties:
> >> +- compatible : "fsl,imx-media";
> > Would you be opposed to calling this "capture-subsystem" instead of
> > "imx-media"? We already use "fsl,imx-display-subsystem" and
> > "fsl,imx-gpu-subsystem" for the display and GPU compound devices.
>
> sure. Some pie-in-the-sky day when DRM and media are unified,
> there could be a single device that handles them all,
Indeed :)
> but for now
> I'm fine with "fsl,capture-subsystem".
Actually, I meant fsl,imx-capture-subsystem. fsl,imx-media-subsystem
would be fine, too. Either way, I'll be happy if it looks similar to the
other two.
[...]
> > This is a clever method to get better frame timestamps. Too bad about
> > the routing requirements. Can this be used on Nitrogen6X?
>
> Absolutely, this support just needs use of the input-capture channels in the
> imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
> input capture API, so at this point fsl,input-capture-channel has no effect,
> but it does work (tested on SabreAuto).
Nice.
[...]
> >> +Required properties:
> >> +- compatible : "fsl,imx6-mipi-csi2";
> > I think this should get an additional "snps,dw-mipi-csi2" compatible,
> > since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.
>
> right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
> Or should wait until the day this subdev is exported for general use, after
> pulling out the gasket specifics?
It can be added right away.
> >> +- reg : physical base address and length of the register set;
> >> +- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
> >> + (the DPHY clock), video_27m, and eim_sel;
> > Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
> > shared gate bit that gates the HSI clocks as well as the MIPI
> > "ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
> > csi-2 core, but we are missing shared gate clocks in the clock tree for
> > these.
>
> Yes, so many clocks for the MIPI core. Why so many? I would think
> there would need to be at most three: a clock for the MIPI CSI-2 core
> and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
> M-PHY if there is one). I have no clue what all these other clocks are.
> But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.
I would imagine the CSI-2 core has a high-speed clock input from the
D-PHY for serial input, an APB clock for register access (ips_clk), and
a pixel clock input for the parallel output (pixel_clk), at least.
The D-PHY will have a PLL reference input (pll_refclk?) and probably its
own register clock (cfg_clk?).
I've looked at the MIPI DSI chapter, and it looks like ac_clk_125m is
used for DSI only.
> > Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
> > video_27m seems fine.
> > But I don't get "dphy".
>
> I presume it's the clock for the D-PHY.
>
> > Which input clock would that correspond to?
> > "pll_refclk?"
>
> the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.
I think that makes sense.
regards
Philipp
^ permalink raw reply
* [PATCH 2/5] phy: meson: add USB2 and USB3 PHY support for Meson GXL
From: Martin Blumenstingl @ 2017-01-16 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587C9566.7080306@ti.com>
Hi Kishon,
thank you for taking the time to review this!
On Mon, Jan 16, 2017 at 10:41 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Saturday 26 November 2016 08:26 PM, Martin Blumenstingl wrote:
>> This adds two new USB PHY drivers found on Meson GXL and GXM SoCs.
>
> Please send them as separate drivers.
OK, I also just discovered that USB2 works even when not configuring
the USB3 PHY. That's another good reason for splitting these.
>> The registers for the USB2 PHY block handle a maximum of 4 ports (newer
>> SoCs may allow more ports, the driver handles this as long as the
>> register length is adjusted in the .dts). The PHY block theoretically
>> allows powering down each PHY port separately (by putting it into
>> "reset" state). Unfortunately this does not work (my board has 2 USB
>> ports, connected to port 1 and 2 of the dwc3's internal hub. When
>> leaving the third USB PHY disabled then the hub sees that a device is
>> plugged in, but it does not work: "usb usb1-port2: connect-debounce
>> failed").
>> The USB3 PHY will take care of enabling/disabling all available ports,
>> because the USB3 PHY also manages the mode of the USB2 PHYs.
>>
>> The USB3 PHY actually has three purposes:
>> - it provides the USB3 PHY
>> - it handles the OTG device/host mode detection interrupt
>> - it notifies the corresponding USB2 PHYs of the OTG mode changes
>> On GXL and GXM SoCs one references all available USB2 PHY ports in the
>> USB3 PHY because all are connected to the same USB controller (thus the
>> mode will always match). This behavior is configurable via devicetree,
>> by passing (or not passing) a list of other ("child") PHYs which should
>> be configured by the USB3 PHY.
>>
>> Unfortunately there are no datasheets available for any of these PHYs.
>> Both drivers were written by reading the reference drivers provided by
>> Amlogic and analyzing the registers on the kernel that was shipped with
>> my board.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> drivers/phy/Kconfig | 13 ++
>> drivers/phy/Makefile | 2 +
>> drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++++++++++++++++++++
>> drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 766 insertions(+)
>> create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
>> create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 728e03f..ea74843 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -502,4 +502,17 @@ config PHY_MESON8B_USB2
>> and GXBB SoCs.
>> If unsure, say N.
>>
>> +config PHY_MESON_GXL_USB
>> + tristate "Meson GXL USB2 and USB3 PHY drivers"
>> + default ARCH_MESON
>> + depends on OF && (ARCH_MESON || COMPILE_TEST)
>> + depends on USB_SUPPORT
>> + select USB_COMMON
>> + select GENERIC_PHY
>> + select REGMAP_MMIO
>> + help
>> + Enable this to support the Meson USB2 and USB3 PHYs found in
>> + Meson GXL SoCs.
>> + If unsure, say N.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 0c7fdae..960a96e 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -61,3 +61,5 @@ obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
>> obj-$(CONFIG_ARCH_TEGRA) += tegra/
>> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
>> obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
>> +obj-$(CONFIG_PHY_MESON_GXL_USB) += phy-meson-gxl-usb2.o
>> +obj-$(CONFIG_PHY_MESON_GXL_USB) += phy-meson-gxl-usb3.o
>> diff --git a/drivers/phy/phy-meson-gxl-usb2.c b/drivers/phy/phy-meson-gxl-usb2.c
>> new file mode 100644
>> index 0000000..c081ce3
[snip]
>> +static struct phy *phy_meson_gxl_usb2_of_xlate(struct device *dev,
>> + struct of_phandle_args *args)
>> +{
>> + struct phy_meson_gxl_usb2_drv *priv = dev_get_drvdata(dev);
>> + int port;
>> +
>> + if (args->args_count != 1) {
>> + dev_err(dev, "Invalid number of cells in 'phy' property\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> +
>> + port = args->args[0];
>> + if (WARN_ON(port >= priv->num_ports))
>> + return ERR_PTR(-ENODEV);
>> +
>> + return priv->ports[port];
>> +}
>
> Please model every port as a sub-node and get rid of custom xlate implementation.
already done in my local tree.
I am in contact with the USB developers to get the USB2 PHYs working
(as all of them have to be turned on when powering up dwc3). The
result of how the dwc3 node with the PHY references may look like can
be seen here: [0]
>> +MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
>> +MODULE_DESCRIPTION("Meson GXL USB2 PHY driver");
>> +MODULE_LICENSE("GPL");
>
> GPL v2 to match with the file header.
good catch, thanks
>> diff --git a/drivers/phy/phy-meson-gxl-usb3.c b/drivers/phy/phy-meson-gxl-usb3.c
>> new file mode 100644
>> index 0000000..90a4028
>> --- /dev/null
>> +++ b/drivers/phy/phy-meson-gxl-usb3.c
>> @@ -0,0 +1,377 @@
>> +/*
>> + * Meson GXL USB3 PHY driver
>> + *
>> + * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/regmap.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/usb/of.h>
>> +#include <linux/workqueue.h>
>> +
>> +#define USB_R0 0x00
>> + #define USB_R0_P30_FSEL_SHIFT 0
>> + #define USB_R0_P30_FSEL_MASK GENMASK(5, 0)
>> + #define USB_R0_P30_PHY_RESET BIT(6)
>> + #define USB_R0_P30_TEST_POWERDOWN_HSP BIT(7)
>> + #define USB_R0_P30_TEST_POWERDOWN_SSP BIT(8)
>> + #define USB_R0_P30_ACJT_LEVEL_SHIFT 9
>> + #define USB_R0_P30_ACJT_LEVEL_MASK GENMASK(13, 9)
>> + #define USB_R0_P30_TX_BOOST_LEVEL_SHIFT 14
>> + #define USB_R0_P30_TX_BOOST_LEVEL_MASK GENMASK(16, 14)
>> + #define USB_R0_P30_LANE0_TX2RX_LOOPBACK BIT(17)
>> + #define USB_R0_P30_LANE0_EXT_PCLK_REQ BIT(18)
>> + #define USB_R0_P30_PCS_RX_LOS_MASK_VAL_SHIFT 19
>> + #define USB_R0_P30_PCS_RX_LOS_MASK_VAL_MASK GENMASK(28, 19)
>> + #define USB_R0_U2D_SS_SCALEDOWN_MODE_SHIFT 29
>> + #define USB_R0_U2D_SS_SCALEDOWN_MODE_MASK GENMASK(30, 29)
>> + #define USB_R0_U2D_ACT BIT(31)
>> +
>> +#define USB_R1 0x04
>> + #define USB_R1_U3H_BIGENDIAN_GS BIT(0)
>> + #define USB_R1_U3H_PME_ENABLE BIT(1)
>> + #define USB_R1_U3H_HUB_PORT_OVERCURRENT_SHIFT 2
>> + #define USB_R1_U3H_HUB_PORT_OVERCURRENT_MASK GENMASK(6, 2)
>> + #define USB_R1_U3H_HUB_PORT_PERM_ATTACH_SHIFT 7
>> + #define USB_R1_U3H_HUB_PORT_PERM_ATTACH_MASK GENMASK(11, 7)
>> + #define USB_R1_U3H_HOST_U2_PORT_DISABLE_SHIFT 12
>> + #define USB_R1_U3H_HOST_U2_PORT_DISABLE_MASK GENMASK(15, 12)
>> + #define USB_R1_U3H_HOST_U3_PORT_DISABLE BIT(16)
>> + #define USB_R1_U3H_HOST_PORT_POWER_CONTROL_PRESENT BIT(17)
>> + #define USB_R1_U3H_HOST_MSI_ENABLE BIT(18)
>> + #define USB_R1_U3H_FLADJ_30MHZ_REG_SHIFT 19
>> + #define USB_R1_U3H_FLADJ_30MHZ_REG_MASK GENMASK(24, 19)
>> + #define USB_R1_P30_PCS_TX_SWING_FULL_SHIFT 25
>> + #define USB_R1_P30_PCS_TX_SWING_FULL_MASK GENMASK(31, 25)
>> +
>> +#define USB_R2 0x08
>> + #define USB_R2_P30_CR_DATA_IN_SHIFT 0
>> + #define USB_R2_P30_CR_DATA_IN_MASK GENMASK(15, 0)
>> + #define USB_R2_P30_CR_READ BIT(16)
>> + #define USB_R2_P30_CR_WRITE BIT(17)
>> + #define USB_R2_P30_CR_CAP_ADDR BIT(18)
>> + #define USB_R2_P30_CR_CAP_DATA BIT(19)
>> + #define USB_R2_P30_PCS_TX_DEEMPH_3P5DB_SHIFT 20
>> + #define USB_R2_P30_PCS_TX_DEEMPH_3P5DB_MASK GENMASK(25, 20)
>> + #define USB_R2_P30_PCS_TX_DEEMPH_6DB_SHIFT 26
>> + #define USB_R2_P30_PCS_TX_DEEMPH_6DB_MASK GENMASK(31, 26)
>> +
>> +#define USB_R3 0x0c
>> + #define USB_R3_P30_SSC_ENABLE BIT(0)
>> + #define USB_R3_P30_SSC_RANGE_SHIFT 1
>> + #define USB_R3_P30_SSC_RANGE_MASK GENMASK(3, 1)
>> + #define USB_R3_P30_SSC_REF_CLK_SEL_SHIFT 4
>> + #define USB_R3_P30_SSC_REF_CLK_SEL_MASK GENMASK(12, 4)
>> + #define USB_R3_P30_REF_SSP_EN BIT(13)
>> + #define USB_R3_P30_LOS_BIAS_SHIFT 16
>> + #define USB_R3_P30_LOS_BIAS_MASK GENMASK(18, 16)
>> + #define USB_R3_P30_LOS_LEVEL_SHIFT 19
>> + #define USB_R3_P30_LOS_LEVEL_MASK GENMASK(23, 19)
>> + #define USB_R3_P30_MPLL_MULTIPLIER_SHIFT 24
>> + #define USB_R3_P30_MPLL_MULTIPLIER_MASK GENMASK(30, 24)
>> +
>> +#define USB_R4 0x10
>> + #define USB_R4_P21_PORT_RESET_0 BIT(0)
>> + #define USB_R4_P21_SLEEP_M0 BIT(1)
>> + #define USB_R4_MEM_PD_SHIFT 2
>> + #define USB_R4_MEM_PD_MASK GENMASK(3, 2)
>> + #define USB_R4_P21_ONLY BIT(4)
>> +
>> +#define USB_R5 0x14
>> + #define USB_R5_ID_DIG_SYNC BIT(0)
>> + #define USB_R5_ID_DIG_REG BIT(1)
>> + #define USB_R5_ID_DIG_CFG_SHIFT 2
>> + #define USB_R5_ID_DIG_CFG_MASK GENMASK(3, 2)
>> + #define USB_R5_ID_DIG_EN_0 BIT(4)
>> + #define USB_R5_ID_DIG_EN_1 BIT(5)
>> + #define USB_R5_ID_DIG_CURR BIT(6)
>> + #define USB_R5_ID_DIG_IRQ BIT(7)
>> + #define USB_R5_ID_DIG_TH_SHIFT 8
>> + #define USB_R5_ID_DIG_TH_MASK GENMASK(15, 8)
>> + #define USB_R5_ID_DIG_CNT_SHIFT 16
>> + #define USB_R5_ID_DIG_CNT_MASK GENMASK(23, 16)
>> +
>> +/* read-only register */
>> +#define USB_R6 0x18
>> + #define USB_R6_P30_CR_DATA_OUT_SHIFT 0
>> + #define USB_R6_P30_CR_DATA_OUT_MASK GENMASK(15, 0)
>> + #define USB_R6_P30_CR_ACK BIT(16)
>> +
>> +#define RESET_COMPLETE_TIME 500
>> +
>> +struct phy_meson_gxl_usb3_priv {
>> + struct regmap *regmap;
>> + struct delayed_work otg_work;
>> + struct phy *this_phy;
>> + int num_usb2_phys;
>> + struct phy **usb2_phys;
>> +};
>> +
>> +static const struct regmap_config phy_meson_gxl_usb3_regmap_conf = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> + .max_register = USB_R6,
>> +};
>> +
>> +static int phy_meson_gxl_usb3_update_mode(struct phy *phy)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv = phy_get_drvdata(phy);
>> + u32 val;
>> + enum phy_mode mode;
>> + int i, ret;
>> +
>> + ret = regmap_read(priv->regmap, USB_R5, &val);
>> + if (ret)
>> + return ret;
>> +
>> + if (val & USB_R5_ID_DIG_CURR) {
>> + mode = PHY_MODE_USB_DEVICE;
>> +
>> + regmap_update_bits(priv->regmap, USB_R0, USB_R0_U2D_ACT,
>> + USB_R0_U2D_ACT);
>> + regmap_update_bits(priv->regmap, USB_R4, USB_R4_P21_SLEEP_M0,
>> + USB_R4_P21_SLEEP_M0);
>> + } else {
>> + mode = PHY_MODE_USB_HOST;
>> +
>> + regmap_update_bits(priv->regmap, USB_R0, USB_R0_U2D_ACT, 0);
>> + regmap_update_bits(priv->regmap, USB_R4, USB_R4_P21_SLEEP_M0,
>> + 0);
>> + }
>> +
>> + /* inform the USB2 PHY that we have changed the mode */
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + ret = phy_set_mode(priv->usb2_phys[i], mode);
>
> I'm finding it difficult to understand this. Why should the mode of one phy be
> set from another phy? Maybe this part should be implemented using extcon?
sounds like a good idea, I will postpone the USB3 PHY driver though
since it's currently only used for "mode switching" (between USB
host/device) and the whole thing requires MUCH more work (as a dwc2
controller is used for device mode, while a dwc3 controller is used
for host mode).
>> + if (ret) {
>> + dev_err(&phy->dev,
>> + "Failed to update usb2-phy #%d mode to %d\n",
>> + i, mode);
>> + return ret;
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void phy_meson_gxl_usb3_work(struct work_struct *data)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv =
>> + container_of(data, struct phy_meson_gxl_usb3_priv,
>> + otg_work.work);
>> +
>> + phy_meson_gxl_usb3_update_mode(priv->this_phy);
>> +
>> + /* unmask IRQs which may have arrived in the meantime */
>> + regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_IRQ, 0);
>> +}
>> +
>> +static int phy_meson_gxl_usb3_init(struct phy *phy)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv = phy_get_drvdata(phy);
>> + int i, ret;
>> +
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + ret = phy_init(priv->usb2_phys[i]);
>> + if (ret) {
>> + dev_err(&phy->dev,
>> + "Failed to initialize related usb2-phy #%d\n",
>> + i);
>> + return ret;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_meson_gxl_usb3_exit(struct phy *phy)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv = phy_get_drvdata(phy);
>> + int i, ret;
>> +
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + ret = phy_exit(priv->usb2_phys[i]);
>> + if (ret) {
>> + dev_err(&phy->dev,
>> + "Failed to exit related usb2-phy #%d\n", i);
>> + return ret;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_meson_gxl_usb3_power_on(struct phy *phy)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv = phy_get_drvdata(phy);
>> + int i, ret;
>> +
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + ret = phy_power_on(priv->usb2_phys[i]);
>> + if (ret) {
>> + dev_err(&phy->dev,
>> + "Failed to power on related usb2-phy #%d\n",
>> + i);
>> + return ret;
>> + }
>> + }
>> +
>> + regmap_update_bits(priv->regmap, USB_R1,
>> + USB_R1_U3H_FLADJ_30MHZ_REG_MASK,
>> + 0x20 << USB_R1_U3H_FLADJ_30MHZ_REG_SHIFT);
>> +
>> + regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_EN_0,
>> + USB_R5_ID_DIG_EN_0);
>> + regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_EN_1,
>> + USB_R5_ID_DIG_EN_1);
>> + regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_TH_MASK,
>> + 0xff << USB_R5_ID_DIG_TH_SHIFT);
>> +
>> + return phy_meson_gxl_usb3_update_mode(phy);
>> +}
>> +
>> +static int phy_meson_gxl_usb3_power_off(struct phy *phy)
>> +{
>> + struct phy_meson_gxl_usb3_priv *priv = phy_get_drvdata(phy);
>> + int i, ret;
>> +
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + ret = phy_power_off(priv->usb2_phys[i]);
>> + if (ret) {
>> + dev_err(&phy->dev,
>> + "Failed to power off related usb2-phy #%d\n",
>> + i);
>> + return ret;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static irqreturn_t phy_meson_gxl_usb3_irq(int irq, void *data)
>> +{
>> + u32 val;
>> + struct phy_meson_gxl_usb3_priv *priv = data;
>> +
>> + regmap_read(priv->regmap, USB_R5, &val);
>> + if (!(val & USB_R5_ID_DIG_IRQ)) {
>> + dev_err(&priv->this_phy->dev, "spurious interrupt\n");
>> + return IRQ_NONE;
>> + }
>> +
>> + schedule_delayed_work(&priv->otg_work, msecs_to_jiffies(10));
>> +
>> + /* acknowledge the IRQ */
>> + regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_IRQ, 0);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static const struct phy_ops phy_meson_gxl_usb3_ops = {
>> + .init = phy_meson_gxl_usb3_init,
>> + .exit = phy_meson_gxl_usb3_exit,
>> + .power_on = phy_meson_gxl_usb3_power_on,
>> + .power_off = phy_meson_gxl_usb3_power_off,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static int phy_meson_gxl_usb3_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + struct phy_meson_gxl_usb3_priv *priv;
>> + struct resource *res;
>> + struct phy *phy;
>> + struct phy_provider *phy_provider;
>> + void __iomem *base;
>> + int i, irq;
>> +
>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + priv->regmap = devm_regmap_init_mmio(dev, base,
>> + &phy_meson_gxl_usb3_regmap_conf);
>> + if (IS_ERR(priv->regmap))
>> + return PTR_ERR(priv->regmap);
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq >= 0) {
>> + INIT_DELAYED_WORK(&priv->otg_work, phy_meson_gxl_usb3_work);
>> +
>> + irq = devm_request_irq(dev, irq, phy_meson_gxl_usb3_irq,
>> + IRQF_SHARED, dev_name(dev),
>> + priv);
>> + if (irq < 0) {
>> + dev_err(dev, "could not register IRQ handler (%d)\n",
>> + irq);
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + priv->num_usb2_phys = of_count_phandle_with_args(np, "phys",
>> + "#phy-cells");
>> +
>> + priv->usb2_phys = devm_kcalloc(dev, priv->num_usb2_phys,
>> + sizeof(*priv->usb2_phys), GFP_KERNEL);
>> + if (!priv->usb2_phys)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < priv->num_usb2_phys; i++) {
>> + priv->usb2_phys[i] = devm_of_phy_get_by_index(dev, np, i);
>
> I'm not sure if referencing usb2_phy from here is the right approach.
that would probably be gone with the USB patches from [0] and with the
switch to extcon
I will send an updated version once we know how to handle powering up
the PHY in xhci-plat.c (which is the series from [0]).
Regards,
Martin
[0] http://marc.info/?l=linux-usb&m=148414866203601&w=2
^ permalink raw reply
* [PATCH] arm64: dts: marvell: add generic-ahci compatibles for CP110 ahci
From: Mark Rutland @ 2017-01-16 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cS72h-0004nc-Rr@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 06:57:39PM +0000, Russell King wrote:
> Testing with an Armada 8040 board shows that adding the generic-ahci
> compatible to the CP110 AHCI nodes gets us working AHCI on the board.
> A previous patch series posted by Thomas Petazzoni was retracted when
> it was realised that the IP was supposed to be, and is, compatible
> with the standard register layout.
>
> Add this compatible.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Assuming the above is correct this looks sane to me. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 3 ++-
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index 464b491c7291..65ad781d7910 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -128,7 +128,8 @@
> };
>
> cpm_sata0: sata at 540000 {
> - compatible = "marvell,armada-8k-ahci";
> + compatible = "marvell,armada-8k-ahci",
> + "generic-ahci";
> reg = <0x540000 0x30000>;
> interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cpm_syscon0 1 15>;
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index b10f4781d8fb..168d667d50a3 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -128,7 +128,8 @@
> };
>
> cps_sata0: sata at 540000 {
> - compatible = "marvell,armada-8k-ahci";
> + compatible = "marvell,armada-8k-ahci",
> + "generic-ahci";
> reg = <0x540000 0x30000>;
> interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cps_syscon0 1 15>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v19 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2017-01-16 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116120123.GD5908@leverpostej>
Hi Mark,
On 16 January 2017 at 20:01, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jan 16, 2017 at 02:26:54PM +0800, Fu Wei wrote:
>> Hi Mark,
>>
>> This v19 (I have mentioned it in my previous email) is the latest
>> patchset which can be applied on v4.10-rc4 directly.
>>
>> please review this patchset, thanks! :-)
>
> Thanks for the pointer; I will look at this shortly.
Great thanks, looking forward to your feedback! :-)
>
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v19 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Mark Rutland @ 2017-01-16 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7vbTLWKgmGe7jH=4OJx7sZ4Ck4iR-spvnHUrStF5XGxKw@mail.gmail.com>
On Mon, Jan 16, 2017 at 02:26:54PM +0800, Fu Wei wrote:
> Hi Mark,
>
> This v19 (I have mentioned it in my previous email) is the latest
> patchset which can be applied on v4.10-rc4 directly.
>
> please review this patchset, thanks! :-)
Thanks for the pointer; I will look at this shortly.
Mark.
^ permalink raw reply
* [PATCH v18 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Mark Rutland @ 2017-01-16 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7ugz_YpxKQUsJbF1vdjm_Nzyh2mH8TZMPqj1cSHGSPCFw@mail.gmail.com>
On Mon, Jan 16, 2017 at 08:54:46AM +0800, Fu Wei wrote:
> On 14 January 2017 at 19:34, Fu Wei <fu.wei@linaro.org> wrote:
> > On 14 January 2017 at 03:29, Mark Rutland <mark.rutland@arm.com> wrote:
> >> Once v4.10-rc4 comes out this weekend, could you please rebase and
> >> repost this?
> >
> > Yes, of course.
> >
> > I have rebased v19 to the latest v4.10-rc3-e96f8f1, it dosen't need
> > any modification.
> > I will rebase it every day, and will repost it if it need any modification.
> >
> > But for now, V19 works well with the master branch of upstream kernel.
> > Do I need to re-post it even if it doesn't need any improvement or
> > modification? :-)
>
> I just fetched the latest mainline kernel, and rebase v19 on the top
> of 4.10-rc4.
> I have double checked it, V19 works well with 4.10-rc4.
> For rebasing, it doesn't need any modification.
Ok. Assuming that the patches apply cleanly atop of v4.10-rc4, I will
look over this shortly.
Thanks for checking that!
Mark.
^ permalink raw reply
* [PATCH V7 10/10] arm/arm64: KVM: add guest SEA support
From: Marc Zyngier @ 2017-01-16 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484244924-24786-11-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 12/01/17 18:15, Tyler Baicar wrote:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> arch/arm/include/asm/kvm_arm.h | 1 +
> arch/arm/include/asm/system_misc.h | 5 +++++
> arch/arm/kvm/mmu.c | 18 ++++++++++++++++--
> arch/arm64/include/asm/kvm_arm.h | 1 +
> arch/arm64/include/asm/system_misc.h | 2 ++
> arch/arm64/mm/fault.c | 13 +++++++++++++
> 6 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
> index e22089f..33a77509 100644
> --- a/arch/arm/include/asm/kvm_arm.h
> +++ b/arch/arm/include/asm/kvm_arm.h
> @@ -187,6 +187,7 @@
> #define FSC_FAULT (0x04)
> #define FSC_ACCESS (0x08)
> #define FSC_PERM (0x0c)
> +#define FSC_EXTABT (0x10)
>
> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> #define HPFAR_MASK (~0xf)
> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
> index a3d61ad..ea45d94 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__ */
>
> +static inline int handle_guest_sea(unsigned long addr, unsigned int esr)
> +{
> + return -1;
> +}
> +
> #endif /* __ASM_ARM_SYSTEM_MISC_H */
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index e9a5c0e..1152966 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -29,6 +29,7 @@
> #include <asm/kvm_asm.h>
> #include <asm/kvm_emulate.h>
> #include <asm/virt.h>
> +#include <asm/system_misc.h>
>
> #include "trace.h"
>
> @@ -1441,8 +1442,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>
> /* Check the stage-2 fault is trans. fault or write fault */
> fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
> - if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
> - fault_status != FSC_ACCESS) {
> +
> + /* The host kernel will handle the synchronous external abort. There
> + * is no need to pass the error into the guest.
> + */
> + if (fault_status == FSC_EXTABT) {
> + if(handle_guest_sea((unsigned long)fault_ipa,
> + kvm_vcpu_get_hsr(vcpu))) {
> + kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
> + kvm_vcpu_trap_get_class(vcpu),
> + (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
> + (unsigned long)kvm_vcpu_get_hsr(vcpu));
So there's one thing I don't like here, which is that we just gave the
guest a very nice way to pollute the host's kernel log with spurious
messages. So I'd rather make it silent, or at the very least rate limited.
> + return -EFAULT;
> + }
> + } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
> + fault_status != FSC_ACCESS) {
> kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
> kvm_vcpu_trap_get_class(vcpu),
> (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 4b5c977..be0efb6 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -201,6 +201,7 @@
> #define FSC_FAULT ESR_ELx_FSC_FAULT
> #define FSC_ACCESS ESR_ELx_FSC_ACCESS
> #define FSC_PERM ESR_ELx_FSC_PERM
> +#define FSC_EXTABT ESR_ELx_FSC_EXTABT
>
> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> #define HPFAR_MASK (~UL(0xf))
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index e7f3440..27816cb 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> int register_sea_notifier(struct notifier_block *nb);
> void unregister_sea_notifier(struct notifier_block *nb);
>
> +int handle_guest_sea(unsigned long addr, unsigned int esr);
> +
> #endif /* __ASM_SYSTEM_MISC_H */
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 81039c7..fa8d4d7 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
> }
>
> /*
> + * Handle Synchronous External Aborts that occur in a guest kernel.
> + */
> +int handle_guest_sea(unsigned long addr, unsigned int esr)
> +{
> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
> +
> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> + fault_name(esr), esr, addr);
Same here.
> +
> + return 0;
> +}
> +
> +/*
> * Dispatch a data abort to the relevant handler.
> */
> asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-16 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dfa7f5a-712e-3457-305b-7e1b7f6a9b3c@arm.com>
On 13/01/17 12:40, Robin Murphy wrote:
> On 13/01/17 09:12, Vladimir Murzin wrote:
>> On 12/01/17 18:07, Robin Murphy wrote:
>>> On 12/01/17 17:15, Vladimir Murzin wrote:
>>>> On 12/01/17 17:04, Robin Murphy wrote:
>>>>> On 12/01/17 16:52, Vladimir Murzin wrote:
>>>>>> On 12/01/17 10:55, Benjamin Gaignard wrote:
>>>>>>> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>>>>>>>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>>>>>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>>>>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>>>>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>>>>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>>>>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>>>>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>>>>>>>
>>>>>>>>>>> This patch set is trying to address the issue by providing region of
>>>>>>>>>>> memory suitable for consistent DMA operations. It is supposed that
>>>>>>>>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>>>>>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>>>>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>>>>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>>>>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>>>>>>>> framework, and it is seems that it might be reused by other
>>>>>>>>>>> architectures like c6x and blackfin.
>>>>>>>>>>>
>>>>>>>>>>> Dedicated DMA region is required for cases other than:
>>>>>>>>>>> - MMU/MPU is off
>>>>>>>>>>> - cpu is v7m w/o cache support
>>>>>>>>>>> - device is coherent
>>>>>>>>>>>
>>>>>>>>>>> In case one of the above conditions is true dma operations are forced
>>>>>>>>>>> to be coherent and wired with dma_noop_ops.
>>>>>>>>>>>
>>>>>>>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>>>>>>>> compilation unit.
>>>>>>>>>>>
>>>>>>>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>>>>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>>>>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>>>>>>>> it doesn't work with my drm/kms driver.
>>>>>>>>>
>>>>>>>>> I guess the same is for fbmem, but would be better to have confirmation since
>>>>>>>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>>>>>>>
>>>>>>>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>>>>>>>> using current dma-mapping
>>>>>>>>>> code.
>>>>>>>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>>>>>>>> used instead of alloc_pages()
>>>>>>>>>> in dma-mapping.
>>>>>>>>>
>>>>>>>>> Unless I've missed something bellow is a call stack for both
>>>>>>>>>
>>>>>>>>> #1
>>>>>>>>> __alloc_simple_buffer
>>>>>>>>> __dma_alloc_buffer
>>>>>>>>> alloc_pages
>>>>>>>>> split_page
>>>>>>>>> __dma_clear_buffer
>>>>>>>>> memset
>>>>>>>>> page_address
>>>>>>>>>
>>>>>>>>> #2
>>>>>>>>> __get_free_pages
>>>>>>>>> alloc_pages
>>>>>>>>> page_address
>>>>>>>>>
>>>>>>>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>>>>>>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>>>>>>>
>>>>>>>>> Is something from above critical for your driver?
>>>>>>>>
>>>>>>>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>>>>>>>> from #1 and it is still working.
>>>>>>>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>>>>>>>
>>>>>>>> I have investigated more and found that dma-noop doesn't take care of
>>>>>>>> "dma-ranges" property which is set in DT.
>>>>>>>> I believed that is the root cause of my problem with your patches.
>>>>>>>
>>>>>>> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
>>>>>>> modetest and fbdemo are now still functional.
>>>>>>>
>>>>>>
>>>>>> Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
>>>>>> so dma-ranges property is in use.
>>>>>>
>>>>>> It looks like virt_to_dma is ARM specific, so I probably have to discard idea
>>>>>> of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
>>>>>> is_device_dma_coherent(dev) check.
>>>>>
>>>>> dma_pfn_offset is a member of struct device, so it should be OK for
>>>>> dma_noop_ops to also make reference to it (and assume it's zero if not
>>>>> explicitly set).
>>>>>
>>>>>> Meanwhile, I'm quite puzzled on how such memory remaping should work together
>>>>>> with reserved memory. It seem it doesn't account dma-ranges while reserving
>>>>>> memory (it is too early) nor while allocating/mapping/etc.
>>>>>
>>>>> The reserved memory is described in terms of CPU physical addresses, so
>>>>> a device offset shouldn't matter from that perspective. It only comes
>>>>> into play at the point you generate the dma_addr_t to hand off to the
>>>>> device - only then do you need to transform the CPU physical address of
>>>>> the allocated/mapped page into the device's view of that page (i.e.
>>>>> subtract the offset).
>>>>
>>>> Thanks for explanation! So dma-coherent.c should be modified, right? I see
>>>> that some architectures provide phys_to_dma/dma_to_phys helpers primary for
>>>> swiotlb, is it safe to reuse them given that default implementation is
>>>> provided? Nothing under Documentation explains how they supposed to be used,
>>>> sorry if asking stupid question.
>>>
>>> Those are essentially SWIOTLB-specific, so can't be universally relied
>>> upon. I think something like this ought to suffice:
>>
>> Yup, but what about dma-coherent.c? Currently it has
>>
>> int dma_alloc_from_coherent(struct device *dev, ssize_t size,
>> dma_addr_t *dma_handle, void **ret)
>> {
>> ...
>> *dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
>> *ret = mem->virt_base + (pageno << PAGE_SHIFT);
>> ...
>> }
>>
>> In case reserved memory is described in terms of CPU phys addresses, would not
>> we need to take into account dma_pfn_offset? What I'm missing?
>
> Ah yes, I overlooked that one. AFAICS, that's intended to be accounted
> for when calling dma_init_coherent_memory (i.e. phys_addr vs.
> device_addr), but that's a bit awkward for a global pool.
>
> How utterly disgusting do you think this (or some variant thereof) looks?
>
> /* Apply device-specific offset for the global pool */
> if (mem == dma_coherent_default_memory)
> *handle += dev->dma_pfn_offset << PAGE_SHIFT;
It'd work for default dma region, but IMO the issue is wider here... does
following look better?
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index b52ba27..22daa4c 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -27,6 +27,15 @@ static inline struct dma_coherent_mem *dev_get_coherent_memory(struct device *de
return dma_coherent_default_memory;
}
+static inline dma_addr_t dma_get_device_base(struct device *dev,
+ struct dma_coherent_mem * mem)
+{
+ if (!dev)
+ return mem->pfn_base << PAGE_SHIFT;
+
+ return (mem->pfn_base + dev->dma_pfn_offset) << PAGE_SHIFT;
+}
+
static bool dma_init_coherent_memory(
phys_addr_t phys_addr, dma_addr_t device_addr, size_t size, int flags,
struct dma_coherent_mem **mem)
@@ -92,13 +101,19 @@ static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
static int dma_assign_coherent_memory(struct device *dev,
struct dma_coherent_mem *mem)
{
+ unsigned long dma_pfn_offset = mem->pfn_base - PFN_DOWN(mem->device_base);
+
if (!dev)
return -ENODEV;
if (dev->dma_mem)
return -EBUSY;
+ if (dev->dma_pfn_offset)
+ WARN_ON(dev->dma_pfn_offset != dma_pfn_offset);
+
dev->dma_mem = mem;
+ dev->dma_pfn_offset = dma_pfn_offset;
/* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
return 0;
@@ -145,7 +160,7 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
return ERR_PTR(-EINVAL);
spin_lock_irqsave(&mem->spinlock, flags);
- pos = (device_addr - mem->device_base) >> PAGE_SHIFT;
+ pos = PFN_DOWN(device_addr - dma_get_device_base(dev, mem));
err = bitmap_allocate_region(mem->bitmap, pos, get_order(size));
spin_unlock_irqrestore(&mem->spinlock, flags);
@@ -195,8 +210,9 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t size,
/*
* Memory was found in the per-device area.
*/
- *dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
+ *dma_handle = dma_get_device_base(dev, mem) + (pageno << PAGE_SHIFT);
*ret = mem->virt_base + (pageno << PAGE_SHIFT);
+
dma_memory_map = (mem->flags & DMA_MEMORY_MAP);
spin_unlock_irqrestore(&mem->spinlock, flags);
if (dma_memory_map)
Cheers
Vladimir
>
> Robin.
>
>> Thanks
>> Vladimir
>>
>>>
>>> ---8<---
>>> diff --git a/lib/dma-noop.c b/lib/dma-noop.c
>>> index 3d766e78fbe2..fbb1b37750d5 100644
>>> --- a/lib/dma-noop.c
>>> +++ b/lib/dma-noop.c
>>> @@ -8,6 +8,11 @@
>>> #include <linux/dma-mapping.h>
>>> #include <linux/scatterlist.h>
>>>
>>> +static dma_addr_t dma_noop_dev_offset(struct device *dev)
>>> +{
>>> + return (dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT;
>>> +}
>>> +
>>> static void *dma_noop_alloc(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t gfp,
>>> unsigned long attrs)
>>> @@ -16,7 +21,7 @@ static void *dma_noop_alloc(struct device *dev, size_t
>>> size,
>>>
>>> ret = (void *)__get_free_pages(gfp, get_order(size));
>>> if (ret)
>>> - *dma_handle = virt_to_phys(ret);
>>> + *dma_handle = virt_to_phys(ret) - dma_noop_dev_offset(dev);
>>> return ret;
>>> }
>>>
>>> @@ -32,7 +37,7 @@ static dma_addr_t dma_noop_map_page(struct device
>>> *dev, struct page *page,
>>> enum dma_data_direction dir,
>>> unsigned long attrs)
>>> {
>>> - return page_to_phys(page) + offset;
>>> + return page_to_phys(page) + offset - dma_noop_dev_offset(dev);
>>> }
>>>
>>> static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl,
>>> int nents,
>>> @@ -47,7 +52,8 @@ static int dma_noop_map_sg(struct device *dev, struct
>>> scatterlist *sgl, int nent
>>>
>>> BUG_ON(!sg_page(sg));
>>> va = sg_virt(sg);
>>> - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
>>> + sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) -
>>> + dma_noop_dev_offset(dev);
>>> sg_dma_len(sg) = sg->length;
>>> }
>>> --->8---
>>>
>>> intentionally whitespace-damaged by copy-pasting off my terminal to
>>> emphasise how utterly untested it is ;)
>>>
>>> Robin.
>>>
>>
>
>
^ permalink raw reply related
* [Question] A question about arm64 pte
From: Catalin Marinas @ 2017-01-16 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d284f510-f025-db84-f21e-a5b167d4bcd2@huawei.com>
On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> I have question about arm64 pte.
I assume the context is ARMv8.0 (without hardware DBM support).
> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> and PTE_DIRTY is to mark whether the page is dirty.
> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
That's what set_pte_at() does.
> Is that means that the page is still writable when PTE_RDONLY is set with PTE_WRITE?
No. On ARMv8.0, PTE_WRITE is a software only bit while PTE_RDONLY
describes the actual hardware permission. If set_pte_at() does not clear
the PTE_RDONLY bit (PTE_DIRTY not set), the page is read-only even
though PTE_WRITE may be set.
> But in ARM Architecture Reference Manual for ARMv8,
> when PTE_RDONLY is set(AP[2:1] = 0b1x), Acess from EL1 is Ready only?
Yes.
> so what is the really means of the PTE_RDONLY?
Read-only. On ARMv8.0, PTE_WRITE is irrelevant from a hardware
perspective.
--
Catalin
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Will Deacon @ 2017-01-16 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484244924-24786-5-git-send-email-tbaicar@codeaurora.org>
On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
> arch/arm64/include/asm/system_misc.h | 13 ++++++++
> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
> 2 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 57f110b..e7f3440 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>
> #endif /* __ASSEMBLY__ */
>
> +/*
> + * The functions below are used to register and unregister callbacks
> + * that are to be invoked when a Synchronous External Abort (SEA)
> + * occurs. An SEA is raised by certain fault status codes that have
> + * either data or instruction abort as the exception class, and
> + * callbacks may be registered to parse or handle such hardware errors.
> + *
> + * Registered callbacks are run in an interrupt/atomic context. They
> + * are not allowed to block or sleep.
> + */
> +int register_sea_notifier(struct notifier_block *nb);
> +void unregister_sea_notifier(struct notifier_block *nb);
I still don't understand why you need notifiers for this. You register
precisely one hook in the series.
> #endif /* __ASM_SYSTEM_MISC_H */
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 05d2bd7..81039c7 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -39,6 +39,22 @@
> #include <asm/pgtable.h>
> #include <asm/tlbflush.h>
>
> +/*
> + * GHES SEA handler code may register a notifier call here to
> + * handle HW error record passed from platform.
> + */
> +static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
> +
> +int register_sea_notifier(struct notifier_block *nb)
> +{
> + return atomic_notifier_chain_register(&sea_handler_chain, nb);
> +}
> +
> +void unregister_sea_notifier(struct notifier_block *nb)
> +{
> + atomic_notifier_chain_unregister(&sea_handler_chain, nb);
> +}
> +
> static const char *fault_name(unsigned int esr);
>
> #ifdef CONFIG_KPROBES
> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> return 1;
> }
>
> +/*
> + * This abort handler deals with Synchronous External Abort.
> + * It calls notifiers, and then returns "fault".
> + */
> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> +{
> + struct siginfo info;
> +
> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
> +
> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> + fault_name(esr), esr, addr);
> +
> + info.si_signo = SIGBUS;
> + info.si_errno = 0;
> + info.si_code = 0;
> + info.si_addr = (void __user *)addr;
> + arm64_notify_die("", regs, &info, esr);
> +
> + return 0;
> +}
> +
> static const struct fault_info {
> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> int sig;
> @@ -502,22 +540,22 @@ static const struct fault_info {
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
> - { do_bad, SIGBUS, 0, "synchronous external abort" },
> + { do_sea, SIGBUS, 0, "synchronous external abort" },
> { do_bad, SIGBUS, 0, "unknown 17" },
> { do_bad, SIGBUS, 0, "unknown 18" },
> { do_bad, SIGBUS, 0, "unknown 19" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error" },
> + { do_sea, SIGBUS, 0, "level 0 SEA (translation table walk)" },
> + { do_sea, SIGBUS, 0, "level 1 SEA (translation table walk)" },
> + { do_sea, SIGBUS, 0, "level 2 SEA (translation table walk)" },
> + { do_sea, SIGBUS, 0, "level 3 SEA (translation table walk)" },
Perhaps I wasn't clear enough in my previous review, but please expand the
acronym for strings and comments.
> + { do_sea, SIGBUS, 0, "synchronous parity or ECC err" },
s/err/error/
Will
^ permalink raw reply
* [v2 2/3] ARM: dts: STM32 Add USB FS host mode support
From: Alexandre Torgue @ 2017-01-16 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+TqcD9v=Z4BAprMoWNnDddmTkzKBAb8Yz1XnHLo0_2-995g@mail.gmail.com>
On 01/16/2017 11:26 AM, Bruno Herrera wrote:
> Hi Alex,
>
> On Mon, Jan 16, 2017 at 6:57 AM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
>> Hi Bruno,
>>
>> On 01/16/2017 03:09 AM, Bruno Herrera wrote:
>>>
>>> This patch adds the USB pins and nodes for USB HS/FS cores working at FS
>>> speed,
>>> using embedded PHY.
>>>
>>> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
>>
>>
>> Sorry, but what is patch 1 & pacth 3 status ?
>
> My bad, I'll add the status of the patch series version 3.
>>
>> For this one, can split it in 3 patches (one patch for SOC and one for each
>> board) please.
>>
>
> No problem.
>>
>>
>>> ---
>>> arch/arm/boot/dts/stm32f429-disco.dts | 30 ++++++++++++++++++++++++++++++
>>> arch/arm/boot/dts/stm32f429.dtsi | 35
>>> ++++++++++++++++++++++++++++++++++-
>>> arch/arm/boot/dts/stm32f469-disco.dts | 30 ++++++++++++++++++++++++++++++
>>> 3 files changed, 94 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
>>> b/arch/arm/boot/dts/stm32f429-disco.dts
>>> index 7d0415e..374c5ed 100644
>>> --- a/arch/arm/boot/dts/stm32f429-disco.dts
>>> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
>>> @@ -88,6 +88,16 @@
>>> gpios = <&gpioa 0 0>;
>>> };
>>> };
>>> +
>>> + /* This turns on vbus for otg for host mode (dwc2) */
>>> + vcc5v_otg: vcc5v-otg-regulator {
>>> + compatible = "regulator-fixed";
>>> + gpio = <&gpioc 4 0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usbotg_pwren_h>;
>>> + regulator-name = "vcc5_host1";
>>> + regulator-always-on;
>>> + };
>>> };
>>>
>>> &clk_hse {
>>> @@ -99,3 +109,23 @@
>>> pinctrl-names = "default";
>>> status = "okay";
>>> };
>>> +
>>> +&usbotg_hs {
>>> + compatible = "st,stm32-fsotg", "snps,dwc2";
>>> + dr_mode = "host";
>>> + pinctrl-0 = <&usbotg_fs_pins_b>;
>>> + pinctrl-names = "default";
>>> + status = "okay";
>>> +};
>>> +
>>> +&pinctrl {
>>> + usb-host {
>>> + usbotg_pwren_h: usbotg-pwren-h {
>>> + pins {
>>> + pinmux = <STM32F429_PC4_FUNC_GPIO>;
>>> + bias-disable;
>>> + drive-push-pull;
>>> + };
>>> + };
>>> + };
>>> +};
>>
>>
>> Pinctrl muxing has to be defined/declared in stm32f429.dtsi
>>
> This is board specific logic and it vary from board to board, should
> it be defined here?
Pinmuxing definition is a SOC part (as it is a possibility offered by
SOC). Pinmuxing choice is board specific.
Regarding your code, it should not boot. Ex for disco:
+ gpio = <&gpiob 2 0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usbotg_pwren_h>;
+
usb-host {
>>> + usbotg_pwren_h: usbotg-pwren-h {
>>> + pins {
>>> + pinmux = <STM32F429_PB2_FUNC_GPIO>;
Indeed, you are declaring two time the pin PB2 (one time through pinctrl
and one other time through gpiolib). in strict mode you can't request 2
times the same Pin.
I assume that your driver want controls this GPIO (request/set direction
/ set, get value ...). in this case you only need to declare this part:
gpio = <&gpiob 2 0>;
The GPIO lib will deal with pinctrl framework for you.
And in this case, yes gpio declaration is board specific so this part
will be in board file.
Let me know, if I'm not enough clear.
Regards
Alex
>>
>>
>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>> index e4dae0e..bc07aa8 100644
>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>> @@ -206,7 +206,7 @@
>>> reg = <0x40007000 0x400>;
>>> };
>>>
>>> - pin-controller {
>>> + pinctrl: pin-controller {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "st,stm32f429-pinctrl";
>>> @@ -316,6 +316,30 @@
>>> };
>>> };
>>>
>>> + usbotg_fs_pins_a: usbotg_fs at 0 {
>>> + pins {
>>> + pinmux =
>>> <STM32F429_PA10_FUNC_OTG_FS_ID>,
>>> +
>>> <STM32F429_PA11_FUNC_OTG_FS_DM>,
>>> +
>>> <STM32F429_PA12_FUNC_OTG_FS_DP>;
>>> + bias-disable;
>>> + drive-push-pull;
>>> + slew-rate = <2>;
>>> + };
>>> + };
>>> +
>>> + usbotg_fs_pins_b: usbotg_fs at 1 {
>>> + pins {
>>> + pinmux =
>>> <STM32F429_PB12_FUNC_OTG_HS_ID>,
>>> +
>>> <STM32F429_PB14_FUNC_OTG_HS_DM>,
>>> +
>>> <STM32F429_PB15_FUNC_OTG_HS_DP>;
>>> + bias-disable;
>>> + drive-push-pull;
>>> + slew-rate = <2>;
>>> + };
>>> + };
>>> +
>>> +
>>> +
>>> usbotg_hs_pins_a: usbotg_hs at 0 {
>>> pins {
>>> pinmux =
>>> <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
>>> @@ -420,6 +444,15 @@
>>> status = "disabled";
>>> };
>>>
>>> + usbotg_fs: usb at 50000000 {
>>> + compatible = "st,stm32f4xx-fsotg", "snps,dwc2";
>>> + reg = <0x50000000 0x40000>;
>>> + interrupts = <67>;
>>> + clocks = <&rcc 0 39>;
>>> + clock-names = "otg";
>>> + status = "disabled";
>>> + };
>>> +
>>> rng: rng at 50060800 {
>>> compatible = "st,stm32-rng";
>>> reg = <0x50060800 0x400>;
>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>> index 8877c00..8ae6763 100644
>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>> @@ -68,6 +68,17 @@
>>> soc {
>>> dma-ranges = <0xc0000000 0x0 0x10000000>;
>>> };
>>> +
>>> + /* This turns on vbus for otg for host mode (dwc2) */
>>> + vcc5v_otg: vcc5v-otg-regulator {
>>> + compatible = "regulator-fixed";
>>> + enable-active-high;
>>> + gpio = <&gpiob 2 0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usbotg_pwren_h>;
>>> + regulator-name = "vcc5_host1";
>>> + regulator-always-on;
>>> + };
>>> };
>>>
>>> &rcc {
>>> @@ -81,3 +92,22 @@
>>> &usart3 {
>>> status = "okay";
>>> };
>>> +
>>> +&usbotg_fs {
>>> + dr_mode = "host";
>>> + pinctrl-0 = <&usbotg_fs_pins_a>;
>>> + pinctrl-names = "default";
>>> + status = "okay";
>>> +};
>>> +
>>> +&pinctrl {
>>> + usb-host {
>>> + usbotg_pwren_h: usbotg-pwren-h {
>>> + pins {
>>> + pinmux = <STM32F429_PB2_FUNC_GPIO>;
>>> + bias-disable;
>>> + drive-push-pull;
>>> + };
>>> + };
>>> + };
>>> +};
>>
>> Same. Note that if you have 2 configuration for one feature (like it is here
>> for "usbotg_pwren_h"), you could index it. Not that I'm adding a dedidacted
>> pinctroller for stm32f469.
>>
> Sorry, but I dont know what you mean by index here.
> The usbotg_pwren_h (VBUS ENABLE) is attached in different port/pins
> for each board.
>
> Br.,
>
>
>> Br
>> Alex
>>>
>>>
>>
>>
^ permalink raw reply
* [PATCH] arm64: Fix swiotlb fallback allocation
From: Alexander Graf @ 2017-01-16 11:46 UTC (permalink / raw)
To: linux-arm-kernel
Commit b67a8b29df introduced logic to skip swiotlb allocation when all memory
is DMA accessible anyway.
While this is a great idea, __dma_alloc still calls swiotlb code unconditionally
to allocate memory when there is no CMA memory available. The swiotlb code is
called to ensure that we at least try get_free_pages().
Without initialization, swiotlb allocation code tries to access io_tlb_list
which is NULL. That results in a stack trace like this:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
[...]
[<ffff00000845b908>] swiotlb_tbl_map_single+0xd0/0x2b0
[<ffff00000845be94>] swiotlb_alloc_coherent+0x10c/0x198
[<ffff000008099dc0>] __dma_alloc+0x68/0x1a8
[<ffff000000a1b410>] drm_gem_cma_create+0x98/0x108 [drm]
[<ffff000000abcaac>] drm_fbdev_cma_create_with_funcs+0xbc/0x368 [drm_kms_helper]
[<ffff000000abcd84>] drm_fbdev_cma_create+0x2c/0x40 [drm_kms_helper]
[<ffff000000abc040>] drm_fb_helper_initial_config+0x238/0x410 [drm_kms_helper]
[<ffff000000abce88>] drm_fbdev_cma_init_with_funcs+0x98/0x160 [drm_kms_helper]
[<ffff000000abcf90>] drm_fbdev_cma_init+0x40/0x58 [drm_kms_helper]
[<ffff000000b47980>] vc4_kms_load+0x90/0xf0 [vc4]
[<ffff000000b46a94>] vc4_drm_bind+0xec/0x168 [vc4]
[...]
Thankfully swiotlb code just learned how to not do allocations with the FORCE_NO
option. This patch configures the swiotlb code to use that if we decide not to
initialize the swiotlb framework.
Fixes: b67a8b29df ("arm64: mm: only initialize swiotlb when necessary")
Signed-off-by: Alexander Graf <agraf@suse.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Jisheng Zhang <jszhang@marvell.com>
CC: Geert Uytterhoeven <geert+renesas@glider.be>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/arm64/mm/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 716d122..380ebe7 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -404,6 +404,8 @@ void __init mem_init(void)
if (swiotlb_force == SWIOTLB_FORCE ||
max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
swiotlb_init(1);
+ else
+ swiotlb_force = SWIOTLB_NO_FORCE;
set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
--
1.8.5.6
^ permalink raw reply related
* [PATCH] PCI: mvebu: change delay after reset to the PCIe spec mandated 100ms
From: Jason Cooper @ 2017-01-16 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116111142.6866-1-l.stach@pengutronix.de>
Hi Lucas,
On Mon, Jan 16, 2017 at 12:11:42PM +0100, Lucas Stach wrote:
> The current default of 20ms cause some devices, which are slow to initialize,
> to not show up during the bus scanning. Change this to the PCIe spec mandated
> 100ms and document this in the DT binding.
>
> From PCIe base spec rev 3.0, chapter "6.6.1. Conventional Reset":
>
> "To allow components to perform internal initialization, system software must
> wait a specified minimum period following the end of a Conventional Reset of
> one or more devices before it is permitted to issue Configuration Requests to
> those devices.
>
> With a Downstream Port that does not support Link speeds greater than
> 5.0 GT/s, software must wait a minimum of 100 ms before sending a
> Configuration Request to the device immediately below that Port."
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Documentation/devicetree/bindings/pci/mvebu-pci.txt | 3 ++-
> drivers/pci/host/pci-mvebu.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Lorenzo Pieralisi @ 2017-01-16 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58799376.6040302@huawei.com>
On Sat, Jan 14, 2017 at 10:56:54AM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2017/1/13 18:21, Lorenzo Pieralisi wrote:
> > On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
> >> With the preparation of platform msi support and interrupt producer
> >> in DSDT, we can add mbigen ACPI support now.
> >>
> >> We are using _PRS methd to indicate number of irq pins instead
> >> of num_pins in DT to avoid _DSD usage in this case.
> >>
> >> For mbi-gen,
> >> Device(MBI0) {
> >> Name(_HID, "HISI0152")
> >> Name(_UID, Zero)
> >> Name(_CRS, ResourceTemplate() {
> >> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> >> })
> >>
> >> Name (_PRS, ResourceTemplate() {
> >> Interrupt(ResourceProducer,...) {12,14,....}
> > I still do not understand why you are using _PRS for this, I think
> > the MBIgen configuration is static and if it is so the Interrupt
> > resource should be part of the _CRS unless there is something I am
> > missing here.
>
> Sorry for not clear in the commit message. MBIgen is an interrupt producer
> which produces irq resource to devices connecting to it, and MBIgen itself
> don't consume wired interrupts.
That's why you mark it as ResourceProducer, but that's not a reason to
put it in the _PRS instead of _CRS.
IIUC _PRS is there to provide a way to define the possible resource
settings of a _configurable_ device (ie programmable) so that the actual
resource value you would programme with a call to its _SRS is sane (ie
the OS has a way, through the _PRS, to detect what possible resource
settings are available for the device).
I think Rafael has more insights into how the _PRS is used on x86
systems so I would ask his point of view here before merrily merging
this code.
> Also devices connecting MBIgen may not consume all the interrupts produced
> by MBIgen, for example, MBIgen may produce 128 interrupts but only half of
> them are currently used, so _PRS here means "provide interrupt resources
> may consumed by devices connecting to it".
See above.
Lorenzo
^ 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