* [PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/mioa701.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 38a96a193dc4..8a5d0491e73c 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -57,7 +57,6 @@
#include <linux/platform_data/media/camera-pxa.h>
#include <mach/audio.h>
#include <mach/smemc.h>
-#include <media/soc_camera.h>
#include "mioa701.h"
@@ -627,6 +626,8 @@ struct pxacamera_platform_data mioa701_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 5000,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
static struct i2c_board_info __initdata mioa701_pi2c_devices[] = {
@@ -643,12 +644,6 @@ static struct i2c_board_info mioa701_i2c_devices[] = {
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0, /* Match id in pxa27x_device_camera in device.c */
- .board_info = &mioa701_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
struct i2c_pxa_platform_data i2c_pdata = {
.fast_mode = 1,
};
@@ -684,7 +679,6 @@ MIO_SIMPLE_DEV(mioa701_sound, "mioa701-wm9713", NULL)
MIO_SIMPLE_DEV(mioa701_board, "mioa701-board", NULL)
MIO_SIMPLE_DEV(wm9713_acodec, "wm9713-codec", NULL);
MIO_SIMPLE_DEV(gpio_vbus, "gpio-vbus", &gpio_vbus_data);
-MIO_SIMPLE_DEV(mioa701_camera, "soc-camera-pdrv",&iclink);
static struct platform_device *devices[] __initdata = {
&mioa701_gpio_keys,
@@ -696,7 +690,6 @@ static struct platform_device *devices[] __initdata = {
&power_dev,
&docg3,
&gpio_vbus,
- &mioa701_camera,
&mioa701_board,
};
@@ -761,6 +754,7 @@ static void __init mioa701_machine_init(void)
platform_add_devices(devices, ARRAY_SIZE(devices));
gsm_init();
+ i2c_register_board_info(0, ARRAY_AND_SIZE(mioa701_i2c_devices));
i2c_register_board_info(1, ARRAY_AND_SIZE(mioa701_pi2c_devices));
pxa_set_i2c_info(&i2c_pdata);
pxa27x_set_i2c_power_info(NULL);
@@ -769,6 +763,7 @@ static void __init mioa701_machine_init(void)
regulator_register_always_on(0, "fixed-5.0V", fixed_5v0_consumers,
ARRAY_SIZE(fixed_5v0_consumers),
5000000);
+ regulator_has_full_constraints();
}
static void mioa701_machine_exit(void)
--
2.1.4
^ permalink raw reply related
* Alignment issues with freescale FEC driver
From: Uwe Kleine-König @ 2016-09-23 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183725.GC1041@n2100.armlinux.org.uk>
Hello Russell,
On Fri, Sep 23, 2016 at 07:37:25PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote:
> > So the question is: should we just live with this and acknowledge a
> > performance penalty of bad alignment or do something about it?
>
> Well, I've no interest in trying to do anything with the FEC driver
> anymore, as I'll just generate another big patch stack which won't
> make it into the kernel in a timely fashion - my last attempt at
> improving the FEC driver was dogged with conflicting changes and I
> gave up with it in the end. I ended up spending a full cycle
> rebasing, re-testing, and re-evaluating their performance only to find
> that I'd missed the merge window again, and other conflicting changes
> got merged which meant that I had to start from the beginning again.
I'm not included in the set of people who are responsible to review and
merge fec patches, but I'd be surprised if you couldn't get an exclusive
lock for that driver. Something like: After 4.X-rc1 the fec isn't
touched any more until you got your series ready for the 4.X+1 merge
window. Of course some fixes might have to go in, but these hopefully
won't disturb much.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/3] nvmem: dt: document lpc1850 OTP binding
From: Joachim Eastwood @ 2016-09-23 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923133529.GA23548@rob-hp-laptop>
On 23 September 2016 at 15:35, Rob Herring <robh@kernel.org> wrote:
> On Tue, Sep 13, 2016 at 06:12:40PM +0200, Joachim Eastwood wrote:
>> Documenation for the LPC18xx/43xx OTP memory bindings.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> .../devicetree/bindings/nvmem/lpc1850-otp.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>> new file mode 100644
>> index 0000000..853b6a7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>> @@ -0,0 +1,20 @@
>> +* NXP LPC18xx OTP memory
>> +
>> +Internal OTP (One Time Programmable) memory for NXP LPC18xx/43xx devices.
>> +
>> +Required properties:
>> + - compatible: Should be "nxp,lpc1850-otp"
>> + - reg: Must contain an entry with the physical base address and length
>> + for each entry in reg-names.
>
>> + - address-cells: must be set to 1.
>> + - size-cells: must be set to 1.
>
> Not needed unless you have child nodes.
They will have "nvmem" cell children. See patch 3/3
+ /* Flashless devices has part ID in OTP bank 0 */
+ part_id: identification at 0 {
+ reg = <0x0 0x10>;
+ };
These cells are documented in nvmem.txt.
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH 2/3] firmware: dt: document lpc1850 boot ROM bindings
From: Joachim Eastwood @ 2016-09-23 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923133949.GA24505@rob-hp-laptop>
On 23 September 2016 at 15:39, Rob Herring <robh@kernel.org> wrote:
> On Tue, Sep 13, 2016 at 09:51:16PM +0200, Joachim Eastwood wrote:
>> Binding documentation for the NXP LPC boot ROM.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> .../devicetree/bindings/firmware/nxp,boot-rom.txt | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>> new file mode 100644
>> index 0000000..5f3a044
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>> @@ -0,0 +1,21 @@
>> +* NXP LPC boot ROM
>> +
>> +NXP LPC microcontrollers contains a boot ROM used to retrieve part information
>> +and access internal Flash memory and OTP memory. Note that the Flash API is
>> +not available on Flashless devices.
>
> Is this determined at run-time? If not flashless devices should have a
> different compatible string to determine this then.
It is determined at run time by reading a 'CHIP ID' register in CREG
(syscon) that is present on both Flash and Flashless devices.
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH] serial: stm32: use mapbase instead of membase for DMA
From: Arnd Bergmann @ 2016-09-23 19:38 UTC (permalink / raw)
To: linux-arm-kernel
Building this driver with a 64-bit dma_addr_t type results in
a compiler warning:
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_rx_probe':
drivers/tty/serial/stm32-usart.c:746:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_tx_probe':
drivers/tty/serial/stm32-usart.c:818:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
While the type conversion here is harmless, this hints at a different
problem: we pass an __iomem pointer into a DMA engine, which expects
a phys_addr_t. This happens to work because stm32 has no MMU and
ioremap() is an identity mapping here, but it's still an incorrect
API use. Using dma_addr_t is doubly wrong here, because that would
be the result of dma_map_single() rather than the physical address.
Using the mapbase instead fixes multiple issues:
- the warning is gone
- we don't go through ioremap in error
- the cast is gone, making it use the correct resource_size_t/phys_addr_t
type in the process.
Fixes: 3489187204eb ("serial: stm32: adding dma support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/tty/serial/stm32-usart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 4d3001b77e7e..2adb678a863b 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -743,7 +743,7 @@ static int stm32_of_dma_rx_probe(struct stm32_port *stm32port,
/* Configure DMA channel */
memset(&config, 0, sizeof(config));
- config.src_addr = (dma_addr_t)port->membase + ofs->rdr;
+ config.src_addr = port->mapbase + ofs->rdr;
config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
ret = dmaengine_slave_config(stm32port->rx_ch, &config);
@@ -815,7 +815,7 @@ static int stm32_of_dma_tx_probe(struct stm32_port *stm32port,
/* Configure DMA channel */
memset(&config, 0, sizeof(config));
- config.dst_addr = (dma_addr_t)port->membase + ofs->tdr;
+ config.dst_addr = port->mapbase + ofs->tdr;
config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
ret = dmaengine_slave_config(stm32port->tx_ch, &config);
--
2.9.0
^ permalink raw reply related
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Christopher Covington @ 2016-09-23 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923191710.GB16019@localhost>
On 09/23/2016 03:17 PM, Bjorn Helgaas wrote:
> On Fri, Sep 23, 2016 at 02:41:39PM -0400, Christopher Covington wrote:
>> On 09/22/2016 07:08 PM, Bjorn Helgaas wrote:
>>> On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote:
>>>> Hi Bjorn,
>>>>
>>>> On 09/21/2016 09:11 AM, Bjorn Helgaas wrote:
>>>>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
>>>>
>>>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>>>> index eb14f74..bb3b8ad 100644
>>>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>>>> @@ -42,86 +42,59 @@ struct mcfg_fixup {
>>>>>>> struct resource cfgres;
>>>>>>> };
>>>>>>>
>>>>>>> -#define MCFG_DOM_ANY (-1)
>>>>>>
>>>>>> Did you delete this because there were no current users, because you'd
>>>>>> prefer users just use "-1", or for some other reason?
>>>>>
>>>>> I removed it because there were no users of it and, more importantly,
>>>>> the code doesn't implement support for it.
>>>>
>>>> It looks like a stale "First match against PCI topology <domain:bus>..."
>>>> comment remains.
>>>
>>> Yep. I removed the comment since it's sort of obvious from the code.
>>> I also renamed a few things and pulled the match out into a helper
>>> function.
>>>
>>> I also changed the dmesg note: I think the actual resource and the
>>> name of the pci_ecam_ops is more interesting than the table IDs (which
>>> I think are already elsewhere in the dmesg log).
>>
>> It looks like the resource is already being printed from
>> drivers/pci/ecam.c:102.
>
> Yes, but I want a hint that a quirk has overridden it because that's a
> clue that there's something wonky about the platform or the firmware.
>
> But I guess it'd be nice to mirror the format of the existing info
> (mem first, then bus range).
>
>>> Here's the incremental diff, which I can't really test:
>>
>> Here's what it looks like for me:
>>
>> ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>> acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
>> acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
>> acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
>> acpi PNP0A08:02: MCFG quirk: ECAM space for [bus 00-1f] at [mem 0xa0000000000-0xa0001ffffff] with pci_3
>
> Is "pci_3" really the entire name? If not, what happened to the rest?
> I was hoping for a symbol we could grep for.
The full name is pci_32b_ops. The print overflowed my tmux pane.
>> acpi PNP0A08:02: ECAM at [mem 0xa0000000000-0xa0001ffffff] for [bus 00-1f]
>> Remapped I/O 0x00000affffff0000 to [io 0x10000-0x1ffff window]
>> PCI host bridge to bus 0002:00
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Bjorn Helgaas @ 2016-09-23 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1b1c38f-0779-82a5-5d3c-b164215a4ed3@codeaurora.org>
On Fri, Sep 23, 2016 at 02:41:39PM -0400, Christopher Covington wrote:
> On 09/22/2016 07:08 PM, Bjorn Helgaas wrote:
> > On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote:
> >> Hi Bjorn,
> >>
> >> On 09/21/2016 09:11 AM, Bjorn Helgaas wrote:
> >>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
> >>
> >>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> >>>>> index eb14f74..bb3b8ad 100644
> >>>>> --- a/drivers/acpi/pci_mcfg.c
> >>>>> +++ b/drivers/acpi/pci_mcfg.c
> >>>>> @@ -42,86 +42,59 @@ struct mcfg_fixup {
> >>>>> struct resource cfgres;
> >>>>> };
> >>>>>
> >>>>> -#define MCFG_DOM_ANY (-1)
> >>>>
> >>>> Did you delete this because there were no current users, because you'd
> >>>> prefer users just use "-1", or for some other reason?
> >>>
> >>> I removed it because there were no users of it and, more importantly,
> >>> the code doesn't implement support for it.
> >>
> >> It looks like a stale "First match against PCI topology <domain:bus>..."
> >> comment remains.
> >
> > Yep. I removed the comment since it's sort of obvious from the code.
> > I also renamed a few things and pulled the match out into a helper
> > function.
> >
> > I also changed the dmesg note: I think the actual resource and the
> > name of the pci_ecam_ops is more interesting than the table IDs (which
> > I think are already elsewhere in the dmesg log).
>
> It looks like the resource is already being printed from
> drivers/pci/ecam.c:102.
Yes, but I want a hint that a quirk has overridden it because that's a
clue that there's something wonky about the platform or the firmware.
But I guess it'd be nice to mirror the format of the existing info
(mem first, then bus range).
> > Here's the incremental diff, which I can't really test:
>
> Here's what it looks like for me:
>
> ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
> acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
> acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
> acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
> acpi PNP0A08:02: MCFG quirk: ECAM space for [bus 00-1f] at [mem 0xa0000000000-0xa0001ffffff] with pci_3
Is "pci_3" really the entire name? If not, what happened to the rest?
I was hoping for a symbol we could grep for.
> acpi PNP0A08:02: ECAM at [mem 0xa0000000000-0xa0001ffffff] for [bus 00-1f]
> Remapped I/O 0x00000affffff0000 to [io 0x10000-0x1ffff window]
> PCI host bridge to bus 0002:00
>
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index 245b79f..0b36bc5 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -36,7 +36,7 @@ struct mcfg_fixup {
> > char oem_id[ACPI_OEM_ID_SIZE + 1];
> > char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> > u32 oem_revision;
> > - u16 seg;
> > + u16 segment;
> > struct resource bus_range;
> > struct pci_ecam_ops *ops;
> > struct resource cfgres;
> > @@ -102,30 +102,37 @@ static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> > static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> > static u32 mcfg_oem_revision;
> >
> > -static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
> > +static int pci_mcfg_quirk_matches(struct mcfg_fixup *f, u16 segment,
> > + struct resource *bus_range)
> > +{
> > + if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> > + !memcmp(f->oem_table_id, mcfg_oem_table_id,
> > + ACPI_OEM_TABLE_ID_SIZE) &&
> > + f->oem_revision == mcfg_oem_revision &&
> > + f->segment == segment &&
> > + resource_contains(&f->bus_range, bus_range))
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> > +static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
> > struct resource *cfgres,
> > struct pci_ecam_ops **ecam_ops)
> > {
> > + u16 segment = root->segment;
> > + struct resource *bus_range = &root->secondary;
> > struct mcfg_fixup *f;
> > int i;
> >
> > - /*
> > - * First match against PCI topology <domain:bus> then use OEM ID, OEM
> > - * table ID, and OEM revision from MCFG table standard header.
> > - */
> > for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
> > - if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> > - !memcmp(f->oem_table_id, mcfg_oem_table_id,
> > - ACPI_OEM_TABLE_ID_SIZE) &&
> > - f->oem_revision == mcfg_oem_revision &&
> > - f->seg == root->segment &&
> > - resource_contains(&f->bus_range, &root->secondary)) {
> > + if (pci_mcfg_quirk_matches(f, segment, bus_range)) {
> > if (f->cfgres.start)
> > *cfgres = f->cfgres;
> > if (f->ops)
> > *ecam_ops = f->ops;
> > - dev_info(&root->device->dev, "Applying PCI MCFG quirks for %s %s rev: %d\n",
> > - f->oem_id, f->oem_table_id, f->oem_revision);
> > + dev_info(&root->device->dev, "MCFG quirk: ECAM space for %pR at %pR with %ps\n",
> > + bus_range, cfgres, *ecam_ops);
> > return;
> > }
> > }
> > @@ -173,7 +180,7 @@ skip_lookup:
> > * MCFG does not have it. Invalid CFG start address means MCFG
> > * firmware bug or we need another quirk in array.
> > */
> > - pci_mcfg_match_quirks(root, &res, &ops);
> > + pci_mcfg_apply_quirks(root, &res, &ops);
> > if (!res.start)
> > return -ENXIO;
> >
> >
>
>
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
> Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Peter Ujfalusi @ 2016-09-23 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06e0406c-3ff0-a069-a48a-0b1b82872f98@oracle.com>
On 09/23/2016 06:24 PM, Santosh Shilimkar wrote:
> On 9/23/2016 7:26 AM, Tony Lindgren wrote:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
>>> On 09/22/16 21:07, Tony Lindgren wrote:
>
> [...]
>
>>> On which linux-next version you are seeing this?
>>
>> This was with next-20160922. But testing it again this is just another
>> regression caused by "softirq: fix tasklet_kill() and its users", so adding
>> Santosh to Cc.
>>
>> So no need to revert $subject patch.
>>
> So your driver also looks like fiddling with tasklet core structures if
> you got impacted because of the core change.
How is that? None of the drivers in the twl6040 stack uses tasklets
explicitly. The core uses regmap_irq and the drivers use threaded irq when
they need interrupt handling, but no tasklet, no fiddling with internals.
--
P?ter
> After the merge window
> am going to take stab at bad users of tasklet but below is
> quick snap shot conversation I had with Thomas and Andrew...
>
> ------------------------------------------------------------------
> B1;2802;0cOn Wed, 21 Sep 2016, Santosh Shilimkar wrote:
>> I requested you to include this patch but now am not sure anymore.
>> Looks like there are almost 30 more users which are directly
>> tweaking 'tasklet_struct' fields and calling other APIs. Hunting them
>> and fixing them probably would be an exercise and also those changes
>> needs those changed drivers to be tested.
>>
>> What do you suggest ? At least this patch needs to be dropped as of now
>> till we can have complete coverage for those bad users.
>
> Yes, it needs to be dropped. Stephen, can you please revert it from next?
>
> How to fix this: The only way is to review all tasklet usage sites for
> creative abuse and then fix them one by one. This needs to be done anyway
> because those are ticking timebombs even without changes in the core
> code. I looked at one of the offenders and it's broken today, it's just
> protected by the extremly low probablity to hit the wreckage case.
>
> What you can do to coerce the developers/maintainers of offending code into
> looking at the mess they created/merged is to implement accessors for the
> tasklet struct fields and replace the open coded fiddling with them.
>
> Once that is done, rename the struct fields to something which is absurd
> enough to type. But don't worry, you will find people doing that. I
> catched a few brainwrecks who actually used:
>
> irqdesc->core_internal_state__do_not_mess_with_it
>
> in their code.
>
> Now after having everything converted to accessors, you can add sanity
> checks into the accessors and emit WARN_ONCE() when they are used in the
> wrong context. That'll make them look and explain why they think that
> fiddling in the internals is a good idea.
>
> Thanks,
>
> tglx
> ------------------------------------------------------------------
>
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Stefan Wahren @ 2016-09-23 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-2-eric@anholt.net>
Hi Eric,
> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13 geschrieben:
>
>
> This driver will be used for accessing the FXL6408 GPIO exander on the
> Pi3. We can't drive it directly from Linux because the firmware is
> continuously polling one of the expander's lines to do its
> undervoltage detection.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> ...
> +
> +static int rpi_gpio_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *fw_node;
> + struct rpi_gpio *rpi;
> + u32 ngpio;
> + int ret;
> +
> + rpi = devm_kzalloc(dev, sizeof *rpi, GFP_KERNEL);
> + if (!rpi)
> + return -ENOMEM;
> + rpi->dev = dev;
> +
> + fw_node = of_parse_phandle(np, "firmware", 0);
AFAIK fw_node must be freed with of_node_put() after usage
> + if (!fw_node) {
> + dev_err(dev, "Missing firmware node\n");
> + return -ENOENT;
> + }
> +
> + rpi->firmware = rpi_firmware_get(fw_node);
> + if (!rpi->firmware)
> + return -EPROBE_DEFER;
> +
> + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpio)) {
> + dev_err(dev, "Missing ngpios");
> + return -ENOENT;
> + }
> + if (of_property_read_u32(pdev->dev.of_node,
> + "raspberrypi,firmware-gpio-offset",
> + &rpi->offset)) {
> + dev_err(dev, "Missing raspberrypi,firmware-gpio-offset");
> + return -ENOENT;
> + }
> +
> + rpi->gc.label = np->full_name;
> + rpi->gc.owner = THIS_MODULE;
> + rpi->gc.of_node = np;
> + rpi->gc.ngpio = ngpio;
> + rpi->gc.direction_input = rpi_gpio_dir_in;
> + rpi->gc.direction_output = rpi_gpio_dir_out;
> + rpi->gc.get = rpi_gpio_get;
> + rpi->gc.set = rpi_gpio_set;
> + rpi->gc.can_sleep = true;
i think it's better to assign rpi->gc.base explicit.
Stefan
^ permalink raw reply
* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-09-23 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923180239.GC29830@leverpostej>
On 9/23/2016 2:02 PM, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> index fd5618b..47bfb5a 100644
>> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> @@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
>> the channel nodes appear on their own, not under a management node.
>>
>> Required properties:
>> -- compatible: must contain "qcom,hidma-1.0"
>> +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
>> +for MSI capable HW.
>> - reg: Addresses for the transfer and event channel
>> - interrupts: Should contain the event interrupt
>> - desc-count: Number of asynchronous requests this channel can handle
>> - iommus: required a iommu node
>>
>> +Optional properties for MSI:
>> +- msi-parent: pointer to the MSI controller object with the DeviceID in use.
>
> The format of msi-cells depends on the particular msi-controller, so no
> need to mention DeviceID here.
>
> Please refer to
> Documentation/devicetree/bindings/interrupt-controller/msi.txt
Thanks, let me do some more research.
>
>> +Example:
>> + msi_parent: <&msi0 0x80024>
>
> This doesn't match (s/_/-/).
ok
>
>> +msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
>> +is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
>> +instance 1.
>
> I don't think you need any of this text, so long as you refer to the
> generic MSI binding document, as above.
ok
>
> Thanks,
> Mark.
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183725.GC1041@n2100.armlinux.org.uk>
Thanks Russell,
On 09/23/2016 11:37 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote:
>> So the question is: should we just live with this and acknowledge a
>> performance penalty of bad alignment or do something about it?
>
> Well, I've no interest in trying to do anything with the FEC driver
> anymore, as I'll just generate another big patch stack which won't
> make it into the kernel in a timely fashion - my last attempt at
> improving the FEC driver was dogged with conflicting changes and I
> gave up with it in the end. I ended up spending a full cycle
> rebasing, re-testing, and re-evaluating their performance only to find
> that I'd missed the merge window again, and other conflicting changes
> got merged which meant that I had to start from the beginning again.
>
That's sad. I recall reading your notes on that patch series and it was
a model for how to structure and document a patch set.
I hadn't noticed that you abandoned it and it's frustrating that the
merge process prevented your efforts from being used.
I'm also disheartened to hear your frustration about getting things
pushed up-stream and the entire Linux community should take note.
>> I'm not sure the cost (or the details) of Eric's proposed fix of allocating
>> and copying the header to another skb.
>
> I had a quick look at this, and although Eric's idea may be a good
> idea, it doesn't contain enough details for me to be able to
> implement it - eg, I've no idea how to attach the 128-byte skb to the
> beginning of a previously allocated skb containing the rest of the
> packet. I've just looked through linux/skbuff.h and I can't see
> anything that takes two sk_buff's that would do the job.
>
> However, I don't think that's necessary in this case, because the
> iMX6 FEC supports the 16-bit alignment of the packet, if only it was
> enabled in hardware and the driver caters for it.
>
Right. If the hardware supports placing things at a suitable address,
that's the right approach.
I'll try to review your earlier patch set and at least find a way to address
the alignment issues.
I'm a bit booked until LinuxCon but will try to get something out soon.
Regards,
Eric
^ permalink raw reply
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Christopher Covington @ 2016-09-23 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922230806.GB1514@localhost>
On 09/22/2016 07:08 PM, Bjorn Helgaas wrote:
> On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote:
>> Hi Bjorn,
>>
>> On 09/21/2016 09:11 AM, Bjorn Helgaas wrote:
>>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
>>
>>>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>>>> index eb14f74..bb3b8ad 100644
>>>>> --- a/drivers/acpi/pci_mcfg.c
>>>>> +++ b/drivers/acpi/pci_mcfg.c
>>>>> @@ -42,86 +42,59 @@ struct mcfg_fixup {
>>>>> struct resource cfgres;
>>>>> };
>>>>>
>>>>> -#define MCFG_DOM_ANY (-1)
>>>>
>>>> Did you delete this because there were no current users, because you'd
>>>> prefer users just use "-1", or for some other reason?
>>>
>>> I removed it because there were no users of it and, more importantly,
>>> the code doesn't implement support for it.
>>
>> It looks like a stale "First match against PCI topology <domain:bus>..."
>> comment remains.
>
> Yep. I removed the comment since it's sort of obvious from the code.
> I also renamed a few things and pulled the match out into a helper
> function.
>
> I also changed the dmesg note: I think the actual resource and the
> name of the pci_ecam_ops is more interesting than the table IDs (which
> I think are already elsewhere in the dmesg log).
It looks like the resource is already being printed from
drivers/pci/ecam.c:102.
> Here's the incremental diff, which I can't really test:
Here's what it looks like for me:
ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
acpi PNP0A08:02: MCFG quirk: ECAM space for [bus 00-1f] at [mem 0xa0000000000-0xa0001ffffff] with pci_3
acpi PNP0A08:02: ECAM at [mem 0xa0000000000-0xa0001ffffff] for [bus 00-1f]
Remapped I/O 0x00000affffff0000 to [io 0x10000-0x1ffff window]
PCI host bridge to bus 0002:00
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 245b79f..0b36bc5 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -36,7 +36,7 @@ struct mcfg_fixup {
> char oem_id[ACPI_OEM_ID_SIZE + 1];
> char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> u32 oem_revision;
> - u16 seg;
> + u16 segment;
> struct resource bus_range;
> struct pci_ecam_ops *ops;
> struct resource cfgres;
> @@ -102,30 +102,37 @@ static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> static u32 mcfg_oem_revision;
>
> -static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
> +static int pci_mcfg_quirk_matches(struct mcfg_fixup *f, u16 segment,
> + struct resource *bus_range)
> +{
> + if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(f->oem_table_id, mcfg_oem_table_id,
> + ACPI_OEM_TABLE_ID_SIZE) &&
> + f->oem_revision == mcfg_oem_revision &&
> + f->segment == segment &&
> + resource_contains(&f->bus_range, bus_range))
> + return 1;
> +
> + return 0;
> +}
> +
> +static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
> struct resource *cfgres,
> struct pci_ecam_ops **ecam_ops)
> {
> + u16 segment = root->segment;
> + struct resource *bus_range = &root->secondary;
> struct mcfg_fixup *f;
> int i;
>
> - /*
> - * First match against PCI topology <domain:bus> then use OEM ID, OEM
> - * table ID, and OEM revision from MCFG table standard header.
> - */
> for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
> - if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
> - !memcmp(f->oem_table_id, mcfg_oem_table_id,
> - ACPI_OEM_TABLE_ID_SIZE) &&
> - f->oem_revision == mcfg_oem_revision &&
> - f->seg == root->segment &&
> - resource_contains(&f->bus_range, &root->secondary)) {
> + if (pci_mcfg_quirk_matches(f, segment, bus_range)) {
> if (f->cfgres.start)
> *cfgres = f->cfgres;
> if (f->ops)
> *ecam_ops = f->ops;
> - dev_info(&root->device->dev, "Applying PCI MCFG quirks for %s %s rev: %d\n",
> - f->oem_id, f->oem_table_id, f->oem_revision);
> + dev_info(&root->device->dev, "MCFG quirk: ECAM space for %pR at %pR with %ps\n",
> + bus_range, cfgres, *ecam_ops);
> return;
> }
> }
> @@ -173,7 +180,7 @@ skip_lookup:
> * MCFG does not have it. Invalid CFG start address means MCFG
> * firmware bug or we need another quirk in array.
> */
> - pci_mcfg_match_quirks(root, &res, &ops);
> + pci_mcfg_apply_quirks(root, &res, &ops);
> if (!res.start)
> return -ENXIO;
>
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183010.GB1041@n2100.armlinux.org.uk>
Thanks Russell,
On 09/23/2016 11:30 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote:
>>> Since the hardware requires longword alignment for its' DMA transfers,
>>> aligning the IP header will require a memcpy, right?
>>
>> The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
>> two padding bits on transmit. ENETx_RACC has the same.
>>
>> What about your hardware?
>
> The iMX6 FEC also has that ability - as part of my FEC patch stack from
> ages ago, I implemented support for it.
>
> "net:fec: implement almost zero-copy receive path"
>
> in my public fec-testing branch.
>
> That patch stack is sadly now totally dead and I've no interest in
> reviving it myself. There was some interest from others in taking my
> patch stack over, but that went quiet.
>
I'll take a look and hopefully revive at least part of the patch set.
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stefan Wahren @ 2016-09-23 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-1-eric@anholt.net>
Hi Eric,
> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13 geschrieben:
>
>
> The RPi firmware exposes all of the board's GPIO lines through
> property calls. Linux chooses to control most lines directly through
> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
> need to access them through the firmware.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> .../bindings/gpio/gpio-raspberrypi-firmware.txt | 22
> ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>
> diff --git
> a/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> new file mode 100644
> index 000000000000..2b635c23a6f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> @@ -0,0 +1,22 @@
> +Raspberry Pi power domain driver
> +
> +Required properties:
> +
> +- compatible: Should be "raspberrypi,firmware-gpio"
i think the compatible should be more specific like
raspberrypi,rpi3-firmware-gpio
and all information which aren't requestable from the firmware should be stored
in a info structure. This makes the driver easier to extend in the future by
adding new compatibles and their info structures.
> +- gpio-controller: Marks the device node as a gpio controller
> +- #gpio-cells: Should be <2> for GPIO number and flags
> +- ngpios: Number of GPIO lines to control. See gpio.txt
> +- firmware: Reference to the RPi firmware device node
> +- raspberrypi,firmware-gpio-offset:
> + Number the firmware uses for the first GPIO line
> + controlled by this driver
We should avoid such properties because they don't really describe the hardware.
Stefan
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Russell King - ARM Linux @ 2016-09-23 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0d6f333-c6fc-6572-0633-d7c2c29b8b3f@nelint.com>
On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote:
> So the question is: should we just live with this and acknowledge a
> performance penalty of bad alignment or do something about it?
Well, I've no interest in trying to do anything with the FEC driver
anymore, as I'll just generate another big patch stack which won't
make it into the kernel in a timely fashion - my last attempt at
improving the FEC driver was dogged with conflicting changes and I
gave up with it in the end. I ended up spending a full cycle
rebasing, re-testing, and re-evaluating their performance only to find
that I'd missed the merge window again, and other conflicting changes
got merged which meant that I had to start from the beginning again.
> I'm not sure the cost (or the details) of Eric's proposed fix of allocating
> and copying the header to another skb.
I had a quick look at this, and although Eric's idea may be a good
idea, it doesn't contain enough details for me to be able to
implement it - eg, I've no idea how to attach the 128-byte skb to the
beginning of a previously allocated skb containing the rest of the
packet. I've just looked through linux/skbuff.h and I can't see
anything that takes two sk_buff's that would do the job.
However, I don't think that's necessary in this case, because the
iMX6 FEC supports the 16-bit alignment of the packet, if only it was
enabled in hardware and the driver caters for it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923181301.GD22965@lunn.ch>
Thanks Andrew.
On 09/23/2016 11:13 AM, Andrew Lunn wrote:
>> Since the hardware requires longword alignment for its' DMA transfers,
>> aligning the IP header will require a memcpy, right?
>
> The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
> two padding bits on transmit. ENETx_RACC has the same.
>
> What about your hardware?
>
You got me with the RTFM!
>From the i.MX6DQ reference manual, bit 7 of ENET_RACC says this:
"RX FIFO Shift-16
When this field is set, the actual frame data starts at bit 16 of the first
word read from the RX FIFO aligning the Ethernet payload on a
32-bit boundary."
Same for the i.MX6UL.
I'm not sure what it will take to use this, but it seems to be exactly
what we're looking for.
^ permalink raw reply
* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Rob Herring @ 2016-09-23 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-2-git-send-email-clg@kaod.org>
On Tue, Sep 20, 2016 at 09:01:38AM +0200, C?dric Le Goater wrote:
> From: Alistair Popple <alistair@popple.id.au>
>
> This patch adds a simple device driver to expose the iBT interface on
> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
> commonly used as BMCs (BaseBoard Management Controllers) and this
> driver implements the BMC side of the BT interface.
>
> The BT (Block Transfer) interface is used to perform in-band IPMI
> communication between a host and its BMC. Entire messages are buffered
> before sending a notification to the other end, host or BMC, that
> there is data to be read. Usually, the host emits requests and the BMC
> responses but the specification provides a mean for the BMC to send
> SMS Attention (BMC-to-Host attention or System Management Software
> attention) messages.
>
> For this purpose, the driver introduces a specific ioctl on the
> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
> on the BMC to signal the host of such an event.
>
> The device name defaults to '/dev/ipmi-bt-host'
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> [clg: - checkpatch fixes
> - added a devicetree binding documentation
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
> ]
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> [clg: - checkpatch --strict fixes
> - removed the use of devm_iounmap, devm_kfree in cleanup paths
> - introduced an atomic-t to limit opens to 1
> - introduced a mutex to protect write/read operations]
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>
> ---
>
> Changes since v2:
>
> - fixed checkpatch --strict issues
> - cleanup'ed includes
> - limit to one opener
> - protect write/read operations with a mutex.
> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>
> Changes since v1:
>
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>
> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
While similar, this is not the kernel directory structure. Just make
this bindings/ipmi/
With that,
Acked-by: Rob Herring <robh@kernel.org>
> drivers/Makefile | 2 +-
> drivers/char/ipmi/Kconfig | 7 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/bt-bmc.c | 510 +++++++++++++++++++++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/bt-bmc.h | 18 +
> 7 files changed, 561 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> create mode 100644 drivers/char/ipmi/bt-bmc.c
> create mode 100644 include/uapi/linux/bt-bmc.h
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Russell King - ARM Linux @ 2016-09-23 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923181301.GD22965@lunn.ch>
On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote:
> > Since the hardware requires longword alignment for its' DMA transfers,
> > aligning the IP header will require a memcpy, right?
>
> The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
> two padding bits on transmit. ENETx_RACC has the same.
>
> What about your hardware?
The iMX6 FEC also has that ability - as part of my FEC patch stack from
ages ago, I implemented support for it.
"net:fec: implement almost zero-copy receive path"
in my public fec-testing branch.
That patch stack is sadly now totally dead and I've no interest in
reviving it myself. There was some interest from others in taking my
patch stack over, but that went quiet.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923173751.GA1041@n2100.armlinux.org.uk>
Thanks Russell,
On 09/23/2016 10:37 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote:
>> Oddly, it does prevent the vast majority (90%+) of the alignment errors.
>>
>> I believe this is because the compiler is generating an ldm instruction
>> when the ntohl() call is used, but I'm stumped about why these aren't
>> generating faults:
After looking at it, I have to think that the code that reads iph->id
is just hit more frequently than the other code in this routine.
>
> ldm generates alignment faults when the address is not aligned to a
> 32-bit boundary. ldr on ARMv6+ does not.
>
>> I don't think that's the case.
>>
>> # CONFIG_IPV6_GRE is not set
>>
>> Hmm... Instrumenting the kernel, it seems that iphdr **is** aligned on
>> a 4-byte boundary.
>>
>> Does the ldm instruction require 8-byte alignment?
>>
>> There's definitely a compiler-version dependency involved here,
>> since using gcc 4.9 also reduced the number of faults dramatically.
>
> Well, I don't think it's that gcc related:
>
I can only say that I noticed a dramatic drop in the number of faults, and
didn't see the inet_gro_receive reported in /proc/cpu/alignment with gcc 4.9
when trying to identify the issue.
> User: 0
> System: 312855 (ip6_route_input+0x6c/0x1e0)
> Skipped: 0
> Half: 0
> Word: 0
> DWord: 2
> Multi: 312853
>
> c06d8998 <ip6_route_input>:
> c06d89ac: e1a04000 mov r4, r0
> c06d89b0: e1d489b4 ldrh r8, [r4, #148] ; 0x94
> c06d89b8: e594a0a0 ldr sl, [r4, #160] ; 0xa0
> c06d89cc: e08ac008 add ip, sl, r8
> c06d89d4: e28c3018 add r3, ip, #24
> c06d89dc: e28c7008 add r7, ip, #8
> c06d89e4: e893000f ldm r3, {r0, r1, r2, r3}
> c06d89ec: e24be044 sub lr, fp, #68 ; 0x44
> c06d89f4: e24b5054 sub r5, fp, #84 ; 0x54
> c06d89fc: e885000f stm r5, {r0, r1, r2, r3}
> c06d8a04: e897000f ldm r7, {r0, r1, r2, r3}
> c06d8a10: e88e000f stm lr, {r0, r1, r2, r3}
>
> This is from:
>
> struct flowi6 fl6 = {
> .flowi6_iif = l3mdev_fib_oif(skb->dev),
> .daddr = iph->daddr,
> .saddr = iph->saddr,
> .flowlabel = ip6_flowinfo(iph),
> .flowi6_mark = skb->mark,
> .flowi6_proto = iph->nexthdr,
> };
>
> specifically, I suspect, the saddr and daddr initialisations.
>
> There's not much to get away from this - the FEC on iMX requires a
> 16-byte alignment for DMA addresses, which violates the network
> stack's requirement for the ethernet packet to be received with a
> two byte offset. So the IP header (and IPv6 headers) will always
> be mis-aligned in memory, which leads to a huge number of alignment
> faults.
>
> There's not much getting away from this - the problem is not in the
> networking stack, but the FEC hardware/network driver. See:
>
> struct fec_enet_private *fep = netdev_priv(ndev);
> int off;
>
> off = ((unsigned long)skb->data) & fep->rx_align;
> if (off)
> skb_reserve(skb, fep->rx_align + 1 - off);
>
> bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev, skb->data, FEC_ENET_RX_FRSIZE - fep->rx_align, DMA_FROM_DEVICE));
>
> in fec_enet_new_rxbdp().
>
So the question is: should we just live with this and acknowledge a
performance penalty of bad alignment or do something about it?
I'm not sure the cost (or the details) of Eric's proposed fix of allocating
and copying the header to another skb.
The original report was of bad network performance, but I haven't
been able to see an impact doing some simple tests using wget
and SSH.
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB263894265429130B91E7880C8DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Friday, September 23, 2016 10:58 AM
> > > Really, though, the firmware call thing is an incredibly niche use-case.
> > > Beyond development, the only real benefit of starting an AArch32 kernel
> > > in Hyp is that you can run AArch32 KVM guests, which you can do equally
> > > well (if not better) under an AArch64 kernel.
> >
> > This was my question earlier in the thread, apparently Alison has
> > another use case in mind, but I don't yet know what that is. If
> > that use case is important enough, we could do it this way.
> >
> > The only use case I can think of at the moment is boot testing
> > on kernelci.org, which could be used to check whether all the drivers
> > work in 32-bit environments.
>
> The reason we want aarch32 kernel support is for specific customers that
> have requirements for legacy 32-bit kernel drivers that function on ARMv7
> but for some reason are very problematic to port to a 64-bit kernel. So,
> the way to ease the 64-bit transition is allow them to run an aarch32 kernel
> and their driver on an ARMv8 SoC. I don't think we specifically care
> whether the kernel starts at EL2 or EL1.
Thanks for the explanation. Unfortunately I don't think that helps
get this approach upstream, in particular I wouldn't want to add
a platform specific hack just to help a third party not have to fix
their out-of-tree drivers to be 64-bit clean.
If your customer already has a chunk of downstream patches large
enough to be problematic to rebuild for 64-bit, they should be able
to also pick up these two patches, but of course what we really
want is to get drivers upstream and fixed (presumably this would
be an even larger task than just fixing them, so I don't set my
hopes too high here).
I'm still not opposed to making *all* 64-bit platforms available
to 32-bit kernels for testing purposes though, and that would solve
the customer problem too, as would the approach of encapsulating
the kernel in hypervisor stub that implements the PSCI calls
and using MACH_VIRT with the respective layerscape drivers enabled.
Arnd
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Andrew Lunn @ 2016-09-23 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0fe7a310-2d2f-4fca-d698-85d66122d91c@nelint.com>
> Since the hardware requires longword alignment for its' DMA transfers,
> aligning the IP header will require a memcpy, right?
The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
two padding bits on transmit. ENETx_RACC has the same.
What about your hardware?
Andrew
^ permalink raw reply
* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Mark Rutland @ 2016-09-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473960166-30155-2-git-send-email-okaya@codeaurora.org>
On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> index fd5618b..47bfb5a 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
> the channel nodes appear on their own, not under a management node.
>
> Required properties:
> -- compatible: must contain "qcom,hidma-1.0"
> +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
> +for MSI capable HW.
> - reg: Addresses for the transfer and event channel
> - interrupts: Should contain the event interrupt
> - desc-count: Number of asynchronous requests this channel can handle
> - iommus: required a iommu node
>
> +Optional properties for MSI:
> +- msi-parent: pointer to the MSI controller object with the DeviceID in use.
The format of msi-cells depends on the particular msi-controller, so no
need to mention DeviceID here.
Please refer to
Documentation/devicetree/bindings/interrupt-controller/msi.txt
> +Example:
> + msi_parent: <&msi0 0x80024>
This doesn't match (s/_/-/).
> +msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
> +is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
> +instance 1.
I don't think you need any of this text, so long as you refer to the
generic MSI binding document, as above.
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Rob Herring @ 2016-09-23 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-3-git-send-email-ayaka@soulik.info>
On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> supported by the simple panel driver.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> new file mode 100644
> index 0000000..dd22685
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> @@ -0,0 +1,7 @@
> +Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "chunghwa,claa070wp03xg"
What about VCC, VLED, LED_EN (PWM), LVBIT, LVFMT, DITHER signals?
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
^ permalink raw reply
* [PATCH v8 2/2] ARM: dts: add TOPEET itop elite based board
From: Rob Herring @ 2016-09-23 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474300103-26659-3-git-send-email-ayaka@soulik.info>
On Mon, Sep 19, 2016 at 11:48:23PM +0800, Randy Li wrote:
> The TOPEET itop exynos 4412 have three versions base board. The
> Elite version is the cheap one without too much peripheral devices
> on it.
>
> Currently supported are serial console, wired networking(USB),
> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
> enabled.
>
> The FIMC is not used for camera currently, I enabled it just for a
> colorspace convertor.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 +++++++++++++++++++++
> 3 files changed, 244 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control
From: Rob Herring @ 2016-09-23 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919142347.11342-2-bhuvanchandra.dv@toradex.com>
On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote:
> Update #pwm-cells to 3 in order to support PWM signal polarity control.
>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> ---
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
> arch/arm/boot/dts/imx7s.dtsi | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
The driver will still work with old DTs, right? If so,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox