* [PATCH 2/3] ARM: convert to generated system call tables
From: Michael Cree @ 2016-10-26 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4146248.jXuviLlvH5@wuerfel>
On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > >
> > > - a lot of the less common architectures just don't get updated
> > > in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > >
> > > - some architectures that add all syscalls sometimes make a mistake
> > > and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > did add the later __NR_execveat.
> >
> > __NR_bpf was not forgotten on Alpha. It was not wired up because
> > extra architecture support is needed which has not been implemented.
> >
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
Oh. When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.
> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.
We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.
Cheers
Michael.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-10-26 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e0adad1-8ef2-029f-cfcd-4a07c962fda2@opensource.altera.com>
Hi!
On Tue, Oct 25, 2016 at 10:38:10AM -0500, Graham Moore wrote:
> On 10/20/2016 09:12 AM, Dinh Nguyen wrote:
> >
> >
> > On 10/20/2016 02:19 AM, Steffen Trumtrar wrote:
> >
> > > > + cdns,tslch-ns = <4>;
> > > > +
> > > > + partition at qspi-boot {
> > > > + /* 8MB for raw data. */
> > > > + label = "Flash 0 Raw Data";
> > > > + reg = <0x0 0x800000>;
> > > > + };
> > > > +
> > > > + partition at qspi-rootfs {
> > > > + /* 120MB for jffs2 data. */
> > > > + label = "Flash 0 jffs2 Filesystem";
> > > > + reg = <0x800000 0x7800000>;
> > > > + };
> > > > + };
> > > > +};
> > > > +
> > >
> > > What is the current preferred way of handling the partitions?
> > > This doesn't fit my Sockit configuration for example. So I would always
> > > have to patch the devicetree.
> >
> > I'm not 100% sure on this. Graham, do you have any insight?
> > >
>
> Well, strictly speaking, these partitions are only for the socdk, the Altera
> dev kit. Our sample designs and file systems expect this layout.
The thing is, that I don't think these partitions belong in a mainline
dts at all. But I'm not sure what the current policy is.
>
> Therefore, these partitions are not required for any other dev kits, and can
> probably be left out.
>
> Or, Steffen, if you have a standard layout you'd like to see, then put that
> in there.
>
Well in my case, it actually doesn't really matter. All the boards
I use do not have u-boot as bootloader but barebox. And barebox uses
devicetree fixups for adding the partition layout that fits the
particular use case. All other partitions are thrown out.
I don't know if u-boot does something like this.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Stephen Boyd @ 2016-10-26 7:35 UTC (permalink / raw)
To: linux-arm-kernel
Let's use the of_io_request_and_map() API so that the frame
region is protected and shows up in /proc/iomem.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Changes from v1:
* Check for IS_ERR instead
drivers/clocksource/arm_arch_timer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 73c487da6d2a..723cc924d8d1 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -964,8 +964,9 @@ static int __init arch_timer_mem_init(struct device_node *np)
}
ret= -ENXIO;
- base = arch_counter_base = of_iomap(best_frame, 0);
- if (!base) {
+ base = arch_counter_base = of_io_request_and_map(best_frame, 0,
+ "arch_mem_timer");
+ if (IS_ERR(base)) {
pr_err("arch_timer: Can't map frame's registers\n");
goto out;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* arm/boot/dts/at91sam9260.dtsi USB clock divisors and AT91SAM9G20
From: Alexandre Belloni @ 2016-10-26 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAkeqgVrCEAtX+Tujjqe4admkhnn1746kL4_d8Z1NjCwVwUGcA@mail.gmail.com>
On 25/10/2016 at 10:49:01 -0700, Andrey Yurovsky wrote :
> I'm working at an AT91SAM9G20 on which the USB clock divisor was wrong
> and traced the issue down to arm/boot/dts/at91sam9260.dtsi which is
> included like this:
>
> at91sam9g20ek_common.dtsi
> at91sam9g20.dtsi
> at91sam9260.dtsi
>
> This has a node:
>
> usb: usbck {
> compatible = "atmel,at91rm9200-clk-usb";
> #clock-cells = <0>;
> atmel,clk-divisors = <1 2 4 0>;
> clocks = <&pllb>;
> };
>
> However the G20 parts seem to need a different divisor, for me this works:
>
> usb: usbck {
> compatible = "atmel,at91rm9200-clk-usb";
> #clock-cells = <0>;
> atmel,clk-divisors = <4 2 0 0>;
> clocks = <&pllb>;
> };
>
> Should the USB clock node be moved to a separate .dtsi file to account
> for this difference?
I think the easiest way of doing it is to override atmel,clk-divisors in
at91sam9g20.dtsi.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-10-26 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-2-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>
> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
> from Axel Haslam to this patch.
>
> In the review of Axel's patch, Sekhar said:
>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
>
> However, the musb device may not be registered. The usb20_clk can be used to
> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
> inclined to leave this as NULL.
But clock look-up has nothing to do with device being registered AFAICT.
It is used to identify the clock consumer. Passing NULL there means the
clock is not associated with any device. Which is not correct as we are
specifically looking at MUSB module clock.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] dmaengine: mv_xor: Add support for scatter-gather DMA mode
From: Stefan Roese @ 2016-10-26 8:10 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds memory to memory scatter-gather support to the Marvell
mv_or DMA driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v2:
- Change none, but now compiles clean for x86_64 since the following patch
has been applied in the mean-time:
434cec62a6d73b8c8080cd992bc97a564fdd5a5a
bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
drivers/dma/mv_xor.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/mv_xor.h | 1 +
2 files changed, 180 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 23f7528..b0d09d9 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -68,6 +68,36 @@ static void mv_desc_init(struct mv_xor_desc_slot *desc,
hw_desc->byte_count = byte_count;
}
+/* Populate the descriptor */
+static void mv_xor_config_sg_ll_desc(struct mv_xor_desc_slot *desc,
+ dma_addr_t dma_src, dma_addr_t dma_dst,
+ u32 len, struct mv_xor_desc_slot *prev)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ hw_desc->status = XOR_DESC_DMA_OWNED;
+ hw_desc->phy_next_desc = 0;
+ /* Configure for XOR with only one src address -> MEMCPY */
+ hw_desc->desc_command = XOR_DESC_OPERATION_XOR | (0x1 << 0);
+ hw_desc->phy_dest_addr = dma_dst;
+ hw_desc->phy_src_addr[0] = dma_src;
+ hw_desc->byte_count = len;
+
+ if (prev) {
+ struct mv_xor_desc *hw_prev = prev->hw_desc;
+
+ hw_prev->phy_next_desc = desc->async_tx.phys;
+ }
+}
+
+static void mv_xor_desc_config_eod(struct mv_xor_desc_slot *desc)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ /* Enable end-of-descriptor interrupt */
+ hw_desc->desc_command |= XOR_DESC_EOD_INT_EN;
+}
+
static void mv_desc_set_mode(struct mv_xor_desc_slot *desc)
{
struct mv_xor_desc *hw_desc = desc->hw_desc;
@@ -228,8 +258,13 @@ mv_chan_clean_completed_slots(struct mv_xor_chan *mv_chan)
list_for_each_entry_safe(iter, _iter, &mv_chan->completed_slots,
node) {
- if (async_tx_test_ack(&iter->async_tx))
+ if (async_tx_test_ack(&iter->async_tx)) {
list_move_tail(&iter->node, &mv_chan->free_slots);
+ if (!list_empty(&iter->sg_tx_list)) {
+ list_splice_tail_init(&iter->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
}
return 0;
}
@@ -244,11 +279,20 @@ mv_desc_clean_slot(struct mv_xor_desc_slot *desc,
/* the client is allowed to attach dependent operations
* until 'ack' is set
*/
- if (!async_tx_test_ack(&desc->async_tx))
+ if (!async_tx_test_ack(&desc->async_tx)) {
/* move this slot to the completed_slots */
list_move_tail(&desc->node, &mv_chan->completed_slots);
- else
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->completed_slots);
+ }
+ } else {
list_move_tail(&desc->node, &mv_chan->free_slots);
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
return 0;
}
@@ -450,6 +494,7 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
dma_async_tx_descriptor_init(&slot->async_tx, chan);
slot->async_tx.tx_submit = mv_xor_tx_submit;
INIT_LIST_HEAD(&slot->node);
+ INIT_LIST_HEAD(&slot->sg_tx_list);
dma_desc = mv_chan->dma_desc_pool;
slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
slot->idx = idx++;
@@ -617,6 +662,132 @@ mv_xor_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
return mv_xor_prep_dma_xor(chan, dest, &src, 1, len, flags);
}
+/**
+ * mv_xor_prep_dma_sg - prepare descriptors for a memory sg transaction
+ * @chan: DMA channel
+ * @dst_sg: Destination scatter list
+ * @dst_sg_len: Number of entries in destination scatter list
+ * @src_sg: Source scatter list
+ * @src_sg_len: Number of entries in source scatter list
+ * @flags: transfer ack flags
+ *
+ * Return: Async transaction descriptor on success and NULL on failure
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_prep_dma_sg(struct dma_chan *chan, struct scatterlist *dst_sg,
+ unsigned int dst_sg_len, struct scatterlist *src_sg,
+ unsigned int src_sg_len, unsigned long flags)
+{
+ struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
+ struct mv_xor_desc_slot *new;
+ struct mv_xor_desc_slot *first = NULL;
+ struct mv_xor_desc_slot *prev = NULL;
+ size_t len, dst_avail, src_avail;
+ dma_addr_t dma_dst, dma_src;
+ int desc_cnt = 0;
+ int ret;
+
+ dev_dbg(mv_chan_to_devp(mv_chan),
+ "%s dst_sg_len: %d src_sg_len: %d flags: %ld\n",
+ __func__, dst_sg_len, src_sg_len, flags);
+
+ dst_avail = sg_dma_len(dst_sg);
+ src_avail = sg_dma_len(src_sg);
+
+ /* Run until we are out of scatterlist entries */
+ while (true) {
+ /* Allocate and populate the descriptor */
+ desc_cnt++;
+ new = mv_chan_alloc_slot(mv_chan);
+ if (!new) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Out of descriptors (desc_cnt=%d)!\n",
+ desc_cnt);
+ goto err;
+ }
+
+ len = min_t(size_t, src_avail, dst_avail);
+ len = min_t(size_t, len, MV_XOR_MAX_BYTE_COUNT);
+ if (len == 0)
+ goto fetch;
+
+ if (len < MV_XOR_MIN_BYTE_COUNT) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Transfer size of %zu too small!\n", len);
+ goto err;
+ }
+
+ dma_dst = sg_dma_address(dst_sg) + sg_dma_len(dst_sg) -
+ dst_avail;
+ dma_src = sg_dma_address(src_sg) + sg_dma_len(src_sg) -
+ src_avail;
+
+ /* Check if a new window needs to get added for 'dst' */
+ ret = mv_xor_add_io_win(mv_chan, dma_dst);
+ if (ret)
+ goto err;
+
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, dma_src);
+ if (ret)
+ goto err;
+
+ /* Populate the descriptor */
+ mv_xor_config_sg_ll_desc(new, dma_src, dma_dst, len, prev);
+ prev = new;
+ dst_avail -= len;
+ src_avail -= len;
+
+ if (!first)
+ first = new;
+ else
+ list_move_tail(&new->node, &first->sg_tx_list);
+
+fetch:
+ /* Fetch the next dst scatterlist entry */
+ if (dst_avail == 0) {
+ if (dst_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ dst_sg = sg_next(dst_sg);
+ if (dst_sg == NULL)
+ break;
+
+ dst_sg_len--;
+ dst_avail = sg_dma_len(dst_sg);
+ }
+
+ /* Fetch the next src scatterlist entry */
+ if (src_avail == 0) {
+ if (src_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ src_sg = sg_next(src_sg);
+ if (src_sg == NULL)
+ break;
+
+ src_sg_len--;
+ src_avail = sg_dma_len(src_sg);
+ }
+ }
+
+ /* Set the EOD flag in the last descriptor */
+ mv_xor_desc_config_eod(new);
+ first->async_tx.flags = flags;
+
+ return &first->async_tx;
+
+err:
+ /* Cleanup: Move all descriptors back into the free list */
+ spin_lock_bh(&mv_chan->lock);
+ mv_desc_clean_slot(first, mv_chan);
+ spin_unlock_bh(&mv_chan->lock);
+
+ return NULL;
+}
+
static void mv_xor_free_chan_resources(struct dma_chan *chan)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
@@ -1083,6 +1254,8 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
dma_dev->device_prep_dma_interrupt = mv_xor_prep_dma_interrupt;
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = mv_xor_prep_dma_memcpy;
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_sg = mv_xor_prep_dma_sg;
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
dma_dev->max_xor = 8;
dma_dev->device_prep_dma_xor = mv_xor_prep_dma_xor;
@@ -1132,10 +1305,11 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
goto err_free_irq;
}
- dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s)\n",
+ dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s%s)\n",
mv_chan->op_in_desc ? "Descriptor Mode" : "Registers Mode",
dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
+ dma_has_cap(DMA_SG, dma_dev->cap_mask) ? "sg " : "",
dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
dma_async_device_register(dma_dev);
@@ -1378,6 +1552,7 @@ static int mv_xor_probe(struct platform_device *pdev)
dma_cap_zero(cap_mask);
dma_cap_set(DMA_MEMCPY, cap_mask);
+ dma_cap_set(DMA_SG, cap_mask);
dma_cap_set(DMA_XOR, cap_mask);
dma_cap_set(DMA_INTERRUPT, cap_mask);
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 88eeab2..cf921dd 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -148,6 +148,7 @@ struct mv_xor_chan {
*/
struct mv_xor_desc_slot {
struct list_head node;
+ struct list_head sg_tx_list;
enum dma_transaction_type type;
void *hw_desc;
u16 idx;
--
2.10.1
^ permalink raw reply related
* [PATCH v14 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2016-10-26 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020151655.GA27598@leverpostej>
Hi Mark
On 20 October 2016 at 23:17, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Oct 20, 2016 at 03:57:52PM +0100, Lorenzo Pieralisi wrote:
>> On Thu, Oct 20, 2016 at 03:31:01PM +0100, Mark Rutland wrote:
>> > Hi,
>> >
>> > On Thu, Sep 29, 2016 at 02:17:08AM +0800, fu.wei at linaro.org wrote:
>> > > From: Fu Wei <fu.wei@linaro.org>
>> >
>> > > This patchset depends on the following patchset:
>> > > [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
>> > > https://lkml.org/lkml/2016/9/12/949
>> >
>> > Is there a branch with these anywhere? I wasn't Cc'd on those and it's
>> > rather difficult to get at the series from an LKML link.
>>
>> For the records, the dependency above has now been merged and it was
>> just a directory creation dependency (drivers/acpi/arm64, where some of
>> the code in this series will live).
>
> Ah, I see. That saves us all some trouble, then. :)
Sorry, I forgot to delete this in v14 cover letter.
The IORT patchset has been merged in to the mainline,
we don't need to mention this anymore. :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v14 2/9] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
From: Fu Wei @ 2016-10-26 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020150933.GK10234@leverpostej>
Hi Mark,
On 20 October 2016 at 23:09, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:10AM +0800, fu.wei at linaro.org wrote:
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index 6f06481..16dcd10 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -45,6 +45,12 @@ enum ppi_nr {
>> MAX_TIMER_PPI
>> };
>>
>> +enum spi_nr {
>> + PHYS_SPI,
>> + VIRT_SPI,
>> + MAX_TIMER_SPI
>> +};
>
> Please rename this to arch_timer_spi_nr (as with patch 1 for
> s/ppi_nr/arch_timer_ppi_nr/). With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
OK, NP, done :-)
Great thanks!
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v14 3/9] clocksource/drivers/arm_arch_timer: Improve printk relevant code
From: Fu Wei @ 2016-10-26 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020153244.GB27598@leverpostej>
Hi Mark,
On 20 October 2016 at 23:32, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:11AM +0800, fu.wei at linaro.org wrote:
>> static void arch_timer_banner(unsigned type)
>> {
>> - pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> - type & ARCH_CP15_TIMER ? "cp15" : "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> - type & ARCH_MEM_TIMER ? "mmio" : "",
>> - (unsigned long)arch_timer_rate / 1000000,
>> - (unsigned long)(arch_timer_rate / 10000) % 100,
>> - type & ARCH_CP15_TIMER ?
>> - (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> - "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> - type & ARCH_MEM_TIMER ?
>> - arch_timer_mem_use_virtual ? "virt" : "phys" :
>> - "");
>> + pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> + type & ARCH_CP15_TIMER ? "cp15" : "",
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> + type & ARCH_MEM_TIMER ? "mmio" : "",
>> + (unsigned long)arch_timer_rate / 1000000,
>> + (unsigned long)(arch_timer_rate / 10000) % 100,
>> + type & ARCH_CP15_TIMER ?
>> + (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> + "",
> Please restore the additional indent on this line...
>
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> + type & ARCH_MEM_TIMER ?
>> + arch_timer_mem_use_virtual ? "virt" : "phys" :
>> + "");
>
> ... and these two.
>
> No matter what checkpatch says, I prefer the code that way so as to keep
> the ternary clear.
yes, NP, I have fixed it :-)
>
> [...]
>
>> @@ -768,7 +769,7 @@ static int __init arch_timer_init(void)
>> return ret;
>>
>> arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
>> -
>> +
>
> Please mention the whitespace fixup in the commit message. It's
> surprising otherwise.
OK, added this message.
>
> With all that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Great thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [linux-sunxi] [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-10-26 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>
Hi,
On 25-10-16 06:11, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Icenowy, I appreciate your work on this, but we really need full otg
support with dynamic switching rather then hardwiring the routing, so
this cannot go in as is.
NACK.
Regards,
Hans
> ---
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 287150d..a63c766 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -36,6 +36,12 @@ Optional properties:
> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>
> +Optional properties for H3 or A64 SoCs:
> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
> + MUSB. (boolean, if this property is set, the OHCI/EHCI
> + controllers at PHY0 should be enabled and the MUSB
> + controller must *NOT* be enabled)
> +
> Example:
> usbphy: phy at 0x01c13400 {
> #phy-cells = <1>;
>
^ permalink raw reply
* [PATCH v14 1/9] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
From: Fu Wei @ 2016-10-26 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020144510.GJ10234@leverpostej>
Hi Mark
On 20 October 2016 at 22:45, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> On Thu, Sep 29, 2016 at 02:17:09AM +0800, fu.wei at linaro.org wrote:
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index caedb74..6f06481 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -19,6 +19,9 @@
>
> Please add:
>
> #include <linux/bitops.h>
>
> ... immediately before the includes below; it's needed to ensure that
> BIT() is defined in all cases. Previously we were relying on implicit
> header includes, which is not good practice.
yes, you are right!
added this, thanks !
>
>> #include <linux/timecounter.h>
>> #include <linux/types.h>
>>
>> +#define ARCH_CP15_TIMER BIT(0)
>> +#define ARCH_MEM_TIMER BIT(1)
>
> If we're going to expose these in a header, it would be better to rename
> them to something that makes their usage/meaning clear. These should
> probably be ARCH_TIMER_TYPE_{CP15,MEM}.
>
> I guess this can wait for subsequent cleanup.
>
>> +enum ppi_nr {
>> + PHYS_SECURE_PPI,
>> + PHYS_NONSECURE_PPI,
>> + VIRT_PPI,
>> + HYP_PPI,
>> + MAX_TIMER_PPI
>> +};
>
> Please rename this to arch_timer_ppi_nr (updating the single user in
> drivers/clocksource/arm_arch_timer.c). That'll avoid the potential for
> name clashes in files this happens to get included in (potentially
> transitively via other headers).
OK, NP, I have fixed this.
>
> With those changes (regardless of the ARCH_TIMER_TYPE_* bits):
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
For ARCH_TIMER_TYPE_*, maybe I should add a patch at the end of this
patchset to fix it, OK ?
Thanks for ACK :-)
>
> Thanks,
> Mark.
>
>> +
>> #define ARCH_TIMER_PHYS_ACCESS 0
>> #define ARCH_TIMER_VIRT_ACCESS 1
>> #define ARCH_TIMER_MEM_PHYS_ACCESS 2
>> --
>> 2.7.4
>>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Lee Jones @ 2016-10-26 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CC15CFB4-60D0-4A63-A3D3-2079CFA31274@gmail.com>
On Tue, 25 Oct 2016, John Syne wrote:
> > On Oct 24, 2016, at 11:38 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 24 Oct 2016, John Syne wrote:
> >>> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
> >>>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>
> >>>> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
> >>>>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>>>>
> >>>>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
> >>>>>>> sampling rates goes up from 100K samples per second to 800K
> >>>>>>> samples per second on AM335x and AM437x SoC.
> >>>>>>>
> >>>>>>> Also increase opendelay for touchscreen configuration to
> >>>>>>> equalize the increase in ADC reference clock frequency,
> >>>>>>> which results in the same amount touch events reported via
> >>>>>>> evtest on AM335x GP EVM.
> >>>>>>>
> >>>>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> This patch depends on ADC DMA patch series [1]
> >>>>>>>
> >>>>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
> >>>>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
> >>>>>>> This answers that DMA support is must for ADC to consume the
> >>>>>>> samples generated at 24MHz with no open, step delay or
> >>>>>>> averaging with patch [2].
> >>>>>>>
> >>>>>>> Measured the performance with the iio_generic_buffer with the
> >>>>>>> patch [3] applied
> >>>>>>>
> >>>>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
> >>>>>>> [2] - http://pastebin.ubuntu.com/23357935/
> >>>>>>> [3] - http://pastebin.ubuntu.com/23357939/
> >>>>>>>
> >>>>>>> ---
> >>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
> >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> index b9a53e0..96c4207 100644
> >>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> @@ -90,7 +90,7 @@
> >>>>>>> /* Delay register */
> >>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
> >>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
> >>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> >>>>> Wouldn?t this be better to add this to the devicetree?
> >>>>>
> >>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> >>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> >>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> >>>>
> >>>> For a touch screen, there is not need to change in these parameter
> >>>> settings, so my opinion is to keep it as is. Or am I missing something?
> >>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
> >>
> >> Here is a DT overlay were this gets using on the BeagleBoneBlack.
> >>
> >> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
> >>
> >> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
> >
> > This looks like configuration, no?
> >
> > DT should be used to describe the hardware.
> You may be right, but how is this different to setting the baud rate on a serial channel or sampling rate on a audio channel? Looking through the DT, there are many configuration settings, so I?m not sure what is the correct way to handle this. Surely it is better to handle this in DT vs hard coding these settings?
I think setting the UART baud rate is also an invalid DT entry.
It's okay to list all of the options in DT, but to actually select
one, that should be done either in userspace or as a kernel option.
Perhaps as a Kconfig selection.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-26 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025134940.GA3993@griffinp-ThinkPad-X1-Carbon-2nd>
> > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > to assume the hardware may have been used in previous boot stages, and it should
> > > not attempt to disable the clock.
> >
> > None of the boot loaders we use do this.
>
> But the Linux kernel isn't just used by us. It is not uncommon for STB
> bootloaders to get information from the frontend as part of the boot process.
Okay, this is the clincher. Since we need to support non-standard
bootloaders, it's difficult to guarantee that the clock will be
disabled at boot. For this reason, I believe that we can call this a
critical clock.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [linux-sunxi] [PATCH RESEND 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-26 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55fe59fc-6e93-d519-2d7c-264c48820fc4@redhat.com>
26.10.2016, 16:28, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 25-10-16 06:11, Icenowy Zheng wrote:
>> ?On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>> ?the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>> ?(which is a Host-only controller, but more stable and easy to implement).
>>
>> ?This property marks whether on a certain board which controller should be
>> ?attached to the PHY.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Icenowy, I appreciate your work on this, but we really need full otg
> support with dynamic switching rather then hardwiring the routing, so
> this cannot go in as is.
Now I have both PHY0 controllers' drivers.
In the tree of https://github.com/Icenowy/linux/tree/ice-a64-v6.1 , I have already
enabled MUSB controller.
And this patchset is for those prefer a stable USB host implement to dual-role
implementation. MUSB is a good UDC, but not a good host controller. My USB
sound card cannot work on MUSB on A33. Even connecting a R8's MUSB (Serial
Gadget) to an A33's MUSB cannot work.
See the IRC log between Andre and me,
https://irclog.whitequark.org/linux-sunxi/2016-10-24#18012695; .
>
> NACK.
>
> Regards,
>
> Hans
>
>> ?---
>> ??Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
>> ??1 file changed, 6 insertions(+)
>>
>> ?diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?index 287150d..a63c766 100644
>> ?--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?@@ -36,6 +36,12 @@ Optional properties:
>> ??- usb1_vbus-supply : regulator phandle for controller usb1 vbus
>> ??- usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>
>> ?+Optional properties for H3 or A64 SoCs:
>> ?+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>> ?+ MUSB. (boolean, if this property is set, the OHCI/EHCI
>> ?+ controllers at PHY0 should be enabled and the MUSB
>> ?+ controller must *NOT* be enabled)
>> ?+
>> ??Example:
>> ??????????usbphy: phy at 0x01c13400 {
>> ??????????????????#phy-cells = <1>;
^ permalink raw reply
* [PATCH v14 5/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Fu Wei @ 2016-10-26 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021112120.GC16630@leverpostej>
Hi Mark,
On 21 October 2016 at 19:21, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 21, 2016 at 12:14:01PM +0100, Mark Rutland wrote:
>> On Thu, Oct 20, 2016 at 05:58:17PM +0100, Mark Rutland wrote:
>> > On Thu, Sep 29, 2016 at 02:17:13AM +0800, fu.wei at linaro.org wrote:
>> > > + arch_timer_ppi[PHYS_NONSECURE_PPI] = acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI);
>> > > + arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI);
>> > > + arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI);
>> > > + /* Always-on capability */
>> > > + arch_timer_c3stop = acpi_gtdt_c3stop();
>> >
>> > ... I think we should check the flag on the relevant interrupt, though
>> > that's worth clarifying.
>>
>> I see I misread the spec; this is part of the common flags.
>>
>> Please ignore this point; sorry for the noise.
>
> Actually, I misread the spec this time around; the flag *can* differ per
> interrupt for the sysreg/cp15 timer, but not for the MMIO timers where
> the flag is in a common field.
>
> So please *do* consider the above.
yes , you are right , will do
Thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Maxime Ripard @ 2016-10-26 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477465231-17704-1-git-send-email-mr.nuke.me@gmail.com>
On Wed, Oct 26, 2016 at 12:00:30AM -0700, Alexandru Gagniuc wrote:
> This is the seventh attempt to get this patch in. I was prompted to look
> into this again as someone recently remarked:
>
> " cool, to bad spi does not work properly on allwinner..."
>
> Two and a half years ago, we were told this will all be handled with DMA.
> A year or so ago, we were told this will all be handled with DMA.
> A week or so ago, we were told this will all be handled with DMA.
>
> See the pattern?
> When DMA finally takes over, this fallback path is not mutually exclusive.
I definitely agree, and we had this patch in the CHIP kernel for quite
some time, working like a charm.
I was planning to respin it in the next few days, glad to see you took
care of it :)
Mark, any comments on this? For the record, it already has my Acked-by.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161026/f2bea18e/attachment.sig>
^ permalink raw reply
* [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
From: Sekhar Nori @ 2016-10-26 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3af8517-c452-ae8c-6840-dd8a684e4ab2@lechnology.com>
On Tuesday 25 October 2016 09:23 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 10/25/2016 05:17 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 03:07 PM, Axel Haslam wrote:
>>> Hi Sekar,
>>>
>>> On Tue, Oct 25, 2016 at 10:10 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>>>>> From: David Lechner <david@lechnology.com>
>>>>>
>>>>> The CFGCHIP registers are used by a number of devices, so using a
>>>>> syscon
>>>>> device to share them. The first consumer of this will by the
>>>>> phy-da8xx-usb
>>>>> driver.
>>>>>
>>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>>> [Axel: minor fix: change id to -1]
>>>>
>>>> Can you please clarify this change? There could be other syscon devices
>>>> on the chip for other common registers. Why use the singular device-id?
>>>>
>>>
>>> in the case of non DT boot, the phy driver is looking for "syscon" :
>>>
>>> d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
>>>
>>> if we register the syscon driver with id = 0, the actual name of the
>>> syscon
>>> device will be "syscon.0" and the phy driver will fail to probe, because
>>> the strncmp match in the syscon driver (syscon_match_pdevname)
>>> will fail.
>>>
>>> should i change the phy driver instead?
>>
>> Yes, please. Forcing only one syscon region for the whole chip will be
>> too restrictive, I am pretty sure.
>>
>> Thanks,
>> Sekhar
>>
>
> In the previous review, you requested that this be changed to -1 [1].
>
> If we change it back to 0, it will also require reverting a patch to the
> phy driver that has already been merged[2].
Sigh. Sorry about going around in circles on this one. Lets go with what
you have. If and when there is a need for another syscon node, the
driver and platform code can be updated. At least we will know why the
change is being done at that time.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Peter Griffin @ 2016-10-26 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026085141.GJ8574@dell>
Hi Lee,
On Wed, 26 Oct 2016, Lee Jones wrote:
> > > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > > to assume the hardware may have been used in previous boot stages, and it should
> > > > not attempt to disable the clock.
> > >
> > > None of the boot loaders we use do this.
> >
> > But the Linux kernel isn't just used by us. It is not uncommon for STB
> > bootloaders to get information from the frontend as part of the boot process.
>
> Okay, this is the clincher. Since we need to support non-standard
> bootloaders, it's difficult to guarantee that the clock will be
> disabled at boot. For this reason, I believe that we can call this a
> critical clock.
>
That's good news as the STi maintainer already acked and applied the patch.
Peter.
^ permalink raw reply
* [PATCH 3/4] dt-bindings: Update domain-idle-state binding to use correct compatibles
From: Sudeep Holla @ 2016-10-26 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh980taqp.fsf@baylibre.com>
On 25/10/16 21:49, Kevin Hilman wrote:
> Lina Iyer <lina.iyer@linaro.org> writes:
>
>> Update domain-idle-state binding to use "domain-idle-state" compatible
>> from Documentation/devicetree/bindings/arm/idle-states.txt.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> Documentation/devicetree/bindings/power/power_domain.txt | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> With no current users for this, I don't see the point of adding a
> compatible now.
>
> IMO, this should wait and be added with the identified user we can
> discuss it then.
>
No, IMO it needs to be used for the proposed SoC idle/genpd solution.
I understand the nodes that are "arm,idle-state" compatible can be used
for this new SoC hierarchical idle management, but it was never defined
for that use originally. So this new feature must be advertised by the
firmware with the presence of "domain-idle-state".
Yes we might have other ways to detect that but I have already seen that
broken on the reference platform, so we need alternate/DT way to specify
that.
Not all existing "arm,idle-state" compatible nodes will be capable of
supporting this new SoC idle feature. It's just better and safer for a
new feature getting added that relies on DT to have a new compatible.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v2:
- move phy timing back to dsi_phy_timconfig.
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 74 +++++++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..8b3b38a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -161,20 +161,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
static void dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+ timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
+ (NS_TO_CYCLE(0x150, cycle_time) << 16);
+ timcon3 = (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+ NS_TO_CYCLE(0x40, cycle_time);
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +200,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
+ /**
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
+ */
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
+
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477464081.17405.2.camel@mtksdaap41>
On Wed, 2016-10-26 at 14:41 +0800, CK Hu wrote:
> Hi, Jitao:
>
> On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> > signal will cause h-time larger than normal and reduce FPS.
> > Need to multiply a coefficient to offset the extra signal's effect.
> > coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> > Ths_exit)/(htotal*bpp/lane_number))
> >
> > Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> > ---
> > Change since v1:
> > - phy_timing2 and phy_timing3 refer clock cycle time.
> > - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
> > 1 file changed, 67 insertions(+), 36 deletions(-)
> >
>
> [snip...]
>
> >
> > -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> > +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> > + u32 phy_timing1, u32 phy_timing2,
> > + u32 phy_timing3)
> > {
> > - u32 timcon0, timcon1, timcon2, timcon3;
> > - unsigned int ui, cycle_time;
> > - unsigned int lpx;
> > -
> > - ui = 1000 / dsi->data_rate + 0x01;
> > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > - lpx = 5;
> > -
> > - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> > - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> > - (4 * lpx);
> > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > - NS_TO_CYCLE(0x40, cycle_time);
> > -
> > - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> > - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> > - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> > - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
>
> Why do you move these calculation to mtk_dsi_poweron()? You can keep
> calculation here and just do some modification.
>
> Regards,
> CK
Thanks for your review. I'll fix it in next patchset.
Best Regards
jitao
>
> > + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> > + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> > + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> > + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> > }
> >
> > static void mtk_dsi_enable(struct mtk_dsi *dsi)
> > @@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > {
> > struct device *dev = dsi->dev;
> > int ret;
> > + u64 bit_clock, total_bits;
> > + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> > + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
> > + u32 ui, cycle_time;
> >
> > if (++dsi->refcount != 1)
> > return 0;
> >
> > + switch (dsi->format) {
> > + case MIPI_DSI_FMT_RGB565:
> > + bit_per_pixel = 16;
> > + break;
> > + case MIPI_DSI_FMT_RGB666_PACKED:
> > + bit_per_pixel = 18;
> > + break;
> > + case MIPI_DSI_FMT_RGB666:
> > + case MIPI_DSI_FMT_RGB888:
> > + default:
> > + bit_per_pixel = 24;
> > + break;
> > + }
> > + /**
> > + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> > + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> > + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> > + * + Thstrail + Ths_exit + Ths_zero) /
> > + * (htotal * byte_per_pixel /lane_number)
> > + */
> > + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> > + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> > + dsi->vm.hsync_len;
> > + htotal_bits = htotal * bit_per_pixel;
> > +
> > /**
> > - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> > - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> > - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> > - * we set mipi_ratio is 1.05.
> > + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> > */
> > - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> > + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> > + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> > + overhead_bits = overhead_cycles * dsi->lanes * 8;
> > + total_bits = htotal_bits + overhead_bits;
> >
> > - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> > + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> > + htotal_bits * dsi->lanes);
> > +
> > + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> > if (ret < 0) {
> > dev_err(dev, "Failed to set data rate: %d\n", ret);
> > goto err_refcount;
> > @@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> >
> > mtk_dsi_enable(dsi);
> > mtk_dsi_reset(dsi);
> > - dsi_phy_timconfig(dsi);
> > +
> > + ui = 1000 / dsi->data_rate + 0x01;
> > + cycle_time = 8000 / dsi->data_rate + 0x01;
> > +
> > + phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> > + phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
> > + phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > + (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > + phy_timing3 = (2 * LPX) << 16 |
> > + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > + NS_TO_CYCLE(0x40, cycle_time);
> > +
> > + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> > + phy_timing3);
> >
> > return 0;
> >
>
>
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-10-26 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+Tqd2MGmz+8XhLXhaZiEc78QOwHSpVrQA65-p1AcfT+_xgg@mail.gmail.com>
Hi Bruno,
On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> Hi Alexandre,
>
>>
>> stm32f469-disco and stm32f429-eval boards use SDRAM start address remapping
>> (to @0) to boost performances. A DMA translation through "dma-ranges"
>> property was needed for other masters than the M4 CPU.
>> stm32f429-disco doesn't use remapping so doesn't need this DMA translation.
>> This patches moves this DMA translation definition from stm32f429 soc file
>> to board files.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
>> index 13c7cd2..a763c15 100644
>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> @@ -82,6 +82,10 @@
>> };
>> };
>>
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> +
>> usbotg_hs_phy: usbphy {
>> #phy-cells = <0>;
>> compatible = "usb-nop-xceiv";
>
> Shouldn't also the peripheral dma-ranges property move to board specific too?
> I had this patch for while but I didn't had the time to submit:
Well spot I forgot it. Actually, discussing with Arnd ysterday on IIRC,
empty dma-ranges is not needed. Can you test on your side by removing
dma-ranges in usb node please ?
I will push a v2 by removing empty dma-ranges if tests are ok in your side.
Thanks in advance
Alex
>
> Author: Bruno Herrera <bruherrera@gmail.com>
> Date: Sun Oct 16 14:50:00 2016 -0200
>
> ARM: DT: STM32: Use dma-ranges property per board not at dtsi file
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> b/arch/arm/boot/dts/stm32429i-eval.dts
> index 6bfc595..2a22a82 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -52,6 +52,10 @@
> model = "STMicroelectronics STM32429i-EVAL board";
> compatible = "st,stm32429i-eval", "st,stm32f429";
>
> + soc {
> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> + };
> +
> chosen {
> bootargs = "root=/dev/ram rdinit=/linuxrc";
> stdout-path = "serial0:115200n8";
> @@ -96,6 +100,7 @@
>
> ðernet0 {
> status = "okay";
> + dma-ranges;
> pinctrl-0 = <ðernet0_mii>;
> pinctrl-names = "default";
> phy-mode = "mii-id";
> @@ -116,6 +121,7 @@
> };
>
> &usbotg_hs {
> + dma-ranges;
> dr_mode = "host";
> phys = <&usbotg_hs_phy>;
> phy-names = "usb2-phy";
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7d624a2..697a133 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -59,7 +59,6 @@
> };
>
> soc {
> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>
> timer2: timer at 40000000 {
> compatible = "st,stm32-timer";
> @@ -472,13 +471,11 @@
> st,syscon = <&syscfg 0x4>;
> snps,pbl = <8>;
> snps,mixed-burst;
> - dma-ranges;
> status = "disabled";
> };
>
> usbotg_hs: usb at 40040000 {
> compatible = "snps,dwc2";
> - dma-ranges;
> reg = <0x40040000 0x40000>;
> interrupts = <77>;
> clocks = <&rcc 0 29>;
>
>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index 0596d60..3a1cfdd 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -59,8 +59,6 @@
>> };
>>
>> soc {
>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> -
>> timer2: timer at 40000000 {
>> compatible = "st,stm32-timer";
>> reg = <0x40000000 0x400>;
>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
>> index 9e73656..c2213c0 100644
>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> @@ -64,6 +64,10 @@
>> aliases {
>> serial0 = &usart3;
>> };
>> +
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> };
>>
>> &clk_hse {
>> --
>
>
> Br.,
> Bruno
>
^ permalink raw reply
* bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]
From: Michael Cree @ 2016-10-26 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026070430.e2tkbzza5lk4lgju@tower>
On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > >
> > > > - a lot of the less common architectures just don't get updated
> > > > in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > >
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > > and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > > did add the later __NR_execveat.
> > >
> > > __NR_bpf was not forgotten on Alpha. It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > >
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> >
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
>
> Oh. When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
>
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
>
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.
Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:
#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK
[snip many passing tests]
#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6
[snip many more passing tests]
Summary: 101 PASSED, 1 FAILED
Should I be concerned about the failing #69 test?
Cheers
Michael.
^ permalink raw reply
* [PATCH v6 1/2] mfd: add support for Allwinner SoCs ADC
From: Lee Jones @ 2016-10-26 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473943444-23979-2-git-send-email-quentin.schulz@free-electrons.com>
On Thu, 15 Sep 2016, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. For now, only the ADC and the thermal
> sensor drivers are probed by the MFD, the touchscreen controller support
> will be added later.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
> ---
>
> v6:
> - remove "-mfd" from filenames and variables inside MFD driver,
> - use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
> - cosmetic changes,
> - use IDs and switch over ID to get cells specific to an architecture, instead
> of using cells direclty, in of_device_id.data,
> - compute size of mfd_cells array instead of hardcoded one,
>
> v5:
> - correct mail address,
>
> v4:
> - rename files and variables from sunxi* to sun4i*,
> - rename defines from SUNXI_* to SUN4I_* or SUN6I_*,
> - remove TP in defines name,
> - rename SUNXI_IRQ_* to SUN4I_GPADC_IRQ_* for consistency,
> - use devm functions for regmap_add_irq_chip and mfd_add_devices,
> - remove remove functions (now empty thanks to devm functions),
>
> v3:
> - use defines in regmap_irq instead of hard coded BITs,
> - use of_device_id data field to chose which MFD cells to add considering
> the compatible responsible of the MFD probe,
> - remove useless initializations,
> - disable all interrupts before adding them to regmap_irqchip,
> - add goto error label in probe,
> - correct wrapping in header license,
> - move defines from IIO driver to header,
> - use GENMASK to limit the size of the variable passed to a macro,
> - prefix register BIT defines with the name of the register,
> - reorder defines,
>
> v2:
> - add license headers,
> - reorder alphabetically includes,
> - add SUNXI_GPADC_ prefixes for defines,
>
> drivers/mfd/Kconfig | 15 ++++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/sun4i-gpadc.c | 181 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/sun4i-gpadc.h | 94 +++++++++++++++++++++
> 4 files changed, 292 insertions(+)
> create mode 100644 drivers/mfd/sun4i-gpadc.c
> create mode 100644 include/linux/mfd/sun4i-gpadc.h
Applied, thanks.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 1bcf601..45db3f4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -29,6 +29,21 @@ config MFD_ACT8945A
> linear regulators, along with a complete ActivePath battery
> charger.
>
> +config MFD_SUN4I_GPADC
> + tristate "Allwinner sunxi platforms' GPADC MFD driver"
> + select MFD_CORE
> + select REGMAP_MMIO
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> + Select this to get support for Allwinner SoCs (A10, A13 and A31) ADC.
> + This driver will only map the hardware interrupt and registers, you
> + have to select individual drivers based on this MFD to be able to use
> + the ADC or the thermal sensor. This will try to probe the ADC driver
> + sun4i-gpadc-iio and the hwmon driver iio_hwmon.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sun4i-gpadc.
> +
> config MFD_AS3711
> bool "AMS AS3711"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 42a66e1..12c49af 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -205,3 +205,5 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +
> +obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/sun4i-gpadc.c b/drivers/mfd/sun4i-gpadc.c
> new file mode 100644
> index 0000000..276a1f4
> --- /dev/null
> +++ b/drivers/mfd/sun4i-gpadc.c
> @@ -0,0 +1,181 @@
> +/* ADC MFD core driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@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 version 2 as published by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/regmap.h>
> +
> +#include <linux/mfd/sun4i-gpadc.h>
> +
> +#define ARCH_SUN4I_A10 0
> +#define ARCH_SUN5I_A13 1
> +#define ARCH_SUN6I_A31 2
> +
> +static struct resource adc_resources[] = {
> + DEFINE_RES_IRQ_NAMED(SUN4I_GPADC_IRQ_FIFO_DATA, "FIFO_DATA_PENDING"),
> + DEFINE_RES_IRQ_NAMED(SUN4I_GPADC_IRQ_TEMP_DATA, "TEMP_DATA_PENDING"),
> +};
> +
> +static const struct regmap_irq sun4i_gpadc_regmap_irq[] = {
> + REGMAP_IRQ_REG(SUN4I_GPADC_IRQ_FIFO_DATA, 0,
> + SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN),
> + REGMAP_IRQ_REG(SUN4I_GPADC_IRQ_TEMP_DATA, 0,
> + SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN),
> +};
> +
> +static const struct regmap_irq_chip sun4i_gpadc_regmap_irq_chip = {
> + .name = "sun4i_gpadc_irq_chip",
> + .status_base = SUN4I_GPADC_INT_FIFOS,
> + .ack_base = SUN4I_GPADC_INT_FIFOS,
> + .mask_base = SUN4I_GPADC_INT_FIFOC,
> + .init_ack_masked = true,
> + .mask_invert = true,
> + .irqs = sun4i_gpadc_regmap_irq,
> + .num_irqs = ARRAY_SIZE(sun4i_gpadc_regmap_irq),
> + .num_regs = 1,
> +};
> +
> +static struct mfd_cell sun4i_gpadc_cells[] = {
> + {
> + .name = "sun4i-a10-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" }
> +};
> +
> +static struct mfd_cell sun5i_gpadc_cells[] = {
> + {
> + .name = "sun5i-a13-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" },
> +};
> +
> +static struct mfd_cell sun6i_gpadc_cells[] = {
> + {
> + .name = "sun6i-a31-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" },
> +};
> +
> +static const struct regmap_config sun4i_gpadc_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .fast_io = true,
> +};
> +
> +static const struct of_device_id sun4i_gpadc_of_match[] = {
> + {
> + .compatible = "allwinner,sun4i-a10-ts",
> + .data = (void *)ARCH_SUN4I_A10,
> + }, {
> + .compatible = "allwinner,sun5i-a13-ts",
> + .data = (void *)ARCH_SUN5I_A13,
> + }, {
> + .compatible = "allwinner,sun6i-a31-ts",
> + .data = (void *)ARCH_SUN6I_A31,
> + }, { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, sun4i_gpadc_of_match);
> +
> +static int sun4i_gpadc_probe(struct platform_device *pdev)
> +{
> + struct sun4i_gpadc_dev *dev;
> + struct resource *mem;
> + const struct of_device_id *of_id;
> + const struct mfd_cell *cells;
> + unsigned int irq, size;
> + int ret;
> +
> + of_id = of_match_node(sun4i_gpadc_of_match, pdev->dev.of_node);
> + if (!of_id)
> + return -EINVAL;
> +
> + switch ((int)of_id->data) {
> + case ARCH_SUN4I_A10:
> + cells = sun4i_gpadc_cells;
> + size = ARRAY_SIZE(sun4i_gpadc_cells);
> + break;
> + case ARCH_SUN5I_A13:
> + cells = sun5i_gpadc_cells;
> + size = ARRAY_SIZE(sun5i_gpadc_cells);
> + break;
> + case ARCH_SUN6I_A31:
> + cells = sun6i_gpadc_cells;
> + size = ARRAY_SIZE(sun6i_gpadc_cells);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + dev->base = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(dev->base))
> + return PTR_ERR(dev->base);
> +
> + dev->dev = &pdev->dev;
> + dev_set_drvdata(dev->dev, dev);
> +
> + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> + &sun4i_gpadc_regmap_config);
> + if (IS_ERR(dev->regmap)) {
> + ret = PTR_ERR(dev->regmap);
> + dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
> + return ret;
> + }
> +
> + /* Disable all interrupts */
> + regmap_write(dev->regmap, SUN4I_GPADC_INT_FIFOC, 0);
> +
> + irq = platform_get_irq(pdev, 0);
> + ret = devm_regmap_add_irq_chip(&pdev->dev, dev->regmap, irq,
> + IRQF_ONESHOT, 0,
> + &sun4i_gpadc_regmap_irq_chip,
> + &dev->regmap_irqc);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add irq chip: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_mfd_add_devices(dev->dev, 0, cells, size, NULL, 0, NULL);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add MFD devices: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver sun4i_gpadc_driver = {
> + .driver = {
> + .name = "sun4i-gpadc",
> + .of_match_table = of_match_ptr(sun4i_gpadc_of_match),
> + },
> + .probe = sun4i_gpadc_probe,
> +};
> +
> +module_platform_driver(sun4i_gpadc_driver);
> +
> +MODULE_DESCRIPTION("Allwinner sunxi platforms' GPADC MFD core driver");
> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> new file mode 100644
> index 0000000..d7a29f2
> --- /dev/null
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -0,0 +1,94 @@
> +/* Header of ADC MFD core driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@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 version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#ifndef __SUN4I_GPADC__H__
> +#define __SUN4I_GPADC__H__
> +
> +#define SUN4I_GPADC_CTRL0 0x00
> +
> +#define SUN4I_GPADC_CTRL0_ADC_FIRST_DLY(x) ((GENMASK(7, 0) & (x)) << 24)
> +#define SUN4I_GPADC_CTRL0_ADC_FIRST_DLY_MODE BIT(23)
> +#define SUN4I_GPADC_CTRL0_ADC_CLK_SELECT BIT(22)
> +#define SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(x) ((GENMASK(1, 0) & (x)) << 20)
> +#define SUN4I_GPADC_CTRL0_FS_DIV(x) ((GENMASK(3, 0) & (x)) << 16)
> +#define SUN4I_GPADC_CTRL0_T_ACQ(x) (GENMASK(15, 0) & (x))
> +
> +#define SUN4I_GPADC_CTRL1 0x04
> +
> +#define SUN4I_GPADC_CTRL1_STYLUS_UP_DEBOUNCE(x) ((GENMASK(7, 0) & (x)) << 12)
> +#define SUN4I_GPADC_CTRL1_STYLUS_UP_DEBOUNCE_EN BIT(9)
> +#define SUN4I_GPADC_CTRL1_TOUCH_PAN_CALI_EN BIT(6)
> +#define SUN4I_GPADC_CTRL1_TP_DUAL_EN BIT(5)
> +#define SUN4I_GPADC_CTRL1_TP_MODE_EN BIT(4)
> +#define SUN4I_GPADC_CTRL1_TP_ADC_SELECT BIT(3)
> +#define SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(2, 0) & (x))
> +
> +/* TP_CTRL1 bits for sun6i SOCs */
> +#define SUN6I_GPADC_CTRL1_TOUCH_PAN_CALI_EN BIT(7)
> +#define SUN6I_GPADC_CTRL1_TP_DUAL_EN BIT(6)
> +#define SUN6I_GPADC_CTRL1_TP_MODE_EN BIT(5)
> +#define SUN6I_GPADC_CTRL1_TP_ADC_SELECT BIT(4)
> +#define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> +
> +#define SUN4I_GPADC_CTRL2 0x08
> +
> +#define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x)) << 28)
> +#define SUN4I_GPADC_CTRL2_TP_MODE_SELECT(x) ((GENMASK(1, 0) & (x)) << 26)
> +#define SUN4I_GPADC_CTRL2_PRE_MEA_EN BIT(24)
> +#define SUN4I_GPADC_CTRL2_PRE_MEA_THRE_CNT(x) (GENMASK(23, 0) & (x))
> +
> +#define SUN4I_GPADC_CTRL3 0x0c
> +
> +#define SUN4I_GPADC_CTRL3_FILTER_EN BIT(2)
> +#define SUN4I_GPADC_CTRL3_FILTER_TYPE(x) (GENMASK(1, 0) & (x))
> +
> +#define SUN4I_GPADC_TPR 0x18
> +
> +#define SUN4I_GPADC_TPR_TEMP_ENABLE BIT(16)
> +#define SUN4I_GPADC_TPR_TEMP_PERIOD(x) (GENMASK(15, 0) & (x))
> +
> +#define SUN4I_GPADC_INT_FIFOC 0x10
> +
> +#define SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN BIT(18)
> +#define SUN4I_GPADC_INT_FIFOC_TP_OVERRUN_IRQ_EN BIT(17)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN BIT(16)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_XY_CHANGE BIT(13)
> +#define SUN4I_GPADC_INT_FIFOC_TP_FIFO_TRIG_LEVEL(x) ((GENMASK(4, 0) & (x)) << 8)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_DRQ_EN BIT(7)
> +#define SUN4I_GPADC_INT_FIFOC_TP_FIFO_FLUSH BIT(4)
> +#define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN BIT(1)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN BIT(0)
> +
> +#define SUN4I_GPADC_INT_FIFOS 0x14
> +
> +#define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDING BIT(18)
> +#define SUN4I_GPADC_INT_FIFOS_FIFO_OVERRUN_PENDING BIT(17)
> +#define SUN4I_GPADC_INT_FIFOS_FIFO_DATA_PENDING BIT(16)
> +#define SUN4I_GPADC_INT_FIFOS_TP_IDLE_FLG BIT(2)
> +#define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDING BIT(1)
> +#define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING BIT(0)
> +
> +#define SUN4I_GPADC_CDAT 0x1c
> +#define SUN4I_GPADC_TEMP_DATA 0x20
> +#define SUN4I_GPADC_DATA 0x24
> +
> +#define SUN4I_GPADC_IRQ_FIFO_DATA 0
> +#define SUN4I_GPADC_IRQ_TEMP_DATA 1
> +
> +/* 10s delay before suspending the IP */
> +#define SUN4I_GPADC_AUTOSUSPEND_DELAY 10000
> +
> +struct sun4i_gpadc_dev {
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap_irq_chip_data *regmap_irqc;
> + void __iomem *base;
> +};
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-26 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026055648.bipks7wthiu4gmlf@phenom.ffwll.local>
Hi Daniel,
Thansk for reviewing!
? 2016/10/26 13:56, Daniel Vetter ??:
> On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
>> Add support for fbdev and kms fb management.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> Small drive-by comment below.
>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index db8d80e..d41138a 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,23 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include <drm/drmP.h>
>> +#include <drm/drm_fb_helper.h>
>> #include <drm/ttm/ttm_bo_driver.h>
>> #include <drm/drm_gem.h>
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer fb;
>
> I wouldn't embed the single framebuffer here, but instead have a pointer
> and just refcount it. This here is a pattern that predates framebuffer
> refcounting, and it leads to plenty of surprises.
will allocate fbdev in next patch version, thanks.
>
> Maybe we should update the documentation of
> drm_framebuffer_unregister_private() to mention that it is deprecated? The
> overview doc in drm_framebuffer.c already explains that, but I guess
> that's not obvious enough.
Just replace drm_framebuffer_unregister_private() with
drm_framebuffer_remove()?
I found many other drivers use the following two functions in their
own xxx_fbdev_destroy():
drm_framebuffer_unregister_private(fbdev->fb);
drm_framebuffer_remove(fbdev->fb);
so the former is redundant and can be removed directly?
>
> Can you pls do that patch? And pls make sure it all looks pretty when
> building the docs with
No problem, i'll send another patch later.
Regards,
Rongrong
>
> $ make htmldocs
>
> Thanks, Daniel
>
^ 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