* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-09-23 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923180239.GC29830@leverpostej>
On 9/23/2016 2:02 PM, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> index fd5618b..47bfb5a 100644
>> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> @@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
>> the channel nodes appear on their own, not under a management node.
>>
>> Required properties:
>> -- compatible: must contain "qcom,hidma-1.0"
>> +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
>> +for MSI capable HW.
>> - reg: Addresses for the transfer and event channel
>> - interrupts: Should contain the event interrupt
>> - desc-count: Number of asynchronous requests this channel can handle
>> - iommus: required a iommu node
>>
>> +Optional properties for MSI:
>> +- msi-parent: pointer to the MSI controller object with the DeviceID in use.
>
> The format of msi-cells depends on the particular msi-controller, so no
> need to mention DeviceID here.
>
> Please refer to
> Documentation/devicetree/bindings/interrupt-controller/msi.txt
Thanks, let me do some more research.
>
>> +Example:
>> + msi_parent: <&msi0 0x80024>
>
> This doesn't match (s/_/-/).
ok
>
>> +msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
>> +is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
>> +instance 1.
>
> I don't think you need any of this text, so long as you refer to the
> generic MSI binding document, as above.
ok
>
> Thanks,
> Mark.
>
--
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
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Stefan Wahren @ 2016-09-23 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-2-eric@anholt.net>
Hi Eric,
> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13 geschrieben:
>
>
> This driver will be used for accessing the FXL6408 GPIO exander on the
> Pi3. We can't drive it directly from Linux because the firmware is
> continuously polling one of the expander's lines to do its
> undervoltage detection.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> ...
> +
> +static int rpi_gpio_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *fw_node;
> + struct rpi_gpio *rpi;
> + u32 ngpio;
> + int ret;
> +
> + rpi = devm_kzalloc(dev, sizeof *rpi, GFP_KERNEL);
> + if (!rpi)
> + return -ENOMEM;
> + rpi->dev = dev;
> +
> + fw_node = of_parse_phandle(np, "firmware", 0);
AFAIK fw_node must be freed with of_node_put() after usage
> + if (!fw_node) {
> + dev_err(dev, "Missing firmware node\n");
> + return -ENOENT;
> + }
> +
> + rpi->firmware = rpi_firmware_get(fw_node);
> + if (!rpi->firmware)
> + return -EPROBE_DEFER;
> +
> + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpio)) {
> + dev_err(dev, "Missing ngpios");
> + return -ENOENT;
> + }
> + if (of_property_read_u32(pdev->dev.of_node,
> + "raspberrypi,firmware-gpio-offset",
> + &rpi->offset)) {
> + dev_err(dev, "Missing raspberrypi,firmware-gpio-offset");
> + return -ENOENT;
> + }
> +
> + rpi->gc.label = np->full_name;
> + rpi->gc.owner = THIS_MODULE;
> + rpi->gc.of_node = np;
> + rpi->gc.ngpio = ngpio;
> + rpi->gc.direction_input = rpi_gpio_dir_in;
> + rpi->gc.direction_output = rpi_gpio_dir_out;
> + rpi->gc.get = rpi_gpio_get;
> + rpi->gc.set = rpi_gpio_set;
> + rpi->gc.can_sleep = true;
i think it's better to assign rpi->gc.base explicit.
Stefan
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Peter Ujfalusi @ 2016-09-23 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06e0406c-3ff0-a069-a48a-0b1b82872f98@oracle.com>
On 09/23/2016 06:24 PM, Santosh Shilimkar wrote:
> On 9/23/2016 7:26 AM, Tony Lindgren wrote:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
>>> On 09/22/16 21:07, Tony Lindgren wrote:
>
> [...]
>
>>> On which linux-next version you are seeing this?
>>
>> This was with next-20160922. But testing it again this is just another
>> regression caused by "softirq: fix tasklet_kill() and its users", so adding
>> Santosh to Cc.
>>
>> So no need to revert $subject patch.
>>
> So your driver also looks like fiddling with tasklet core structures if
> you got impacted because of the core change.
How is that? None of the drivers in the twl6040 stack uses tasklets
explicitly. The core uses regmap_irq and the drivers use threaded irq when
they need interrupt handling, but no tasklet, no fiddling with internals.
--
P?ter
> After the merge window
> am going to take stab at bad users of tasklet but below is
> quick snap shot conversation I had with Thomas and Andrew...
>
> ------------------------------------------------------------------
> B1;2802;0cOn Wed, 21 Sep 2016, Santosh Shilimkar wrote:
>> I requested you to include this patch but now am not sure anymore.
>> Looks like there are almost 30 more users which are directly
>> tweaking 'tasklet_struct' fields and calling other APIs. Hunting them
>> and fixing them probably would be an exercise and also those changes
>> needs those changed drivers to be tested.
>>
>> What do you suggest ? At least this patch needs to be dropped as of now
>> till we can have complete coverage for those bad users.
>
> Yes, it needs to be dropped. Stephen, can you please revert it from next?
>
> How to fix this: The only way is to review all tasklet usage sites for
> creative abuse and then fix them one by one. This needs to be done anyway
> because those are ticking timebombs even without changes in the core
> code. I looked at one of the offenders and it's broken today, it's just
> protected by the extremly low probablity to hit the wreckage case.
>
> What you can do to coerce the developers/maintainers of offending code into
> looking at the mess they created/merged is to implement accessors for the
> tasklet struct fields and replace the open coded fiddling with them.
>
> Once that is done, rename the struct fields to something which is absurd
> enough to type. But don't worry, you will find people doing that. I
> catched a few brainwrecks who actually used:
>
> irqdesc->core_internal_state__do_not_mess_with_it
>
> in their code.
>
> Now after having everything converted to accessors, you can add sanity
> checks into the accessors and emit WARN_ONCE() when they are used in the
> wrong context. That'll make them look and explain why they think that
> fiddling in the internals is a good idea.
>
> Thanks,
>
> tglx
> ------------------------------------------------------------------
>
^ permalink raw reply
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Bjorn Helgaas @ 2016-09-23 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1b1c38f-0779-82a5-5d3c-b164215a4ed3@codeaurora.org>
On Fri, Sep 23, 2016 at 02:41:39PM -0400, Christopher Covington wrote:
> On 09/22/2016 07:08 PM, Bjorn Helgaas wrote:
> > On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote:
> >> Hi Bjorn,
> >>
> >> On 09/21/2016 09:11 AM, Bjorn Helgaas wrote:
> >>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
> >>
> >>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> >>>>> index eb14f74..bb3b8ad 100644
> >>>>> --- a/drivers/acpi/pci_mcfg.c
> >>>>> +++ b/drivers/acpi/pci_mcfg.c
> >>>>> @@ -42,86 +42,59 @@ struct mcfg_fixup {
> >>>>> struct resource cfgres;
> >>>>> };
> >>>>>
> >>>>> -#define MCFG_DOM_ANY (-1)
> >>>>
> >>>> Did you delete this because there were no current users, because you'd
> >>>> prefer users just use "-1", or for some other reason?
> >>>
> >>> I removed it because there were no users of it and, more importantly,
> >>> the code doesn't implement support for it.
> >>
> >> It looks like a stale "First match against PCI topology <domain:bus>..."
> >> comment remains.
> >
> > Yep. I removed the comment since it's sort of obvious from the code.
> > I also renamed a few things and pulled the match out into a helper
> > function.
> >
> > I also changed the dmesg note: I think the actual resource and the
> > name of the pci_ecam_ops is more interesting than the table IDs (which
> > I think are already elsewhere in the dmesg log).
>
> It looks like the resource is already being printed from
> drivers/pci/ecam.c:102.
Yes, but I want a hint that a quirk has overridden it because that's a
clue that there's something wonky about the platform or the firmware.
But I guess it'd be nice to mirror the format of the existing info
(mem first, then bus range).
> > Here's the incremental diff, which I can't really test:
>
> Here's what it looks like for me:
>
> ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
> acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
> acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
> acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
> acpi PNP0A08:02: MCFG quirk: ECAM space for [bus 00-1f] at [mem 0xa0000000000-0xa0001ffffff] with pci_3
Is "pci_3" really the entire name? If not, what happened to the rest?
I was hoping for a symbol we could grep for.
> acpi PNP0A08:02: ECAM at [mem 0xa0000000000-0xa0001ffffff] for [bus 00-1f]
> Remapped I/O 0x00000affffff0000 to [io 0x10000-0x1ffff window]
> PCI host bridge to bus 0002:00
>
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index 245b79f..0b36bc5 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -36,7 +36,7 @@ struct mcfg_fixup {
> > char oem_id[ACPI_OEM_ID_SIZE + 1];
> > char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> > u32 oem_revision;
> > - u16 seg;
> > + u16 segment;
> > struct resource bus_range;
> > struct pci_ecam_ops *ops;
> > struct resource cfgres;
> > @@ -102,30 +102,37 @@ static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> > static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> > static u32 mcfg_oem_revision;
> >
> > -static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
> > +static int pci_mcfg_quirk_matches(struct mcfg_fixup *f, u16 segment,
> > + struct resource *bus_range)
> > +{
> > + if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> > + !memcmp(f->oem_table_id, mcfg_oem_table_id,
> > + ACPI_OEM_TABLE_ID_SIZE) &&
> > + f->oem_revision == mcfg_oem_revision &&
> > + f->segment == segment &&
> > + resource_contains(&f->bus_range, bus_range))
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> > +static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
> > struct resource *cfgres,
> > struct pci_ecam_ops **ecam_ops)
> > {
> > + u16 segment = root->segment;
> > + struct resource *bus_range = &root->secondary;
> > struct mcfg_fixup *f;
> > int i;
> >
> > - /*
> > - * First match against PCI topology <domain:bus> then use OEM ID, OEM
> > - * table ID, and OEM revision from MCFG table standard header.
> > - */
> > for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
> > - if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> > - !memcmp(f->oem_table_id, mcfg_oem_table_id,
> > - ACPI_OEM_TABLE_ID_SIZE) &&
> > - f->oem_revision == mcfg_oem_revision &&
> > - f->seg == root->segment &&
> > - resource_contains(&f->bus_range, &root->secondary)) {
> > + if (pci_mcfg_quirk_matches(f, segment, bus_range)) {
> > if (f->cfgres.start)
> > *cfgres = f->cfgres;
> > if (f->ops)
> > *ecam_ops = f->ops;
> > - dev_info(&root->device->dev, "Applying PCI MCFG quirks for %s %s rev: %d\n",
> > - f->oem_id, f->oem_table_id, f->oem_revision);
> > + dev_info(&root->device->dev, "MCFG quirk: ECAM space for %pR at %pR with %ps\n",
> > + bus_range, cfgres, *ecam_ops);
> > return;
> > }
> > }
> > @@ -173,7 +180,7 @@ skip_lookup:
> > * MCFG does not have it. Invalid CFG start address means MCFG
> > * firmware bug or we need another quirk in array.
> > */
> > - pci_mcfg_match_quirks(root, &res, &ops);
> > + pci_mcfg_apply_quirks(root, &res, &ops);
> > if (!res.start)
> > return -ENXIO;
> >
> >
>
>
> --
> 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
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Christopher Covington @ 2016-09-23 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923191710.GB16019@localhost>
On 09/23/2016 03:17 PM, Bjorn Helgaas wrote:
> On Fri, Sep 23, 2016 at 02:41:39PM -0400, Christopher Covington wrote:
>> On 09/22/2016 07:08 PM, Bjorn Helgaas wrote:
>>> On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote:
>>>> Hi Bjorn,
>>>>
>>>> On 09/21/2016 09:11 AM, Bjorn Helgaas wrote:
>>>>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index eb14f74..bb3b8ad 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -42,86 +42,59 @@ struct mcfg_fixup {
>>>>>>> struct resource cfgres;
>>>>>>> };
>>>>>>>
>>>>>>> -#define MCFG_DOM_ANY (-1)
>>>>>>
>>>>>> Did you delete this because there were no current users, because you'd
>>>>>> prefer users just use "-1", or for some other reason?
>>>>>
>>>>> I removed it because there were no users of it and, more importantly,
>>>>> the code doesn't implement support for it.
>>>>
>>>> It looks like a stale "First match against PCI topology <domain:bus>..."
>>>> comment remains.
>>>
>>> Yep. I removed the comment since it's sort of obvious from the code.
>>> I also renamed a few things and pulled the match out into a helper
>>> function.
>>>
>>> I also changed the dmesg note: I think the actual resource and the
>>> name of the pci_ecam_ops is more interesting than the table IDs (which
>>> I think are already elsewhere in the dmesg log).
>>
>> It looks like the resource is already being printed from
>> drivers/pci/ecam.c:102.
>
> Yes, but I want a hint that a quirk has overridden it because that's a
> clue that there's something wonky about the platform or the firmware.
>
> But I guess it'd be nice to mirror the format of the existing info
> (mem first, then bus range).
>
>>> Here's the incremental diff, which I can't really test:
>>
>> Here's what it looks like for me:
>>
>> ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>> acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
>> acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
>> acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
>> acpi PNP0A08:02: MCFG quirk: ECAM space for [bus 00-1f] at [mem 0xa0000000000-0xa0001ffffff] with pci_3
>
> Is "pci_3" really the entire name? If not, what happened to the rest?
> I was hoping for a symbol we could grep for.
The full name is pci_32b_ops. The print overflowed my tmux pane.
>> acpi PNP0A08:02: ECAM at [mem 0xa0000000000-0xa0001ffffff] for [bus 00-1f]
>> Remapped I/O 0x00000affffff0000 to [io 0x10000-0x1ffff window]
>> PCI host bridge to bus 0002:00
Thanks,
Cov
--
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
* [PATCH] serial: stm32: use mapbase instead of membase for DMA
From: Arnd Bergmann @ 2016-09-23 19:38 UTC (permalink / raw)
To: linux-arm-kernel
Building this driver with a 64-bit dma_addr_t type results in
a compiler warning:
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_rx_probe':
drivers/tty/serial/stm32-usart.c:746:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_tx_probe':
drivers/tty/serial/stm32-usart.c:818:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
While the type conversion here is harmless, this hints at a different
problem: we pass an __iomem pointer into a DMA engine, which expects
a phys_addr_t. This happens to work because stm32 has no MMU and
ioremap() is an identity mapping here, but it's still an incorrect
API use. Using dma_addr_t is doubly wrong here, because that would
be the result of dma_map_single() rather than the physical address.
Using the mapbase instead fixes multiple issues:
- the warning is gone
- we don't go through ioremap in error
- the cast is gone, making it use the correct resource_size_t/phys_addr_t
type in the process.
Fixes: 3489187204eb ("serial: stm32: adding dma support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/tty/serial/stm32-usart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 4d3001b77e7e..2adb678a863b 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -743,7 +743,7 @@ static int stm32_of_dma_rx_probe(struct stm32_port *stm32port,
/* Configure DMA channel */
memset(&config, 0, sizeof(config));
- config.src_addr = (dma_addr_t)port->membase + ofs->rdr;
+ config.src_addr = port->mapbase + ofs->rdr;
config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
ret = dmaengine_slave_config(stm32port->rx_ch, &config);
@@ -815,7 +815,7 @@ static int stm32_of_dma_tx_probe(struct stm32_port *stm32port,
/* Configure DMA channel */
memset(&config, 0, sizeof(config));
- config.dst_addr = (dma_addr_t)port->membase + ofs->tdr;
+ config.dst_addr = port->mapbase + ofs->tdr;
config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
ret = dmaengine_slave_config(stm32port->tx_ch, &config);
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] firmware: dt: document lpc1850 boot ROM bindings
From: Joachim Eastwood @ 2016-09-23 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923133949.GA24505@rob-hp-laptop>
On 23 September 2016 at 15:39, Rob Herring <robh@kernel.org> wrote:
> On Tue, Sep 13, 2016 at 09:51:16PM +0200, Joachim Eastwood wrote:
>> Binding documentation for the NXP LPC boot ROM.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> .../devicetree/bindings/firmware/nxp,boot-rom.txt | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>> new file mode 100644
>> index 0000000..5f3a044
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>> @@ -0,0 +1,21 @@
>> +* NXP LPC boot ROM
>> +
>> +NXP LPC microcontrollers contains a boot ROM used to retrieve part information
>> +and access internal Flash memory and OTP memory. Note that the Flash API is
>> +not available on Flashless devices.
>
> Is this determined at run-time? If not flashless devices should have a
> different compatible string to determine this then.
It is determined at run time by reading a 'CHIP ID' register in CREG
(syscon) that is present on both Flash and Flashless devices.
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH 2/3] nvmem: dt: document lpc1850 OTP binding
From: Joachim Eastwood @ 2016-09-23 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923133529.GA23548@rob-hp-laptop>
On 23 September 2016 at 15:35, Rob Herring <robh@kernel.org> wrote:
> On Tue, Sep 13, 2016 at 06:12:40PM +0200, Joachim Eastwood wrote:
>> Documenation for the LPC18xx/43xx OTP memory bindings.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> .../devicetree/bindings/nvmem/lpc1850-otp.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>> new file mode 100644
>> index 0000000..853b6a7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>> @@ -0,0 +1,20 @@
>> +* NXP LPC18xx OTP memory
>> +
>> +Internal OTP (One Time Programmable) memory for NXP LPC18xx/43xx devices.
>> +
>> +Required properties:
>> + - compatible: Should be "nxp,lpc1850-otp"
>> + - reg: Must contain an entry with the physical base address and length
>> + for each entry in reg-names.
>
>> + - address-cells: must be set to 1.
>> + - size-cells: must be set to 1.
>
> Not needed unless you have child nodes.
They will have "nvmem" cell children. See patch 3/3
+ /* Flashless devices has part ID in OTP bank 0 */
+ part_id: identification at 0 {
+ reg = <0x0 0x10>;
+ };
These cells are documented in nvmem.txt.
regards,
Joachim Eastwood
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Uwe Kleine-König @ 2016-09-23 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183725.GC1041@n2100.armlinux.org.uk>
Hello Russell,
On Fri, Sep 23, 2016 at 07:37:25PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote:
> > So the question is: should we just live with this and acknowledge a
> > performance penalty of bad alignment or do something about it?
>
> Well, I've no interest in trying to do anything with the FEC driver
> anymore, as I'll just generate another big patch stack which won't
> make it into the kernel in a timely fashion - my last attempt at
> improving the FEC driver was dogged with conflicting changes and I
> gave up with it in the end. I ended up spending a full cycle
> rebasing, re-testing, and re-evaluating their performance only to find
> that I'd missed the merge window again, and other conflicting changes
> got merged which meant that I had to start from the beginning again.
I'm not included in the set of people who are responsible to review and
merge fec patches, but I'd be surprised if you couldn't get an exclusive
lock for that driver. Something like: After 4.X-rc1 the fec isn't
touched any more until you got your series ready for the 4.X+1 merge
window. Of course some fixes might have to go in, but these hopefully
won't disturb much.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/mioa701.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 38a96a193dc4..8a5d0491e73c 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -57,7 +57,6 @@
#include <linux/platform_data/media/camera-pxa.h>
#include <mach/audio.h>
#include <mach/smemc.h>
-#include <media/soc_camera.h>
#include "mioa701.h"
@@ -627,6 +626,8 @@ struct pxacamera_platform_data mioa701_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 5000,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
static struct i2c_board_info __initdata mioa701_pi2c_devices[] = {
@@ -643,12 +644,6 @@ static struct i2c_board_info mioa701_i2c_devices[] = {
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0, /* Match id in pxa27x_device_camera in device.c */
- .board_info = &mioa701_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
struct i2c_pxa_platform_data i2c_pdata = {
.fast_mode = 1,
};
@@ -684,7 +679,6 @@ MIO_SIMPLE_DEV(mioa701_sound, "mioa701-wm9713", NULL)
MIO_SIMPLE_DEV(mioa701_board, "mioa701-board", NULL)
MIO_SIMPLE_DEV(wm9713_acodec, "wm9713-codec", NULL);
MIO_SIMPLE_DEV(gpio_vbus, "gpio-vbus", &gpio_vbus_data);
-MIO_SIMPLE_DEV(mioa701_camera, "soc-camera-pdrv",&iclink);
static struct platform_device *devices[] __initdata = {
&mioa701_gpio_keys,
@@ -696,7 +690,6 @@ static struct platform_device *devices[] __initdata = {
&power_dev,
&docg3,
&gpio_vbus,
- &mioa701_camera,
&mioa701_board,
};
@@ -761,6 +754,7 @@ static void __init mioa701_machine_init(void)
platform_add_devices(devices, ARRAY_SIZE(devices));
gsm_init();
+ i2c_register_board_info(0, ARRAY_AND_SIZE(mioa701_i2c_devices));
i2c_register_board_info(1, ARRAY_AND_SIZE(mioa701_pi2c_devices));
pxa_set_i2c_info(&i2c_pdata);
pxa27x_set_i2c_power_info(NULL);
@@ -769,6 +763,7 @@ static void __init mioa701_machine_init(void)
regulator_register_always_on(0, "fixed-5.0V", fixed_5v0_consumers,
ARRAY_SIZE(fixed_5v0_consumers),
5000000);
+ regulator_has_full_constraints();
}
static void mioa701_machine_exit(void)
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] ARM: pxa: ezx: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-1-git-send-email-robert.jarzmik@free.fr>
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/ezx.c | 176 ++++++++++++++++++++----------------------------
1 file changed, 72 insertions(+), 104 deletions(-)
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 34ad0a89d4a9..0b8300e6fca3 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -17,14 +17,14 @@
#include <linux/delay.h>
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <linux/input.h>
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
#include <linux/leds-lp3944.h>
#include <linux/i2c/pxa-i2c.h>
-#include <media/soc_camera.h>
-
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -723,6 +723,42 @@ static struct platform_device a780_gpio_keys = {
};
/* camera */
+static struct regulator_consumer_supply camera_dummy_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "0-005d"),
+};
+
+static struct regulator_init_data camera_dummy_initdata = {
+ .consumer_supplies = camera_dummy_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(camera_dummy_supplies),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config camera_dummy_config = {
+ .supply_name = "camera_vdd",
+ .microvolts = 2800000,
+ .gpio = GPIO50_nCAM_EN,
+ .enable_high = 0,
+ .init_data = &camera_dummy_initdata,
+};
+
+static struct platform_device camera_supply_dummy_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &camera_dummy_config,
+ },
+};
+static int a780_camera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
+ msleep(10);
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
+
+ return 0;
+}
+
static int a780_camera_init(void)
{
int err;
@@ -731,73 +767,36 @@ static int a780_camera_init(void)
* GPIO50_nCAM_EN is active low
* GPIO19_GEN1_CAM_RST is active on rising edge
*/
- err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
- if (err) {
- pr_err("%s: Failed to request nCAM_EN\n", __func__);
- goto fail;
- }
-
err = gpio_request(GPIO19_GEN1_CAM_RST, "CAM_RST");
if (err) {
pr_err("%s: Failed to request CAM_RST\n", __func__);
- goto fail_gpio_cam_rst;
+ return err;
}
- gpio_direction_output(GPIO50_nCAM_EN, 1);
gpio_direction_output(GPIO19_GEN1_CAM_RST, 0);
-
- return 0;
-
-fail_gpio_cam_rst:
- gpio_free(GPIO50_nCAM_EN);
-fail:
- return err;
-}
-
-static int a780_camera_power(struct device *dev, int on)
-{
- gpio_set_value(GPIO50_nCAM_EN, !on);
- return 0;
-}
-
-static int a780_camera_reset(struct device *dev)
-{
- gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
- msleep(10);
- gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
+ a780_camera_reset(NULL);
return 0;
}
struct pxacamera_platform_data a780_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN |
+ PXA_CAMERA_PCP,
.mclk_10khz = 5000,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
-static struct i2c_board_info a780_camera_i2c_board_info = {
- I2C_BOARD_INFO("mt9m111", 0x5d),
-};
-
-static struct soc_camera_link a780_iclink = {
- .bus_id = 0,
- .flags = SOCAM_SENSOR_INVERT_PCLK,
- .i2c_adapter_id = 0,
- .board_info = &a780_camera_i2c_board_info,
- .power = a780_camera_power,
- .reset = a780_camera_reset,
-};
-
-static struct platform_device a780_camera = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &a780_iclink,
+static struct i2c_board_info a780_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO("mt9m111", 0x5d),
},
};
static struct platform_device *a780_devices[] __initdata = {
&a780_gpio_keys,
+ &camera_supply_dummy_device,
};
static void __init a780_init(void)
@@ -811,19 +810,19 @@ static void __init a780_init(void)
pxa_set_stuart_info(NULL);
pxa_set_i2c_info(NULL);
+ i2c_register_board_info(0, ARRAY_AND_SIZE(a780_i2c_board_info));
pxa_set_fb_info(NULL, &ezx_fb_info_1);
pxa_set_keypad_info(&a780_keypad_platform_data);
- if (a780_camera_init() == 0) {
+ if (a780_camera_init() == 0)
pxa_set_camera_info(&a780_pxacamera_platform_data);
- platform_device_register(&a780_camera);
- }
pwm_add_table(ezx_pwm_lookup, ARRAY_SIZE(ezx_pwm_lookup));
platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
platform_add_devices(ARRAY_AND_SIZE(a780_devices));
+ regulator_has_full_constraints();
}
MACHINE_START(EZX_A780, "Motorola EZX A780")
@@ -1001,6 +1000,15 @@ static struct platform_device a910_gpio_keys = {
};
/* camera */
+static int a910_camera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO28_GEN2_CAM_RST, 0);
+ msleep(10);
+ gpio_set_value(GPIO28_GEN2_CAM_RST, 1);
+
+ return 0;
+}
+
static int a910_camera_init(void)
{
int err;
@@ -1009,68 +1017,25 @@ static int a910_camera_init(void)
* GPIO50_nCAM_EN is active low
* GPIO28_GEN2_CAM_RST is active on rising edge
*/
- err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
- if (err) {
- pr_err("%s: Failed to request nCAM_EN\n", __func__);
- goto fail;
- }
-
err = gpio_request(GPIO28_GEN2_CAM_RST, "CAM_RST");
if (err) {
pr_err("%s: Failed to request CAM_RST\n", __func__);
- goto fail_gpio_cam_rst;
+ return err;
}
- gpio_direction_output(GPIO50_nCAM_EN, 1);
gpio_direction_output(GPIO28_GEN2_CAM_RST, 0);
-
- return 0;
-
-fail_gpio_cam_rst:
- gpio_free(GPIO50_nCAM_EN);
-fail:
- return err;
-}
-
-static int a910_camera_power(struct device *dev, int on)
-{
- gpio_set_value(GPIO50_nCAM_EN, !on);
- return 0;
-}
-
-static int a910_camera_reset(struct device *dev)
-{
- gpio_set_value(GPIO28_GEN2_CAM_RST, 0);
- msleep(10);
- gpio_set_value(GPIO28_GEN2_CAM_RST, 1);
+ a910_camera_reset(NULL);
return 0;
}
struct pxacamera_platform_data a910_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN |
+ PXA_CAMERA_PCP,
.mclk_10khz = 5000,
-};
-
-static struct i2c_board_info a910_camera_i2c_board_info = {
- I2C_BOARD_INFO("mt9m111", 0x5d),
-};
-
-static struct soc_camera_link a910_iclink = {
- .bus_id = 0,
- .i2c_adapter_id = 0,
- .board_info = &a910_camera_i2c_board_info,
- .power = a910_camera_power,
- .reset = a910_camera_reset,
-};
-
-static struct platform_device a910_camera = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &a910_iclink,
- },
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
/* leds-lp3944 */
@@ -1122,10 +1087,14 @@ static struct i2c_board_info __initdata a910_i2c_board_info[] = {
I2C_BOARD_INFO("lp3944", 0x60),
.platform_data = &a910_lp3944_leds,
},
+ {
+ I2C_BOARD_INFO("mt9m111", 0x5d),
+ },
};
static struct platform_device *a910_devices[] __initdata = {
&a910_gpio_keys,
+ &camera_supply_dummy_device,
};
static void __init a910_init(void)
@@ -1145,14 +1114,13 @@ static void __init a910_init(void)
pxa_set_keypad_info(&a910_keypad_platform_data);
- if (a910_camera_init() == 0) {
+ if (a910_camera_init() == 0)
pxa_set_camera_info(&a910_pxacamera_platform_data);
- platform_device_register(&a910_camera);
- }
pwm_add_table(ezx_pwm_lookup, ARRAY_SIZE(ezx_pwm_lookup));
platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
platform_add_devices(ARRAY_AND_SIZE(a910_devices));
+ regulator_has_full_constraints();
}
MACHINE_START(EZX_A910, "Motorola EZX A910")
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] ARM: pxa: em-x270: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-1-git-send-email-robert.jarzmik@free.fr>
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/em-x270.c | 85 ++++++++++++++-------------------------------
1 file changed, 27 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 03354c21e1f2..2d7762ab1d70 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -34,8 +34,6 @@
#include <linux/i2c/pxa-i2c.h>
#include <linux/regulator/userspace-consumer.h>
-#include <media/soc_camera.h>
-
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -969,81 +967,52 @@ static int em_x270_sensor_init(void)
return ret;
gpio_direction_output(cam_reset, 0);
-
- em_x270_camera_ldo = regulator_get(NULL, "vcc cam");
- if (em_x270_camera_ldo == NULL) {
- gpio_free(cam_reset);
- return -ENODEV;
- }
-
- ret = regulator_enable(em_x270_camera_ldo);
- if (ret) {
- regulator_put(em_x270_camera_ldo);
- gpio_free(cam_reset);
- return ret;
- }
-
gpio_set_value(cam_reset, 1);
return 0;
}
-struct pxacamera_platform_data em_x270_camera_platform_data = {
- .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
- .mclk_10khz = 2600,
+static struct regulator_consumer_supply camera_dummy_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "0-005d"),
};
-static int em_x270_sensor_power(struct device *dev, int on)
-{
- int ret;
- int is_on = regulator_is_enabled(em_x270_camera_ldo);
-
- if (on == is_on)
- return 0;
-
- gpio_set_value(cam_reset, !on);
-
- if (on)
- ret = regulator_enable(em_x270_camera_ldo);
- else
- ret = regulator_disable(em_x270_camera_ldo);
-
- if (ret)
- return ret;
-
- gpio_set_value(cam_reset, on);
-
- return 0;
-}
-
-static struct i2c_board_info em_x270_i2c_cam_info[] = {
- {
- I2C_BOARD_INFO("mt9m111", 0x48),
+static struct regulator_init_data camera_dummy_initdata = {
+ .consumer_supplies = camera_dummy_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(camera_dummy_supplies),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0,
- .power = em_x270_sensor_power,
- .board_info = &em_x270_i2c_cam_info[0],
- .i2c_adapter_id = 0,
+static struct fixed_voltage_config camera_dummy_config = {
+ .supply_name = "camera_vdd",
+ .input_supply = "vcc cam",
+ .microvolts = 2800000,
+ .gpio = GPIO56_MT9M111_nOE,
+ .enable_high = 0,
+ .init_data = &camera_dummy_initdata,
};
-static struct platform_device em_x270_camera = {
- .name = "soc-camera-pdrv",
- .id = -1,
+static struct platform_device camera_supply_dummy_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
.dev = {
- .platform_data = &iclink,
+ .platform_data = &camera_dummy_config,
},
};
+struct pxacamera_platform_data em_x270_camera_platform_data = {
+ .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ .mclk_10khz = 2600,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
+};
+
static void __init em_x270_init_camera(void)
{
- if (em_x270_sensor_init() == 0) {
+ if (em_x270_sensor_init() == 0)
pxa_set_camera_info(&em_x270_camera_platform_data);
- platform_device_register(&em_x270_camera);
- }
}
#else
static inline void em_x270_init_camera(void) {}
--
2.1.4
^ permalink raw reply related
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Santosh Shilimkar @ 2016-09-23 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <663a8a97-f01f-ce10-b0c6-c1a5ca0f11d2@ti.com>
On 9/23/2016 12:05 PM, Peter Ujfalusi wrote:
> On 09/23/2016 06:24 PM, Santosh Shilimkar wrote:
>> On 9/23/2016 7:26 AM, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
>>>> On 09/22/16 21:07, Tony Lindgren wrote:
>>
>> [...]
>>
>>>> On which linux-next version you are seeing this?
>>>
>>> This was with next-20160922. But testing it again this is just another
>>> regression caused by "softirq: fix tasklet_kill() and its users", so adding
>>> Santosh to Cc.
>>>
>>> So no need to revert $subject patch.
>>>
>> So your driver also looks like fiddling with tasklet core structures if
>> you got impacted because of the core change.
>
> How is that? None of the drivers in the twl6040 stack uses tasklets
> explicitly. The core uses regmap_irq and the drivers use threaded irq when
> they need interrupt handling, but no tasklet, no fiddling with internals.
>
May be MFD core or some up dependency for this driver does that.
If not then you shouldn't be impacted because of the change.
Regards,
Santosh
^ permalink raw reply
* [PATCH] [media] VPU: mediatek: Fix return value in case of error
From: Christophe JAILLET @ 2016-09-23 21:19 UTC (permalink / raw)
To: linux-arm-kernel
If 'dma_alloc_coherent()' returns NULL, 'vpu_alloc_ext_mem()' will
return 0 which means success.
Return -ENOMEM instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index c9bf58c97878..3edb5ed852e6 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -674,7 +674,7 @@ static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
GFP_KERNEL);
if (!vpu->extmem[fw_type].va) {
dev_err(dev, "Failed to allocate the extended program memory\n");
- return PTR_ERR(vpu->extmem[fw_type].va);
+ return -ENOMEM;
}
/* Disable extend0. Enable extend1 */
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ASoC: rk3399_gru_sound: fix recording pop at first attempt
From: Rob Herring @ 2016-09-23 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474552206-31742-1-git-send-email-zhengxing@rock-chips.com>
On Thu, Sep 22, 2016 at 09:50:06PM +0800, Xing Zheng wrote:
> From: Wonjoon Lee <woojoo.lee@samsung.com>
>
> Pop happens when mclk applied but dmic's own boot-time
This statement doesn't make sense.
> Specify dmic delay times in dt to make sure
> clocks are ready earlier than dmic working
I don't think this really belongs in DT. Seems like better control of
the init order is needed. Or why not just a fixed delay in the driver?
>
> Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - rename dmic-delay to dmic-wakeup-delay-ms
>
> .../bindings/sound/rockchip,rk3399-gru-sound.txt | 7 +++++++
> sound/soc/rockchip/rk3399_gru_sound.c | 14 ++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> index f19b6c8..eac91db 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> @@ -6,10 +6,17 @@ Required properties:
> connected to the codecs
> - rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
>
> +Optional properties:
> +- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
> + If this option is specified, which means it's required dmic need
> + delay for DMIC to ready so that rt5514 can avoid recording before
> + DMIC send valid data
> +
> Example:
>
> sound {
> compatible = "rockchip,rk3399-gru-sound";
> rockchip,cpu = <&i2s0>;
> rockchip,codec = <&max98357a &rt5514 &da7219>;
> + dmic-wakeup-delay-ms = <20>;
> };
> diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
> index ee06489..9ed735a 100644
> --- a/sound/soc/rockchip/rk3399_gru_sound.c
> +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> @@ -38,6 +38,8 @@
>
> #define SOUND_FS 256
>
> +unsigned int rt5514_dmic_delay;
> +
> static struct snd_soc_jack rockchip_sound_jack;
>
> static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
> @@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct snd_pcm_substream *substream,
> return ret;
> }
>
> + /* Wait for DMIC stable */
> + msleep(rt5514_dmic_delay);
> +
> return 0;
> }
>
> @@ -343,6 +348,15 @@ static int rockchip_sound_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + /* Set DMIC delay */
> + ret = device_property_read_u32(&pdev->dev, "dmic-delay",
Obviously, this doesn't work now...
> + &rt5514_dmic_delay);
> + if (ret) {
> + rt5514_dmic_delay = 0;
> + dev_dbg(&pdev->dev,
> + "no optional property 'dmic-delay' found, default: no delay\n");
> + }
> +
> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH] clk: zx296718: register driver earlier with core_initcall
From: Stephen Boyd @ 2016-09-23 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474595108-15790-1-git-send-email-shawn.guo@linaro.org>
On 09/23, Shawn Guo wrote:
> Clock driver should be registered with an earlier initcall than
> module_init which is used by most of client device drivers. Otherwise,
> probing of these client drivers will likely be deferred due to that
> calls into clk API will return -EPROBE_DEFER.
>
> Deferred probing is not a problem for most subsystems, but could bring
> some side effect for particular subsystem, like display. On ZX296718
> platform, we get Linux logo and boot log lost from display device, just
> because the DRM/KMS driver gets -EPROBE_DEFER from devm_clk_get() call.
>
> Let's use core_initcall (qcom and a few other clk drivers use that) for
> driver registration to avoid those unnecessary -EPROBE_DEFER and get rid
> of the side effect with ZX296718 display system.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Not the ideal solution but it'll do for now.
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/3] clk: mvebu: fix setting unwanted flags in CP110 gate clock
From: Stephen Boyd @ 2016-09-23 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-2-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> Armada CP110 system controller comprises its own routine responsble
> for registering gate clocks. Among others 'flags' field in
> struct clk_init_data was not set, using a random values, which
> may cause an unpredicted behavior.
>
> This patch fixes the problem by resetting all fields of clk_init_data
> before assigning values for all gated clocks of Armada 7k/8k SoCs family.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> CC: <stable@vger.kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 2/3] clk: mvebu: dynamically allocate resources in Armada CP110 system controller
From: Stephen Boyd @ 2016-09-23 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-3-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> Original commit, which added support for Armada CP110 system controller
> used global variables for storing all clock information. It worked
> fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
> was introduced, the data got overwritten and corrupted.
>
> This patch fixes the issue by allocating resources dynamically in the
> driver probe and storing it as platform drvdata.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> CC: <stable@vger.kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-09-23 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-4-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
> - CP110_CLK_NUM, GFP_KERNEL);
> - if (!cp110_clks)
> - return -ENOMEM;
> -
> - cp110_clk_data = devm_kzalloc(&pdev->dev,
> - sizeof(*cp110_clk_data),
> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
> GFP_KERNEL);
This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
way?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Marcin Wojtas @ 2016-09-23 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923214730.GF21232@codeaurora.org>
Hi Stephen,
2016-09-23 23:47 GMT+02:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 09/21, Marcin Wojtas wrote:
>> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
>> - CP110_CLK_NUM, GFP_KERNEL);
>> - if (!cp110_clks)
>> - return -ENOMEM;
>> -
>> - cp110_clk_data = devm_kzalloc(&pdev->dev,
>> - sizeof(*cp110_clk_data),
>> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
>> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
>> GFP_KERNEL);
>
> This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
> way?
After some time, at a first sight it seems I should've used following:
cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
sizeof(struct
clk_hw *) * CP110_CLK_NUM,
GFP_KERNEL);
I'll re-check, but is that what you meant?
Best regards,
Marcin
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-09-23 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKfDrtDDMPi4oBmpNN_+b4mvG6cVnZT7pNTo8tcNUyzwyA@mail.gmail.com>
On 09/24, Marcin Wojtas wrote:
> Hi Stephen,
>
> 2016-09-23 23:47 GMT+02:00 Stephen Boyd <sboyd@codeaurora.org>:
> > On 09/21, Marcin Wojtas wrote:
> >> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
> >> if (ret)
> >> return ret;
> >>
> >> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
> >> - CP110_CLK_NUM, GFP_KERNEL);
> >> - if (!cp110_clks)
> >> - return -ENOMEM;
> >> -
> >> - cp110_clk_data = devm_kzalloc(&pdev->dev,
> >> - sizeof(*cp110_clk_data),
> >> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
> >> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
> >> GFP_KERNEL);
> >
> > This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
> > way?
>
> After some time, at a first sight it seems I should've used following:
> cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
> sizeof(struct
> clk_hw *) * CP110_CLK_NUM,
> GFP_KERNEL);
>
> I'll re-check, but is that what you meant?
Yes that looks better.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
From: Fabio Estevam @ 2016-09-23 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474036587-13819-3-git-send-email-fabio.estevam@nxp.com>
Hi Stephen,
On Fri, Sep 16, 2016 at 11:36 AM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
> tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
> enter the ldb_di_ipu_div divider. If the divider gets locked up, no
> ldb_di[x]_clk is generated, and the LVDS display will hang when the
> ipu_di_clk is sourced from ldb_di_clk.
>
> To fix the problem, both the new and current parent of the ldb_di_clk
> should be disabled before the switch. This patch ensures that correct
> steps are followed when ldb_di_clk parent is switched in the beginning
> of boot. The glitchy muxes are then registered as read-only. The clock
> parent can be selected using the assigned-clocks and
> assigned-clock-parents properties of the ccm device tree node:
>
> &clks {
> assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> assigned-clock-parents = <&clks IMX6QDL_CLK_MMDC_CH1_AXI>,
> <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
> };
>
> The issue is explained in detail in EB821 ("LDB Clock Switch Procedure &
> i.MX6 Asynchronous Clock Switching Guidelines") [1].
>
> [1] http://www.nxp.com/files/32bit/doc/eng_bulletin/EB821.pdf
>
> Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan@nxp.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Reviewed-by: Akshay Bhat <akshay.bhat@timesys.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Tested-by: Charles Kang <Charles.Kang@advantech.com.tw>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Do you think this one could be applied to clk-next? It fixes an
important LVDS bug.
Thanks
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-23 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKNFzo6RWJO5WOvsyO3e4UTo5Zn48aaDac=+uL_CQWerQ@mail.gmail.com>
On Fri, Sep 23, 2016 at 10:01:13AM -0500, Rob Herring wrote:
> On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
> >> This patchset adds a specific compatible string in the Meson I2C driver
> >> for the Amlogic Meson gxbb SoC.
> >>
> >> Other patch series (pinctrl and device tree) are being sent to complete
> >> the i2c support on meson gxbb
> >>
> >> Neil Armstrong (2):
> >> i2c: meson: add gxbb compatible string
> >> dt-bindings: i2c-meson: add gxbb compatible string
> >
> > Squashed both patches and applied to for-next, thanks!
>
> Please don't squash. We ask people to split DT bindings for a reason
> being reviews and bindings may not go thru subsystem maintainers in
> the future. It also makes it harder to find things in the archives or
> patchwork (as does maintainer fixups of subject lines).
I intentionally don't ask people to send me the patches squashed. So,
you will have them seperate in patchwork et al. I only squash them just
before commiting to my tree. That's because I found that when digging
through git history, it is much more convenient to have all the
information in one commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/4c831195/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/4] regulator: axp20x: add the AXP803
From: Rob Herring @ 2016-09-23 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c9e5c21df09a1feb1b00aa000c3c0f77e51eac3.1474621107.git.moinejf@free.fr>
On Fri, Sep 23, 2016 at 09:00:42AM +0200, Jean-Francois Moine wrote:
> The X-Powers AXP803 PMIC is close to the AXP809 with more outputs.
> It is used in some Allwinner boards as the Sinovoip BananaPi M64
> and the Pine A64.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> not tested
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 32 +++-
> drivers/mfd/axp20x.c | 13 ++
> drivers/regulator/Makefile | 3 +-
> drivers/regulator/axp803.c | 225 +++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 1 +
> 5 files changed, 271 insertions(+), 3 deletions(-)
> create mode 100644 drivers/regulator/axp803.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 8f3ad9a..3332d02 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,12 +6,13 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> + "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
> + "x-powers,axp806", "x-powers,axp809"
If you respin this, please reformat this to one per line.
Acked-by: Rob Herring <robh@kernel.org>
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> @@ -86,6 +87,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply
> +DCDC3 : DC-DC buck : vin3-supply
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply
> +DCDC6 : DC-DC buck : vin6-supply
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +RTC_LDO : LDO : ips-supply : always on
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
^ permalink raw reply
* [PATCH v3 4/4] regulator: axp20x: add the AXP813
From: Rob Herring @ 2016-09-23 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21ac1fd8ab33185ec2cdb436272f48571695ce54.1474621108.git.moinejf@free.fr>
On Fri, Sep 23, 2016 at 09:22:41AM +0200, Jean-Francois Moine wrote:
> The X-Powers AXP813 PMIC is close to the AXP803.
> It is used in some Allwinner boards as the Sinovoip BananaPi M3+.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +-
> drivers/mfd/axp20x.c | 2 +
> drivers/regulator/Makefile | 2 +-
> drivers/regulator/axp813.c | 229 +++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 1 +
> 5 files changed, 239 insertions(+), 4 deletions(-)
> create mode 100644 drivers/regulator/axp813.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 3332d02..62019fb 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -8,11 +8,12 @@ axp221 (X-Powers)
> axp223 (X-Powers)
> axp803 (X-Powers)
> axp809 (X-Powers)
> +axp813 (X-Powers)
>
> Required properties:
> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
> - "x-powers,axp806", "x-powers,axp809"
> + "x-powers,axp806", "x-powers,axp809", "x-powers,axp813"
Same comment here.
Acked-by: Rob Herring <robh@kernel.org>
^ 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