* [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 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 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
* 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 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
* [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 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
* 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 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 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
* 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
* [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-11 22:48 UTC (permalink / raw)
To: linux-arm-kernel
Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
I believe this may cause the boot issues reported on Exynos5800 Peach Pi
from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
management in the DP driver.
I can't test right now, but I'm posting anyways as a RFT in case others
that have access to a Peach Pi can test it.
Best regards,
Javier
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
};
+&mixer {
+ status = "okay";
+};
+
/* eMMC flash */
&mmc_0 {
status = "okay";
--
2.14.3
^ permalink raw reply related
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB156535B0FBBAF51FE274F0A7D0370@SN1PR0101MB1565.prod.exchangelabs.com>
Hi Hartley,
> On Monday, December 11, 2017 2:40 PM, Lukasz Majewski wrote:
> > Hi Hartley,
> >
> >> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
> >>>
> >>> The BK3 board is a derivative of the ts72xx reference design.
> >>
> >> Lukasz,
> >>
> >> I was just reviewing the other TS-72xx boards and noticed this:
> >>
> >> <snip>
> >>
> >>> +/* BK3 specific defines */
> >>> +#define BK3_CPLDVER_PHYS_BASE 0x23400000
> >>> +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
> >>> +#define BK3_CPLDVER_SIZE 0x00001000
> >>> +
> >>
> >> <snip>
> >>
> >>> +static struct map_desc bk3_io_desc[] __initdata = {
> >>> + {
> >>> + .virtual = BK3_CPLDVER_VIRT_BASE,
> >>> + .pfn =
> >>> __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
> >>> + .length = BK3_CPLDVER_SIZE,
> >>> + .type = MT_DEVICE,
> >>> + }
> >>> +};
> >>> +
> >>
> >> This register appears to be common to all the TS-72xx boards.
> >
> > The CPLD was used on the reference ts-72xx boards, but support for
> > it seems to not be present in the mainline kernel.
>
> The CPLD is not directly called out but some parts of it are
> supported in the mainline kernel.
>
> The RTC index and data registers are chip selected by the CPLD and
> Watchdog is in the CPLD. Also, the model number, options, and
> options2 registers are in the CPLD.
>
> There are a couple other registers in the CPLD that are not currently
> present in mainline. Some aren't because I haven't figured a good way
> to utilize them (the COM2 RS485 registers and the PC/104 memory/IO
> spaces) or they simply have not been necessary yet (the two status
> registers). There are a couple listed in the manuals that are
> specific to the TS-7260 that also have not been added.
>
> Basically, anything in the EP93xx CS1 or CS2 memory region is in or
> controlled by the CPLD.
>
> > Do you have a ts72xx board with CPLD embedded? Is any of your
> > design using it?
>
> I have a stock TS-7300 board.
>
> > My another concern - is it safe to perform IO mapping on memory
> > regions which are not used / specified?
>
> The mapping is safe. If there is nothing at the address you just read
> back the static state (noise) of the bus and writing doesn't do
> anything.
Ok.
>
> > When I do a single ts72xx mapping - for all boards - then we may
> > end up with some mappings which are not needed.
>
> True, but it's harmless and it keeps the platform init code cleaner.
I will add all the mappings.
>
> > With the code as it is - I only map regions which are already used
> > on relevant boards.
>
> Yes, but this register in particular exists in the CPLD on all the
> TS-72xx boards.
>
> >> I don't think Arnd has pulled the series yet. Would you mind
> >> renaming the defines and rebasing this patch?
> >
> > If needed I can resend the patch series, or prepare a single fix
> > patch. No problem.
>
> Fixing it after Arnd merges your series is fine. I just wanted to
> make sure it was pointed out.
I've checked a few minutes ago and it seems like arm-soc hasn't been
pulled to for-next.
I may resend the whole series.
>
> BTW, is there a reason the BK3 board needs this register mapped? It
> was mapped in the Technologic Systems 2.4, 2.6, and 3.x kernels but I
> never found anything that used it.
It is used to check the version. BK3 has some CPLD modifications and
it is important to know which version we do have as the board is
already deployed for some time in the field.
> Of course the stock boards
> probably always had the same revision in the CPLD, the BK3 board
> might have multiple revisions...
Yes, correct.
>
> Hartley
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/4003dd39/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni @ 2017-12-11 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513032152-13211-1-git-send-email-shankerd@codeaurora.org>
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
Changes since v3:
Rebased to kernel v4.15-rc3 and removed the alternatives.
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost the corrected patches.
Changes since v1:
Apply the workaround where it's required.
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 +++++++++++-
arch/arm64/include/asm/assembler.h | 10 ++++++++++
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S | 1 +
arch/arm64/kvm/hyp-init.S | 1 +
8 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 304bf22..fc1c884 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -75,3 +75,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f..c9a7e9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -557,7 +557,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
@@ -576,6 +575,17 @@ config HISILICON_ERRATUM_161600802
a 128kB offset to be applied to the target address in this commands.
If unsure, say Y.
+
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index aef72d8..8b16828 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -512,4 +512,14 @@
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..2a752cb 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -37,6 +37,7 @@ ENTRY(__cpu_soft_restart)
mrs x12, sctlr_el1
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
+ pre_disable_mmu_workaround
msr sctlr_el1, x12
isb
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..6b9736c 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -96,6 +96,7 @@ ENTRY(entry)
mrs x0, sctlr_el2
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
b 2f
@@ -103,6 +104,7 @@ ENTRY(entry)
mrs x0, sctlr_el1
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el1, x0
isb
2:
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 67e86a0..e3cb9fb 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -750,6 +750,7 @@ __primary_switch:
* to take into account by discarding the current kernel mapping and
* creating a new one.
*/
+ pre_disable_mmu_workaround
msr sctlr_el1, x20 // disable the MMU
isb
bl __create_page_tables // recreate kernel mapping
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index ce704a4..f407e42 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -45,6 +45,7 @@ ENTRY(arm64_relocate_new_kernel)
mrs x0, sctlr_el2
ldr x1, =SCTLR_ELx_FLAGS
bic x0, x0, x1
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
1:
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3f96155..870828c 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -151,6 +151,7 @@ reset:
mrs x5, sctlr_el2
ldr x6, =SCTLR_ELx_FLAGS
bic x5, x5, x6 // Clear SCTL_M and etc
+ pre_disable_mmu_workaround
msr sctlr_el2, x5
isb
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v5 1/2] arm64: Define cputype macros for Falkor CPU
From: Shanker Donthineni @ 2017-12-11 22:42 UTC (permalink / raw)
To: linux-arm-kernel
Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
#define BRCM_CPU_PART_VULCAN 0x516
#define QCOM_CPU_PART_FALKOR_V1 0x800
+#define QCOM_CPU_PART_FALKOR 0xC00
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
#ifndef __ASSEMBLY__
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Shuah Khan @ 2017-12-11 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b46b554a-eab0-6167-3fb2-484cd1f11ffd@samsung.com>
Hi Marek,
On 12/11/2017 03:43 AM, Marek Szyprowski wrote:
> Hi Shuah,
>
> Do you have a bit of spare time for Exynos kernel development? Could you investigate why Peach-Pi(t) Chromebooks fails to boot with recent kernels? If I remember correctly, you had access to those boards.
Unfortunately I don't have Peach-Pi(t) Chromebook.
thanks,
-- Shuah
^ permalink raw reply
* [v7, 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl, imx6q-snvs-lpgpr" node
From: Maciej S. Szmigiero @ 2017-12-11 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170620070932.10353-4-o.rempel@pengutronix.de>
On 20.06.2017 09:09, Oleksij Rempel wrote:
> This node is for Low Power General Purpose Register which can
> be used as Non-Volatile Storage.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
> arch/arm/boot/dts/imx6ul.dtsi | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index e426faa9c243..94e992558238 100644
(..)
FYI: It looks to me that while the driver itself from this series was
picked up and eventually reached Linus' tree this DT change was
forgotten, since I can't find in any tree (or am I not looking at the
right place?).
Maciej
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uFcGftSeQjkKu9SZmkQd8-irbUTMcOnUwi7HZtb5TePag@mail.gmail.com>
[adding Marek and Shuah to cc list]
On Mon, Dec 11, 2017 at 6:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Mon, Dec 11, 2017 at 11:30 AM, Guillaume Tucker
> <guillaume.tucker@collabora.com> wrote:
>> Hi Daniel,
>>
>> 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
Best regards,
Javier
>> Hope this helps!
>>
>> Best wishes,
>> Guillaume
>>
>>
>> -------- Forwarded Message --------
>> Subject: mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
>> Date: Mon, 11 Dec 2017 08:25:55 +0000 (UTC)
>> From: kernelci.org bot <bot@kernelci.org>
>> To: guillaume.tucker at collabora.com
>>
>> Bisection result for mainline/master (v4.15-rc3) on peach-pi
>>
>> Good known revision:
>>
>> c6b3e96 Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>>
>> Bad known revision:
>>
>> 50c4c4e Linux 4.15-rc3
>>
>> Extra parameters:
>>
>> Tree: mainline
>> Branch: master
>> Target: peach-pi
>> Lab: lab-collabora
>> Defconfig: exynos_defconfig
>> Plan: boot
>>
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit a703c55004e1c5076d57e43771b3e11117796ea0
>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Date: Mon Dec 4 21:48:18 2017 +0100
>>
>> drm: safely free connectors from connector_iter
>> In
>> commit 613051dac40da1751ab269572766d3348d45a197
>> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Date: Wed Dec 14 00:08:06 2016 +0100
>> drm: locking&new iterators for connector_list
>> we've went to extreme lengths to make sure connector iterations
>> works
>> in any context, without introducing any additional locking context.
>> This worked, except for a small fumble in the implementation:
>> When we actually race with a concurrent connector unplug event, and
>> our temporary connector reference turns out to be the final one, then
>> everything breaks: We call the connector release function from
>> whatever context we happen to be in, which can be an irq/atomic
>> context. And connector freeing grabs all kinds of locks and stuff.
>> Fix this by creating a specially safe put function for
>> connetor_iter,
>> which (in this rare case) punts the cleanup to a worker.
>> Reported-by: Ben Widawsky <ben@bwidawsk.net>
>> Cc: Ben Widawsky <ben@bwidawsk.net>
>> Fixes: 613051dac40d ("drm: locking&new iterators for connector_list")
>> Cc: Dave Airlie <airlied@gmail.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: <stable@vger.kernel.org> # v4.11+
>> Reviewed-by: Dave Airlie <airlied@gmail.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel.vetter at ffwll.ch
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index 25f4b2e..4820141 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -152,6 +152,16 @@ static void drm_connector_free(struct kref *kref)
>> connector->funcs->destroy(connector);
>> }
>> +static void drm_connector_free_work_fn(struct work_struct *work)
>> +{
>> + struct drm_connector *connector =
>> + container_of(work, struct drm_connector, free_work);
>> + struct drm_device *dev = connector->dev;
>> +
>> + drm_mode_object_unregister(dev, &connector->base);
>> + connector->funcs->destroy(connector);
>> +}
>> +
>> /**
>> * drm_connector_init - Init a preallocated connector
>> * @dev: DRM device
>> @@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device *dev,
>> if (ret)
>> return ret;
>> + INIT_WORK(&connector->free_work, drm_connector_free_work_fn);
>> +
>> connector->base.properties = &connector->properties;
>> connector->dev = dev;
>> connector->funcs = funcs;
>> @@ -529,6 +541,18 @@ void drm_connector_list_iter_begin(struct drm_device
>> *dev,
>> }
>> EXPORT_SYMBOL(drm_connector_list_iter_begin);
>> +/*
>> + * Extra-safe connector put function that works in any context. Should only
>> be
>> + * used from the connector_iter functions, where we never really expect to
>> + * actually release the connector when dropping our final reference.
>> + */
>> +static void
>> +drm_connector_put_safe(struct drm_connector *conn)
>> +{
>> + if (refcount_dec_and_test(&conn->base.refcount.refcount))
>> + schedule_work(&conn->free_work);
>> +}
>> +
>> /**
>> * drm_connector_list_iter_next - return next connector
>> * @iter: connectr_list iterator
>> @@ -561,7 +585,7 @@ drm_connector_list_iter_next(struct
>> drm_connector_list_iter *iter)
>> spin_unlock_irqrestore(&config->connector_list_lock, flags);
>> if (old_conn)
>> - drm_connector_put(old_conn);
>> + drm_connector_put_safe(old_conn);
>> return iter->conn;
>> }
>> @@ -580,7 +604,7 @@ void drm_connector_list_iter_end(struct
>> drm_connector_list_iter *iter)
>> {
>> iter->dev = NULL;
>> if (iter->conn)
>> - drm_connector_put(iter->conn);
>> + drm_connector_put_safe(iter->conn);
>> lock_release(&connector_list_iter_dep_map, 0, _RET_IP_);
>> }
>> EXPORT_SYMBOL(drm_connector_list_iter_end);
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index cda8bfa..cc78b3d 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -431,6 +431,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>> drm_connector_put(connector);
>> }
>> drm_connector_list_iter_end(&conn_iter);
>> + /* connector_iter drops references in a work item. */
>> + flush_scheduled_work();
>> if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
>> drm_connector_list_iter_begin(dev, &conn_iter);
>> drm_for_each_connector_iter(connector, &conn_iter)
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index df9807a..a4649c5 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -916,6 +916,14 @@ struct drm_connector {
>> uint8_t num_h_tile, num_v_tile;
>> uint8_t tile_h_loc, tile_v_loc;
>> uint16_t tile_h_size, tile_v_size;
>> +
>> + /**
>> + * @free_work:
>> + *
>> + * Work used only by &drm_connector_iter to be able to clean up a
>> + * connector from any context.
>> + */
>> + struct work_struct free_work;
>> };
>> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
>> -------------------------------------------------------------------------------
>>
>>
>> Git bisection log:
>>
>> -------------------------------------------------------------------------------
>> git bisect start
>> # good: [c6b3e9693f8a32ba3b07e2f2723886ea2aff4e94] Merge branch 'for-linus'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>> git bisect good c6b3e9693f8a32ba3b07e2f2723886ea2aff4e94
>> # bad: [50c4c4e268a2d7a3e58ebb698ac74da0de40ae36] Linux 4.15-rc3
>> git bisect bad 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36
>> # bad: [e9ef1fe312b533592e39cddc1327463c30b0ed8d] Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>> git bisect bad e9ef1fe312b533592e39cddc1327463c30b0ed8d
>> # bad: [77071bc6c472bb0b36818f3e9595114cdf98c86d] Merge tag 'media/v4.15-2'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>> git bisect bad 77071bc6c472bb0b36818f3e9595114cdf98c86d
>> # bad: [4066aa72f9f2886105c6f747d7f9bd4f14f53c12] Merge tag
>> 'drm-fixes-for-v4.15-rc3' of git://people.freedesktop.org/~airlied/linux
>> git bisect bad 4066aa72f9f2886105c6f747d7f9bd4f14f53c12
>> # bad: [96980844bb4b74d2e7ce93d907670658e39a3992] Merge tag
>> 'drm-intel-fixes-2017-12-07' of git://anongit.freedesktop.org/drm/drm-intel
>> into drm-fixes
>> git bisect bad 96980844bb4b74d2e7ce93d907670658e39a3992
>> # bad: [120a264f9c2782682027d931d83dcbd22e01da80] drm/exynos: gem: Drop
>> NONCONTIG flag for buffers allocated without IOMMU
>> git bisect bad 120a264f9c2782682027d931d83dcbd22e01da80
>> # good: [2bf257d662509553ae226239e7dc1c3d00636ca6] drm/ttm: roundup the
>> shrink request to prevent skip huge pool
>> git bisect good 2bf257d662509553ae226239e7dc1c3d00636ca6
>> # good: [db8f884ca7fe6af64d443d1510464efe23826131] Merge branch
>> 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
>> git bisect good db8f884ca7fe6af64d443d1510464efe23826131
>> # bad: [bd3a3a2e92624942a143e485c83e641b2492d828] Merge tag
>> 'drm-misc-fixes-2017-12-06' of git://anongit.freedesktop.org/drm/drm-misc
>> into drm-fixes
>> git bisect bad bd3a3a2e92624942a143e485c83e641b2492d828
>> # bad: [a703c55004e1c5076d57e43771b3e11117796ea0] drm: safely free
>> connectors from connector_iter
>> git bisect bad a703c55004e1c5076d57e43771b3e11117796ea0
>> # first bad commit: [a703c55004e1c5076d57e43771b3e11117796ea0] drm: safely
>> free connectors from connector_iter
>> -------------------------------------------------------------------------------
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Hartley Sweeten @ 2017-12-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211223941.744be82f@jawa>
On Monday, December 11, 2017 2:40 PM, Lukasz Majewski wrote:
> Hi Hartley,
>
>> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
>>>
>>> The BK3 board is a derivative of the ts72xx reference design.
>>
>> Lukasz,
>>
>> I was just reviewing the other TS-72xx boards and noticed this:
>>
>> <snip>
>>
>>> +/* BK3 specific defines */
>>> +#define BK3_CPLDVER_PHYS_BASE 0x23400000
>>> +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
>>> +#define BK3_CPLDVER_SIZE 0x00001000
>>> +
>>
>> <snip>
>>
>>> +static struct map_desc bk3_io_desc[] __initdata = {
>>> + {
>>> + .virtual = BK3_CPLDVER_VIRT_BASE,
>>> + .pfn =
>>> __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
>>> + .length = BK3_CPLDVER_SIZE,
>>> + .type = MT_DEVICE,
>>> + }
>>> +};
>>> +
>>
>> This register appears to be common to all the TS-72xx boards.
>
> The CPLD was used on the reference ts-72xx boards, but support for it seems
> to not be present in the mainline kernel.
The CPLD is not directly called out but some parts of it are supported in the mainline
kernel.
The RTC index and data registers are chip selected by the CPLD and Watchdog is in
the CPLD. Also, the model number, options, and options2 registers are in the CPLD.
There are a couple other registers in the CPLD that are not currently present in
mainline. Some aren't because I haven't figured a good way to utilize them (the
COM2 RS485 registers and the PC/104 memory/IO spaces) or they simply have not
been necessary yet (the two status registers). There are a couple listed in the manuals
that are specific to the TS-7260 that also have not been added.
Basically, anything in the EP93xx CS1 or CS2 memory region is in or controlled by the CPLD.
> Do you have a ts72xx board with CPLD embedded? Is any of your design using it?
I have a stock TS-7300 board.
> My another concern - is it safe to perform IO mapping on memory regions which are
> not used / specified?
The mapping is safe. If there is nothing at the address you just read back the static state
(noise) of the bus and writing doesn't do anything.
> When I do a single ts72xx mapping - for all boards - then we may end up with some
> mappings which are not needed.
True, but it's harmless and it keeps the platform init code cleaner.
> With the code as it is - I only map regions which are already used on relevant boards.
Yes, but this register in particular exists in the CPLD on all the TS-72xx boards.
>> I don't think Arnd has pulled the series yet. Would you mind renaming
>> the defines and rebasing this patch?
>
> If needed I can resend the patch series, or prepare a single fix patch.
> No problem.
Fixing it after Arnd merges your series is fine. I just wanted to make sure it was
pointed out.
BTW, is there a reason the BK3 board needs this register mapped? It was mapped
in the Technologic Systems 2.4, 2.6, and 3.x kernels but I never found anything that
used it. Of course the stock boards probably always had the same revision in the CPLD,
the BK3 board might have multiple revisions...
Hartley
^ permalink raw reply
* [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni @ 2017-12-11 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211104558.pm3lijsdfg2xhj7h@lakrids.cambridge.arm.com>
Thanks Mark, I'll post v5 patch without alternatives.
On 12/11/2017 04:45 AM, Mark Rutland wrote:
> Hi,
>
> On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote:
>> +/**
>> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
>> + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
>> + */
>> + .macro pre_disable_mmu_workaround
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
>> + isb
>> +alternative_else_nop_endif
>> +#endif
>> + .endm
>
> There's really no need for this to be an alternative. It makes the
> kernel larger and more complex due to all the altinstr data and probing
> code.
>
> As Will suggested last time [1], please just use the ifdef, and always
> compile-in the extra ISB if CONFIG_QCOM_FALKOR_ERRATUM_E1041 is
> selected. Get rid of the alternatives and probing code.
>
> All you need here is:
>
> /*
> * Some Falkor parts make errant speculative instruction fetches
> * when SCTLR_ELx.M is cleared. An ISB before the write to
> * SCTLR_ELx prevents this.
> */
> .macro pre_disable_mmu_workaround
> #ifdef
> isb
> #endif
> .endm
>
>> +
>> + .macro pre_disable_mmu_early_workaround
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
>> + isb
>> +#endif
>> + .endm
>> +
>
> ... and we don't need a special early variant.
>
> Thanks,
> Mark.
>
> [1] https://lkml.kernel.org/r/20171201112457.GE18083 at arm.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Kevin Hilman @ 2017-12-11 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4357a69da97f46a324eec4c766f4bc9d9e7733ff.1490545262.git-series.plaes@plaes.org>
On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
> Convert sun4i-a10.dtsi to new CCU driver.
>
> Signed-off-by: Priit Laes <plaes@plaes.org>
I finally got around to bisecting a mainline boot failure on
sun4i-a10-cubieboard that's been happening for quite a while. Based
on on kernelci.org, it showed up sometime during the v4.15 merge
window[1]. It bisected down to this commit (in mainline as commit
41193869f2bdb585ce09bfdd16d9482aadd560ad).
When it fails, there is no output on the serial console, so I don't
know exactly how it's failing, just that it no longer boots.
Kevin
[1] https://kernelci.org/boot/id/5a2e10cd59b51430a9afa173/
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 636 ++++----------------------------
> 1 file changed, 82 insertions(+), 554 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index ba20b48..0d8320a 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -45,7 +45,8 @@
>
> #include <dt-bindings/thermal/thermal.h>
>
> -#include <dt-bindings/clock/sun4i-a10-pll2.h>
> +#include <dt-bindings/clock/sunxi-a10-a20-ccu.h>
> +#include <dt-bindings/reset/sunxi-a10-a20-ccu.h>
> #include <dt-bindings/dma/sun4i-a10.h>
> #include <dt-bindings/pinctrl/sun4i-a10.h>
>
> @@ -65,9 +66,9 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&de_be0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -75,10 +76,11 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch1_clk>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> + <&ccu CLK_TCON0_CH1>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -86,9 +88,10 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0";
> - clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch0_clk>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_DE_BE0>,
> + <&ccu CLK_AHB_DE_FE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_DE_FE0>, <&ccu CLK_TCON0_CH1>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
>
> @@ -96,11 +99,11 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> - clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> - <&ahb_gates 44>, <&ahb_gates 46>,
> - <&de_be0_clk>, <&de_fe0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 5>,
> - <&dram_gates 25>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_TVE0>, <&ccu CLK_AHB_LCD0>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_TVE0>,
> + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> status = "disabled";
> };
> };
> @@ -112,7 +115,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a8";
> reg = <0x0>;
> - clocks = <&cpu>;
> + clocks = <&ccu CLK_CPU>;
> clock-latency = <244144>; /* 8 32k periods */
> operating-points = <
> /* kHz uV */
> @@ -168,18 +171,6 @@
> #size-cells = <1>;
> ranges;
>
> - /*
> - * This is a dummy clock, to be used as placeholder on
> - * other mux clocks when a specific parent clock is not
> - * yet implemented. It should be dropped when the driver
> - * is complete.
> - */
> - dummy: dummy {
> - #clock-cells = <0>;
> - compatible = "fixed-clock";
> - clock-frequency = <0>;
> - };
> -
> osc24M: clk at 01c20050 {
> #clock-cells = <0>;
> compatible = "allwinner,sun4i-a10-osc-clk";
> @@ -188,487 +179,12 @@
> clock-output-names = "osc24M";
> };
>
> - osc3M: osc3M_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <8>;
> - clock-mult = <1>;
> - clocks = <&osc24M>;
> - clock-output-names = "osc3M";
> - };
> -
> osc32k: clk at 0 {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32768>;
> clock-output-names = "osc32k";
> };
> -
> - pll1: clk at 01c20000 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20000 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll1";
> - };
> -
> - pll2: clk at 01c20008 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll2-clk";
> - reg = <0x01c20008 0x8>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll2-1x", "pll2-2x",
> - "pll2-4x", "pll2-8x";
> - };
> -
> - pll3: clk at 01c20010 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20010 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll3";
> - };
> -
> - pll3x2: pll3x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll3>;
> - clock-output-names = "pll3-2x";
> - };
> -
> - pll4: clk at 01c20018 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20018 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll4";
> - };
> -
> - pll5: clk at 01c20020 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll5-clk";
> - reg = <0x01c20020 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll5_ddr", "pll5_other";
> - };
> -
> - pll6: clk at 01c20028 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll6-clk";
> - reg = <0x01c20028 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll6_sata", "pll6_other", "pll6";
> - };
> -
> - pll7: clk at 01c20030 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20030 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll7";
> - };
> -
> - pll7x2: pll7x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll7>;
> - clock-output-names = "pll7-2x";
> - };
> -
> - /* dummy is 200M */
> - cpu: cpu at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-cpu-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> - clock-output-names = "cpu";
> - };
> -
> - axi: axi at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-axi-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&cpu>;
> - clock-output-names = "axi";
> - };
> -
> - axi_gates: clk at 01c2005c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-axi-gates-clk";
> - reg = <0x01c2005c 0x4>;
> - clocks = <&axi>;
> - clock-indices = <0>;
> - clock-output-names = "axi_dram";
> - };
> -
> - ahb: ahb at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-ahb-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&axi>;
> - clock-output-names = "ahb";
> - };
> -
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <3>,
> - <4>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <11>, <12>,
> - <13>, <14>, <16>,
> - <17>, <18>, <20>,
> - <21>, <22>, <23>,
> - <24>, <25>, <26>,
> - <32>, <33>, <34>,
> - <35>, <36>, <37>,
> - <40>, <41>, <43>,
> - <44>, <45>,
> - <46>, <47>,
> - <50>, <52>;
> - clock-output-names = "ahb_usb0", "ahb_ehci0",
> - "ahb_ohci0", "ahb_ehci1",
> - "ahb_ohci1", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_mmc3", "ahb_ms",
> - "ahb_nand", "ahb_sdram", "ahb_ace",
> - "ahb_emac", "ahb_ts", "ahb_spi0",
> - "ahb_spi1", "ahb_spi2", "ahb_spi3",
> - "ahb_pata", "ahb_sata", "ahb_gps",
> - "ahb_ve", "ahb_tvd", "ahb_tve0",
> - "ahb_tve1", "ahb_lcd0", "ahb_lcd1",
> - "ahb_csi0", "ahb_csi1", "ahb_hdmi",
> - "ahb_de_be0", "ahb_de_be1",
> - "ahb_de_fe0", "ahb_de_fe1",
> - "ahb_mp", "ahb_mali400";
> - };
> -
> - apb0: apb0 at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb0-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&ahb>;
> - clock-output-names = "apb0";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <1>,
> - <2>, <3>,
> - <5>, <6>,
> - <7>, <10>;
> - clock-output-names = "apb0_codec", "apb0_spdif",
> - "apb0_ac97", "apb0_iis",
> - "apb0_pio", "apb0_ir0",
> - "apb0_ir1", "apb0_keypad";
> - };
> -
> - apb1: clk at 01c20058 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb1-clk";
> - reg = <0x01c20058 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> - clock-output-names = "apb1";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <4>,
> - <5>, <6>,
> - <7>, <16>,
> - <17>, <18>,
> - <19>, <20>,
> - <21>, <22>,
> - <23>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_can",
> - "apb1_scr", "apb1_ps20",
> - "apb1_ps21", "apb1_uart0",
> - "apb1_uart1", "apb1_uart2",
> - "apb1_uart3", "apb1_uart4",
> - "apb1_uart5", "apb1_uart6",
> - "apb1_uart7";
> - };
> -
> - nand_clk: clk at 01c20080 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20080 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "nand";
> - };
> -
> - ms_clk: clk at 01c20084 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20084 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ms";
> - };
> -
> - mmc0_clk: clk at 01c20088 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20088 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc0",
> - "mmc0_output",
> - "mmc0_sample";
> - };
> -
> - mmc1_clk: clk at 01c2008c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c2008c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc1",
> - "mmc1_output",
> - "mmc1_sample";
> - };
> -
> - mmc2_clk: clk at 01c20090 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20090 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc2",
> - "mmc2_output",
> - "mmc2_sample";
> - };
> -
> - mmc3_clk: clk at 01c20094 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20094 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc3",
> - "mmc3_output",
> - "mmc3_sample";
> - };
> -
> - ts_clk: clk at 01c20098 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20098 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ts";
> - };
> -
> - ss_clk: clk at 01c2009c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c2009c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ss";
> - };
> -
> - spi0_clk: clk at 01c200a0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi0";
> - };
> -
> - spi1_clk: clk at 01c200a4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi1";
> - };
> -
> - spi2_clk: clk at 01c200a8 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a8 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi2";
> - };
> -
> - pata_clk: clk at 01c200ac {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200ac 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "pata";
> - };
> -
> - ir0_clk: clk at 01c200b0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir0";
> - };
> -
> - ir1_clk: clk at 01c200b4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir1";
> - };
> -
> - spdif_clk: clk at 01c200c0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod1-clk";
> - reg = <0x01c200c0 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_8X>,
> - <&pll2 SUN4I_A10_PLL2_4X>,
> - <&pll2 SUN4I_A10_PLL2_2X>,
> - <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "spdif";
> - };
> -
> - usb_clk: clk at 01c200cc {
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-usb-clk";
> - reg = <0x01c200cc 0x4>;
> - clocks = <&pll6 1>;
> - clock-output-names = "usb_ohci0", "usb_ohci1",
> - "usb_phy";
> - };
> -
> - spi3_clk: clk at 01c200d4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200d4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi3";
> - };
> -
> - dram_gates: clk at 01c20100 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-dram-gates-clk";
> - reg = <0x01c20100 0x4>;
> - clocks = <&pll5 0>;
> - clock-indices = <0>,
> - <1>, <2>,
> - <3>,
> - <4>,
> - <5>, <6>,
> - <15>,
> - <24>, <25>,
> - <26>, <27>,
> - <28>, <29>;
> - clock-output-names = "dram_ve",
> - "dram_csi0", "dram_csi1",
> - "dram_ts",
> - "dram_tvd",
> - "dram_tve0", "dram_tve1",
> - "dram_output",
> - "dram_de_fe1", "dram_de_fe0",
> - "dram_de_be0", "dram_de_be1",
> - "dram_de_mp", "dram_ace";
> - };
> -
> - de_be0_clk: clk at 01c20104 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20104 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be0";
> - };
> -
> - de_be1_clk: clk at 01c20108 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20108 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be1";
> - };
> -
> - de_fe0_clk: clk at 01c2010c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c2010c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe0";
> - };
> -
> - de_fe1_clk: clk at 01c20110 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20110 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe1";
> - };
> -
> -
> - tcon0_ch0_clk: clk at 01c20118 {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c20118 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon0-ch0-sclk";
> -
> - };
> -
> - tcon1_ch0_clk: clk at 01c2011c {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c2011c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon1-ch0-sclk";
> -
> - };
> -
> - tcon0_ch1_clk: clk at 01c2012c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c2012c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon0-ch1-sclk";
> -
> - };
> -
> - tcon1_ch1_clk: clk at 01c20130 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c20130 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon1-ch1-sclk";
> -
> - };
> -
> - ve_clk: clk at 01c2013c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-ve-clk";
> - reg = <0x01c2013c 0x4>;
> - clocks = <&pll4>;
> - clock-output-names = "ve";
> - };
> -
> - codec_clk: clk at 01c20140 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-codec-clk";
> - reg = <0x01c20140 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "codec";
> - };
> };
>
> soc at 01c00000 {
> @@ -717,7 +233,7 @@
> compatible = "allwinner,sun4i-a10-dma";
> reg = <0x01c02000 0x1000>;
> interrupts = <27>;
> - clocks = <&ahb_gates 6>;
> + clocks = <&ccu CLK_AHB_DMA>;
> #dma-cells = <2>;
> };
>
> @@ -725,7 +241,7 @@
> compatible = "allwinner,sun4i-a10-nand";
> reg = <0x01c03000 0x1000>;
> interrupts = <37>;
> - clocks = <&ahb_gates 13>, <&nand_clk>;
> + clocks = <&ccu CLK_AHB_NAND>, <&ccu CLK_NAND>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 3>;
> dma-names = "rxtx";
> @@ -738,7 +254,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c05000 0x1000>;
> interrupts = <10>;
> - clocks = <&ahb_gates 20>, <&spi0_clk>;
> + clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> <&dma SUN4I_DMA_DEDICATED 26>;
> @@ -752,7 +268,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c06000 0x1000>;
> interrupts = <11>;
> - clocks = <&ahb_gates 21>, <&spi1_clk>;
> + clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> <&dma SUN4I_DMA_DEDICATED 8>;
> @@ -766,7 +282,7 @@
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <55>;
> - clocks = <&ahb_gates 17>;
> + clocks = <&ccu CLK_AHB_EMAC>;
> allwinner,sram = <&emac_sram 1>;
> status = "disabled";
> };
> @@ -782,10 +298,10 @@
> mmc0: mmc at 01c0f000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c0f000 0x1000>;
> - clocks = <&ahb_gates 8>,
> - <&mmc0_clk 0>,
> - <&mmc0_clk 1>,
> - <&mmc0_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC0>,
> + <&ccu CLK_MMC0>,
> + <&ccu CLK_MMC0_OUTPUT>,
> + <&ccu CLK_MMC0_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -799,10 +315,10 @@
> mmc1: mmc at 01c10000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c10000 0x1000>;
> - clocks = <&ahb_gates 9>,
> - <&mmc1_clk 0>,
> - <&mmc1_clk 1>,
> - <&mmc1_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC1>,
> + <&ccu CLK_MMC1>,
> + <&ccu CLK_MMC1_OUTPUT>,
> + <&ccu CLK_MMC1_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -816,10 +332,10 @@
> mmc2: mmc at 01c11000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c11000 0x1000>;
> - clocks = <&ahb_gates 10>,
> - <&mmc2_clk 0>,
> - <&mmc2_clk 1>,
> - <&mmc2_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC2>,
> + <&ccu CLK_MMC2>,
> + <&ccu CLK_MMC2_OUTPUT>,
> + <&ccu CLK_MMC2_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -833,10 +349,10 @@
> mmc3: mmc at 01c12000 {
> compatible = "allwinner,sun4i-a10-mmc";
> reg = <0x01c12000 0x1000>;
> - clocks = <&ahb_gates 11>,
> - <&mmc3_clk 0>,
> - <&mmc3_clk 1>,
> - <&mmc3_clk 2>;
> + clocks = <&ccu CLK_AHB_MMC3>,
> + <&ccu CLK_MMC3>,
> + <&ccu CLK_MMC3_OUTPUT>,
> + <&ccu CLK_MMC3_SAMPLE>;
> clock-names = "ahb",
> "mmc",
> "output",
> @@ -850,7 +366,7 @@
> usb_otg: usb at 01c13000 {
> compatible = "allwinner,sun4i-a10-musb";
> reg = <0x01c13000 0x0400>;
> - clocks = <&ahb_gates 0>;
> + clocks = <&ccu CLK_AHB_OTG>;
> interrupts = <38>;
> interrupt-names = "mc";
> phys = <&usbphy 0>;
> @@ -865,9 +381,11 @@
> compatible = "allwinner,sun4i-a10-usb-phy";
> reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> reg-names = "phy_ctrl", "pmu1", "pmu2";
> - clocks = <&usb_clk 8>;
> + clocks = <&ccu CLK_USB_PHY>;
> clock-names = "usb_phy";
> - resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
> + resets = <&ccu RST_USB_PHY0>,
> + <&ccu RST_USB_PHY1>,
> + <&ccu RST_USB_PHY2>;
> reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
> status = "disabled";
> };
> @@ -876,7 +394,7 @@
> compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> reg = <0x01c14000 0x100>;
> interrupts = <39>;
> - clocks = <&ahb_gates 1>;
> + clocks = <&ccu CLK_AHB_EHCI0>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -886,7 +404,7 @@
> compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <64>;
> - clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + clocks = <&ccu CLK_USB_OHCI0>, <&ccu CLK_AHB_OHCI0>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -896,7 +414,7 @@
> compatible = "allwinner,sun4i-a10-crypto";
> reg = <0x01c15000 0x1000>;
> interrupts = <86>;
> - clocks = <&ahb_gates 5>, <&ss_clk>;
> + clocks = <&ccu CLK_AHB_SS>, <&ccu CLK_SS>;
> clock-names = "ahb", "mod";
> };
>
> @@ -904,7 +422,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
> interrupts = <12>;
> - clocks = <&ahb_gates 22>, <&spi2_clk>;
> + clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> <&dma SUN4I_DMA_DEDICATED 28>;
> @@ -918,7 +436,8 @@
> compatible = "allwinner,sun4i-a10-ahci";
> reg = <0x01c18000 0x1000>;
> interrupts = <56>;
> - clocks = <&pll6 0>, <&ahb_gates 25>;
> + clocks = <&ccu CLK_PLL_PERIPH_SATA>,
> + <&ccu CLK_AHB_SATA>;
> status = "disabled";
> };
>
> @@ -926,7 +445,7 @@
> compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> reg = <0x01c1c000 0x100>;
> interrupts = <40>;
> - clocks = <&ahb_gates 3>;
> + clocks = <&ccu CLK_AHB_EHCI1>;
> phys = <&usbphy 2>;
> phy-names = "usb";
> status = "disabled";
> @@ -936,7 +455,7 @@
> compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> reg = <0x01c1c400 0x100>;
> interrupts = <65>;
> - clocks = <&usb_clk 7>, <&ahb_gates 4>;
> + clocks = <&ccu CLK_USB_OHCI1>, <&ccu CLK_AHB_OHCI1>;
> phys = <&usbphy 2>;
> phy-names = "usb";
> status = "disabled";
> @@ -946,7 +465,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c1f000 0x1000>;
> interrupts = <50>;
> - clocks = <&ahb_gates 23>, <&spi3_clk>;
> + clocks = <&ccu CLK_AHB_SPI3>, <&ccu CLK_SPI3>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 31>,
> <&dma SUN4I_DMA_DEDICATED 30>;
> @@ -956,6 +475,15 @@
> #size-cells = <0>;
> };
>
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun4i-a10-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> intc: interrupt-controller at 01c20400 {
> compatible = "allwinner,sun4i-a10-ic";
> reg = <0x01c20400 0x400>;
> @@ -967,7 +495,7 @@
> compatible = "allwinner,sun4i-a10-pinctrl";
> reg = <0x01c20800 0x400>;
> interrupts = <28>;
> - clocks = <&apb0_gates 5>, <&osc24M>, <&osc32k>;
> + clocks = <&ccu CLK_APB0_PIO>, <&osc24M>, <&osc32k>;
> clock-names = "apb", "hosc", "losc";
> gpio-controller;
> interrupt-controller;
> @@ -1145,7 +673,7 @@
> compatible = "allwinner,sun4i-a10-spdif";
> reg = <0x01c21000 0x400>;
> interrupts = <13>;
> - clocks = <&apb0_gates 1>, <&spdif_clk>;
> + clocks = <&ccu CLK_APB0_SPDIF>, <&ccu CLK_SPDIF>;
> clock-names = "apb", "spdif";
> dmas = <&dma SUN4I_DMA_NORMAL 2>,
> <&dma SUN4I_DMA_NORMAL 2>;
> @@ -1155,7 +683,7 @@
>
> ir0: ir at 01c21800 {
> compatible = "allwinner,sun4i-a10-ir";
> - clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clocks = <&ccu CLK_APB0_IR0>, <&ccu CLK_IR0>;
> clock-names = "apb", "ir";
> interrupts = <5>;
> reg = <0x01c21800 0x40>;
> @@ -1164,7 +692,7 @@
>
> ir1: ir at 01c21c00 {
> compatible = "allwinner,sun4i-a10-ir";
> - clocks = <&apb0_gates 7>, <&ir1_clk>;
> + clocks = <&ccu CLK_APB0_IR1>, <&ccu CLK_IR1>;
> clock-names = "apb", "ir";
> interrupts = <6>;
> reg = <0x01c21c00 0x40>;
> @@ -1183,7 +711,7 @@
> compatible = "allwinner,sun4i-a10-codec";
> reg = <0x01c22c00 0x40>;
> interrupts = <30>;
> - clocks = <&apb0_gates 0>, <&codec_clk>;
> + clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
> clock-names = "apb", "codec";
> dmas = <&dma SUN4I_DMA_NORMAL 19>,
> <&dma SUN4I_DMA_NORMAL 19>;
> @@ -1209,7 +737,7 @@
> interrupts = <1>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 16>;
> + clocks = <&ccu CLK_APB1_UART0>;
> status = "disabled";
> };
>
> @@ -1219,7 +747,7 @@
> interrupts = <2>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 17>;
> + clocks = <&ccu CLK_APB1_UART1>;
> status = "disabled";
> };
>
> @@ -1229,7 +757,7 @@
> interrupts = <3>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 18>;
> + clocks = <&ccu CLK_APB1_UART2>;
> status = "disabled";
> };
>
> @@ -1239,7 +767,7 @@
> interrupts = <4>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 19>;
> + clocks = <&ccu CLK_APB1_UART3>;
> status = "disabled";
> };
>
> @@ -1249,7 +777,7 @@
> interrupts = <17>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 20>;
> + clocks = <&ccu CLK_APB1_UART4>;
> status = "disabled";
> };
>
> @@ -1259,7 +787,7 @@
> interrupts = <18>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 21>;
> + clocks = <&ccu CLK_APB1_UART5>;
> status = "disabled";
> };
>
> @@ -1269,7 +797,7 @@
> interrupts = <19>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 22>;
> + clocks = <&ccu CLK_APB1_UART6>;
> status = "disabled";
> };
>
> @@ -1279,7 +807,7 @@
> interrupts = <20>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 23>;
> + clocks = <&ccu CLK_APB1_UART7>;
> status = "disabled";
> };
>
> @@ -1287,7 +815,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2ac00 0x400>;
> interrupts = <7>;
> - clocks = <&apb1_gates 0>;
> + clocks = <&ccu CLK_APB1_I2C0>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1297,7 +825,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b000 0x400>;
> interrupts = <8>;
> - clocks = <&apb1_gates 1>;
> + clocks = <&ccu CLK_APB1_I2C1>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1307,7 +835,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b400 0x400>;
> interrupts = <9>;
> - clocks = <&apb1_gates 2>;
> + clocks = <&ccu CLK_APB1_I2C2>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1317,7 +845,7 @@
> compatible = "allwinner,sun4i-a10-ps2";
> reg = <0x01c2a000 0x400>;
> interrupts = <62>;
> - clocks = <&apb1_gates 6>;
> + clocks = <&ccu CLK_APB1_PS20>;
> status = "disabled";
> };
>
> @@ -1325,7 +853,7 @@
> compatible = "allwinner,sun4i-a10-ps2";
> reg = <0x01c2a400 0x400>;
> interrupts = <63>;
> - clocks = <&apb1_gates 7>;
> + clocks = <&ccu CLK_APB1_PS21>;
> status = "disabled";
> };
> };
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] phy: rockchip-typec: Try to turn the PHY on several times
From: Douglas Anderson @ 2017-12-11 21:45 UTC (permalink / raw)
To: linux-arm-kernel
Bind / unbind stress testing of the USB controller on rk3399 found
that we'd often end up with lots of failures that looked like this:
phy phy-ff800000.phy.9: phy poweron failed --> -110
dwc3 fe900000.dwc3: failed to initialize core
dwc3: probe of fe900000.dwc3 failed with error -110
Those errors were sometimes seen at bootup too, in which case USB
peripherals wouldn't work until unplugged and re-plugged in.
I spent some time trying to figure out why the PHY was failing to
power on but I wasn't able to. Possibly this has to do with the fact
that the PHY docs say that the USB controller "needs to be held in
reset to hold pipe power state in P2 before initializing the Type C
PHY" but that doesn't appear to be easy to do with the dwc3 driver
today. Messing around with the ordering of the reset vs. the PHY
initialization in the dwc3 driver didn't seem to fix things.
I did, however, find that if I simply retry the power on it seems to
have a good chance of working. So let's add some retries. I ran a
pretty tight bind/unbind loop overnight. When I did so, I found that
I need to retry between 1% and 2% of the time. Overnight I found only
a small handful of times where I needed 2 retries. I never found a
case where I needed 3 retries.
I'm completely aware of the fact that this is quite an ugly hack and I
wish I didn't have to resort to it, but I have no other real idea how
to make this hardware reliable. If Rockchip in the future can come up
with a solution we can always revert this hack. Until then, let's at
least have something that works.
This patch is tested atop Enric's latest dwc3 patch series ending at:
https://patchwork.kernel.org/patch/10095527/
...but it could be applied independently of that series without any
bad effects.
For some more details on this bug, you can refer to:
https://bugs.chromium.org/p/chromium/issues/detail?id=783464
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/phy/rockchip/phy-rockchip-typec.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
index ee85fa0ca4b0..5c2157156ce1 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -349,6 +349,8 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DP BIT(2)
+#define POWER_ON_TRIES 5
+
struct usb3phy_reg {
u32 offset;
u32 enable_bit;
@@ -818,9 +820,8 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)
return mode;
}
-static int rockchip_usb3_phy_power_on(struct phy *phy)
+static int _rockchip_usb3_phy_power_on(struct rockchip_typec_phy *tcphy)
{
- struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
struct rockchip_usb3phy_port_cfg *cfg = &tcphy->port_cfgs;
const struct usb3phy_reg *reg = &cfg->pipe_status;
int timeout, new_mode, ret = 0;
@@ -867,6 +868,25 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
return ret;
}
+static int rockchip_usb3_phy_power_on(struct phy *phy)
+{
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
+ int ret;
+ int tries;
+
+ for (tries = 0; tries < POWER_ON_TRIES; tries++) {
+ ret = _rockchip_usb3_phy_power_on(tcphy);
+ if (!ret)
+ break;
+ }
+
+ if (tries && !ret)
+ dev_info(tcphy->dev, "Needed %d loops to turn on\n", tries);
+
+ return ret;
+}
+
+
static int rockchip_usb3_phy_power_off(struct phy *phy)
{
struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB156532C13ABBAE280B3754CED0370@SN1PR0101MB1565.prod.exchangelabs.com>
Hi Hartley,
> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
> >
> > The BK3 board is a derivative of the ts72xx reference design.
>
> Lukasz,
>
> I was just reviewing the other TS-72xx boards and noticed this:
>
> <snip>
>
> > +/* BK3 specific defines */
> > +#define BK3_CPLDVER_PHYS_BASE 0x23400000
> > +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
> > +#define BK3_CPLDVER_SIZE 0x00001000
> > +
>
> <snip>
>
> > +static struct map_desc bk3_io_desc[] __initdata = {
> > + {
> > + .virtual = BK3_CPLDVER_VIRT_BASE,
> > + .pfn =
> > __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
> > + .length = BK3_CPLDVER_SIZE,
> > + .type = MT_DEVICE,
> > + }
> > +};
> > +
>
> This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for it
seems to not be present in the mainline kernel.
Do you have a ts72xx board with CPLD embedded? Is any of your design
using it?
My another concern - is it safe to perform IO mapping on memory regions
which are not used / specified? When I do a single ts72xx mapping - for
all boards - then we may end up with some mappings which are not needed.
With the code as it is - I only map regions which are already used on
relevant boards.
>
> I don't think Arnd has pulled the series yet. Would you mind renaming
> the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix patch.
No problem.
> The BK3 board and other TS-72xx
> boards can then have a common .map_io.
>
> Thanks,
> Hartley
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/0cfc9f29/attachment.sig>
^ permalink raw reply
* [PATCH 02/12] mtd: nand: add reworked Marvell NAND controller driver
From: Miquel RAYNAL @ 2017-12-11 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211180511.1d734b37@bbrezillon>
On Mon, 11 Dec 2017 18:05:11 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Mon, 11 Dec 2017 17:55:06 +0100
> Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
>
> > On Mon, 11 Dec 2017 13:27:30 -0300
> > Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> >
> > > On 7 December 2017 at 17:18, Miquel Raynal
> > > <miquel.raynal@free-electrons.com> wrote:
> > > > Add marvell_nand driver which aims at replacing the existing
> > > > pxa3xx_nand driver.
> > > >
> > > > The new driver intends to be easier to understand and follows
> > > > the brand new NAND framework rules by implementing hooks for
> > > > every pattern the controller might support and referencing them
> > > > inside a parser object that will be given to the core at each
> > > > ->exec_op() call.
> > > >
> > > > Raw accessors are implemented, useful to test/debug
> > > > memory/filesystem corruptions. Userspace binaries contained in
> > > > the mtd-utils package may now be used and their output trusted.
> > > >
> > > > Timings may not be kept from the bootloader anymore, the timings
> > > > used for instance in U-Boot were not optimal and it supposed to
> > > > have NAND support (and initialized) in the bootloader.
> > > >
> > > > Thanks to the improved timings, implementation of ONFI mode 5
> > > > support (with EDO managed by adding a delay on data sampling),
> > > > merging the commands together and optimizing writes in the
> > > > command registers, the new driver may achieve faster
> > > > throughputs in both directions. Measurements show an
> > > > improvement of about +23% read throughput and +24% write
> > > > throughput. These measurements have been done with an
> > > > Armada-385-DB-AP (4kiB NAND pages forced in 4-bit strength BCH
> > > > ECC correction) using the userspace tool 'flash_speed' from the
> > > > MTD test suite.
> > > >
> > > > Besides these important topics, the new driver addresses several
> > > > unsolved known issues in the old driver which:
> > > > - did not work with ECC soft neither with ECC none ;
> > > > - relied on naked read/write (which is unchanged) while the
> > > > NFCv1 embedded in the pxa3xx platforms do not implement it, so
> > > > several NAND commands did not actually ever work without any
> > > > notice (like reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
> > > > - wrote the OOB data correctly, but was not able to read it
> > > > correctly past the first OOB data chunk ;
> > > > - did not displayed ECC bytes ;
> > > > - used device tree bindings that did not allow more than one
> > > > NAND chip, and did not allow to choose the correct chip select
> > > > if not incrementing from 0. Plus, the Ready/Busy line used had
> > > > to be 0.
> > > >
> > > > Old device tree bindings are still supported but deprecated. A
> > > > more hierarchical view has to be used to keep the controller
> > > > and the NAND chip structures clearly separated both inside the
> > > > device tree and also in the driver code.
> > > >
> > >
> > > So, is this driver fully compatible with the current pxa3xx-nand
> > > driver?
> >
> > It should be!
> >
> > >
> > > Have you tested with U-Boot's driver (based on the pxa3xx-nand)?
> > >
> > > I recally some subtle issues with the fact that U-Boot and Linux
> > > had to agree about the BBT format.
> >
> > I kept the pxa3xx_nand driver BBT format.
> >
> > This is something I mistakenly omitted from the commit message:
> >
> > There are 5 supported layouts in the driver (the same as withing the
> > pxa3xx_nand driver):
> > 1/ Page: 512B, strength 1b/512B (hamming)
> > 2/ Page: 2kiB, strength 4b/2kiB (hamming)
> > 3/ page: 2kiB, strength 16b/2kiB (BCH)
> > 4/ page: 4kiB, strength 16b/2kiB (BCH)
> > 5/ page: 4kiB, strength 32b/2kiB (BCH)
>
> Are you sure of #5? I thought the engine was only capable of modifying
> the ECC block size, not the strength. If this is the case, then mode
> #5 is actually 16b/1024kiB.
You are right, #5 you actually be:
5/ page: 4kiB, strength 16b/1kiB (BCH)
Thanks for pointing it,
Miqu?l
>
> >
> > Layout 2 has been tested with CM_X300 compulab module (PXA SoC) with
> > and without DMA.
> > Layout 4 has been tested with an Armada 385 db, an Armada 7040 DB
> > and an Armada 8040 DB.
> > Layout 5 has been tested with an Armada 398 db.
> >
> > Layout 1 has been tested with the Armada 385 db with some hacks.
> > Layout 3 has been tested with the Armada 385 db with some other
> > hacks, that is why I am concerned about the other thread on the MTD
> > mailing list "wait timeout when scanning for BB" where a 2kiB page
> > with 16b/2048B strength is in use.
> >
> > Regards,
> > Miqu?l
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] tty: serial: imx: allow breaks to be received when using dma
From: Troy Kisky @ 2017-12-11 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3f0140a-92bb-ed59-ee79-971385634d4d@boundarydevices.com>
On 10/20/2017 3:17 PM, Troy Kisky wrote:
> On 10/20/2017 3:13 PM, Troy Kisky wrote:
>> This allows me to login after sending a break when service
>> serial-getty at ttymxc0.service is running
>>
>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>> ---
>> drivers/tty/serial/imx.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 506fcd742b47..39033f460a24 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -934,7 +934,6 @@ static void dma_rx_callback(void *data)
>> status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
>>
>> if (status == DMA_ERROR) {
>> - dev_err(sport->port.dev, "DMA transaction error.\n");
>> clear_rx_errors(sport);
>> return;
>> }
>> @@ -1035,6 +1034,7 @@ static int start_rx_dma(struct imx_port *sport)
>>
>> static void clear_rx_errors(struct imx_port *sport)
>> {
>> + struct tty_port *port = &sport->port.state->port;
>> unsigned int status_usr1, status_usr2;
>>
>> status_usr1 = readl(sport->port.membase + USR1);
>> @@ -1043,12 +1043,18 @@ static void clear_rx_errors(struct imx_port *sport)
>> if (status_usr2 & USR2_BRCD) {
>> sport->port.icount.brk++;
>> writel(USR2_BRCD, sport->port.membase + USR2);
>> - } else if (status_usr1 & USR1_FRAMERR) {
>> - sport->port.icount.frame++;
>> - writel(USR1_FRAMERR, sport->port.membase + USR1);
>> - } else if (status_usr1 & USR1_PARITYERR) {
>> - sport->port.icount.parity++;
>> - writel(USR1_PARITYERR, sport->port.membase + USR1);
>> + if (tty_insert_flip_char(port, 0, TTY_BREAK) == 0)
>> + sport->port.icount.buf_overrun++;
>> + tty_flip_buffer_push(port);
>> + } else {
>> + dev_err(sport->port.dev, "DMA transaction error.\n");
>> + if (status_usr1 & USR1_FRAMERR) {
>> + sport->port.icount.frame++;
>> + writel(USR1_FRAMERR, sport->port.membase + USR1);
>> + } else if (status_usr1 & USR1_PARITYERR) {
>> + sport->port.icount.parity++;
>> + writel(USR1_PARITYERR, sport->port.membase + USR1);
>> + }
>> }
>>
>> if (status_usr2 & USR2_ORE) {
>>
>
>
>
> Does this need to use
> spin_lock_irqsave(&sport->port.lock, flags);
>
>
> I would have, but dma_rx_callback doesn't.
>
> BR
> Troy
>
>
I think the path is fine as is. Should I send a rebased version ?
Thanks
Troy
^ 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