* [PATCH v4 0/8] Add support for legacy SCPI protocol
From: Neil Armstrong @ 2016-10-05 7:33 UTC (permalink / raw)
To: linux-arm-kernel
This patchset aims to support the legacy SCPI firmware implementation that was
delivered as early technology preview for the JUNO platform.
Finally a stable, maintained and public implementation for the SCPI protocol
has been upstreamed part of the JUNO support and it is the recommended way
of implementing SCP communication on ARMv8 platforms.
The Amlogic GXBB platform is using this legacy protocol, as the RK3368 & RK3399
platforms. This patchset will only add support for Amlogic GXBB SoC.
This patchset add support for the legacy protocol in the arm_scpi.c file,
avoiding code duplication.
Last RFC discution tread can be found at : https://lkml.org/lkml/2016/8/9/210
Changes since v3 at : http://lkml.kernel.org/r/1473262477-18045-1-git-send-email-narmstrong at baylibre.com
- Changed back author to Sudeep Holla for first patch
- Merged legacy functions to scpi_send_message, tx_prepare and handle_remote_message
- Added legacy locking scheme
- Merged back legacy_scpi_sensor_get_value into scpi_sensor_get_value
- Rebased on linux-next-20161004 with patchset [1]
Changes since v2 at : http://lkml.kernel.org/r/1471952816-30877-1-git-send-email-narmstrong at baylibre.com
- Added command indirection table and use it in each commands
- Added bitmap for high priority commands
- Cleaned up legacy tx_prepare/handle_message to align to standard functions
- Dropped legacy_scpi_ops
Changes since v1 at : http://lkml.kernel.org/r/1471515066-3626-1-git-send-email-narmstrong at baylibre.com
- Dropped vendor_send_message and rockchip vendor mechanism patches
- Merged alternate functions into main functions using is_legacy boolean
- Added DT match table to set is_legacy to true
- Kept alternate scpi_ops structure for legacy
[1] http://lkml.kernel.org/r/1475595430-30075-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (7):
scpi: Add alternative legacy structures, functions and macros
scpi: Do not fail if get_capabilities is not implemented
scpi: Add support for Legacy match table for Amlogic GXBB SoC
scpi: grow MAX_DVFS_OPPS to 16 entries
dt-bindings: Add support for Amlogic GXBB SCPI Interface
ARM64: dts: meson-gxbb: Add SRAM node
ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes
Sudeep Holla (1):
scpi: Add cmd indirection table to prepare for legacy commands
Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 ++++
drivers/firmware/arm_scpi.c | 317 ++++++++++++++++++---
3 files changed, 339 insertions(+), 43 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
From: Nipun Gupta @ 2016-10-05 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2273af20d844bd618c6a90b57e639700328ebf7f.1473695704.git.robin.murphy@arm.com>
> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Robin Murphy
> Sent: Monday, September 12, 2016 21:44
> To: will.deacon at arm.com; joro at 8bytes.org; iommu at lists.linux-
> foundation.org; linux-arm-kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org; punit.agrawal at arm.com;
> thunder.leizhen at huawei.com
> Subject: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
>
> When an MSI doorbell is located downstream of an IOMMU, attaching devices
> to a DMA ops domain and switching on translation leads to a rude shock when
> their attempt to write to the physical address returned by the irqchip driver
> faults (or worse, writes into some already-mapped
> buffer) and no interrupt is forthcoming.
>
> Address this by adding a hook for relevant irqchip drivers to call from their
> compose_msi_msg() callback, to swizzle the physical address with an
> appropriatly-mapped IOVA for any device attached to one of our DMA ops
> domains.
>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 136
> ++++++++++++++++++++++++++++++++++-----
> drivers/irqchip/irq-gic-v2m.c | 3 +
> drivers/irqchip/irq-gic-v3-its.c | 3 +
> include/linux/dma-iommu.h | 9 +++
> 4 files changed, 136 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index
> 00c8a08d56e7..4329d18080cf 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -25,10 +25,28 @@
> #include <linux/huge_mm.h>
> #include <linux/iommu.h>
> #include <linux/iova.h>
> +#include <linux/irq.h>
> #include <linux/mm.h>
> #include <linux/scatterlist.h>
> #include <linux/vmalloc.h>
>
> +struct iommu_dma_msi_page {
> + struct list_head list;
> + dma_addr_t iova;
> + phys_addr_t phys;
> +};
> +
> +struct iommu_dma_cookie {
> + struct iova_domain iovad;
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> +};
> +
> +static inline struct iova_domain *cookie_iovad(struct iommu_domain
> +*domain) {
> + return &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad; }
> +
> int iommu_dma_init(void)
> {
> return iova_cache_get();
> @@ -43,15 +61,19 @@ int iommu_dma_init(void)
> */
> int iommu_get_dma_cookie(struct iommu_domain *domain) {
> - struct iova_domain *iovad;
> + struct iommu_dma_cookie *cookie;
>
> if (domain->iova_cookie)
> return -EEXIST;
>
> - iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
> - domain->iova_cookie = iovad;
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (!cookie)
> + return -ENOMEM;
>
> - return iovad ? 0 : -ENOMEM;
> + spin_lock_init(&cookie->msi_lock);
> + INIT_LIST_HEAD(&cookie->msi_page_list);
> + domain->iova_cookie = cookie;
> + return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_cookie);
>
> @@ -63,14 +85,20 @@ EXPORT_SYMBOL(iommu_get_dma_cookie);
> */
> void iommu_put_dma_cookie(struct iommu_domain *domain) {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iommu_dma_msi_page *msi, *tmp;
>
> - if (!iovad)
> + if (!cookie)
> return;
>
> - if (iovad->granule)
> - put_iova_domain(iovad);
> - kfree(iovad);
> + if (cookie->iovad.granule)
> + put_iova_domain(&cookie->iovad);
> +
> + list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> + list_del(&msi->list);
> + kfree(msi);
> + }
> + kfree(cookie);
> domain->iova_cookie = NULL;
> }
> EXPORT_SYMBOL(iommu_put_dma_cookie);
> @@ -88,7 +116,7 @@ EXPORT_SYMBOL(iommu_put_dma_cookie);
> */
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t
> base, u64 size) {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> unsigned long order, base_pfn, end_pfn;
>
> if (!iovad)
> @@ -155,7 +183,7 @@ int dma_direction_to_prot(enum dma_data_direction
> dir, bool coherent) static struct iova *__alloc_iova(struct iommu_domain
> *domain, size_t size,
> dma_addr_t dma_limit)
> {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> unsigned long shift = iova_shift(iovad);
> unsigned long length = iova_align(iovad, size) >> shift;
>
> @@ -171,7 +199,7 @@ static struct iova *__alloc_iova(struct iommu_domain
> *domain, size_t size,
> /* The IOVA allocator knows what we mapped, so just unmap whatever that
> was */ static void __iommu_dma_unmap(struct iommu_domain *domain,
> dma_addr_t dma_addr) {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> unsigned long shift = iova_shift(iovad);
> unsigned long pfn = dma_addr >> shift;
> struct iova *iova = find_iova(iovad, pfn); @@ -294,7 +322,7 @@ struct
> page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
> void (*flush_page)(struct device *, const void *, phys_addr_t)) {
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> struct iova *iova;
> struct page **pages;
> struct sg_table sgt;
> @@ -386,7 +414,7 @@ dma_addr_t iommu_dma_map_page(struct device
> *dev, struct page *page, {
> dma_addr_t dma_addr;
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> phys_addr_t phys = page_to_phys(page) + offset;
> size_t iova_off = iova_offset(iovad, phys);
> size_t len = iova_align(iovad, size + iova_off); @@ -495,7 +523,7 @@
> int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> int nents, int prot)
> {
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
> struct iova *iova;
> struct scatterlist *s, *prev = NULL;
> dma_addr_t dma_addr;
> @@ -587,3 +615,81 @@ int iommu_dma_mapping_error(struct device *dev,
> dma_addr_t dma_addr) {
> return dma_addr == DMA_ERROR_CODE;
> }
> +
> +static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device
> *dev,
> + phys_addr_t msi_addr, struct iommu_domain *domain) {
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iommu_dma_msi_page *msi_page;
> + struct iova_domain *iovad = &cookie->iovad;
> + struct iova *iova;
> + int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> +
> + msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> + list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> + if (msi_page->phys == msi_addr)
> + return msi_page;
> +
> + msi_page = kzalloc(sizeof(*msi_page), GFP_ATOMIC);
> + if (!msi_page)
> + return NULL;
> +
> + iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
I think this should be 'iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));'
as __alloc_iova takes input parameter as 'struct iova_domain *'
Regards,
Nipun
> + if (!iova)
> + goto out_free_page;
> +
> + msi_page->phys = msi_addr;
> + msi_page->iova = iova_dma_addr(iovad, iova);
> + if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule,
> prot))
> + goto out_free_iova;
> +
> + INIT_LIST_HEAD(&msi_page->list);
> + list_add(&msi_page->list, &cookie->msi_page_list);
> + return msi_page;
> +
> +out_free_iova:
> + __free_iova(iovad, iova);
> +out_free_page:
> + kfree(msi_page);
> + return NULL;
> +}
> +
> +void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg) {
> + struct device *dev = msi_desc_to_dev(irq_get_msi_desc(irq));
> + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> + struct iommu_dma_cookie *cookie;
> + struct iommu_dma_msi_page *msi_page;
> + phys_addr_t msi_addr = (u64)msg->address_hi << 32 | msg->address_lo;
> + unsigned long flags;
> +
> + if (!domain || !domain->iova_cookie)
> + return;
> +
> + cookie = domain->iova_cookie;
> +
> + /*
> + * We disable IRQs to rule out a possible inversion against
> + * irq_desc_lock if, say, someone tries to retarget the affinity
> + * of an MSI from within an IPI handler.
> + */
> + spin_lock_irqsave(&cookie->msi_lock, flags);
> + msi_page = iommu_dma_get_msi_page(dev, msi_addr, domain);
> + spin_unlock_irqrestore(&cookie->msi_lock, flags);
> +
> + if (WARN_ON(!msi_page)) {
> + /*
> + * We're called from a void callback, so the best we can do is
> + * 'fail' by filling the message with obviously bogus values.
> + * Since we got this far due to an IOMMU being present, it's
> + * not like the existing address would have worked anyway...
> + */
> + msg->address_hi = ~0U;
> + msg->address_lo = ~0U;
> + msg->data = ~0U;
> + } else {
> + msg->address_hi = upper_32_bits(msi_page->iova);
> + msg->address_lo &= iova_mask(&cookie->iovad);
> + msg->address_lo += lower_32_bits(msi_page->iova);
> + }
> +}
> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c index
> 35eb7ac5d21f..863e073c6f7f 100644
> --- a/drivers/irqchip/irq-gic-v2m.c
> +++ b/drivers/irqchip/irq-gic-v2m.c
> @@ -16,6 +16,7 @@
> #define pr_fmt(fmt) "GICv2m: " fmt
>
> #include <linux/acpi.h>
> +#include <linux/dma-iommu.h>
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> #include <linux/kernel.h>
> @@ -108,6 +109,8 @@ static void gicv2m_compose_msi_msg(struct irq_data
> *data, struct msi_msg *msg)
>
> if (v2m->flags & GICV2M_NEEDS_SPI_OFFSET)
> msg->data -= v2m->spi_offset;
> +
> + iommu_dma_map_msi_msg(data->irq, msg);
> }
>
> static struct irq_chip gicv2m_irq_chip = { diff --git a/drivers/irqchip/irq-gic-v3-
> its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 36b9c28a5c91..98ff669d5962 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -18,6 +18,7 @@
> #include <linux/bitmap.h>
> #include <linux/cpu.h>
> #include <linux/delay.h>
> +#include <linux/dma-iommu.h>
> #include <linux/interrupt.h>
> #include <linux/log2.h>
> #include <linux/mm.h>
> @@ -655,6 +656,8 @@ static void its_irq_compose_msi_msg(struct irq_data
> *d, struct msi_msg *msg)
> msg->address_lo = addr & ((1UL << 32) - 1);
> msg->address_hi = addr >> 32;
> msg->data = its_get_event_id(d);
> +
> + iommu_dma_map_msi_msg(d->irq, msg);
> }
>
> static struct irq_chip its_irq_chip = { diff --git a/include/linux/dma-iommu.h
> b/include/linux/dma-iommu.h index 81c5c8d167ad..5ee806e41b5c 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -21,6 +21,7 @@
>
> #ifdef CONFIG_IOMMU_DMA
> #include <linux/iommu.h>
> +#include <linux/msi.h>
>
> int iommu_dma_init(void);
>
> @@ -62,9 +63,13 @@ void iommu_dma_unmap_sg(struct device *dev, struct
> scatterlist *sg, int nents, int iommu_dma_supported(struct device *dev, u64
> mask); int iommu_dma_mapping_error(struct device *dev, dma_addr_t
> dma_addr);
>
> +/* The DMA API isn't _quite_ the whole story, though... */ void
> +iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> +
> #else
>
> struct iommu_domain;
> +struct msi_msg;
>
> static inline int iommu_dma_init(void)
> {
> @@ -80,6 +85,10 @@ static inline void iommu_put_dma_cookie(struct
> iommu_domain *domain) { }
>
> +static inline void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> +{ }
> +
> #endif /* CONFIG_IOMMU_DMA */
> #endif /* __KERNEL__ */
> #endif /* __DMA_IOMMU_H */
> --
> 2.8.1.dirty
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH v2 2/4] drivers: iio: ti_am335x_adc: add dma support
From: Peter Ujfalusi @ 2016-10-05 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9c3108e-ffd1-472a-a2d3-2948665de217@ti.com>
On 10/05/16 09:21, Mugunthan V N wrote:
> On Tuesday 04 October 2016 02:02 PM, Peter Ujfalusi wrote:
>> On 10/03/16 16:03, Mugunthan V N wrote:
>>> +static int tiadc_request_dma(struct platform_device *pdev,
>>> + struct tiadc_device *adc_dev)
>>> +{
>>> + struct tiadc_dma *dma = &adc_dev->dma;
>>> + dma_cap_mask_t mask;
>>> +
>>> + /* Default slave configuration parameters */
>>> + dma->conf.direction = DMA_DEV_TO_MEM;
>>> + dma->conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>>> + dma->conf.src_addr = adc_dev->mfd_tscadc->tscadc_phys_base + REG_FIFO1;
>>> +
>>> + dma_cap_zero(mask);
>>> + dma_cap_set(DMA_CYCLIC, mask);
>>> +
>>> + /* Get a channel for RX */
>>> + dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
>>> + if (!dma->chan)
>>> + return -ENODEV;
>>
>> dma_request_chan() ERR_PTR in case of failure, never NULL. You should reuse
>> the returned error code to support deferred probing.
>
> Will fix this in v3.
>
>>
>>> +
>>> + /* RX buffer */
>>> + dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>>> + &dma->addr, GFP_KERNEL);
>>> + if (!dma->buf)
>>> + goto err;
>>> +
>>> + return 0;
>>> +err:
>>> + dma_release_channel(dma->chan);
>>> +
>>> + return -ENOMEM;
>>> +}
>>> +
>>> static int tiadc_parse_dt(struct platform_device *pdev,
>>> struct tiadc_device *adc_dev)
>>> {
>>> @@ -512,8 +639,14 @@ static int tiadc_probe(struct platform_device *pdev)
>>>
>>> platform_set_drvdata(pdev, indio_dev);
>>>
>>> + err = tiadc_request_dma(pdev, adc_dev);
>>> + if (err && err != -ENODEV)
>>> + goto err_dma;
>>
>> You should handle the deferred probing for DMA channel.
>
> + dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
> + if (IS_ERR(dma->chan)) {
> + int ret = PTR_ERR(dma->chan);
> +
> + dma->chan = NULL;
> + return ret;
You don't need the 'ret' variable:
return PTR_ERR(dma->chan);
> + }
>
> With this probe defer will be taken care and ADC will continue without
> DMA when request channel returns -ENODEV.
I would rather have explicit check for deferred probe:
err = tiadc_request_dma(pdev, adc_dev);
if (err && err == -EPROBE_DEFER)
goto err_dma;
--
P?ter
^ permalink raw reply
* [PATCH v2 2/4] drivers: iio: ti_am335x_adc: add dma support
From: Mugunthan V N @ 2016-10-05 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ff2c6ef-3fa1-dc8b-fb6e-1a4dcfea8ea9@ti.com>
On Tuesday 04 October 2016 02:02 PM, Peter Ujfalusi wrote:
> On 10/03/16 16:03, Mugunthan V N wrote:
>> +static int tiadc_request_dma(struct platform_device *pdev,
>> + struct tiadc_device *adc_dev)
>> +{
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + dma_cap_mask_t mask;
>> +
>> + /* Default slave configuration parameters */
>> + dma->conf.direction = DMA_DEV_TO_MEM;
>> + dma->conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> + dma->conf.src_addr = adc_dev->mfd_tscadc->tscadc_phys_base + REG_FIFO1;
>> +
>> + dma_cap_zero(mask);
>> + dma_cap_set(DMA_CYCLIC, mask);
>> +
>> + /* Get a channel for RX */
>> + dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
>> + if (!dma->chan)
>> + return -ENODEV;
>
> dma_request_chan() ERR_PTR in case of failure, never NULL. You should reuse
> the returned error code to support deferred probing.
Will fix this in v3.
>
>> +
>> + /* RX buffer */
>> + dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + &dma->addr, GFP_KERNEL);
>> + if (!dma->buf)
>> + goto err;
>> +
>> + return 0;
>> +err:
>> + dma_release_channel(dma->chan);
>> +
>> + return -ENOMEM;
>> +}
>> +
>> static int tiadc_parse_dt(struct platform_device *pdev,
>> struct tiadc_device *adc_dev)
>> {
>> @@ -512,8 +639,14 @@ static int tiadc_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, indio_dev);
>>
>> + err = tiadc_request_dma(pdev, adc_dev);
>> + if (err && err != -ENODEV)
>> + goto err_dma;
>
> You should handle the deferred probing for DMA channel.
+ dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
+ if (IS_ERR(dma->chan)) {
+ int ret = PTR_ERR(dma->chan);
+
+ dma->chan = NULL;
+ return ret;
+ }
With this probe defer will be taken care and ADC will continue without
DMA when request channel returns -ENODEV.
Regards
Mugunthan V N
>
>> +
>> return 0;
>>
>> +err_dma:
>> + iio_device_unregister(indio_dev);
>> err_buffer_unregister:
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> err_free_channels:
>> @@ -525,8 +658,14 @@ static int tiadc_remove(struct platform_device *pdev)
>> {
>> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> u32 step_en;
>>
>> + if (dma->chan) {
>> + dma_free_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + dma->buf, dma->addr);
>> + dma_release_channel(dma->chan);
>> + }
>> iio_device_unregister(indio_dev);
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> tiadc_channels_remove(indio_dev);
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> index e45a208..b9a53e0 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -23,6 +23,8 @@
>> #define REG_IRQENABLE 0x02C
>> #define REG_IRQCLR 0x030
>> #define REG_IRQWAKEUP 0x034
>> +#define REG_DMAENABLE_SET 0x038
>> +#define REG_DMAENABLE_CLEAR 0x03c
>> #define REG_CTRL 0x040
>> #define REG_ADCFSM 0x044
>> #define REG_CLKDIV 0x04C
>> @@ -36,6 +38,7 @@
>> #define REG_FIFO0THR 0xE8
>> #define REG_FIFO1CNT 0xF0
>> #define REG_FIFO1THR 0xF4
>> +#define REG_DMA1REQ 0xF8
>> #define REG_FIFO0 0x100
>> #define REG_FIFO1 0x200
>>
>> @@ -126,6 +129,10 @@
>> #define FIFOREAD_DATA_MASK (0xfff << 0)
>> #define FIFOREAD_CHNLID_MASK (0xf << 16)
>>
>> +/* DMA ENABLE/CLEAR Register */
>> +#define DMA_FIFO0 BIT(0)
>> +#define DMA_FIFO1 BIT(1)
>> +
>> /* Sequencer Status */
>> #define SEQ_STATUS BIT(5)
>> #define CHARGE_STEP 0x11
>>
>
>
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Paweł Jarosz @ 2016-10-05 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
Hi
W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
> Hi, Pawe?:
> On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
>> For some reason accessing memory region above 0xfe000000 freezes
>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> RK3066 only support 2GB memory from 0x60000000 to 0xE0000000, can not access
> above 0xfe000000. I think you mean 0x9F000000?
Yes i meant 0x9F00000. Sorry for that.
> I don't remember RK3066 has such limit. I will double check with our IC
> design team.
> Do you know which master can not access this memory area
> [0x9F000000~0xA0000000)?
I don't.
> Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM
Thanks
Pawel
^ permalink raw reply
* [PATCH 07/14] ASoC: Add sun8i audio card
From: Code Kipper @ 2016-10-05 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <33d641ff43f0c0349cdfa2cdbbfdcdde66205596.1475571575.git.mylene.josserand@free-electrons.com>
On 4 October 2016 at 11:46, Myl?ne Josserand
<mylene.josserand@free-electrons.com> wrote:
> Add the audio card for sun8i SoC. This card links the codec driver
> (digital part) with the DAI driver. The analog codec driver is
> added as an aux_device.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> ---
> sound/soc/sunxi/Kconfig | 14 +++++++
> sound/soc/sunxi/Makefile | 1 +
> sound/soc/sunxi/sun8i.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 116 insertions(+)
> create mode 100644 sound/soc/sunxi/sun8i.c
>
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 9e287b0..7b97395 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -27,6 +27,20 @@ config SND_SUN4I_SPDIF
> Say Y or M to add support for the S/PDIF audio block in the Allwinner
> A10 and affiliated SoCs.
>
> +config SND_SUN8I
> + tristate "Allwinner SUN6I/SUN8I audio card support"
> + select SND_SUN8I_CODEC
> + select SND_SUN4I_I2S
> + select SND_SUN8I_CODEC_ANALOG
> + select REGMAP_MMIO
> + help
> + This option enables the audio card for Allwinner A33 (sun8i) SoC.
> + It enables the DAI driver (SND_SUN4I_I2S), the digital audio
> + codec driver (SND_SUN8I_CODEC) and the analog codec driver
> + (SND_SUN8I_CODEC_ANALOG).
> +
> + Say Y or M if you want to add sun8i/6i card support
> +
> config SND_SUN8I_CODEC
> tristate "Allwinner SUN8I audio codec"
> select REGMAP_MMIO
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index 1da63d3..7f1bab9 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
> obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o
> obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
> +obj-$(CONFIG_SND_SUN8I) += sun8i.o
> obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o
> obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
> diff --git a/sound/soc/sunxi/sun8i.c b/sound/soc/sunxi/sun8i.c
> new file mode 100644
> index 0000000..565cd88
> --- /dev/null
> +++ b/sound/soc/sunxi/sun8i.c
> @@ -0,0 +1,101 @@
> +/*
> + * ALSA SoC driver for Allwinner sun8i SoC
> + *
> + * Copyright (C) 2016 Myl?ne Josserand <mylene.josserand@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/firmware.h>
> +#include <linux/module.h>
> +
> +#include <sound/soc.h>
> +
> +static struct snd_soc_aux_dev sun8i_audio_prcm_aux_devs[] = {
> + {
> + .name = "sun8i-codec-analog",
> + .codec_name = "sun8i-codec-analog.0",
> + },
> +};
> +
> +static struct snd_soc_dai_link sun8i_dai_link = {
> + .name = "sun4i-i2s",
> + .stream_name = "Playback",
> + .codec_dai_name = "sun8i",
> + .dai_fmt = SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_I2S |
> + SND_SOC_DAIFMT_CBM_CFM,
> +};
> +
> +static struct snd_soc_card sun8i_card = {
> + .name = "sun8i-card",
> + .owner = THIS_MODULE,
> + .dai_link = &sun8i_dai_link,
> + .num_links = 1,
> + .aux_dev = sun8i_audio_prcm_aux_devs,
> + .num_aux_devs = ARRAY_SIZE(sun8i_audio_prcm_aux_devs),
> +};
> +
> +static int sun8i_probe(struct platform_device *pdev)
> +{
> + struct snd_soc_dai_link *link = &sun8i_dai_link;
> + struct device_node *np = pdev->dev.of_node;
> + int ret;
> +
> + /* register the soc card */
> + sun8i_card.dev = &pdev->dev;
> +
> + /* Retrieve the audio-codec from DT */
> + link->codec_of_node = of_parse_phandle(np, "allwinner,audio-codec", 0);
> + if (!link->codec_of_node) {
> + dev_err(&pdev->dev, "Missing audio codec\n");
> + return -EINVAL;
> + }
> +
> + /* Retrieve DAI from DT */
> + link->cpu_of_node = of_parse_phandle(np, "allwinner,i2s-controller", 0);
Now that I've spent some time trying to add my changes for the H3
ontop of your code, I think this file should be more generic and rely
on the dtsi more. It's pretty A33 specific but with little effort it
can be worked to cover all of the sun8i type drivers. I would change
"allwinner,i2s-controller" to "allwinner,audio-dai" for starters and
then maybe pull in some info for the dai-link from the dtsi.
CK
> + if (!link->cpu_of_node) {
> + dev_err(&pdev->dev, "Missing I2S controller\n");
> + return -EINVAL;
> + }
> +
> + link->platform_of_node = link->cpu_of_node;
> +
> + /* Register the sound card */
> + ret = devm_snd_soc_register_card(&pdev->dev, &sun8i_card);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "Soc register card failed %d\n", ret);
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +static const struct of_device_id sun8i_of_match[] = {
> + { .compatible = "allwinner,sun8i-audio", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, sun8i_of_match);
> +
> +static struct platform_driver sun8i_card_driver = {
> + .probe = sun8i_probe,
> + .driver = {
> + .name = "sun8i-audio",
> + .of_match_table = sun8i_of_match,
> + },
> +};
> +
> +module_platform_driver(sun8i_card_driver);
> +
> +MODULE_AUTHOR("Myl?ne Josserand <mylene.josserand@free-electrons.com>");
> +MODULE_DESCRIPTION("Allwinner sun8i machine ASoC driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-10-05 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70ca1b97-8de4-921f-0cef-e02a88691ccd@caviumnetworks.com>
Manish,
On Tue, Oct 04, 2016 at 06:53:28PM +0530, Manish Jaggi wrote:
>
> On 10/04/2016 04:23 PM, James Morse wrote:
> > Hi Manish,
> >
> > On 04/10/16 11:05, Manish Jaggi wrote:
> >> On 10/04/2016 03:16 PM, James Morse wrote:
> >>> On 03/10/16 13:41, Manish Jaggi wrote:
> >>>> On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:
> >>>>> On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:
> >>>>>> First kernel is booted with mem=2G crashkernel=1G command line option.
> >>>>>> While the system has 64G memory.
> >>>
> >>>>> Are you saying that "mem=..." doesn't have any effect?
> >>>> What I am saying it that If the first kernel is booted using mem= option and crashkernel= option
> >>>> the memory for second kernel has to be withing the crashkernel size.
> >>>> As per /proc/iomem System RAM the information is correct, but the /proc/meminfo is showing total memory
> >>>> much more than the first kernel had in first place.
> >>>
> >>> So your second crashkernel has 63G of memory? Unless you provide the same 'mem='
> >>> to the kdump kernel, this is the expected behaviour. The
> >>> DT:/reserved-memory/crash_dump describes the memory not to use.
> >>>
> >>> On your first boot with 'mem=2G' memblock_mem_limit_remove_map() called from
> >>> arm64_memblock_init() removed the top 62G of memory. Neither the first kernel
> >>> nor kexec-tools know about the top 62G.
> >>> When you run kexec-tools, it describes what it sees in /proc/iomem in the
> >>> DT:/reserved-memory/crash_dump, which is just the remaining 1G of memory.
> >>>
> >>> When we crash and reboot, the crash kernel discovers all 64G of memory from the
> >>> EFI memory map.
> >
> >> So the iomem and meminfo should be same or different for the second kernel?
> >> Also i assumed that crashkernel=1G should restrict the second kernels to 1G.
> >
> > Not with v26 of this series. What should it do with the 62G of memory that was
> > removed by booting with 'mem=2G'? It isn't part of the crashkernel reserved
> > area, and it isn't part of the vmcore described in elfcorehdr either...
> >
> >
> >> This is my understanding from the description. It should not require a second mem= option
> >
> >>> kexec-tools described the 1G of memory that the first kernel was using in the
> >>> DT:/reserved-memory/crash_dump node, so early_init_fdt_scan_reserved_mem()
> >>> reserves the 1G of memory the first kernel used. This leaves us with 63G of memory.
> >>>
> >>> This may change with the next version of kdump if it switches back to using
> >>> DT:/chosen/linux,usable-memory-range.
> >>> If you need v26 to avoid the top 62G of memory, you need to provide the same
> >>> 'mem=' to the first and second kernel.
> >
> >> If I provide for second kernel, I dont see any prints after Bye.
> >> Have you tired this anytime?
> >
> > Yes, on juno-r1 passing 'mem=2G' to both the first and second kernel causes only
> > the first 2G of memory to be used with this pattern:
> > first kernel: [1G used for linux] [1G reserved for Crash kernel] [6G memory
> > hidden]
> > kdump kernel: [1G vmcore] [1G used for linux] [6G memory hidden]
> >
> >
> Oh, ok!
> I was giving mem=1G to crashkernel to test. with mem=2G it works.
I didn't know that you specified "mem=1G" in our local discussions ...
> >>>>>> 1.2 Live crash dump fails with error
> >>>
> >>> ... do we expect this to work? I don't think it has anything to do with this
> >>> series...
> >>>
> >> Why it should not?
> >> I saved the vmcore file while in second kernel. Since crash without vmcore file didnt run,
> >> Tried with vmcore file and it worked. Its just that if you want to boot a second kernel
> >> with read only file system without network live crash dump analysis is handy.
> >
> > Ah, you want to run /usr/bin/crash with the kdump boot of linux. You still need
> > to tell it where to find the memory image: "crash /path/to/vmlinux /proc/vmcore"
> > should do the trick.
> >
> We should fix the documentation of kdump them.
> Since it is not supported, it should be removed.
Remove what?
And can you please double-check if you still have any problem
on a live system or with a saved core file?
(except for "mem=" stuff)
-Takahiro AKASHI
> > Thanks,
> >
> > James
> >
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-10-05 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F37A73.3030105@arm.com>
On Tue, Oct 04, 2016 at 10:46:27AM +0100, James Morse wrote:
> Hi Manish,
>
> On 03/10/16 13:41, Manish Jaggi wrote:
> > On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:
> >> On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:
> >>> With the v26 kdump and v3 kexec-tools and top of tree crash.git, below are the tests done
> >>> Attached is a patch in crash.git (symbols.c) to make crash utility work on my setup.
> >>> Can you please have a look and provide your comments.
> >>>
> >>> To generate a panic, i have a kernel module which on init calls panic.
>
> ... modules ... I haven't tested that. I bet it causes some problems!
> We probably need to include module_alloc_base as an elf note in the vmcore file...
No, I don't think so :)
I created some test module as Manish implied and tested kdump:
(My kernel here even enables KASLR.)
===8<===
$ crash vmlinux vmcore
...
please wait... (gathering module symbol data)
...
crash> mod -S
MODULE NAME SIZE OBJECT FILE
ffff04d78f4b8000 testmod 16384 /opt/buildroot/15.11_64/root/kexec/testmod.ko
crash> bt
PID: 1102 TASK: ffffb4da8e910000 CPU: 0 COMMAND: "insmod"
#0 [ffffb4da8e9afa30] __crash_kexec at ffff0e0045020a54
#1 [ffffb4da8e9afb90] panic at ffff0e004505523c
#2 [ffffb4da8e9afc50] testmod_init at ffff04d78f4b6014 [testmod]
#3 [ffffb4da8e9afb40] do_one_initcall at ffff0e0044f7333c
--- <Exception in user> ---
PC: 0000000a LR: 00000000 SP: ffff04d78f4b6000 PSTATE: 7669726420656c75
X12: ffffb4da8e9ac000 X11: ffff04d78f4b6018 X10: ffffb4da8e9afc50 X9: 20676e6973756143
X8: 00000000 X7: ffff0e0045e5ce00 X6: ffff0e0045e5c000 X5: 600001c5
X4: ffff0e0045020a58 X3: ffffb4da8e9afa30 X2: ffff0e004502098c X1: ffffb4da8e9afa30
X0: 00000124
crash> disas testmod_init
Dump of assembler code for function testmod_init:
0xffff04d78f4b6000 <+0>: stp x29, x30, [sp,#-16]!
0xffff04d78f4b6004 <+4>: mov x29, sp
0xffff04d78f4b6008 <+8>: ldr x0, 0xffff04d78f4b6018
0xffff04d78f4b600c <+12>: bl 0xffff04d78f4b6090
0xffff04d78f4b6010 <+16>: ldr x0, 0xffff04d78f4b6020
0xffff04d78f4b6014 <+20>: bl 0xffff04d78f4b6080
End of assembler dump.
===>8===
(I see some issue in disassembled code, though.)
>
>
> >>> First kernel is booted with mem=2G crashkernel=1G command line option.
> >>> While the system has 64G memory.
>
> >> Are you saying that "mem=..." doesn't have any effect?
> > What I am saying it that If the first kernel is booted using mem= option and crashkernel= option
> > the memory for second kernel has to be withing the crashkernel size.
> > As per /proc/iomem System RAM the information is correct, but the /proc/meminfo is showing total memory
> > much more than the first kernel had in first place.
>
> So your second crashkernel has 63G of memory? Unless you provide the same 'mem='
> to the kdump kernel, this is the expected behaviour. The
> DT:/reserved-memory/crash_dump describes the memory not to use.
>
> On your first boot with 'mem=2G' memblock_mem_limit_remove_map() called from
> arm64_memblock_init() removed the top 62G of memory. Neither the first kernel
> nor kexec-tools know about the top 62G.
> When you run kexec-tools, it describes what it sees in /proc/iomem in the
> DT:/reserved-memory/crash_dump, which is just the remaining 1G of memory.
>
> When we crash and reboot, the crash kernel discovers all 64G of memory from the
> EFI memory map.
> kexec-tools described the 1G of memory that the first kernel was using in the
> DT:/reserved-memory/crash_dump node, so early_init_fdt_scan_reserved_mem()
> reserves the 1G of memory the first kernel used. This leaves us with 63G of memory.
Thank you very much for elaborating this on behalf of myself!
> This may change with the next version of kdump if it switches back to using
> DT:/chosen/linux,usable-memory-range.
Indeed.
We need to talk to Rob.
Thanks,
-Takahiro AKASHI
> If you need v26 to avoid the top 62G of memory, you need to provide the same
> 'mem=' to the first and second kernel.
>
>
> >>> 1.2 Live crash dump fails with error
>
> ... do we expect this to work? I don't think it has anything to do with this
> series...
>
>
> Thanks,
>
> James
>
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-05 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <434a0256-de86-c1f0-0dc3-a38f55596e8e@arm.com>
On Tue, Oct 4, 2016 at 7:59 PM, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>
>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>> Hi Venkatesh,
>>>
>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>> stall" while dumping the trace. Attached is the log of sequence
>>>> followed. Was trying to collect the trace data from hardware and see
>>>> if it is any valid data. Am I missing anything here?.
>>>>
>>>
>>> There are few fixes from me and Suzuki queued for v4.9.
>>> Can you check if this issue persists even on linux-next ?
>>
>>
>> Issue is the same in linux-next as well. Please find the attached log.
>>
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 120.009698] INFO: rcu_preempt detected stalls on CPUs/tasks:
>> [ 120.015307] 2-...: (1 GPs behind) idle=f11/140000000000000/0
>> softirq=224/224 fqs=1903
>> [ 120.023226] (detected by 1, t=5255 jiffies, g=-1, c=-2, q=19)
>> [ 120.029001] Task dump for CPU 2:
>> [ 120.032190] dd R running task 0 1270 1267
>> 0x00000002
>> [ 120.039172] Call trace:
>> [ 120.041594] [<ffff000008085534>] __switch_to+0xc8/0xd4
>> [ 120.046675] [<0000000000020000>] 0x20000
>>
>> Steps followed,
>> # git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> linux-next
>> # cd linux-next
>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig <---
>> enable coresight
>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image
>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
>> # arch/arm64/boot/Image <--- copied this kernel
>> # arch/arm64/boot/dts/arm/juno-r1.dtb <--- copied this dtb
>>
>> Top commit in linux-next is,
>>
>> commit c7d3b912180a9bb0733e5cfab84e5a7493dd3599
>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue Oct 4 14:52:03 2016 +1100
>>
>> Add linux-next specific files for 20161004
>
>
> Can't reproduce it here either.
>
> root at localhost:/sys/bus/coresight/devices# echo 1 > 20010000.etf/enable_sink
> root at localhost:/sys/bus/coresight/devices# echo 1 >
> 22140000.etm/enable_source
> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
> of=/root/etr.bin
> 65536+0 records in
> 65536+0 records out
> 65536 bytes (66 kB) copied, 0.227546 s, 288 kB/s
> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
> of=/root/etr.bin
> 65536+0 records in
> 65536+0 records out
> 65536 bytes (66 kB) copied, 0.233527 s, 281 kB/s
> root at localhost:/sys/bus/coresight/devices# echo 0 > 20010000.etf/enable_sink
> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
> of=/root/etr.bin
> 65536+0 records in
> 65536+0 records out
> 65536 bytes (66 kB) copied, 0.474943 s, 138 kB/s
>
> FWIW, here is my firmware version :
>
> NOTICE: Booting Trusted Firmware
> NOTICE: BL1: v1.1(release):e04723e21362
> NOTICE: BL1: Built : 15:39:56, Sep 1 2015
> NOTICE: BL1: Booting BL2
> NOTICE: BL2: v1.1(release):e04723e21362
> NOTICE: BL2: Built : 15:42:30, Sep 1 2015
> NOTICE: BL1: Booting BL3-1
> NOTICE: BL3-1: v1.1(release):604d5da6f2aa
> NOTICE: BL3-1: Built : 14:50:36, Sep 10 2015
> UEFI firmware (version ea31f8e built at 16:35:17 on Aug 5 2015)
>
Hang is seen while trying to dump trace _after_ disabling the ETM
source. Is it not supposed to work?.
It works fine, when dumped before disabling ETM source. Please find
the log below.
linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
[ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
[ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 enabled
[ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
inport 1 enabled
[ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 108.105492] coresight-tmc 20010000.etf: TMC read start
[ 108.404335] coresight-tmc 20010000.etf: TMC read end
65536+0 records in
65536+0 records out
linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 125.069740] coresight-tmc 20010000.etf: TMC read start
[ 125.184370] coresight-tmc 20010000.etf: TMC read end
65536+0 records in
65536+0 records out
linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
[ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
[ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
inport 1 disabled
[ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 disabled
[ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
<---- It hangs here...
My firmware version,
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.1(debug):4a1dcde
NOTICE: BL1: Built : 17:54:40, Nov 24 2015
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.1(debug):4a1dcde
NOTICE: BL2: Built : 17:54:40, Nov 24 2015
NOTICE: BL1: Booting BL3-1
NOTICE: BL3-1: v1.1(debug):4a1dcde
NOTICE: BL3-1: Built : 17:54:40, Nov 24 2015
UEFI firmware (version 9ed6f7e built@17:54:28 on Nov 24 2015)
>
> Cheers
> Suzuki
>
^ permalink raw reply
* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Vivek Gautam @ 2016-10-05 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgQ2j+NtDwgn972-1UdY=j4DEsB+0d7VdhoC9i9WHRc9yQ@mail.gmail.com>
Hi Anand,
On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon <linux.amoon@gmail.com> wrote:
> Hi Vivek,
>
[snip]
>
> What I feel is that their need to be some reset of usb phy so that
> device are assigned to respective bus ports.
The phy resets are what we do in the phy-exynos5-usbdrd driver. In
addition to what we
have currently in this phy driver, we just need the phy calibration
patch [1] for phy configurations.
[1] https://lkml.org/lkml/2015/2/2/259
> odroid at odroid:~$ lsusb -t
> /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
This shows the ethernet device gets detected on the high-speed port of one
of the controller.
The lsusb output for kernel v4.7.x posted by Michael show that the
ethernet device got detected on super-speed port of the controller.
So, there seems to be a difference between the two.
Or, is this how it is behaving ?
Is this lsusb output on 4.8 kernel with the patch [1] ?
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
>
> Bus 06.Port should register the Realtek Ethernet r8153 device.
> But I am not able to trace out how it's should happen.
If i understand, below is how the configuration looks like on the board?
+-----------------------+
+------>| |
| | Bus 6 |-------+
+-----------+ | (super-speed) | |
| | +-----------------------+ |
|Controller | | --------> Ethernet device
| 2 | |
| | +-----------------------+ |
+-----------+ | | |
| | Bus 5 |-------+
+------>| (high-speed) |
+-----------------------+
+-----------------------+
+------>| |
| | Bus 4 |-------+
+-----------+ | (super-speed) | |
| | +-----------------------+ |
|Controller | | --------> (On board
hub ?? _OR_ external hub with downstream devices) ???
| 1 | |
| | +-----------------------+ |
+-----------+ | | |
| | Bus 3 |-------+
+------>| (high-speed) |
+-----------------------+
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Jassi Brar @ 2016-10-05 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475636064.21937.25.camel@mtksdaap41>
On 5 October 2016 at 08:24, Horng-Shyang Liao <hs.liao@mediatek.com> wrote:
> On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
>
> After I trace mailbox driver, I realize that CMDQ driver cannot use
> tx_done.
>
> CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> driver will apply these tasks into GCE HW "immediately". These tasks,
> which are queued in GCE HW, may not execute immediately since they
> may need to wait event(s), e.g. vsync.
>
> However, in mailbox driver, mailbox uses a software buffer to queue
> sent messages. It only sends next message until previous message is
> done. This cannot fulfill CMDQ's requirement.
>
I understand
a) GCE HW can internally queue many tasks in some 'FIFO'
b) Execution of some task may have to wait until some external event
occurs (like vsync)
c) GCE does not generate irq/flag for each task executed (?)
If so, may be your tx_done should return 'true' so long as the GCE HW
can accept tasks in its 'FIFO'. For mailbox api, any task that is
queued on GCE, is assumed to be transmitted.
> Quote some code from mailbox driver. Please notice "active_req" part.
>
> static void msg_submit(struct mbox_chan *chan)
> {
> ...
> if (!chan->msg_count || chan->active_req)
> goto exit;
> ...
> err = chan->mbox->ops->send_data(chan, data);
> if (!err) {
> chan->active_req = data;
> chan->msg_count--;
> }
> ...
> }
>
> static void tx_tick(struct mbox_chan *chan, int r)
> {
> ...
> spin_lock_irqsave(&chan->lock, flags);
> mssg = chan->active_req;
> chan->active_req = NULL;
> spin_unlock_irqrestore(&chan->lock, flags);
> ...
> }
>
> Current workable CMDQ driver uses mbox_client_txdone() to prevent
> this issue, and then uses self callback functions to handle done tasks.
>
> int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> *task, cmdq_async_flush_cb cb, void *data)
> {
> ...
> mbox_send_message(client->chan, task);
> /* We can send next task immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
> ...
> }
>
> Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> call mbox_chan_received_data() when CMDQ task is done. But, this may
> violate the design of mailbox. What do you think?
>
If my point (c) above does not hold, maybe look at implementing
tx_done() callback and submit next task from the callback of last
done.
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Mugunthan V N @ 2016-10-05 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4ef7fc1-73f7-7136-0d60-6ce8a8ff33b9@ti.com>
On Tuesday 04 October 2016 06:41 PM, Lokesh Vutla wrote:
>
> On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
>> > The default impedance settings of the phy is not the optimal
>> > value, due to this the second ethernet is not working. Fix it
>> > with correct values which makes the second ethernet port to work.
>> >
>> > Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> > ---
>> > arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > index f9cfd3b..d626cd7 100644
>> > --- a/arch/arm/boot/dts/dra72-evm-revc.dts
>> > +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > @@ -62,6 +62,7 @@
>> > ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>> > ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
>> > ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
>> > + ti,min-output-imepdance;
> s/imepdance/impedance
>
Thanks for quick catch. Will fix this in v3.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-05 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004131032.GL11677@lunn.ch>
On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
>
> Did you really test this? Or did you make the same typos in your device
> tree file?
>
I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation
From: Chen-Yu Tsai @ 2016-10-05 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004162430.GQ5228@lukather>
On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Oct 04, 2016 at 11:46:21AM +0200, Myl?ne Josserand wrote:
>> Add the documentation for dt-binding of the analog audiocodec
>> driver for SUN8I SoC.
>>
>> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
>> ---
>> .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> new file mode 100644
>> index 0000000..a03ec20
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>> @@ -0,0 +1,20 @@
>> +* Allwinner A23/A33 Analog Codec
>> +
>> +This codec must be handled as a PRCM subnode.
>
> Like Mark was saying, you should probably reference the sun6i-prcm.txt
> binding here
>
>> +Required properties:
>> +- compatible: must be either "allwinner,sun8i-codec-analog"
>
> Our compatible prefix is <family>-<soc>, and using the older SoC that
> introduced that block.
>
> In this case, that would be sun6i-a31, I think?
sun6i-a31s actually, but a31s has extra line out controls,
so the right one would be sun8i-a23. Both are listed in my
original driver.
ChenYu
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-10-05 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475228829.3658.1.camel@mtksdaap41>
On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> > Hi, HS:
> >
> > One comment inline
> >
> > On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > > Hi CK,
> > >
> > > Please see my inline reply.
> > >
> > > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > > Hi, HS:
> > > >
> > > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > > > CMDQ is used to help write registers with critical time limitation,
> > > > > such as updating display configuration during the vblank. It controls
> > > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > > it can be extended to other hardwares for future requirements.
> > > > >
> > > > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > > > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > > > > ---
> > > >
> > > > [snip...]
> > > >
> > > > > +
> > > > > +struct cmdq_task {
> > > > > + struct cmdq *cmdq;
> > > > > + struct list_head list_entry;
> > > > > + void *va_base;
> > > > > + dma_addr_t pa_base;
> > > > > + size_t cmd_buf_size; /* command occupied size */
> > > > > + size_t buf_size; /* real buffer size */
> > > > > + bool finalized;
> > > > > + struct cmdq_thread *thread;
> > > >
> > > > I think thread info could be removed from cmdq_task. Only
> > > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > > task->thread and caller of both function has the thread info. So you
> > > > could just pass thread info into these two function and remove thread
> > > > info in cmdq_task.
> > >
> > > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > > more pointers will need to be delivered between functions for future
> > > extension. IMHO, it would be better to keep thread pointer inside
> > > cmdq_task.
> > >
> > > > > + struct cmdq_task_cb cb;
> > > >
> > > > I think this callback function is equal to mailbox client tx_done
> > > > callback. It's better to use already-defined interface rather than
> > > > creating your own.
> > >
> > > This is because CMDQ driver allows different callback functions for
> > > different tasks, but mailbox only allows one callback function per
> > > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > > callback functions. So, I will use tx_done in CMDQ v15.
> >
> > Up to now, one callback function for one channel is enough for DRM. So
> > 'different callback function for different sent-message' looks like an
> > advanced function. Maybe you should not include it in first patch.
> >
> > Regards,
> > CK
>
> Hi CK,
>
> OK. I will do it.
>
> Thanks,
> HS
>
> [snip...]
Hi CK,
After I trace mailbox driver, I realize that CMDQ driver cannot use
tx_done.
CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
driver will apply these tasks into GCE HW "immediately". These tasks,
which are queued in GCE HW, may not execute immediately since they
may need to wait event(s), e.g. vsync.
However, in mailbox driver, mailbox uses a software buffer to queue
sent messages. It only sends next message until previous message is
done. This cannot fulfill CMDQ's requirement.
Quote some code from mailbox driver. Please notice "active_req" part.
static void msg_submit(struct mbox_chan *chan)
{
...
if (!chan->msg_count || chan->active_req)
goto exit;
...
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
chan->active_req = data;
chan->msg_count--;
}
...
}
static void tx_tick(struct mbox_chan *chan, int r)
{
...
spin_lock_irqsave(&chan->lock, flags);
mssg = chan->active_req;
chan->active_req = NULL;
spin_unlock_irqrestore(&chan->lock, flags);
...
}
Current workable CMDQ driver uses mbox_client_txdone() to prevent
this issue, and then uses self callback functions to handle done tasks.
int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
*task, cmdq_async_flush_cb cb, void *data)
{
...
mbox_send_message(client->chan, task);
/* We can send next task immediately, so just call txdone. */
mbox_client_txdone(client->chan, 0);
...
}
Another solution is to use rx_callback; i.e. CMDQ mailbox controller
call mbox_chan_received_data() when CMDQ task is done. But, this may
violate the design of mailbox. What do you think?
Thanks,
HS
Hi Jassi,
Do you have any suggestion about previous situation?
Thanks,
HS
^ permalink raw reply
* [PATCH] clk: lpc32xx: fix pwm clock divider computation
From: Vladimir Zapolskiy @ 2016-10-05 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474915467-11101-1-git-send-email-slemieux.tyco@gmail.com>
Hi Sylvain,
On 26.09.2016 21:44, Sylvain Lemieux wrote:
> From: Sylvain Lemieux <slemieux@tycoint.com>
>
> A zero value in the PWM clock divider register
> (PWM1_FREQ/PWM2_FREQ) turn off the PWM clock.
>
> The "CLK_DIVIDER_ALLOW_ZERO" option is used for hardware that handle
> the zero divider by not modifying their clock input (i.e. bypass).
> See "/include/linux/clk-provider.h" for details.
the problem is that the divider value is not set to some non-zero
value when the clock is enabled, right?
I think it does not matter if the clock rate value is set to parent
clock rate or any other value when divider is 0 *and* clock is gated.
Enabling or disabling a clock is a gate control, so I suggest two
alternative options at your choice (my preference is option 2):
1) add a custom clk_pwm_gate_enable(), clk_pwm_gate_disable() and
clk_pwm_gate_is_enabled() functions combined under lpc32xx_clk_pwm_gate_ops.
Next instead of adding one more define for a single exception
please reassign .ops for two PWM clocks in runtime in
lpc32xx_clk_init() function before calling lpc32xx_clk_register()
in a loop.
But this option is too invasive, a simpler solution is below.
2) in lpc32xx_clk_init() before clock registrations check for zero
dividers of PWM clocks, then if a divider is 0 and clock is gated
set divider to 1, if the divider is 0 and clock is not gated then
gate the clock and set divider to 1, in other cases do nothing.
> Remove the CLK_DIVIDER_ALLOW_ZERO option and add support to handle
> the clock rate computation of the PWM clock divider 0 value.
>
> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> ---
> Note:
> * Should we include a new CLK_DIVIDER option for this case
> (i.e. clock off when zero ) in "clk-provider.h"?
>
> drivers/clk/nxp/clk-lpc32xx.c | 52 +++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
> index 34c9735..3ca3a14 100644
> --- a/drivers/clk/nxp/clk-lpc32xx.c
> +++ b/drivers/clk/nxp/clk-lpc32xx.c
> @@ -959,6 +959,25 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> divider->flags);
> }
>
> +static unsigned long clk_divider_pwm_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
> + unsigned int val;
> +
> + regmap_read(clk_regmap, divider->reg, &val);
> +
> + val >>= divider->shift;
> + val &= div_mask(divider->width);
> +
> + /* Handle 0 divider -> PWM clock is off. */
> + if(val == 0)
No space in front of the open parenthesis.
> + return 0;
> +
> + return divider_recalc_rate(hw, parent_rate, val, divider->table,
> + divider->flags);
> +}
> +
> static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> @@ -999,6 +1018,12 @@ static const struct clk_ops lpc32xx_clk_divider_ops = {
> .set_rate = clk_divider_set_rate,
> };
>
> +static const struct clk_ops lpc32xx_clk_pwm_divider_ops = {
> + .recalc_rate = clk_divider_pwm_recalc_rate,
> + .round_rate = clk_divider_round_rate,
> + .set_rate = clk_divider_set_rate,
> +};
> +
> static u8 clk_mux_get_parent(struct clk_hw *hw)
> {
> struct lpc32xx_clk_mux *mux = to_lpc32xx_mux(hw);
> @@ -1151,6 +1176,25 @@ struct clk_hw_proto {
> }, \
> }
>
> +#define LPC32XX_DEFINE_PWM_DIV(_idx, _reg, _shift, _width, _tab, _fl) \
> +[CLK_PREFIX(_idx)] = { \
> + .type = CLK_DIV, \
> + { \
> + .hw0 = { \
> + .ops = &lpc32xx_clk_pwm_divider_ops, \
> + { \
> + .div = { \
> + .reg = LPC32XX_CLKPWR_ ## _reg, \
> + .shift = (_shift), \
> + .width = (_width), \
> + .table = (_tab), \
> + .flags = (_fl), \
> + }, \
> + }, \
> + }, \
> + }, \
> +}
> +
> #define LPC32XX_DEFINE_GATE(_idx, _reg, _bit, _flags) \
> [CLK_PREFIX(_idx)] = { \
> .type = CLK_GATE, \
> @@ -1281,14 +1325,14 @@ static struct clk_hw_proto clk_hw_proto[LPC32XX_CLK_HW_MAX] = {
> LPC32XX_DEFINE_GATE(MCPWM, TIMCLK_CTRL1, 6, 0),
>
> LPC32XX_DEFINE_MUX(PWM1_MUX, PWMCLK_CTRL, 1, 0x1, NULL, 0),
> - LPC32XX_DEFINE_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
> - CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
> + LPC32XX_DEFINE_PWM_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
> + CLK_DIVIDER_ONE_BASED),
> LPC32XX_DEFINE_GATE(PWM1_GATE, PWMCLK_CTRL, 0, 0),
> LPC32XX_DEFINE_COMPOSITE(PWM1, PWM1_MUX, PWM1_DIV, PWM1_GATE),
>
> LPC32XX_DEFINE_MUX(PWM2_MUX, PWMCLK_CTRL, 3, 0x1, NULL, 0),
> - LPC32XX_DEFINE_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
> - CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
> + LPC32XX_DEFINE_PWM_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
> + CLK_DIVIDER_ONE_BASED),
> LPC32XX_DEFINE_GATE(PWM2_GATE, PWMCLK_CTRL, 2, 0),
> LPC32XX_DEFINE_COMPOSITE(PWM2, PWM2_MUX, PWM2_DIV, PWM2_GATE),
>
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Huang, Tao @ 2016-10-05 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001140939.GA31220@vaio-ubuntu>
Hi, Pawe?:
On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
RK3066 only support 2GB memory from 0x60000000 to 0xE0000000, can not access
above 0xfe000000. I think you mean 0x9F000000?
> solved same way.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -93,6 +93,19 @@
> };
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + /*
> + * The rk3066 cannot use the memory area above 0x9F000000
> + * for some unknown reason.
> + */
I don't remember RK3066 has such limit. I will double check with our IC
design team.
Do you know which master can not access this memory area
[0x9F000000~0xA0000000)?
> + unusable at 9F000000 {
> + reg = <0x9F000000 0x1000000>;
> + };
> + };
> +
> i2s0: i2s at 10118000 {
> compatible = "rockchip,rk3066-i2s";
> reg = <0x10118000 0x2000>;
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Vladimir Zapolskiy @ 2016-10-05 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474916056-11336-1-git-send-email-slemieux.tyco@gmail.com>
Hi Sylvain,
On 26.09.2016 21:54, Sylvain Lemieux wrote:
> From: Sylvain Lemieux <slemieux@tycoint.com>
>
> Probably most of NXP LPC32xx boards have 13MHz main oscillator
> and therefore for HCLK PLL and ARM core clock rate default
> hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
> rate of 208MHz / 2 = 104MHz.
>
> The change explicitly defines the peripheral PWM1/PWM2 default
> clock output rate of 104MHz. If needed it can be redefined
> in a board DTS file.
>
> Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
> ---
> Note:
> * There is a dependency on the following patch:
> "ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
> http://www.spinics.net/lists/arm-kernel/msg530277.html
> * This patch should be apply after
> "ARM: dts: lpc32xx: add pwm-cells to base dts file"
> http://www.spinics.net/lists/arm-kernel/msg534050.html
> - There is no dependency between the patches.
>
> arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> index c031c94..d669200 100644
> --- a/arch/arm/boot/dts/lpc32xx.dtsi
> +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> @@ -471,6 +471,7 @@
> clocks = <&clk LPC32XX_CLK_PWM1>;
> assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
> assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> + assigned-clock-rates = <104000000>;
PWM controller clock source can be 32KHz or CLK_PERIPH, the latter is
equal either to SYSCLK or HCLK PLL divided by HCLKDIV_CTRL[6:2].
Do you set the divider to 1? If yes, then I would say
1) this is very specific to your board, generally CLK_PERIPH
is set to be about 10-13MHz,
2) HCLKDIV or PERIPH clock configuration shall not be done in pwm device node.
104MHz is too high value to be set by default for PWM clock.
> status = "disabled";
> #pwm-cells = <2>;
> };
> @@ -481,6 +482,7 @@
> clocks = <&clk LPC32XX_CLK_PWM2>;
> assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
> assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> + assigned-clock-rates = <104000000>;
> status = "disabled";
> #pwm-cells = <2>;
> };
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: rockchip: arch counter doesn't tick in system suspend
From: Doug Anderson @ 2016-10-04 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475604730-140264-2-git-send-email-briannorris@chromium.org>
Hi,
On Tue, Oct 4, 2016 at 11:12 AM, Brian Norris <briannorris@chromium.org> wrote:
> The "arm,no-tick-in-suspend" property was introduced to note
> implementations where the system counter does not quite follow the ARM
> specification that it "must be implemented in an always-on power
> domain".
>
> Particularly, RK3399's counter stops ticking when we switch from the
> 24MHz clock to the 32KHz clock in low-power suspend, so let's mark it as
> such.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> v2: new in v2
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Doug Anderson @ 2016-10-04 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
Hi,
On Tue, Oct 4, 2016 at 11:12 AM, Brian Norris <briannorris@chromium.org> wrote:
> The ARM ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> v2:
> * add new device tree property, instead of re-using the "always-on"
> property (which has different meaning)
>
> Documentation/devicetree/bindings/arm/arch_timer.txt | 5 +++++
> drivers/clocksource/arm_arch_timer.c | 9 ++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
FWIW:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* ks_dw_pcie_initiate_link_train() question
From: Murali Karicheri @ 2016-10-04 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004174051.GE3449@localhost>
On 10/04/2016 01:40 PM, Bjorn Helgaas wrote:
> Hi Murali,
>
> This code looks suspicious. Can you comment?
>
> void ks_dw_pcie_initiate_link_train(struct keystone_pcie *ks_pcie)
> {
> u32 val;
>
> /* Disable Link training */
> val = readl(ks_pcie->va_app_base + CMD_STATUS);
> val &= ~LTSSM_EN_VAL;
> writel(LTSSM_EN_VAL | val, ks_pcie->va_app_base + CMD_STATUS);
>
> Here we cleared the LTSSM_EN_VAL bit in "val", but then we add it
> right back in before writing it back to CMD_STATUS.
>
> That looks like a cut and paste error to me, but of course I don't
> know the hardware.
>
> /* Initiate Link Training */
> val = readl(ks_pcie->va_app_base + CMD_STATUS);
> writel(LTSSM_EN_VAL | val, ks_pcie->va_app_base + CMD_STATUS);
> }
>
>
Bjorn,
Good catch! That is a cut-n-paste error. Here is the description from
device manual
================
Disable link training by de-asserting the LTSSM_EN bit in the PCIESS
Command Status Register (CMD_STATUS[LTSSM_EN]=0). Upon reset, the
LTSSM_EN is de-asserted automatically by hardware.
Initiate link training can be initiated by asserting LTSSM_EN bit in the
CMD_STATUS register (CMD_STATUS[LTSSM_EN]=1).
================================================
Probably it works because it is de-asserted automatically upon
reset by hardware. Let me test this and send you a patch?
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* [PATCH] efi/arm: fix absolute relocation detection for older toolchains
From: Matt Fleming @ 2016-10-04 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu94ZEuGyrcGTKMvTPKpvaR+R3AAXNY=diX28RDhc=Cv7Q@mail.gmail.com>
On Tue, 04 Oct, at 11:34:31AM, Ard Biesheuvel wrote:
>
> These relocations are harmless, since the debug ones are only
> interpreted by the debugger, and the ones generated by
> EXPORT_SYMBOL(sort) will never be referenced, since the symbols they
> contain are either renamed to __efistub_xxx (arm64), or they are not
> part of the kernel proper (arm)
>
> So both cases are false positives, but the diagnostic is important,
> and so breaking the build is appropriate for any other absolute
> relocation that may appear.
>
> The effect of the patch is not that the diagnostic is ignored, but
> that these relocations are not generated in the first place (-g0) or
> removed explicitly (ksymtab/krcrctab+sort) rather than via a wildcard.
> So other than not breaking the build, this patch should have no user
> observeable differences.
Thanks Ard, sounds reasonable. Feel free to take this through
whichever tree you think is best.
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
^ permalink raw reply
* [PATCH V2 3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-04 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475615720-31047-1-git-send-email-okaya@codeaurora.org>
The SCI function was removed in two steps (first refactor and then remove).
This patch does the revert in one step.
The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
refactored the original code so that SCI penalty is calculated dynamically
by the time get_penalty function is called. This patch does a partial
revert for the SCI functionality only.
The commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function") is
for the removal of the function. SCI penalty API was replaced by the
runtime penalty calculation based on the value of
acpi_gbl_FADT.sci_interrupt.
The IRQ type does not get updated at the right time for some platforms and
results in incorrect penalty assignment for PCI IRQs as
irq_get_trigger_type returns the wrong type.
The register_gsi function delivers the IRQ found in the ACPI table to
the interrupt controller driver. Penalties are calculated before a
link object is enabled to find out which interrupt has the least number
of users. By the time penalties are calculated, the IRQ is not registered
yet and the API returns the wrong type.
Tested-by: Jonathan Liu <net147@gmail.com>
Tested-by: Ondrej Zary <linux@rainbow-software.org>
Link: https://lkml.org/lkml/2016/10/4/283
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 34 ++++++++++++++--------------------
include/linux/acpi.h | 1 +
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 90d84c3..0ffd26e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
* stash over-ride to indicate we've been here
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 06c2a11..6a2af19 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -495,27 +495,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
static int acpi_irq_get_penalty(int irq)
{
- int penalty = 0;
-
- /*
- * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
- * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
- * use for PCI IRQs.
- */
- if (irq == acpi_gbl_FADT.sci_interrupt) {
- u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
-
- if (type != IRQ_TYPE_LEVEL_LOW)
- penalty += PIRQ_PENALTY_ISA_ALWAYS;
- else
- penalty += PIRQ_PENALTY_PCI_USING;
- }
-
- if (irq < ACPI_MAX_ISA_IRQS)
- return penalty + acpi_irq_penalty[irq];
+ if (irq < ACPI_MAX_IRQS)
+ return acpi_irq_penalty[irq];
- penalty += acpi_irq_pci_sharing_penalty(irq);
- return penalty;
+ return acpi_irq_pci_sharing_penalty(irq);
}
int __init acpi_irq_penalty_init(void)
@@ -886,6 +869,17 @@ bool acpi_isa_irq_available(int irq)
acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
}
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
+{
+ if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
+ if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
+ polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
+ acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
+ else
+ acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
+ }
+}
+
/*
* Over-ride default table to reserve additional IRQs for use by ISA
* e.g. acpi_irq_isa=5
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d8452c..85ac7d5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -318,6 +318,7 @@ struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
void acpi_penalize_isa_irq(int irq, int active);
bool acpi_isa_irq_available(int irq);
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
void acpi_pci_irq_disable (struct pci_dev *dev);
extern int ec_read(u8 addr, u8 *val);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-04 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475615720-31047-1-git-send-email-okaya@codeaurora.org>
The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
resource requirements") removed PCI_USING penalty from
acpi_pci_link_allocate function as there is no longer a fixed size penalty
array for both PCI and IRQ interrupts.
We need to add the PCI_USING penalty for ISA interrupts too if the link is
in use and matches our ISA IRQ number.
Tested-by: Jonathan Liu <net147@gmail.com>
Tested-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/pci_link.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index f3792f4..06c2a11 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -620,6 +620,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
acpi_device_bid(link->device));
return -ENODEV;
} else {
+ if (link->irq.active < ACPI_MAX_IRQS)
+ acpi_irq_penalty[link->irq.active] +=
+ PIRQ_PENALTY_PCI_USING;
+
printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
acpi_device_name(link->device),
acpi_device_bid(link->device), link->irq.active);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/3] Revert "ACPI, PCI, IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-04 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475615720-31047-1-git-send-email-okaya@codeaurora.org>
This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array
size to 16").
The code maintains a fixed size array for IRQ penalties. The array
gets updated by external calls such as acpi_penalize_sci_irq,
acpi_penalize_isa_irq to reflect the actual interrupt usage of the
system. Since the IRQ distribution is platform specific, this is
not known ahead of time. The IRQs get updated based on the SCI
interrupt number BIOS has chosen or the ISA IRQs that were assigned
to existing peripherals.
By the time ACPI gets initialized, this code tries to determine an
IRQ number based on penalty values in this array. It will try to locate
the IRQ with the least penalty assignment so that interrupt sharing is
avoided if possible.
A couple of notes about the external APIs:
1. These API can be called before the ACPI is started. Therefore, one
cannot assume that the PCI link objects are initialized for calculating
penalties.
2. The polarity and trigger information passed via the
acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
is reporting as the call might have been placed before the IRQ is
registered by the interrupt subsystem.
The previous change was in the direction to remove these external API and
try to calculate the penalties at runtime for the ISA path as well. This
didn't work out well with the existing platforms.
Restoring the old behavior for IRQ < 256 and the new behavior will remain
effective for IRQ >= 256.
Tested-by: Jonathan Liu <net147@gmail.com>
Tested-by: Ondrej Zary <linux@rainbow-software.org>
Link: http://www.gossamer-threads.com/lists/linux/kernel/2537016#2537016
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/pci_link.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index c983bf7..f3792f4 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -438,6 +438,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
* enabled system.
*/
+#define ACPI_MAX_IRQS 256
#define ACPI_MAX_ISA_IRQS 16
#define PIRQ_PENALTY_PCI_POSSIBLE (16*16)
@@ -446,7 +447,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
#define PIRQ_PENALTY_ISA_USED (16*16*16*16*16)
#define PIRQ_PENALTY_ISA_ALWAYS (16*16*16*16*16*16)
-static int acpi_isa_irq_penalty[ACPI_MAX_ISA_IRQS] = {
+static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ0 timer */
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ1 keyboard */
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ2 cascade */
@@ -511,7 +512,7 @@ static int acpi_irq_get_penalty(int irq)
}
if (irq < ACPI_MAX_ISA_IRQS)
- return penalty + acpi_isa_irq_penalty[irq];
+ return penalty + acpi_irq_penalty[irq];
penalty += acpi_irq_pci_sharing_penalty(irq);
return penalty;
@@ -538,14 +539,14 @@ int __init acpi_irq_penalty_init(void)
for (i = 0; i < link->irq.possible_count; i++) {
if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
- acpi_isa_irq_penalty[link->irq.
+ acpi_irq_penalty[link->irq.
possible[i]] +=
penalty;
}
} else if (link->irq.active &&
- (link->irq.active < ACPI_MAX_ISA_IRQS)) {
- acpi_isa_irq_penalty[link->irq.active] +=
+ (link->irq.active < ACPI_MAX_IRQS)) {
+ acpi_irq_penalty[link->irq.active] +=
PIRQ_PENALTY_PCI_POSSIBLE;
}
}
@@ -828,7 +829,7 @@ static void acpi_pci_link_remove(struct acpi_device *device)
}
/*
- * modify acpi_isa_irq_penalty[] from cmdline
+ * modify acpi_irq_penalty[] from cmdline
*/
static int __init acpi_irq_penalty_update(char *str, int used)
{
@@ -837,24 +838,24 @@ static int __init acpi_irq_penalty_update(char *str, int used)
for (i = 0; i < 16; i++) {
int retval;
int irq;
- int new_penalty;
retval = get_option(&str, &irq);
if (!retval)
break; /* no number found */
- /* see if this is a ISA IRQ */
- if ((irq < 0) || (irq >= ACPI_MAX_ISA_IRQS))
+ if (irq < 0)
+ continue;
+
+ if (irq >= ARRAY_SIZE(acpi_irq_penalty))
continue;
if (used)
- new_penalty = acpi_irq_get_penalty(irq) +
- PIRQ_PENALTY_ISA_USED;
+ acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ PIRQ_PENALTY_ISA_USED;
else
- new_penalty = 0;
+ acpi_irq_penalty[irq] = 0;
- acpi_isa_irq_penalty[irq] = new_penalty;
if (retval != 2) /* no next number */
break;
}
@@ -870,14 +871,14 @@ static int __init acpi_irq_penalty_update(char *str, int used)
*/
void acpi_penalize_isa_irq(int irq, int active)
{
- if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
- acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
- (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
+ if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty))
+ acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
}
bool acpi_isa_irq_available(int irq)
{
- return irq >= 0 && (irq >= ARRAY_SIZE(acpi_isa_irq_penalty) ||
+ return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
}
--
1.9.1
^ permalink raw reply related
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