* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-05-29 18:03 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-arm-kernel, Scott Branden, Ray Jui, linux-kernel, linux-spi,
Mark Brown, bcm-kernel-feedback-list, linux-rpi-kernel,
Martin Sperl, Nicolas Saenz Julienne
In-Reply-To: <20200529175350.2wtoqttipa354m2m@wunner.de>
On 5/29/20 10:53 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:43 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
>>>> --- a/drivers/spi/spi-bcm2835.c
>>>> +++ b/drivers/spi/spi-bcm2835.c
>>>> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
>>>> if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>>>> bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>>>>
>>>> + /* check if we got interrupt enabled */
>>>> + if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
>>>> + return IRQ_NONE;
>>>> +
>>>> /* Read as many bytes as possible from FIFO */
>>>> bcm2835_rd_fifo(bs);
>>>> /* Write as many bytes as possible to FIFO */
> [...]
>>> Finally, it would be nice if the check would be optimized away when
>>> compiling for pre-RasPi4 products, maybe something like:
>>>
>>> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
>>> + return IRQ_NONE;
>>
>> Rather than keying this off ARM_LPAE or any other option, this should be
>> keyed off a compatible string, that way we can even conditionally pass
>> IRQF_SHARED to the interrupt handler if we care so much about performance.
>
> But a compatible string can't be checked at compile time, can it?
No, but you can have a different interrupt handler that it set at
runtime if you want to completely eliminate this comparison.
My point is that CONFIG_ARM_LPAE is just too brittle, there is nothing
that prevents you from using a non-LPAE kernel on the Pi 4, even PCIe
could be made to work if using super section mappings to map the PCIe
outbound space. Even on models with over 4GB of DRAM, if you are willing
to lose some of it, it can work.
>
> The point is that at the least the Foundation compiles and ships a separate
> kernel for each of the three platforms BCM2835, BCM2837, BCM2711. It's
> unnecessary to check whether an interrupt was actually raised if we *know*
> in advance that it's not shared (as is the case with kernels compiled for
> BCM2835 and BCM2837).
I am fine with any solution that does not involve keying off
CONFIG_ARM_LPAE to discriminate 2711 from any other chip.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2: Use custom soc attribute group instead of device_create_file
From: Tony Lindgren @ 2020-05-29 18:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, linux-omap, Arnd Bergmann, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200523170859.50003-9-sudeep.holla@arm.com>
* Sudeep Holla <sudeep.holla@arm.com> [200523 17:10]:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
>
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
>
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.
Acked-by: Tony Lindgren <tony@atomide.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-05-29 17:55 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Heikki Krogerus,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
Julien Grall, Christoph Hellwig, Stefano Stabellini,
Saravana Kannan, Rafael J. Wysocki,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Alan Stern,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Corey Minyard,
Suzuki K Poulose, Mark Brown,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Dan Williams, Andy Shevchenko, moderated list:ARM PORT,
Greg Kroah-Hartman, Oliver Neukum, open list, Wolfram Sang,
open list:DMA MAPPING HELPERS, open list:USB SUBSYSTEM,
Robin Murphy, Nicolas Saenz Julienne
In-Reply-To: <20200529174858.GA2640397@bogus>
On Fri, May 29, 2020 at 1:49 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> > v2:
> > Commit: "device core: Add ability to handle multiple dma offsets"
> > o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
> > o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
> > o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
> > o dev->dma_pfn_map => dev->dma_pfn_offset_map
> > o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
> > o In device.h: s/const void */const struct dma_pfn_offset_region */
> > o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> > guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
> > o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> > dev->dma_pfn_offset_map is copied as well.
> > o Merged two of the DMA commits into one (Christoph).
> >
> > Commit "arm: dma-mapping: Invoke dma offset func if needed":
> > o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
> >
> > Other commits' changes:
> > o Removed need for carrying of_id var in priv (Nicolas)
> > o Commit message rewordings (Bjorn)
> > o Commit log messages filled to 75 chars (Bjorn)
> > o devm_reset_control_get_shared())
> > => devm_reset_control_get_optional_shared (Philipp)
> > o Add call to reset_control_assert() in PCIe remove routines (Philipp)
> >
> > v1:
> > This patchset expands the usefulness of the Broadcom Settop Box PCIe
> > controller by building upon the PCIe driver used currently by the
> > Raspbery Pi. Other forms of this patchset were submitted by me years
> > ago and not accepted; the major sticking point was the code required
> > for the DMA remapping needed for the PCIe driver to work [1].
> >
> > There have been many changes to the DMA and OF subsystems since that
> > time, making a cleaner and less intrusive patchset possible. This
> > patchset implements a generalization of "dev->dma_pfn_offset", except
> > that instead of a single scalar offset it provides for multiple
> > offsets via a function which depends upon the "dma-ranges" property of
> > the PCIe host controller. This is required for proper functionality
> > of the BrcmSTB PCIe controller and possibly some other devices.
>
> If you can enable the h/w support without the multiple offset support,
> then I'd split up this series. The latter part might take a bit more
> time.
>
> Rob
Unfortunately, the STB PCIe controller depends on the multiple PFN
offset functionality.
Thanks,
Jim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
From: Rob Herring @ 2020-05-29 17:48 UTC (permalink / raw)
To: Jim Quinlan
Cc: Ulf Hansson, Heikki Krogerus, linux-pci,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
Julien Grall, Christoph Hellwig, Stefano Stabellini,
Saravana Kannan, Rafael J. Wysocki, bcm-kernel-feedback-list,
Alan Stern, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Corey Minyard, Suzuki K Poulose, Mark Brown,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Dan Williams, Andy Shevchenko, moderated list:ARM PORT,
Greg Kroah-Hartman, Oliver Neukum, open list, Wolfram Sang,
open list:DMA MAPPING HELPERS, open list:USB SUBSYSTEM,
Robin Murphy, Nicolas Saenz Julienne
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> v2:
> Commit: "device core: Add ability to handle multiple dma offsets"
> o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
> o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
> o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
> o dev->dma_pfn_map => dev->dma_pfn_offset_map
> o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
> o In device.h: s/const void */const struct dma_pfn_offset_region */
> o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
> o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> dev->dma_pfn_offset_map is copied as well.
> o Merged two of the DMA commits into one (Christoph).
>
> Commit "arm: dma-mapping: Invoke dma offset func if needed":
> o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
>
> Other commits' changes:
> o Removed need for carrying of_id var in priv (Nicolas)
> o Commit message rewordings (Bjorn)
> o Commit log messages filled to 75 chars (Bjorn)
> o devm_reset_control_get_shared())
> => devm_reset_control_get_optional_shared (Philipp)
> o Add call to reset_control_assert() in PCIe remove routines (Philipp)
>
> v1:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
>
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible. This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller. This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.
If you can enable the h/w support without the multiple offset support,
then I'd split up this series. The latter part might take a bit more
time.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Florian Fainelli @ 2020-05-29 17:48 UTC (permalink / raw)
To: Lukas Wunner, Florian Fainelli
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Scott Branden, Ray Jui, linux-kernel, open list:SPI SUBSYSTEM,
Mark Brown,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne
In-Reply-To: <20200529174719.5tvchnoov747fm2x@wunner.de>
On 5/29/20 10:47 AM, Lukas Wunner wrote:
> On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
>> Make sure we clear the FIFOs, stop the block, disable the clock and
>> release the DMA channel.
>
> To what end? Why is this change necessary? Sorry but this seems like
> an awfully terse commit message.
To ensure clocks are disabled and to save power in low power modes used
on 7211 for instance.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Mark Brown @ 2020-05-29 17:48 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-arm-kernel, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, linux-spi, bcm-kernel-feedback-list,
linux-rpi-kernel, Martin Sperl, Nicolas Saenz Julienne
In-Reply-To: <20200529174358.som3snunfxch6phi@wunner.de>
[-- Attachment #1.1: Type: text/plain, Size: 313 bytes --]
On Fri, May 29, 2020 at 07:43:58PM +0200, Lukas Wunner wrote:
> This definitely looks wrong. The check whether the interrupt is enabled
> should be moved *before* the conditional calls to bcm2835_rd_fifo_blind()
> and bcm2835_wr_fifo_blind(), i.e. to the top of the function.
Hrm, right - I'll drop the patch.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] ARM: OMAP2: Switch to use DEVICE_ATTR_RO()
From: Tony Lindgren @ 2020-05-29 17:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, linux-omap, Arnd Bergmann, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200523170859.50003-8-sudeep.holla@arm.com>
* Sudeep Holla <sudeep.holla@arm.com> [200523 17:10]:
> Move device attributes to DEVICE_ATTR_RO() as that would make things
> a lot more "obvious" what is happening over the existing __ATTR usage.
Acked-by: Tony Lindgren <tony@atomide.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Rob Herring @ 2020-05-29 17:46 UTC (permalink / raw)
To: Jim Quinlan
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, linux-pci, open list, bcm-kernel-feedback-list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas, Christoph Hellwig, Nicolas Saenz Julienne
In-Reply-To: <20200526191303.1492-4-james.quinlan@broadcom.com>
On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> 7211 (STB version of RPi4).
> - add new property 'brcm,scb-sizes'
> - add new property 'resets'
> - add new property 'reset-names'
> - allow 'ranges' and 'dma-ranges' to have more than one item and update
> the example to show this.
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> ---
> .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 8680a0f86c5a..66a7df45983d 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -14,7 +14,13 @@ allOf:
>
> properties:
> compatible:
> - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> + items:
> + - enum:
Don't need items here. Just change the const to enum.
> + - brcm,bcm2711-pcie # The Raspberry Pi 4
> + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> + - brcm,bcm7445-pcie # Broadcom 7445 Arm
>
> reg:
> maxItems: 1
> @@ -34,10 +40,12 @@ properties:
> - const: msi
>
> ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 4
>
> dma-ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 6
>
> clocks:
> maxItems: 1
> @@ -58,8 +66,30 @@ properties:
>
> aspm-no-l0s: true
>
> + resets:
> + description: for "brcm,bcm7216-pcie", must be a valid reset
> + phandle pointing to the RESCAL reset controller provider node.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + reset-names:
> + items:
> + - const: rescal
These are going to need to be an if/then schema if they only apply to
certain compatible(s).
> +
> + brcm,scb-sizes:
> + description: (u32, u32) tuple giving the 64bit PCIe memory
> + viewport size of a memory controller. There may be up to
> + three controllers, and each size must be a power of two
> + with a size greater or equal to the amount of memory the
> + controller supports.
This sounds like what dma-ranges should express?
If not, we do have 64-bit size if that what you need.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + minItems: 2
> + maxItems: 6
> +
> required:
> - reg
> + - ranges
> - dma-ranges
> - "#interrupt-cells"
> - interrupts
> @@ -93,7 +123,9 @@ examples:
> msi-parent = <&pcie0>;
> msi-controller;
> ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> - dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
> + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
> brcm,enable-ssc;
> + brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
> };
> };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-05-29 17:46 UTC (permalink / raw)
To: Lukas Wunner, Nicolas Saenz Julienne
Cc: Scott Branden, Ray Jui, linux-kernel, linux-spi, Mark Brown,
bcm-kernel-feedback-list, linux-rpi-kernel, Martin Sperl,
linux-arm-kernel
In-Reply-To: <20200529174358.som3snunfxch6phi@wunner.de>
On 5/29/20 10:43 AM, Lukas Wunner wrote:
> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
>> --- a/drivers/spi/spi-bcm2835.c
>> +++ b/drivers/spi/spi-bcm2835.c
>> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
>> if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>> bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>>
>> + /* check if we got interrupt enabled */
>> + if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
>> + return IRQ_NONE;
>> +
>> /* Read as many bytes as possible from FIFO */
>> bcm2835_rd_fifo(bs);
>> /* Write as many bytes as possible to FIFO */
>
> This definitely looks wrong. The check whether the interrupt is enabled
> should be moved *before* the conditional calls to bcm2835_rd_fifo_blind()
> and bcm2835_wr_fifo_blind(), i.e. to the top of the function.
>
> Otherwise if an interrupt is raised by another SPI controller,
> this function may perform read/write accesses to the FIFO and
> interfere with an ongoing transfer in DMA or poll mode.
>
> Also, instead of performing an MMIO read, just use the "cs" variable
> which was assigned at the top of the function.
>
> The code comment should explain that the check is necessary because the
> interrupt may be shared with other controllers on the BCM2711.
>
> Finally, it would be nice if the check would be optimized away when
> compiling for pre-RasPi4 products, maybe something like:
>
> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
> + return IRQ_NONE;
Rather than keying this off ARM_LPAE or any other option, this should be
keyed off a compatible string, that way we can even conditionally pass
IRQF_SHARED to the interrupt handler if we care so much about performance.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer
From: Daniel Lezcano @ 2020-05-29 17:43 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
linux-omap, linux-mediatek, linux-arm-msm, linux-imx
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
lorenzo.pieralisi, khilman, steven.price, cw00.choi, mingo,
mgorman, rui.zhang, alyssa.rosenzweig, orjan.eide, daniel,
b.zolnierkie, s.hauer, rostedt, matthias.bgg, Dietmar.Eggemann,
airlied, tomeu.vizoso, qperret, sboyd, rdunlap, rjw, agross,
kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-4-lukasz.luba@arm.com>
On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
>
> Update the related users to use new function and new callback from the
> Energy Model.
>
> Acked-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Tzung-Bi Shih @ 2020-05-29 17:26 UTC (permalink / raw)
To: Mark Brown
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20200529130539.GK4610@sirena.org.uk>
On Fri, May 29, 2020 at 9:05 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 07:22:43PM +0800, Tzung-Bi Shih wrote:
> > On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > What is DMIC one wire mode? This doesn't sound like something I'd
> > > expect to vary at runtime.
>
> > It means: 1 PDM data wire carries 2 channel data (rising edge for left
> > and falling edge for right).
>
> I thought that was normal for DMICs - is this selecting between left and
> right or something?
Not sure what is the common name but use the same context here.
MT6358 accepts up to 2 PDM wires for 2 DMICs.
If one wire mode is on, MT6358 only accepts 1 PDM wire.
If one wire mode is off, MT6358 merges L/R from 2 PDM wires into 1
I2S-like to SoC.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/11] thermal: remove get_mode() operation of drivers
From: Andrzej Pietrasiewicz @ 2020-05-29 17:22 UTC (permalink / raw)
To: Guenter Roeck
Cc: Emmanuel Grumbach, Heiko Stuebner, Kalle Valo, linux-wireless,
Peter Kaestle, platform-driver-x86, Vishal Kulkarni, Luca Coelho,
Miquel Raynal, Shawn Guo, kernel, Fabio Estevam, Amit Kucheria,
linux-rockchip, Chunyan Zhang, Daniel Lezcano, linux-acpi,
linux-arm-kernel, Darren Hart, Zhang Rui, Gayatri Kammela,
NXP Linux Team, Johannes Berg, linux-pm, Sascha Hauer,
Intel Linux Wireless, Ido Schimmel, Niklas Söderlund,
Jiri Pirko, Orson Zhai, Thomas Gleixner, Allison Randal,
Support Opensource, netdev, Rafael J . Wysocki, Sebastian Reichel,
linux-renesas-soc, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Baolin Wang, Len Brown, Enrico Weigelt,
David S . Miller, Andy Shevchenko
In-Reply-To: <20200529154910.GA158174@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:49, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:45PM +0200, Andrzej Pietrasiewicz wrote:
>> get_mode() is now redundant, as the state is stored in struct
>> thermal_zone_device.
>>
>> Consequently the "mode" attribute in sysfs can always be visible, because
>> it is always possible to get the mode from struct tzd.
>>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>
> There is a slight semantic change for the two drivers which still have
> a local copy of enum thermal_device_mode: Previously trying to read the
> mode for those would return -EPERM since they don't have a get_mode
> function. Now the global value for mode is returned, but I am not sure
> if it matches the local value.
Please see my replies to your comment about patch 4/11.
Regards,
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
From: Andrzej Pietrasiewicz @ 2020-05-29 17:21 UTC (permalink / raw)
To: Guenter Roeck
Cc: Emmanuel Grumbach, Heiko Stuebner, Kalle Valo, linux-wireless,
Peter Kaestle, platform-driver-x86, Vishal Kulkarni, Luca Coelho,
Miquel Raynal, Shawn Guo, kernel, Fabio Estevam, Amit Kucheria,
linux-rockchip, Chunyan Zhang, Daniel Lezcano, linux-acpi,
linux-arm-kernel, Darren Hart, Zhang Rui, Gayatri Kammela,
NXP Linux Team, Johannes Berg, linux-pm, Sascha Hauer,
Intel Linux Wireless, Ido Schimmel, Niklas Söderlund,
Jiri Pirko, Orson Zhai, Thomas Gleixner, Allison Randal,
Support Opensource, netdev, Rafael J . Wysocki, Sebastian Reichel,
linux-renesas-soc, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Baolin Wang, Len Brown, Enrico Weigelt,
David S . Miller, Andy Shevchenko
In-Reply-To: <5010f7df-59d6-92ef-c99a-0dbd715f0ad2@collabora.com>
Hi again,
W dniu 29.05.2020 o 18:08, Andrzej Pietrasiewicz pisze:
> Hi Guenter,
>
> W dniu 29.05.2020 o 17:42, Guenter Roeck pisze:
>> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
>>> Prepare for eliminating get_mode().
>>>
>> Might be worthwhile to explain (not only in the subject) what you are
>> doing here.
>>
>>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>>> ---
>>> drivers/acpi/thermal.c | 18 ++++++----------
>>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++++++------------
>>> drivers/platform/x86/acerhdf.c | 15 ++++++-------
>>> drivers/thermal/da9062-thermal.c | 6 ++----
>>> drivers/thermal/imx_thermal.c | 17 +++++++--------
>>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++--------
>>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++++++-------
>>> drivers/thermal/thermal_of.c | 10 +++------
>>
>> After this patch is applied on top of the thermal 'testing' branch,
>> there are still local instances of thermal_device_mode in
>> drivers/thermal/st/stm_thermal.c
>> drivers/thermal/ti-soc-thermal/ti-thermal-common.c
>>
>> If there is a reason not to replace those, it might make sense to explain
>> it here.
>>
>
> My understanding is that these two are sensor devices which are "plugged"
> into their "parent" thermal zone device. The latter is the "proper" tzd.
> They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops.
> The former doesn't even have get_mode(). The thermal core, when it calls
> get_mode(), operates on the "parent" thermal zone devices.
>
> Consequently, the drivers you mention use their "mode" members for
> their private purpose, not for the purpose of storing the "parent"
> thermal zone device mode.
>
Let me also say it differently.
Both drivers which you mention use devm_thermal_zone_of_sensor_register().
It calls thermal_zone_of_sensor_register(), which "will search the list of
thermal zones described in device tree and look for the zone that refer to
the sensor device pointed by @dev->of_node as temperature providers. For
the zone pointing to the sensor node, the sensor will be added to the DT
thermal zone device." When a match is found thermal_zone_of_add_sensor()
is invoked, which (using thermal_zone_get_zone_by_name()) iterates over
all registered thermal_zone_devices. The one eventually found will be
returned and propagated to the original caller of
devm_thermal_zone_of_sensor_register(). The state of this returned
device is managed elsewhere (in that device's struct tzd). The "mode"
member you are referring to is thus unrelated.
Regards,
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64 fix for 5.7-rc8/final
From: Catalin Marinas @ 2020-05-29 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Will Deacon, linux-kernel, linux-arm-kernel
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 8cfb347ad0cffdbfc69c82506fb3be9429563211:
arm64: Add get_user() type annotation on the !access_ok() path (2020-05-22 16:59:49 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to ba051f097fc30b00f6b66044386901141351a557:
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up() (2020-05-28 12:04:55 +0100)
----------------------------------------------------------------
Ensure __cpu_up() returns an error if cpu_online() is false after
waiting for completion on cpu_running.
----------------------------------------------------------------
Nobuhiro Iwamatsu (1):
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Ray Jui, Nicolas Saenz Julienne,
Scott Branden, Florian Fainelli
Cc: Martin Sperl, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-spi
In-Reply-To: <20200528185805.28991-1-nsaenzjulienne@suse.de>
On Thu, 28 May 2020 20:58:04 +0200, Nicolas Saenz Julienne wrote:
> bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple
> instances of the bcm2835 SPI controller. So this enables shared
> interrupt support for them.
>
> The early bail out in the interrupt routine avoids messing with buffers
> of transfers being done by other means. Otherwise, the driver can handle
> receiving interrupts asserted by other controllers during an IRQ based
> transfer.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Enable shared interrupt support
commit: ecfbd3cf3b8bb73ac6a80ddf430b5912fd4402a6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: linux-kernel, Florian Fainelli
Cc: Scott Branden, Ray Jui, open list:SPI SUBSYSTEM,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528190605.24850-1-f.fainelli@gmail.com>
On Thu, 28 May 2020 12:06:05 -0700, Florian Fainelli wrote:
> Make sure we clear the FIFOs, stop the block, disable the clock and
> release the DMA channel.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Implement shutdown callback
commit: 118eb0e52eb74b899053a0f46dfe7e178788d23b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
From: Cristian Ciocaltea @ 2020-05-29 17:10 UTC (permalink / raw)
To: Andreas Färber
Cc: Greg Kroah-Hartman, Manivannan Sadhasivam, linux-actions,
linux-kernel, linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <16ff435f-9172-e01d-dfe6-7aa8575c4bd6@suse.de>
On Fri, May 29, 2020 at 05:56:47PM +0200, Andreas Färber wrote:
> Hi,
>
> Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> > Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> > that enables OWL UART to be used for KGDB debugging over serial line.
> >
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> > ---
> > drivers/tty/serial/owl-uart.c | 45 ++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> > index c2fa2f15d50a..26dcc374dec5 100644
> > --- a/drivers/tty/serial/owl-uart.c
> > +++ b/drivers/tty/serial/owl-uart.c
> > @@ -12,6 +12,7 @@
> > #include <linux/console.h>
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> > @@ -20,13 +21,13 @@
> > #include <linux/tty.h>
> > #include <linux/tty_flip.h>
> > -#define OWL_UART_PORT_NUM 7
> > -#define OWL_UART_DEV_NAME "ttyOWL"
> > +#define OWL_UART_PORT_NUM 7
> > +#define OWL_UART_DEV_NAME "ttyOWL"
> > -#define OWL_UART_CTL 0x000
> > -#define OWL_UART_RXDAT 0x004
> > -#define OWL_UART_TXDAT 0x008
> > -#define OWL_UART_STAT 0x00c
> > +#define OWL_UART_CTL 0x000
> > +#define OWL_UART_RXDAT 0x004
> > +#define OWL_UART_TXDAT 0x008
> > +#define OWL_UART_STAT 0x00c
>
> Please do not unnecessarily re-indent kernel code. You can do so when you're
> actually adding something new.
>
Hi Andreas,
Thank you for reviewing!
Sure, I will revert unnecessary changes.
>
> > #define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
> > #define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
> > @@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port, int flags)
> > }
> > }
> > +#ifdef CONFIG_CONSOLE_POLL
> > +
> > +static int owl_uart_poll_get_char(struct uart_port *port)
> > +{
> > + u32 c = NO_POLL_CHAR;
> > +
> > + if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
> > + c = owl_uart_read(port, OWL_UART_RXDAT);
> > +
> > + return c;
> > +}
> > +
> > +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
> > +{
> > + /* Wait while TX FIFO is full */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
> > + cpu_relax();
> > +
> > + /* Send the character out */
> > + owl_uart_write(port, c, OWL_UART_TXDAT);
> > +
> > + /* Wait for transmitter to become empty */
> > + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
> > + cpu_relax();
> > +}
>
> How is this different from earlycon? I dislike that this is being
> open-coded. Please try to reuse existing functions for this.
>
I actually tried initially to reuse the existing code, but I found
a few (possible) issues:
- owl_uart_port_write() does more things than I think it's really
needed here, i.e. I'm not sure if the locking stuff and the IRQ
setup are required. From what I've noticed, most serial drivers provide
a very simple implementation (and lock free) for the callbacks, but
I couldn't figure out if locking could be required in some
circumstances.
- owl_console_putchar() could be a better alternative, but it depends
on CONFIG_SERIAL_OWL_CONSOLE which might not be enabled if the user
only chooses CONFIG_KGDB_SERIAL_CONSOLE, although this is probably
not a valid scenario.
Kind regards,
Cristi
>
> Regards,
> Andreas
>
> > +
> > +#endif /* CONFIG_CONSOLE_POLL */
> > +
> > static const struct uart_ops owl_uart_ops = {
> > .set_mctrl = owl_uart_set_mctrl,
> > .get_mctrl = owl_uart_get_mctrl,
> > @@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
> > .request_port = owl_uart_request_port,
> > .release_port = owl_uart_release_port,
> > .verify_port = owl_uart_verify_port,
> > +#ifdef CONFIG_CONSOLE_POLL
> > + .poll_get_char = owl_uart_poll_get_char,
> > + .poll_put_char = owl_uart_poll_put_char,
> > +#endif
> > };
> > #ifdef CONFIG_SERIAL_OWL_CONSOLE
> >
>
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (AG Nürnberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Rob Herring @ 2020-05-29 17:07 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, heiko, dmitry.torokhov, linux-kernel, linux-rockchip,
robh+dt, linux-input, linux-arm-kernel
In-Reply-To: <20200520073327.6016-1-jbx6244@gmail.com>
On Wed, 20 May 2020 09:33:27 +0200, Johan Jonker wrote:
> A test with the command below gives this error:
>
> arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> touchscreen@3e: reg:0:0: 56 was expected
>
> The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> was shipped with different addresses then the binding currently allows.
> Change the reg property that any address will pass.
>
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> edt-ft5x06.yaml
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Lukasz Luba @ 2020-05-29 17:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Kevin Hilman, Andy Gross,
Daniel Lezcano, steven.price, Chanwoo Choi, Ingo Molnar,
dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide, Daniel Vetter,
Linux PM, linux-arm-msm, Sascha Hauer, Steven Rostedt,
moderated list:ARM/Mediatek SoC..., Matthias Brugger,
Linux OMAP Mailing List, Dietmar Eggemann, Linux ARM,
David Airlie, Tomeu Vizoso, Quentin Perret, Stephen Boyd,
Randy Dunlap, Rafael J. Wysocki, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz, Sascha Hauer, Sudeep Holla,
patrick.bellasi, Shawn Guo
In-Reply-To: <CAJZ5v0g5whSUMkd4majCGj0j9TMeO+fCfhxB6FNWoaLpPsi6UA@mail.gmail.com>
On 5/29/20 5:18 PM, Rafael J. Wysocki wrote:
> On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Hi Rafael,
>>
>>
>> On 5/27/20 10:58 AM, Lukasz Luba wrote:
>>> Hi all,
>>>
>>> Background of this version:
>>> This is the v8 of the patch set and is has smaller scope. I had to split
>>> the series into two: EM changes and thermal changes due to devfreq
>>> dependencies. The patches from v7 9-14 which change devfreq cooling are
>>> going to be sent in separate patch series, just after this set get merged
>>> into mainline. These patches related to EM got acks and hopefully can go
>>> through linux-pm tree. The later thermal patches will go through thermal
>>> tree.
>>>
>>> The idea and purpose of the Energy Model framework changes:
>>> This patch set introduces support for devices in the Energy Model (EM)
>>> framework. It will unify the power model for thermal subsystem. It will
>>> make simpler to add support for new devices willing to use more
>>> advanced features (like Intelligent Power Allocation). Now it should
>>> require less knowledge and effort for driver developer to add e.g.
>>> GPU driver with simple energy model. A more sophisticated energy model
>>> in the thermal framework is also possible, driver needs to provide
>>> a dedicated callback function. More information can be found in the
>>> updated documentation file.
>>>
>>> First 7 patches are refactoring Energy Model framework to add support
>>> of other devices that CPUs. They change:
>>> - naming convention from 'capacity' to 'performance' state,
>>> - API arguments adding device pointer and not rely only on cpumask,
>>> - change naming when 'cpu' was used, now it's a 'device'
>>> - internal structure to maintain registered devices
>>> - update users to the new API
>>> Patch 8 updates OPP framework helper function to be more generic, not
>>> CPU specific.
>>>
>>> The patch set is based on linux-pm branch linux-next 813946019dfd.
>>>
>>
>> Could you take the patch set via your linux-pm?
>
> I can do that, but I didn't realize that it was targeted at me, so I
> need some more time to review the patches.
>
> Thanks!
>
No worries. Thank you for your time!
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-05-29 16:57 UTC (permalink / raw)
To: Bartosz Golaszewski, Sean Wang, John Crispin, Matthias Brugger,
Mark Lee, Jakub Kicinski, David S . Miller
Cc: Stephane Le Provost, Fabien Parent, Pedro Tsai, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, netdev,
linux-arm-kernel
In-Reply-To: <159077110913.28779.5053923375043778782.b4-ty@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]
On Fri, May 29, 2020 at 05:52:00PM +0100, Mark Brown wrote:
> [1/1] regmap: provide helpers for simple bit operations
> commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
Let me know if you need a pull request for this, given the merge window
is likely to open over the weekend I figured it's likely too late to
apply the second patch before then.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-05-29 16:51 UTC (permalink / raw)
To: Bartosz Golaszewski, Sean Wang, John Crispin, Matthias Brugger,
Mark Lee, Jakub Kicinski, David S . Miller
Cc: Stephane Le Provost, Fabien Parent, Pedro Tsai, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, netdev,
linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
On Thu, 28 May 2020 17:45:01 +0200, Bartosz Golaszewski wrote:
> I noticed that oftentimes I use regmap_update_bits() for simple bit
> setting or clearing. In this case the fourth argument is superfluous as
> it's always 0 or equal to the mask argument.
>
> This series proposes to add simple bit operations for setting, clearing
> and testing specific bits with regmap.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: provide helpers for simple bit operations
commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] watchdog: sunxi_wdt: fix improper error exit code
From: Guenter Roeck @ 2020-05-29 16:51 UTC (permalink / raw)
To: Frank Lee
Cc: linux-watchdog, tiny.windzz, linux-kernel, mripard, wens, wuyan,
wim, linux-arm-kernel
In-Reply-To: <20200529094514.26374-1-frank@allwinnertech.com>
On Fri, May 29, 2020 at 05:45:14PM +0800, Frank Lee wrote:
> From: Martin Wu <wuyan@allwinnertech.com>
>
> sunxi_wdt_probe() should return -ENOMEM when devm_kzalloc() fails.
>
> Signed-off-by: Martin Wu <wuyan@allwinnertech.com>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/sunxi_wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
> index 5f05a45ac187..b50757882a98 100644
> --- a/drivers/watchdog/sunxi_wdt.c
> +++ b/drivers/watchdog/sunxi_wdt.c
> @@ -235,7 +235,7 @@ static int sunxi_wdt_probe(struct platform_device *pdev)
>
> sunxi_wdt = devm_kzalloc(dev, sizeof(*sunxi_wdt), GFP_KERNEL);
> if (!sunxi_wdt)
> - return -EINVAL;
> + return -ENOMEM;
>
> sunxi_wdt->wdt_regs = of_device_get_match_data(dev);
> if (!sunxi_wdt->wdt_regs)
> --
> 2.24.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH v5 6/6] drm: exynos: mixer: Add interconnect support
From: Sylwester Nawrocki @ 2020-05-29 16:32 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
From: Marek Szyprowski <m.szyprowski@samsung.com>
This patch adds interconnect support to exynos-mixer. The mixer works
the same as before when CONFIG_INTERCONNECT is 'n'.
For proper operation of the video mixer block we need to ensure the
interconnect busses like DMC or LEFTBUS provide enough bandwidth so
as to avoid DMA buffer underruns in the mixer block. i.e we need to
prevent those busses from operating in low perfomance OPPs when
the mixer is running.
In this patch the bus bandwidth request is done through the interconnect
API, the bandiwidth value is calculated from selected DRM mode, i.e.
video plane width, height, refresh rate and pixel format.
Co-developed-by: Artur Świgoń <a.swigon@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[s.nawrocki: renamed soc_path variable to icc_path, edited commit desc.]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes for v5:
- renamed soc_path variable to icc_path
---
drivers/gpu/drm/exynos/exynos_mixer.c | 73 ++++++++++++++++++++++++++++++++---
1 file changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21b726b..bdae683 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -13,6 +13,7 @@
#include <linux/component.h>
#include <linux/delay.h>
#include <linux/i2c.h>
+#include <linux/interconnect.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/kernel.h>
@@ -98,6 +99,7 @@ struct mixer_context {
struct exynos_drm_crtc *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
unsigned long flags;
+ struct icc_path *icc_path;
int irq;
void __iomem *mixer_regs;
@@ -934,6 +936,42 @@ static void mixer_disable_vblank(struct exynos_drm_crtc *crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
+static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
+{
+ struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
+ struct mixer_context *ctx = crtc->ctx;
+ unsigned long bw, bandwidth = 0;
+ u32 avg_bw, peak_bw;
+ int i, j, sub;
+
+ if (!ctx->icc_path)
+ return;
+
+ for (i = 0; i < MIXER_WIN_NR; i++) {
+ struct drm_plane *plane = &ctx->planes[i].base;
+ const struct drm_format_info *format;
+
+ if (plane->state && plane->state->crtc && plane->state->fb) {
+ format = plane->state->fb->format;
+ bw = mode->hdisplay * mode->vdisplay *
+ drm_mode_vrefresh(mode);
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ bw /= 2;
+ for (j = 0; j < format->num_planes; j++) {
+ sub = j ? (format->vsub * format->hsub) : 1;
+ bandwidth += format->cpp[j] * bw / sub;
+ }
+ }
+ }
+
+ /* add 20% safety margin */
+ bandwidth = bandwidth / 4 * 5;
+ dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
+
+ avg_bw = peak_bw = Bps_to_icc(bandwidth);
+ icc_set_bw(ctx->icc_path, avg_bw, peak_bw);
+}
+
static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
@@ -985,6 +1023,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc *crtc)
if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
+ mixer_set_memory_bandwidth(crtc);
mixer_enable_sync(mixer_ctx);
exynos_crtc_handle_event(crtc);
}
@@ -1032,6 +1071,7 @@ static void mixer_atomic_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, &ctx->planes[i]);
+ mixer_set_memory_bandwidth(crtc);
exynos_drm_pipe_clk_enable(crtc, false);
pm_runtime_put(ctx->dev);
@@ -1223,12 +1263,22 @@ static int mixer_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
const struct mixer_drv_data *drv;
struct mixer_context *ctx;
+ struct icc_path *path;
int ret;
+ /*
+ * Returns NULL if CONFIG_INTERCONNECT is disabled.
+ * May return ERR_PTR(-EPROBE_DEFER).
+ */
+ path = of_icc_get(dev, NULL);
+ if (IS_ERR(path))
+ return PTR_ERR(path);
+
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
DRM_DEV_ERROR(dev, "failed to alloc mixer context.\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
drv = of_device_get_match_data(dev);
@@ -1236,6 +1286,7 @@ static int mixer_probe(struct platform_device *pdev)
ctx->pdev = pdev;
ctx->dev = dev;
ctx->mxr_ver = drv->version;
+ ctx->icc_path = path;
if (drv->is_vp_enabled)
__set_bit(MXR_BIT_VP_ENABLED, &ctx->flags);
@@ -1245,17 +1296,29 @@ static int mixer_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ret = component_add(&pdev->dev, &mixer_component_ops);
- if (!ret)
- pm_runtime_enable(dev);
+ if (ret < 0)
+ goto err;
+
+ pm_runtime_enable(dev);
+
+ return 0;
+
+err:
+ icc_put(path);
return ret;
}
static int mixer_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct mixer_context *ctx = dev_get_drvdata(dev);
+
+ pm_runtime_disable(dev);
+
+ component_del(dev, &mixer_component_ops);
- component_del(&pdev->dev, &mixer_component_ops);
+ icc_put(ctx->icc_path);
return 0;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH v5 5/6] ARM: dts: exynos: Add interconnects to Exynos4412 mixer
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
From: Artur Świgoń <a.swigon@samsung.com>
This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a NULL name simply
returns the right path.
Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
---
Changes for v5:
- none.
---
arch/arm/boot/dts/exynos4412.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index a7496d3..eee86d2 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -776,6 +776,7 @@
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
<&clock CLK_SCLK_HDMI>, <&clock CLK_VP>;
+ interconnects = <&bus_display &bus_dmc>;
};
&pmu {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH v5 4/6] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
This patch adds the following properties for Exynos4412 interconnect
bus nodes:
- samsung,interconnect-parent: to declare connections between
nodes in order to guarantee PM QoS requirements between nodes;
- #interconnect-cells: required by the interconnect framework.
Note that #interconnect-cells is always zero and node IDs are not
hardcoded anywhere.
Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes for v5:
- adjust to renamed exynos,interconnect-parent-node property,
- add properties in common exynos4412.dtsi file rather than
in Odroid specific odroid4412-odroid-common.dtsi.
---
arch/arm/boot/dts/exynos4412.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 4886894..a7496d3 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -381,6 +381,7 @@
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -450,6 +451,8 @@
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
+ samsung,interconnect-parent = <&bus_dmc>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -466,6 +469,8 @@
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
+ samsung,interconnect-parent = <&bus_leftbus>;
+ #interconnect-cells = <0>;
status = "disabled";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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