On 10/18/19 7:35 PM, Robin Murphy wrote:
> On 18/10/2019 17:44, Marek Vasut wrote:
>> On 10/18/19 5:44 PM, Robin Murphy wrote:
>>> On 18/10/2019 15:26, Marek Vasut wrote:
>>>> On 10/18/19 2:53 PM, Robin Murphy wrote:
>>>>> On 18/10/2019 13:22, M
On 10/18/19 5:44 PM, Robin Murphy wrote:
> On 18/10/2019 15:26, Marek Vasut wrote:
>> On 10/18/19 2:53 PM, Robin Murphy wrote:
>>> On 18/10/2019 13:22, Marek Vasut wrote:
>>>> On 10/18/19 11:53 AM, Lorenzo Pieralisi wrote:
>>>>> On Thu, Oct 17
On 10/18/19 2:53 PM, Robin Murphy wrote:
> On 18/10/2019 13:22, Marek Vasut wrote:
>> On 10/18/19 11:53 AM, Lorenzo Pieralisi wrote:
>>> On Thu, Oct 17, 2019 at 05:01:26PM +0200, Marek Vasut wrote:
>>>
>>> [...]
>>>
>>>>> Again, j
On 10/18/19 11:53 AM, Lorenzo Pieralisi wrote:
> On Thu, Oct 17, 2019 at 05:01:26PM +0200, Marek Vasut wrote:
>
> [...]
>
>>> Again, just handling the first N dma-ranges entries and ignoring the
>>> rest is not 'configure the controller correctly'.
>
rectly to
>>> the system PA space.
>>
>> And in that 1% of cases, we are OK with failure which could have been
>> easily prevented if the controller was programmed correctly ? That does
>> not look like a good thing.
>
> You don't need dma-ranges if you want to handle holes in DRAM. Use
> memblock to get this information. Then it will work if you boot using
> UEFI too.
Do you have any further details about this ?
> dma-ranges at the PCI bridge should be restrictions in the PCI bridge,
> not ones somewhere else in the system.
--
Best regards,
Marek Vasut
On 10/17/19 3:06 PM, Robin Murphy wrote:
> On 17/10/2019 11:55, Marek Vasut wrote:
>> On 10/17/19 9:06 AM, Geert Uytterhoeven wrote:
>>
>> [...]
>>
>>>>>>> I suppose if your intent is to use inbound windows as a poor man's
>>>>&g
n/memory
> and dma-ranges, there is no problem?
Unless of course the remote device initiates a transfer. And if the
controller is programmed such that accesses to the missing DRAM in the
holes are not filtered out by the controller, then the controller will
gladly let the transaction through. Do we really want to let this happen ?
[...]
--
Best regards,
Marek Vasut
cause undefined behavior. Surely we do not want that ?
> You are setting up random inbound windows. The bootloader can't assume
> what order the OS parses dma-ranges, and the OS can't assume what
> order the bootloader writes the entries.
But the OS can assume the ranges are correct and cover only valid
memory, right ? That is, memory into which the PCI controller can safely
access.
--
Best regards,
Marek Vasut
u would list them
> out. But I think that's wrong and difficult to maintain. You'd also
> need to deal with reserved-memory regions too.
What's the problem with that? The bootloader has all that information
and can patch the DT correctly. In fact, in my specific case, I have
platform which can be populated with differently sized DRAM, so the
holes are also dynamically calculated ; there is no one DT then, the
bootloader is responsible to generate the dma-ranges accordingly.
--
Best regards,
Marek Vasut
On 10/16/19 8:12 PM, Rob Herring wrote:
> On Wed, Oct 16, 2019 at 11:18 AM Lorenzo Pieralisi
> wrote:
>>
>> [+RobH, Robin]
>>
>> On Wed, Oct 16, 2019 at 05:29:50PM +0200, Marek Vasut wrote:
>>
>> [...]
>>
>>>>> The firmware provides
On 10/16/19 5:26 PM, Lorenzo Pieralisi wrote:
> On Wed, Oct 16, 2019 at 05:10:02PM +0200, Marek Vasut wrote:
>> On 10/16/19 5:00 PM, Lorenzo Pieralisi wrote:
>>> On Fri, Aug 09, 2019 at 07:57:40PM +0200, Marek Vasut wrote:
>>>> From: Marek Vasut
>>>>
On 10/16/19 5:00 PM, Lorenzo Pieralisi wrote:
> On Fri, Aug 09, 2019 at 07:57:40PM +0200, Marek Vasut wrote:
>> From: Marek Vasut
>>
>> In case the "dma-ranges" DT property contains either too many ranges
>> or the range start address is unaligned in such a
On 8/9/19 7:57 PM, Marek Vasut wrote:
> Since the $idx variable value is stored across multiple calls to
> rcar_pcie_inbound_ranges() function, and the $idx value is used to
> index registers which are written, subsequent calls might cause
> the $idx value to be high enough to trigger
ry, and if we happen to allocate a buffer
> that's not addressable, DMA to the buffer fails". It'd be nice to
> know what the failure looks like (SERR# asserted, panic, reboot, etc).
[...]
While it's good that someone finally looked at these patches, these were
since superseded by the following series:
https://patchwork.ozlabs.org/cover/1168166/
--
Best regards,
Marek Vasut
On 9/30/19 5:08 PM, Rob Herring wrote:
> On Mon, Sep 30, 2019 at 7:45 AM Marek Vasut wrote:
>>
>> On 9/24/19 12:33 AM, Rob Herring wrote:
>>> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
>>>>
>>>> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>
On 9/24/19 12:33 AM, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
>>
>> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>>
>>> From: Marek Vasut
>>>
>>> Add dma-ranges property into /soc node to describe the DMA capabilities
&g
On 9/24/19 12:33 AM, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
>>
>> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>>
>>> From: Marek Vasut
>>>
>>> Add dma-ranges property into /soc node to describe the DMA capab
On 9/14/19 6:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sat, Sep 14, 2019 at 6:06 PM Marek Vasut wrote:
>> On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
>>> On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
>>>> Add dma-ranges property into /soc node
hough, so I wonder if it's the PCIe translation patches which need to
be updated then ?
[1]
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm64/boot/dts/renesas/r8a7795.dtsi#L2653
--
Best regards,
Marek Vasut
bled on powerpc.
>
> You dropped Grant's name on this. Wouldn't matter too much as we can
> run 'git blame', but now we have another level to trace back thru.
I think that's what Frank suggested, since he reworded this message before.
>> +*/
>> +
>> if (IS_ENABLED(CONFIG_PPC)) {
>> /* To save cycles, we cache the result for global "Mac"
>> setting */
>> - static int quirk_state = -1;
>> + static int quirk_state_initialized;
>
> This can be bool too.
Fine
[...]
--
Best regards,
Marek Vasut
On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA ranges, which
On 9/13/19 5:14 PM, Rob Herring wrote:
> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>
>> From: Marek Vasut
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA ranges, which
On 9/9/19 11:05 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, Sep 9, 2019 at 10:42 AM Marek Vasut wrote:
>> On 9/9/19 10:19 AM, Geert Uytterhoeven wrote:
>>> On Sat, Sep 7, 2019 at 6:16 PM wrote:
>>>> From: Marek Vasut
>>>>
>>>&g
On 9/9/19 10:19 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sat, Sep 7, 2019 at 6:16 PM wrote:
>> From: Marek Vasut
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA r
On 8/10/19 9:47 PM, Frank Rowand wrote:
> On 8/10/19 6:39 AM, Marek Vasut wrote:
>> On 8/10/19 12:34 AM, Rob Herring wrote:
>>> On Fri, Aug 9, 2019 at 11:33 AM wrote:
>>>>
>>>> From: Marek Vasut
>>>>
>>>> The of_empty_ranges_qui
From: Marek Vasut
Add dma-ranges property into /soc node to describe the DMA capabilities
of the bus. This is currently needed to translate PCI DMA ranges, which
are limited to 32bit addresses.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Wolfram Sang
Cc: devicet...@vger.kernel.org
From: Marek Vasut
The of_empty_ranges_quirk() returns a mix of boolean and signed integer
types, which cannot work well. Replace that with boolean only and fix
usage logic in of_translate_one() -- the check should trigger when the
ranges are NULL and the quirk is applicable on the hardware
On 8/16/19 3:38 PM, Simon Horman wrote:
> On Fri, Aug 16, 2019 at 03:28:04PM +0200, Marek Vasut wrote:
>> On 8/16/19 3:23 PM, Simon Horman wrote:
>>> On Fri, Aug 09, 2019 at 07:57:40PM +0200, marek.va...@gmail.com wrote:
>>>> From: Marek Vasut
>>>>
On 8/16/19 3:23 PM, Simon Horman wrote:
> On Fri, Aug 09, 2019 at 07:57:40PM +0200, marek.va...@gmail.com wrote:
>> From: Marek Vasut
>>
>> In case the "dma-ranges" DT property contains either too many ranges
>> or the range start address is unaligned in su
On 8/16/19 12:52 PM, Lorenzo Pieralisi wrote:
> On Fri, Aug 09, 2019 at 07:57:39PM +0200, marek.va...@gmail.com wrote:
>> From: Marek Vasut
>>
>> Since the $idx variable value is stored across multiple calls to
>> rcar_pcie_inbound_ranges() function, and the $id
On 8/10/19 12:34 AM, Rob Herring wrote:
> On Fri, Aug 9, 2019 at 11:33 AM wrote:
>>
>> From: Marek Vasut
>>
>> The of_empty_ranges_quirk() returns a mix of boolean and signed integer
>> types, which cannot work well.
>
> It never returns a negative. T
rns resources,
>> and is left to the caller, how it wants to use them.
>>
>> Signed-off-by: Oza Pawandeep
>> Signed-off-by: Marek Vasut
>> Cc: Arnd Bergmann
>> Cc: Geert Uytterhoeven
>> Cc: Lorenzo Pieralisi
>> Cc: Robin Murphy
>> Cc: Simo
From: Marek Vasut
Due to hardware constraints, the size of each inbound range entry
populated into the controller cannot be larger than the alignment
of the entry's start address. Currently, the alignment for each
"dma-ranges" inbound range is calculated only once for eac
From: Marek Vasut
In case the "dma-ranges" DT property contains either too many ranges
or the range start address is unaligned in such a way that populating
the range into the controller requires multiple entries, a situation
may occur where all ranges cannot be loaded into the
From: Marek Vasut
Since the $idx variable value is stored across multiple calls to
rcar_pcie_inbound_ranges() function, and the $idx value is used to
index registers which are written, subsequent calls might cause
the $idx value to be high enough to trigger writes into nonexistent
registers
From: Marek Vasut
In case the "dma-ranges" DT property contains either too many ranges
or the range start address is unaligned in such a way that populating
the range into the controller requires multiple entries, a situation
may occur where all ranges cannot be loaded into the
From: Marek Vasut
Due to hardware constraints, the size of each inbound range entry
populated into the controller cannot be larger than the alignment
of the entry's start address. Currently, the alignment for each
"dma-ranges" inbound range is calculated only once for eac
From: Marek Vasut
Since the $idx variable value is stored across multiple calls to
rcar_pcie_inbound_ranges() function, and the $idx value is used to
index registers which are written, subsequent calls might cause
the $idx value to be high enough to trigger writes into nonexistent
registers
;;
we should get dev->coherent_dma_mask=0x7f.
based on which IOVA allocation space will honour PCI host
bridge limitations.
the implementation hooks bus specific callbacks for getting
dma-ranges.
Signed-off-by: Oza Pawandeep
Signed-off-by: Marek Vasut
Cc: Arnd Bergmann
Cc: Geert U
ARMv8 where 64bit IOVA
could be allocated.
It handles multiple inbound windows, and returns resources,
and is left to the caller, how it wants to use them.
Signed-off-by: Oza Pawandeep
Signed-off-by: Marek Vasut
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Lorenzo Pieralisi
Cc: Robin Murphy
Cc
From: Marek Vasut
The of_empty_ranges_quirk() returns a mix of boolean and signed integer
types, which cannot work well. Replace that with boolean only and fix
usage logic in of_translate_one() -- the check should trigger when the
ranges are NULL and the quirk is applicable on the hardware
From: Marek Vasut
Due to hardware constraints, the size of each inbound range entry
populated into the controller cannot be larger than the alignment
of the entry's start address. Currently, the alignment for each
"dma-ranges" inbound range is calculated only once for eac
From: Marek Vasut
In case the "dma-ranges" DT property contains either too many ranges
or the range start address is unaligned in such a way that populating
the range into the controller requires multiple entries, a situation
may occur where all ranges cannot be loaded into the
042] softirqs last enabled at (40174): []
>>> _local_bh_enable+0x20/0x40
>>>
>>> [ 12.264434] softirqs last disabled at (40175): []
>>> irq_exit+0x144/0x150
>>>
>>> [ 12.273278] ---[ end trace cfa1ae1709343a35 ]---
>>>
>>> [ 12.278880] e1000e :01:00.0 eth0: Reset adapter unexpectedly
>>>
>>>
>>>
>>> Q1) Has any one observed this issue?
>>>
>>>
>>>
>>> It works without any issues for the following cases with upstream kernel.
>>>
>>>
>>>
>>> Case1: Use the below commit[1] from renesas-bsp
>>>
>>>
>>>
>>> [1].
>>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/
>>> commit/?id=561e15db1ed8c5cc2fc340796e2d1c643111d27a
>>>
>>>
>>>
>>> Case 2: Disable the bank#1 from device tree
>>>
>>>
>>>
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
>>>
>>> +#if 0
>>>
>>> memory@6 {
>>>
>>> device_type = "memory";
>>>
>>> reg = <0x6 0x 0x0 0x8000>;
>>>
>>> };
>>>
>>> +#endif
>>>
>>> +
>>>
>>> };
>>>
>>>
>>>
>>> Q2) Could please share your thought on this issue?
>>
>> I presume it's this [1]. Robin seems to be working on a fix, see [2],
>> although I
>> suspect he won't deliver it, so I'll have to get back to this topic myself.
>
> Thanks for the update. Please let me know when the patch is ready. I am
> happy to test and will provide feedback.
Will do. I am kinda waiting for Robin, but maybe I just shouldn't :)
--
Best regards,
Marek Vasut
device_type = "memory";
>
> reg = <0x6 0x 0x0 0x8000>;
>
> };
>
> +#endif
>
> +
>
> };
>
>
>
> Q2) Could please share your thought on this issue?
I presume it's this [1]. Robin seems to be working on a fix, see [2],
although I suspect he won't deliver it, so I'll have to get back to this
topic myself.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=561e15db1ed8c5cc2fc340796e2d1c643111d27a
[2] https://patchwork.kernel.org/patch/10842111/
--
Best regards,
Marek Vasut
From: Marek Vasut
On ARM64 R-Car Gen3 R8A7795 system with Intel NVMe SSD inserted into the
PCIe slot, with CONFIG_PROVE_LOCKING=y enabled in the kernel config, the
following lockdep warning can be triggered:
$ lspci
01:00.0 Class 0108: 8086:f1a5 # This is the NVMe SSD
00:00.0 Class 0604
On 5/3/19 8:13 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Fri, May 3, 2019 at 5:18 PM Marek Vasut wrote:
>> On 5/3/19 2:36 PM, Geert Uytterhoeven wrote:
>>>> &rwdt {
>>>> @@ -309,6 +314,8 @@
>>>> };
>>>>
>>>
From: Marek Vasut
The PMIC IRQ line pin multiplexing configuration is missing from the DTs.
Since the line is configured correctly by default, the system works fine.
However, add the IRQ line pin multiplexing configuration for completeness.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc
On 5/8/19 3:51 PM, Eugeniu Rosca wrote:
> Hi Marek,
>
> On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
> [..]
>>>>> 1.c Use OpenOCD
>>>>> + Presumably same advantages as using a Lauterbach
>>>>> + Based on Kieran's https:
On 5/8/19 11:32 AM, Eugeniu Rosca wrote:
> On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
> [..]
>>>>> 1.d. Use CPLD Configurator
>>>>> + H3_M3_StarterKit_Configurator.exe is a Windows tool shipped by
>>>>> Renesas, hen
On 5/8/19 4:48 AM, masonccy...@mxic.com.tw wrote:
> Hi Jones,
>
>> "Lee Jones"
>> 2019/05/07 下午 08:58
>>
>> To
>>
>> "Marek Vasut" ,
>>
>> cc
>>
>> "Rob Herring" , "Mason Yang"
>> ,
On 5/7/19 5:53 PM, Eugeniu Rosca wrote:
> Hi Marek,
Hi,
> Thanks for the swift reply and for the useful references/links.
>
> On Tue, May 07, 2019 at 03:23:12PM +0200, Marek Vasut wrote:
>> On 5/7/19 12:41 PM, Eugeniu Rosca wrote:
>>> Dear Marek, dear Kieran,
>&
D
> pins, to conveniently switch between QSPI/Hyperflash/SCIF
> boot mode from a GUI
> + Most of the advantages pointed out above
> - ULCB-only solution (i.e. does not apply to Salvator-X)
> - Requires a Windows host
Where can I obtain this and are there sources / documentation available?
--
Best regards,
Marek Vasut
ingle device connected to irq2, I think it makes
> sense to move the pinctrl properties to the pmic node below.
It makes blanche somehow inconsistent with the other boards, but if you
insist ... ?
> With that fixed:
> Reviewed-by: Geert Uytterhoeven
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Best regards,
Marek Vasut
On 3/19/19 11:26 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Mar 4, 2019 at 9:00 PM wrote:
>> From: Marek Vasut
>>
>> Add IIC3 node to R8A7792 SoC device tree and a DA9063 PMIC node
>> to V2H Blanche board device tree.
>>
>> Signed
From: Marek Vasut
The PMIC IRQ line pin multiplexing configuration is missing from the DTs.
Since the line is configured correctly by default, the system works fine.
However, add the IRQ line pin multiplexing configuration for completeness.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc
On 4/26/19 1:07 AM, Rob Herring wrote:
> On Wed, Apr 24, 2019 at 4:54 PM Marek Vasut wrote:
>>
>> On 4/24/19 11:23 PM, Rob Herring wrote:
>>> On Wed, Apr 24, 2019 at 03:55:36PM +0800, Mason Yang wrote:
>>>> Document the bindings used by the Renesas R-Car Gen3
clocks = <&cpg CPG_MOD 917>;
>> +clock-names = "rpc";
>> +power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> + resets = <&cpg 917>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +flash@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +spi-max-frequency = <4000>;
>> +spi-tx-bus-width = <1>;
>> +spi-rx-bus-width = <1>;
>> +};
>> +};
>> --
>> 1.9.1
>>
--
Best regards,
Marek Vasut
On 3/28/19 4:25 AM, Marek Vasut wrote:
> On 3/19/19 12:25 AM, Marek Vasut wrote:
>> On 3/18/19 2:14 PM, Robin Murphy wrote:
>>> On 17/03/2019 23:36, Marek Vasut wrote:
>>>> On 3/17/19 11:29 AM, Geert Uytterhoeven wrote:
>>>>> Hi Marek,
>>>
On 4/4/19 11:28 AM, Lorenzo Pieralisi wrote:
> On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.va...@gmail.com wrote:
>> From: Marek Vasut
>>
>> The MSI message address in the RC address space can be 64 bit. The
>> R-Car PCIe RC supports such a 64bit MSI message a
From: Marek Vasut
Replace various variable types with u32 or unsigned int type for
variables holding register values, since the registers are 32bit.
Note that rcar_pcie_msi_irq() still uses various variable types
because both find_first_bit() and __fls() require various variable
types as an
From: Marek Vasut
Replace unsigned long with u32 and unsigned int in register accessor
functions, since they access 32bit registers.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux
From: Marek Vasut
The MSI message address in the RC address space can be 64 bit. The
R-Car PCIe RC supports such a 64bit MSI message address as well.
The code currently uses virt_to_phys(__get_free_pages()) to obtain
a reserved page for the MSI message address, and the return value
of which can
From: Marek Vasut
Replace macros using constants with BIT()s instead, no functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
From: Marek Vasut
Replace (8 * n) with (BITS_PER_BYTE * n) to make bit shift operations
consistent. No functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux
From: Marek Vasut
Drop useless casts from debug messages, they are no longer needed
due to the data type cleanup.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
On 3/29/19 8:32 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Mar 25, 2019 at 12:41 PM wrote:
>> From: Marek Vasut
>>
>> The MSI message address in the RC address space can be 64 bit. The
>> R-Car PCIe RC supports such a 64bit MSI message address as
From: Marek Vasut
Add nodes enabling internal PCI controllers to which the internal USB
controllers are connected, add USB PHY node and pinmux nodes.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: linux-renesas-soc@vger.kernel.org
To: linux-arm-ker
On 3/28/19 5:31 PM, Geert Uytterhoeven wrote:
> Hi Lorenzo,
>
> On Thu, Mar 28, 2019 at 5:28 PM Lorenzo Pieralisi
> wrote:
>> On Thu, Mar 28, 2019 at 09:02:00AM +0100, Geert Uytterhoeven wrote:
>>> On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut wrote:
>>>>
people couldn't even run suspend/resume
>> cycles on their systems:
>> 1. Early releases of the affected boards came with firmware revisions with
>> non-functional PSCI system suspend,
>> 2. Preparing the PMIC for suspend required ugly assistance from i2cset
>> in userspace, until the Linux driver learned to take care of that itself
>> in v4.18/v4.19.
>>
>> I guess the fix can survive postponing to v5.2, though...
>
> Ok, I'll merge it to -next for v5.2, thanks.
ACK.
--
Best regards,
Marek Vasut
On 3/19/19 12:25 AM, Marek Vasut wrote:
> On 3/18/19 2:14 PM, Robin Murphy wrote:
>> On 17/03/2019 23:36, Marek Vasut wrote:
>>> On 3/17/19 11:29 AM, Geert Uytterhoeven wrote:
>>>> Hi Marek,
>>>
>>> Hi,
>>>
>>>> On Sun, Mar 17
On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> On Wed, Mar 27, 2019 at 12:30 PM Simon Horman wrote:
>> On Mon, Mar 25, 2019 at 12:41:01PM +0100, marek.va...@gmail.com wrote:
>>> From: Marek Vasut
>>> The MSI message address in the RC address space can be 64 bit. The
On 3/26/19 2:04 PM, Lorenzo Pieralisi wrote:
> On Mon, Mar 25, 2019 at 12:40:56PM +0100, marek.va...@gmail.com wrote:
>> From: Marek Vasut
>>
>> Replace macros using constants with BIT()s instead, no functional change.
>>
>> Signed-off-by: Marek Vasut
>&
e bus. Such accesses
>> can happen early in the PCI resume process, in the resume_noirq, thus
>> the link must be reestablished in the resume_noirq callback of the
>> driver.
>>
>> Signed-off-by: Kazufumi Ikeda
>> Signed-off-by: Gaku Inami
>> Signed-off-by
driver resume_noirq() callback.
Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
Signed-off-by: Kazufumi Ikeda
Signed-off-by: Gaku Inami
Signed-off-by: Marek Vasut
[lorenzo.pieral...@arm.com: reformatted commit log]
Signed-off-by: Lorenzo Pieralisi
Reviewed-by: Si
From: Marek Vasut
The MSI message address in the RC address space can be 64 bit. The
R-Car PCIe RC supports such a 64bit MSI message address as well.
The code currently uses virt_to_phys(__get_free_pages()) to obtain
a reserved page for the MSI message address, and the return value
of which can
From: Marek Vasut
Replace macros using constants with BIT()s instead, no functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
From: Marek Vasut
Replace unsigned long with u32 and unsigned int in register accessor
functions, since they access 32bit registers.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux
From: Marek Vasut
Replace (8 * n) with (BITS_PER_BYTE * n) to make bit shift operations
consistent. No functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux
From: Marek Vasut
Replace various variable types with u32 or unsigned int type for
variables holding register values, since the registers are 32bit.
Note that rcar_pcie_msi_irq() still uses various variable types
because both find_first_bit() and __fls() require various variable
types as an
From: Marek Vasut
Drop useless casts from debug messages, they are no longer needed
due to the data type cleanup.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
On 3/25/19 9:06 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Thu, Mar 21, 2019 at 4:20 AM Marek Vasut wrote:
>> On 3/18/19 9:19 AM, Geert Uytterhoeven wrote:
>>> On Mon, Mar 18, 2019 at 12:39 AM Marek Vasut wrote:
>>>> On 3/17/19 11:22 AM, Geert Uytt
On 3/25/19 9:07 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Sat, Mar 23, 2019 at 2:54 AM wrote:
>> From: Marek Vasut
>>
>> Replace unsigned long with u32 in register accessor functions,
>> since they access 32bit registers.
>>
>> Signed-off-by:
On 3/25/19 9:26 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Sat, Mar 23, 2019 at 2:54 AM wrote:
>> From: Marek Vasut
>>
>> Replace (8 * n) with (n << 3) to make bit shift operations consistent.
>> No functional change.
>>
>> Sig
From: Marek Vasut
Replace various variable types with u32 or unsigned int type for
variables holding register values, since the registers are 32bit.
Note that rcar_pcie_msi_irq() still uses various variable types
because both find_first_bit() and __fls() require various variable
types as an
From: Marek Vasut
Replace (8 * n) with (n << 3) to make bit shift operations consistent.
No functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
Re
From: Marek Vasut
Replace unsigned long with u32 in register accessor functions,
since they access 32bit registers.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
From: Marek Vasut
Replace macros using constants with BIT()s instead, no functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
about converting 'addr' and 'data' here? Other than those, I didn't
> find other candidates in this driver.
Sure, fixed.
--
Best regards,
Marek Vasut
clear, the discussion is now rather about whether we
should allocate the reserved page with GFP_DMA32 and keep it in 32bit
address range or not.
I'll reword the commit message though.
--
Best regards,
Marek Vasut
From: Marek Vasut
Drop useless casts from debug messages, they are no longer needed
due to the data type cleanup.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
From: Marek Vasut
The MSI message address in the RC address space can be 64 bit. The
R-Car PCIe RC supports such a 64bit MSI message address as well.
The code currently uses virt_to_phys(__get_free_pages()) to obtain
a reserved page for the MSI message address, and the return value
of which can
On 3/22/19 1:42 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Fri, Mar 22, 2019 at 1:33 PM Marek Vasut wrote:
>> On 3/22/19 1:29 PM, Geert Uytterhoeven wrote:
>>> On Fri, Mar 22, 2019 at 1:18 PM Lorenzo Pieralisi
>>> wrote:
>>>> On Fri, Mar 22, 2
ix (most likely fixing initial S2R support, please
> help me chase the commit ID), should we consider it for stable kernels ?
>
> Without it I understand S2R is actually broken on platforms with this
> host bridge.
I don't think this ever worked, so it's hard to find a Fixes: commit for
this.
--
Best regards,
Marek Vasut
On 3/22/19 1:29 PM, Geert Uytterhoeven wrote:
> Hi Lorenzo, Marek,
Hi,
> On Fri, Mar 22, 2019 at 1:18 PM Lorenzo Pieralisi
> wrote:
>> On Fri, Mar 22, 2019 at 01:09:13PM +0100, Marek Vasut wrote:
>>> On 3/22/19 12:31 PM, Lorenzo Pieralisi wrote:
>>>> On S
From: Marek Vasut
Replace unsigned long with u32 in register accessor functions,
since they access 32bit registers.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
From: Marek Vasut
Drop useless casts from debug messages, they are no longer needed
due to the data type cleanup.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
From: Marek Vasut
The MSI address can be 64bit. Switch the data type used to hold the
result of virt_to_phys() to phys_addr_t to reflect its properties
correctly and program the top 32bits of PA into PCIEMSIAUR.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon
From: Marek Vasut
Replace macros using constants with BIT()s instead, no functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
---
V2: Bundle this patch
From: Marek Vasut
Replace (8 * n) with (n << 3) to make bit shift operations consistent.
No functional change.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To: linux-...@vger.kernel.org
1 - 100 of 716 matches
Mail list logo
