* [PATCH] RFC: ARM: fix the uaccess crash on PB11MPCore
From: Neil Armstrong @ 2016-10-17 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYJjxVsUsFUHxhy5dgjkCvYRHFRfqJwyireysMRbrLwRg@mail.gmail.com>
On 09/12/2016 03:36 PM, Linus Walleij wrote:
> On Fri, Sep 9, 2016 at 9:57 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 07/11/2016 07:08 PM, Linus Walleij wrote:
>
>>> The following patch was sketched by Russell in response to my
>>> crashes on the PB11MPCore after the patch for software-based
>>> priviledged no access support for ARMv8.1. See this thread:
>>> http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2
>>>
>>> I am unsure what is going on, I suspect everyone involved in
>>> the discussion is. I just want to repost this to get the
>>> discussion restarted, as I still have to apply this patch
>>> with every kernel iteration to get my PB11MPCore Realview
>>> running.
>>>
>>> I also know that Oxnas has actual, mass-deployed NAS (PogoPlug
>>> Pro variants) using PB11MPCore, and that they may or may not
>>> be seeing the same issue so I want their feedback on this: do
>>> you or do you not see this with mainline, or have you not even
>>> tested?
>>>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Neil Armstrong <narmstrong@baylibre.com>
>>> Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> arch/arm/kernel/smp_tlb.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>
>> Hi Linus, Russell, Arnd,
>>
>> I made a quick port ox OX820 over v4.8-rc4 and when enabling CONFIG_CPU_SW_DOMAIN_PAN
>> I get the following trace at boot time :
>> [ 1.690000] Unable to handle kernel paging request at virtual address b6f23684
>> [ 1.690000] Unable to handle kernel paging request at virtual address b6f95ef4
>> [ 1.690000] pgd = c281c000
>> [ 1.690000] [b6f95ef4] *pgd=62821831, *pte=00000000, *ppte=00000000
>> [ 1.690000] Internal error: Oops: 81f [#1] SMP ARM
>> [ 1.690000] Modules linked in:
>> [ 1.690000] CPU: 1 PID: 65 Comm: mount Not tainted 4.8.0-rc4-00001-g0e9c45d-dirty #22
>> [ 1.690000] Hardware name: Generic DT based system
>> [ 1.690000] task: c2aad860 task.stack: c2814000
>> [ 1.690000] PC is at ipi_flush_tlb_page+0x34/0x44
>> [ 1.690000] LR is at on_each_cpu_mask+0x58/0x60
>> [ 1.690000] pc : [<c010d3dc>] lr : [<c017d584>] psr: 20000193
>> [ 1.690000] sp : c2815da0 ip : 00000002 fp : 00067c40
>> [ 1.690000] r10: c0702744 r9 : 67c4079f r8 : 67c9e75f
>> [ 1.690000] r7 : c2815dbc r6 : c010d3a8 r5 : c2816164 r4 : 20000113
>> [ 1.690000] r3 : 00000000 r2 : b6f95003 r1 : 00000003 r0 : 00000003
>> [ 1.690000] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
>> [ 1.690000] Control: 00c5787d Table: 6281c00a DAC: 00000051
>> [ 1.690000] Process mount (pid: 65, stack limit = 0xc2814190)
>> [ 1.690000] Stack: (0xc2815da0 to 0xc2816000)
>> [...]
>> [ 1.690000] ---[ end trace 8f1207a6d611da09 ]---
>>
>> When applying this patch, it solved the issue.
>>
>> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
>
> So this problem appears on all ARM11MPcore, not just the RealView.
>
> Yours,
> Linus Walleij
>
Hi Russell,
Is there a plan to push this fix as it appears to break the Realview platform and the OX820 I am currently pushing ?
Thanks,
Neil
^ permalink raw reply
* [PATCH v4 2/8] scpi: Add alternative legacy structures, functions and macros
From: Neil Armstrong @ 2016-10-17 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7bf3b68c-19aa-85c3-8b20-66b7380eaf3f@arm.com>
On 10/10/2016 04:36 PM, Sudeep Holla wrote:
> Hi Neil,
>
> Sorry, I could not reply to your response on v3. Anyways I will review v4.
>
> On 05/10/16 08:33, Neil Armstrong wrote:
>> This patch adds support for the Legacy SCPI protocol in early JUNO versions and
>> shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this
>> version of protocol with extended vendor commands
>> .
>> In order to support the legacy SCPI protocol variant, add back the structures
>> and macros that varies against the final specification.
>> Then add indirection table for legacy commands.
>> Finally Add bitmap field for channel selection since the Legacy protocol mandates to
>> send a selected subset of the commands on the high priority channel instead of the
>> low priority channel.
>>
>> The message sending path differs from the final SCPI procotocol because the
>> Amlogic SCP firmware always reply 1 instead of a special value containing the command
>> byte and replied rx data length.
>> For this reason commands queuing cannot be used and we assume the reply command is
>> the head of the rx_pending list since we ensure sequential command sending with a
>> separate dedicated mutex.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/firmware/arm_scpi.c | 221 +++++++++++++++++++++++++++++++++++++++-----
>> 1 file changed, 199 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>> index 498afa0..6244eb1 100644
>> --- a/drivers/firmware/arm_scpi.c
>> +++ b/drivers/firmware/arm_scpi.c
>
> [...]
>
>> @@ -307,21 +398,46 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
>> return;
>> }
>>
>> - list_for_each_entry(t, &ch->rx_pending, node)
>> - if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>> - list_del(&t->node);
>> - match = t;
>> - break;
>> - }
>> + /* Command type is not replied by the SCP Firmware in legacy Mode
>> + * We should consider that command is the head of pending RX commands
>> + * if the list is not empty. In TX only mode, the list would be empty.
>> + */
>> + if (scpi_info->is_legacy) {
>> + match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
>> + node);
>> + list_del(&match->node);
>> + } else {
>> + list_for_each_entry(t, &ch->rx_pending, node)
>> + if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>> + list_del(&t->node);
>> + match = t;
>> + break;
>> + }
>> + }
>> /* check if wait_for_completion is in progress or timed-out */
>> if (match && !completion_done(&match->done)) {
>> - struct scpi_shared_mem *mem = ch->rx_payload;
>> - unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
>> + unsigned int len;
>> +
>> + if (scpi_info->is_legacy) {
>> + struct legacy_scpi_shared_mem *mem = ch->rx_payload;
>> +
>> + /* RX Length is not replied by the lagcy Firmware */
>> + len = match->rx_len;
>> +
>> + match->status = le32_to_cpu(mem->status);
>> + memcpy_fromio(match->rx_buf, mem->payload, len);
>
> The above 2 seems common to both, no ?
No, the shared_mem structure differs.
>
>> + } else {
>> + struct scpi_shared_mem *mem = ch->rx_payload;
>> +
>> + len = min(match->rx_len, CMD_SIZE(cmd));
>> +
>> + match->status = le32_to_cpu(mem->status);
>> + memcpy_fromio(match->rx_buf, mem->payload, len);
>> + }
>>
>> - match->status = le32_to_cpu(mem->status);
>> - memcpy_fromio(match->rx_buf, mem->payload, len);
>> if (match->rx_len > len)
>> memset(match->rx_buf + len, 0, match->rx_len - len);
>> +
>
> Spurious ?
Yep
>
>> complete(&match->done);
>> }
>> spin_unlock_irqrestore(&ch->rx_lock, flags);
>> @@ -331,7 +447,12 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
>> {
>> struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
>> struct scpi_shared_mem *mem = ch->rx_payload;
>> - u32 cmd = le32_to_cpu(mem->command);
>> + u32 cmd;
>> +
>> + if (scpi_info->is_legacy)
>> + cmd = *(u32 *)msg;
>
> Do we need do this if it doesn't contain command ?
No, will remove.
>
>> + else
>> + cmd = le32_to_cpu(mem->command);
>>
>> scpi_process_cmd(ch, cmd);
>> }
>> @@ -343,17 +464,26 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
>> struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
>> struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
>>
>> - if (t->tx_buf)
>> - memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>> + if (t->tx_buf) {
>> + if (scpi_info->is_legacy)
>> + memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
>> + else
>> + memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>> + }
>> +
>> if (t->rx_buf) {
>> if (!(++ch->token))
>> ++ch->token;
>> ADD_SCPI_TOKEN(t->cmd, ch->token);
>> + if (scpi_info->is_legacy)
>> + t->slot = t->cmd;
>
> I thought passing token was not an issue from your previous response,
> but you are overriding it here, why ?
Indeed, I can leave it, but it's useless since it won't serve to distinguish multiple similar commands.
>
>> spin_lock_irqsave(&ch->rx_lock, flags);
>> list_add_tail(&t->node, &ch->rx_pending);
>> spin_unlock_irqrestore(&ch->rx_lock, flags);
>> }
>> - mem->command = cpu_to_le32(t->cmd);
>> +
>> + if (!scpi_info->is_legacy)
>> + mem->command = cpu_to_le32(t->cmd);
>> }
>>
>> static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
>> @@ -396,21 +526,37 @@ static int scpi_send_message(unsigned int offset, void *tx_buf,
>>
>> cmd = scpi_info->scpi_cmds[offset];
>>
>> - chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
>> + if (scpi_info->is_legacy)
>> + chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
>> + else
>> + chan = atomic_inc_return(&scpi_info->next_chan) %
>> + scpi_info->num_chans;
>> scpi_chan = scpi_info->channels + chan;
>>
>> msg = get_scpi_xfer(scpi_chan);
>> if (!msg)
>> return -ENOMEM;
>>
>> - msg->slot = BIT(SCPI_SLOT);
>> - msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
>> + if (scpi_info->is_legacy) {
>> + msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
>> + msg->slot = msg->cmd;
>> + } else {
>> + msg->slot = BIT(SCPI_SLOT);
>> + msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
>> + }
>> msg->tx_buf = tx_buf;
>> msg->tx_len = tx_len;
>> msg->rx_buf = rx_buf;
>> msg->rx_len = rx_len;
>> init_completion(&msg->done);
>>
>> + /* Since we cannot distinguish the original command in the
>> + * MHU reply stat value from a Legacy SCP firmware, ensure
>> + * sequential command sending to the firmware.
>> + */
>
> OK this comment now questions the existence of this extra lock.
> The mailbox will always send the commands in the sequential order.
> It's only firmware that can re-order the response. Since that can't
> happen in you case, I really don't see the need for this.
>
> Please explain the race you would see without this locking. Yes I
> understand that only one command is supposed to be sent to firmware at a
> time. Suppose you allow more callers here, all will wait on the
> completion flags and the first in the list gets unblocked right ?
> I am just trying to understand if there's real need for this extra
> lock when we already have that from the list.
In my current tests I have huge kernel hang when having multiple callers,
I must find out where this issue comes from...
In any case, we have an issue about the command sequencing.
If we push a tx-only command and then right after a tx-rx command, the
mailbox callback from the first command won't be able to distinguish which
command is handled !
In this case, the rx_pending list will not be empty, some garbage will be returned
to the second command handler and the real data from the second command handling
will be lost thinking it's a tx-only command.
We have two choices here :
- Also push the tx-only commands to the rx_pending list, and also wait for their completion
- Add an extra lock
What is your preferred scheme ?
>> + if (scpi_info->is_legacy)
>> + mutex_lock(&scpi_chan->legacy_lock);
>> +
>> ret = mbox_send_message(scpi_chan->chan, msg);
>> if (ret < 0 || !rx_buf)
>> goto out;
>> @@ -421,9 +567,13 @@ static int scpi_send_message(unsigned int offset, void *tx_buf,
>> /* first status word */
>> ret = msg->status;
>> out:
>> - if (ret < 0 && rx_buf) /* remove entry from the list if timed-out */
>> + if (ret < 0 && rx_buf)
>> + /* remove entry from the list if timed-out */
>> scpi_process_cmd(scpi_chan, msg->cmd);
>>
>> + if (scpi_info->is_legacy)
>> + mutex_unlock(&scpi_chan->legacy_lock);
>> +
>> put_scpi_xfer(msg, scpi_chan);
>> /* SCPI error codes > 0, translate them to Linux scale*/
>> return ret > 0 ? scpi_to_linux_errno(ret) : ret;
>
> [...]
>
>> @@ -525,7 +687,6 @@ static struct scpi_dvfs_info *scpi_dvfs_get_info(u8 domain)
>>
>> info->count = DVFS_OPP_COUNT(buf.header);
>> info->latency = DVFS_LATENCY(buf.header) * 1000; /* uS to nS */
>> -
>
> Spurious ?
Indeed.
>
>> info->opps = kcalloc(info->count, sizeof(*opp), GFP_KERNEL);
>> if (!info->opps) {
>> kfree(info);
>> @@ -580,9 +741,13 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
>>
>> ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
>> &buf, sizeof(buf));
>> - if (!ret)
>> - *val = (u64)le32_to_cpu(buf.hi_val) << 32 |
>> - le32_to_cpu(buf.lo_val);
>> + if (!ret) {
>> + if (scpi_info->is_legacy)
>> + *val = (u64)le32_to_cpu(buf.lo_val);
>> + else
>> + *val = (u64)le32_to_cpu(buf.hi_val) << 32 |
>> + le32_to_cpu(buf.lo_val);
>> + }
>
> Not required as I have mentioned couple of times in previous versions,
> it's zero filled by the driver.
>
OK
I will fix the issues, but I need your advice for the locking scheme. I really want this
to be merged and be able to go forward !
Thanks,
Neil
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Adrian Hunter @ 2016-10-17 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bed26dc-f4c1-7f0d-36b6-d7d5fcbf0da9@marvell.com>
On 13/10/16 08:38, Ziji Hu wrote:
> Hi Adrian,
>
> On 2016/10/12 21:07, Adrian Hunter wrote:
>> On 12/10/16 14:58, Ziji Hu wrote:
>>> Hi Adrian,
>>>
>>> Thank you very much for your review.
>>> I will firstly fix the typo.
>>>
>>> On 2016/10/11 20:37, Adrian Hunter wrote:
> <snip>
>>>>> +
>>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>>> + struct mmc_ios *ios)
>>>>> +{
>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>> +
>>>>> + /*
>>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>>> + * clock in mmc_set_signal_voltage().
>>>>> + * If Internal clock is disabled, the 3.3V/1.8V bit can not be updated.
>>>>> + * Thus here manually enable internal clock.
>>>>> + *
>>>>> + * After switch completes, it is unnecessary to disable internal clock,
>>>>> + * since keeping internal clock active obeys SD spec.
>>>>> + */
>>>>> + enable_xenon_internal_clk(host);
>>>>> +
>>>>> + if (priv->card_candidate) {
>>>>
>>>> mmc_power_up() calls __mmc_set_signal_voltage() calls
>>>> host->ops->start_signal_voltage_switch so priv->card_candidate could be an
>>>> invalid reference to an old card.
>>>>
>>>> So that's not going to work if the card changes - not only for removable
>>>> cards but even for eMMC if init fails and retries.
>>>>
>>> As you point out, this piece of code have defects, even though it actually works on Marvell multiple platforms, unless eMMC card is removable.
>>>
>>> I can add a property to explicitly indicate eMMC type in DTS.
>>> Then card_candidate access can be removed here.
>>> Does it sounds more reasonable to you?
>>
>> Sure
>>
>>>
>>>>> + if (mmc_card_mmc(priv->card_candidate))
>>>>> + return xenon_emmc_signal_voltage_switch(mmc, ios);
>>>>
>>>> So if all you need to know is whether it is a eMMC, why can't DT tell you?
>>>>
>>> I can add an eMMC type property in DTS, to remove the card_candidate access here.
>>>
>>>>> + }
>>>>> +
>>>>> + return sdhci_start_signal_voltage_switch(mmc, ios);
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * After determining which slot is used for SDIO,
>>>>> + * some additional task is required.
>>>>> + */
>>>>> +static void xenon_init_card(struct mmc_host *mmc, struct mmc_card *card)
>>>>> +{
>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>> + u32 reg;
>>>>> + u8 slot_idx;
>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>> +
>>>>> + /* Link the card for delay adjustment */
>>>>> + priv->card_candidate = card;
>>>>
>>>> You really need a better way to get the card. I suggest you take up the
>>>> issue with Ulf. One possibility is to have mmc core set host->card = card
>>>> much earlier.
>>>>
>>> Could you please tell me if any issue related to card_candidate still exists, after the card_candidate is removed from xenon_start_signal_voltage_switch() in above?
>>> It seems that when init_card is called, the structure card has already been updated and stable in MMC/SD/SDIO initialization sequence.
>>> May I keep it here?
>>
>> It works by accident rather than by design. We can do better.
>>
> Could you please tell me some details which are satisfied about card_candidate?
>
> I must admit that card_candidate in xenon_start_signal_voltage_switch() is imperfect.
> But card_candidate in init_card() and later in set_ios() work by design, rather than by accident. We did a lot of tests on several platforms.
>
> The structure mmc_card passed in here is a stable one. Thus in my very own opinion, it is safe and stable to use mmc_card here.
> card_candidate is used only in card initialization. It is not active in later transfers after initialization is done.
> It will always updated with mmc_card in next card initialization.
Ok, so maybe just add some comments and more explanation of how it works.
>
>>>
>>>>> + /* Set tuning functionality of this slot */
>>>>> + xenon_slot_tuning_setup(host);
>>>>> +
>>>>> + slot_idx = priv->slot_idx;
>>>>> + if (!mmc_card_sdio(card)) {
>>>>> + /* Re-enable the Auto-CMD12 cap flag. */
>>>>> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>> + host->flags |= SDHCI_AUTO_CMD12;
>>>>> +
>>>>> + /* Clear SDIO Card Inserted indication */
>>>>> + reg = sdhci_readl(host, SDHC_SYS_CFG_INFO);
>>>>> + reg &= ~(1 << (slot_idx + SLOT_TYPE_SDIO_SHIFT));
>>>>> + sdhci_writel(host, reg, SDHC_SYS_CFG_INFO);
>>>>> +
>>>>> + if (mmc_card_mmc(card)) {
>>>>> + mmc->caps |= MMC_CAP_NONREMOVABLE;
>>>>> + if (!(host->quirks2 & SDHCI_QUIRK2_NO_1_8_V))
>>>>> + mmc->caps |= MMC_CAP_1_8V_DDR;
>>>>> + /*
>>>>> + * Force to clear BUS_TEST to
>>>>> + * skip bus_test_pre and bus_test_post
>>>>> + */
>>>>> + mmc->caps &= ~MMC_CAP_BUS_WIDTH_TEST;
>>>>> + mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ |
>>>>> + MMC_CAP2_PACKED_CMD;
>>>>> + if (mmc->caps & MMC_CAP_8_BIT_DATA)
>>>>> + mmc->caps2 |= MMC_CAP2_HS400_1_8V;
>>>>> + }
>>>>> + } else {
>>>>> + /*
>>>>> + * Delete the Auto-CMD12 cap flag.
>>>>> + * Otherwise, when sending multi-block CMD53,
>>>>> + * Driver will set Transfer Mode Register to enable Auto CMD12.
>>>>> + * However, SDIO device cannot recognize CMD12.
>>>>> + * Thus SDHC will time-out for waiting for CMD12 response.
>>>>> + */
>>>>> + host->quirks &= ~SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>> + host->flags &= ~SDHCI_AUTO_CMD12;
>>>>
>>>> sdhci_set_transfer_mode() won't enable auto-CMD12 for CMD53 anyway, so is
>>>> this needed?
>>>>
>>> In Xenon driver, Auto-CMD12 flag is set to enable full support to Auto-CMD feature, both Auto-CMD12 and Auto-CMD23.
>>> As a result, when Xenon SDHC slot can both support SD and SDIO, Auto-CMD12 is disabled when SDIO card is inserted, and renabled when SD is inserted.
>>>
>>> I recheck the sdhci code to set Auto-CMD bit in Transfer Mode register, in sdhci_set_transfer_mode():
>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1)
>>> As you can see, as long as it is CMD18/CMD25 OR there are multiple data blocks, Auto-CMD field will be set.
>>> CMD53 doesn't have CMD23. Thus Auto-CMD12 is selected since Auto-CMD12 flag is set.
>>> Thus I have to clear Auto-CMD12 to avoid issuing Auto-CMD12 in SDIO transfer.
>>
>>
>> The code is:
>>
>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1) {
>> mode = SDHCI_TRNS_BLK_CNT_EN | SDHCI_TRNS_MULTI;
>> /*
>> * If we are sending CMD23, CMD12 never gets sent
>> * on successful completion (so no Auto-CMD12).
>> */
>> if (sdhci_auto_cmd12(host, cmd->mrq) &&
>> (cmd->opcode != SD_IO_RW_EXTENDED))
>> mode |= SDHCI_TRNS_AUTO_CMD12;
>> else if (cmd->mrq->sbc && (host->flags & SDHCI_AUTO_CMD23)) {
>> mode |= SDHCI_TRNS_AUTO_CMD23;
>> sdhci_writel(host, cmd->mrq->sbc->arg, SDHCI_ARGUMENT2);
>> }
>> }
>>
>> You can see the check for SD_IO_RW_EXTENDED which is CMD53.
>>
> Sorry. I didn't notice CMD53 check was added.
> I introduced this Auto-CMD12 hack since kernel 3.8. It seems that this check is not added in kernel 3.8.
> Thanks for the information. I will remove the Auto-CMD12 hack.
>
>>>
>>> I just meet a similar issue in RPMB.
>>> When Auto-CMD12 flag is set, eMMC RPMB access will trigger Auto-CMD12, since CMD25 is in use.
>>> It will cause RPMB access failed.
>>
>> Can you explain more about the RPMB issue. Doesn't it use CMD23, so CMD12
>> wouldn't be used - auto or manually.
>>
> RPMB go through the MMC ioctl routine.
> Unlike normal data transfer, MMC ioctl for RPMB explicitly issues CMD23. When CMD25 is issued, there is neither data->sbc nor Auto-CMD23.
> As a result, sdhci driver will automatically enable Auto-CMD12 for RPMB CMD25 if Auto-CMD12 flag is set.
OK, so SDHCI should also not allow auto-cmd12 if there is no stop command
i.e. data->stop is null.
>
>>>
>>> One possible solution is to drop Auto-CMD12 support and use Auto-CMD23 only, in Xenon driver.
>>> May I know you opinion, please?
>>
>> I don't use auto-CMD12 because I don't know if it provides any benefit and
>> sdhci does not seem to have implemented Auto CMD12 Error Recovery, although
>> I have never looked at it closely.
>>
> Actually, Auto-CMD23 is always used on our Xenon. Auto-CMD12 is not used at all.
> But since this driver is a general one for all Marvell products, Auto-CMD12 is also supported in case that Auto-CMD23 is not available.
>
>
^ permalink raw reply
* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Felipe Balbi @ 2016-10-17 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476627597.1752.3.camel@mniewoehner.de>
Hi,
Michael Niew?hner <linux@mniewoehner.de> writes:
> Hi Felipe,
> On Fri, 2016-10-07 at 22:26 +0200, Michael Niew?hner wrote:
>> Hi Felipe,
>>
>> On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
>> > Hi,
>> >
>> > Michael Niew?hner <linux@mniewoehner.de> writes:
>> > >
>> > > >
>> > > > The clocks are same across working/non-working.
>> > > > Is it possible to bisect the commit that's causing hang for 4.8x ?
>> > >
>> > >
>> > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
>> > > This patch causes both the hang on reboot and the lsusb hang.
>> >
>> > How to reproduce? Why don't we see this on x86 and TI boards? I'm
>> > guessing this is failed bisection, as I can't see anything in that
>> > commit that would cause reboot hang. Also, that code path is *NOT*
>> > executed when you run lsusb.
>> >
>>
>> I've tested this procedure multiple times to be sure:
>>
>> - checkout?c499ff71, compile, boot the odroid
>> - run lsusb -v => lsusb hangs, can't terminate with ctrl-c
>> - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below)
>> - revert c499ff71, mrproper, compile, boot the odroid
>> - run lsusb -v => shows full output, not hanging
>> - run reboot or poweroff => board powers off / reboots just fine
>>
>>
>> dmesg poweroff not working:
>> ...
>> [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144???????
>> [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...???
>> [??120.769212] systemd-shutdown[1]: Unmounting file systems.????????????????????
>> [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.???????????????
>> [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.?????????????????????
>> [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.101014] systemd-shutdown[1]: All filesystems unmounted.??????????????????
>> [??121.106523] systemd-shutdown[1]: Deactivating swaps.?????????????????????????
>> [??121.111585] systemd-shutdown[1]: All swaps deactivated.??????????????????????
>> [??121.116661] systemd-shutdown[1]: Detaching loop devices.?????????????????????
>> [??121.126395] systemd-shutdown[1]: All loop devices detached.??????????????????
>> [??121.130525] systemd-shutdown[1]: Detaching DM devices.???????????????????????
>> [??121.135824] systemd-shutdown[1]: All DM devices detached.????????????????????
>> [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.?????
>> [??121.171739] systemd-shutdown[1]: Powering off.
>>
>> => at this point removing the sd card would show a message?
>> "removed mmc0" (not sure what the real message was...) so the board is not completely off.
>>
>>
>> dmesg poweroff working:
>> ...
>> [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144???????
>> [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...???
>> [??120.769212] systemd-shutdown[1]: Unmounting file systems.????????????????????
>> [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.???????????????
>> [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.?????????????????????
>> [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)????????????????????
>> [??121.101014] systemd-shutdown[1]: All filesystems unmounted.??????????????????
>> [??121.106523] systemd-shutdown[1]: Deactivating swaps.?????????????????????????
>> [??121.111585] systemd-shutdown[1]: All swaps deactivated.??????????????????????
>> [??121.116661] systemd-shutdown[1]: Detaching loop devices.?????????????????????
>> [??121.126395] systemd-shutdown[1]: All loop devices detached.??????????????????
>> [??121.130525] systemd-shutdown[1]: Detaching DM devices.???????????????????????
>> [??121.135824] systemd-shutdown[1]: All DM devices detached.????????????????????
>> [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.?????
>> [??121.171739] systemd-shutdown[1]: Powering off.
>> [??121.182331] rebo?
>>
>>
>>
>> Best regards
>> Michael Niew?hner
>
>
> I did some more tests with next-20161016. Reverting / commenting out
> one part of your patch "solves" the lsusb hang, the reboot problem
> and also the "debounce failed" message. [1]
> Another "solution" is to call phy_power_off before phy_power_on. [2]
>
> Disclaimer: I have no idea what I was doing ;-) These were just some
> simple trial-and-error attempts that maybe help to find the real
> cause of the problems.
>
> [1]
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 7287a76..5ef589d 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -724,6 +724,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> ? /* Adjust Frame Length */
> ? dwc3_frame_length_adjustment(dwc);
> ?
> +/*
> ? usb_phy_set_suspend(dwc->usb2_phy, 0);
> ? usb_phy_set_suspend(dwc->usb3_phy, 0);
> ? ret = phy_power_on(dwc->usb2_generic_phy);
> @@ -733,6 +734,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> ? ret = phy_power_on(dwc->usb3_generic_phy);
> ? if (ret < 0)
> ? goto err3;
> +*/
> ?
> ? ret = dwc3_event_buffers_setup(dwc);
> ? if (ret) {
>
> [2]
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 7287a76..f6c8e13 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -726,6 +726,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
> ?
> ????????usb_phy_set_suspend(dwc->usb2_phy, 0);
> ????????usb_phy_set_suspend(dwc->usb3_phy, 0);
> +???????phy_power_off(dwc->usb2_generic_phy);
> +???????phy_power_off(dwc->usb3_generic_phy);
This looks like a PHY driver bug to me. Which PHY driver are you using?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/a826b912/attachment-0001.sig>
^ permalink raw reply
* aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
From: Leizhen (ThunderTown) @ 2016-10-17 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8b9f6fc-3a4b-f74a-c930-f500bcc00a1d@redhat.com>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index d3f151cfd4a1..8507703dabe4 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
>> return;
>> }
>> bootcpu_valid = true;
>> + early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
>> return;
>> }
>>
>
> Anyway, your patch works with both the two-node NUMA configuration Drew suggested for testing, and with the single-node config that I originally used for the bisection. Therefore:
>
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
>
> Thank you very much for the quick bugfix! And, I think your patch (when you send it for real) should carry
I'm so sorry about this. My patch series prepared before ACPI NUMA upstreamed, and forgot considering it in later.
>
> Fixes: 7ba5f605f3a0d9495aad539eeb8346d726dfc183
>
> too, because it supplies the cpu#0<->node#xxx association that 7ba5f605f3a0 removed not just for DT, but also for ACPI.
>
> Cheers!
> Laszlo
>
> .
>
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Adrian Hunter @ 2016-10-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bcf4abca-9f2e-6d1b-6690-d672766e18cb@marvell.com>
On 12/10/16 15:17, Ziji Hu wrote:
> Hi Adrian,
>
> On 2016/10/11 20:39, Adrian Hunter wrote:
>> On 07/10/16 18:22, Gregory CLEMENT wrote:
>>> From: Ziji Hu <huziji@marvell.com>
>>>
>>> Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY.
>>> Three types of PHYs are supported.
>>>
>>> Add support to multiple types of PHYs init and configuration.
>>> Add register definitions of PHYs.
>>>
>>> Signed-off-by: Hu Ziji <huziji@marvell.com>
>>> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> ---
>>> MAINTAINERS | 1 +-
>>> drivers/mmc/host/Makefile | 2 +-
>>> drivers/mmc/host/sdhci-xenon-phy.c | 1141 +++++++++++++++++++++++++++++-
>>> drivers/mmc/host/sdhci-xenon-phy.h | 157 ++++-
>>> drivers/mmc/host/sdhci-xenon.c | 4 +-
>>> drivers/mmc/host/sdhci-xenon.h | 17 +-
>>> 6 files changed, 1321 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
>>> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 859420e5dfd3..b5673c2ee5f2 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7583,6 +7583,7 @@ M: Ziji Hu <huziji@marvell.com>
>>> L: linux-mmc at vger.kernel.org
>>> S: Supported
>>> F: drivers/mmc/host/sdhci-xenon.*
>>> +F: drivers/mmc/host/sdhci-xenon-phy.*
>>> F: Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>>>
>>> MATROX FRAMEBUFFER DRIVER
>>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>>> index 75eaf743486c..4f2854556ff7 100644
>>> --- a/drivers/mmc/host/Makefile
>>> +++ b/drivers/mmc/host/Makefile
>>> @@ -82,4 +82,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y)
>>> endif
>>>
>>> obj-$(CONFIG_MMC_SDHCI_XENON) += sdhci-xenon-driver.o
>>> -sdhci-xenon-driver-y += sdhci-xenon.o
>>> +sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy.o
>>> diff --git a/drivers/mmc/host/sdhci-xenon-phy.c b/drivers/mmc/host/sdhci-xenon-phy.c
>>> new file mode 100644
>>> index 000000000000..4eb8fea1bec9
>>> --- /dev/null
>>> +++ b/drivers/mmc/host/sdhci-xenon-phy.c
>>
>> <SNIP>
>>
>>> +static int __xenon_emmc_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + int err;
>>> + u8 *ext_csd = NULL;
>>> +
>>> + err = mmc_get_ext_csd(card, &ext_csd);
>>> + kfree(ext_csd);
>>> +
>>> + return err;
>>> +}
>>> +
>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + struct mmc_command cmd = {0};
>>> + int err;
>>> +
>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>> +
>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>> + if (err)
>>> + return err;
>>> +
>>> + if (cmd.resp[0] & R5_ERROR)
>>> + return -EIO;
>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>> + return -EINVAL;
>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>> + return -ERANGE;
>>> + return 0;
>>> +}
>>> +
>>> +static int __xenon_sd_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + struct mmc_command cmd = {0};
>>> + int err;
>>> +
>>> + cmd.opcode = MMC_SEND_STATUS;
>>> + cmd.arg = card->rca << 16;
>>> + cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>> +
>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>> + return err;
>>> +}
>>> +
>>> +static int xenon_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + WARN_ON(!card);
>>> + WARN_ON(!card->host);
>>> +
>>> + if (mmc_card_mmc(card))
>>> + return __xenon_emmc_delay_adj_test(card);
>>> + else if (mmc_card_sd(card))
>>> + return __xenon_sd_delay_adj_test(card);
>>> + else if (mmc_card_sdio(card))
>>> + return __xenon_sdio_delay_adj_test(card);
>>> + else
>>> + return -EINVAL;
>>> +}
>>
>> So you are issuing commands from the ->set_ios() callback. I would want to
>> get Ulf's OK for that before going further.
>>
> Yes, you are correct.
> In some speed mode, Xenon SDHC has to send a series of transfers to search for a perfect sampling point in PHY delay line.
> It is like tuning process.
>
>> One thing: you will need to ensure you don't trigger get HS400 re-tuning
>> because it will call back into ->set_ios().
>>
> Could you please make the term "HS400 re-tuning" more detailed?
> In current MMC driver, "HS400 re-tuning" will go back to HS200, execute HS200 tuning and come back to HS400.
> I'm sure our Xenon SDHC will not execute it.
Currently, re-tuning is automatically enabled whenever tuning is executed,
and then re-tuning will be done periodically or after CRC errors. The
function to disable re-tuning mmc_retune_disable() is not exported, however
if you have you are determining the sampling point your own way, you could
simply not implement ->execute_tuning() and then there would be no tuning
and no re-tuning.
>
> However, in coming eMMC 5.2, there is a real HS400 re-tuning, in which tuning can be directly executed in HS400 mode.
> Our Xenon SDHC will neither trigger this HS400 re-tuning.
> But since so far there is no such feature in MMC driver, I cannot give you a 100% guarantee now.
>
>> And you have the problem that you need to get a reference to the card before
>> the card device has been added. As I wrote in response to the previous
>> patch, you should get Ulf's help with that too.
>>
> Sure.
> I will get card_candidate solved at first.
> Thank you again for your review and help.
>
> Thank you.
>
> Best regards,
> Hu Ziji
>>
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Tomi Valkeinen @ 2016-10-17 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65fde145-0820-794d-d345-621f66cdacc0@ti.com>
On 17/10/16 10:12, Sekhar Nori wrote:
> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>> On 15/10/16 20:42, Sekhar Nori wrote:
>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index f79e1b9..32908ae 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>
>>>> @@ -399,6 +420,14 @@
>>>> <&edma0 0 1>;
>>>> dma-names = "tx", "rx";
>>>> };
>>>> +
>>>> + display: display at 213000 {
>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>
>>> This should instead be:
>>>
>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>
>>> as the closest match should appear first in the list.
>>
>> Actually I don't think that's correct. The LCDC on da850 is not
>> compatible with the LCDC on AM335x. I think it should be just
>> "ti,da850-tilcdc".
>
> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
> the case, I wonder how the patch passed testing. Bartosz?
AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
similar, but different.
The driver gets the version number from LCDC's register, and acts based
on that, so afaik the compatible string doesn't really affect the
functionality (as long as it matches).
But even if it works with the current driver, I don't think
"ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/b6ff5ea1/attachment.sig>
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Ulf Hansson @ 2016-10-17 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476467276-75094-1-git-send-email-lina.iyer@linaro.org>
On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
> Hi all,
>
> Changes since v2 [3] -
> - Addressed review comments from v2.
> - domain-idle-states documentation updated
> - fixed compiler issues with imx driver
> - minor code change in pm_domains.c
> - The series is available at [4].
>
> Changes since v1 [2] -
> - Addressed review comments from v1.
> - Fixes around dynamic allocation of genpd states
> - Used OF method for iterating phandles
> - Updated documentation, examples
> - Rename state variable (provider -> fwnode)
> - The series is available at [3].
>
> The changes from [1] are -
> - Allocating memory for domain idle states dynamically
> - Conform to naming conventions for internal and exported genpd functions
> - DT binding example for domain-idle-state
> - Use fwnode instead of of_node
> - Handle atomic case for removal of PM Domain
> - Rebase on top of Rafael's pm/genpd tree
>
> Thanks,
> Lina
>
> Lina Iyer (8):
> PM / Domains: Make genpd state allocation dynamic
> PM / Domain: Add residency property to genpd states
> PM / Domains: Allow domain power states to be read from DT
> PM / Domains: Save the fwnode in genpd_power_state
> dt/bindings: Update binding for PM domain idle states
> PM / Domains: Abstract genpd locking
> PM / Domains: Support IRQ safe PM domains
> PM / doc: Update device documentation for devices in IRQ safe PM
> domains
>
> .../devicetree/bindings/power/power_domain.txt | 43 +++
> Documentation/power/devices.txt | 9 +-
> arch/arm/mach-imx/gpc.c | 17 +-
> drivers/base/power/domain.c | 358 +++++++++++++++++----
> include/linux/pm_domain.h | 28 +-
> 5 files changed, 383 insertions(+), 72 deletions(-)
>
Rafael, Lina,
This looks good to me! Unless any other objections, I suggest to apply
this to get it tested in linux-next.
Kind regards
Uffe
> --
> 2.7.4
>
> [1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
> [2]. http://www.spinics.net/lists/arm-kernel/msg535106.html
> [3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v2
> [4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v3
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-10-17 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65fde145-0820-794d-d345-621f66cdacc0@ti.com>
2016-10-17 9:12 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>> On 15/10/16 20:42, Sekhar Nori wrote:
>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index f79e1b9..32908ae 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>
>>>> @@ -399,6 +420,14 @@
>>>> <&edma0 0 1>;
>>>> dma-names = "tx", "rx";
>>>> };
>>>> +
>>>> + display: display at 213000 {
>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>
>>> This should instead be:
>>>
>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>
>>> as the closest match should appear first in the list.
>>
>> Actually I don't think that's correct. The LCDC on da850 is not
>> compatible with the LCDC on AM335x. I think it should be just
>> "ti,da850-tilcdc".
>
> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
> the case, I wonder how the patch passed testing. Bartosz?
>
DA850 uses revision 1 of the IP while am33xx is equipped with rev 2.
The driver reads the appropriate register, detects the revision and
sets the corresponding field in struct tilcdc_drm_private in
tilcdc_load().
Thanks,
Bartosz
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-17 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1e23c3e9-d34b-1d8f-8565-c9932a60fd32@ti.com>
On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
> On 15/10/16 20:42, Sekhar Nori wrote:
>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index f79e1b9..32908ae 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>
>>> @@ -399,6 +420,14 @@
>>> <&edma0 0 1>;
>>> dma-names = "tx", "rx";
>>> };
>>> +
>>> + display: display at 213000 {
>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>
>> This should instead be:
>>
>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>
>> as the closest match should appear first in the list.
>
> Actually I don't think that's correct. The LCDC on da850 is not
> compatible with the LCDC on AM335x. I think it should be just
> "ti,da850-tilcdc".
So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
the case, I wonder how the patch passed testing. Bartosz?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-10-17 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12cfb59f-f7ca-d4df-eb7f-42348e357979@samsung.com>
Resending, missed out on the link last time.
>-----Original Message-----
From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-owner at vger.kernel.org] On Behalf Of Marek Szyprowski
>Sent: Monday, October 10, 2016 6:07 PM
>To: Sricharan R <sricharan@codeaurora.org>; will.deacon at arm.com; robin.murphy at arm.com; joro at 8bytes.org; iommu at lists.linux-
>foundation.org; linux-arm-kernel at lists.infradead.org; linux-arm-msm at vger.kernel.org; laurent.pinchart at ideasonboard.com;
>tfiga at chromium.org; srinivas.kandagatla at linaro.org
>Subject: Re: [PATCH V3 0/8] IOMMU probe deferral support
>
>Hi Sricharan,
>
>
>On 2016-10-04 19:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>>
>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> | |
>> pci_bus_add_device (device_add/driver_register)
>> | |
>> device_attach device_initial_probe
>> | |
>> __device_attach_driver __device_attach_driver
>> |
>> driver_probe_device
>> |
>> really_probe
>> |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver
>> is
>> called which inturn calls dma_deconfigure.
>>
>> If the ACPI bus code follows the same, we can add acpi_dma_configure
>> at the same place as of_dma_configure.
>>
>> This series is based on the recently merged Generic DT bindings for
>> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>>
>> This time tested this with platform and pci device for probe deferral
>> and reprobe on arm64 based platform. There is an issue on the cleanup
>> path for arm64 though, where there is WARN_ON if the dma_ops is reset
>> while
>> device is attached to an domain in arch_teardown_dma_ops.
>> But with iommu_groups created from the iommu driver, the device is
>> always
>> attached to a domain/default_domain. So so the WARN has to be
>> removed/handled
>> probably.
>
>Thanks for continuing work on this feature! Your can add my:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
Hi Will,Robin,Joerg,
I have tested the probe deferral for platform/pcie bus devices based on latest Generic DT bindings
series merged [1], for pci/arm-smmu.
It will be good to know from you on whats the right way to take this forward ?
[1] http://www.spinics.net/lists/devicetree/msg142943.html
Regards,
Sricharan
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-10-17 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12cfb59f-f7ca-d4df-eb7f-42348e357979@samsung.com>
>-----Original Message-----
>From: Sricharan [mailto:sricharan at codeaurora.org]
>Sent: Wednesday, October 12, 2016 11:55 AM
>To: 'Marek Szyprowski' <m.szyprowski@samsung.com>; 'will.deacon at arm.com' <will.deacon@arm.com>; 'robin.murphy at arm.com'
><robin.murphy@arm.com>; 'joro at 8bytes.org' <joro@8bytes.org>; 'iommu at lists.linux-foundation.org' <iommu@lists.linux-
>foundation.org>; 'linux-arm-kernel at lists.infradead.org' <linux-arm-kernel@lists.infradead.org>; 'linux-arm-msm at vger.kernel.org'
><linux-arm-msm@vger.kernel.org>; 'laurent.pinchart at ideasonboard.com' <laurent.pinchart@ideasonboard.com>;
>'tfiga at chromium.org' <tfiga@chromium.org>; 'srinivas.kandagatla at linaro.org' <srinivas.kandagatla@linaro.org>
>Subject: RE: [PATCH V3 0/8] IOMMU probe deferral support
>
>Hi Marek,
>
>>Hi Sricharan,
>>
>>
>>On 2016-10-04 19:03, Sricharan R wrote:
>>> Initial post from Laurent Pinchart[1]. This is
>>> series calls the dma ops configuration for the devices
>>> at a generic place so that it works for all busses.
>>> The dma_configure_ops for a device is now called during
>>> the device_attach callback just before the probe of the
>>> bus/driver is called. Similarly dma_deconfigure is called during
>>> device/driver_detach path.
>>>
>>>
>>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>>> | |
>>> pci_bus_add_device (device_add/driver_register)
>>> | |
>>> device_attach device_initial_probe
>>> | |
>>> __device_attach_driver __device_attach_driver
>>> |
>>> driver_probe_device
>>> |
>>> really_probe
>>> |
>>> dma_configure
>>>
>>> Similarly on the device/driver_unregister path __device_release_driver is
>>> called which inturn calls dma_deconfigure.
>>>
>>> If the ACPI bus code follows the same, we can add acpi_dma_configure
>>> at the same place as of_dma_configure.
>>>
>>> This series is based on the recently merged Generic DT bindings for
>>> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>>>
>>> This time tested this with platform and pci device for probe deferral
>>> and reprobe on arm64 based platform. There is an issue on the cleanup
>>> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
>>> device is attached to an domain in arch_teardown_dma_ops.
>>> But with iommu_groups created from the iommu driver, the device is always
>>> attached to a domain/default_domain. So so the WARN has to be removed/handled
>>> probably.
>>
>>Thanks for continuing work on this feature! Your can add my:
>>
>>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
Hi Will,Robin,Joerg,
I have tested the probe deferral for platform/pcie bus devices based on latest Generic bindings
series merged [1], for pci/arm-smmu.
It will good to know from you on whats the right way to take this forward ?
Regards,
Sricharan
^ permalink raw reply
* [STLinux Kernel] [PATCH 28/57] [media] c8sectpfe: don't break long lines
From: Peter Griffin @ 2016-10-17 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b82cb64c6328c81104143d8a509d4ab6f77873a2.1476475771.git.mchehab@s-opensource.com>
On Fri, 14 Oct 2016, Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 15 +++++----------
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Adrian Hunter @ 2016-10-17 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476297352-7812-3-git-send-email-scott.branden@broadcom.com>
On 12/10/16 21:35, Scott Branden wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module
From: maitysanchayan at gmail.com @ 2016-10-17 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921112438.8661-1-maitysanchayan@gmail.com>
Hello,
Ping?
- Sanchayan.
On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 ++++++++
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 890 +++++++++++++++++++++++++++
> 3 files changed, 1144 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-aristainetos_7.dtb \
> imx6dl-aristainetos2_4.dtb \
> imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
> imx6dl-cubox-i.dtb \
> imx6dl-dfi-fs700-m60.dtb \
> imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 0000000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> + "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = &i2c2;
> + i2c1 = &i2c3;
> + };
> +
> + aliases {
> + rtc0 = &rtc_i2c;
> + rtc1 = &snvs_rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk at 1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <16000000>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = <KEY_WAKEUP>;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_lcdif>;
> + status = "okay";
> +
> + port at 0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + panel: panel {
> + /*
> + * edt,et057090dhu: EDT 5.7" LCD TFT
> + * edt,et070080dh6: EDT 7.0" LCD TFT
> + */
> + compatible = "edt,et057090dhu";
> + backlight = <&backlight>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +};
> +
> +&backlight {
> + brightness-levels = <0 127 191 223 239 247 251 255>;
> + default-brightness-level = <1>;
> + status = "okay";
> +};
> +
> +/* Colibri SSP */
> +&ecspi4 {
> + status = "okay";
> +
> + mcp251x0: mcp251x at 1 {
> + compatible = "microchip,mcp2515";
> + reg = <0>;
> + clocks = <&clk16m>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 0x2>;
> + spi-max-frequency = <10000000>;
> + status = "okay";
> + };
> +};
> +
> +&hdmi {
> + status = "okay";
> +};
> +
> +/*
> + * Colibri I2C: I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
> + */
> +&i2c3 {
> + status = "okay";
> +
> + /* M41T0M6 real time clock on carrier board */
> + rtc_i2c: rtc at 68 {
> + compatible = "st,m41t00";
> + reg = <0x68>;
> + };
> +};
> +
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&lcd_display_in>;
> +};
> +
> +&pwm1 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&pwm3 {
> + status = "okay";
> +};
> +
> +&pwm4 {
> + status = "okay";
> +};
> +
> +®_usb_host_vbus {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&usbh1 {
> + vbus-supply = <®_usb_host_vbus>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + status = "okay";
> +};
> +
> +/* Colibri MMC */
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc_cd>;
> + cd-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* MMCD */
> + status = "okay";
> +};
> +
> +&weim {
> + status = "okay";
> +
> + /* weim memory map: 32MB on CS0, 32MB on CS1, 32MB on CS2 */
> + ranges = <0 0 0x08000000 0x02000000
> + 1 0 0x0a000000 0x02000000
> + 2 0 0x0c000000 0x02000000>;
> +
> + /* SRAM on Colibri nEXT_CS0 */
> + sram at 0,0 {
> + compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
> + reg = <0 0 0x00010000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
> + 0x00000000 0x04000040 0x00000000>;
> + };
> +
> + /* SRAM on Colibri nEXT_CS1 */
> + sram at 1,0 {
> + compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
> + reg = <1 0 0x00010000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
> + 0x00000000 0x04000040 0x00000000>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> new file mode 100644
> index 0000000..e6faa65
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> @@ -0,0 +1,890 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S Module";
> + compatible = "toradex,colibri_imx6dl", "fsl,imx6dl";
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_bl_on>;
> + pwms = <&pwm3 0 5000000>;
> + enable-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* Colibri BL_ON */
> + status = "disabled";
> + };
> +
> + reg_1p8v: regulator-1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_2p5v: regulator-2p5v {
> + compatible = "regulator-fixed";
> + regulator-name = "2P5V";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-always-on;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_usb_host_vbus: regulator-usb-host-vbus {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_regulator_usbh_pwr>;
> + regulator-name = "usb_host_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>; /* USBH_PEN */
> + status = "disabled";
> + };
> +
> + sound {
> + compatible = "fsl,imx-audio-sgtl5000";
> + model = "imx6dl-colibri-sgtl5000";
> + ssi-controller = <&ssi1>;
> + audio-codec = <&codec>;
> + audio-routing =
> + "Headphone Jack", "HP_OUT",
> + "LINE_IN", "Line In Jack",
> + "MIC_IN", "Mic Jack",
> + "Mic Jack", "Mic Bias";
> + mux-int-port = <1>;
> + mux-ext-port = <5>;
> + };
> +
> + /* Optional S/PDIF in on SODIMM 88 and out on SODIMM 90, 137 or 168 */
> + sound_spdif: sound-spdif {
> + compatible = "fsl,imx-audio-spdif";
> + model = "imx-spdif";
> + spdif-controller = <&spdif>;
> + spdif-in;
> + spdif-out;
> + status = "disabled";
> + };
> +};
> +
> +&audmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_audmux &pinctrl_mic_gnd>;
> + status = "okay";
> +};
> +
> +/* Optional on SODIMM 55/63 */
> +&can1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "disabled";
> +};
> +
> +/* Optional on SODIMM 178/188 */
> +&can2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "disabled";
> +};
> +
> +/* Colibri SSP */
> +&ecspi4 {
> + fsl,spi-num-chipselects = <1>;
> + cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi4>;
> + status = "disabled";
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi_ddc>;
> + status = "disabled";
> +};
> +
> +/*
> + * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
> + * touch screen controller
> + */
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + pmic: pfuze100 at 08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + /* vgen1: unused */
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + /* vgen3: unused */
> +
> + vgen4_reg: vgen4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + codec: sgtl5000 at 0a {
> + compatible = "fsl,sgtl5000";
> + reg = <0x0a>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + VDDA-supply = <®_2p5v>;
> + VDDIO-supply = <®_3p3v>;
> + };
> +
> + /* STMPE811 touch screen controller */
> + stmpe811 at 41 {
> + compatible = "st,stmpe811";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touch_int>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x41>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-parent = <&gpio6>;
> + interrupt-controller;
> + id = <0>;
> + blocks = <0x5>;
> + irq-trigger = <0x1>;
> +
> + stmpe_touchscreen {
> + compatible = "st,stmpe-ts";
> + reg = <0>;
> + /* 3.25 MHz ADC clock speed */
> + st,adc-freq = <1>;
> + /* 8 sample average control */
> + st,ave-ctrl = <3>;
> + /* 7 length fractional part in z */
> + st,fraction-z = <7>;
> + /*
> + * 50 mA typical 80 mA max touchscreen drivers
> + * current limit value
> + */
> + st,i-drive = <1>;
> + /* 12-bit ADC */
> + st,mod-12b = <1>;
> + /* internal ADC reference */
> + st,ref-sel = <0>;
> + /* ADC converstion time: 80 clocks */
> + st,sample-time = <4>;
> + /* 1 ms panel driver settling time */
> + st,settling = <3>;
> + /* 5 ms touch detect interrupt delay */
> + st,touch-det-delay = <5>;
> + };
> + };
> +};
> +
> +/*
> + * I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
> + */
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default", "recovery";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + pinctrl-1 = <&pinctrl_i2c3_recovery>;
> + scl-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> + sda-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<B> */
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm1>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<D> */
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm2>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<A> */
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<C> */
> +&pwm4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm4>;
> + status = "disabled";
> +};
> +
> +/* Optional S/PDIF out on SODIMM 137 */
> +&spdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spdif>;
> + status = "disabled";
> +};
> +
> +&ssi1 {
> + status = "okay";
> +};
> +
> +/* Colibri UART_A */
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1_dte &pinctrl_uart1_ctrl>;
> + fsl,dte-mode;
> + uart-has-rtscts;
> + status = "disabled";
> +};
> +
> +/* Colibri UART_B */
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2_dte>;
> + fsl,dte-mode;
> + uart-has-rtscts;
> + status = "disabled";
> +};
> +
> +/* Colibri UART_C */
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3_dte>;
> + fsl,dte-mode;
> + status = "disabled";
> +};
> +
> +&usbotg {
> + pinctrl-names = "default";
> + disable-over-current;
> + dr_mode = "peripheral";
> + status = "disabled";
> +};
> +
> +/* Colibri MMC */
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + vqmmc-supply = <®_3p3v>;
> + bus-width = <4>;
> + voltage-ranges = <3300 3300>;
> + status = "disabled";
> +};
> +
> +/* eMMC */
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + vqmmc-supply = <®_3p3v>;
> + bus-width = <8>;
> + voltage-ranges = <3300 3300>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&weim {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_weim_sram &pinctrl_weim_cs0
> + &pinctrl_weim_cs1 &pinctrl_weim_cs2
> + &pinctrl_weim_rdnwr &pinctrl_weim_npwe>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + status = "disabled";
> +};
> +
> +&iomuxc {
> + pinctrl_audmux: audmuxgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
> + MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x130b0
> + MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
> + MX6QDL_PAD_KEY_ROW1__AUD5_RXD 0x130b0
> + /* SGTL5000 sys_mclk */
> + MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x000b0
> + >;
> + };
> +
> + pinctrl_cam_mclk: cammclkgrp {
> + fsl,pins = <
> + /* Parallel Camera CAM sys_mclk */
> + MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x00b0
> + >;
> + };
> +
> + pinctrl_ecspi4: ecspi4grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D22__ECSPI4_MISO 0x100b1
> + MX6QDL_PAD_EIM_D28__ECSPI4_MOSI 0x100b1
> + MX6QDL_PAD_EIM_D21__ECSPI4_SCLK 0x100b1
> + /* SPI CS */
> + MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x000b1
> + >;
> + };
> +
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK ((1<<30) | 0x1b0b0)
> + >;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> + MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> + MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_bl_on: gpioblon {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_keys: gpiokeys {
> + fsl,pins = <
> + /* Power button */
> + MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x1b0b0
> + >;
> + };
> +
> + pinctrl_hdmi_ddc: hdmiddcgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__I2C2_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c3_recovery: i2c3recoverygrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_3__GPIO1_IO03 0x4001b8b1
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_ipu1_csi0: ipu1csi0grp { /* Parallel Camera */
> + fsl,pins = <
> + MX6QDL_PAD_EIM_A17__IPU1_CSI1_DATA12 0xb0b1
> + MX6QDL_PAD_EIM_A18__IPU1_CSI1_DATA13 0xb0b1
> + MX6QDL_PAD_EIM_A19__IPU1_CSI1_DATA14 0xb0b1
> + MX6QDL_PAD_EIM_A20__IPU1_CSI1_DATA15 0xb0b1
> + MX6QDL_PAD_EIM_A21__IPU1_CSI1_DATA16 0xb0b1
> + MX6QDL_PAD_EIM_A22__IPU1_CSI1_DATA17 0xb0b1
> + MX6QDL_PAD_EIM_A23__IPU1_CSI1_DATA18 0xb0b1
> + MX6QDL_PAD_EIM_A24__IPU1_CSI1_DATA19 0xb0b1
> + MX6QDL_PAD_EIM_D17__IPU1_CSI1_PIXCLK 0xb0b1
> + MX6QDL_PAD_EIM_EB3__IPU1_CSI1_HSYNC 0xb0b1
> + MX6QDL_PAD_EIM_D29__IPU1_CSI1_VSYNC 0xb0b1
> + /* Disable PWM pins on camera interface */
> + MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x40
> + MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x40
> + >;
> + };
> +
> + pinctrl_ipu1_lcdif: ipu1lcdifgrp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xa1
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xa1
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0xa1
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0xa1
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xa1
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xa1
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xa1
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xa1
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xa1
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xa1
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xa1
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xa1
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xa1
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xa1
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xa1
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xa1
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xa1
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xa1
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xa1
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xa1
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xa1
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xa1
> + >;
> + };
> +
> + pinctrl_mic_gnd: gpiomicgnd {
> + fsl,pins = <
> + /* Controls Mic GND, PU or '1' pull Mic GND to GND */
> + MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x1b0b0
> + >;
> + };
> +
> + pinctrl_mmc_cd: gpiommccd {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x80000000
> + >;
> + };
> +
> + pinctrl_pwm1: pwm1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
> + >;
> + };
> +
> + pinctrl_pwm2: pwm2grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> + MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x00040
> + >;
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x00040
> + >;
> + };
> +
> + pinctrl_pwm4: pwm4grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
> + >;
> + };
> +
> + pinctrl_regulator_usbh_pwr: gpioregusbhpwrgrp {
> + fsl,pins = <
> + /* USBH_EN */
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x0f058
> + >;
> + };
> +
> + pinctrl_spdif: spdifgrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
> + >;
> + };
> +
> + pinctrl_touch_int: gpiotouchintgrp {
> + fsl,pins = <
> + /* STMPE811 interrupt */
> + MX6QDL_PAD_RGMII_TD0__GPIO6_IO20 0x1b0b0
> + >;
> + };
> +
> + pinctrl_uart1_dce: uart1dcegrp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + /* DTE mode */
> + pinctrl_uart1_dte: uart1dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D19__UART1_RTS_B 0x1b0b1
> + MX6QDL_PAD_EIM_D20__UART1_CTS_B 0x1b0b1
> + >;
> + };
> +
> + /* Additional DTR, DSR, DCD */
> + pinctrl_uart1_ctrl: uart1ctrlgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D23__UART1_DCD_B 0x1b0b0
> + MX6QDL_PAD_EIM_D24__UART1_DTR_B 0x1b0b0
> + MX6QDL_PAD_EIM_D25__UART1_DSR_B 0x1b0b0
> + >;
> + };
> +
> + pinctrl_uart2_dte: uart2dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart3_dte: uart3dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_CLK__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_CMD__UART3_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usbc_det: usbcdetgrp {
> + fsl,pins = <
> + /* USBC_DET */
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
> + /* USBC_DET_EN */
> + MX6QDL_PAD_RGMII_TX_CTL__GPIO6_IO26 0x0f058
> + /* USBC_DET_OVERWRITE */
> + MX6QDL_PAD_RGMII_RXC__GPIO6_IO30 0x0f058
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> + /* eMMC reset */
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> + >;
> + };
> +
> + pinctrl_usdhc3_100mhz: usdhc3100mhzgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170b9
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170b9
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170b9
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170b9
> + /* eMMC reset */
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x170b9
> + >;
> + };
> +
> + pinctrl_usdhc3_200mhz: usdhc3200mhzgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170f9
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170f9
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170f9
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170f9
> + /* eMMC reset */
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x170f9
> + >;
> + };
> +
> + pinctrl_weim_cs0: weimcs0grp {
> + fsl,pins = <
> + /* nEXT_CS0 */
> + MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_cs1: weimcs1grp {
> + fsl,pins = <
> + /* nEXT_CS1 */
> + MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_cs2: weimcs2grp {
> + fsl,pins = <
> + /* nEXT_CS2 */
> + MX6QDL_PAD_SD2_DAT1__EIM_CS2_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_sram: weimsramgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> + MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> + /* Data */
> + MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
> + MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
> + /* Address */
> + MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> + MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> + MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> + MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> + MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> + MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> + MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> + MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> + MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> + MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> + MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> + MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> + MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> + MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> + MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> + MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_rdnwr: weimrdnwr {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CLK__GPIO1_IO10 0x0040
> + MX6QDL_PAD_RGMII_TD3__GPIO6_IO23 0x130b0
> + >;
> + };
> +
> + pinctrl_weim_npwe: weimnpwe {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x0040
> + MX6QDL_PAD_RGMII_TD2__GPIO6_IO22 0x130b0
> + >;
> + };
> +
> + /* ADDRESS[16:18] [25] used as GPIO */
> + pinctrl_weim_gpio_1: weimgpio-1 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
> + MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
> + MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> + >;
> + };
> +
> + /* ADDRESS[19:24] used as GPIO */
> + pinctrl_weim_gpio_2: weimgpio-2 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
> + MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> + >;
> + };
> +
> + /* DATA[16:31] used as GPIO */
> + pinctrl_weim_gpio_3: weimgpio-3 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x1b0b0
> + MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x1b0b0
> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0
> + MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
> + MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x1b0b0
> + MX6QDL_PAD_NANDF_ALE__GPIO6_IO08 0x1b0b0
> + MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x1b0b0
> + MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
> + MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x1b0b0
> + MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
> + MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
> + MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x1b0b0
> + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
> + MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x1b0b0
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + >;
> + };
> +
> + /* DQM[0:3] used as GPIO */
> + pinctrl_weim_gpio_4: weimgpio-4 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x1b0b0
> + MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x1b0b0
> + MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
> + MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> + >;
> + };
> +
> + /* RDY used as GPIO */
> + pinctrl_weim_gpio_5: weimgpio-5 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x1b0b0
> + >;
> + };
> +
> + /* ADDRESS[16] DATA[30] used as GPIO */
> + pinctrl_weim_gpio_6: weimgpio-6 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0
> + >;
> + };
> +};
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH v2] spi: spi-fsl-dspi: Add DMA support for Vybrid
From: maitysanchayan at gmail.com @ 2016-10-17 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <607397542d083f13dc98909958672eeb0d326c79.1475578195.git.maitysanchayan@gmail.com>
Hello,
Ping?
Regards,
Sanchayan.
On 16-10-04 16:28:33, Sanchayan Maity wrote:
> Add DMA support for Vybrid.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> Changes since v1:
> - Change in the dspi_dma_xfer function. Use more apt DSPI_FIFO_SIZE
> instead of sizeof(u32)
> - Do not set RSER on every iteration of loop
>
> Tested on Toradex Colibri Vybrid VF61 module with spi based MCP CAN 251x
> and spidev using RX/TX loopback and based on shawn's for-next branch
> currently at 4.8-rc1.
>
> Regards,
> Sanchayan.
> ---
> drivers/spi/spi-fsl-dspi.c | 291 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 291 insertions(+)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 9e9dadb..0f81075 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -15,6 +15,8 @@
>
> #include <linux/clk.h>
> #include <linux/delay.h>
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
> #include <linux/err.h>
> #include <linux/errno.h>
> #include <linux/interrupt.h>
> @@ -40,6 +42,7 @@
> #define TRAN_STATE_WORD_ODD_NUM 0x04
>
> #define DSPI_FIFO_SIZE 4
> +#define DSPI_DMA_BUFSIZE (DSPI_FIFO_SIZE * 1024)
>
> #define SPI_MCR 0x00
> #define SPI_MCR_MASTER (1 << 31)
> @@ -71,6 +74,11 @@
> #define SPI_SR_EOQF 0x10000000
> #define SPI_SR_TCFQF 0x80000000
>
> +#define SPI_RSER_TFFFE BIT(25)
> +#define SPI_RSER_TFFFD BIT(24)
> +#define SPI_RSER_RFDFE BIT(17)
> +#define SPI_RSER_RFDFD BIT(16)
> +
> #define SPI_RSER 0x30
> #define SPI_RSER_EOQFE 0x10000000
> #define SPI_RSER_TCFQE 0x80000000
> @@ -108,6 +116,8 @@
>
> #define SPI_TCR_TCNT_MAX 0x10000
>
> +#define DMA_COMPLETION_TIMEOUT msecs_to_jiffies(3000)
> +
> struct chip_data {
> u32 mcr_val;
> u32 ctar_val;
> @@ -117,6 +127,7 @@ struct chip_data {
> enum dspi_trans_mode {
> DSPI_EOQ_MODE = 0,
> DSPI_TCFQ_MODE,
> + DSPI_DMA_MODE,
> };
>
> struct fsl_dspi_devtype_data {
> @@ -139,6 +150,22 @@ static const struct fsl_dspi_devtype_data ls2085a_data = {
> .max_clock_factor = 8,
> };
>
> +struct fsl_dspi_dma {
> + u32 curr_xfer_len;
> +
> + u32 *tx_dma_buf;
> + struct dma_chan *chan_tx;
> + dma_addr_t tx_dma_phys;
> + struct completion cmd_tx_complete;
> + struct dma_async_tx_descriptor *tx_desc;
> +
> + u32 *rx_dma_buf;
> + struct dma_chan *chan_rx;
> + dma_addr_t rx_dma_phys;
> + struct completion cmd_rx_complete;
> + struct dma_async_tx_descriptor *rx_desc;
> +};
> +
> struct fsl_dspi {
> struct spi_master *master;
> struct platform_device *pdev;
> @@ -165,6 +192,7 @@ struct fsl_dspi {
> u32 waitflags;
>
> u32 spi_tcnt;
> + struct fsl_dspi_dma *dma;
> };
>
> static inline int is_double_byte_mode(struct fsl_dspi *dspi)
> @@ -368,6 +396,259 @@ static void dspi_tcfq_read(struct fsl_dspi *dspi)
> dspi_data_from_popr(dspi, rx_word);
> }
>
> +static void dspi_tx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> +
> + complete(&dma->cmd_tx_complete);
> +}
> +
> +static void dspi_rx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> + int rx_word;
> + int i, len;
> + u16 d;
> +
> + rx_word = is_double_byte_mode(dspi);
> +
> + len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> + for (i = 0; i < len; i++) {
> + d = dspi->dma->rx_dma_buf[i];
> + rx_word ? (*(u16 *)dspi->rx = d) :
> + (*(u8 *)dspi->rx = d);
> + dspi->rx += rx_word + 1;
> + }
> + }
> +
> + complete(&dma->cmd_rx_complete);
> +}
> +
> +static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = &dspi->pdev->dev;
> + int time_left;
> + int tx_word;
> + int i, len;
> + u16 val;
> +
> + tx_word = is_double_byte_mode(dspi);
> +
> + len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + for (i = 0; i < len - 1; i++) {
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] =
> + SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> + dspi->tx += tx_word + 1;
> + }
> +
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0);
> + dspi->tx += tx_word + 1;
> +
> + dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> + dma->tx_dma_phys,
> + DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> + DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!dma->tx_desc) {
> + dev_err(dev, "Not able to get desc for DMA xfer\n");
> + return -EIO;
> + }
> +
> + dma->tx_desc->callback = dspi_tx_dma_callback;
> + dma->tx_desc->callback_param = dspi;
> + if (dma_submit_error(dmaengine_submit(dma->tx_desc))) {
> + dev_err(dev, "DMA submit failed\n");
> + return -EINVAL;
> + }
> +
> + dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
> + dma->rx_dma_phys,
> + DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!dma->rx_desc) {
> + dev_err(dev, "Not able to get desc for DMA xfer\n");
> + return -EIO;
> + }
> +
> + dma->rx_desc->callback = dspi_rx_dma_callback;
> + dma->rx_desc->callback_param = dspi;
> + if (dma_submit_error(dmaengine_submit(dma->rx_desc))) {
> + dev_err(dev, "DMA submit failed\n");
> + return -EINVAL;
> + }
> +
> + reinit_completion(&dspi->dma->cmd_rx_complete);
> + reinit_completion(&dspi->dma->cmd_tx_complete);
> +
> + dma_async_issue_pending(dma->chan_rx);
> + dma_async_issue_pending(dma->chan_tx);
> +
> + time_left = wait_for_completion_timeout(&dspi->dma->cmd_tx_complete,
> + DMA_COMPLETION_TIMEOUT);
> + if (time_left == 0) {
> + dev_err(dev, "DMA tx timeout\n");
> + dmaengine_terminate_all(dma->chan_tx);
> + dmaengine_terminate_all(dma->chan_rx);
> + return -ETIMEDOUT;
> + }
> +
> + time_left = wait_for_completion_timeout(&dspi->dma->cmd_rx_complete,
> + DMA_COMPLETION_TIMEOUT);
> + if (time_left == 0) {
> + dev_err(dev, "DMA rx timeout\n");
> + dmaengine_terminate_all(dma->chan_tx);
> + dmaengine_terminate_all(dma->chan_rx);
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}
> +
> +static int dspi_dma_xfer(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = &dspi->pdev->dev;
> + int curr_remaining_bytes;
> + int ret = 0;
> +
> + curr_remaining_bytes = dspi->len;
> + while (curr_remaining_bytes) {
> + /* Check if current transfer fits the DMA buffer */
> + dma->curr_xfer_len = curr_remaining_bytes;
> + if (curr_remaining_bytes > DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE)
> + dma->curr_xfer_len = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
> +
> + ret = dspi_next_xfer_dma_submit(dspi);
> + if (ret) {
> + dev_err(dev, "DMA transfer failed\n");
> + goto exit;
> +
> + } else {
> + curr_remaining_bytes -= dma->curr_xfer_len;
> + if (curr_remaining_bytes < 0)
> + curr_remaining_bytes = 0;
> + dspi->len = curr_remaining_bytes;
> + }
> + }
> +
> +exit:
> + return ret;
> +}
> +
> +static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
> +{
> + struct fsl_dspi_dma *dma;
> + struct dma_slave_config cfg;
> + struct device *dev = &dspi->pdev->dev;
> + int ret;
> +
> + dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
> + if (!dma)
> + return -ENOMEM;
> +
> + dma->chan_rx = dma_request_slave_channel(dev, "rx");
> + if (!dma->chan_rx) {
> + dev_err(dev, "rx dma channel not available\n");
> + ret = -ENODEV;
> + return ret;
> + }
> +
> + dma->chan_tx = dma_request_slave_channel(dev, "tx");
> + if (!dma->chan_tx) {
> + dev_err(dev, "tx dma channel not available\n");
> + ret = -ENODEV;
> + goto err_tx_channel;
> + }
> +
> + dma->tx_dma_buf = dma_alloc_coherent(dev, DSPI_DMA_BUFSIZE,
> + &dma->tx_dma_phys, GFP_KERNEL);
> + if (!dma->tx_dma_buf) {
> + ret = -ENOMEM;
> + goto err_tx_dma_buf;
> + }
> +
> + dma->rx_dma_buf = dma_alloc_coherent(dev, DSPI_DMA_BUFSIZE,
> + &dma->rx_dma_phys, GFP_KERNEL);
> + if (!dma->rx_dma_buf) {
> + ret = -ENOMEM;
> + goto err_rx_dma_buf;
> + }
> +
> + cfg.src_addr = phy_addr + SPI_POPR;
> + cfg.dst_addr = phy_addr + SPI_PUSHR;
> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.src_maxburst = 1;
> + cfg.dst_maxburst = 1;
> +
> + cfg.direction = DMA_DEV_TO_MEM;
> + ret = dmaengine_slave_config(dma->chan_rx, &cfg);
> + if (ret) {
> + dev_err(dev, "can't configure rx dma channel\n");
> + ret = -EINVAL;
> + goto err_slave_config;
> + }
> +
> + cfg.direction = DMA_MEM_TO_DEV;
> + ret = dmaengine_slave_config(dma->chan_tx, &cfg);
> + if (ret) {
> + dev_err(dev, "can't configure tx dma channel\n");
> + ret = -EINVAL;
> + goto err_slave_config;
> + }
> +
> + dspi->dma = dma;
> + dspi->devtype_data->trans_mode = DSPI_DMA_MODE;
> + init_completion(&dma->cmd_tx_complete);
> + init_completion(&dma->cmd_rx_complete);
> +
> + return 0;
> +
> +err_slave_config:
> + devm_kfree(dev, dma->rx_dma_buf);
> +err_rx_dma_buf:
> + devm_kfree(dev, dma->tx_dma_buf);
> +err_tx_dma_buf:
> + dma_release_channel(dma->chan_tx);
> +err_tx_channel:
> + dma_release_channel(dma->chan_rx);
> +
> + devm_kfree(dev, dma);
> + dspi->dma = NULL;
> +
> + return ret;
> +}
> +
> +static void dspi_release_dma(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = &dspi->pdev->dev;
> +
> + if (dma) {
> + if (dma->chan_tx) {
> + dma_unmap_single(dev, dma->tx_dma_phys,
> + DSPI_DMA_BUFSIZE, DMA_TO_DEVICE);
> + dma_release_channel(dma->chan_tx);
> + }
> +
> + if (dma->chan_rx) {
> + dma_unmap_single(dev, dma->rx_dma_phys,
> + DSPI_DMA_BUFSIZE, DMA_FROM_DEVICE);
> + dma_release_channel(dma->chan_rx);
> + }
> + }
> +}
> +
> static int dspi_transfer_one_message(struct spi_master *master,
> struct spi_message *message)
> {
> @@ -424,6 +705,12 @@ static int dspi_transfer_one_message(struct spi_master *master,
> regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_TCFQE);
> dspi_tcfq_write(dspi);
> break;
> + case DSPI_DMA_MODE:
> + regmap_write(dspi->regmap, SPI_RSER,
> + SPI_RSER_TFFFE | SPI_RSER_TFFFD |
> + SPI_RSER_RFDFE | SPI_RSER_RFDFD);
> + status = dspi_dma_xfer(dspi);
> + goto out;
> default:
> dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
> trans_mode);
> @@ -730,6 +1017,9 @@ static int dspi_probe(struct platform_device *pdev)
> }
> clk_prepare_enable(dspi->clk);
>
> + if (dspi_request_dma(dspi, res->start))
> + dev_warn(&pdev->dev, "can't get dma channels\n");
> +
> master->max_speed_hz =
> clk_get_rate(dspi->clk) / dspi->devtype_data->max_clock_factor;
>
> @@ -758,6 +1048,7 @@ static int dspi_remove(struct platform_device *pdev)
> struct fsl_dspi *dspi = spi_master_get_devdata(master);
>
> /* Disconnect from the SPI framework */
> + dspi_release_dma(dspi);
> clk_disable_unprepare(dspi->clk);
> spi_unregister_master(dspi->master);
> spi_master_put(dspi->master);
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Tomi Valkeinen @ 2016-10-17 5:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d276e51-9d37-8648-4aad-283bb2b23626@ti.com>
On 15/10/16 20:42, Sekhar Nori wrote:
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>
>> @@ -399,6 +420,14 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + display: display at 213000 {
>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>
> This should instead be:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>
> as the closest match should appear first in the list.
Actually I don't think that's correct. The LCDC on da850 is not
compatible with the LCDC on AM335x. I think it should be just
"ti,da850-tilcdc".
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/a26c6f6e/attachment.sig>
^ permalink raw reply
* [PATCH v8 0/8] power: add power sequence library
From: Peter Chen @ 2016-10-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097336.earU4jV2qd@vostro.rjw.lan>
On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> >
> > Changes for v8:
> > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> > preallocate instances problem which the number of instance is decided at
> > compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
> > match method. [Patch 2/8]
> > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> >
> > Changes for v7:
> > - Create kinds of power sequence instance at postcore_initcall, and match
> > the instance with node using compatible string, the beneit of this is
> > the host driver doesn't need to consider which pwrseq instance needs
> > to be used, and pwrseq core will match it, however, it eats some memories
> > if less power sequence instances are used. [Patch 2/8]
> > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> > use device_node for parameters at pwrseq_on. [Patch 2/8]
> > - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> > - Tested three pwrseq instances together using both specific compatible string and
> > generic libraries.
> >
> > Changes for v6:
> > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > - Applies Joshua Clayton's three dts changes for two boards,
> > the USB device's reg has only #address-cells, but without #size-cells.
> >
> > Changes for v5:
> > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > - Fix the linker error when the pwrseq user is compiled as module
> >
> > Changes for v4:
> > - Create the patch on next-20160722
> > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> > - Using more friendly wait method for reset gpio [Patch 2/6]
> > - Support multiple input clocks [Patch 2/6]
> > - Add Rob Herring's ack for DT changes
> > - Add Joshua Clayton's Tested-by
> >
> > Changes for v3:
> > - Delete "power-sequence" property at binding-doc, and change related code
> > at both library and user code.
> > - Change binding-doc example node name with Rob's comments
> > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> > add additional code request gpio with proper gpio flags
> > - Add Philipp Zabel's Ack and MAINTAINER's entry
> >
> > Changes for v2:
> > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > - Should use structure not but its pointer for kzalloc
> > - Since chipidea core has no of_node, let core's of_node equals glue
> > layer's at core's probe
> >
> > Joshua Clayton (2):
> > ARM: dts: imx6qdl: Enable usb node children with <reg>
> > ARM: dts: imx6q-evi: Fix onboard hub reset line
> >
> > Peter Chen (6):
> > binding-doc: power: pwrseq-generic: add binding doc for generic power
> > sequence library
> > power: add power sequence library
> > binding-doc: usb: usb-device: add optional properties for power
> > sequence
> > usb: core: add power sequence handling for USB devices
> > usb: chipidea: let chipidea core device of_node equal's glue layer
> > device of_node
> > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> >
> > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++++++
> > .../devicetree/bindings/usb/usb-device.txt | 10 +-
> > MAINTAINERS | 9 +
> > arch/arm/boot/dts/imx6q-evi.dts | 25 +--
> > arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-
> > arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> > drivers/power/Kconfig | 1 +
> > drivers/power/Makefile | 1 +
> > drivers/power/pwrseq/Kconfig | 19 ++
> > drivers/power/pwrseq/Makefile | 2 +
> > drivers/power/pwrseq/core.c | 191 +++++++++++++++++++++
> > drivers/power/pwrseq/pwrseq_generic.c | 183 ++++++++++++++++++++
> > drivers/usb/chipidea/core.c | 27 ++-
> > drivers/usb/core/hub.c | 41 ++++-
> > drivers/usb/core/hub.h | 1 +
> > include/linux/power/pwrseq.h | 72 ++++++++
> > 16 files changed, 621 insertions(+), 41 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> > create mode 100644 drivers/power/pwrseq/Kconfig
> > create mode 100644 drivers/power/pwrseq/Makefile
> > create mode 100644 drivers/power/pwrseq/core.c
> > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> > create mode 100644 include/linux/power/pwrseq.h
>
> Meta question: Who's the maintainer you are targetting this at?
>
Sebastian Reichel mentioned it is better through your tree.
I could be the maintainer for it, and send "GIT PULL" for you
through my git
(https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/)
Is it ok for you?
--
Best Regards,
Peter Chen
^ permalink raw reply
* rockchip: drm: analogix_dp-rockchip would stock the kernel
From: Randy Li @ 2016-10-17 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580421E5.9030609@rock-chips.com>
On 10/17/2016 08:57 AM, Mark yao wrote:
> On 2016?10?16? 02:03, ayaka wrote:
>> Hello:
>> I meet a problem with eDP in rk3288 with the linux next 20161006,
>> it is just like the early stage of 4.4
>> kernel. I have added a eDP panel entry in the firefly reload board,
>> once the kernel loaded analogix_dp-rockchip.ko, after printed the
>> following two lines, the kernel stop working.
>> rockchip-drm display-subsystem: bound ff940000.vop (ops
>> vop_component_ops [rockchipdrm])
>> rockchip-drm display-subsystem: bound ff930000.vop (ops
>> vop_component_ops [rockchipdrm])
>
> Hi ayaka
>
> This log seems no problem.
I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a
proper power supply. I would submit a patch to enable the regulator at
DP driver.
>
> How about tested it with build-in? we had test it with build-in.
>
> Maybe this patch can help you, you can have a try.
> https://patchwork.kernel.org/patch/9374135
>
> Thanks.
>
>> In the early June of the 4.4 kernel, I meet the same problem with
>> rk3288 evb board with different error message, I have to disable the
>> display system that time.
>> In the today test, I meet the same problem with rk3399 evb board in
>> 4.4.
>> I have no idea what caused that, and it is a little hard to debug as
>> kernel still would never kill that task.
>> Randy Li
>>
>>
>>
>
>
--
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================
^ permalink raw reply
* rockchip: drm: analogix_dp-rockchip would stock the kernel
From: Mark yao @ 2016-10-17 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>
On 2016?10?16? 02:03, ayaka wrote:
> Hello:
> I meet a problem with eDP in rk3288 with the linux next 20161006,
> it is just like the early stage of 4.4
> kernel. I have added a eDP panel entry in the firefly reload board,
> once the kernel loaded analogix_dp-rockchip.ko, after printed the
> following two lines, the kernel stop working.
> rockchip-drm display-subsystem: bound ff940000.vop (ops
> vop_component_ops [rockchipdrm])
> rockchip-drm display-subsystem: bound ff930000.vop (ops
> vop_component_ops [rockchipdrm])
Hi ayaka
This log seems no problem.
How about tested it with build-in? we had test it with build-in.
Maybe this patch can help you, you can have a try.
https://patchwork.kernel.org/patch/9374135
Thanks.
> In the early June of the 4.4 kernel, I meet the same problem with
> rk3288 evb board with different error message, I have to disable the
> display system that time.
> In the today test, I meet the same problem with rk3399 evb board in
> 4.4.
> I have no idea what caused that, and it is a little hard to debug as
> kernel still would never kill that task.
> Randy Li
>
>
>
--
?ark Yao
^ permalink raw reply
* [PATCH] watchdog: at91sam9: keep watchdog running in idle mode
From: Sylvain Rochet @ 2016-10-16 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59c665f8-de09-c11c-f62a-5064016cd8fd@roeck-us.net>
Hi Guenter,
On Sun, Oct 16, 2016 at 08:55:41AM -0700, Guenter Roeck wrote:
> On 10/16/2016 08:50 AM, Guenter Roeck wrote:
> > On 10/16/2016 08:33 AM, Sylvain Rochet wrote:
> > >
> > > Looks like this one falls through the cracks, it didn't reach mainline
> > > and therefore wasn't applied to stable branches.
> >
> > Possibly that happened because you did not copy the watchdog mailing list.
>
> ... and your other patches were not sent to the watchdog mailing list either,
> so you should not expect them to be picked up either.
>
> Seriously, how do you expect _any_ patch to be picked up if you neither copy
> the subsystem mailing list nor the subsystem maintainer ?
Whoops, thanks for the heads up, I wonder how I managed to mess up that
at that time, I usually take care of that. The other series need
respinning anyway so I can fix it for v2 (if any).
Cheers,
Sylvain
^ permalink raw reply
* RK3288 USB issues with ath9k_htc Wi-Fi dongles on veyron devices
From: Paul Kocialkowski @ 2016-10-16 20:01 UTC (permalink / raw)
To: linux-arm-kernel
I'm trying to use ath9k_htc Wi-Fi dongles with various rk3288 veyron devices,
which currently do not work.
I have a bunch of different dongles, that all work nicely with other devices.
The kernel I'm running is 4.9-rc1 and the USB connectors I'm using are linked to
OTG and HOST1 (both DWC2 controllers).
I have applied the latest version of Randy Li's patches, that fix an USB error
with these controllers. They do not fix my issue, or otherwise change the
behavior I'm seeing. The very same device running with the chromeos-3.14 kernel
works nicely and doesn't have this issue.
There are two different cases, that happen interchangeably and randomly:
1. The dongle is detected and the driver is probed but the first register reads
fail:
[??322.841142] usb 2-1: new high-speed USB device number 3 using dwc2
[??323.104591] usb 2-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[??323.113489] usb 2-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[??323.122204] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested
[??323.414012] usb 2-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[??323.665556] ath9k_htc 2-1:1.0: ath9k_htc: HTC initialized with 33 credits
[??324.710992] ath: phy1: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[??324.717899] ath: phy1: REGISTER READ FAILED: (0x4020, -110)
[??324.723525] ath: phy1: Mac Chip Rev 0x0f.3 is not supported by this driver
[??324.730416] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.737853] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.745296] ath9k_htc: Failed to initialize the device
[??324.755440] usb 2-1: ath9k_htc: USB layer deinitialized
2. The dongle is detected, the first few register reads succeed but register
reads fail as soon as the dongle enters power-saving mode:
[???68.070377] ath: phy0: Removed a station entry for VIF 0 (idx: 0)
[???68.078752] ath: phy0: Detach Interface at idx: 0
[???68.085260] ath: phy0: AWAKE -> FULL-SLEEP
[???68.090766] ath: phy0: FULL-SLEEP -> AWAKE
[???68.107512] ath: phy0: AWAKE -> FULL-SLEEP
[???68.112756] ath: phy0: Driver halt
[???68.117108] ath: phy0: Starting driver with initial channel: 2412 MHz
[???68.123577] ath: phy0: FULL-SLEEP -> AWAKE
[???69.191104] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[???69.197987] ath: phy0: REGISTER READ FAILED: (0x7044, -110)
[???70.231015] ath: phy0: Timeout waiting for WMI command: WMI_REG_RMW_CMDID
What could be causing these issues?
Cheers!
--
Paul Kocialkowski, developer of free digital technology at the lower levels
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161016/1b55bd2d/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.
From: Paul Kocialkowski @ 2016-10-16 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twd1vzc5.fsf@aikidev.net>
Hi,
Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit?:
> This essentially mimics what was done with rk3288-veyron-minnie in
> commit 984926781122f034d5bc9962815d135b6c4a8e1d.
>
> The eMMC of the speedy Chromebook also appears to need the same tuning
> workaround, as it frequently fails to recognize the eMMC without it.
I have a device where (without this patch) eMMC sometimes fails, with:
[????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 175
[????3.571742] mmc2: new HS200 MMC card at address 0001
[????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
And sometimes works, with:
[????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 176
[????3.491093] mmc2: new HS200 MMC card at address 0001
[????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.493548]??mmcblk2: p1 p2
However, with this change, it always fails, with:
[????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[????3.333174] mmc2: error -110 whilst initialising MMC card
I don't have so much time to investigate this issue, but it's clear that this
patch doesn't fix the issue (and actually worsens it) for my device.
Cheers!
> Signed-off-by: Vagrant Cascadian <vagrantc@aikidev.net>
> ---
> Changes in v2:
> ?- Added Signed-off-by.
>
> ?arch/arm/boot/dts/rk3288-veyron-speedy.dts | 5 +++++
> ?1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> index a0d033f..500fd18 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -124,6 +124,11 @@
> ????????????&sdmmc_bus4>;
> ?};
>
> +
> +&emmc {
> +???????/delete-property/mmc-hs200-1_8v;
> +};
> +
> ?&vcc_5v {
> ????enable-active-high;
> ????gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Paul Kocialkowski, developer of free digital technology at the lower levels
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161016/6ae8dfd0/attachment.sig>
^ permalink raw reply
* [PATCH] ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: SF Markus Elfring @ 2016-10-16 19:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Oct 2016 20:48:28 +0200
Some data were printed into a sequence by six separate function calls.
Print the same data by a single function call instead.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm64/kernel/cpuinfo.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index b3d5b3e..f22687d 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v)
if (elf_hwcap & (1 << j))
seq_printf(m, " %s", hwcap_str[j]);
}
- seq_puts(m, "\n");
-
- seq_printf(m, "CPU implementer\t: 0x%02x\n",
- MIDR_IMPLEMENTOR(midr));
- seq_printf(m, "CPU architecture: 8\n");
- seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
- seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
- seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
+ seq_printf(m,
+ "\n"
+ "CPU implementer\t: 0x%02x\n"
+ "CPU architecture: 8\n"
+ "CPU variant\t: 0x%x\n"
+ "CPU part\t: 0x%03x\n"
+ "CPU revision\t: %d\n\n",
+ MIDR_IMPLEMENTOR(midr),
+ MIDR_VARIANT(midr),
+ MIDR_PARTNUM(midr),
+ MIDR_REVISION(midr));
}
return 0;
--
2.10.1
^ permalink raw reply related
* [PATCH] ARM: at91/dt: pullup dbgu rx instead of tx
From: Sylvain Rochet @ 2016-10-16 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d2d5aba-cca3-93c6-0c59-3acbbd7b6169@lysator.liu.se>
Hi Peter,
On Sun, Oct 16, 2016 at 12:57:09PM +0200, Peter Rosin wrote:
> Hi again,
>
> I forgot about this, and it's been a year. But isn't it time to
> upstream those pull-up fixes that Sylvain provided?
Thank you for your reminder, actually I waited an answer on this nice
subject: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368643.html
But this is not relevant for this change anyway, if we should set a
pull-(up|down) on all push-pull pads to reduce power consumption it
should be enforced in the pinctrl driver, the dt must stay logical.
I just sent a v2 with all useless comments removed as suggested by
Alexandre and without the explanation about the removed extra power
consumption when removing a pull-(up|down) on a push-pull output because
it does even seem to be the contrary on Atmel SoCs.
Sylvain
^ 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