* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Karthik Nayak @ 2016-11-14 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <xmqq60nqzuye.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 14, 2016 at 7:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>>>> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
>>>> index 600b703..f4ad297 100644
>>>> --- a/Documentation/git-for-each-ref.txt
>>>> +++ b/Documentation/git-for-each-ref.txt
>>>> @@ -96,7 +96,9 @@ refname::
>>>> slash-separated path components from the front of the refname
>>>> (e.g., `%(refname:strip=2)` turns `refs/tags/foo` into `foo`.
>>>> `<N>` must be a positive integer. If a displayed ref has fewer
>>>> - components than `<N>`, the command aborts with an error.
>>>> + components than `<N>`, the command aborts with an error. For the base
>>>> + directory of the ref (i.e. foo in refs/foo/bar/boz) append
>>>> + `:base`. For the entire directory path append `:dir`.
>
> Sorry that I missed this so far and I do not know how many recent
> rerolls had them like this, but I am not sure about these :base and
> :dir suffixes. From their names I think readers would expect that
> they do rough equivalents to basename() and dirname() applied to the
> refname, but the example contradicts with that intuition. The
> result of applying basename() to 'refs/boo/bar/boz' would be 'boz'
> and not 'foo' as the example says.
>
True that the options ':dir' and ':base' seem to be conflicting with
the use case
of basename() and dirname(), These were names which I thought best fit
the options
with no relation to basename() and dirname(). But now that you mention
it, it would
make sense to change these names to something more suitable, any suggestions
would be welcome.
> So assuming that :base and :dir are unrelated to basename() and
> dirname():
>
> - I think calling these :base and :dir may be misleading
>
> - More importantly, what do these do? I do not think of a good
> description that generalizes "base of refs/foo/bar/boz is foo" to
> explain your :base.
$ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
refs/heads/master refs/heads
refs/heads/ref-filter refs/heads
refs/remotes/junio/va/i18n refs/remotes/junio/va
$ ./git for-each-ref refs/heads --format
"%(align:left,30)%(refname)%(end) %(refname:base)"
refs/heads/master heads
refs/heads/ref-filter heads
refs/remotes/junio/va/i18n remotes
I guess this should clear it up.
>
> - A :dir that corresponds to the :base that picks 'foo' from
> 'refs/foo/bar/boz' needs an example, too.
>
I could add in an example.
> Or is the above example simply a typo? Is refs/foo/bar/boz:base
> 'boz', not 'foo'?
>
>
Not a typo, but open to changes in name.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v7 08/14] mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
From: Stephen Boyd @ 2016-11-14 19:37 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-9-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -577,6 +578,90 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
> return SDHCI_MSM_MIN_CLOCK;
> }
>
> +/**
> + * __sdhci_msm_set_clock - sdhci_msm clock control.
> + *
> + * Description:
> + * Implement MSM version of sdhci_set_clock.
> + * This is required since MSM controller does not
> + * use internal divider and instead directly control
> + * the GCC clock as per HW recommendation.
> + **/
> +void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + u16 clk;
> + unsigned long timeout;
> +
> + /*
> + * Keep actual_clock as zero -
> + * - since there is no divider used so no need of having actual_clock.
> + * - MSM controller uses SDCLK for data timeout calculation. If
> + * actual_clock is zero, host->clock is taken for calculation.
> + */
> + host->mmc->actual_clock = 0;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + return;
> +
> + /*
> + * MSM controller do not use clock divider.
> + * Thus read SDHCI_CLOCK_CONTROL and only enable
> + * clock with no divider value programmed.
> + */
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +
> + clk |= SDHCI_CLOCK_INT_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> + /* Wait max 20 ms */
> + timeout = 20;
> + while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> + & SDHCI_CLOCK_INT_STABLE)) {
> + if (timeout == 0) {
> + pr_err("%s: Internal clock never stabilised\n",
> + mmc_hostname(host->mmc));
> + return;
> + }
> + timeout--;
> + mdelay(1);
> + }
> +
> + clk |= SDHCI_CLOCK_CARD_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
This is almost a copy/paste of sdhci_set_clock(). Can we make
sdhci_set_clock() call a __sdhci_set_clock() function that takes
unsigned int clock, and also a flag indicating if we want to set
the internal clock divider or not? Then we can call
__sdhci_set_clock() from sdhci_set_clock() with (clock, true) as
arguments and (clock, false).
> +}
> +
> +/* sdhci_msm_set_clock - Called with (host->lock) spinlock held. */
> +static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + int rc;
> +
> + if (!clock) {
> + msm_host->clk_rate = clock;
> + goto out;
> + }
> +
> + spin_unlock_irq(&host->lock);
> + if (clock != msm_host->clk_rate) {
Why do we need to check here? Can't we call clk_set_rate()
Unconditionally?
> + rc = clk_set_rate(msm_host->clk, clock);
> + if (rc) {
> + pr_err("%s: Failed to set clock at rate %u\n",
> + mmc_hostname(host->mmc), clock);
> + spin_lock_irq(&host->lock);
> + goto out;
Or replace the above two lines with goto err;
> + }
> + msm_host->clk_rate = clock;
> + pr_debug("%s: Setting clock at rate %lu\n",
> + mmc_hostname(host->mmc), clk_get_rate(msm_host->clk));
> + }
And put an err label here.
> + spin_lock_irq(&host->lock);
> +out:
> + __sdhci_msm_set_clock(host, clock);
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V2] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Sinan Kaya @ 2016-11-14 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <457a0a58-fcb5-26d6-99e6-7192dd071e1c@codeaurora.org>
Hi Vinod,
On 11/13/2016 10:10 PM, Sinan Kaya wrote:
> On 11/13/2016 10:04 PM, Vinod Koul wrote:
>> On Wed, Oct 19, 2016 at 02:42:46PM -0400, Sinan Kaya wrote:
>>> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
>>> the HIDMA object. This is caused by stale sysfs entries remaining from the
>>> previous execution.
>>>
>>> _sysfs_warn_dup+0x5c/0x78
>>> sysfs_add_file_mode_ns+0x13c/0x1c0
>>> sysfs_create_file_ns+0x2c/0x40
>>> device_create_file+0x54/0xa0
>>> hidma_probe+0x7c8/0x808
>>>
>>> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
>>> the probe and remove path. To do proper clean up, adding the attrs object
>>> to the device data structure to keep it around until remove call is made.
>>
>> This doesnt apply for me, I think due to other patches applied..
>>
>
> OK. Let me rebase.
>
I fetched your topic/qcom branch and applied this patch on top.
This is what I see at this moment.
22f20f5 dmaengine: qcom_hidma: cleanup sysfs entries during remove
8cc12b2 dmaengine: qcom_hidma: hide MSI handler when unused
87ffcea dmaengine: qcom_hidma: remove unneeded of_node_put()
1c0e3e8 dmaengine: qcom_hidma: add MSI support for interrupts
I posted V3 a minute ago with the contents of 22f20f5.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH V2] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Sinan Kaya @ 2016-11-14 19:37 UTC (permalink / raw)
To: Vinod Koul
Cc: dmaengine, timur, cov, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <457a0a58-fcb5-26d6-99e6-7192dd071e1c@codeaurora.org>
Hi Vinod,
On 11/13/2016 10:10 PM, Sinan Kaya wrote:
> On 11/13/2016 10:04 PM, Vinod Koul wrote:
>> On Wed, Oct 19, 2016 at 02:42:46PM -0400, Sinan Kaya wrote:
>>> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
>>> the HIDMA object. This is caused by stale sysfs entries remaining from the
>>> previous execution.
>>>
>>> _sysfs_warn_dup+0x5c/0x78
>>> sysfs_add_file_mode_ns+0x13c/0x1c0
>>> sysfs_create_file_ns+0x2c/0x40
>>> device_create_file+0x54/0xa0
>>> hidma_probe+0x7c8/0x808
>>>
>>> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
>>> the probe and remove path. To do proper clean up, adding the attrs object
>>> to the device data structure to keep it around until remove call is made.
>>
>> This doesnt apply for me, I think due to other patches applied..
>>
>
> OK. Let me rebase.
>
I fetched your topic/qcom branch and applied this patch on top.
This is what I see at this moment.
22f20f5 dmaengine: qcom_hidma: cleanup sysfs entries during remove
8cc12b2 dmaengine: qcom_hidma: hide MSI handler when unused
87ffcea dmaengine: qcom_hidma: remove unneeded of_node_put()
1c0e3e8 dmaengine: qcom_hidma: add MSI support for interrupts
I posted V3 a minute ago with the contents of 22f20f5.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:36 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <20161114185621.GC27931@tuxbot>
On 14/11/16 18:56, Bjorn Andersson wrote:
> On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes from v1:
>> - Removed unnessary locking spotted by Bjorn
>> - updated register naming to reflect PM8821
>> - lot of cleanups suggested by Bjorn
>> - rebased on top of Linus Walleij's pm8xxx namespace
>> cleanup patch.
>
> Looks good, just some minor style nits below.
Thanks, I will address all the comments in next version.
>
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
>> 2 files changed, 238 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>
> 8 < 9, so move it one step up please.
sure.. makes sense.
>
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> [..]
>> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
>> +#define PM8821_SSBI_REG(m, b, offset) \
>> + ((m == 0) ? \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
>> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
>> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
>> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
>> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
>
> I like how this cleaned up the rest of the implementation.
>
> [..]
>
>> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>
> "Reading block %d failed ret=%d"
yep.
>
>> + return;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>
> This seems more like a debug thing, either showing missbehaving hardware
> or something odd in the driver. I think you should drop the print or
> make it pr_debug().
okay.
>
>> + return;
>> + }
>
> I would prefer that you just drop the entire if statement, it's just an
> corner case optimization with a info print.
>
i will have a closer look at this part once again.
>> +
>> + /* Convert block offset to global block number */
>> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>
> Empty line
will fix all the empty lines in next version.
>
>> +}
>> +
>> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
>> + int master, u8 master_val)
>> +{
>> + int block;
>> +
>> + for (block = 1; block < 8; block++)
>> + if (master_val & BIT(block))
>> + pm8821_irq_block_handler(chip, master, block);
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> ^
> |
> I see you're using vim :)
>
>> + return;
>> + }
>> +
>> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
>
> Indentation
>
>> + if (master & GENMASK(7, 1))
>> + pm8821_irq_master_handler(chip, 0, master);
>> +
>> + /* bit 0 marks if master 1 contains any bits */
>
> Dito
yep.
>
>> + if (!(master & BIT(0)))
>> + goto done;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>
> "goto done;" so that we pass chained_irq_exit()
yes,
>
>> + }
>> +
>> + pm8821_irq_master_handler(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>
> [..]
>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to mask IRQ %d rc=%d\n"
>
>> + return;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>
> "Failed to clear IRQ %d rc=%d\n"
>
>> + }
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to unmask IRQ %d rc=%d\n"
will update it in next version.
>
>> +
>
> Empty line
>
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int rc, pmirq = irqd_to_hwirq(d);
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>
> Odd capitalization, I suggest that you match it to the other functions
> by:
>
> "Reading status of IRQ %d failed rc=%d\n"
>
Okay
>> + return rc;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> + return rc;
>> +}
>> +
>
> [..]
>
>>
>> static int pm8xxx_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *match;
>> + const struct pm_irq_data *data;
>> struct regmap *regmap;
>> int irq, rc;
>> unsigned int val;
>> u32 rev;
>> struct pm_irq_chip *chip;
>> - unsigned int nirqs = PM8XXX_NR_IRQS;
>> +
>> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(&pdev->dev, "No matching driver data found\n");
>> + return -EINVAL;
>> + }
>> +
>> + data = match->data;
>
> data = of_device_get_match_data(&pdev->dev); (from of_device.h)
This is good one.. I will use it in next version.
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114185621.GC27931@tuxbot>
On 14/11/16 18:56, Bjorn Andersson wrote:
> On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes from v1:
>> - Removed unnessary locking spotted by Bjorn
>> - updated register naming to reflect PM8821
>> - lot of cleanups suggested by Bjorn
>> - rebased on top of Linus Walleij's pm8xxx namespace
>> cleanup patch.
>
> Looks good, just some minor style nits below.
Thanks, I will address all the comments in next version.
>
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
>> 2 files changed, 238 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>
> 8 < 9, so move it one step up please.
sure.. makes sense.
>
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> [..]
>> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
>> +#define PM8821_SSBI_REG(m, b, offset) \
>> + ((m == 0) ? \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
>> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
>> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
>> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
>> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
>
> I like how this cleaned up the rest of the implementation.
>
> [..]
>
>> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>
> "Reading block %d failed ret=%d"
yep.
>
>> + return;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>
> This seems more like a debug thing, either showing missbehaving hardware
> or something odd in the driver. I think you should drop the print or
> make it pr_debug().
okay.
>
>> + return;
>> + }
>
> I would prefer that you just drop the entire if statement, it's just an
> corner case optimization with a info print.
>
i will have a closer look at this part once again.
>> +
>> + /* Convert block offset to global block number */
>> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>
> Empty line
will fix all the empty lines in next version.
>
>> +}
>> +
>> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
>> + int master, u8 master_val)
>> +{
>> + int block;
>> +
>> + for (block = 1; block < 8; block++)
>> + if (master_val & BIT(block))
>> + pm8821_irq_block_handler(chip, master, block);
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> ^
> |
> I see you're using vim :)
>
>> + return;
>> + }
>> +
>> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
>
> Indentation
>
>> + if (master & GENMASK(7, 1))
>> + pm8821_irq_master_handler(chip, 0, master);
>> +
>> + /* bit 0 marks if master 1 contains any bits */
>
> Dito
yep.
>
>> + if (!(master & BIT(0)))
>> + goto done;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>
> "goto done;" so that we pass chained_irq_exit()
yes,
>
>> + }
>> +
>> + pm8821_irq_master_handler(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>
> [..]
>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to mask IRQ %d rc=%d\n"
>
>> + return;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>
> "Failed to clear IRQ %d rc=%d\n"
>
>> + }
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to unmask IRQ %d rc=%d\n"
will update it in next version.
>
>> +
>
> Empty line
>
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int rc, pmirq = irqd_to_hwirq(d);
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>
> Odd capitalization, I suggest that you match it to the other functions
> by:
>
> "Reading status of IRQ %d failed rc=%d\n"
>
Okay
>> + return rc;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> + return rc;
>> +}
>> +
>
> [..]
>
>>
>> static int pm8xxx_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *match;
>> + const struct pm_irq_data *data;
>> struct regmap *regmap;
>> int irq, rc;
>> unsigned int val;
>> u32 rev;
>> struct pm_irq_chip *chip;
>> - unsigned int nirqs = PM8XXX_NR_IRQS;
>> +
>> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(&pdev->dev, "No matching driver data found\n");
>> + return -EINVAL;
>> + }
>> +
>> + data = match->data;
>
> data = of_device_get_match_data(&pdev->dev); (from of_device.h)
This is good one.. I will use it in next version.
> Regards,
> Bjorn
>
^ permalink raw reply
* [oe][Patch] systemd: systemd should not depend on systemd-container
From: Max Krummenacher @ 2016-11-14 19:35 UTC (permalink / raw)
To: openembedded-core; +Cc: Max Krummenacher
Currently systemd depends on systemd-container due to a dangling
symlink deployed with systemd.
Move the symlink to systemd-container.
| DEBUG: systemd contains dangling link /lib/systemd/system/systemd-machined.service
| DEBUG: target found in systemd-container
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---
meta/recipes-core/systemd/systemd_230.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd_230.bb b/meta/recipes-core/systemd/systemd_230.bb
index a949fe8..cc196d1 100644
--- a/meta/recipes-core/systemd/systemd_230.bb
+++ b/meta/recipes-core/systemd/systemd_230.bb
@@ -369,6 +369,7 @@ FILES_${PN}-container = "${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.c
${systemd_system_unitdir}/org.freedesktop.machine1.busname \
${systemd_system_unitdir}/systemd-importd.service \
${systemd_system_unitdir}/systemd-machined.service \
+ ${systemd_system_unitdir}/dbus-org.freedesktop.machine1.service \
${systemd_system_unitdir}/var-lib-machines.mount \
${rootlibexecdir}/systemd/systemd-import \
${rootlibexecdir}/systemd/systemd-importd \
--
2.5.5
^ permalink raw reply related
* [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
From: Stephen Boyd @ 2016-11-14 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111074017.GA21045@b29397-desktop>
Quoting Peter Chen (2016-11-10 23:40:17)
> On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-18 02:31:40)
> > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > > I've also sent separate patches for other minor pieces to make this
> > > > all work. The full tree can be found here[2], hacks and all to get
> > > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > > and ifc6410 with configfs gadgets and otg cables.
> > > >
> > > > Patches based on v4.8-rc1
> >
> > Oops should be v4.9-rc1 here.
> >
> > > >
> > > > Changes from v4:
> > > > * Picked up Acks from Rob
> > > > * Updated HS phy init sequence DT property to restrict it to offsets
> > >
> > > I remembered that you got all my acks for chipidea patches, right? I did
> > > not check for this series.
> >
> > Sorry I've added in one more patch
> >
> > usb: chipidea: Emulate OTGSC interrupt enable path
> >
> > to fix extcon interrupt emulation even further.
> >
> > >
> > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > > provider" [1] still not be accepted, I need this patch to be merged
> > > first, then apply your chipidea part, otherwise, there is a building
> > > warning.
> > >
> > > [1] https://patchwork.kernel.org/patch/9322583/
> >
> > Yes, I'm going to resend that patch now. I hope that David will apply it
> > for -rc2.
>
> Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
> it), your GPU fix is still not there.
>
It looks like the patch is in drm-misc. I think they're going to hold
off on merging it until the next merge window though. fb80016af071 is
the commit in drm-misc tree and in linux-next. I'm not sure anything can
be done here besides a cross tree merge or ignore the warning?
^ permalink raw reply
* Re: [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
From: Stephen Boyd @ 2016-11-14 19:35 UTC (permalink / raw)
To: Peter Chen
Cc: Felipe Balbi, Heikki Krogerus, Arnd Bergmann, Neil Armstrong,
linux-arm-msm, linux-usb, linux-kernel, Bjorn Andersson,
devicetree, Rob Herring, Peter Chen, Greg Kroah-Hartman,
Andy Gross, Ivan T. Ivanov, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <20161111074017.GA21045@b29397-desktop>
Quoting Peter Chen (2016-11-10 23:40:17)
> On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-18 02:31:40)
> > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > > I've also sent separate patches for other minor pieces to make this
> > > > all work. The full tree can be found here[2], hacks and all to get
> > > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > > and ifc6410 with configfs gadgets and otg cables.
> > > >
> > > > Patches based on v4.8-rc1
> >
> > Oops should be v4.9-rc1 here.
> >
> > > >
> > > > Changes from v4:
> > > > * Picked up Acks from Rob
> > > > * Updated HS phy init sequence DT property to restrict it to offsets
> > >
> > > I remembered that you got all my acks for chipidea patches, right? I did
> > > not check for this series.
> >
> > Sorry I've added in one more patch
> >
> > usb: chipidea: Emulate OTGSC interrupt enable path
> >
> > to fix extcon interrupt emulation even further.
> >
> > >
> > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > > provider" [1] still not be accepted, I need this patch to be merged
> > > first, then apply your chipidea part, otherwise, there is a building
> > > warning.
> > >
> > > [1] https://patchwork.kernel.org/patch/9322583/
> >
> > Yes, I'm going to resend that patch now. I hope that David will apply it
> > for -rc2.
>
> Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
> it), your GPU fix is still not there.
>
It looks like the patch is in drm-misc. I think they're going to hold
off on merging it until the next merge window though. fb80016af071 is
the commit in drm-misc tree and in linux-next. I'm not sure anything can
be done here besides a cross tree merge or ignore the warning?
^ permalink raw reply
* Re: [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: Laura Abbott, linux-kernel
Cc: Russell King, Catalin Marinas, Will Deacon, Arnd Bergmann,
Nicolas Pitre, Chris Brandt, Pratyush Anand, Ard Biesheuvel,
Mark Rutland, James Morse, Neeraj Upadhyay, Andrew Morton,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov,
Jerome Marchand, Konstantin Khlebnikov, Joonsoo Kim,
moderated list:ARM PORT,
open list:GENERIC INCLUDE/ASM HEADER FILES,
open list:MEMORY MANAGEMENT
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-14 19:34 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Andrew Morton,
Rob Herring, Frank Rowand, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <87bmxii85s.fsf@concordia.ellerman.id.au>
On Mon, Nov 14, 2016 at 10:59:43PM +1100, Michael Ellerman wrote:
>So I'm not opposed to this, but it is a little vague.
>
>What does the "hotpluggable" property really mean?
>
>Is it just a hint to the operating system? (which may or may not be
>Linux).
>
>Or is it a direction, "this memory must be able to be hotunplugged"?
>
>I think you're intending the former, ie. a hint, which is probably OK.
>But it needs to be documented clearly.
Yes, you've got it right. It's just a hint, not a mandate.
I'm about to send v7 which adds a description of "hotpluggable" in the
documentation. Hopefully I've explained it well enough there.
--
Reza Arbab
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-14 19:34 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Andrew Morton,
Rob Herring, Frank Rowand, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <87bmxii85s.fsf@concordia.ellerman.id.au>
On Mon, Nov 14, 2016 at 10:59:43PM +1100, Michael Ellerman wrote:
>So I'm not opposed to this, but it is a little vague.
>
>What does the "hotpluggable" property really mean?
>
>Is it just a hint to the operating system? (which may or may not be
>Linux).
>
>Or is it a direction, "this memory must be able to be hotunplugged"?
>
>I think you're intending the former, ie. a hint, which is probably OK.
>But it needs to be documented clearly.
Yes, you've got it right. It's just a hint, not a mandate.
I'm about to send v7 which adds a description of "hotpluggable" in the
documentation. Hopefully I've explained it well enough there.
--
Reza Arbab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control
From: Rob Herring @ 2016-11-14 19:34 UTC (permalink / raw)
To: Laxman Dewangan
Cc: linus.walleij, mark.rutland, swarren, thierry.reding, gnurou,
yamada.masahiro, jonathanh, linux-gpio, devicetree, linux-tegra,
linux-kernel
In-Reply-To: <1478696782-11657-2-git-send-email-ldewangan@nvidia.com>
On Wed, Nov 09, 2016 at 06:36:21PM +0530, Laxman Dewangan wrote:
> NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> low power state of some of its IO pads. The IO pads can work in
> the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
> sources. When IO interfaces are not used then IO pads can be
> configure in low power state to reduce the power consumption from
> that IO pads.
>
> On Tegra124, the voltage level of IO power rail source is auto
> detected by hardware(SoC) and hence it is only require to configure
> in low power mode if IO pads are not used.
>
> On T210 onwards, the auto-detection of voltage level from IO power
> rail is removed from SoC and hence SW need to configure the PMC
> register explicitly to set proper voltage in IO pads based on
> IO rail power source voltage.
>
> Add DT binding document for detailing the DT properties for
> configuring IO pads voltage levels and its power state.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
>
> ---
> Changes from V1:
> The DT binding document is modified to explain the regulator handle
> for different IOs and how can it be passed from the DT.
> ---
> .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> new file mode 100644
> index 0000000..6ca961f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> @@ -0,0 +1,126 @@
> +NVIDIA Tegra PMC IO pad controller
> +
> +NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> +low power state of some of its IO pads. When IO interface are not
> +used then IO pads can be configure in low power state to reduce
> +the power from that IO pads. The IO pads can work in the voltage
> +of the 1.8V and 3.3V of IO voltage from power rail sources.
> +
> +On Tegra124, the voltage of IO power rail source is auto detected by
> +SoC and hence it is only require to configure in low power mode if
> +IO pads are not used.
> +
> +On T210 onwards, the HW based auto-detection for IO voltage is removed
> +and hence SW need to configure the PMC register explicitly, to set proper
> +voltage in IO pads, based on IO rail power source voltage.
> +
> +The voltage configurations and low power state of IO pads should be done
> +in boot if it is not going to change other wise dynamically based on IO
> +rail voltage on that IO pads and usage of IO pads
s/other wise/otherwise/
The end of the sentence is not clear and missing a period.
> +
> +The DT property of the io pads must be under the node of pmc i.e.
> +pmc@7000e400 for Tegra124 onwards.
s/io/IO/
> +
> +Please refer to <pinctrl-bindings.txt> in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +Tegra's pin configuration nodes act as a container for an arbitrary number of
> +subnodes. Each of these subnodes represents some desired configuration for an
> +IO pads, or a list of IO pads. This configuration can include the voltage and
> +power enable/disable control
> +
> +The name of each subnode is not important; all subnodes should be enumerated
> +and processed purely based on their content. Each subnode only affects those
> +parameters that are explicitly listed. Unspecified is represented as an absent
> +property,
> +
> +See the TRM to determine which properties and values apply to each IO pads.
> +
> +Required subnode-properties:
> +==========================
> +- pins : An array of strings. Each string contains the name of an IO pads. Valid
> + values for these names are listed below.
> +
> +Optional subnode-properties:
> +==========================
> +Following properties are supported from generic pin configuration explained
> +in <dt-bindings/pinctrl/pinctrl-binding.txt>.
> +low-power-enable: enable low power mode.
> +low-power-disable: disable low power mode.
> +
> +Valid values for pin for T124 are:
> + audio, bb, cam, comp, csia, csib, csie, dsi, dsib, dsic, dsid, hdmi,
> + hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, sdmmc4, sys-ddc, uart, usb0, usb1, usb2,
> + usb-bias
> +
> +Valid values for pin for T210 are:
> + audio, audio-hv, cam, csia, csib, csic, csid, csie, csif,
> + dbg, debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2,
> + gpio, hdmi, hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, spi, spi-hv, uart, usb-bias, usb0,
> + usb1, usb2, usb3.
> +
> +To find out the IO rail voltage for setting the voltage of IO pad by SW,
> +the regulator supply handle must provided from the DT and it is explained
> +in the regulator DT binding document
> + <devicetree/bindings/regulator/regulator.txt>.
> +For example, for GPIO rail the supply name is vddio-gpio and regulator
> +handle is supplied from DT as
> + vddio-gpio-supply = <®ulator_xyz>;
> +
> +For T210, following IO pads support the 1.8V/3.3V and the corresponding
> +io voltage pin names are as follows:
> + audio -> vddio-audio
> + audio-hv -> vddio-audio-hv
> + cam ->vddio-cam
> + dbg -> vddio-dbg
> + dmic -> vddio-dmic
> + gpio -> vddio-gpio
> + pex-ctrl -> vddio-pex-ctrl
> + sdmmc1 -> vddio-sdmmc1
> + sdmmc3 -> vddio-sdmmc3
> + spi -> vddio-spi
> + spi-hv -> vddio-spi-hv
> + uart -> vddio-uart
> +
> +Example:
> + i2c@7000d000 {
> + pmic@3c {
> + regulators {
> + vddio_sdmmc1: ldo2 {
> + /* Regulator entries for LDO2 */
> + };
> +
> + vdd_cam: ldo3 {
> + /* Regulator entries for LDO3 */
> + };
> + };
> + };
> + };
> +
> + pmc@7000e400 {
> + vddio-cam = <&vdd_cam>;
Missing -supply.
> + vddio-sdmmc1-supply = <&vddio_sdmmc1>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tegra_io_pad_volt_default>;
> + tegra_io_pad_volt_default: common {
> + audio-hv {
> + pins = "audio-hv";
> + low-power-disable;
> + };
> +
> + gpio {
> + pins = "gpio";
> + low-power-disable;
> + };
> +
> + audio {
> + pins = "audio", "dmic", "sdmmc3";
What's the purpose of grouping these?
> + low-power-enable;
> + };
> + };
> +
> + };
> --
> 2.1.4
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active
From: Paolo Bonzini @ 2016-11-14 19:33 UTC (permalink / raw)
To: Alex Williamson; +Cc: cornelia.huck, famz, qemu-devel, stefanha, mst
In-Reply-To: <20161114114929.0a45aacf@t450s.home>
On 14/11/2016 19:49, Alex Williamson wrote:
> On Mon, 14 Nov 2016 19:10:54 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> On 14/11/2016 18:09, Alex Williamson wrote:
>>> Hmm, fixed yet not fixed. I get a nice shutdown and it even eliminates
>>> a cpu spike shown in virt-manager at the end of shutdown that was
>>> typical previously, but then I noticed dmesg showing me segfaults, so I
>>> hooked up gdb and:
>>
>> Well, that I don't get the segfault already says something... Though
>> it's not even clear from the backtrace what is causing the segfault.
>> Let's try the same printf without the change.
>
> Log starting from virsh shutdown. The final line occurs just as the VM
> starts spinning on all vcpus. Thanks,
Ok, this could be a start. Just for information what is your virtio-win
version?
Paolo
^ permalink raw reply
* Re: [PATCH 1/3] block: fast-path for small and simple direct I/O requests
From: Omar Sandoval @ 2016-11-14 19:33 UTC (permalink / raw)
To: Jens Axboe; +Cc: axboe, linux-block, linux-fsdevel, hch, Christoph Hellwig
In-Reply-To: <1478927487-12998-2-git-send-email-axboe@fb.com>
On Fri, Nov 11, 2016 at 10:11:25PM -0700, Jens Axboe wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> This patch adds a small and simple fast patch for small direct I/O
> requests on block devices that don't use AIO. Between the neat
> bio_iov_iter_get_pages helper that avoids allocating a page array
> for get_user_pages and the on-stack bio and biovec this avoid memory
> allocations and atomic operations entirely in the direct I/O code
> (lower levels might still do memory allocations and will usually
> have at least some atomic operations, though).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Jens Axboe <axboe@fb.com>
> ---
> fs/block_dev.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
[snip]
> static ssize_t
> blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
> {
> struct file *file = iocb->ki_filp;
> struct inode *inode = bdev_file_inode(file);
> + int nr_pages;
>
> + nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
> + if (!nr_pages)
> + return 0;
> + if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
> + return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
> return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
> blkdev_get_block, NULL, NULL,
> DIO_SKIP_DIO_COUNT);
__blockdev_direct_IO() does a few cache prefetches that we're now
bypassing, do we want to do the same in __blkdev_direct_IO_simple()?
That's the stuff added in 65dd2aa90aa1 ("dio: optimize cache misses in
the submission path").
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Omar
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:33 UTC (permalink / raw)
To: Stephen Boyd, Lee Jones
Cc: bjorn.andersson, Rob Herring, Andy Gross, devicetree,
linux-kernel, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <a1116e3f-32d2-aa2d-9404-1d8147bd8500@codeaurora.org>
On 14/11/16 18:40, Stephen Boyd wrote:
> On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
>> index 7f9620e..dc347d3 100644
>> --- a/drivers/mfd/qcom-pm8xxx.c
>> +++ b/drivers/mfd/qcom-pm8xxx.c
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>
> Hm? vi?
yes.. That was good catch!! will fix it in next version...
>
^ permalink raw reply
* Re: [PATCH] IB/mlx4: Rework special QP creation error path
From: Laurence Oberman @ 2016-11-14 19:33 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, Yishai Hadas, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3a41daa7-cfb8-7374-5dab-dfa3b1bf83ff-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
----- Original Message -----
> From: "Bart Van Assche" <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> To: "Doug Ledford" <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: "Yishai Hadas" <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Sent: Monday, November 14, 2016 11:44:11 AM
> Subject: [PATCH] IB/mlx4: Rework special QP creation error path
>
> The special QP creation error path relies on offset_of(struct mlx4_ib_sqp,
> qp) == 0. Remove this assumption because that makes the QP creation
> code easier to understand.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/infiniband/hw/mlx4/qp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/qp.c
> b/drivers/infiniband/hw/mlx4/qp.c
> index 570bc86..b63d6be 100644
> --- a/drivers/infiniband/hw/mlx4/qp.c
> +++ b/drivers/infiniband/hw/mlx4/qp.c
> @@ -644,7 +644,7 @@ static int create_qp_common(struct mlx4_ib_dev *dev,
> struct ib_pd *pd,
> int qpn;
> int err;
> struct ib_qp_cap backup_cap;
> - struct mlx4_ib_sqp *sqp;
> + struct mlx4_ib_sqp *sqp = NULL;
> struct mlx4_ib_qp *qp;
> enum mlx4_ib_qp_type qp_type = (enum mlx4_ib_qp_type) init_attr->qp_type;
> struct mlx4_ib_cq *mcq;
> @@ -933,7 +933,9 @@ static int create_qp_common(struct mlx4_ib_dev *dev,
> struct ib_pd *pd,
> mlx4_db_free(dev->dev, &qp->db);
>
> err:
> - if (!*caller_qp)
> + if (sqp)
> + kfree(sqp);
> + else if (!*caller_qp)
> kfree(qp);
> return err;
> }
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
This looks fine to me.
Reviewed-by: Laurence Oberman <loberman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1116e3f-32d2-aa2d-9404-1d8147bd8500@codeaurora.org>
On 14/11/16 18:40, Stephen Boyd wrote:
> On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
>> index 7f9620e..dc347d3 100644
>> --- a/drivers/mfd/qcom-pm8xxx.c
>> +++ b/drivers/mfd/qcom-pm8xxx.c
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>
> Hm? vi?
yes.. That was good catch!! will fix it in next version...
>
^ permalink raw reply
* Re: [PATCH 1/2] Btrfs: fix file extent corruption
From: Chris Mason @ 2016-11-14 19:32 UTC (permalink / raw)
To: Josef Bacik, linux-btrfs, kernel-team
In-Reply-To: <1479150382-19273-1-git-send-email-jbacik@fb.com>
On 11/14/2016 02:06 PM, Josef Bacik wrote:
> In order to do hole punching we have a block reserve to hold the reservation we
> need to drop the extents in our range. Since we could end up dropping a lot of
> extents we set rsv->failfast so we can just loop around again and drop the
> remaining of the range. Unfortunately we unconditionally fill the hole extents
> in and start from the last extent we encountered, which we may or may not have
> dropped. So this can result in overlapping file extent entries, which can be
> tripped over in a variety of ways, either by hitting BUG_ON(!ret) in
> fill_holes() after the search, or in btrfs_set_item_key_safe() in
> btrfs_drop_extent() at a later time by an unrelated task. Fix this by only
> setting drop_end to the last extent we did actually drop. This way our holes
> are filled in properly for the range that we did drop, and the rest of the range
> that remains to be dropped is actually dropped. Thanks,
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
Thanks for tracking this down Josef. We should mark it for stable too.
-chris
^ permalink raw reply
* Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events
From: Steve Longerbeam @ 2016-11-14 19:32 UTC (permalink / raw)
To: Steve Longerbeam, Hans Verkuil, lars
Cc: mchehab, linux-media, linux-kernel, Mauro Carvalho Chehab
In-Reply-To: <de4a622c-0d2b-0233-3f82-958a16319656@mentor.com>
On 11/14/2016 11:19 AM, Steve Longerbeam wrote:
>
>
> On 11/14/2016 03:36 AM, Hans Verkuil wrote:
>> On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
>>> Add a signal lock status change to the source changes bitmask.
>>> This indicates there was a signal lock or unlock event detected
>>> at the input of a video decoder.
>>>
>>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>>> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>>>
>>> ---
>>>
>>> v4:
>>> - converted to rst from DocBook
>>>
>>> v3: no changes
>>> v2: no changes
>>> ---
>>> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 9 +++++++++
>>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>>> include/uapi/linux/videodev2.h | 1 +
>>> 3 files changed, 11 insertions(+)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> index 73c0d5b..7d8a053 100644
>>> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>> @@ -564,6 +564,15 @@ call.
>>> an input. This can come from an input connector or from a video
>>> decoder.
>>> + - .. row 2
>>> +
>>> + - ``V4L2_EVENT_SRC_CH_LOCK_STATUS``
>>> +
>>> + - 0x0002
>>> +
>>> + - This event gets triggered when there is a signal lock or
>>> + unlock detected at the input of a video decoder.
>>> +
>>> Return Value
>>> ============
>>> diff --git a/Documentation/media/videodev2.h.rst.exceptions
>>> b/Documentation/media/videodev2.h.rst.exceptions
>>> index 9bb9a6c..f412cc8 100644
>>> --- a/Documentation/media/videodev2.h.rst.exceptions
>>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>>> @@ -453,6 +453,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS
>>> ctrl-changes-flags
>>> replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>>> replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
>>> +replace define V4L2_EVENT_SRC_CH_LOCK_STATUS src-changes-flags
>>> replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ
>>> v4l2-event-motion-det
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h
>>> index 724f43e..08a153f 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
>>> };
>>> #define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
>>> +#define V4L2_EVENT_SRC_CH_LOCK_STATUS (1 << 1)
>>> struct v4l2_event_src_change {
>>> __u32 changes;
>>>
>> Quoting from an old (July) conversation about this:
>>
>>>>> I'm not entirely sure I like this. Typically losing lock means
>>>>> that this event
>>>>> is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and
>>>>> userspace has
>>>>> to check the new timings etc., which will fail if there is no lock
>>>>> anymore.
>>>>>
>>>>> This information is also available through ENUMINPUT.
>>>>>
>>>>> I would need to know more about why you think this is needed,
>>>>> because I don't
>>>>> see what this adds.
>>> Hi Hans,
>>>
>>> At least on the ADV718x, a source resolution change (from an
>>> autodetected video
>>> standard change) and a signal lock status change are distinct events.
>>> For example
>>> there can be a temporary loss of input signal lock without a change in
>>> detected
>>> input video standard/resolution.
>> OK, but what can the application do with that event? If the glitch
>> didn't
>> affect the video, then it is pointless.
>
> Hi Hans, that's just it, for i.mx6 it does affect video. On i.mx6 a
> temporary
> loss of signal from the adv7180 often results in a "split image", or
> rolling
> image from captured frame to the next, and the only way to recover
> from this failure is to restart the pipeline (stream off -- stream
> on). So
> the application needs to be informed of this temporary loss of signal
> event in order to restart streaming.
>
>
>>
>> If the lock is lost, then normally you loose video as well. If not, then
>> applications are not interested in the event.
>
> Yes, the lost lock causes a temporary or permanent loss of video,
> but with no other indications from the adv7180 (such as a detected
> video standard change). And on i.mx6, the lost lock often (actually
> usually) causes a split or rolling image.
>
Also it seems the sequence of actions from the application due to a
SRC_CH_LOCK_STATUS event would be in line with the action due to
SRC_CH_RESOLUTION. In other words for SRC_CH_RESOLUTION,
the app requests an update on the detected video standard via
QUERYSTD, and for SRC_CH_LOCK_STATUS, it requests an update
on input status (ENUMINPUTS).
Steve
^ permalink raw reply
* Re: [Qemu-devel] [RFC 2/2] cputlb: drop flush_global flag from tlb_flush
From: Richard Henderson @ 2016-11-14 19:28 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Aurelien Jarno,
Peter Maydell, Eduardo Habkost, Edgar E. Iglesias, Yongbok Kim,
Jia Liu, David Gibson, Alexander Graf, Mark Cave-Ayland,
Artyom Tarasenko, Guan Xuetao, Max Filippov, open list:ARM,
open list:PowerPC
In-Reply-To: <20161114174010.31040-3-alex.bennee@linaro.org>
On 11/14/2016 06:40 PM, Alex Bennée wrote:
> We have never has the concept of global TLB entries which would avoid
> the flush so we never actually use this flag. Drop it and make clear
> that tlb_flush is the sledge-hammer it has always been.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
Reviewed-by: Richard Henderson <rth@twiddle.net>
r~
^ permalink raw reply
* Re: [RFC 2/2] cputlb: drop flush_global flag from tlb_flush
From: Richard Henderson @ 2016-11-14 19:28 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, Paolo Bonzini, Peter Crosthwaite, Aurelien Jarno,
Peter Maydell, Eduardo Habkost, Edgar E. Iglesias, Yongbok Kim,
Jia Liu, David Gibson, Alexander Graf, Mark Cave-Ayland,
Artyom Tarasenko, Guan Xuetao, Max Filippov, open list:ARM,
open list:PowerPC
In-Reply-To: <20161114174010.31040-3-alex.bennee@linaro.org>
On 11/14/2016 06:40 PM, Alex Bennée wrote:
> We have never has the concept of global TLB entries which would avoid
> the flush so we never actually use this flag. Drop it and make clear
> that tlb_flush is the sledge-hammer it has always been.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
Reviewed-by: Richard Henderson <rth@twiddle.net>
r~
^ permalink raw reply
* Re: [Libtirpc-devel] [PATCH rpcbind] Move default state-dir to /run/rpcbind
From: Steve Dickson @ 2016-11-14 19:26 UTC (permalink / raw)
To: NeilBrown, Linux NFS Mailing List, libtirpc-devel
In-Reply-To: <20161114191234.GV21655@vapier.lan>
On 11/14/2016 02:12 PM, Mike Frysinger wrote:
> On 14 Nov 2016 10:09, NeilBrown wrote:
>> On Sat, Nov 12 2016, Mike Frysinger wrote:
>>> On 11 Nov 2016 14:36, NeilBrown wrote:
>>>> rpcbind can save state in a file to allow restart without forgetting
>>>> about running services.
>>>>
>>>> The default location is currently "/tmp" which is an over-used
>>>> directory that isn't really suitable for system files.
>>>> The modern preferences would be a subdirectory of "/run", which can
>>>> be selected with a ./configure option. That subdirectory would still need
>>>> to be created by something.
>>> the portable path is /var/cache instead of /run. i don't think libtirpc
>>> should be configuring itself to assume Linux by default.
>> In principle I agree. But is /var/cache really a good choice?
>> We don't want the state files to persist over a reboot, and I strongly
>> suspect that /var/cache is designed to do exactly that.
>>
>> Are there agree standards that are broader than Linux that we can look
>> to?
>> FHS defines /var/run (or even /run) but I suspect it is linux-only.
> /var/run should work across systems i believe. at least BSD's support it.
In the Red Hat distos /var/run is a symbolic link to /run and the systemd
folks have asked us to use /run instead of /var/run
steved.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 01/21] specs/qcow2: fix bitmap granularity qemu-specific note
From: John Snow @ 2016-11-14 19:26 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-block, qemu-devel
Cc: kwolf, famz, armbru, mreitz, stefanha, pbonzini, den
In-Reply-To: <1478715476-132280-2-git-send-email-vsementsov@virtuozzo.com>
On 11/09/2016 01:17 PM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> docs/specs/qcow2.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index 80cdfd0..dda53dd 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -472,8 +472,7 @@ Structure of a bitmap directory entry:
> 17: granularity_bits
> Granularity bits. Valid values: 0 - 63.
>
> - Note: Qemu currently doesn't support granularity_bits
> - greater than 31.
> + Note: Qemu currently supports only values 9 - 31.
>
> Granularity is calculated as
> granularity = 1 << granularity_bits
>
Reviewed-by: John Snow <jsnow@redhat.com>
^ permalink raw reply
* Re: [PATCH 3/3] backports: empty define for __ro_after_init
From: Arend Van Spriel @ 2016-11-14 19:26 UTC (permalink / raw)
To: Luis R. Rodriguez, Johannes Berg, Kees Cook; +Cc: backports
In-Reply-To: <20161114185917.GZ13978@wotan.suse.de>
On 14-11-2016 19:59, Luis R. Rodriguez wrote:
> On Sat, Nov 12, 2016 at 10:07:22PM +0100, Johannes Berg wrote:
>> On Sat, 2016-11-12 at 20:18 +0000, Arend van Spriel wrote:
>>> nl80211 now uses section qualifier __ro_after_init. However, this
>>> is not available in kernels before v4.6. Neither is the section
>>> itself hence adding an empty define in backports.
>>
>>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,6,0))
>>> +#define __ro_after_init
>>> +#endif
>>
>> Due to how __ro_after_init works, it *has* to be a macro originally, so
>> you could just ifndef on itself:
>>
>> #ifndef __ro_after_init
>> #define __ro_after_init
>> #endif
>>
>> and be slightly more compatible in case somebody ever backports it.
>
> Agreed.
Agree as well hence I posted a V2 yesterday ;-)
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe backports" in
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.