* [PATCH] spi: atmel: use managed resource for gpio chip select
From: Nicolas Ferre @ 2016-11-07 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUQLkHn4=3U6TNjgTN--RUHZHsbwNu9dLdFrBJA0sx4aw@mail.gmail.com>
Le 21/09/2016 ? 10:20, Geert Uytterhoeven a ?crit :
> Hi Nicolas,
>
> On Wed, Sep 21, 2016 at 9:55 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> Use the managed gpio CS pin request so that we avoid having trouble
>> in the cleanup code.
>> In fact, if module was configured with DT, cleanup code released
>> invalid pin. Since resource wasn't freed, module cannot be reinserted.
>>
>> Reported-by: Alexander Morozov <linux@meltdown.ru>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>> drivers/spi/spi-atmel.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
>> index 8feac599e9ab..4e3f2345844a 100644
>> --- a/drivers/spi/spi-atmel.c
>> +++ b/drivers/spi/spi-atmel.c
>> @@ -1248,7 +1248,8 @@ static int atmel_spi_setup(struct spi_device *spi)
>> return -ENOMEM;
>>
>> if (as->use_cs_gpios) {
>> - ret = gpio_request(npcs_pin, dev_name(&spi->dev));
>> + ret = devm_gpio_request(&spi->dev,
>> + npcs_pin, dev_name(&spi->dev));
>
> Note that spi_master.setup() can be called multiple times during the lifetime
> of the spi_device.
Sure, this is what I read in include/linux/spi/spi.h "It's always safe
to call this unless transfers are pending on the device whose settings
are being modified."
It also means that the whole memory allocation for devices that is done
a few lines above this gpio request is also completely wrong... This
function needs a serious refactoring.
Thanks for the heads-up.
Best regards,
>> if (ret) {
>> kfree(asd);
>> return ret;
>> @@ -1471,13 +1472,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
>> static void atmel_spi_cleanup(struct spi_device *spi)
>> {
>> struct atmel_spi_device *asd = spi->controller_state;
>> - unsigned gpio = (unsigned long) spi->controller_data;
>>
>> if (!asd)
>> return;
>>
>> spi->controller_state = NULL;
>> - gpio_free(gpio);
>> kfree(asd);
>> }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/6] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Daniel Thompson @ 2016-11-07 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-3-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
> from pll-sai-p.
>
> The SDIO clock could be also derived from 48Mhz or from sys clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 7641acd..dda15bc 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -199,7 +199,7 @@ struct stm32f4_gate_data {
> { STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
> - { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
> + { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
I'm confused. How do the "sdmux" clock come to exist on STM32F429?
> { STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
> @@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
> "no-clock", "lse", "lsi", "hse-rtc"
> };
>
> +static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
> +
> +static const char *sdmux_parents[2] = { "pll48", "sys" };
> +
> struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> @@ -1109,6 +1113,18 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> goto fail;
> }
>
> + if (of_device_is_compatible(np, "st,stm32f469-rcc")) {
> + clk_hw_register_mux_table(NULL, "pll48",
> + pll48_parents, ARRAY_SIZE(pll48_parents), 0,
> + base + STM32F4_RCC_DCKCFGR, 27, 1, 0, NULL,
> + &stm32f4_clk_lock);
> +
> + clk_hw_register_mux_table(NULL, "sdmux",
> + sdmux_parents, ARRAY_SIZE(sdmux_parents), 0,
> + base + STM32F4_RCC_DCKCFGR, 28, 1, 0, NULL,
> + &stm32f4_clk_lock);
> + }
> +
> of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
> return;
> fail:
>
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Peter Griffin @ 2016-11-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103213703.GA15449@tuxbot>
Hi Bjorn,
On Thu, 03 Nov 2016, Bjorn Andersson wrote:
> On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote:
>
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> >
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> >
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> >
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> > drivers/remoteproc/Kconfig | 7 +-
> > drivers/remoteproc/Makefile | 1 +
> > drivers/remoteproc/st_slim_rproc.c | 364 +++++++++++++++++++++++++++++++
> > include/linux/remoteproc/st_slim_rproc.h | 58 +++++
> > 4 files changed, 428 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/remoteproc/st_slim_rproc.c
> > create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index f396bfe..9270c8e 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -58,7 +58,6 @@ config DA8XX_REMOTEPROC
> > tristate "DA8xx/OMAP-L13x remoteproc support"
> > depends on ARCH_DAVINCI_DA8XX
> > select CMA if MMU
> > - select REMOTEPROC
>
> No, this is an unrelated change to this patch.
Sorry that crept in as part of the rebase. Will fix.
>
> > select RPMSG_VIRTIO
> > help
> > Say y here to support DA8xx/OMAP-L13x remote processors via the
> > @@ -99,10 +98,10 @@ config QCOM_WCNSS_PIL
> > tristate "Qualcomm WCNSS Peripheral Image Loader"
> > depends on OF && ARCH_QCOM
> > depends on QCOM_SMEM
> > + depends on REMOTEPROC
> > select QCOM_MDT_LOADER
> > select QCOM_SCM
> > select QCOM_WCNSS_IRIS
> > - select REMOTEPROC
>
> Dito.
Will fix.
>
>
> 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.
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.
>
> > help
> > Say y here to support the Peripheral Image Loader for the Qualcomm
> > Wireless Connectivity Subsystem.
> > @@ -116,4 +115,8 @@ config ST_REMOTEPROC
> > processor framework.
> > This can be either built-in or a loadable module.
> >
> > +config ST_SLIM_REMOTEPROC
> > + tristate
> > + select REMOTEPROC
> > +
> > endmenu
> [..]
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> [..]
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > + char *fw_name)
> > +{
> [..]
> > + rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > + fw_name, sizeof(*slim_rproc));
> [..]
> > + rproc_put(rproc);
>
> As of v4.9 you need to rproc_free() rather than rproc_put() to undo
> rproc_alloc().
Will fix.
regards,
Peter.
^ permalink raw reply
* [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Daniel Thompson @ 2016-11-07 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-4-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds post dividers of I2S & SAI PLLs.
> These dividers are managed by a dedicated register (RCC_DCKCFGR).
> The PLL should be off before a set rate.
> This patch also introduces the lcd-tft clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index dda15bc..5fa5d51 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
> enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> + CLK_LCD,
> END_PRIMARY_CLK
> };
>
> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const char *name,
> static const struct clk_div_table pll_divp_table[] = {
> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
> };
> +static const struct clk_div_table pll_lcd_div_table[] = {
> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
> +};
>
> /*
> * Decode current PLL state and (statically) model the state we inherit from
> @@ -659,16 +663,35 @@ static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
> 16, 2, 0, pll_divp_table, pll_hw, lock);
>
> - if (data->q_name)
> + if (data->q_name) {
> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
> pll_hw, lock);
>
> - if (data->r_name)
> + if (data->pll_num == PLL_I2S)
> + clk_register_pll_div("plli2s-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> +
> + if (data->pll_num == PLL_SAI)
> + clk_register_pll_div("pllsai-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> + }
Shouldn't this be in the config structures?
It seems very odd to me to allow the config structures to control
whether we take the branch or not and then add these hard coded hacks.
Daniel.
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-07 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d60df94d-8f42-12eb-af55-2fc839c126bc@linaro.org>
Hi Daniel,
Thanks for reviewing.
On 11/07/2016 02:53 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch introduces PLL_I2S and PLL_SAI.
>> Vco clock of these PLLs can be modify by DT (only n multiplicator,
>> m divider is still fixed by the boot-loader).
>> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 371
>> ++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 359 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index c2661e2..7641acd 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -28,6 +28,7 @@
> > ...
>> +static const struct clk_div_table pll_divp_table[] = {
>> + { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
>> +};
>> +
>> /*
>> * Decode current PLL state and (statically) model the state we
>> inherit from
>> * the bootloader.
>> */
>
> This comment isn't right. For a start the model is no longer static.
>
you're right, i will suppress it.
>
>> @@ -615,18 +944,24 @@ struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> int gates_num;
>> + const struct stm32f4_pll_data *pll_data;
>> + int pll_num;
>
> pll_num is unused.
>
ok
BR
Gabriel
>
> Daniel.
^ permalink raw reply
* [PATCH v2] staging: vc04_services: add vchiq_pagelist_info structure
From: Michael Zoran @ 2016-11-07 14:06 UTC (permalink / raw)
To: linux-arm-kernel
The current dma_map_sg based implementation for bulk messages
computes many offsets into a single allocation multiple times in
both the create and free code paths. This is inefficient,
error prone and in fact still has a few lingering issues
with arm64.
This change replaces a small portion of that inplementation with
new code that uses a new struct vchiq_pagelist_info to store the
needed information rather then complex offset calculations.
This improved implementation should be more efficient and easier
to understand and maintain.
Tests Run(Both Pass):
vchiq_test -p 1
vchiq_test -f 10
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
.../interface/vchiq_arm/vchiq_2835_arm.c | 223 +++++++++++----------
1 file changed, 113 insertions(+), 110 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 1499a96..2b500d8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -62,6 +62,18 @@ typedef struct vchiq_2835_state_struct {
VCHIQ_ARM_STATE_T arm_state;
} VCHIQ_2835_ARM_STATE_T;
+struct vchiq_pagelist_info {
+ PAGELIST_T *pagelist;
+ size_t pagelist_buffer_size;
+ dma_addr_t dma_addr;
+ enum dma_data_direction dma_dir;
+ unsigned int num_pages;
+ unsigned int pages_need_release;
+ struct page **pages;
+ struct scatterlist *scatterlist;
+ unsigned int scatterlist_mapped;
+};
+
static void __iomem *g_regs;
static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
static unsigned int g_fragments_size;
@@ -77,13 +89,13 @@ static DEFINE_SEMAPHORE(g_free_fragments_mutex);
static irqreturn_t
vchiq_doorbell_irq(int irq, void *dev_id);
-static int
+static struct vchiq_pagelist_info *
create_pagelist(char __user *buf, size_t count, unsigned short type,
- struct task_struct *task, PAGELIST_T **ppagelist,
- dma_addr_t *dma_addr);
+ struct task_struct *task);
static void
-free_pagelist(dma_addr_t dma_addr, PAGELIST_T *pagelist, int actual);
+free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
+ int actual);
int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
{
@@ -224,29 +236,27 @@ VCHIQ_STATUS_T
vchiq_prepare_bulk_data(VCHIQ_BULK_T *bulk, VCHI_MEM_HANDLE_T memhandle,
void *offset, int size, int dir)
{
- PAGELIST_T *pagelist;
- int ret;
- dma_addr_t dma_addr;
+ struct vchiq_pagelist_info *pagelistinfo;
WARN_ON(memhandle != VCHI_MEM_HANDLE_INVALID);
- ret = create_pagelist((char __user *)offset, size,
- (dir == VCHIQ_BULK_RECEIVE)
- ? PAGELIST_READ
- : PAGELIST_WRITE,
- current,
- &pagelist,
- &dma_addr);
+ pagelistinfo = create_pagelist((char __user *)offset, size,
+ (dir == VCHIQ_BULK_RECEIVE)
+ ? PAGELIST_READ
+ : PAGELIST_WRITE,
+ current);
- if (ret != 0)
+ if (!pagelistinfo)
return VCHIQ_ERROR;
bulk->handle = memhandle;
- bulk->data = (void *)(unsigned long)dma_addr;
+ bulk->data = (void *)(unsigned long)pagelistinfo->dma_addr;
- /* Store the pagelist address in remote_data, which isn't used by the
- slave. */
- bulk->remote_data = pagelist;
+ /*
+ * Store the pagelistinfo address in remote_data,
+ * which isn't used by the slave.
+ */
+ bulk->remote_data = pagelistinfo;
return VCHIQ_SUCCESS;
}
@@ -255,8 +265,8 @@ void
vchiq_complete_bulk(VCHIQ_BULK_T *bulk)
{
if (bulk && bulk->remote_data && bulk->actual)
- free_pagelist((dma_addr_t)(unsigned long)bulk->data,
- (PAGELIST_T *)bulk->remote_data, bulk->actual);
+ free_pagelist((struct vchiq_pagelist_info *)bulk->remote_data,
+ bulk->actual);
}
void
@@ -344,6 +354,25 @@ vchiq_doorbell_irq(int irq, void *dev_id)
return ret;
}
+static void
+cleaup_pagelistinfo(struct vchiq_pagelist_info *pagelistinfo)
+{
+ if (pagelistinfo->scatterlist_mapped) {
+ dma_unmap_sg(g_dev, pagelistinfo->scatterlist,
+ pagelistinfo->num_pages, pagelistinfo->dma_dir);
+ }
+
+ if (pagelistinfo->pages_need_release) {
+ unsigned int i;
+
+ for (i = 0; i < pagelistinfo->num_pages; i++)
+ put_page(pagelistinfo->pages[i]);
+ }
+
+ dma_free_coherent(g_dev, pagelistinfo->pagelist_buffer_size,
+ pagelistinfo->pagelist, pagelistinfo->dma_addr);
+}
+
/* There is a potential problem with partial cache lines (pages?)
** at the ends of the block when reading. If the CPU accessed anything in
** the same line (page?) then it may have pulled old data into the cache,
@@ -352,52 +381,64 @@ vchiq_doorbell_irq(int irq, void *dev_id)
** cached area.
*/
-static int
+static struct vchiq_pagelist_info *
create_pagelist(char __user *buf, size_t count, unsigned short type,
- struct task_struct *task, PAGELIST_T **ppagelist,
- dma_addr_t *dma_addr)
+ struct task_struct *task)
{
PAGELIST_T *pagelist;
+ struct vchiq_pagelist_info *pagelistinfo;
struct page **pages;
u32 *addrs;
unsigned int num_pages, offset, i, k;
int actual_pages;
- unsigned long *need_release;
size_t pagelist_size;
struct scatterlist *scatterlist, *sg;
int dma_buffers;
- int dir;
+ dma_addr_t dma_addr;
offset = ((unsigned int)(unsigned long)buf & (PAGE_SIZE - 1));
num_pages = (count + offset + PAGE_SIZE - 1) / PAGE_SIZE;
pagelist_size = sizeof(PAGELIST_T) +
- (num_pages * sizeof(unsigned long)) +
- sizeof(unsigned long) +
+ (num_pages * sizeof(u32)) +
(num_pages * sizeof(pages[0]) +
- (num_pages * sizeof(struct scatterlist)));
-
- *ppagelist = NULL;
-
- dir = (type == PAGELIST_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ (num_pages * sizeof(struct scatterlist))) +
+ sizeof(struct vchiq_pagelist_info);
/* Allocate enough storage to hold the page pointers and the page
** list
*/
pagelist = dma_zalloc_coherent(g_dev,
pagelist_size,
- dma_addr,
+ &dma_addr,
GFP_KERNEL);
vchiq_log_trace(vchiq_arm_log_level, "create_pagelist - %pK",
pagelist);
if (!pagelist)
- return -ENOMEM;
+ return NULL;
+
+ addrs = pagelist->addrs;
+ pages = (struct page **)(addrs + num_pages);
+ scatterlist = (struct scatterlist *)(pages + num_pages);
+ pagelistinfo = (struct vchiq_pagelist_info *)
+ (scatterlist + num_pages);
- addrs = pagelist->addrs;
- need_release = (unsigned long *)(addrs + num_pages);
- pages = (struct page **)(addrs + num_pages + 1);
- scatterlist = (struct scatterlist *)(pages + num_pages);
+ pagelist->length = count;
+ pagelist->type = type;
+ pagelist->offset = offset;
+
+ /* Populate the fields of the pagelistinfo structure */
+ pagelistinfo->pagelist = pagelist;
+ pagelistinfo->pagelist_buffer_size = pagelist_size;
+ pagelistinfo->dma_addr = dma_addr;
+ pagelistinfo->dma_dir = (type == PAGELIST_WRITE) ?
+ DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ pagelistinfo->num_pages = num_pages;
+ pagelistinfo->pages_need_release = 0;
+ pagelistinfo->pages = pages;
+ pagelistinfo->scatterlist = scatterlist;
+ pagelistinfo->scatterlist_mapped = 0;
if (is_vmalloc_addr(buf)) {
unsigned long length = count;
@@ -415,7 +456,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
length -= bytes;
off = 0;
}
- *need_release = 0; /* do not try and release vmalloc pages */
+ /* do not try and release vmalloc pages */
} else {
down_read(&task->mm->mmap_sem);
actual_pages = get_user_pages(
@@ -438,19 +479,13 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
actual_pages--;
put_page(pages[actual_pages]);
}
- dma_free_coherent(g_dev, pagelist_size,
- pagelist, *dma_addr);
- if (actual_pages == 0)
- actual_pages = -ENOMEM;
- return actual_pages;
+ cleaup_pagelistinfo(pagelistinfo);
+ return NULL;
}
- *need_release = 1; /* release user pages */
+ /* release user pages */
+ pagelistinfo->pages_need_release = 1;
}
- pagelist->length = count;
- pagelist->type = type;
- pagelist->offset = offset;
-
/*
* Initialize the scatterlist so that the magic cookie
* is filled if debugging is enabled
@@ -463,15 +498,15 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
dma_buffers = dma_map_sg(g_dev,
scatterlist,
num_pages,
- dir);
+ pagelistinfo->dma_dir);
if (dma_buffers == 0) {
- dma_free_coherent(g_dev, pagelist_size,
- pagelist, *dma_addr);
-
- return -EINTR;
+ cleaup_pagelistinfo(pagelistinfo);
+ return NULL;
}
+ pagelistinfo->scatterlist_mapped = 1;
+
/* Combine adjacent blocks for performance */
k = 0;
for_each_sg(scatterlist, sg, dma_buffers, i) {
@@ -503,11 +538,8 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
char *fragments;
if (down_interruptible(&g_free_fragments_sema) != 0) {
- dma_unmap_sg(g_dev, scatterlist, num_pages,
- DMA_BIDIRECTIONAL);
- dma_free_coherent(g_dev, pagelist_size,
- pagelist, *dma_addr);
- return -EINTR;
+ cleaup_pagelistinfo(pagelistinfo);
+ return NULL;
}
WARN_ON(g_free_fragments == NULL);
@@ -521,42 +553,28 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
(fragments - g_fragments_base) / g_fragments_size;
}
- *ppagelist = pagelist;
-
- return 0;
+ return pagelistinfo;
}
static void
-free_pagelist(dma_addr_t dma_addr, PAGELIST_T *pagelist, int actual)
+free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
+ int actual)
{
- unsigned long *need_release;
- struct page **pages;
- unsigned int num_pages, i;
- size_t pagelist_size;
- struct scatterlist *scatterlist;
- int dir;
+ unsigned int i;
+ PAGELIST_T *pagelist = pagelistinfo->pagelist;
+ struct page **pages = pagelistinfo->pages;
+ unsigned int num_pages = pagelistinfo->num_pages;
vchiq_log_trace(vchiq_arm_log_level, "free_pagelist - %pK, %d",
- pagelist, actual);
-
- dir = (pagelist->type == PAGELIST_WRITE) ? DMA_TO_DEVICE :
- DMA_FROM_DEVICE;
-
- num_pages =
- (pagelist->length + pagelist->offset + PAGE_SIZE - 1) /
- PAGE_SIZE;
+ pagelistinfo->pagelist, actual);
- pagelist_size = sizeof(PAGELIST_T) +
- (num_pages * sizeof(unsigned long)) +
- sizeof(unsigned long) +
- (num_pages * sizeof(pages[0]) +
- (num_pages * sizeof(struct scatterlist)));
-
- need_release = (unsigned long *)(pagelist->addrs + num_pages);
- pages = (struct page **)(pagelist->addrs + num_pages + 1);
- scatterlist = (struct scatterlist *)(pages + num_pages);
-
- dma_unmap_sg(g_dev, scatterlist, num_pages, dir);
+ /*
+ * NOTE: dma_unmap_sg must be called before the
+ * cpu can touch any of the data/pages.
+ */
+ dma_unmap_sg(g_dev, pagelistinfo->scatterlist,
+ pagelistinfo->num_pages, pagelistinfo->dma_dir);
+ pagelistinfo->scatterlist_mapped = 0;
/* Deal with any partial cache lines (fragments) */
if (pagelist->type >= PAGELIST_READ_WITH_FRAGMENTS) {
@@ -594,27 +612,12 @@ free_pagelist(dma_addr_t dma_addr, PAGELIST_T *pagelist, int actual)
up(&g_free_fragments_sema);
}
- if (*need_release) {
- unsigned int length = pagelist->length;
- unsigned int offset = pagelist->offset;
-
- for (i = 0; i < num_pages; i++) {
- struct page *pg = pages[i];
-
- if (pagelist->type != PAGELIST_WRITE) {
- unsigned int bytes = PAGE_SIZE - offset;
-
- if (bytes > length)
- bytes = length;
-
- length -= bytes;
- offset = 0;
- set_page_dirty(pg);
- }
- put_page(pg);
- }
+ /* Need to mark all the pages dirty. */
+ if (pagelist->type != PAGELIST_WRITE &&
+ pagelistinfo->pages_need_release) {
+ for (i = 0; i < num_pages; i++)
+ set_page_dirty(pages[i]);
}
- dma_free_coherent(g_dev, pagelist_size,
- pagelist, dma_addr);
+ cleaup_pagelistinfo(pagelistinfo);
}
--
2.10.2
^ permalink raw reply related
* [PATCH 2/6] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Gabriel Fernandez @ 2016-11-07 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45a332b6-5170-9ae3-8d5e-c5f827c3edea@linaro.org>
Hi Daniel,
On 11/07/2016 02:55 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
>> from pll-sai-p.
>>
>> The SDIO clock could be also derived from 48Mhz or from sys clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index 7641acd..dda15bc 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -199,7 +199,7 @@ struct stm32f4_gate_data {
>> { STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
>> - { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
>> + { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
>
> I'm confused. How do the "sdmux" clock come to exist on STM32F429?
>
"sdmux" only exist on STM32F469 (struct stm32f4_gate_data stm32f469_gates[])
BR
Gabriel
>
>> { STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
>> @@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct
>> device *dev, const char *name,
>> "no-clock", "lse", "lsi", "hse-rtc"
>> };
>>
>> +static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
>> +
>> +static const char *sdmux_parents[2] = { "pll48", "sys" };
>> +
>> struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> @@ -1109,6 +1113,18 @@ static void __init stm32f4_rcc_init(struct
>> device_node *np)
>> goto fail;
>> }
>>
>> + if (of_device_is_compatible(np, "st,stm32f469-rcc")) {
>> + clk_hw_register_mux_table(NULL, "pll48",
>> + pll48_parents, ARRAY_SIZE(pll48_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 27, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> +
>> + clk_hw_register_mux_table(NULL, "sdmux",
>> + sdmux_parents, ARRAY_SIZE(sdmux_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 28, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> + }
>> +
>> of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
>> return;
>> fail:
>>
>
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107132854.GF12559@ulmo.ba.sec>
On 07/11/16 13:28, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>> no OTG-enabled connector.
>>
>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>> ---
>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Where is this information coming from? I don't have one of the Nyans
> myself, but one of the Tegra132 devices I have, which I think was
> derived from one of the Nyans uses one of the external host ports as
> forced recovery port, for which it would need OTG.
>
> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> In that case I think one of the ports must be OTG.
It is true that the port on the back on the nyan-big can be used with
recovery mode. I was thinking that this is not a true OTG port as it is
just a 4-pin type A socket and does not have an ID pin. Thinking some
more about this the USB spec does include a "Host Negotiation Protocol
(HNP)" that allows a host and device to swap roles and so keeping it as
OTG seems valid afterall.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 3/3] ARM: gr8: evb: Add i2s codec
From: Chen-Yu Tsai @ 2016-11-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d99da31af41b26d9109113e19223ee8b88f76ae.1478524066.git-series.maxime.ripard@free-electrons.com>
On Mon, Nov 7, 2016 at 9:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The GR8-EVB comes with a wm8978 codec connected to the i2s bus.
>
> Add a card in order to have it working
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/boot/dts/ntc-gr8-evb.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ntc-gr8-evb.dts b/arch/arm/boot/dts/ntc-gr8-evb.dts
> index 12b4317a4383..5291e425caf9 100644
> --- a/arch/arm/boot/dts/ntc-gr8-evb.dts
> +++ b/arch/arm/boot/dts/ntc-gr8-evb.dts
> @@ -76,6 +76,20 @@
> default-brightness-level = <8>;
> };
>
> + i2s {
"sound" might be a better node name? The I2S controllers are also named "i2s".
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "gr8-evb-wm8978";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,mclk-fs = <512>;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s0>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&wm8978>;
> + };
> + };
>
> panel {
> compatible = "allwinner,sun4i-a10-sub-evb-5-lcd";
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEqLBRknDAKQu1641BEd_MKe42hYx+Jz8FcASZvC1dn6+yazxg@mail.gmail.com>
Hi Sean,
On Thu, Nov 03, 2016 at 03:11:26PM -0600, Sean Paul wrote:
> On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Russell,
> >
> > On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote:
> >> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> >> > The first one is that this overscanning should be reported by the
> >> > connector I guess? but this is really TV specific, so we need one way
> >> > to let the user tell how the image is displayed on its side, and we
> >> > cannot really autodetect it, and this needs to be done at runtime so
> >> > that we can present some shiny interface to let it select which
> >> > overscan ratio works for him/her.
> >>
> >> See xbmc... they go through a nice shiny setup which includes adjusting
> >> the visible area. From what I remember, it has pointers on each corner
> >> which you can adjust to be just visible on the screen, so xbmc knows
> >> how much overscan there is, and xbmc itself reduces down to the user
> >> set size.
> >
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
> >
> > We might not have a GPU in the system, and we might not even have an
> > entire graphic stack on top either, so I don't think fixing at the
> > user-space level is a good option (especially since we already have an
> > overscan property in DRM).
> >
>
> Hi Maxime,
> I took a quick look at the first 2 patches in the series and they look
> good at first glance. I have them in my queue to review more
> carefully.
Yes, the first one is pretty scary.
If it can ease your review, I made a bunch of unittests to test that
code. It's pretty hacky (basically a copy of some kernel structures
and the new logic to parse the command line), but it should test it
with a significant number of cases:
http://code.bulix.org/4lnlk7-107122?raw
It's pretty straightforward to compile, you just have to link against
cmocka.
> Can you explain why you can't fix this by specifying a new mode with
> big porches (as Russell suggested)?
I'll reply to his mail.
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/20161107/f6460e69/attachment.sig>
^ permalink raw reply
* [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Gabriel Fernandez @ 2016-11-07 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <860ce6a2-066f-2b44-3cf5-2d73720ed588@linaro.org>
Hi Daniel,
On 11/07/2016 02:58 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch adds post dividers of I2S & SAI PLLs.
>> These dividers are managed by a dedicated register (RCC_DCKCFGR).
>> The PLL should be off before a set rate.
>> This patch also introduces the lcd-tft clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index dda15bc..5fa5d51 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
>> enum {
>> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
>> PLL_VCO_I2S, PLL_VCO_SAI,
>> + CLK_LCD,
>> END_PRIMARY_CLK
>> };
>>
>> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const
>> char *name,
>> static const struct clk_div_table pll_divp_table[] = {
>> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
>> };
>> +static const struct clk_div_table pll_lcd_div_table[] = {
>> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
>> +};
>>
>> /*
>> * Decode current PLL state and (statically) model the state we
>> inherit from
>> @@ -659,16 +663,35 @@ static struct clk_hw
>> *stm32f4_rcc_register_pll(const char *pllsrc,
>> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
>> 16, 2, 0, pll_divp_table, pll_hw, lock);
>>
>> - if (data->q_name)
>> + if (data->q_name) {
>> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
>> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
>> pll_hw, lock);
>>
>> - if (data->r_name)
>> + if (data->pll_num == PLL_I2S)
>> + clk_register_pll_div("plli2s-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> +
>> + if (data->pll_num == PLL_SAI)
>> + clk_register_pll_div("pllsai-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> + }
>
> Shouldn't this be in the config structures?
>
> It seems very odd to me to allow the config structures to control
> whether we take the branch or not and then add these hard coded hacks.
>
ok i will put it in the config structure.
BR
Gabriel.
>
> Daniel.
^ permalink raw reply
* [PATCH 4/6] clk: stm32f4: Add I2S clock
From: Daniel Thompson @ 2016-11-07 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-5-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces I2S clock for stm32f4 soc.
> The I2S clock could be derived from an external clock or from pll-i2s
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 5fa5d51..b7cb359 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -216,6 +216,7 @@ enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> CLK_LCD,
> + CLK_I2S,
Sorry, this has just clicked and it applies to most of the other
patches, but adding things to this list effectively extends the clock
bindings (i.e. the list of valid "other" clocks access with a primary
index of 1).
This list if a list of "arbitrary" constants by which DT periphericals
can be linked to specific clocks.
So...
1) If a clock is introduced here we should update the clock binding
documentations.
2) If no peripheral can connect to the clock (because it is internal
to the clock gen logic and peripherals must connect to the gated
version) it should not be included in this enum.
3) I failed to mention this when the four undocumented clocks
(LSI, LSE, HSE_RTC and RTC) were added.
4) I *should* have added a comment explaining the above to the code.
> END_PRIMARY_CLK
> };
>
> @@ -967,6 +968,8 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
>
> static const char *sdmux_parents[2] = { "pll48", "sys" };
>
> +static const char *i2s_parents[2] = { "plli2s-r", NULL };
> +
> struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> @@ -1005,7 +1008,7 @@ struct stm32f4_clk_data {
>
> static void __init stm32f4_rcc_init(struct device_node *np)
> {
> - const char *hse_clk;
> + const char *hse_clk, *i2s_in_clk;
> int n;
> const struct of_device_id *match;
> const struct stm32f4_clk_data *data;
> @@ -1038,6 +1041,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> stm32f4_gate_map = data->gates_map;
>
> hse_clk = of_clk_get_parent_name(np, 0);
> + i2s_in_clk = of_clk_get_parent_name(np, 1);
Again this looks like a change to the DT bindings.
Also does the code work if i2s_in_clk is NULL or as you hoping to get
away with a not-backwards compatible change?
Daniel.
>
> clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
> 16000000, 160000);
> @@ -1053,6 +1057,12 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll(pllsrc,
> &data->pll_data[2], &stm32f4_clk_lock);
>
> + i2s_parents[1] = i2s_in_clk;
> +
> + clks[CLK_I2S] = clk_hw_register_mux_table(NULL, "i2s",
> + i2s_parents, ARRAY_SIZE(i2s_parents), 0,
> + base + STM32F4_RCC_CFGR, 23, 1, 0, NULL,
> + &stm32f4_clk_lock);
> sys_parents[1] = hse_clk;
> clk_register_mux_table(
> NULL, "sys", sys_parents, ARRAY_SIZE(sys_parents), 0,
>
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-07 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2127881.qmAR1XgW9F@wuerfel>
On 07/11/2016 13:26, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
>> From: Tan Xiaojun <tanxiaojun@huawei.com>
>>
>> The Hisilicon Djtag is an independent component which connects
>> with some other components in the SoC by Debug Bus. This driver
>> can be configured to access the registers of connecting components
>> (like L3 cache) during real time debugging.
>
> The formatting of the text seems odd, please remove the leading spaces.
>
My only response is at the bottom (I will not snip the code for early
referencing convenience).
Anurup/Tan can respond to the rest.
>> drivers/soc/Kconfig | 1 +
>> drivers/soc/Makefile | 1 +
>> drivers/soc/hisilicon/Kconfig | 12 +
>> drivers/soc/hisilicon/Makefile | 1 +
>> drivers/soc/hisilicon/djtag.c | 639 ++++++++++++++++++++++++++++++++++++
>> include/linux/soc/hisilicon/djtag.h | 38 +++
>
> Do you expect other drivers to be added that reference this interface?
> If not, or if you are unsure, just put all of it under drivers/perf
> so we don't introduce a global API that has only one user.
>
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/init.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm-generic/delay.h>
>
> Never include files from asm-generic directly except from
> an architecture specific asm/*.h header file.
>
>
>> +DEFINE_IDR(djtag_hosts_idr);
>
> make this static
>
>> +static void djtag_read32_relaxed(void __iomem *regs_base, u32 off, u32 *value)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + *value = readl_relaxed(reg_addr);
>> +}
>> +
>> +static void djtag_write32(void __iomem *regs_base, u32 off, u32 val)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + writel(val, reg_addr);
>> +}
>
> This looks like an odd combination of interfaces.
> Why can the reads be "relaxed" when the writes can not?
>
> Generally speaking, I'd advise to always use non-relaxed accessors
> unless there is a strong performance reason, and in that case there
> should be a comment explaining the use at each of the callers
> of a relaxed accessor.
>
>> + /* ensure the djtag operation is done */
>> + do {
>> + djtag_read32_relaxed(regs_base, SC_DJTAG_MSTR_START_EN_EX, &rd);
>> +
>> + if (!(rd & DJTAG_MSTR_START_EN_EX))
>> + break;
>> +
>> + udelay(1);
>> + } while (timeout--);
>
> This one is obviously not performance critical at all, so use a non-relaxed
> accessor. Same for the other two in this function.
>
> Are these functions ever called from atomic context? If yes, please document
> from what context they can be called, otherwise please consider changing
> the udelay calls into sleeping waits.
>
>> +int hisi_djtag_writel(struct hisi_djtag_client *client, u32 offset, u32 mod_sel,
>> + u32 mod_mask, u32 val)
>> +{
>> + void __iomem *reg_map = client->host->sysctl_reg_map;
>> + unsigned long flags;
>> + int ret = 0;
>> +
>> + spin_lock_irqsave(&client->host->lock, flags);
>> + ret = client->host->djtag_readwrite(reg_map, offset, mod_sel, mod_mask,
>> + true, val, 0, NULL);
>> + if (ret)
>> + pr_err("djtag_writel: error! ret=%d\n", ret);
>> + spin_unlock_irqrestore(&client->host->lock, flags);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hisi_djtag_writel);
>
> That would of course imply changing the spinlock to a mutex here as well.
>
>> +static const struct of_device_id djtag_of_match[] = {
>> + /* for hip05(D02) cpu die */
>> + { .compatible = "hisilicon,hip05-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip05(D02) io die */
>> + { .compatible = "hisilicon,hip05-io-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) cpu die */
>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) io die */
>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) cpu die */
>> + { .compatible = "hisilicon,hip07-cpu-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) io die */
>> + { .compatible = "hisilicon,hip07-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + {},
>> +};
>
> If these are backwards compatible, just mark them as compatible in DT,
> e.g. hip06 can use
>
> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
>
> so you can tell the difference if you need to, but the driver only has to
> list the oldest one here.
>
> What is the difference between the cpu and io djtag interfaces?
>
> I think you can also drop the '(void *)'.
>
>> +static void djtag_register_devices(struct hisi_djtag_host *host)
>> +{
>> + struct device_node *node;
>> + struct hisi_djtag_client *client;
>> +
>> + if (!host->of_node)
>> + return;
>> +
>> + for_each_available_child_of_node(host->of_node, node) {
>> + if (of_node_test_and_set_flag(node, OF_POPULATED))
>> + continue;
>> + client = hisi_djtag_of_register_device(host, node);
>> + list_add(&client->next, &host->client_list);
>> + }
>> +}
>
> Can you explain your thoughts behind creating a new bus type
> and adding the child devices manually rather than using
> platform_device structures with of_platform_populate()?
>
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
>
> Arnd
>
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
driver arch, where we have a host bus adapter and child devices attached
to the bus. The child devices are bus driver devices and have bus
addresses. We think of the djtag as a separate bus, so we are modelling
it as such.
The bus driver offers a simple host interface for clients to read/write
to the djtag bus: bus accesses are hidden from the client, the host
drives the bus.
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
Maybe, not sure.
Cheers,
John
>
> .
>
^ permalink raw reply
* [PATCH 1/6] mfd: max8997: Initialize max8997 register map
From: Javier Martinez Canillas @ 2016-11-07 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-2-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch add regmap initialization to use register map
> in max8997-clk device driver
>
> CC: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Patch looks good to me. Now that the driver uses regmap, I think you should
be able to get rid of drivers/mfd/max8997-irq.c and use the regmap IRQ chip
like is done in most Maxim PMIC MFD drivers.
That can be done as a follow-up of this series though.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
From: Lucas Stach @ 2016-11-07 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C+3rCnpQvonXyDaMmUxsDYAnXRBXrUwbP3AT5TbofSgQ@mail.gmail.com>
Am Montag, den 07.11.2016, 10:15 -0200 schrieb Fabio Estevam:
> Hi Lucas,
>
> On Mon, Nov 7, 2016 at 8:34 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>
> > The problem is definitely present in current mainline Linux. I intent to
> > remove this workaround from the kernel, but we need to make sure that
> > the bootloader properly disables PCIe before jumping to the kernel
> > image.
> >
> > I don't know what the status of this is in U-Boot, but Barebox already
> > does this correctly.
> >
> > Fabio, would you mind to port this coed to U-Boot, or at least check if
> > it does the right thing?
>
> Sure, could you point me to the Barebox fix so I can take a look?
>
Sure,
https://git.pengutronix.de/cgit/barebox/commit/?id=f1da98da2760c21487bbba8f7fb957c843a22896
Regards,
Lucas
^ permalink raw reply
* [PATCH 2/6] dt-bindings: clk: max8997: Add DT binding documentation
From: Javier Martinez Canillas @ 2016-11-07 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-3-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Add Device Tree binding documentation for the clocks
> outputs in the Maxim-8997 Power Management IC.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> CC: linux-clk at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-07 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-2-git-send-email-gabriel.fernandez@st.com>
> +static struct clk_hw *clk_register_pll_div(const char *name,
> + const char *parent_name, unsigned long flags,
> + void __iomem *reg, u8 shift, u8 width,
> + u8 clk_divider_flags, const struct clk_div_table *table,
> + struct clk_hw *pll_hw, spinlock_t *lock)
> +{
> + struct stm32f4_pll_div *pll_div;
> + struct clk_hw *hw;
> + struct clk_init_data init;
> + int ret;
> +
> + /* allocate the divider */
> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
> + if (!pll_div)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &stm32f4_pll_div_ops;
> + init.flags = flags;
Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
should have CLK_SET_RATE_GATE flag and we can get rid of custom
divider ops.
> -static void stm32f4_rcc_register_pll(const char *hse_clk, const char *hsi_clk)
> +
> +static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
> + const struct stm32f4_pll_data *data, spinlock_t *lock)
> {
> - unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
> + struct stm32f4_pll *pll;
> + struct clk_init_data init = { NULL };
> + void __iomem *reg;
> + struct clk_hw *pll_hw;
> + int ret;
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = data->vco_name;
> + init.ops = &stm32f4_pll_gate_ops;
> + init.flags = CLK_IGNORE_UNUSED;
CLK_SET_RATE_GATE here
Moreover why not having VCO as a composite clock from gate and mult ?
According to docs SAI VCO (don't know about I2S ) must be within
certain range so clk_set_rate_range should be somewhere.
^ permalink raw reply
* [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Javier Martinez Canillas @ 2016-11-07 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> CC: linux-clk at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
What kernel version are you basing this on? The Maxim common clock code
is going away for v4.9 and instead the clk-max77686 driver supports both
77686 and 77802 clocks. See commit 8ad313fe4e00 ("clk: max77686: Combine
Maxim max77686 and max77802 driver").
Since the 8997 clock IP looks very similar to 77802 AFAICT, you should
also extend the clk-max77686 driver to have 8997 support.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Adam Ford @ 2016-11-07 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105070043.GA5597@dragon>
On Sat, Nov 5, 2016 at 2:00 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Fri, Nov 04, 2016 at 12:44:21PM -0500, Adam Ford wrote:
>> >> +&iomuxc {
>> >> + imx6qdl-logicpd-baseboard {
>> >> +
>> >
>> > Drop this container node and put the following pinctrl nodes directly
>> > under &iomuxc.
>> >
>>
>> Like the regulators above, if I remove this connector, the system
>> won't boot. I compared both the regulator and the iomuxc containers
>> in this device tree with other imx6q boards, and I seem to be
>> consistent with what other boards are doing.
>
> You might want to rebase the patch to latest mainline like v4.9-rc3 and
> test first.
I rebased on the 4.9-rc4, and the pinmux errors go away, but the
regulators appear to need their own container or I get the following
error:
Warning (reg_format): "reg" property in /regulator-otg-vbus has
invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-h1-vbus has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-3v3 has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-pcie has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Can I leave the the regulator container? This seems consistent with
the other imx6 boards.
adam
>
> Shawn
^ permalink raw reply
* [PATCH 4/6] ARM: dts: Add clock provider specific properties to max8997 node
From: Javier Martinez Canillas @ 2016-11-07 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-5-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch adds a label and #clock-cells property to device node of
> max8997 PMIC to allow using it as a clock provider.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210-origen.dts | 3 ++-
> arch/arm/boot/dts/exynos4210-trats.dts | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index cb3a255..6c7ef4e 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -147,11 +147,12 @@
> pinctrl-0 = <&i2c0_bus>;
> pinctrl-names = "default";
>
> - max8997_pmic at 66 {
> + max8997: max8997_pmic at 66 {
The ePAPR says that the node name should be "somewhat generic, reflecting
the function of the device and not its precise programming model". So I
think this should be instead:
max8997: pmic at 66 {
[...]
> - max8997_pmic at 66 {
> + max8997: max8997_pmic at 66 {
Same here.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 5/6] mfd: max8997: Add max8997-clk name in mfd_cell
From: Javier Martinez Canillas @ 2016-11-07 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-6-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch add max8997-clk in mfd_cell max8997_devs in order to probe
> max8997-clk device driver.
>
> CC: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 6/6] ARM: dts: Extend the S3C RTC node with rtc_src clock
From: Javier Martinez Canillas @ 2016-11-07 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-7-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Extend the S3C RTC node with rtc_src clock so it could be operational.
> The rtc_src clock is provided by MAX8997.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-07 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103095444.GX1041@n2100.armlinux.org.uk>
Hi Russell,
On Thu, Nov 03, 2016 at 09:54:45AM +0000, Russell King - ARM Linux wrote:
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
>
> Well, it will have to be doing a scaling step anyway. If the video
> frame is a different size to the active area, scaling is required
> no matter what. A 576p SD image needs to be scaled up, and a 1080p
> image would need to be scaled down for a 1080p overscanned display
> with a reduced active area to counter the overscanning - no matter
> how you do it.
Yes, except that scaling is not always an option. In my particular
example, there's no scaler after the CRTC, which essentially prevents
it from being used in that use case. Which is also why I ended up
reducing the mode reported to the user.
> For graphics, userspace could add mode(s) with increased porches and
> reduced active area itself to achieve an underscanned display on a
> timing which the display device always overscans - there's no need to
> do that in the kernel, all the APIs are there to be able to do it
> already.
>
> That means your framebuffer will be smaller, but that's the case
> anyway.
Yes, that would be a good idea. But it's not always an option for
applications that would rely on the fbdev emulation (like QT's eglfs),
which would then have no way to change whatever default there is (and
the only one able to know how bad it actually is is the user).
> > > > The second one is that we still need to expose the reduced modes to
> > > > userspace, and not only the displayed size, so that the applications
> > > > know what they must draw on. But I guess this could be adjusted by the
> > > > core too.
> > > >
> > > > In order to work consistently, I think all planes should be adjusted
> > > > that way, so that relative coordinates are from the primary plane
> > > > origin, and not the display origin. But that could be adjusted too by
> > > > the core I guess.
> > >
> > > I'm not sure about that - we want the graphics to be visible, but that
> > > may not be appropriate for an video overlay frame. It's quite common
> > > for (eg) broadcast video to contain dead pixels or other artifacts on
> > > the right hand side, and the broadcast video expects overscan to be
> > > present.
> > >
> > > I know this because I have run my TV with overscan disabled, even for
> > > broadcast TV.
> >
> > I know, but on this particular hardware, composite really is just
> > another video output. There's not even a TV receiver in it, so I don't
> > think we have to worry about it.
>
> Whether or not there's a TV receiver is irrelevant - if you can decode
> broadcast video, then you run into the problem. For example, if you
> plug in a USB DVB stick, stream it across the network, etc.
Good point.
> Remember, you're proposing a generic solution, so making arguments
> about things that are not possible with your specific hardware isn't
> really that relevant to a generic solution.
This is definitely not what I'm proposing. I've been told very early
on that such a generic solution was not even worth working on.
> So, I may want my graphics to appear on an overscanned display such
> that I can see the borders, but I may want the overlaid video to use
> the full active area (including overscan) to hide some of the broadcast
> mess at the edges of the screen.
>
> > > Yea, that's quite sad, "analog" has become a dirty word, but really
> > > this has nothing to do with "analog" at all - there are LCD TVs (and
> > > some monitors) out there which take HDMI signals but refuse to
> > > disable overscan no matter what you do to them if you provide them
> > > with a "broadcast" mode - so the analog excuse is very poor.
> >
> > I'd agree with you, but I was also told to not turn that into a
> > generic code and deal with that in my driver.
>
> I guess whoever told you that was wrong. I used to have a cheap TV
> here which took HDMI, and always overscans broadcast modes, and
> underscans PC modes. No amount of fiddling with various settings
> (either in the TV or AVI frames) changes that.
>
> I've run into that with a _monitor_ that Andrew Hutton has, which has
> a HDMI input - exactly the same thing - 1080p, 720p etc are all
> unconditionally overscanned, 1024x768 etc are all unconditionally
> underscanned and there's nothing that can be done to change it.
>
> The problem is that TVs are at liberty to have this behaviour, so
> the overscaned problem is always going to be there, and each driver
> should not be dealing with it in their own specific ways.
I agree with you, however, without any directions on how to do this,
and willingness to merge this, I don't really see why we would work on
such a generic implementation in the first place.
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/20161107/8a156bb1/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: Propagate error to the caller
From: Maxime Ripard @ 2016-11-07 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107011957.GK3327@joana>
On Mon, Nov 07, 2016 at 10:19:57AM +0900, Gustavo Padovan wrote:
> Hi Christophe,
>
> 2016-11-04 Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>
> > If 'sun4i_layers_init()' returns an error, propagate it instead of
> > returning -EINVAL unconditionally.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > ---
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Applied, 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/20161107/310f8f7b/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Fabio Estevam @ 2016-11-07 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xJ=KK-=5sVu0Or5bep-cdk3hq4+a3gFj-W0bCcVhQyWNw@mail.gmail.com>
Hi Adam,
On Mon, Nov 7, 2016 at 1:03 PM, Adam Ford <aford173@gmail.com> wrote:
> I rebased on the 4.9-rc4, and the pinmux errors go away, but the
> regulators appear to need their own container or I get the following
> error:
You can write the regulators without the container as follows:
reg_3p3v: regulator-3p3v {
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
^ 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