* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-11 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=mUHgTxvYpOYstE7rQn8fKS3QGiTT=FzBUc8DREvVuTeQ@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:28 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> [adding Marek and Shuah to cc list]
[snip]
>>>
>>> Please see below, I've had several bisection results pointing at
>>> that commit over the week-end on mainline but also on linux-next
>>> and net-next. While the peach-pi is a bit flaky at the moment
>>> and is likely to have more than one issue, it does seem like this
>>> commit is causing some well reproducible kernel hang.
>>>
>>> Here's a re-run with v4.15-rc3 showing the issue:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018478
>>>
>>> and here's another one with the change mentioned below reverted:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018479
>>>
>>> They both show a warning about "unbalanced disables for lcd_vdd",
>>> I don't know if this is related as I haven't investigated any
>>> further. It does appear to reliably hang with v4.15-rc3 and
>>> boot most of the time with the commit reverted though.
>>>
>>> The automated kernelci.org bisection is still an experimental
>>> tool and it may well be a false positive, so please take this
>>> result with a pinch of salt...
>>
>> The patch just very minimal moves the connector cleanup around (so
>> timing change), but except when you unload a driver (or maybe that
>> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
>> more info than "seems to hang a bit more" I have no idea what's wrong.
>> The patch itself should work, at least it survived quite some serious
>> testing we do on everything.
>> -Daniel
>>
>
> Marek was pointing to a different culprit [0] in this [1] thread. I
> see that both commits made it to v4.15-rc3, which is the first version
> where boot fails. So maybe is a combination of both? Or rather
> reverting one patch masks the error in the other.
>
> I've access to the machine but unfortunately not a lot of time to dig
> on this, I could try to do it in the weekend though.
>
> [0]: https://patchwork.kernel.org/patch/10067711/
> [1]: https://www.spinics.net/lists/arm-kernel/msg622152.html
>
So I gave a quick look to this, and at the very least there's a bug in
the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
exynos: Add status property to Exynos 542x Mixer nodes").
I've posted a fix for that:
https://patchwork.kernel.org/patch/10105921/
I believe this could be also be the cause for the boot failure, since
I see in the boot log that things start to go wrong after exynos-drm
fails to bind the HDMI component:
[ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
0xc1398690): -1
Anyway, I don't have access to the machine now, but it would be nice
if someone test. Or I would do in a few days.
Best regards,
Javier
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Russell King - ARM Linux @ 2017-12-11 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=m-fYZvYN4gLwBf8NwHvJb7PtNdVKR+SXgVKExZGtW4Qw@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas wrote:
> So I gave a quick look to this, and at the very least there's a bug in
> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
> exynos: Add status property to Exynos 542x Mixer nodes").
>
> I've posted a fix for that:
>
> https://patchwork.kernel.org/patch/10105921/
>
> I believe this could be also be the cause for the boot failure, since
> I see in the boot log that things start to go wrong after exynos-drm
> fails to bind the HDMI component:
>
> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
> 0xc1398690): -1
Umm, -1 ? Looking that error code up in
include/uapi/asm-generic/errno-base.h says it's -EPERM.
I suspect that's someone just returning -1 because they're lazy...
which is real bad form and needs fixing.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor
From: Richard Cochran @ 2017-12-11 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141435.2915-2-aleksey.makarov@cavium.com>
Sorry I didn't finish reviewing before...
On Mon, Dec 11, 2017 at 05:14:30PM +0300, Aleksey Makarov wrote:
> +/**
> + * cavium_ptp_adjfreq() - Adjust ptp frequency
> + * @ptp: PTP clock info
> + * @ppb: how much to adjust by, in parts-per-billion
> + */
> +static int cavium_ptp_adjfreq(struct ptp_clock_info *ptp_info, s32 ppb)
adjfreq() is deprecated. See ptp_clock_kernel.h. Please re-work this
to implement the adjfine() method instead.
> +/**
> + * cavium_ptp_enable() - Check if PTP is enabled
Nit - comment is not correct. This method is for the auxiliary PHC
functions.
> + * @ptp: PTP clock info
> + * @rq: request
> + * @on: is it on
> + */
> +static int cavium_ptp_enable(struct ptp_clock_info *ptp_info,
> + struct ptp_clock_request *rq, int on)
> +{
> + return -EOPNOTSUPP;
> +}
...
> +static int cavium_ptp_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct cavium_ptp *clock;
> + struct cyclecounter *cc;
> + u64 clock_cfg;
> + u64 clock_comp;
> + int err;
> +
> + clock = devm_kzalloc(dev, sizeof(*clock), GFP_KERNEL);
> + if (!clock)
> + return -ENOMEM;
> +
> + clock->pdev = pdev;
> +
> + err = pcim_enable_device(pdev);
> + if (err)
> + return err;
> +
> + err = pcim_iomap_regions(pdev, 1 << PCI_PTP_BAR_NO, pci_name(pdev));
> + if (err)
> + return err;
> +
> + clock->reg_base = pcim_iomap_table(pdev)[PCI_PTP_BAR_NO];
> +
> + spin_lock_init(&clock->spin_lock);
> +
> + cc = &clock->cycle_counter;
> + cc->read = cavium_ptp_cc_read;
> + cc->mask = CYCLECOUNTER_MASK(64);
> + cc->mult = 1;
> + cc->shift = 0;
> +
> + timecounter_init(&clock->time_counter, &clock->cycle_counter,
> + ktime_to_ns(ktime_get_real()));
> +
> + clock->clock_rate = ptp_cavium_clock_get();
> +
> + clock->ptp_info = (struct ptp_clock_info) {
> + .owner = THIS_MODULE,
> + .name = "ThunderX PTP",
> + .max_adj = 1000000000ull,
> + .n_ext_ts = 0,
> + .n_pins = 0,
> + .pps = 0,
> + .adjfreq = cavium_ptp_adjfreq,
> + .adjtime = cavium_ptp_adjtime,
> + .gettime64 = cavium_ptp_gettime,
> + .settime64 = cavium_ptp_settime,
> + .enable = cavium_ptp_enable,
> + };
> +
> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
> + clock_cfg |= PTP_CLOCK_CFG_PTP_EN;
> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
> +
> + clock_comp = ((u64)1000000000ull << 32) / clock->clock_rate;
> + writeq(clock_comp, clock->reg_base + PTP_CLOCK_COMP);
> +
> + clock->ptp_clock = ptp_clock_register(&clock->ptp_info, dev);
> + if (IS_ERR(clock->ptp_clock)) {
You need to handle the case when ptp_clock_register() returns NULL.
from ptp_clock_kernel.h:
/**
* ptp_clock_register() - register a PTP hardware clock driver
*
* @info: Structure describing the new clock.
* @parent: Pointer to the parent device of the new clock.
*
* Returns a valid pointer on success or PTR_ERR on failure. If PHC
* support is missing at the configuration level, this function
* returns NULL, and drivers are expected to gracefully handle that
* case separately.
*/
> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
> + clock_cfg &= ~PTP_CLOCK_CFG_PTP_EN;
> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
> + return PTR_ERR(clock->ptp_clock);
> + }
> +
> + pci_set_drvdata(pdev, clock);
> + return 0;
> +}
Thanks,
Richard
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Russell King - ARM Linux @ 2017-12-11 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211225829.GA1959@n2100.armlinux.org.uk>
On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas wrote:
> > So I gave a quick look to this, and at the very least there's a bug in
> > the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
> > exynos: Add status property to Exynos 542x Mixer nodes").
> >
> > I've posted a fix for that:
> >
> > https://patchwork.kernel.org/patch/10105921/
> >
> > I believe this could be also be the cause for the boot failure, since
> > I see in the boot log that things start to go wrong after exynos-drm
> > fails to bind the HDMI component:
> >
> > [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
> > 0xc1398690): -1
>
> Umm, -1 ? Looking that error code up in
> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>
> I suspect that's someone just returning -1 because they're lazy...
> which is real bad form and needs fixing.
Oh, it really is -EPERM:
struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device *drm_dev,
enum exynos_drm_output_type out_type)
{
struct drm_crtc *crtc;
drm_for_each_crtc(crtc, drm_dev)
if (to_exynos_crtc(crtc)->type == out_type)
return to_exynos_crtc(crtc);
return ERR_PTR(-EPERM);
}
Does "Operation not permitted" really convey the error here? It doesn't
look like a permission error to me.
Can we please avoid abusing errno codes?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Fabio Estevam @ 2017-12-11 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3BB206AB2B1BD448954845CE6FF69A8E01CB53233C@NT-Mail07.beckhoff.com>
Hi Patrick,
On Mon, Dec 11, 2017 at 5:08 AM, Patrick Br?nn <P.Bruenn@beckhoff.com> wrote:
>>rtc at ...
>>
> The rtc for which this series adds support is embedded within a function block called
> "Secure Real Time Clock". This driver doesn't utilize all of the hardware features by
> now. But maybe someone else wants to extend the functionalities, later.
> For that possibility I wanted to name the node "srtc". Should I still change this?
>
> I believe you have a much better understanding of what should be done here. I don't
> want to argue with you, just thought you might not had that information. So if I am
> wrong just tell me and I will change it without further "complaining".
>From the Devicetree Specification document:
"Generic Names Recommendation
The name of a node should be somewhat generic, reflecting the function
of the device and not its precise program-
ming model. If appropriate, the name should be one of the following choices:
...
rtc
"
So better use 'rtc' as suggested by Rob.
^ permalink raw reply
* [PATCH v3] net: ethernet: arc: fix error handling in emac_rockchip_probe
From: Branislav Radocaj @ 2017-12-11 23:13 UTC (permalink / raw)
To: linux-arm-kernel
If clk_set_rate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Changes since v2 [1]:
* Merged with latest code changes
Changes since v1:
Update made thanks to David's review, much appreciated David.
* Improved inconsistent failure handling of clock rate setting
* For completeness of usecase, added arc_emac_probe error handling
Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
---
[1] https://marc.info/?l=linux-netdev&m=151301239802445&w=2
---
drivers/net/ethernet/arc/emac_rockchip.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index c6163874e4e7..16f9bee992fe 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -199,9 +199,11 @@ static int emac_rockchip_probe(struct platform_device *pdev)
/* RMII interface needs always a rate of 50MHz */
err = clk_set_rate(priv->refclk, 50000000);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change reference clock rate (%d)\n", err);
+ goto out_regulator_disable;
+ }
if (priv->soc_data->need_div_macclk) {
priv->macclk = devm_clk_get(dev, "macclk");
@@ -230,12 +232,14 @@ static int emac_rockchip_probe(struct platform_device *pdev)
err = arc_emac_probe(ndev, interface);
if (err) {
dev_err(dev, "failed to probe arc emac (%d)\n", err);
- goto out_regulator_disable;
+ goto out_clk_disable_macclk;
}
return 0;
+
out_clk_disable_macclk:
- clk_disable_unprepare(priv->macclk);
+ if (priv->soc_data->need_div_macclk)
+ clk_disable_unprepare(priv->macclk);
out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] watchdog: davinci_wdt: add restart function
From: Guenter Roeck @ 2017-12-11 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513012869-7647-2-git-send-email-david@lechnology.com>
On Mon, Dec 11, 2017 at 11:21:08AM -0600, David Lechner wrote:
> This adds a restart function to the davinci watchdog timer driver.
>
> This is copied from arch/arm/mach-davinci/time.c and will allow us to
> remove the code from there.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/davinci_wdt.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
> index 2f46487..3e4c592 100644
> --- a/drivers/watchdog/davinci_wdt.c
> +++ b/drivers/watchdog/davinci_wdt.c
> @@ -140,6 +140,42 @@ static unsigned int davinci_wdt_get_timeleft(struct watchdog_device *wdd)
> return wdd->timeout - timer_counter;
> }
>
> +static int davinci_wdt_restart(struct watchdog_device *wdd,
> + unsigned long action, void *data)
> +{
> + struct davinci_wdt_device *davinci_wdt = watchdog_get_drvdata(wdd);
> + u32 tgcr, wdtcr;
> +
> + /* disable, internal clock source */
> + iowrite32(0, davinci_wdt->base + TCR);
> +
> + /* reset timer, set mode to 64-bit watchdog, and unreset */
> + tgcr = 0;
> + iowrite32(tgcr, davinci_wdt->base + TGCR);
> + tgcr = TIMMODE_64BIT_WDOG | TIM12RS_UNRESET | TIM34RS_UNRESET;
> + iowrite32(tgcr, davinci_wdt->base + TGCR);
> +
> + /* clear counter and period regs */
> + iowrite32(0, davinci_wdt->base + TIM12);
> + iowrite32(0, davinci_wdt->base + TIM34);
> + iowrite32(0, davinci_wdt->base + PRD12);
> + iowrite32(0, davinci_wdt->base + PRD34);
> +
> + /* put watchdog in pre-active state */
> + wdtcr = WDKEY_SEQ0 | WDEN;
> + iowrite32(wdtcr, davinci_wdt->base + WDTCR);
> +
> + /* put watchdog in active state */
> + wdtcr = WDKEY_SEQ1 | WDEN;
> + iowrite32(wdtcr, davinci_wdt->base + WDTCR);
> +
> + /* write an invalid value to the WDKEY field to trigger a restart */
> + wdtcr = 0x00004000;
> + iowrite32(wdtcr, davinci_wdt->base + WDTCR);
> +
> + return 0;
> +}
> +
> static const struct watchdog_info davinci_wdt_info = {
> .options = WDIOF_KEEPALIVEPING,
> .identity = "DaVinci/Keystone Watchdog",
> @@ -151,6 +187,7 @@ static const struct watchdog_ops davinci_wdt_ops = {
> .stop = davinci_wdt_ping,
> .ping = davinci_wdt_ping,
> .get_timeleft = davinci_wdt_get_timeleft,
> + .restart = davinci_wdt_restart,
> };
>
> static int davinci_wdt_probe(struct platform_device *pdev)
> @@ -195,6 +232,7 @@ static int davinci_wdt_probe(struct platform_device *pdev)
>
> watchdog_set_drvdata(wdd, davinci_wdt);
> watchdog_set_nowayout(wdd, 1);
> + watchdog_set_restart_priority(wdd, 128);
>
> wdt_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> davinci_wdt->base = devm_ioremap_resource(dev, wdt_mem);
> --
> 2.7.4
>
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Shuah Khan @ 2017-12-11 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211230213.GB1959@n2100.armlinux.org.uk>
On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas wrote:
>>> So I gave a quick look to this, and at the very least there's a bug in
>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>
>>> I've posted a fix for that:
>>>
>>> https://patchwork.kernel.org/patch/10105921/
>>>
>>> I believe this could be also be the cause for the boot failure, since
>>> I see in the boot log that things start to go wrong after exynos-drm
>>> fails to bind the HDMI component:
>>>
>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>> 0xc1398690): -1
>>
>> Umm, -1 ? Looking that error code up in
>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>
>> I suspect that's someone just returning -1 because they're lazy...
>> which is real bad form and needs fixing.
>
> Oh, it really is -EPERM:
>
> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device *drm_dev,
> enum exynos_drm_output_type out_type)
> {
> struct drm_crtc *crtc;
>
> drm_for_each_crtc(crtc, drm_dev)
> if (to_exynos_crtc(crtc)->type == out_type)
> return to_exynos_crtc(crtc);
>
> return ERR_PTR(-EPERM);
> }
>
> Does "Operation not permitted" really convey the error here? It doesn't
> look like a permission error to me.
>
> Can we please avoid abusing errno codes?
I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
with top commit g968edbd worked just fine for me last Friday. I ran several
tests and everything checked out except the exynos-gsc lockdep issue I sent
a 4.14 patch for.
However, with 4.15-rc3, dmesg is gets filled with
[ 342.337181] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 342.337470] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 342.337851] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.382346] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.396682] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.399244] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.399496] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.399848] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.400163] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.400495] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.401294] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
[ 402.401595] [drm] Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer
Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
I will start bisect and try to isolate the problem. I suspect this is related to dts
changes perhaps? I used to this problem a while back and it has been fixed.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH net-next v5 2/2] net: thunderx: add timestamping support
From: Richard Cochran @ 2017-12-11 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141435.2915-3-aleksey.makarov@cavium.com>
On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote:
> diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
> index 4a02e618e318..204b234beb9d 100644
> --- a/drivers/net/ethernet/cavium/thunder/nic.h
> +++ b/drivers/net/ethernet/cavium/thunder/nic.h
> @@ -263,6 +263,8 @@ struct nicvf_drv_stats {
> struct u64_stats_sync syncp;
> };
>
> +struct cavium_ptp;
> +
> struct nicvf {
> struct nicvf *pnicvf;
> struct net_device *netdev;
> @@ -312,6 +314,12 @@ struct nicvf {
> struct tasklet_struct qs_err_task;
> struct work_struct reset_task;
>
> + /* PTP timestamp */
> + struct cavium_ptp *ptp_clock;
> + bool hw_rx_tstamp;
> + struct sk_buff *ptp_skb;
> + atomic_t tx_ptp_skbs;
It is disturbing that the above two fields are set in different
places. Shouldn't they be unified into one logical lock?
Here you clear them together:
> +static void nicvf_snd_ptp_handler(struct net_device *netdev,
> + struct cqe_send_t *cqe_tx)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> + struct skb_shared_hwtstamps ts;
> + u64 ns;
> +
> + nic = nic->pnicvf;
> +
> + /* Sync for 'ptp_skb' */
> + smp_rmb();
> +
> + /* New timestamp request can be queued now */
> + atomic_set(&nic->tx_ptp_skbs, 0);
> +
> + /* Check for timestamp requested skb */
> + if (!nic->ptp_skb)
> + return;
> +
> + /* Check if timestamping is timedout, which is set to 10us */
> + if (cqe_tx->send_status == CQ_TX_ERROP_TSTMP_TIMEOUT ||
> + cqe_tx->send_status == CQ_TX_ERROP_TSTMP_CONFLICT)
> + goto no_tstamp;
> +
> + /* Get the timestamp */
> + memset(&ts, 0, sizeof(ts));
> + ns = cavium_ptp_tstamp2time(nic->ptp_clock, cqe_tx->ptp_timestamp);
> + ts.hwtstamp = ns_to_ktime(ns);
> + skb_tstamp_tx(nic->ptp_skb, &ts);
> +
> +no_tstamp:
> + /* Free the original skb */
> + dev_kfree_skb_any(nic->ptp_skb);
> + nic->ptp_skb = NULL;
> + /* Sync 'ptp_skb' */
> + smp_wmb();
> +}
> +
but here you set the one:
> @@ -657,7 +697,12 @@ static void nicvf_snd_pkt_handler(struct net_device *netdev,
> prefetch(skb);
> (*tx_pkts)++;
> *tx_bytes += skb->len;
> - napi_consume_skb(skb, budget);
> + /* If timestamp is requested for this skb, don't free it */
> + if (skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS &&
> + !nic->pnicvf->ptp_skb)
> + nic->pnicvf->ptp_skb = skb;
> + else
> + napi_consume_skb(skb, budget);
> sq->skbuff[cqe_tx->sqe_ptr] = (u64)NULL;
> } else {
> /* In case of SW TSO on 88xx, only last segment will have
here you clear one:
> @@ -1319,12 +1382,28 @@ int nicvf_stop(struct net_device *netdev)
>
> nicvf_free_cq_poll(nic);
>
> + /* Free any pending SKB saved to receive timestamp */
> + if (nic->ptp_skb) {
> + dev_kfree_skb_any(nic->ptp_skb);
> + nic->ptp_skb = NULL;
> + }
> +
> /* Clear multiqset info */
> nic->pnicvf = nic;
>
> return 0;
> }
here you clear both:
> @@ -1394,6 +1473,12 @@ int nicvf_open(struct net_device *netdev)
> if (nic->sqs_mode)
> nicvf_get_primary_vf_struct(nic);
>
> + /* Configure PTP timestamp */
> + if (nic->ptp_clock)
> + nicvf_config_hw_rx_tstamp(nic, nic->hw_rx_tstamp);
> + atomic_set(&nic->tx_ptp_skbs, 0);
> + nic->ptp_skb = NULL;
> +
> /* Configure receive side scaling and MTU */
> if (!nic->sqs_mode) {
> nicvf_rss_init(nic);
here you set the other:
> @@ -1385,6 +1388,29 @@ nicvf_sq_add_hdr_subdesc(struct nicvf *nic, struct snd_queue *sq, int qentry,
> hdr->inner_l3_offset = skb_network_offset(skb) - 2;
> this_cpu_inc(nic->pnicvf->drv_stats->tx_tso);
> }
> +
> + /* Check if timestamp is requested */
> + if (!(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
> + skb_tx_timestamp(skb);
> + return;
> + }
> +
> + /* Tx timestamping not supported along with TSO, so ignore request */
> + if (skb_shinfo(skb)->gso_size)
> + return;
> +
> + /* HW supports only a single outstanding packet to timestamp */
> + if (!atomic_add_unless(&nic->pnicvf->tx_ptp_skbs, 1, 1))
> + return;
> +
> + /* Mark the SKB for later reference */
> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> +
> + /* Finally enable timestamp generation
> + * Since 'post_cqe' is also set, two CQEs will be posted
> + * for this packet i.e CQE_TYPE_SEND and CQE_TYPE_SEND_PTP.
> + */
> + hdr->tstmp = 1;
> }
and so it is completely non-obvious whether this is race free or not.
Thanks,
Richard
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171116232239.16823-1-lukma@denx.de>
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 4/4)
This series applies on top of linux-next/master (next-20171211)
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
arch/arm/mach-ep93xx/ts72xx.h | 9 +++
arch/arm/tools/mach-types | 1 +
5 files changed, 176 insertions(+), 12 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v5 1/4] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This commit adds include file guards to ts72xx.h
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 8a3206a54b39..7b7490f10fa9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -12,6 +12,9 @@
* febfd000 22800000 4K options register #2
*/
+#ifndef __TS72XX_H_
+#define __TS72XX_H_
+
#define TS72XX_MODEL_PHYS_BASE 0x22000000
#define TS72XX_MODEL_VIRT_BASE IOMEM(0xfebff000)
#define TS72XX_MODEL_SIZE 0x00001000
@@ -83,3 +86,4 @@ static inline int is_ts9420_installed(void)
TS72XX_OPTIONS2_TS9420);
}
#endif
+#endif /* __TS72XX_H_ */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/4] ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept parameters
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index f386ebae0163..141ae4c65a81 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -123,8 +123,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset = 0,
.chip_delay = 15,
- .partitions = ts72xx_nand_parts,
- .nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
.ctrl = {
.cmd_ctrl = ts72xx_nand_hwcontrol,
@@ -148,8 +146,8 @@ static struct platform_device ts72xx_nand_flash = {
.num_resources = ARRAY_SIZE(ts72xx_nand_resource),
};
-
-static void __init ts72xx_register_flash(void)
+void __init ts72xx_register_flash(struct mtd_partition *parts, int n,
+ resource_size_t start)
{
/*
* TS7200 has NOR flash all other TS72xx board have NAND flash.
@@ -157,16 +155,12 @@ static void __init ts72xx_register_flash(void)
if (board_is_ts7200()) {
ep93xx_register_flash(2, EP93XX_CS6_PHYS_BASE, SZ_16M);
} else {
- resource_size_t start;
-
- if (is_ts9420_installed())
- start = EP93XX_CS7_PHYS_BASE;
- else
- start = EP93XX_CS6_PHYS_BASE;
-
ts72xx_nand_resource[0].start = start;
ts72xx_nand_resource[0].end = start + SZ_16M - 1;
+ ts72xx_nand_data.chip.partitions = parts;
+ ts72xx_nand_data.chip.nr_partitions = n;
+
platform_device_register(&ts72xx_nand_flash);
}
}
@@ -257,7 +251,9 @@ static struct ep93xx_spi_info ts72xx_spi_info __initdata = {
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
- ts72xx_register_flash();
+ ts72xx_register_flash(ts72xx_nand_parts, ARRAY_SIZE(ts72xx_nand_parts),
+ is_ts9420_installed() ?
+ EP93XX_CS7_PHYS_BASE : EP93XX_CS6_PHYS_BASE);
platform_device_register(&ts72xx_rtc_device);
platform_device_register(&ts72xx_wdt_device);
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/4] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This patch extends readability of ts72xx.c code.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes to v4:
- Adjust the code to be applicable to linux-next/master
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 141ae4c65a81..17af9d834b51 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -31,6 +31,9 @@
#include "soc.h"
#include "ts72xx.h"
+/*************************************************************************
+ * IO map
+ *************************************************************************/
static struct map_desc ts72xx_io_desc[] __initdata = {
{
.virtual = (unsigned long)TS72XX_MODEL_VIRT_BASE,
@@ -201,10 +204,16 @@ static struct platform_device ts72xx_wdt_device = {
.num_resources = ARRAY_SIZE(ts72xx_wdt_resources),
};
+/*************************************************************************
+ * ETH
+ *************************************************************************/
static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
.phy_id = 1,
};
+/*************************************************************************
+ * TS72XX support code
+ *************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
/* Relative to EP93XX_CS1_PHYS_BASE */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 4/4] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
Changes for v3:
- Add SD card support (via SPI) for BK3
- Remove definition of apb:i2s bus
- Remove board registration of CPLD WDT device
- Add I2S platform device to BK3
- Add MAINTAINERS entry for BK3 maintainer
Changes for v4:
- Adjust the code to be applicable on top of linux-next/master
Changes for v5:
- Combine map_io to be reused across all ts72xx boards
---
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 136 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 155 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d195739f892..17e1263b085d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1258,6 +1258,12 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: drivers/net/ethernet/cavium/thunder/
+ARM/CIRRUS LOGIC BK3 MACHINE SUPPORT
+M: Lukasz Majewski <lukma@denx.de>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-ep93xx/ts72xx.c
+
ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
M: Alexander Shiyan <shc_work@mail.ru>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 61a75ca3684e..c095236d7ff8 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -21,6 +21,13 @@ config MACH_ADSSPHERE
Say 'Y' here if you want your kernel to support the ADS
Sphere board.
+config MACH_BK3
+ bool "Support Liebherr BK3.1"
+ select MACH_TS72XX
+ help
+ Say 'Y' here if you want your kernel to support the
+ Liebherr controller BK3.1.
+
config MACH_EDB93XX
bool
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 17af9d834b51..c089a2a4fe30 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -19,10 +19,15 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <linux/spi/mmc_spi.h>
+#include <linux/mmc/host.h>
#include <linux/platform_data/spi-ep93xx.h>
#include <mach/gpio-ep93xx.h>
#include <mach/hardware.h>
+#include <mach/irqs.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -50,6 +55,11 @@ static struct map_desc ts72xx_io_desc[] __initdata = {
.pfn = __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
.length = TS72XX_OPTIONS2_SIZE,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)TS72XX_CPLDVER_VIRT_BASE,
+ .pfn = __phys_to_pfn(TS72XX_CPLDVER_PHYS_BASE),
+ .length = TS72XX_CPLDVER_SIZE,
+ .type = MT_DEVICE,
}
};
@@ -212,6 +222,69 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
};
/*************************************************************************
+ * SPI SD/MMC host
+ *************************************************************************/
+#define BK3_EN_SDCARD_PHYS_BASE 0x12400000
+#define BK3_EN_SDCARD_PWR 0x0
+#define BK3_DIS_SDCARD_PWR 0x0C
+static void bk3_mmc_spi_setpower(struct device *dev, unsigned int vdd)
+{
+ void __iomem *pwr_sd = ioremap(BK3_EN_SDCARD_PHYS_BASE, SZ_4K);
+
+ if (!pwr_sd) {
+ pr_err("Failed to enable SD card power!");
+ return;
+ }
+
+ pr_debug("%s: SD card pwr %s VDD:0x%x\n", __func__,
+ !!vdd ? "ON" : "OFF", vdd);
+
+ if (!!vdd)
+ __raw_writeb(BK3_EN_SDCARD_PWR, pwr_sd);
+ else
+ __raw_writeb(BK3_DIS_SDCARD_PWR, pwr_sd);
+
+ iounmap(pwr_sd);
+}
+
+static struct mmc_spi_platform_data bk3_spi_mmc_data = {
+ .detect_delay = 500,
+ .powerup_msecs = 100,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
+ .caps = MMC_CAP_NONREMOVABLE,
+ .setpower = bk3_mmc_spi_setpower,
+};
+
+/*************************************************************************
+ * SPI Bus - SD card access
+ *************************************************************************/
+static struct spi_board_info bk3_spi_board_info[] __initdata = {
+ {
+ .modalias = "mmc_spi",
+ .platform_data = &bk3_spi_mmc_data,
+ .max_speed_hz = 7.4E6,
+ .bus_num = 0,
+ .chip_select = 0,
+ .mode = SPI_MODE_0,
+ },
+};
+
+/*
+ * This is a stub -> the FGPIO[3] pin is not connected on the schematic
+ * The all work is performed automatically by !SPI_FRAME (SFRM1) and
+ * goes through CPLD
+ */
+static int bk3_spi_chipselects[] __initdata = {
+ EP93XX_GPIO_LINE_F(3),
+};
+
+static struct ep93xx_spi_info bk3_spi_master __initdata = {
+ .chipselect = bk3_spi_chipselects,
+ .num_chipselect = ARRAY_SIZE(bk3_spi_chipselects),
+ .use_dma = 1,
+};
+
+/*************************************************************************
* TS72XX support code
*************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
@@ -285,3 +358,66 @@ MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
.init_late = ep93xx_init_late,
.restart = ep93xx_restart,
MACHINE_END
+
+/*************************************************************************
+ * EP93xx I2S audio peripheral handling
+ *************************************************************************/
+static struct resource ep93xx_i2s_resource[] = {
+ DEFINE_RES_MEM(EP93XX_I2S_PHYS_BASE, 0x100),
+ DEFINE_RES_IRQ_NAMED(IRQ_EP93XX_SAI, "spilink i2s slave"),
+};
+
+static struct platform_device ep93xx_i2s_device = {
+ .name = "ep93xx-spilink-i2s",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(ep93xx_i2s_resource),
+ .resource = ep93xx_i2s_resource,
+};
+
+/*************************************************************************
+ * BK3 support code
+ *************************************************************************/
+static struct mtd_partition bk3_nand_parts[] = {
+ {
+ .name = "System",
+ .offset = 0x00000000,
+ .size = 0x01e00000,
+ }, {
+ .name = "Data",
+ .offset = 0x01e00000,
+ .size = 0x05f20000
+ }, {
+ .name = "RedBoot",
+ .offset = 0x07d20000,
+ .size = 0x002e0000,
+ .mask_flags = MTD_WRITEABLE, /* force RO */
+ },
+};
+
+static void __init bk3_init_machine(void)
+{
+ ep93xx_init_devices();
+
+ ts72xx_register_flash(bk3_nand_parts, ARRAY_SIZE(bk3_nand_parts),
+ EP93XX_CS6_PHYS_BASE);
+
+ ep93xx_register_eth(&ts72xx_eth_data, 1);
+
+ ep93xx_register_spi(&bk3_spi_master, bk3_spi_board_info,
+ ARRAY_SIZE(bk3_spi_board_info));
+
+ /* Configure ep93xx's I2S to use AC97 pins */
+ ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_I2SONAC97);
+ platform_device_register(&ep93xx_i2s_device);
+}
+
+MACHINE_START(BK3, "Liebherr controller BK3.1")
+ /* Maintainer: Lukasz Majewski <lukma@denx.de> */
+ .atag_offset = 0x100,
+ .map_io = ts72xx_map_io,
+ .init_irq = ep93xx_init_irq,
+ .init_time = ep93xx_timer_init,
+ .init_machine = bk3_init_machine,
+ .init_late = ep93xx_init_late,
+ .restart = ep93xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 7b7490f10fa9..00b4941d29c9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -10,6 +10,7 @@
* febff000 22000000 4K model number register (bits 0-2)
* febfe000 22400000 4K options register
* febfd000 22800000 4K options register #2
+ * febfc000 23400000 4K CPLD version register
*/
#ifndef __TS72XX_H_
@@ -42,6 +43,10 @@
#define TS72XX_OPTIONS2_TS9420 0x04
#define TS72XX_OPTIONS2_TS9420_BOOT 0x02
+#define TS72XX_CPLDVER_PHYS_BASE 0x23400000
+#define TS72XX_CPLDVER_VIRT_BASE IOMEM(0xfebfc000)
+#define TS72XX_CPLDVER_SIZE 0x00001000
+
#ifndef __ASSEMBLY__
static inline int ts72xx_model(void)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index a9313b66f770..4eac94c1eb6f 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -345,6 +345,7 @@ mxlads MACH_MXLADS MXLADS 1851
linkstation_mini MACH_LINKSTATION_MINI LINKSTATION_MINI 1858
afeb9260 MACH_AFEB9260 AFEB9260 1859
imx27ipcam MACH_IMX27IPCAM IMX27IPCAM 1871
+bk3 MACH_BK3 BK3 1880
rd88f6183ap_ge MACH_RD88F6183AP_GE RD88F6183AP_GE 1894
realview_pba8 MACH_REALVIEW_PBA8 REALVIEW_PBA8 1897
realview_pbx MACH_REALVIEW_PBX REALVIEW_PBX 1901
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v5 2/2] net: thunderx: add timestamping support
From: Richard Cochran @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141435.2915-3-aleksey.makarov@cavium.com>
On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote:
> @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, struct pfc *cfg)
> }
> }
>
> +/* Enable or disable HW timestamping by BGX for pkts received on a LMAC */
> +static void nic_config_timestamp(struct nicpf *nic, int vf, struct set_ptp *ptp)
> +{
> + struct pkind_cfg *pkind;
> + u8 lmac, bgx_idx;
> + u64 pkind_val, pkind_idx;
> +
> + if (vf >= nic->num_vf_en)
> + return;
> +
> + bgx_idx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> + lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> +
> + pkind_idx = lmac + bgx_idx * MAX_LMAC_PER_BGX;
> + pkind_val = nic_reg_read(nic, NIC_PF_PKIND_0_15_CFG | (pkind_idx << 3));
> + pkind = (struct pkind_cfg *)&pkind_val;
> +
> + if (ptp->enable && !pkind->hdr_sl) {
> + /* Skiplen to exclude 8byte timestamp while parsing pkt
> + * If not configured, will result in L2 errors.
> + */
> + pkind->hdr_sl = 4;
> + /* Adjust max packet length allowed */
> + pkind->maxlen += (pkind->hdr_sl * 2);
> + bgx_config_timestamping(nic->node, bgx_idx, lmac, true);
> + nic_reg_write(nic,
> + NIC_PF_RX_ETYPE_0_7 | (1 << 3),
> + (ETYPE_ALG_ENDPARSE << 16) | ETH_P_1588);
don't need three lines for this function call.
> + } else if (!ptp->enable && pkind->hdr_sl) {
> + pkind->maxlen -= (pkind->hdr_sl * 2);
> + pkind->hdr_sl = 0;
> + bgx_config_timestamping(nic->node, bgx_idx, lmac, false);
> + nic_reg_write(nic,
> + NIC_PF_RX_ETYPE_0_7 | (1 << 3),
> + (1ULL << 16) | ETH_P_8021Q); /* reset value */
here neither. Also avoid comment on the LHS. If 1<<16 means "reset"
then just define a macro.
> + }
> +
> + nic_reg_write(nic, NIC_PF_PKIND_0_15_CFG | (pkind_idx << 3), pkind_val);
> +}
> +
Thanks,
Richard
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Hartley Sweeten @ 2017-12-11 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
On Monday, December 11, 2017 4:36 PM, Lukasz Majewski wrote:
> This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
>
> This patchset consists of following patches:
>
> - ts72xx.[c|h] cosmetic cleanup/improvement
> - Rewrite ts72xx.c to be reusable by bk3
> - The Liebherr's BK3 board has been added with re-using code of
> ts72xx.c (detalied list of changes can be found in patch 4/4)
>
> This series applies on top of linux-next/master (next-20171211)
>
> Lukasz Majewski (4):
> ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
> ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
> parameters
> ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
> ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
>
> MAINTAINERS | 6 ++
> arch/arm/mach-ep93xx/Kconfig | 7 ++
> arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
> arch/arm/mach-ep93xx/ts72xx.h | 9 +++
> arch/arm/tools/mach-types | 1 +
> 5 files changed, 176 insertions(+), 12 deletions(-)
Looks good. Thanks!
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT changes for v4.16
From: Kevin Hilman @ 2017-12-12 0:27 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
for you to fetch changes up to 71a3dfd07ce1a69060bf040f28799171aa6a4ed3:
ARM: meson: enable MESON_IRQ_GPIO also for MACH_MESON8 (2017-12-11 15:58:46 -0800)
----------------------------------------------------------------
Amlogic 32-bit DT changes for v4.16
- meson8: GPIO IRQ support
- switch to stable UART bindings w/correct clock
- add more L2 cache settings
- drop unused ADC clock
----------------------------------------------------------------
Martin Blumenstingl (6):
ARM: dts: meson8b: add more L2 cache settings
ARM: dts: meson8: add more L2 cache settings
ARM: dts: meson8: use stable UART bindings with correct gate clock
ARM: dts: meson8b: use stable UART bindings with correct gate clock
ARM: dts: meson8: enable the GPIO interrupt controller
ARM: meson: enable MESON_IRQ_GPIO also for MACH_MESON8
Xingyu Chen (1):
ARM: dts: meson: drop "sana" clock from SAR ADC
arch/arm/boot/dts/meson8.dtsi | 29 ++++++++++++++++++++++-------
arch/arm/boot/dts/meson8b.dtsi | 24 +++++++++++++++++-------
arch/arm/mach-meson/Kconfig | 1 +
3 files changed, 40 insertions(+), 14 deletions(-)
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.16
From: Kevin Hilman @ 2017-12-12 0:28 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
for you to fetch changes up to 3106507e1004dd398ef75d0caf048f97ba2dfd0b:
ARM64: dts: meson-gxm: fix q200 interrupt number (2017-12-08 10:47:28 -0800)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.16
- meson-gx: add VPU power domain support
- odroid-c2: add HDMI and CEC nodes
- misc cleanups
----------------------------------------------------------------
Jerome Brunet (1):
ARM64: dts: meson-gxm: fix q200 interrupt number
Kevin Hilman (1):
ARM64: dts: amlogic: use generic bus node names
Martin Blumenstingl (2):
ARM64: dts: meson: add comments with the GPIO for the PHY interrupts
ARM64: dts: meson-gxm: add the PHY interrupt line on Khadas VIM2
Neil Armstrong (4):
ARM64: dts: meson-gx: add VPU power domain
ARM64: dts: meson-gx: Add HDMI_5V regulator on selected boards
ARM64: dts: meson-gx: grow reset controller memory zone
ARM64: dts: odroid-c2: Add HDMI and CEC Nodes
Xingyu Chen (1):
ARM64: dts: meson: drop "sana" clock from SAR ADC
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++++++++----
arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 +
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 1 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 46 ++++++++++++++++++++++++++++++++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 46 ++++++++++++++++++++++++++++++++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts | 3 ++-
12 files changed, 192 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] arm: dts: uniphier: add efuse node for UniPhier 32bit SoC
From: Keiji Hayashibara @ 2017-12-12 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNARmYfnYpACrUtYccBPyjnvXg0ymA=WZ=+nGAtanaXZk1w@mail.gmail.com>
Hello Yamada-san,
Sorry, I will be careful next time.
I was checking with the command of
"get_maintainer.pl -f arch/arm/boot/dts/".
Thank you.
Best Regards,
Keiji Hayashibara
> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
> Sent: Tuesday, December 12, 2017 1:06 AM
>
> 2017-12-04 17:12 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> > Add efuse node for UniPhier LD4, Pro4, sLD8, Pro5 and PXs2.
> > This efuse node is included in soc-glue.
> >
> > Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> > ---
> > arch/arm/boot/dts/uniphier-ld4.dtsi | 18 ++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pro4.dtsi | 23 +++++++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pro5.dtsi | 33
> > +++++++++++++++++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pxs2.dtsi | 18 ++++++++++++++++++
> > arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++++++++++++++++++
> > 5 files changed, 110 insertions(+)
>
>
> Applied to linux-uniphier,
> but please reconsider To: list next time.
>
> This patch was addressed to Rob and Mark, but they do not pick up platform DT patches.
>
>
> You do not need to get Rob's Ack for a patch like this.
>
>
> Binding is a contract between operation system and DT.
>
> The binding for this
> (Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt)
> was approved by Rob and merged in the mainline.
>
> Given that this patch follows the binding correctly, it should be safe.
>
> Thanks.
>
>
>
> > diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi
> > b/arch/arm/boot/dts/uniphier-ld4.dtsi
> > index 01fc3e1..6883f3b 100644
> > --- a/arch/arm/boot/dts/uniphier-ld4.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
> > @@ -273,6 +273,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-ld4-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > + };
> > +
> > timer at 60000200 {
> > compatible = "arm,cortex-a9-global-timer";
> > reg = <0x60000200 0x20>; diff --git
> > a/arch/arm/boot/dts/uniphier-pro4.dtsi
> > b/arch/arm/boot/dts/uniphier-pro4.dtsi
> > index 7955c3a..150726b 100644
> > --- a/arch/arm/boot/dts/uniphier-pro4.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
> > @@ -294,6 +294,29 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pro4-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x14>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pro4-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-pro5.dtsi
> > b/arch/arm/boot/dts/uniphier-pro5.dtsi
> > index 6589b8a..f291dd6 100644
> > --- a/arch/arm/boot/dts/uniphier-pro5.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
> > @@ -355,6 +355,39 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pro5-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x28>;
> > + };
> > +
> > + efuse at 300 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x300 0x14>;
> > + };
> > +
> > + efuse at 400 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x400 0x8>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pro5-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > index d82d6d8..8e54e87 100644
> > --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > @@ -375,6 +375,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pxs2-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x58>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pxs2-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-sld8.dtsi
> > b/arch/arm/boot/dts/uniphier-sld8.dtsi
> > index 7188536..afafe7c 100644
> > --- a/arch/arm/boot/dts/uniphier-sld8.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
> > @@ -277,6 +277,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-sld8-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x14>;
> > + };
> > + };
> > +
> > timer at 60000200 {
> > compatible = "arm,cortex-a9-global-timer";
> > reg = <0x60000200 0x20>;
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Masahiro Yamada
^ permalink raw reply
* [PATCH v5 2/9] ACPI/PPTT: Add Processor Properties Topology Table parsing
From: Rafael J. Wysocki @ 2017-12-12 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-3-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:23 PM CET Jeremy Linton wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, COD (clusters
> on die), within a given package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
This is only going to be used by ARM64 for the time being, so I need
someone from that camp to review this.
Sudeep, Hanjun, Lorenzo?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Rafael J. Wysocki @ 2017-12-12 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-5-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:25 PM CET Jeremy Linton wrote:
> Add a entry to to struct cacheinfo to maintain a reference to the PPTT
> node which can be used to match identical caches across cores. Also
> stub out cache_setup_acpi() so that individual architectures can
> enable ACPI topology parsing.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/pptt.c | 1 +
> drivers/base/cacheinfo.c | 20 ++++++++++++++------
> include/linux/cacheinfo.h | 13 ++++++++++++-
> 3 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index 0f8a1631af33..a35e457cefb7 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -329,6 +329,7 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
> {
> int valid_flags = 0;
>
> + this_leaf->firmware_node = cpu_node;
> if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
> this_leaf->size = found_cache->size;
> valid_flags++;
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index eb3af2739537..ba89f9310e6f 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -86,7 +86,10 @@ static int cache_setup_of_node(unsigned int cpu)
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> {
> - return sib_leaf->of_node == this_leaf->of_node;
> + if (acpi_disabled)
> + return sib_leaf->of_node == this_leaf->of_node;
> + else
> + return sib_leaf->firmware_node == this_leaf->firmware_node;
> }
>
> /* OF properties to query for a given cache type */
> @@ -215,6 +218,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> }
> #endif
>
> +int __weak cache_setup_acpi(unsigned int cpu)
> +{
> + return -ENOTSUPP;
> +}
> +
> static int cache_shared_cpu_map_setup(unsigned int cpu)
> {
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> @@ -225,11 +233,11 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
> if (this_cpu_ci->cpu_map_populated)
> return 0;
>
> - if (of_have_populated_dt())
> + if (!acpi_disabled)
> + ret = cache_setup_acpi(cpu);
> + else if (of_have_populated_dt())
> ret = cache_setup_of_node(cpu);
> - else if (!acpi_disabled)
> - /* No cache property/hierarchy support yet in ACPI */
> - ret = -ENOTSUPP;
> +
> if (ret)
> return ret;
>
> @@ -286,7 +294,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
>
> static void cache_override_properties(unsigned int cpu)
> {
> - if (of_have_populated_dt())
> + if (acpi_disabled && of_have_populated_dt())
> return cache_of_override_properties(cpu);
> }
>
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index 3d9805297cda..7ebff157ae6c 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -37,6 +37,8 @@ enum cache_type {
> * @of_node: if devicetree is used, this represents either the cpu node in
> * case there's no explicit cache node or the cache node itself in the
> * device tree
> + * @firmware_node: When not using DT, this may contain pointers to other
> + * firmware based values. Particularly ACPI/PPTT unique values.
> * @disable_sysfs: indicates whether this node is visible to the user via
> * sysfs or not
> * @priv: pointer to any private data structure specific to particular
> @@ -65,8 +67,8 @@ struct cacheinfo {
> #define CACHE_ALLOCATE_POLICY_MASK \
> (CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
> #define CACHE_ID BIT(4)
> -
> struct device_node *of_node;
> + void *firmware_node;
What about converting this to using struct fwnode instead of adding
fields to it?
> bool disable_sysfs;
> void *priv;
> };
> @@ -99,6 +101,15 @@ int func(unsigned int cpu) \
> struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
> int init_cache_level(unsigned int cpu);
> int populate_cache_leaves(unsigned int cpu);
> +int cache_setup_acpi(unsigned int cpu);
> +int acpi_find_last_cache_level(unsigned int cpu);
> +#ifndef CONFIG_ACPI
> +int acpi_find_last_cache_level(unsigned int cpu)
> +{
> + /*ACPI kernels should be built with PPTT support*/
> + return 0;
> +}
> +#endif
>
> const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
>
>
Thanks,
Rafael
^ permalink raw reply
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: Rafael J. Wysocki @ 2017-12-12 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-7-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> The PPTT can be used to determine the groupings of CPU's at
> given levels in the system. Lets add a few routines to the PPTT
> parsing code to return a unique id for each unique level in the
> processor hierarchy. This can then be matched to build
> thread/core/cluster/die/package/etc mappings for each processing
> element in the system.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Why can't this be folded into patch [2/9]?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Rafael J. Wysocki @ 2017-12-12 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211075719.GD25177@vireshk-i7>
On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> > Add opp v2 information,
> > and also add clocks, regulators and opp information into cpu nodes
> >
> > Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
> > arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
> > 2 files changed, 84 insertions(+)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Of course, DT bindings require ACKs from DT maintainers to be applied.
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: gengdongjiu @ 2017-12-12 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211132914.GJ22781@e103592.cambridge.arm.com>
On 2017/12/11 21:29, Dave Martin wrote:
>> Thanks for the point out.
>> In fact, this feature only adds two instructions:
>> FP16 * FP16 + FP32
>> FP16 * FP16 - FP32
>>
>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>> will call "FHM", I think call it "FMLXL" may be better, which can
>> stand for FMLAL/FMLSL instructions.
> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
> to match the ISAR0 field name -- we've tended to follow this policy
> for other extension names unless there's a much better or more obvious
> name available
Agree with you, I also think the "FHM" is better.
>
> For "FMLXL", new instructions might be added in the future that match
> the same pattern, and then "FMLXL" could become ambiguous. So maybe
> this is not the best choice.
Ok.
>
>>> Maybe something like "widening half-precision floating-point multiply
>>> accumulate" is acceptable wording consistent with the existing
>>> architecture, but I just made that up, so it's not official ;)
>> how about something like "performing a multiplication of each FP16
>> element of one vector with the corresponding FP16 element of a second
>> vector, and to add or subtract this without an intermediate rounding
>> to the corresponding FP32 element in a third vector."?
> We could have that, I guess.
Ok, thanks!
>
>>>> instructions set. Let the userspace know about it via a
>>>> HWCAP bit and MRS emulation.
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: gengdongjiu @ 2017-12-12 2:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ebb6a36-0e09-1ac1-7785-cc9d4e4147fb@arm.com>
On 2017/12/12 2:58, Suzuki K Poulose wrote:
> Hi gengdongjiu
>
> Sorry for the late response. I have a similar patch to add the support for "FHM", which I was about to post it this week.
Suzuki, you are welcome.
May be you can not post again to avoid the duplicate review, thanks!
>
> On 11/12/17 13:29, Dave Martin wrote:
>> On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote:
>>>
>>> On 2017/12/11 19:59, Dave P Martin wrote:
>>>> On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote:
>>>>> ARM v8.4 extensions include support for new floating point
>>>>> multiplication variant instructions to the AArch64 SIMD
>>>>
>>>> Do we have any human-readable description of what the new instructions
>>>> do?
>>>>
>>>> Since the v8.4 spec itself only describes these as "New Floating
>>>> Point Multiplication Variant", I wonder what "FHM" actually stands
>>>> for.
>>> Thanks for the point out.
>>> In fact, this feature only adds two instructions:
>>> FP16 * FP16 + FP32
>>> FP16 * FP16 - FP32
>>>
>>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>>> will call "FHM", I? think call it "FMLXL" may be better, which can
>>> stand for FMLAL/FMLSL instructions.
>>
>> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
>> to match the ISAR0 field name -- we've tended to follow this policy
>> for other extension names unless there's a much better or more obvious
>> name available.
>>
>> For "FMLXL", new instructions might be added in the future that match
>> the same pattern, and then "FMLXL" could become ambiguous.? So maybe
>> this is not the best choice.
>
> I think the FHM stands for "FP Half precision Multiplication instructions". I vote for keeping the feature bit in sync with the register bit definition. i.e, FHM.
agree with you
>
> However, my version of the patch names the HWCAP bit "asimdfml", following the compiler name for the feature option "fp16fml", which
> is not perfect either. I think FHM is the safe option here.
yes, "FHM" is safe here.
>
>>
>>>> Maybe something like "widening half-precision floating-point multiply
>>>> accumulate" is acceptable wording consistent with the existing
>>>> architecture, but I just made that up, so it's not official ;)
>>>
>>> how about something like "performing a multiplication of each FP16
>>> element of one vector with the corresponding FP16 element of a second
>>> vector, and to add or subtract this without an intermediate rounding
>>> to the corresponding FP32 element in a third vector."?
>>
>> We could have that, I guess.
>>
>
> I agree, and that matches the feature description.
Ok, thanks!
>
>
^ 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