* Re: [PATCH 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:36 UTC (permalink / raw)
To: Rob Herring, Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Scott Branden, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, open list:PIN CONTROL 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: <20200529193315.GA2807797@bogus>
On 5/29/20 12:33 PM, Rob Herring wrote:
> On Thu, May 28, 2020 at 12:21:10PM -0700, Florian Fainelli wrote:
>> BCM7211 supports wake-up interrupts in the form of optional interrupt
>> lines, one per bank, plus the "all banks" interrupt line.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> index dfc67b90591c..5682b2010e50 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> @@ -16,7 +16,9 @@ Required properties:
>> second cell is used to specify optional parameters:
>> - bit 0 specifies polarity (0 for normal, 1 for inverted)
>> - interrupts : The interrupt outputs from the controller. One interrupt per
>> - individual bank followed by the "all banks" interrupt.
>> + individual bank followed by the "all banks" interrupt. For BCM7211, an
>> + additional set of per-bank interrupt line and an "all banks" wake-up
>> + interrupt may be specified.
>
> Is 'all banks' the name? Generally 'wakeup' is used for a wake up irq.
The firmware provided DTB on 7211 names the interrupts "gpio_%d" for the
standard interrupts, including the "all banks" which is then "gpio_3"
and the wake-up interrupts are named "gpio_%d_wake", and the all banks
wake-up is "gpio_3_wake".
--
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][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Bjorn Helgaas @ 2020-05-29 19:33 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Kuppuswamy Sathyanarayanan, Ganapatrao Prabhakerrao Kulkarni,
Myron Stowe, Vijay Mohan Pandarathil, Marc Zyngier,
Bhupesh Sharma, kexec mailing list, Robin Murphy, linux-pci,
Prabhakar Kushwaha, Will Deacon, linux-arm-kernel
In-Reply-To: <CAJ2QiJKKSy20Z5oZ-yMb3AaioowBWC9ooQeQ+n+vXGLdiYKhgg@mail.gmail.com>
On Fri, May 29, 2020 at 07:48:10PM +0530, Prabhakar Kushwaha wrote:
> On Thu, May 28, 2020 at 1:48 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Wed, May 27, 2020 at 05:14:39PM +0530, Prabhakar Kushwaha wrote:
> > > On Fri, May 22, 2020 at 4:19 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Thu, May 21, 2020 at 09:28:20AM +0530, Prabhakar Kushwaha wrote:
> > > > > On Wed, May 20, 2020 at 4:52 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > > On Thu, May 14, 2020 at 12:47:02PM +0530, Prabhakar Kushwaha wrote:
> > > > > > > On Wed, May 13, 2020 at 3:33 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > > > > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> > > > > > > > > An SMMU Stream table is created by the primary kernel. This table is
> > > > > > > > > used by the SMMU to perform address translations for device-originated
> > > > > > > > > transactions. Any crash (if happened) launches the kdump kernel which
> > > > > > > > > re-creates the SMMU Stream table. New transactions will be translated
> > > > > > > > > via this new table..
> > > > > > > > >
> > > > > > > > > There are scenarios, where devices are still having old pending
> > > > > > > > > transactions (configured in the primary kernel). These transactions
> > > > > > > > > come in-between Stream table creation and device-driver probe.
> > > > > > > > > As new stream table does not have entry for older transactions,
> > > > > > > > > it will be aborted by SMMU.
> > > > > > > > >
> > > > > > > > > Similar observations were found with PCIe-Intel 82576 Gigabit
> > > > > > > > > Network card. It sends old Memory Read transaction in kdump kernel.
> > > > > > > > > Transactions configured for older Stream table entries, that do not
> > > > > > > > > exist any longer in the new table, will cause a PCIe Completion Abort.
> > > > > > > >
> > > > > > > > That sounds like exactly what we want, doesn't it?
> > > > > > > >
> > > > > > > > Or do you *want* DMA from the previous kernel to complete? That will
> > > > > > > > read or scribble on something, but maybe that's not terrible as long
> > > > > > > > as it's not memory used by the kdump kernel.
> > > > > > >
> > > > > > > Yes, Abort should happen. But it should happen in context of driver.
> > > > > > > But current abort is happening because of SMMU and no driver/pcie
> > > > > > > setup present at this moment.
> > > > > >
> > > > > > I don't understand what you mean by "in context of driver." The whole
> > > > > > problem is that we can't control *when* the abort happens, so it may
> > > > > > happen in *any* context. It may happen when a NIC receives a packet
> > > > > > or at some other unpredictable time.
> > > > > >
> > > > > > > Solution of this issue should be at 2 place
> > > > > > > a) SMMU level: I still believe, this patch has potential to overcome
> > > > > > > issue till finally driver's probe takeover.
> > > > > > > b) Device level: Even if something goes wrong. Driver/device should
> > > > > > > able to recover.
> > > > > > >
> > > > > > > > > Returned PCIe completion abort further leads to AER Errors from APEI
> > > > > > > > > Generic Hardware Error Source (GHES) with completion timeout.
> > > > > > > > > A network device hang is observed even after continuous
> > > > > > > > > reset/recovery from driver, Hence device is no more usable.
> > > > > > > >
> > > > > > > > The fact that the device is no longer usable is definitely a problem.
> > > > > > > > But in principle we *should* be able to recover from these errors. If
> > > > > > > > we could recover and reliably use the device after the error, that
> > > > > > > > seems like it would be a more robust solution that having to add
> > > > > > > > special cases in every IOMMU driver.
> > > > > > > >
> > > > > > > > If you have details about this sort of error, I'd like to try to fix
> > > > > > > > it because we want to recover from that sort of error in normal
> > > > > > > > (non-crash) situations as well.
> > > > > > > >
> > > > > > > Completion abort case should be gracefully handled. And device should
> > > > > > > always remain usable.
> > > > > > >
> > > > > > > There are 2 scenario which I am testing with Ethernet card PCIe-Intel
> > > > > > > 82576 Gigabit Network card.
> > > > > > >
> > > > > > > I) Crash testing using kdump root file system: De-facto scenario
> > > > > > > - kdump file system does not have Ethernet driver
> > > > > > > - A lot of AER prints [1], making it impossible to work on shell
> > > > > > > of kdump root file system.
> > > > > >
> > > > > > In this case, I think report_error_detected() is deciding that because
> > > > > > the device has no driver, we can't do anything. The flow is like
> > > > > > this:
> > > > > >
> > > > > > aer_recover_work_func # aer_recover_work
> > > > > > kfifo_get(aer_recover_ring, entry)
> > > > > > dev = pci_get_domain_bus_and_slot
> > > > > > cper_print_aer(dev, ...)
> > > > > > pci_err("AER: aer_status:")
> > > > > > pci_err("AER: [14] CmpltTO")
> > > > > > pci_err("AER: aer_layer=")
> > > > > > if (AER_NONFATAL)
> > > > > > pcie_do_recovery(dev, pci_channel_io_normal)
> > > > > > status = CAN_RECOVER
> > > > > > pci_walk_bus(report_normal_detected)
> > > > > > report_error_detected
> > > > > > if (!dev->driver)
> > > > > > vote = NO_AER_DRIVER
> > > > > > pci_info("can't recover (no error_detected callback)")
> > > > > > *result = merge_result(*, NO_AER_DRIVER)
> > > > > > # always NO_AER_DRIVER
> > > > > > status is now NO_AER_DRIVER
> > > > > >
> > > > > > So pcie_do_recovery() does not call .report_mmio_enabled() or .slot_reset(),
> > > > > > and status is not RECOVERED, so it skips .resume().
> > > > > >
> > > > > > I don't remember the history there, but if a device has no driver and
> > > > > > the device generates errors, it seems like we ought to be able to
> > > > > > reset it.
> > > > >
> > > > > But how to reset the device considering there is no driver.
> > > > > Hypothetically, this case should be taken care by PCIe subsystem to
> > > > > perform reset at PCIe level.
> > > >
> > > > I don't understand your question. The PCI core (not the device
> > > > driver) already does the reset. When pcie_do_recovery() calls
> > > > reset_link(), all devices on the other side of the link are reset.
> > > >
> > > > > > We should be able to field one (or a few) AER errors, reset the
> > > > > > device, and you should be able to use the shell in the kdump kernel.
> > > > > >
> > > > > here kdump shell is usable only problem is a "lot of AER Errors". One
> > > > > cannot see what they are typing.
> > > >
> > > > Right, that's what I expect. If the PCI core resets the device, you
> > > > should get just a few AER errors, and they should stop after the
> > > > device is reset.
> > > >
> > > > > > > - Note kdump shell allows to use makedumpfile, vmcore-dmesg applications.
> > > > > > >
> > > > > > > II) Crash testing using default root file system: Specific case to
> > > > > > > test Ethernet driver in second kernel
> > > > > > > - Default root file system have Ethernet driver
> > > > > > > - AER error comes even before the driver probe starts.
> > > > > > > - Driver does reset Ethernet card as part of probe but no success.
> > > > > > > - AER also tries to recover. but no success. [2]
> > > > > > > - I also tries to remove AER errors by using "pci=noaer" bootargs
> > > > > > > and commenting ghes_handle_aer() from GHES driver..
> > > > > > > than different set of errors come which also never able to recover [3]
> > > > > > >
> > > > >
> > > > > Please suggest your view on this case. Here driver is preset.
> > > > > (driver/net/ethernet/intel/igb/igb_main.c)
> > > > > In this case AER errors starts even before driver probe starts.
> > > > > After probe, driver does the device reset with no success and even AER
> > > > > recovery does not work.
> > > >
> > > > This case should be the same as the one above. If we can change the
> > > > PCI core so it can reset the device when there's no driver, that would
> > > > apply to case I (where there will never be a driver) and to case II
> > > > (where there is no driver now, but a driver will probe the device
> > > > later).
> > >
> > > Does this means change are required in PCI core.
> >
> > Yes, I am suggesting that the PCI core does not do the right thing
> > here.
> >
> > > I tried following changes in pcie_do_recovery() but it did not help.
> > > Same error as before.
> > >
> > > -- a/drivers/pci/pcie/err.c
> > > +++ b/drivers/pci/pcie/err.c
> > > pci_info(dev, "broadcast resume message\n");
> > > pci_walk_bus(bus, report_resume, &status);
> > > @@ -203,7 +207,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
> > > return status;
> > >
> > > failed:
> > > pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
> > > + pci_reset_function(dev);
> > > + pci_aer_clear_device_status(dev);
> > > + pci_aer_clear_nonfatal_status(dev);
> >
> > Did you confirm that this resets the devices in question (0000:09:00.0
> > and 0000:09:00.1, I think), and what reset mechanism this uses (FLR,
> > PM, etc)?
>
> Earlier reset was happening with P2P bridge(0000:00:09.0) this the
> reason no effect. After making following changes, both devices are
> now getting reset.
> Both devices are using FLR.
>
> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
> index 117c0a2b2ba4..26b908f55aef 100644
> --- a/drivers/pci/pcie/err.c
> +++ b/drivers/pci/pcie/err.c
> @@ -66,6 +66,20 @@ static int report_error_detected(struct pci_dev *dev,
> if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
> vote = PCI_ERS_RESULT_NO_AER_DRIVER;
> pci_info(dev, "can't recover (no
> error_detected callback)\n");
> +
> + pci_save_state(dev);
> + pci_cfg_access_lock(dev);
> +
> + /* Quiesce the device completely */
> + pci_write_config_word(dev, PCI_COMMAND,
> + PCI_COMMAND_INTX_DISABLE);
> + if (!__pci_reset_function_locked(dev)) {
> + vote = PCI_ERS_RESULT_RECOVERED;
> + pci_info(dev, "recovered via pci level
> reset\n");
> + }
Why do we need to save the state and quiesce the device? The reset
should disable interrupts anyway. In this particular case where
there's no driver, I don't think we should have to restore the state.
We maybe should *remove* the device and re-enumerate it after the
reset, but the state from before the reset should be irrelevant.
> + pci_cfg_access_unlock(dev);
> + pci_restore_state(dev);
> } else {
> vote = PCI_ERS_RESULT_NONE;
> }
>
> in order to take care of case 2 (driver comes after sometime) ==>
> following code needs to be added to avoid crash during igb_probe. It
> looks to be a race condition between AER and igb_probe().
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index b46bff8fe056..c48f0a54bb95 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -3012,6 +3012,11 @@ static int igb_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> /* Catch broken hardware that put the wrong VF device ID in
> * the PCIe SR-IOV capability.
> */
> + if (pci_dev_trylock(pdev)) {
> + mdelay(1000);
> + pci_info(pdev,"device is locked, try waiting 1 sec\n");
> + }
This is interesting to learn about the AER/driver interaction, but of
course, we wouldn't want to add code like this permanently.
> Here are the observation with all above changes
> A) AER errors are less but they are still there for both case 1 (No
> driver at all) and case 2 (driver comes after some time)
We'll certainly get *some* AER errors. We have to get one before we
know to reset the device.
> B) Each AER error(NON_FATAL) causes both devices to reset. It happens many times
I'm not sure why we reset both devices. Are we seeing errors from
both, or could we be more selective in the code?
> C) After that AER errors [1] comes is only for device 0000:09:00.0.
> This is strange as this pci device is not being used during test.
> Ping/ssh are happening with 0000:09:01.0
> D) If wait for some more time. No more AER errors from any device
> E) Ping is working fine in case 2.
>
> 09:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 09:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
>
> # lspci -t -v
>
> \-[0000:00]-+-00.0 Cavium, Inc. CN99xx [ThunderX2] Integrated PCI Host bridge
> +-01.0-[01]--
> +-02.0-[02]--
> +-03.0-[03]--
> +-04.0-[04]--
> +-05.0-[05]--+-00.0 Broadcom Inc. and subsidiaries
> BCM57840 NetXtreme II 10 Gigabit Ethernet
> | \-00.1 Broadcom Inc. and subsidiaries
> BCM57840 NetXtreme II 10 Gigabit Ethernet
> +-06.0-[06]--
> +-07.0-[07]--
> +-08.0-[08]--
> +-09.0-[09-0a]--+-00.0 Intel Corporation 82576 Gigabit
> Network Connection
> | \-00.1 Intel Corporation 82576 Gigabit
> Network Connection
>
>
> [1] AER error which comes for 09:00.0:
>
> [ 81.659825] {7}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 0
> [ 81.668080] {7}[Hardware Error]: It has been corrected by h/w and
> requires no further action
> [ 81.676503] {7}[Hardware Error]: event severity: corrected
> [ 81.681975] {7}[Hardware Error]: Error 0, type: corrected
> [ 81.687447] {7}[Hardware Error]: section_type: PCIe error
> [ 81.693004] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 81.698908] {7}[Hardware Error]: version: 3.0
> [ 81.703424] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 81.709589] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 81.715059] {7}[Hardware Error]: slot: 0
> [ 81.719141] {7}[Hardware Error]: secondary_bus: 0x00
> [ 81.724265] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 81.730864] {7}[Hardware Error]: class_code: 000002
> [ 81.735901] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 81.742587] {7}[Hardware Error]: Error 1, type: corrected
> [ 81.748058] {7}[Hardware Error]: section_type: PCIe error
> [ 81.753615] {7}[Hardware Error]: port_type: 4, root port
> [ 81.759086] {7}[Hardware Error]: version: 3.0
> [ 81.763602] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 81.769767] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 81.775237] {7}[Hardware Error]: slot: 0
> [ 81.779319] {7}[Hardware Error]: secondary_bus: 0x09
> [ 81.784442] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 81.791041] {7}[Hardware Error]: class_code: 000406
> [ 81.796078] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 81.803806] {7}[Hardware Error]: Error 2, type: corrected
> [ 81.809276] {7}[Hardware Error]: section_type: PCIe error
> [ 81.814834] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 81.820738] {7}[Hardware Error]: version: 3.0
> [ 81.825254] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 81.831419] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 81.836889] {7}[Hardware Error]: slot: 0
> [ 81.840971] {7}[Hardware Error]: secondary_bus: 0x00
> [ 81.846094] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 81.852693] {7}[Hardware Error]: class_code: 000002
> [ 81.857730] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 81.864416] {7}[Hardware Error]: Error 3, type: corrected
> [ 81.869886] {7}[Hardware Error]: section_type: PCIe error
> [ 81.875444] {7}[Hardware Error]: port_type: 4, root port
> [ 81.880914] {7}[Hardware Error]: version: 3.0
> [ 81.885430] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 81.891595] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 81.897066] {7}[Hardware Error]: slot: 0
> [ 81.901147] {7}[Hardware Error]: secondary_bus: 0x09
> [ 81.906271] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 81.912870] {7}[Hardware Error]: class_code: 000406
> [ 81.917906] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 81.925634] {7}[Hardware Error]: Error 4, type: corrected
> [ 81.931104] {7}[Hardware Error]: section_type: PCIe error
> [ 81.936662] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 81.942566] {7}[Hardware Error]: version: 3.0
> [ 81.947082] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 81.953247] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 81.958717] {7}[Hardware Error]: slot: 0
> [ 81.962799] {7}[Hardware Error]: secondary_bus: 0x00
> [ 81.967923] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 81.974522] {7}[Hardware Error]: class_code: 000002
> [ 81.979558] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 81.986244] {7}[Hardware Error]: Error 5, type: corrected
> [ 81.991715] {7}[Hardware Error]: section_type: PCIe error
> [ 81.997272] {7}[Hardware Error]: port_type: 4, root port
> [ 82.002743] {7}[Hardware Error]: version: 3.0
> [ 82.007259] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 82.013424] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 82.018894] {7}[Hardware Error]: slot: 0
> [ 82.022976] {7}[Hardware Error]: secondary_bus: 0x09
> [ 82.028099] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 82.034698] {7}[Hardware Error]: class_code: 000406
> [ 82.039735] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 82.047463] {7}[Hardware Error]: Error 6, type: corrected
> [ 82.052933] {7}[Hardware Error]: section_type: PCIe error
> [ 82.058491] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 82.064395] {7}[Hardware Error]: version: 3.0
> [ 82.068911] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 82.075076] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 82.080547] {7}[Hardware Error]: slot: 0
> [ 82.084628] {7}[Hardware Error]: secondary_bus: 0x00
> [ 82.089752] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 82.096351] {7}[Hardware Error]: class_code: 000002
> [ 82.101387] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 82.108073] {7}[Hardware Error]: Error 7, type: corrected
> [ 82.113544] {7}[Hardware Error]: section_type: PCIe error
> [ 82.119101] {7}[Hardware Error]: port_type: 4, root port
> [ 82.124572] {7}[Hardware Error]: version: 3.0
> [ 82.129087] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 82.135252] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 82.140723] {7}[Hardware Error]: slot: 0
> [ 82.144805] {7}[Hardware Error]: secondary_bus: 0x09
> [ 82.149928] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 82.156527] {7}[Hardware Error]: class_code: 000406
> [ 82.161564] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 82.169291] {7}[Hardware Error]: Error 8, type: corrected
> [ 82.174762] {7}[Hardware Error]: section_type: PCIe error
> [ 82.180319] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 82.186224] {7}[Hardware Error]: version: 3.0
> [ 82.190739] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 82.196904] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 82.202375] {7}[Hardware Error]: slot: 0
> [ 82.206456] {7}[Hardware Error]: secondary_bus: 0x00
> [ 82.211580] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 82.218179] {7}[Hardware Error]: class_code: 000002
> [ 82.223216] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 82.229901] {7}[Hardware Error]: Error 9, type: corrected
> [ 82.235372] {7}[Hardware Error]: section_type: PCIe error
> [ 82.240929] {7}[Hardware Error]: port_type: 4, root port
> [ 82.246400] {7}[Hardware Error]: version: 3.0
> [ 82.250916] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 82.257081] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 82.262551] {7}[Hardware Error]: slot: 0
> [ 82.266633] {7}[Hardware Error]: secondary_bus: 0x09
> [ 82.271756] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 82.278355] {7}[Hardware Error]: class_code: 000406
> [ 82.283392] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 82.291119] {7}[Hardware Error]: Error 10, type: corrected
> [ 82.296676] {7}[Hardware Error]: section_type: PCIe error
> [ 82.302234] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 82.308138] {7}[Hardware Error]: version: 3.0
> [ 82.312654] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 82.318819] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 82.324290] {7}[Hardware Error]: slot: 0
> [ 82.328371] {7}[Hardware Error]: secondary_bus: 0x00
> [ 82.333495] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 82.340094] {7}[Hardware Error]: class_code: 000002
> [ 82.345131] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 82.351816] {7}[Hardware Error]: Error 11, type: corrected
> [ 82.357374] {7}[Hardware Error]: section_type: PCIe error
> [ 82.362931] {7}[Hardware Error]: port_type: 4, root port
> [ 82.368402] {7}[Hardware Error]: version: 3.0
> [ 82.372917] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 82.379082] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 82.384553] {7}[Hardware Error]: slot: 0
> [ 82.388635] {7}[Hardware Error]: secondary_bus: 0x09
> [ 82.393758] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 82.400357] {7}[Hardware Error]: class_code: 000406
> [ 82.405394] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 82.413121] {7}[Hardware Error]: Error 12, type: corrected
> [ 82.418678] {7}[Hardware Error]: section_type: PCIe error
> [ 82.424236] {7}[Hardware Error]: port_type: 0, PCIe end point
> [ 82.430140] {7}[Hardware Error]: version: 3.0
> [ 82.434656] {7}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 82.440821] {7}[Hardware Error]: device_id: 0000:09:00.0
> [ 82.446291] {7}[Hardware Error]: slot: 0
> [ 82.450373] {7}[Hardware Error]: secondary_bus: 0x00
> [ 82.455497] {7}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 82.462096] {7}[Hardware Error]: class_code: 000002
> [ 82.467132] {7}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 82.473818] {7}[Hardware Error]: Error 13, type: corrected
> [ 82.479375] {7}[Hardware Error]: section_type: PCIe error
> [ 82.484933] {7}[Hardware Error]: port_type: 4, root port
> [ 82.490403] {7}[Hardware Error]: version: 3.0
> [ 82.494919] {7}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 82.501084] {7}[Hardware Error]: device_id: 0000:00:09.0
> [ 82.506555] {7}[Hardware Error]: slot: 0
> [ 82.510636] {7}[Hardware Error]: secondary_bus: 0x09
> [ 82.515760] {7}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 82.522359] {7}[Hardware Error]: class_code: 000406
> [ 82.527395] {7}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 82.535171] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.542476] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.550301] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.558032] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.566296] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.573597] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.581421] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.589151] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.597411] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.604711] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.612535] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.620271] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.628525] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.635826] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.643649] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.651385] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.659645] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.666940] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.674763] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.682498] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.690759] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.698053] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.705876] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.713612] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 82.721872] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 82.729167] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 82.736990] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 82.744725] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 88.059225] {8}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 0
> [ 88.067478] {8}[Hardware Error]: It has been corrected by h/w and
> requires no further action
> [ 88.075899] {8}[Hardware Error]: event severity: corrected
> [ 88.081370] {8}[Hardware Error]: Error 0, type: corrected
> [ 88.086841] {8}[Hardware Error]: section_type: PCIe error
> [ 88.092399] {8}[Hardware Error]: port_type: 0, PCIe end point
> [ 88.098303] {8}[Hardware Error]: version: 3.0
> [ 88.102819] {8}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 88.108984] {8}[Hardware Error]: device_id: 0000:09:00.0
> [ 88.114455] {8}[Hardware Error]: slot: 0
> [ 88.118536] {8}[Hardware Error]: secondary_bus: 0x00
> [ 88.123660] {8}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 88.130259] {8}[Hardware Error]: class_code: 000002
> [ 88.135296] {8}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 88.141981] {8}[Hardware Error]: Error 1, type: corrected
> [ 88.147452] {8}[Hardware Error]: section_type: PCIe error
> [ 88.153009] {8}[Hardware Error]: port_type: 4, root port
> [ 88.158480] {8}[Hardware Error]: version: 3.0
> [ 88.162995] {8}[Hardware Error]: command: 0x0106, status: 0x4010
> [ 88.169161] {8}[Hardware Error]: device_id: 0000:00:09.0
> [ 88.174633] {8}[Hardware Error]: slot: 0
> [ 88.180018] {8}[Hardware Error]: secondary_bus: 0x09
> [ 88.185142] {8}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> [ 88.191914] {8}[Hardware Error]: class_code: 000406
> [ 88.196951] {8}[Hardware Error]: bridge: secondary_status:
> 0x6000, control: 0x0002
> [ 88.204852] {8}[Hardware Error]: Error 2, type: corrected
> [ 88.210323] {8}[Hardware Error]: section_type: PCIe error
> [ 88.215881] {8}[Hardware Error]: port_type: 0, PCIe end point
> [ 88.221786] {8}[Hardware Error]: version: 3.0
> [ 88.226301] {8}[Hardware Error]: command: 0x0507, status: 0x0010
> [ 88.232466] {8}[Hardware Error]: device_id: 0000:09:00.0
> [ 88.237937] {8}[Hardware Error]: slot: 0
> [ 88.242019] {8}[Hardware Error]: secondary_bus: 0x00
> [ 88.247142] {8}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> [ 88.253741] {8}[Hardware Error]: class_code: 000002
> [ 88.258778] {8}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> [ 88.265509] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 88.272812] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
> [ 88.280635] pcieport 0000:00:09.0: AER: aer_status: 0x00000000,
> aer_mask: 0x00002000
> [ 88.288363] pcieport 0000:00:09.0: AER: aer_layer=Transaction
> Layer, aer_agent=Receiver ID
> [ 88.296622] igb 0000:09:00.0: AER: aer_status: 0x00002000,
> aer_mask: 0x00002000
> [ 88.305391] igb 0000:09:00.0: AER: aer_layer=Transaction Layer,
> aer_agent=Receiver ID
>
> > Case I is using APEI, and it looks like that can queue up 16 errors
> > (AER_RECOVER_RING_SIZE), so that queue could be completely full before
> > we even get a chance to reset the device. But I would think that the
> > reset should *eventually* stop the errors, even though we might log
> > 30+ of them first.
> >
> > As an experiment, you could reduce AER_RECOVER_RING_SIZE to 1 or 2 and
> > see if it reduces the logging.
>
> Did not tried this experiment. I believe it is not required now
>
> --pk
>
> >
> > > > > Problem mentioned in case I and II goes away if do pci_reset_function
> > > > > during enumeration phase of kdump kernel.
> > > > > can we thought of doing pci_reset_function for all devices in kdump
> > > > > kernel or device specific quirk.
> > > > >
> > > > > --pk
> > > > >
> > > > >
> > > > > > > As per my understanding, possible solutions are
> > > > > > > - Copy SMMU table i.e. this patch
> > > > > > > OR
> > > > > > > - Doing pci_reset_function() during enumeration phase.
> > > > > > > I also tried clearing "M" bit using pci_clear_master during
> > > > > > > enumeration but it did not help. Because driver re-set M bit causing
> > > > > > > same AER error again.
> > > > > > >
> > > > > > >
> > > > > > > -pk
> > > > > > >
> > > > > > > ---------------------------------------------------------------------------------------------------------------------------
> > > > > > > [1] with bootargs having pci=noaer
> > > > > > >
> > > > > > > [ 22.494648] {4}[Hardware Error]: Hardware error from APEI Generic
> > > > > > > Hardware Error Source: 1
> > > > > > > [ 22.512773] {4}[Hardware Error]: event severity: recoverable
> > > > > > > [ 22.518419] {4}[Hardware Error]: Error 0, type: recoverable
> > > > > > > [ 22.544804] {4}[Hardware Error]: section_type: PCIe error
> > > > > > > [ 22.550363] {4}[Hardware Error]: port_type: 0, PCIe end point
> > > > > > > [ 22.556268] {4}[Hardware Error]: version: 3.0
> > > > > > > [ 22.560785] {4}[Hardware Error]: command: 0x0507, status: 0x4010
> > > > > > > [ 22.576852] {4}[Hardware Error]: device_id: 0000:09:00.1
> > > > > > > [ 22.582323] {4}[Hardware Error]: slot: 0
> > > > > > > [ 22.586406] {4}[Hardware Error]: secondary_bus: 0x00
> > > > > > > [ 22.591530] {4}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > > > > > [ 22.608900] {4}[Hardware Error]: class_code: 000002
> > > > > > > [ 22.613938] {4}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > > > > > [ 22.803534] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > > > > aer_mask: 0x00000000
> > > > > > > [ 22.810838] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > > > > [ 22.817613] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > > > > aer_agent=Requester ID
> > > > > > > [ 22.847374] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > > > > [ 22.866161] mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED,
> > > > > > > total mem (8153768 kB)
> > > > > > > [ 22.946178] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> > > > > > > [ 22.995142] pci 0000:09:00.1: AER: can't recover (no error_detected callback)
> > > > > > > [ 23.002300] pcieport 0000:00:09.0: AER: device recovery failed
> > > > > > > [ 23.027607] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > > > > aer_mask: 0x00000000
> > > > > > > [ 23.044109] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > > > > [ 23.060713] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > > > > aer_agent=Requester ID
> > > > > > > [ 23.068616] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > > > > [ 23.122056] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> >
> > <snip>
_______________________________________________
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 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Rob Herring @ 2020-05-29 19:33 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Scott Branden, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, open list:PIN CONTROL 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: <20200528192112.26123-3-f.fainelli@gmail.com>
On Thu, May 28, 2020 at 12:21:10PM -0700, Florian Fainelli wrote:
> BCM7211 supports wake-up interrupts in the form of optional interrupt
> lines, one per bank, plus the "all banks" interrupt line.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
> index dfc67b90591c..5682b2010e50 100644
> --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
> @@ -16,7 +16,9 @@ Required properties:
> second cell is used to specify optional parameters:
> - bit 0 specifies polarity (0 for normal, 1 for inverted)
> - interrupts : The interrupt outputs from the controller. One interrupt per
> - individual bank followed by the "all banks" interrupt.
> + individual bank followed by the "all banks" interrupt. For BCM7211, an
> + additional set of per-bank interrupt line and an "all banks" wake-up
> + interrupt may be specified.
Is 'all banks' the name? Generally 'wakeup' is used for a wake up irq.
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 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm, bcm2835-gpio.txt
From: Rob Herring @ 2020-05-29 19:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Scott Branden, Geert Uytterhoeven, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-2-f.fainelli@gmail.com>
On Thu, 28 May 2020 12:21:09 -0700, Florian Fainelli wrote:
> Document the brcm,bcm7211-gpio compatible string in the
> brcm,bcm2835-gpio.txt document.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: Rob Herring @ 2020-05-29 19:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: devicetree, Stephane Le Provost, Fabien Parent, Pedro Tsai,
linux-kernel, Bartosz Golaszewski, Rob Herring, linux-mediatek,
Andrew Perepech, netdev, Matthias Brugger, Jakub Kicinski,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
On Thu, 28 May 2020 15:59:02 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
>
> .../net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} (96%)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Rob Herring @ 2020-05-29 19:24 UTC (permalink / raw)
To: EastL
Cc: mark.rutland, devicetree, wsd_upstream, Sean Wang, linux-kernel,
dmaengine, vkoul, linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <1590659832-31476-2-git-send-email-EastL.Lee@mediatek.com>
On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6779 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: EastL <EastL.Lee@mediatek.com>
Need a full name.
> ---
> .../devicetree/bindings/dma/mtk-cqdma.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> new file mode 100644
> index 0000000..045aa0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Command-Queue DMA controller Device Tree Binding
> +
> +maintainers:
> + - EastL <EastL.Lee@mediatek.com>
> +
> +description:
> + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> + is dedicated to memory-to-memory transfer through queue based
> + descriptor management.
> +
Need a $ref to dma-controller.yaml
> +properties:
> + "#dma-cells":
> + minimum: 1
> + # Should be enough
> + maximum: 255
> + description:
> + Used to provide DMA controller specific information.
> +
> + compatible:
> + const: mediatek,cqdma
Needs SoC specific compatible string(s).
> +
> + reg:
> + minItems: 1
> + maxItems: 255
You can have 255 register regions?
You need to define what each region is if more than 1.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 255
255 interrupts?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: cqdma
> +
> + dma-channel-mask:
> + description:
> + Bitmask of available DMA channels in ascending order that are
> + not reserved by firmware and are available to the
> + kernel. i.e. first channel corresponds to LSB.
> + The first item in the array is for channels 0-31, the second is for
> + channels 32-63, etc.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + items:
> + minItems: 1
> + # Should be enough
> + maxItems: 255
This already has a definition in dma-common.yaml. Don't copy-n-paste
it. Just add any constraints you have. Like what is the max number of
channels?
> +
> + dma-channels:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA channels supported by the controller.
> +
> + dma-requests:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA request signals supported by the controller.
Same comment on these 2.
> +
> +required:
> + - "#dma-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dma-channel-mask
> + - dma-channels
> + - dma-requests
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt6779-clk.h>
> + cqdma: dma-controller@10212000 {
> + compatible = "mediatek,cqdma";
> + reg = <0 0x10212000 0 0x80>,
> + <0 0x10212080 0 0x80>,
> + <0 0x10212100 0 0x80>;
Examples default to 1 cell each for address and size.
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channel-mask = <63>;
> + dma-channels = <3>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +...
> --
> 1.9.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 v4 0/2] soc: ti: add k3 platforms chipid module driver
From: santosh.shilimkar @ 2020-05-29 19:19 UTC (permalink / raw)
To: Arnd Bergmann, Grygorii Strashko
Cc: Nishanth Menon, DTML, Dave Gerlach, Lokesh Vutla, Sekhar Nori,
linux-kernel@vger.kernel.org, Tero Kristo, Rob Herring,
Santosh Shilimkar, Linux ARM
In-Reply-To: <CAK8P3a31DYOn1TyjxCYM7ebc9nL5EFKsNpSHkq55bG54Bns+MA@mail.gmail.com>
On 5/29/20 11:34 AM, Arnd Bergmann wrote:
> On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 12/05/2020 15:34, Grygorii Strashko wrote:
>
>>> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
>>> drivers/soc/ti/Kconfig | 10 ++
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
>>> 4 files changed, 203 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>>> create mode 100644 drivers/soc/ti/k3-socinfo.c
>>>
>>
>> Any chances you can pick this up?
>
> I merged a version of this driver from Santosh's pull request into the
> arm/drviers tree yesterday.
>
> Is there something missing?
>
Nope. I was going to reply on the thread but missed it.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
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: <20200529191522.27938-1-f.fainelli@gmail.com>
Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to
specifically treat the GPIO interrupts during suspend and resume, and
simply implement an irq_set_wake() callback that is responsible for
enabling the parent wake-up interrupt as a wake-up interrupt.
To avoid allocating unnecessary resources for other chips, the wake-up
interrupts are only initialized if we have a brcm,bcm7211-gpio
compatibility string.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 76 ++++++++++++++++++++++++++-
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 1b00d93aa66e..1fbf067a3eed 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -19,6 +19,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -76,6 +77,7 @@
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
+ int *wake_irq;
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -435,6 +437,11 @@ static void bcm2835_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(host_chip, desc);
}
+static irqreturn_t bcm2835_gpio_wake_irq_handler(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
unsigned reg, unsigned offset, bool enable)
{
@@ -634,6 +641,34 @@ static void bcm2835_gpio_irq_ack(struct irq_data *data)
bcm2835_gpio_set_bit(pc, GPEDS0, gpio);
}
+static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
+ unsigned gpio = irqd_to_hwirq(data);
+ unsigned int irqgroup;
+ int ret = -EINVAL;
+
+ if (!pc->wake_irq)
+ return ret;
+
+ if (gpio <= 27)
+ irqgroup = 0;
+ else if (gpio >= 28 && gpio <= 45)
+ irqgroup = 1;
+ else if (gpio >= 46 && gpio <= 53)
+ irqgroup = 2;
+ else
+ return ret;
+
+ if (on)
+ ret = enable_irq_wake(pc->wake_irq[irqgroup]);
+ else
+ ret = disable_irq_wake(pc->wake_irq[irqgroup]);
+
+ return ret;
+}
+
static struct irq_chip bcm2835_gpio_irq_chip = {
.name = MODULE_NAME,
.irq_enable = bcm2835_gpio_irq_enable,
@@ -642,6 +677,8 @@ static struct irq_chip bcm2835_gpio_irq_chip = {
.irq_ack = bcm2835_gpio_irq_ack,
.irq_mask = bcm2835_gpio_irq_disable,
.irq_unmask = bcm2835_gpio_irq_enable,
+ .irq_set_wake = bcm2835_gpio_irq_set_wake,
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
static int bcm2835_pctl_get_groups_count(struct pinctrl_dev *pctldev)
@@ -1154,6 +1191,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
struct resource iomem;
int err, i;
const struct of_device_id *match;
+ int is_7211 = 0;
BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_pins) != BCM2711_NUM_GPIOS);
BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_groups) != BCM2711_NUM_GPIOS);
@@ -1180,6 +1218,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
return -EINVAL;
pdata = match->data;
+ is_7211 = of_device_is_compatible(np, "brcm,bcm7211-gpio");
pc->gpio_chip = *pdata->gpio_chip;
pc->gpio_chip.parent = dev;
@@ -1214,6 +1253,15 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!girq->parents)
return -ENOMEM;
+
+ if (is_7211) {
+ pc->wake_irq = devm_kcalloc(dev, BCM2835_NUM_IRQS,
+ sizeof(*pc->wake_irq),
+ GFP_KERNEL);
+ if (!pc->wake_irq)
+ return -ENOMEM;
+ }
+
/*
* Use the same handler for all groups: this is necessary
* since we use one gpiochip to cover all lines - the
@@ -1221,8 +1269,34 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
* bank that was firing the IRQ and look up the per-group
* and bank data.
*/
- for (i = 0; i < BCM2835_NUM_IRQS; i++)
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
+
girq->parents[i] = irq_of_parse_and_map(np, i);
+ if (!is_7211)
+ continue;
+
+ /* Skip over the all banks interrupts */
+ pc->wake_irq[i] = irq_of_parse_and_map(np, i +
+ BCM2835_NUM_IRQS + 1);
+
+ len = strlen(dev_name(pc->dev)) + 16;
+ name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+
+ snprintf(name, len, "%s:bank%d", dev_name(pc->dev), i);
+
+ /* These are optional interrupts */
+ err = devm_request_irq(dev, pc->wake_irq[i],
+ bcm2835_gpio_wake_irq_handler,
+ IRQF_SHARED, name, pc);
+ if (err)
+ dev_warn(dev, "unable to request wake IRQ %d\n",
+ pc->wake_irq[i]);
+ }
+
girq->default_type = IRQ_TYPE_NONE;
girq->handler = handle_level_irq;
--
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 related
* [PATCH v2 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
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: <20200529191522.27938-1-f.fainelli@gmail.com>
The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
BCM2711 SoC, match the compatible string and use the correct set of
options.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 06bd2b70af3c..1b00d93aa66e 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1137,6 +1137,10 @@ static const struct of_device_id bcm2835_pinctrl_match[] = {
.compatible = "brcm,bcm2711-gpio",
.data = &bcm2711_plat_data,
},
+ {
+ .compatible = "brcm,bcm7211-gpio",
+ .data = &bcm2711_plat_data,
+ },
{}
};
--
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 related
* [PATCH v2 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
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: <20200529191522.27938-1-f.fainelli@gmail.com>
BCM7211 supports wake-up interrupts in the form of optional interrupt
lines, one per bank, plus the "all banks" interrupt line.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index dfc67b90591c..5682b2010e50 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -16,7 +16,9 @@ Required properties:
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- interrupts : The interrupt outputs from the controller. One interrupt per
- individual bank followed by the "all banks" interrupt.
+ individual bank followed by the "all banks" interrupt. For BCM7211, an
+ additional set of per-bank interrupt line and an "all banks" wake-up
+ interrupt may be specified.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
--
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 related
* [PATCH v2 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm, bcm2835-gpio.txt
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
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: <20200529191522.27938-1-f.fainelli@gmail.com>
Document the brcm,bcm7211-gpio compatible string in the
brcm,bcm2835-gpio.txt document.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 3cab7336a326..dfc67b90591c 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -9,6 +9,7 @@ Required properties:
"brcm,bcm2835-gpio" - BCM2835 compatible pinctrl
"brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
"brcm,bcm2711-gpio" - BCM2711 compatible pinctrl
+ "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
- reg: Should contain the physical address of the GPIO module's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
--
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 related
* [PATCH v2 0/4] pinctrl: bcm2835: Support for wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
Hi Linus,
This patch series updates the bcm2835 pinctrl driver to support
the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4)
except that it also supports wake-up interrupts.
Thanks!
Changes in v2:
- fixed patch #3 to reference the correct data structure (Stefan)
- fixed patch #4 to use conditional initialization and fetching of
interrupt resources to limit the memory overhead for non-7211 chips
Florian Fainelli (4):
dt-bindings: pinctrl: Document 7211 compatible for
brcm,bcm2835-gpio.txt
dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
.../bindings/pinctrl/brcm,bcm2835-gpio.txt | 5 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 80 ++++++++++++++++++-
2 files changed, 83 insertions(+), 2 deletions(-)
--
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 0/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
From: John Hubbard @ 2020-05-29 19:15 UTC (permalink / raw)
To: Dragan Cvetic, LKML
Cc: Arnd Bergmann, Greg Kroah-Hartman, Michal Simek, Souptick Joarder,
Derek Kiernan, linux-arm-kernel@lists.infradead.org
In-Reply-To: <DM6PR02MB41405A1300813F8A511BE449CB8F0@DM6PR02MB4140.namprd02.prod.outlook.com>
On 2020-05-29 01:29, Dragan Cvetic wrote:
> Hi John,
>
> Thank you for the suggestion, please find my comment below:
>
>> -----Original Message-----
>> From: John Hubbard <jhubbard@nvidia.com>
>> Sent: Wednesday 27 May 2020 02:26
>> To: LKML <linux-kernel@vger.kernel.org>
>> Cc: Souptick Joarder <jrdr.linux@gmail.com>; John Hubbard <jhubbard@nvidia.com>; Derek Kiernan <dkiernan@xilinx.com>; Dragan
>> Cvetic <draganc@xilinx.com>; Arnd Bergmann <arnd@arndb.de>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Michal Simek
>> <michals@xilinx.com>; linux-arm-kernel@lists.infradead.org
>> Subject: [PATCH 0/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
>>
>> Hi,
>>
>> There are also a couple of tiny cleanup patches, just to fix up a few
>> minor issues that I spotted while converting from get_user_pages_fast()
>> to pin_user_pages_fast().
>>
>> Note that I have only compile-tested these patches, although that does
>> also include cross-compiling for a few other arches. Any run-time
>> testing would be greatly appreciated!
>>
>> Cc: Derek Kiernan <derek.kiernan@xilinx.com>
>> Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Michal Simek <michal.simek@xilinx.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>>
>> John Hubbard (3):
>> misc: xilinx-sdfec: improve get_user_pages_fast() error handling
>> misc: xilinx-sdfec: cleanup return value in xsdfec_table_write()
>> misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
>
>
> Reviewed-by:
> Technically there is no problem in this patch, but as you said this should be tested.
> Currently due to Covid-19 I'm not able to access the HW and I cannot validate this suggestion.
>
Hi Dragan,
Thanks for the review, and for *wanting* to do the testing, even though you
can't right now. :)
thanks,
--
John Hubbard
NVIDIA
>>
>> drivers/misc/xilinx_sdfec.c | 30 +++++++++++++++++-------------
>> 1 file changed, 17 insertions(+), 13 deletions(-)
>>
>>
>> base-commit: 9cb1fd0efd195590b828b9b865421ad345a4a145
>> --
>> 2.26.2
>
_______________________________________________
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: Guenter Roeck @ 2020-05-29 19:08 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
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: <a0c0310f-9870-47be-4ca3-c07e41c380fc@collabora.com>
On 5/29/20 10:21 AM, Andrzej Pietrasiewicz wrote:
> 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.
>
Quite confusing, especially since the ti-soc driver doesn't seem to use
the variable at all after setting it, and the stm_thermal driver uses it
to reflect power status associated with suspend/resume. So, yes, I agree
this is fine.
Thanks,
Guenter
> 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 v14 1/3] dt-bindings: i2c: npcm7xx: add NPCM I2C controller
From: Rob Herring @ 2020-05-29 19:07 UTC (permalink / raw)
To: Tali Perry
Cc: devicetree, benjaminfair, kfting, avifishman70, venture, openbmc,
wsa, brendanhiggins, ofery, linux-kernel, yuenn, robh+dt,
linux-i2c, andriy.shevchenko, linux-arm-kernel, tmaimon77
In-Reply-To: <20200527200820.47359-2-tali.perry1@gmail.com>
On Wed, 27 May 2020 23:08:18 +0300, Tali Perry wrote:
> Added device tree binding documentation for Nuvoton BMC
> NPCM I2C controller.
>
> Signed-off-by: Tali Perry <tali.perry1@gmail.com>
> ---
> .../bindings/i2c/nuvoton,npcm7xx-i2c.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 0/8] Convert the intel iommu driver to the dma-iommu api
From: Logan Gunthorpe @ 2020-05-29 19:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Marek Szyprowski, Jean-Philippe Brucker, linux-samsung-soc,
Marc Zyngier, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, Andy Gross, linux-arm-kernel, linux-s390,
linux-arm-msm, intel-gfx, Jani Nikula, Alex Williamson,
linux-mediatek, Rodrigo Vivi, Matthias Brugger, Thomas Gleixner,
virtualization, Gerald Schaefer, David Woodhouse, Cornelia Huck,
linux-kernel, Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <20200529124523.GA11817@infradead.org>
On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
>>> This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
>>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51
>>>
>>> Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
>
> Mark did a big audit into the map_sg API abuse and initially had
> some i915 patches, but then gave up on them with this comment:
>
> "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix
> it fully. The driver creatively uses sg_table->orig_nents to store the
> size of the allocate scatterlist and ignores the number of the entries
> returned by dma_map_sg function. In this patchset I only fixed the
> sg_table objects exported by dmabuf related functions. I hope that I
> didn't break anything there."
>
> it would be really nice if the i915 maintainers could help with sorting
> that API abuse out.
>
I agree completely that the API abuse should be sorted out, but I think
that's much larger than just the i915 driver. Pretty much every dma-buf
map_dma_buf implementation I looked at ignores the returned nents of
sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See:
amdgpu_dma_buf_map
armada_gem_prime_map_dma_buf
drm_gem_map_dma_buf
i915_gem_map_dma_buf
tegra_gem_prime_map_dma_buf
So this should probably be addressed by the whole GPU community.
However, as Robin pointed out, there are other ugly tricks like stopping
iterating through the SGL when sg_dma_len() is zero. For example, the
AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
this trick and thus likely isn't buggy (otherwise, I'd expect someone to
have complained by now seeing AMD has already switched to IOMMU-DMA.
As I tried to point out in my previous email, i915 does not do this
trick. In fact, it completely ignores sg_dma_len() and is thus
completely broken. See i915_scatterlist.h and the __sgt_iter() function.
So it doesn't sound to me like Mark's fix would address the issue at
all. Per my previous email, I'd guess that it can be fixed simply by
adjusting the __sgt_iter() function to do something more sensible.
(Better yet, if possible, ditch __sgt_iter() and use the common DRM
function that AMD uses).
This would at least allow us to make progress with Tom's IOMMU-DMA patch
set and once that gets in, it will be harder for other drivers to make
the same mistake.
Logan
_______________________________________________
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 0/2] soc: ti: add k3 platforms chipid module driver
From: Arnd Bergmann @ 2020-05-29 18:34 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Nishanth Menon, DTML, Dave Gerlach, Lokesh Vutla, Sekhar Nori,
linux-kernel@vger.kernel.org, Tero Kristo, Rob Herring,
Santosh Shilimkar, Linux ARM
In-Reply-To: <a132765e-f4e4-a1e8-fb43-239188fecf1b@ti.com>
On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> On 12/05/2020 15:34, Grygorii Strashko wrote:
> > .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
> > drivers/soc/ti/Kconfig | 10 ++
> > drivers/soc/ti/Makefile | 1 +
> > drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
> > 4 files changed, 203 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
> > create mode 100644 drivers/soc/ti/k3-socinfo.c
> >
>
> Any chances you can pick this up?
I merged a version of this driver from Santosh's pull request into the
arm/drviers tree yesterday.
Is there something missing?
Arnd
_______________________________________________
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 0/2] soc: ti: add k3 platforms chipid module driver
From: Grygorii Strashko @ 2020-05-29 18:22 UTC (permalink / raw)
To: Santosh Shilimkar, Tero Kristo, Rob Herring, Lokesh Vutla,
devicetree, Arnd Bergmann
Cc: Nishanth Menon, Sekhar Nori, linux-kernel, linux-arm-kernel,
Dave Gerlach
In-Reply-To: <20200512123449.16517-1-grygorii.strashko@ti.com>
Hi Santosh,
On 12/05/2020 15:34, Grygorii Strashko wrote:
> Hi All,
>
> This series introduces TI K3 Multicore SoC platforms chipid module driver
> which provides identification support of the TI K3 SoCs (family, revision)
> and register this information with the SoC bus. It is available under
> /sys/devices/soc0/ for user space, and can be checked, where needed,
> in Kernel using soc_device_match().
> It is also required for introducing support for new revisions of
> K3 AM65x/J721E SoCs.
>
> Example J721E:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments K3 J721E SoC
> J721E
> SR1.0
>
> Example AM65x:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments AM654 Base Board
> AM65X
> SR1.0
>
> Changes in v4:
> - convert to platform_driver as suggested by Arnd Bergmann <arnd@arndb.de>
>
> Changes in v3:
> - add handling of kasprintf() fail
>
> Changes in v2:
> - pr_debug() replaced with pr_info() to show SoC info on init
> - minor format change
> - split series on driver and platform changes
> - add Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
>
> v3: https://lkml.org/lkml/2020/5/8/357
> v2: https://lkml.org/lkml/2020/5/5/1193
> v1: https://lwn.net/Articles/818577/
>
> Grygorii Strashko (2):
> dt-bindings: soc: ti: add binding for k3 platforms chipid module
> soc: ti: add k3 platforms chipid module driver
>
> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
> drivers/soc/ti/Kconfig | 10 ++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
> 4 files changed, 203 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
> create mode 100644 drivers/soc/ti/k3-socinfo.c
>
Any chances you can pick this up?
--
Best regards,
grygorii
_______________________________________________
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/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-29 18:20 UTC (permalink / raw)
To: Pavel Machek
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200529180743.GA1081@bug>
On 29.05.20 20:07, Pavel Machek wrote:
> Hi!
>
> Plus, do we need calibration matrix for magnetometer?
I guess so. It's not a calibration matrix, it's the mount matrix that
tells you how the chip is placed on the PCB relative to a "natural"
orientation, see
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-iio#L1638
>
> Best regards,
> Pavel
>
_______________________________________________
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 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Rob Herring @ 2020-05-29 18:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
Eric Anholt, bcm-kernel-feedback-list, Nicolas Saenz Julienne,
Phil Elwell, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <e85e24a494a3ff41177c94673ced0f4280b6a0ee.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index 000000000000..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license...
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt <eric@anholt.net>
> +
> +properties:
> + compatible:
> + enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
What's the difference between the 2 blocks?
> +
> + reg:
> + items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> + items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> + description: The HDMI state machine clock
> +
> + clock-names:
> + const: hdmi
> +
> + ddc:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> + description: >
> + Phandle of the I2C controller used for DDC EDID probing
Goes in the connector.
And isn't the standard name ddc-i2c-bus?
> +
> + hpd-gpios:
> + description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
Goes in the connector.
> +
> + dmas:
> + maxItems: 1
> + description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> + const: audio-rx
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hdmi0: hdmi@7ef00700 {
> + compatible = "brcm,bcm2711-hdmi0";
> + reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef20000 0x100>;
> + reg-names = "hdmi",
> + "dvp",
> + "phy",
> + "rm",
> + "packet",
> + "metadata",
> + "csc",
> + "cec",
> + "hd";
> + clocks = <&firmware_clocks 13>;
> + clock-names = "hdmi";
> + resets = <&dvp 0>;
> + ddc = <&ddc0>;
> + };
> +
> +...
> --
> git-series 0.9.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] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Mark Brown @ 2020-05-29 18:16 UTC (permalink / raw)
To: Tzung-Bi Shih
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: <CA+Px+wVhXoU=BdBmMW0sdPtUrnQH+Kn6dkFdW-n67qEDGceCEQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 657 bytes --]
On Sat, May 30, 2020 at 01:26:20AM +0800, Tzung-Bi Shih wrote:
> On Fri, May 29, 2020 at 9:05 PM Mark Brown <broonie@kernel.org> wrote:
> > 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.
Oh, interesting - so it's essentially a mixer? Not seen that before but
makes sense. In any case this definitely seems like a good fit for a DT
property.
[-- 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 02/25] dt-bindings: clock: Add a binding for the RPi Firmware clocks
From: Rob Herring @ 2020-05-29 18:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Tim Gover, Dave Stevenson, Stephen Boyd,
Michael Turquette, linux-kernel, Phil Elwell, Rob Herring,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, linux-clk,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <919e2f2f13583d4d53d0e95b81fc3fb8a7606107.1590594293.git-series.maxime@cerno.tech>
On Wed, 27 May 2020 17:44:58 +0200, Maxime Ripard wrote:
> The firmware running on the RPi VideoCore can be used to discover and
> change the various clocks running in the BCM2711. Since devices will
> need to use them through the DT, let's add a pretty simple binding.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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/2] arm64: dts: Add a device tree for the Librem5 phone
From: Pavel Machek @ 2020-05-29 18:07 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200529162850.GC3709@amd>
Hi!
Plus, do we need calibration matrix for magnetometer?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
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 18:04 UTC (permalink / raw)
To: Lukas Wunner
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: <20200529175831.p4dphb5luymgapzx@wunner.de>
On 5/29/20 10:58 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
>> 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.
>
> Thanks for the explanation, that's an important tidbit. I wasn't even
> aware that this SPI controller is used on SoCs beyond the Raspberry Pi
> ones. Does the BCM7211 use shared interrupts for this controller?
> Does it have DMA DREQ attached?
For all practical purposes you can consider that 7211 is identical to a
2711, it does use shared interrupts for this controller and there is a
DRAM DREQ attached as well. Where they differ are on the display, video,
and memory controller MAC.
--
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: 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
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