* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-14 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <127cdd42-6fd8-c671-60b7-3826b351577f@samsung.com>
Hi,
On 14-11-16 10:12, Jacek Anaszewski wrote:
> Hi,
>
> On 11/13/2016 02:52 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 13-11-16 12:44, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 11/12/2016 10:14 PM, Hans de Goede wrote:
>>
>> <snip>
>>
>>>>>> So I would like to propose creating a new read-write
>>>>>> user_brightness file.
>>>>>>
>>>>>> The write behavior would be 100% identical to the brightness
>>>>>> file (in code terms it will call the same store function).
>>>>>>
>>>>>> The the read behavior otoh will be different: it will shows
>>>>>> the last brightness as set by the user, this would show the
>>>>>> read behavior we really want of brightness: show the real
>>>>>> brightness when not blinking / triggers are active and show
>>>>>> the brightness used when on when blinking / triggers are active.
>>>>>>
>>>>>> We could then add poll support on this new user_brightness
>>>>>> file, thus avoiding the problem with the extra cpu-load on
>>>>>> notifications on blinking / triggers.
>>>>>
>>>>> I agree that user_brightness allows to solve the issues you raised
>>>>> about inconsistent write and read brightness' semantics
>>>>> (which is not that painful IMHO).
>>>>>
>>>>> Reporting non-user brightness changes on user_brightness file
>>>>> doesn't sound reasonable though.
>>>>
>>>> The changes I'm interested in are user brightness changes they
>>>> are just not done through sysfs, but through a hardwired hotkey,
>>>> they are however very much done by the user.
>>>
>>> Ah, so this file name would be misleading especially taking into account
>>> the context in which "user" is used in kernel, which predominantly
>>> means "userspace", e.g. copy_to_user(), copy_from_user().
>>>
>>>>> Also, how would we read the
>>>>> brightness set by the firmware? We'd have to read brightness
>>>>> file, so still two files would have to be opened which is
>>>>> a second drawback of this approach.
>>>>
>>>> No, look carefully at the definition of the read behavior
>>>> I plan to put in the ABI doc:
>>>
>>> OK, "user" was what confused me. So in this case changes made
>>> by the firmware even if in a result of user activity
>>> (pressing hardware key) obviously cannot be treated similarly
>>> to the changes made from the userspace context.
>>
>> In the end both result on the brightness of the device
>> changing, so any userspace process interested in monitoring
>> the brightness will want to know about both type of changes.
>>
>>> Unless you're able to give references to the kernel code which
>>> contradict my judgement.
>>
>> AFAIK the audio code will signal volume changes done by
>> hardwired buttons the same way as audio changes done
>> by userspace calling into the kernel. This also makes
>> sense because in the end, what is interesting for a
>> mixer app, is that the volume changed, and what the
>> new volume is.
>
> OK, so it is indeed similar to your LED use case. Nonetheless
> in case of LED controllers it is also possible that hardware
> adjusts LED brightness in case of low battery voltage.
>
> If a device is able e.g. to generate an interrupt to notify this
> kind of event, then we would like also to be able to notify the client
> about that. It wouldn't be user generated brightness change though.
>
>>>> "Reading this file will return the actual led brightness
>>>> when not blinking and no triggers are active; reading this
>>>> file will return the brightness used when the led is on
>>>> when blinking or triggers are active."
>>>
>>> This is unnecessarily entangled. Blinking means timer trigger
>>> is active.
>>
>> Ok.
>>
>>>> So for e.g. the backlit keyboard case reading this single
>>>> file will return the actual brightness of the backlight,
>>>> since this does not involve blinking or triggers.
>>>>
>>>> Basically the idea is that the user_brightness file
>>>> will have the semantics which IMHO the brightness file
>>>> itself should have had from the beginning, but which
>>>> we can't change now due to ABI reasons.
>>>
>>> And in fact introducing user_brightness file would indeed
>>> fix that shortcoming. However without providing notifications
>>> of hw brightness changes on it.
>>
>> See above, I believe such a file should report any
>> changes in brightness, except those caused by triggers,
>> so it would report hw brightness changes.
>>
>> Anyways if you're not interested in fixing the
>> shortcomings of the current read behavior on the
>> brightness file (I'm fine with that, I can live
>> with the shortcomings) I suggest that we simply go
>> with v2 of my poll() patch.
>
> v2 entails power consumption related issues.
>
> Generally I think that we could add the file you proposed,
> however it would be good to devise a name which will cover
> also the cases when brightness is changed by firmware without
> user interaction.
>
>>>>> Having no difference in this area between the two approaches
>>>>> I'm still in favour of the read-only file for notifying
>>>>> brightness changes procured by hardware.
>>>>
>>>> That brings back the needing 2 fds problem; and does
>>>> not solve userspace not being able to reliably read
>>>> the led on brightness when blinking or using triggers.
>>>>
>>>> And this also has the issue that one is doing poll() on
>>>> one fd to detect changes on another fd,
>>>
>>> It is not necessarily true. We can treat the polling on
>>> hw_brightness_change file as a means to detect brightness
>>> changes procured by hardware and we can read that brightness
>>> by executing read on this same fd. It could return -ENODATA
>>> if no such an event has occurred so far.
>>
>> That would still require 2 fds as userspace also wants to
>> be able to set the keyboard backlight, but allowing read()
>> on the hw_brightness_change file at least fixes the weirdness
>> where userspace gets woken from poll() without being able to
>> read. So if you insist on going the hw_brightness_change file
>> route, then I can live with that (and upower will simply
>> need to open 2 fds, that is doable).
>>
>> But, BUT, I would greatly prefer to just go for v4 of my
>> patch, which fixes the only real problem we've seen with
>> my patch as original merged without adding a new, somewhat
>> convoluted sysfs attribute.
>
> Hmm, v4 still calls led_notify_brightness_change(led_cdev)
> from both __led_set_brightness() and __led_set_brightness_blocking().
Ugh, I see I accidentally send a v4 twice, instead of
calling the version which dropped those called v5 as
I should have, sorry.
The v4 which I would like to see merged, the one with
those calls dropped, is here:
https://patchwork.kernel.org/patch/9423093/
Regards,
Hans
^ permalink raw reply
* [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-14 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110114505.17618-1-maitysanchayan@gmail.com>
Enable DMA for DSPI2 and DSPI3 on Vybrid.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Add signed-off-by missing in v1.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
^ permalink raw reply related
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-14 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-4-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
OK, following the discussion elsewhere I've had a go at the less stupid,
but more involved, version. Thoughts?
Robin.
----->8-----
From: Robin Murphy <robin.murphy@arm.com>
Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
include/linux/dma-iommu.h | 6 +++
2 files changed, 100 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..33d66a8273c6 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
- struct iommu_dma_cookie *cookie;
-
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
- if (!cookie)
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
return -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);
/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ struct iommu_dma_cookie *cookie;
+
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!cookie)
+ return -ENOMEM;
+
+ cookie->msi_iova = base;
+ domain->iova_cookie = cookie;
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_msi_cookie);
+
+/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- 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;
@@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- 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))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
+
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..d69932474576 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@ int iommu_dma_init(void);
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Corentin Labbe @ 2016-11-14 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479120886-13425-4-git-send-email-sunil.kovvuri@gmail.com>
On Mon, Nov 14, 2016 at 04:24:44PM +0530, sunil.kovvuri at gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> This patch fixes enabling of HW verification of L3/L4 length and
> TCP/UDP checksum which is currently being cleared. Also fixed VLAN
> stripping config which is being cleared when multiqset is enabled.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> index f0e0ca6..3050177 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> @@ -538,9 +538,12 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
> mbx.rq.cfg = (1ULL << 62) | (RQ_CQ_DROP << 8);
> nicvf_send_msg_to_pf(nic, &mbx);
>
> - nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0, 0x00);
> - if (!nic->sqs_mode)
> + if (!nic->sqs_mode && (qidx == 0)) {
> + /* Enable checking L3/L4 length and TCP/UDP checksums */
> + nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0,
> + ((1 << 24) | (1 << 23) | (1 << 21)));
Hello
You could use the BIT() macro here
Regards
^ permalink raw reply
* [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Linus Walleij @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
When dynamically unloading overlays, it is important that freed pins are
restored to being inputs to prevent functions from being enabled in
multiple places at once.
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I want to apply this to cater for my GPIOLIB_IRQCHIP
refactorings.
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 1d8fc104e26b..2df59d9964a2 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -844,6 +844,16 @@ static const struct pinctrl_ops bcm2835_pctl_ops = {
.dt_free_map = bcm2835_pctl_dt_free_map,
};
+static int bcm2835_pmx_free(struct pinctrl_dev *pctldev,
+ unsigned offset)
+{
+ struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
+
+ /* disable by setting to GPIO_IN */
+ bcm2835_pinctrl_fsel_set(pc, offset, BCM2835_FSEL_GPIO_IN);
+ return 0;
+}
+
static int bcm2835_pmx_get_functions_count(struct pinctrl_dev *pctldev)
{
return BCM2835_FSEL_COUNT;
@@ -903,6 +913,7 @@ static int bcm2835_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
}
static const struct pinmux_ops bcm2835_pmx_ops = {
+ .free = bcm2835_pmx_free,
.get_functions_count = bcm2835_pmx_get_functions_count,
.get_function_name = bcm2835_pmx_get_function_name,
.get_function_groups = bcm2835_pmx_get_function_groups,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Linus Walleij @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
Contrary to the documentation, the BCM2835 GPIO controller actually
has four interrupt lines - one each for the three IRQ groups and one
common. Confusingly, the GPIO interrupt groups don't correspond
directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
so split out a function to process the interrupts for a single GPIO
bank.
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I want to apply this to cater for my GPIOLIB_IRQCHIP
refactorings.
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index b2dd278f18b1..1d8fc104e26b 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -47,6 +47,7 @@
#define MODULE_NAME "pinctrl-bcm2835"
#define BCM2835_NUM_GPIOS 54
#define BCM2835_NUM_BANKS 2
+#define BCM2835_NUM_IRQS 3
#define BCM2835_PIN_BITMAP_SZ \
DIV_ROUND_UP(BCM2835_NUM_GPIOS, sizeof(unsigned long) * 8)
@@ -88,13 +89,13 @@ enum bcm2835_pinconf_pull {
struct bcm2835_gpio_irqdata {
struct bcm2835_pinctrl *pc;
- int bank;
+ int irqgroup;
};
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
- int irq[BCM2835_NUM_BANKS];
+ int irq[BCM2835_NUM_IRQS];
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -105,7 +106,7 @@ struct bcm2835_pinctrl {
struct gpio_chip gpio_chip;
struct pinctrl_gpio_range gpio_range;
- struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_BANKS];
+ struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_IRQS];
spinlock_t irq_lock[BCM2835_NUM_BANKS];
};
@@ -391,17 +392,16 @@ static struct gpio_chip bcm2835_gpio_chip = {
.can_sleep = false,
};
-static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
+static int bcm2835_gpio_irq_handle_bank(struct bcm2835_pinctrl *pc,
+ unsigned int bank, u32 mask)
{
- struct bcm2835_gpio_irqdata *irqdata = dev_id;
- struct bcm2835_pinctrl *pc = irqdata->pc;
- int bank = irqdata->bank;
unsigned long events;
unsigned offset;
unsigned gpio;
unsigned int type;
events = bcm2835_gpio_rd(pc, GPEDS0 + bank * 4);
+ events &= mask;
events &= pc->enabled_irq_map[bank];
for_each_set_bit(offset, &events, 32) {
gpio = (32 * bank) + offset;
@@ -409,7 +409,30 @@ static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
generic_handle_irq(irq_linear_revmap(pc->irq_domain, gpio));
}
- return events ? IRQ_HANDLED : IRQ_NONE;
+
+ return (events != 0);
+}
+
+static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
+{
+ struct bcm2835_gpio_irqdata *irqdata = dev_id;
+ struct bcm2835_pinctrl *pc = irqdata->pc;
+ int handled = 0;
+
+ switch (irqdata->irqgroup) {
+ case 0: /* IRQ0 covers GPIOs 0-27 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 0, 0x0fffffff);
+ break;
+ case 1: /* IRQ1 covers GPIOs 28-45 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 0, 0xf0000000) |
+ bcm2835_gpio_irq_handle_bank(pc, 1, 0x00003fff);
+ break;
+ case 2: /* IRQ2 covers GPIOs 46-53 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 1, 0x003fc000);
+ break;
+ }
+
+ return handled ? IRQ_HANDLED : IRQ_NONE;
}
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
@@ -1000,8 +1023,6 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
for (i = 0; i < BCM2835_NUM_BANKS; i++) {
unsigned long events;
unsigned offset;
- int len;
- char *name;
/* clear event detection flags */
bcm2835_gpio_wr(pc, GPREN0 + i * 4, 0);
@@ -1016,10 +1037,15 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
for_each_set_bit(offset, &events, 32)
bcm2835_gpio_wr(pc, GPEDS0 + i * 4, BIT(offset));
+ spin_lock_init(&pc->irq_lock[i]);
+ }
+
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
pc->irq[i] = irq_of_parse_and_map(np, i);
pc->irq_data[i].pc = pc;
- pc->irq_data[i].bank = i;
- spin_lock_init(&pc->irq_lock[i]);
+ pc->irq_data[i].irqgroup = i;
len = strlen(dev_name(pc->dev)) + 16;
name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
@@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
.remove = bcm2835_pinctrl_remove,
.driver = {
.name = MODULE_NAME,
+ .owner = THIS_MODULE,
.of_match_table = bcm2835_pinctrl_match,
},
};
--
2.7.4
^ permalink raw reply related
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105203841.9661-1-uwe@kleine-koenig.org>
Hello Uwe and all!
On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig
<uwe@kleine-koenig.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
>
> Hello,
>
> the following components are working:
>
> - WAN port
> - eMMC
But I not not sure about DDR50 mode. At least with kernel 4.4, that we
use in production, we had to limit to SDR50 to overcome I/O errors and
communication instability, if I can remember it correctly. So it might
need more testing with the current kernel.
>
> - UART0
> - USB
It is worth noting that the USB 2.0 interface of Armada 385 is wired to
USB pinout of the last (right-most) PCIe connector. The two USB3
interfaces routed through SERDES 1 and 3 go directly to the external
USB connectors.
>
> Still missing is support for the switch. Wireless fails to probe,
> didn't
> debug this up to now. SFP is untested as is UART1.
Actually SFP is connected to SGMII interface of eth1, which is routed
through SERDES 5. The SGMII line is shared between the SFP and metallic
PHY 88E1514. There is a autonomous high-speed switch connected to the
SFPDET signal from SFP cage. It disconnects the metallic SFP and
connects SGMII to SFP once the module is connected.
The SFP is also connected to the I2C mux port 4 and to GPIO expander
for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
clock-frequency = <100000>;
i2cmux at 70 {
compatible = "nxp,pca9547";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
status = "okay";
...
i2c at 7 {
/* SFP+ GPIO expander */
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
sfpgpio: gpio at 71 {
compatible = "nxp,pca9538";
reg = <0x71>;
interrupt-parent = <&gpio1>;
interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
gpio-controller;
#gpio-cells = <2>;
};
};
};
};
We have our proprietary support hacked onto mvneta driver for
disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore
SFP in this DTS altogether and let's wait till "phylink based SFP
module support" or something alike hits upstream, so we can base the
SFP support on solid code; unless somebody has a better idea, of course.
>
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..d3cd8a4d713d
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,246 @@
...
> +
> + /* USB part of the eSATA/USB 2.0 port */
This comment is perhaps some error inherited from my development DTS.
We do not have any eSATA, perhaps PCIe/USB 2.0 slot.
>
> + usb at 58000 {
> + status = "okay";
> + };
> +
> +
> +ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge0_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +ð1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge1_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
switch. The problem is that from what I have read so far the switch can
not operate in DSA mode with two CPU ports. We currently operate the
switch in "normal mode" with the eth0 and eth1 set to fixed-link
1000/full and with proprietary driver (derived from OpenWRT switch
drivers). I would say that these records for eth0 and eth1 are
therefore redundant, because it does nothing without the switch support
and it would most likely change once we have DSA driver (using only
eth0).
Tomas
^ permalink raw reply
* [PATCH v2 10/10] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Andy Yan @ 2016-11-14 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan@rock-chips.com>
RK1108 EVB is designed by Rockchip for CVR field.
This patch add basic support for it, which can boot with
initramfs into shell.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
- move the board in the rockchip.txt to the block of Rockchip boards
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 10b92b5..e658b62 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,6 +1,5 @@
Rockchip platforms device tree bindings
---------------------------------------
-
- Kylin RK3036 board:
Required root node properties:
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
@@ -111,6 +110,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
+- Rockchip RK1108 Evaluation board
+ Required root node properties:
+ - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e49476a..249dca9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pba8.dtb \
arm-realview-pbx-a9.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk1108-evb.dtb \
rk3036-evb.dtb \
rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
diff --git a/arch/arm/boot/dts/rk1108-evb.dts b/arch/arm/boot/dts/rk1108-evb.dts
new file mode 100644
index 0000000..3956cff
--- /dev/null
+++ b/arch/arm/boot/dts/rk1108-evb.dts
@@ -0,0 +1,69 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk1108.dtsi"
+
+/ {
+ model = "Rockchip RK1108 Evaluation board";
+ compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
+ memory at 60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x08000000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Robin Murphy @ 2016-11-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
With no coherency to worry about, just plug'em straight in.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d98de6..5cd0a383b14b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -796,6 +796,8 @@ static struct dma_map_ops iommu_dma_ops = {
.sync_single_for_device = __iommu_sync_single_for_device,
.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
.sync_sg_for_device = __iommu_sync_sg_for_device,
+ .map_resource = iommu_dma_map_resource,
+ .unmap_resource = iommu_dma_unmap_resource,
.dma_supported = iommu_dma_supported,
.mapping_error = iommu_dma_mapping_error,
};
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-11-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need for arch code wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v4: Add the missed static qualifier (thanks Catalin)
drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
include/linux/dma-iommu.h | 4 ++++
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..2db0d641cf45 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
return ret;
}
-dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size, int prot)
+static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
+ size_t size, int prot)
{
dma_addr_t dma_addr;
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
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);
struct iova *iova = __alloc_iova(domain, len, dma_get_mask(dev));
@@ -454,6 +453,12 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
return dma_addr + iova_off;
}
+dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size, int prot)
+{
+ return __iommu_dma_map(dev, page_to_phys(page) + offset, size, prot);
+}
+
void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
@@ -624,6 +629,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return __iommu_dma_map(dev, phys, size,
+ dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 07/10] ARM: add low level debug uart for rk1108
From: Andy Yan @ 2016-11-14 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan@rock-chips.com>
RK1108 UARTs are Synopsis DesignWare 8250 compatible.
Only with different register addresses.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Tested-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
Changes in v2: None
arch/arm/Kconfig.debug | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..408540f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -776,6 +776,30 @@ choice
their output to the standard serial port on the RealView
PB1176 platform.
+ config DEBUG_RK1108_UART0
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART0"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
+ config DEBUG_RK1108_UART1
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART1"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
+ config DEBUG_RK1108_UART2
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART2"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
config DEBUG_RK29_UART0
bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
depends on ARCH_ROCKCHIP
@@ -1465,6 +1489,9 @@ config DEBUG_UART_PHYS
default 0x10126000 if DEBUG_RK3X_UART1
default 0x101f1000 if DEBUG_VERSATILE
default 0x101fb000 if DEBUG_NOMADIK_UART
+ default 0x10210000 if DEBUG_RK1108_UART2
+ default 0x10220000 if DEBUG_RK1108_UART1
+ default 0x10230000 if DEBUG_RK1108_UART0
default 0x11002000 if DEBUG_MT8127_UART0
default 0x11006000 if DEBUG_MT6589_UART0
default 0x11009000 if DEBUG_MT8135_UART3
@@ -1563,6 +1590,9 @@ config DEBUG_UART_PHYS
config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
+ default 0xc881f000 if DEBUG_RK1108_UART2
+ default 0xc8821000 if DEBUG_RK1108_UART1
+ default 0xc8912000 if DEBUG_RK1108_UART0
default 0xe0000a00 if DEBUG_NETX_UART
default 0xe0010fe0 if ARCH_RPC
default 0xf0000be0 if ARCH_EBSA110
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] iio: adc: Add support for STM32 ADC
From: Lars-Peter Clausen @ 2016-11-14 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478794738-28933-4-git-send-email-fabrice.gasnier@st.com>
On 11/10/2016 05:18 PM, Fabrice Gasnier wrote:
[...]
> + static int stm32_adc_single_conv(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *res)
> +{
> + struct stm32_adc *adc = iio_priv(indio_dev);
> + long timeout;
> + u32 val;
> + u16 result;
> + int ret;
> +
> + reinit_completion(&adc->completion);
> +
> + adc->buffer = &result;
> +
> + /* Program chan number in regular sequence */
> + val = stm32_adc_readl(adc, STM32F4_ADCX_SQR3);
> + val &= ~STM32F4_SQ1_MASK;
> + val |= chan->channel << STM32F4_SQ1_SHIFT;
> + stm32_adc_writel(adc, STM32F4_ADCX_SQR3, val);
> +
> + /* Set regular sequence len (0 for 1 conversion) */
> + stm32_adc_clr_bits(adc, STM32F4_ADCX_SQR1, STM32F4_L_MASK);
> +
> + /* Trigger detection disabled (conversion can be launched in SW) */
> + stm32_adc_clr_bits(adc, STM32F4_ADCX_CR2, STM32F4_EXTEN_MASK);
> +
> + stm32_adc_conv_irq_enable(adc);
> +
> + stm32_adc_start_conv(adc);
> +
> + timeout = wait_for_completion_interruptible_timeout(
> + &adc->completion, STM32_ADC_TIMEOUT);
> + if (timeout == 0) {
> + dev_warn(&indio_dev->dev, "Conversion timed out!\n");
This should be dev_dbg() at most. This out of band reporting is not
particular useful for applications as it is impossible to match the error to
the action that triggered it. And you also report the error through the
error code, so the applications knows what is going on.
> + ret = -ETIMEDOUT;
> + } else if (timeout < 0) {
> + dev_warn(&indio_dev->dev, "Interrupted conversion!\n");
> + ret = -EINTR;
This should just propagate the error returned by wait_for_completion...().
This will make sure that the right behavior occurs based on the SA_RESTART
policy.
> + } else {
> + *res = result;
> + ret = IIO_VAL_INT;
> + }
> +
> + stm32_adc_stop_conv(adc);
> +
> + stm32_adc_conv_irq_disable(adc);
> +
> + return ret;
^ permalink raw reply
* [PATCH v2 04/10] clk: rockchip: add clock controller for rk1108
From: Andy Yan @ 2016-11-14 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan@rock-chips.com>
From: Shawn Lin <shawn.lin@rock-chips.com>
Add the clock tree definition and driver for rk1108 SoC.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jacob Chen <jacob2.chen@rock-chips.com>
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
---
Changes in v2:
- fix some CodingStyle issues
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-rk1108.c | 451 ++++++++++++++++++++++++++++++++++++++
drivers/clk/rockchip/clk.h | 14 ++
3 files changed, 466 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-rk1108.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b5f2c8e..16e098c 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-mmc-phase.o
obj-y += clk-ddr.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-rk1108.o
obj-y += clk-rk3036.o
obj-y += clk-rk3188.o
obj-y += clk-rk3228.o
diff --git a/drivers/clk/rockchip/clk-rk1108.c b/drivers/clk/rockchip/clk-rk1108.c
new file mode 100644
index 0000000..e3a4f74
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk1108.c
@@ -0,0 +1,451 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Shawn Lin <shawn.lin@rock-chips.com>
+ * Andy Yan <andy.yan@rock-chips.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/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
+#include <dt-bindings/clock/rk1108-cru.h>
+#include "clk.h"
+
+#define RK1108_GRF_SOC_STATUS0 0x480
+
+enum rk1108_plls {
+ apll, dpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk1108_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(1608000000, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1584000000, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1560000000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1536000000, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1512000000, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1488000000, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1464000000, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1440000000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1416000000, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1392000000, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1368000000, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1344000000, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1320000000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1296000000, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1272000000, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1248000000, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1200000000, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1188000000, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1104000000, 1, 46, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1100000000, 12, 550, 1, 1, 1, 0),
+ RK3036_PLL_RATE(1008000000, 1, 84, 2, 1, 1, 0),
+ RK3036_PLL_RATE(1000000000, 6, 500, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 984000000, 1, 82, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 960000000, 1, 80, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 936000000, 1, 78, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 912000000, 1, 76, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 900000000, 4, 300, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 888000000, 1, 74, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 864000000, 1, 72, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 840000000, 1, 70, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 816000000, 1, 68, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 800000000, 6, 400, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 700000000, 6, 350, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 696000000, 1, 58, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 600000000, 1, 75, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 594000000, 2, 99, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 504000000, 1, 63, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 500000000, 6, 250, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 408000000, 1, 68, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 312000000, 1, 52, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 216000000, 1, 72, 4, 2, 1, 0),
+ RK3036_PLL_RATE( 96000000, 1, 64, 4, 4, 1, 0),
+ { /* sentinel */ },
+};
+
+#define RK1108_DIV_CORE_MASK 0xf
+#define RK1108_DIV_CORE_SHIFT 4
+
+#define RK1108_CLKSEL0(_core_peri_div) \
+ { \
+ .reg = RK1108_CLKSEL_CON(1), \
+ .val = HIWORD_UPDATE(_core_peri_div, RK1108_DIV_CORE_MASK, \
+ RK1108_DIV_CORE_SHIFT) \
+ }
+
+#define RK1108_CPUCLK_RATE(_prate, _core_peri_div) \
+ { \
+ .prate = _prate, \
+ .divs = { \
+ RK1108_CLKSEL0(_core_peri_div), \
+ }, \
+ }
+
+static struct rockchip_cpuclk_rate_table rk1108_cpuclk_rates[] __initdata = {
+ RK1108_CPUCLK_RATE(816000000, 4),
+ RK1108_CPUCLK_RATE(600000000, 4),
+ RK1108_CPUCLK_RATE(312000000, 4),
+};
+
+static const struct rockchip_cpuclk_reg_data rk1108_cpuclk_data = {
+ .core_reg = RK1108_CLKSEL_CON(0),
+ .div_core_shift = 0,
+ .div_core_mask = 0x1f,
+ .mux_core_alt = 1,
+ .mux_core_main = 0,
+ .mux_core_shift = 8,
+ .mux_core_mask = 0x1,
+};
+
+PNAME(mux_pll_p) = { "xin24m", "xin24m"};
+PNAME(mux_ddrphy_p) = { "dpll_ddr", "gpll_ddr", "apll_ddr" };
+PNAME(mux_armclk_p) = { "apll_core", "gpll_core", "dpll_core" };
+PNAME(mux_pmu_1f) = { "xin24m", "pmu_24m"};
+PNAME(mux_usb480m_phy_p) = { "usb480m_phy0", "usb480m_phy1" };
+PNAME(mux_usb480m_p) = { "usb480m_phy", "xin24m" };
+PNAME(mux_hdmiphy_p) = { "hdmiphy_phy", "pclk_top_pre", "xin24m" };
+PNAME(mux_pll_src_4plls_p) = { "dpll", "hdmiphy", "gpll", "usb480m" };
+PNAME(mux_pll_src_3plls_p) = { "apll", "gpll", "dpll" };
+PNAME(mux_pll_src_2plls_p) = { "dpll", "gpll" };
+PNAME(mux_aclk_peri_src_p) = { "aclk_peri_src_dpll", "aclk_peri_src_gpll" };
+PNAME(mux_aclk_bus_src_p) = { "aclk_bus_src_gpll", "aclk_bus_src_apll", "aclk_bus_src_dpll" };
+PNAME(mux_mmc_src_p) = { "dpll", "gpll", "xin24m", "usb480m" };
+PNAME(mux_pll_src_dpll_gpll_usb480m_p) = { "dpll", "gpll", "usb480m" };
+PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
+PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
+PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
+
+static struct rockchip_pll_clock rk1108_pll_clks[] __initdata = {
+ [apll] = PLL(pll_rk3399, RK1108_APLL_ID, "apll", mux_pll_p, 0, RK1108_PLL_CON(0),
+ RK1108_PLL_CON(3), 8, 31, 0, rk1108_pll_rates),
+ [dpll] = PLL(pll_rk3399, RK1108_DPLL_ID, "dpll", mux_pll_p, 0, RK1108_PLL_CON(8),
+ RK1108_PLL_CON(11), 8, 31, 0, NULL),
+ [gpll] = PLL(pll_rk3399, RK1108_GPLL_ID, "gpll", mux_pll_p, 0, RK1108_PLL_CON(16),
+ RK1108_PLL_CON(19), 8, 31, ROCKCHIP_PLL_SYNC_RATE, rk1108_pll_rates),
+};
+
+#define MFLAGS CLK_MUX_HIWORD_MASK
+#define DFLAGS CLK_DIVIDER_HIWORD_MASK
+#define GFLAGS (CLK_GATE_HIWORD_MASK | CLK_GATE_SET_TO_DISABLE)
+
+static struct rockchip_clk_branch rk1108_uart0_fracmux __initdata =
+ MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(13), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk1108_uart1_fracmux __initdata =
+ MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(14), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk1108_uart2_fracmux __initdata =
+ MUX(SCLK_UART2, "sclk_uart2", mux_uart2_p, CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(15), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk1108_clk_branches[] __initdata = {
+ /*
+ * Clock-Architecture Diagram 2
+ */
+
+ /* PD_CORE */
+ GATE(0, "dpll_core", "dpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 1, GFLAGS),
+ GATE(0, "apll_core", "apll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 0, GFLAGS),
+ GATE(0, "gpll_core", "gpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 2, GFLAGS),
+ COMPOSITE_NOMUX(0, "pclken_dbg", "armclk", CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(1), 4, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
+ RK1108_CLKGATE_CON(0), 5, GFLAGS),
+ COMPOSITE_NOMUX(ACLK_ENMCORE, "aclkenm_core", "armclk", CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(1), 0, 3, DFLAGS | CLK_DIVIDER_READ_ONLY,
+ RK1108_CLKGATE_CON(0), 4, GFLAGS),
+ GATE(ACLK_CORE, "aclk_core", "aclkenm_core", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(11), 0, GFLAGS),
+ GATE(0, "pclk_dbg", "pclken_dbg", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(11), 1, GFLAGS),
+
+ /* PD_RKVENC */
+
+ /* PD_RKVDEC */
+
+ /* PD_PMU_wrapper */
+ COMPOSITE_NOMUX(0, "pmu_24m_ena", "gpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(38), 0, 5, DFLAGS,
+ RK1108_CLKGATE_CON(8), 12, GFLAGS),
+ GATE(0, "pmu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 0, GFLAGS),
+ GATE(0, "intmem1", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 1, GFLAGS),
+ GATE(0, "gpio0_pmu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 2, GFLAGS),
+ GATE(0, "pmugrf", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 3, GFLAGS),
+ GATE(0, "pmu_noc", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 4, GFLAGS),
+ GATE(0, "i2c0_pmu_pclk", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 5, GFLAGS),
+ GATE(0, "pwm0_pmu_pclk", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(10), 6, GFLAGS),
+ COMPOSITE(0, "pwm0_pmu_clk", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(12), 7, 1, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(8), 15, GFLAGS),
+ COMPOSITE(0, "i2c0_pmu_clk", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(19), 7, 1, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(8), 14, GFLAGS),
+ GATE(0, "pvtm_pmu", "xin24m", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(8), 13, GFLAGS),
+
+ /*
+ * Clock-Architecture Diagram 4
+ */
+ COMPOSITE(0, "aclk_vio0_2wrap_occ", mux_pll_src_4plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(28), 6, 2, MFLAGS, 0, 5, DFLAGS,
+ RK1108_CLKGATE_CON(6), 0, GFLAGS),
+ GATE(0, "aclk_vio0_pre", "aclk_vio0_2wrap_occ", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(17), 0, GFLAGS),
+ COMPOSITE_NOMUX(0, "hclk_vio_pre", "aclk_vio0_pre", 0,
+ RK1108_CLKSEL_CON(29), 0, 5, DFLAGS,
+ RK1108_CLKGATE_CON(7), 2, GFLAGS),
+ COMPOSITE_NOMUX(0, "pclk_vio_pre", "aclk_vio0_pre", 0,
+ RK1108_CLKSEL_CON(29), 8, 5, DFLAGS,
+ RK1108_CLKGATE_CON(7), 3, GFLAGS),
+
+ /*
+ * Clock-Architecture Diagram 5
+ */
+
+ /* PD_BUS */
+ GATE(0, "aclk_bus_src_gpll", "gpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 0, GFLAGS),
+ GATE(0, "aclk_bus_src_apll", "apll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 1, GFLAGS),
+ GATE(0, "aclk_bus_src_dpll", "dpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 2, GFLAGS),
+ COMPOSITE_NOGATE(ACLK_PRE, "aclk_bus_pre", mux_aclk_bus_src_p, 0,
+ RK1108_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 5, DFLAGS),
+ COMPOSITE_NOMUX(0, "hclk_bus_pre", "aclk_bus_2wrap_occ", 0,
+ RK1108_CLKSEL_CON(3), 0, 5, DFLAGS,
+ RK1108_CLKGATE_CON(1), 4, GFLAGS),
+ COMPOSITE_NOMUX(0, "pclken_bus", "aclk_bus_2wrap_occ", 0,
+ RK1108_CLKSEL_CON(3), 8, 5, DFLAGS,
+ RK1108_CLKGATE_CON(1), 5, GFLAGS),
+ GATE(0, "pclk_bus_pre", "pclken_bus", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 6, GFLAGS),
+ GATE(0, "pclk_top_pre", "pclken_bus", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 7, GFLAGS),
+ GATE(0, "pclk_ddr_pre", "pclken_bus", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 8, GFLAGS),
+ GATE(0, "clk_timer0", "mux_pll_p", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 9, GFLAGS),
+ GATE(0, "clk_timer1", "mux_pll_p", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(1), 10, GFLAGS),
+ GATE(0, "pclk_timer", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 4, GFLAGS),
+
+ COMPOSITE(0, "uart0_src", mux_pll_src_dpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(13), 12, 2, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 1, GFLAGS),
+ COMPOSITE(0, "uart1_src", mux_pll_src_dpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(14), 12, 2, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 3, GFLAGS),
+ COMPOSITE(0, "uart21_src", mux_pll_src_dpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(15), 12, 2, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 5, GFLAGS),
+
+ COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(16), 0,
+ RK1108_CLKGATE_CON(3), 2, GFLAGS,
+ &rk1108_uart0_fracmux),
+ COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(17), 0,
+ RK1108_CLKGATE_CON(3), 4, GFLAGS,
+ &rk1108_uart1_fracmux),
+ COMPOSITE_FRACMUX(0, "uart2_frac", "uart2_src", CLK_SET_RATE_PARENT,
+ RK1108_CLKSEL_CON(18), 0,
+ RK1108_CLKGATE_CON(3), 6, GFLAGS,
+ &rk1108_uart2_fracmux),
+ GATE(PCLK_UART0, "pclk_uart0", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 10, GFLAGS),
+ GATE(PCLK_UART1, "pclk_uart1", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 11, GFLAGS),
+ GATE(PCLK_UART2, "pclk_uart2", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 12, GFLAGS),
+
+ COMPOSITE(0, "clk_i2c1", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(19), 15, 2, MFLAGS, 8, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 7, GFLAGS),
+ COMPOSITE(0, "clk_i2c2", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(20), 7, 2, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 8, GFLAGS),
+ COMPOSITE(0, "clk_i2c3", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(20), 15, 2, MFLAGS, 8, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 9, GFLAGS),
+ GATE(0, "pclk_i2c1", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 0, GFLAGS),
+ GATE(0, "pclk_i2c2", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 1, GFLAGS),
+ GATE(0, "pclk_i2c3", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 2, GFLAGS),
+ COMPOSITE(0, "clk_pwm1", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(12), 15, 2, MFLAGS, 8, 7, DFLAGS,
+ RK1108_CLKGATE_CON(3), 10, GFLAGS),
+ GATE(0, "pclk_pwm1", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 6, GFLAGS),
+ GATE(0, "pclk_wdt", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 3, GFLAGS),
+ GATE(0, "pclk_gpio1", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 7, GFLAGS),
+ GATE(0, "pclk_gpio2", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 8, GFLAGS),
+ GATE(0, "pclk_gpio3", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(13), 9, GFLAGS),
+
+ GATE(0, "pclk_grf", "pclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(14), 0, GFLAGS),
+
+ GATE(ACLK_DMAC, "aclk_dmac", "aclk_bus_pre", 0,
+ RK1108_CLKGATE_CON(12), 2, GFLAGS),
+ GATE(0, "hclk_rom", "hclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(12), 3, GFLAGS),
+ GATE(0, "aclk_intmem", "aclk_bus_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(12), 1, GFLAGS),
+
+ /* PD_DDR */
+ GATE(0, "apll_ddr", "apll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 8, GFLAGS),
+ GATE(0, "dpll_ddr", "dpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 9, GFLAGS),
+ GATE(0, "gpll_ddr", "gpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 10, GFLAGS),
+ COMPOSITE(0, "ddrphy4x", mux_ddrphy_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(4), 8, 2, MFLAGS, 0, 3,
+ DFLAGS | CLK_DIVIDER_POWER_OF_TWO,
+ RK1108_CLKGATE_CON(10), 9, GFLAGS),
+ GATE(0, "ddrupctl", "ddrphy_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(12), 4, GFLAGS),
+ GATE(0, "ddrc", "ddrphy", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(12), 5, GFLAGS),
+ GATE(0, "ddrmon", "ddrphy_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(12), 6, GFLAGS),
+ GATE(0, "timer_clk", "xin24m", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(0), 11, GFLAGS),
+
+ /*
+ * Clock-Architecture Diagram 6
+ */
+
+ /* PD_PERI */
+ COMPOSITE_NOMUX(0, "pclk_periph_pre", "gpll", 0,
+ RK1108_CLKSEL_CON(23), 10, 5, DFLAGS,
+ RK1108_CLKGATE_CON(4), 5, GFLAGS),
+ GATE(0, "pclk_periph", "pclk_periph_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(15), 13, GFLAGS),
+ COMPOSITE_NOMUX(0, "hclk_periph_pre", "gpll", 0,
+ RK1108_CLKSEL_CON(23), 5, 5, DFLAGS,
+ RK1108_CLKGATE_CON(4), 4, GFLAGS),
+ GATE(0, "hclk_periph", "hclk_periph_pre", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(15), 12, GFLAGS),
+
+ GATE(0, "aclk_peri_src_dpll", "dpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(4), 1, GFLAGS),
+ GATE(0, "aclk_peri_src_gpll", "gpll", CLK_IGNORE_UNUSED,
+ RK1108_CLKGATE_CON(4), 2, GFLAGS),
+ COMPOSITE(0, "aclk_periph", mux_aclk_peri_src_p, CLK_IGNORE_UNUSED,
+ RK1108_CLKSEL_CON(23), 15, 2, MFLAGS, 0, 5, DFLAGS,
+ RK1108_CLKGATE_CON(15), 11, GFLAGS),
+
+ COMPOSITE(SCLK_SDMMC, "sclk_sdmmc0", mux_mmc_src_p, 0,
+ RK1108_CLKSEL_CON(25), 8, 2, MFLAGS, 0, 8, DFLAGS,
+ RK1108_CLKGATE_CON(5), 0, GFLAGS),
+
+ COMPOSITE_NODIV(0, "sclk_sdio_src", mux_mmc_src_p, 0,
+ RK1108_CLKSEL_CON(25), 10, 2, MFLAGS,
+ RK1108_CLKGATE_CON(5), 2, GFLAGS),
+ DIV(SCLK_SDIO, "sclk_sdio", "sclk_sdio_src", 0,
+ RK1108_CLKSEL_CON(26), 0, 8, DFLAGS),
+
+ COMPOSITE_NODIV(0, "sclk_emmc_src", mux_mmc_src_p, 0,
+ RK1108_CLKSEL_CON(25), 12, 2, MFLAGS,
+ RK1108_CLKGATE_CON(5), 1, GFLAGS),
+ DIV(SCLK_EMMC, "sclk_emmc", "sclk_emmc_src", 0,
+ RK2928_CLKSEL_CON(26), 8, 8, DFLAGS),
+ GATE(HCLK_SDMMC, "hclk_sdmmc", "hclk_periph", 0, RK1108_CLKGATE_CON(15), 0, GFLAGS),
+ GATE(HCLK_SDIO, "hclk_sdio", "hclk_periph", 0, RK1108_CLKGATE_CON(15), 1, GFLAGS),
+ GATE(HCLK_EMMC, "hclk_emmc", "hclk_periph", 0, RK1108_CLKGATE_CON(15), 2, GFLAGS),
+
+ COMPOSITE(SCLK_NANDC, "sclk_nandc", mux_pll_src_2plls_p, 0,
+ RK1108_CLKSEL_CON(27), 14, 2, MFLAGS, 8, 5, DFLAGS,
+ RK1108_CLKGATE_CON(5), 3, GFLAGS),
+ GATE(HCLK_NANDC, "hclk_nandc", "hclk_periph", 0, RK1108_CLKGATE_CON(15), 3, GFLAGS),
+
+ COMPOSITE(SCLK_SFC, "sclk_sfc", mux_pll_src_2plls_p, 0,
+ RK1108_CLKSEL_CON(27), 7, 2, MFLAGS, 0, 7, DFLAGS,
+ RK1108_CLKGATE_CON(5), 4, GFLAGS),
+ GATE(HCLK_SFC, "hclk_sfc", "hclk_periph", 0, RK1108_CLKGATE_CON(15), 10, GFLAGS),
+ MMC(SCLK_SDMMC_DRV, "sdmmc_drv", "sclk_sdmmc", RK1108_SDMMC_CON0, 1),
+ MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc", RK1108_SDMMC_CON1, 1),
+
+ MMC(SCLK_SDIO_DRV, "sdio_drv", "sclk_sdio", RK1108_SDIO_CON0, 1),
+ MMC(SCLK_SDIO_SAMPLE, "sdio_sample", "sclk_sdio", RK1108_SDIO_CON1, 1),
+
+ MMC(SCLK_EMMC_DRV, "emmc_drv", "sclk_emmc", RK1108_EMMC_CON0, 1),
+ MMC(SCLK_EMMC_SAMPLE, "emmc_sample", "sclk_emmc", RK1108_EMMC_CON1, 1),
+};
+
+static const char *const rk1108_critical_clocks[] __initconst = {
+ "aclk_core",
+ "aclk_bus_src_gpll",
+ "aclk_periph",
+ "hclk_periph",
+ "pclk_periph",
+};
+
+static void __init rk1108_clk_init(struct device_node *np)
+{
+ struct rockchip_clk_provider *ctx;
+ void __iomem *reg_base;
+
+ reg_base = of_iomap(np, 0);
+ if (!reg_base) {
+ pr_err("%s: could not map cru region\n", __func__);
+ return;
+ }
+
+ ctx = rockchip_clk_init(np, reg_base, CLK_NR_CLKS);
+ if (IS_ERR(ctx)) {
+ pr_err("%s: rockchip clk init failed\n", __func__);
+ iounmap(reg_base);
+ return;
+ }
+
+ rockchip_clk_register_plls(ctx, rk1108_pll_clks,
+ ARRAY_SIZE(rk1108_pll_clks),
+ RK1108_GRF_SOC_STATUS0);
+ rockchip_clk_register_branches(ctx, rk1108_clk_branches,
+ ARRAY_SIZE(rk1108_clk_branches));
+ rockchip_clk_protect_critical(rk1108_critical_clocks,
+ ARRAY_SIZE(rk1108_critical_clocks));
+
+ rockchip_clk_register_armclk(ctx, RK1108_ARMCLK, "armclk",
+ mux_armclk_p, ARRAY_SIZE(mux_armclk_p),
+ &rk1108_cpuclk_data, rk1108_cpuclk_rates,
+ ARRAY_SIZE(rk1108_cpuclk_rates));
+
+ rockchip_register_softrst(np, 13, reg_base + RK1108_SOFTRST_CON(0),
+ ROCKCHIP_SOFTRST_HIWORD_MASK);
+
+ rockchip_register_restart_notifier(ctx, RK1108_GLB_SRST_FST, NULL);
+
+ rockchip_clk_of_add_provider(np, ctx);
+}
+CLK_OF_DECLARE(rk1108_cru, "rockchip,rk1108-cru", rk1108_clk_init);
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 1653edd..90c580a 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -34,6 +34,20 @@ struct clk;
#define HIWORD_UPDATE(val, mask, shift) \
((val) << (shift) | (mask) << ((shift) + 16))
+/* register positions shared by RK1108, RK2928, RK3036, RK3066, RK3188 and RK3228 */
+#define RK1108_PLL_CON(x) ((x) * 0x4)
+#define RK1108_CLKSEL_CON(x) ((x) * 0x4 + 0x60)
+#define RK1108_CLKGATE_CON(x) ((x) * 0x4 + 0x120)
+#define RK1108_SOFTRST_CON(x) ((x) * 0x4 + 0x180)
+#define RK1108_GLB_SRST_FST 0x1c0
+#define RK1108_GLB_SRST_SND 0x1c4
+#define RK1108_SDMMC_CON0 0x1d8
+#define RK1108_SDMMC_CON1 0x1dc
+#define RK1108_SDIO_CON0 0x1e0
+#define RK1108_SDIO_CON1 0x1e4
+#define RK1108_EMMC_CON0 0x1e8
+#define RK1108_EMMC_CON1 0x1ec
+
#define RK2928_PLL_CON(x) ((x) * 0x4)
#define RK2928_MODE_CON 0x40
#define RK2928_CLKSEL_CON(x) ((x) * 0x4 + 0x44)
--
2.7.4
^ permalink raw reply related
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: pankaj.dubey @ 2016-11-14 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3587281.4kOCcW9Ryd@wuerfel>
On Monday 14 November 2016 05:26 PM, Arnd Bergmann wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>> static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> - { .compatible = "arm,cortex-a9-scu", },
>> - { .compatible = "arm,cortex-a5-scu", },
>> { }
>> };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> - unsigned int ncores;
>> int i;
>>
>> - np = of_find_matching_node(NULL, realview_scu_match);
>> - if (!np) {
>> - pr_err("PLATSMP: No SCU base address\n");
>> - return;
>> + if (of_scu_enable()) {
>> + np = of_find_matching_node(NULL, realview_scu_match);
>> + scu_base = of_iomap(np, 0);
>> + of_node_put(np);
>> + if (!scu_base) {
>> + pr_err("PLATSMP: No SCU remap\n");
>> + return;
>> + }
>> + scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>
Do you mean "arm,arm11mp-scu" this is generic SCU specific to ARM?
If it's generic then it can be moved on the same line I moved a5-scu and
a9-scu.
I left it here in same file, as I understood it might be related with
very specific to realview platform.
Thanks,
Pankaj Dubey
> Arnd
>
>
>
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Arnd Bergmann @ 2016-11-14 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71596b86-7653-5c02-fc46-59409a91243f@samsung.com>
On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> >> + scu_base = of_iomap(np, 0);
> >> + of_node_put(np);
> >> + if (!scu_base) {
> >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> >
> > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > what does it mean, but it may confuse normal users. In current version,
> > berlin doesn't complain like this for non-ca9 SoCs
> >
>
> OK, let me see other reviewer's comment on this. Then we will decide if
> this error message is required or can be omitted.
We need to look at all callers here, to see if the function ever gets
called for a CPU that doesn't have an SCU. I'd say we should warn if
we know there is an SCU but we cannot map it, but never warn on
any of the CPU cores that don't support an SCU.
Arnd
^ permalink raw reply
* [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Matthias Brugger @ 2016-11-14 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479120886-13425-1-git-send-email-sunil.kovvuri@gmail.com>
On 14/11/16 11:54, sunil.kovvuri at gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> This patchset includes fixes for incorrect LMAC credits,
> unreliable driver statistics, memory leak upon interface
> down e.t.c
>
Are these fixes relevant to for older kernels as well?
If so, please add "Cc: stable at vger.kernel.org" to the Sigend-off list.
Thanks,
Matthias
> Radha Mohan Chintakuntla (1):
> net: thunderx: Introduce BGX_ID_MASK macro to extract bgx_id
>
> Sunil Goutham (4):
> net: thunderx: Program LMAC credits based on MTU
> net: thunderx: Fix configuration of L3/L4 length checking
> net: thunderx: Fix VF driver's interface statistics
> net: thunderx: Fix memory leak and other issues upon interface toggle
>
> drivers/net/ethernet/cavium/thunder/nic.h | 64 +++++----
> drivers/net/ethernet/cavium/thunder/nic_main.c | 37 +++--
> drivers/net/ethernet/cavium/thunder/nic_reg.h | 1 +
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c | 105 +++++++-------
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 153 +++++++++++----------
> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 118 +++++++++-------
> drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 24 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 4 +-
> drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 2 +
> 9 files changed, 274 insertions(+), 234 deletions(-)
>
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-14 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114102654.GA1677@red-moon>
On 14/11/16 10:26, Lorenzo Pieralisi wrote:
> Hi Robin, Joerg,
>
> On Fri, Nov 11, 2016 at 05:43:39PM +0000, Robin Murphy wrote:
>> On 11/11/16 16:27, Joerg Roedel wrote:
>>> On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
>>>> In the original of_iommu_configure design, the thought was that an ops
>>>> structure could be IOMMU-instance-specific (hence the later-removed
>>>> "priv" member), so I suppose right now it is mostly a hangover from
>>>> that. However, it's also what we initialise a device's fwspec with, so
>>>> becomes important again if we're ever going to get past the limitations
>>>> of buses-which-are-not-actually-buses[1].
>>>
>>> Yeah, I discussed this with a few others at LPC. My current idea is to
>>> tell the iommu-core which hardware-iommus exist in the system and a
>>> seperate iommu_ops ptr for each of them. Then every struct device can
>>> link to the iommu-instance it is translated by.
>>
>> Er, that sounds very much like a description of what we already have in
>> 4.9-rc. Every struct device now has an iommu_fwspec which encapsulates
>> both an iommu_ops pointer (which can perfectly well be per-instance if
>> the IOMMU driver wants) and a place for the IOMMU-private data to
>> replace the mess of archdata.iommu and driver-internal globals.
>>
>>> We are not there yet, but this will give you the same per-device
>>> iommu-ops as implemented here.
>>
>> With those two patches I linked to, which make the bulk of the IOMMU
>> core code per-device-ops-aware off the bat, I'd say we *are* already
>> pretty much there. It's only iommu_domain_alloc() which needs a
>> device-based alternative, and the non-of_xlate-based IOMMU drivers to
>> either call iommu_fwspec_init() for themselves, or perhaps for x86
>> plumbing in DMAR/IVRS equivalents of the IORT parsing to the
>> infrastructure provided by this series.
>
> I think it all boils down to how we end up implementing the per-device
> iommu_ops look-up/binding, question is what do you want me to do with
> this patch, it should be fine to drop it and use dev->bus->iommu_ops
> for the look-up but I should know sooner rather than later to make
> sure the series get another good round of testing.
If we've already made the decision to move away from bus ops, I don't
see that it makes sense to deliberately introduce new dependencies on
them. Besides, as it stands, this patch literally implements "tell the
iommu-core which hardware-iommus exist in the system and a seperate
iommu_ops ptr for each of them" straight off.
Robin.
>
> Please let me know, thank you very much.
>
> Lorenzo
>
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-14 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114101101.GK1575@localhost.localdomain>
On 11/14/2016 11:11 AM, Charles Keepax wrote:
>> The whole series can be pulled from git repository:
>> > git://linuxtv.org/snawrocki/samsung.git
>> > branch: for-v4.10/dma/pl080-s3c64xx-v2
>
> Tested this series again still looks good to me. The code on that
> branch does differ from the code on the list by the following
> diff however:
>
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -2317,7 +2317,7 @@ static int pl08x_probe(struct amba_device
> *adev, const struct amba_id *id)
> } else {
> pl08x->slave.filter.map = pl08x->pd->slave_map;
> pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
> - pl08x->slave.filter.fn = pl08x_filter_id;
> + pl08x->slave.filter.fn = pl08x_filter_fn;
> }
>
> I tested the code from the list, rather than the branch.
Oops, I forgot to push the final branch again, it's corrected
now. Thanks for your time, hopefully there is no need to bother
you with this series any more.
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Arnd Bergmann @ 2016-11-14 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-5-git-send-email-pankaj.dubey@samsung.com>
On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
> static const struct of_device_id realview_scu_match[] = {
> { .compatible = "arm,arm11mp-scu", },
> - { .compatible = "arm,cortex-a9-scu", },
> - { .compatible = "arm,cortex-a5-scu", },
> { }
> };
>
> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned int max_cpus)
> struct device_node *np;
> void __iomem *scu_base;
> struct regmap *map;
> - unsigned int ncores;
> int i;
>
> - np = of_find_matching_node(NULL, realview_scu_match);
> - if (!np) {
> - pr_err("PLATSMP: No SCU base address\n");
> - return;
> + if (of_scu_enable()) {
> + np = of_find_matching_node(NULL, realview_scu_match);
> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("PLATSMP: No SCU remap\n");
> + return;
> + }
> + scu_enable(scu_base);
> }
>
The only difference here seems to be that realview also needs to handle
"arm,arm11mp-scu". Why not move that into the generic implementation?
Arnd
^ permalink raw reply
* [PATCH v2 00/10] Add basic support for Rockchip RK1108 SOC
From: Andy Yan @ 2016-11-14 11:55 UTC (permalink / raw)
To: linux-arm-kernel
RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
It is designed for varies application scenario such as car DVR, sports
DV, secure camera and UAV camera.
This patch series add basic support for it, which can boot a board with
initramfs into shell.
More new feathers will come soon.
Changes in v2:
- split dt-binding header from clk driver
- fix some CodingStyle issues
- add dt-binding documentation for pinctrl
- add pull and drive-strength functionality for pinctrl
- fix timer and gic dt description
- ordering devices by register address
- move the board in the rockchip.txt to the block of Rockchip boards
Andy Yan (6):
dt-bindings: add documentation for rk1108 pinctrl
pinctrl: rockchip: add support for rk1108
ARM: add low level debug uart for rk1108
ARM: dts: add basic support for Rockchip RK1108 SOC
ARM: rockchip: enable support for RK1108 SoC
ARM: dts: rockchip: add rockchip RK1108 Evaluation board
Shawn Lin (4):
dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
dt-bindings: add documentation for rk1108 cru
clk: rockchip: add dt-binding header for rk1108
clk: rockchip: add clock controller for rk1108
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
.../bindings/clock/rockchip,rk1108-cru.txt | 60 +++
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
.../bindings/pinctrl/rockchip,pinctrl.txt | 9 +-
arch/arm/Kconfig.debug | 30 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++
arch/arm/boot/dts/rk1108.dtsi | 428 +++++++++++++++++++
arch/arm/mach-rockchip/rockchip.c | 1 +
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-rk1108.c | 451 +++++++++++++++++++++
drivers/clk/rockchip/clk.h | 14 +
drivers/pinctrl/pinctrl-rockchip.c | 87 +++-
include/dt-bindings/clock/rk1108-cru.h | 270 ++++++++++++
14 files changed, 1421 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
create mode 100644 arch/arm/boot/dts/rk1108.dtsi
create mode 100644 drivers/clk/rockchip/clk-rk1108.c
create mode 100644 include/dt-bindings/clock/rk1108-cru.h
--
2.7.4
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-14 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110184210.GA11835@kozik-lap>
On 11/10/2016 07:42 PM, Krzysztof Kozlowski wrote:
> On Thu, Nov 10, 2016 at 04:17:48PM +0100, Sylwester Nawrocki wrote:
>> > This patch series aims to convert the s3c64xx platform to use
>> > the new DMA channel request API, i.e. this is only meaningful
>> > for non-dt systems using s3c64xx SoCs.
>> >
>> > Presumably the first 2 or 4 patches in this series could be queued
>> > for v4.10-rc1 and the remaining patches could be left for subsequent
>> > release, to avoid non-trivial conflict with patches already applied
>> > in the ASoC tree.
>
> Sounds good to me. Should I put the ARM/s3c64xx commits on separate
> branch in case someone would like to pull a tag with it?
I think it makes sense to put first 4 patches from the series onto
a separate branch, and the remaining ones would need to wait for
next development cycle.
But of course firstly we need some feedback and Ack on the first
(DMA controller driver) patch.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH RFC 1/7] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-14 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3693046.Gh6DJsekH3@wuerfel>
On 11/07/2016 08:55 PM, Arnd Bergmann wrote:
>> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
>> > index d5c75c8..0d1eb2e 100644
>> > --- a/drivers/dma/amba-pl08x.c
>> > +++ b/drivers/dma/amba-pl08x.c
>> > @@ -1793,6 +1793,23 @@ bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
>> > }
[...]
>> > +static bool pl08x_filter_fn(struct dma_chan *chan, void *chan_id)
>> > +{
>> > + struct pl08x_dma_chan *plchan;
[...]
>> > + plchan = to_pl08x_chan(chan);
>> > +
>> > + /* Check that the channel is not taken! */
>> > + if (plchan->cd == chan_id)
>> > + return true;
>
> What I had in mind was a bit different: Instead of comparing the
> channel, I was thinking of modifying the channel itself, something
> like:
>
> plchan->signal = chan_id->signal;
> plchan->periph_buses = chan_id->periph_buses;
>
> after that, remove the plchan->cd data. Unfortunately, the muxing in
> arch/arm/mach-spear/ makes this a bit harder. I'd have to think
> about it some more. It may be easier to do this after moving
> spear and lpc32xx over to use dma_slave_map.
I've posted updated version of this patch, please let me know
if you have any further comments.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH v3 2/2] arm64: Support systems without FP/ASIMD
From: Catalin Marinas @ 2016-11-14 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478613381-5718-3-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
On Tue, Nov 08, 2016 at 01:56:21PM +0000, Suzuki K. Poulose wrote:
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index 87b4465..4174f09 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -34,7 +34,8 @@
> #define ARM64_HAS_32BIT_EL0 13
> #define ARM64_HYP_OFFSET_LOW 14
> #define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
> +#define ARM64_HAS_NO_FPSIMD 16
>
> -#define ARM64_NCAPS 16
> +#define ARM64_NCAPS 17
>
> #endif /* __ASM_CPUCAPS_H */
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 9890d20..ce45770 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -213,6 +213,11 @@ static inline bool system_supports_mixed_endian_el0(void)
> return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
> }
>
> +static inline bool system_supports_fpsimd(void)
> +{
> + return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
> +}
Any particular reason why using negation instead of a ARM64_HAS_FPSIMD?
A potential problem would be the default cpus_have_const_cap()
implementation and the default static key having a slight performance
impact.
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index fc2bd19..f89385d 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -746,6 +746,14 @@ static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
> return idmap_addr > GENMASK(VA_BITS - 2, 0) && !is_kernel_in_hyp_mode();
> }
>
> +static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unused)
> +{
> + u64 pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
> +
> + return cpuid_feature_extract_signed_field(pfr0,
> + ID_AA64PFR0_FP_SHIFT) < 0;
> +}
> +
> static const struct arm64_cpu_capabilities arm64_features[] = {
> {
> .desc = "GIC system register CPU interface",
> @@ -829,6 +837,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .def_scope = SCOPE_SYSTEM,
> .matches = hyp_offset_low,
> },
> + {
> + /* FP/SIMD is not implemented */
> + .capability = ARM64_HAS_NO_FPSIMD,
> + .def_scope = SCOPE_SYSTEM,
> + .min_field_value = 0,
> + .matches = has_no_fpsimd,
> + },
If we go for negation, I don't think we need a min_field_value at all,
the matching is done by the has_no_fpsimd() function.
--
Catalin
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Peter Griffin @ 2016-11-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114051854.GW3000@localhost>
Hi Vinod,
On Mon, 14 Nov 2016, Vinod Koul wrote:
> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > >
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > >
> > > So the remoteproc parts now has to go through my tree.
> >
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
>
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
OK.
>
> >
> > That way there won't be any conflicts and you can both accept further changes
> > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > because they have dependencies on each other.
> >
> > I will send a v11 series in a moment which includes the feedback in this email
> > and also include the additional fixes which Vinod has applied since the driver
> > has been in linux-next.
>
> WHY.. Stuff is already merged twice!
When the feedback is "there is an unrelated change in this patch", the only way
you can fix that is by having a new version of the patch.
>Please send updated on top of already
> merged code!
You have dropped the remoteproc parts which were updated in v11, so
it is no longer merged. Bjorn can now pick the v11 versions if he chooses which
incporporates his feedback.
>This is how kernel developement is done...
regards,
Peter.
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau at arm.com @ 2016-11-14 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ 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