On 03/01/2021 10:00, Samuel Holland wrote:
> On boards where the only peripheral connected to PL0/PL1 is an X-Powers
> PMIC, configure the connection to use the RSB bus rather than the I2C
> bus. Compared to the I2C controller that shares the pins, the RSB
> controller allows a higher bus
On 15/12/2020 03:25, Samuel Holland wrote:
> On 12/14/20 8:57 AM, Maxime Ripard wrote:
>> Hi Samuel,
>>
>> On Sun, Dec 13, 2020 at 05:55:03PM -0600, Samuel Holland wrote:
>>> While no information about the H6 RSB controller is included in the
>>> datasheet or manual, the vendor BSP and power
On 13/12/2020 18:24, Icenowy Zheng wrote:
> 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
>> Newer SoCs (A100, H616) need to clear a different bit in our
>> "unknown"
>> PMU PHY register.
>
> It looks like that the unknown PHY register is PHYCTL register for each
> individual PHY, and the bit
On 13/12/2020 17:47, Icenowy Zheng wrote:
Hi Icenowy,
> 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
>> Hi,
>>
>> this is the quite expanded second version of the support series for
>> the
>> Allwinner H616 SoC.
>> Besides many fixes for the bugs discovered by the diligent reviewers
>> (many
On 10/12/2020 13:31, Icenowy Zheng wrote:
> 在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
>> While the clocks are fairly similar to the H6, many differ in tiny
>> details, so a separate clock driver seems indicated.
>>
>> Derived from the H6 clock driver, and adjusted according to the
>> manual.
On 09/12/2020 22:20, Jernej Škrabec wrote:
> Dne sreda, 09. december 2020 ob 22:35:51 CET je André Przywara napisal(a):
>> On 09/12/2020 14:33, Clément Péron wrote:
>>
>> Hi,
>>
>>> I try to review this, and compare against the vendor Kernel>
>>>
On 09/12/2020 14:33, Clément Péron wrote:
Hi,
> I try to review this, and compare against the vendor Kernel>
> On Wed, 2 Dec 2020 at 14:54, Andre Przywara wrote:
>>
>> While the clocks are fairly similar to the H6, many differ in tiny
>> details, so a separate clock driver seems indicated.
>>
On 03/12/2020 16:20, Chen-Yu Tsai wrote:
Hi,
> On Thu, Dec 3, 2020 at 11:45 PM André Przywara wrote:
>>
>> On 03/12/2020 15:02, Chen-Yu Tsai wrote:
>>> On Thu, Dec 3, 2020 at 6:54 PM André Przywara
>>> wrote:
>>>>
>>>> On 03/12/2020 03
On 07/12/2020 01:07, André Przywara wrote:
> On 06/12/2020 16:01, Icenowy Zheng wrote:
>
> Hi,
>
>>>>>> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 16)), /*
>>> PI_EINT16 */
>>>>>> +};
>>>>>> +static cons
On 10/11/2020 06:40, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> Add support for a100's usb phy, which with 2 PHYs.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/phy/allwinner/phy-sun4i-usb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git
On 06/12/2020 16:01, Icenowy Zheng wrote:
Hi,
> 于 2020年12月6日 GMT+08:00 下午10:52:17, "André Przywara"
> 写到:
>> On 06/12/2020 12:42, Jernej Škrabec wrote:
>>
>> Hi,
>>
>>> Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron
>>
On 06/12/2020 12:42, Jernej Škrabec wrote:
Hi,
> Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron napisal(a):
>> Hi Andre,
>>
>> On Wed, 2 Dec 2020 at 14:54, Andre Przywara wrote:
>>> Port A is used for an internal connection to some analogue circuitry
>>> which looks like an
On 03/12/2020 15:02, Chen-Yu Tsai wrote:
> On Thu, Dec 3, 2020 at 6:54 PM André Przywara wrote:
>>
>> On 03/12/2020 03:16, Samuel Holland wrote:
>>
>> Hi,
>>
>>> On 12/2/20 7:54 AM, Andre Przywara wrote:
>>> ...
>>
On 02/12/2020 14:31, Icenowy Zheng wrote:
Hi,
> 于 2020年12月2日 GMT+08:00 下午9:54:05, Andre Przywara 写到:
>> The clocks itself are identical to the H6 R-CCU, it's just that the
>> H616
>> has not all of them implemented (or connected).
>
> For selective clocks, try to follow the practice of V3(s)
On 02/12/2020 18:20, Jernej Škrabec wrote:
Hi,
> Dne sreda, 02. december 2020 ob 14:54:05 CET je Andre Przywara napisal(a):
>> The clocks itself are identical to the H6 R-CCU, it's just that the H616
>> has not all of them implemented (or connected).
>>
>> Signed-off-by: Andre Przywara
>> ---
On 03/12/2020 03:16, Samuel Holland wrote:
Hi,
> On 12/2/20 7:54 AM, Andre Przywara wrote:
> ...
>> +soc {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0x0 0x0 0x0 0x4000>;
>> +
>> +
On 02/12/2020 16:33, Jernej Škrabec wrote:
Hi,
> Dne sreda, 02. december 2020 ob 14:54:08 CET je Andre Przywara napisal(a):
>> This (relatively) new SoC is similar to the H6, but drops the (broken)
>> PCIe support and the USB 3.0 controller. It also gets the management
>> controller removed,
On 02/12/2020 21:03, Jernej Škrabec wrote:
> Dne sreda, 02. december 2020 ob 14:54:06 CET je Andre Przywara napisal(a):
>> While the clocks are fairly similar to the H6, many differ in tiny
>> details, so a separate clock driver seems indicated.
>>
>> Derived from the H6 clock driver, and adjusted
On 02/12/2020 15:57, Icenowy Zheng wrote:
> 在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
>> The OrangePi Zero 2 is a development board with the new H616 SoC.
>>
>> It features the usual connectors used on those small boards, and
>> comes
>> with the AXP305, which seems to be compatible with the
On 02/12/2020 16:03, Icenowy Zheng wrote:
> 在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
>> This (relatively) new SoC is similar to the H6, but drops the
>> (broken)
>> PCIe support and the USB 3.0 controller. It also gets the management
>> controller removed, which in turn removes *some*, but
On 28/11/2020 19:56, André Przywara wrote:
> On 10/11/2020 06:46, Frank Lee wrote:
Hi,
one more thing below ...
>> From: Yangtao Li
>>
>> This patch adds support for A100 MMC controller, which use word address
>> for internal dma.
>>
>> Signed-off-by:
On 10/11/2020 06:28, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> The dma of a100 is similar to h6, with some minor changes to
> support greater addressing capabilities.
So apparently those changes are backwards compatible, right?
Why do we need then a new struct now, when this is actually
On 10/11/2020 06:29, Frank Lee wrote:
> From: Yangtao Li
>
> The A100 SoC has a DMA controller that supports 8 DMA channels
> to and from various peripherals.
>
> Add a device node for it.
>
> Signed-off-by: Yangtao Li
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 12
On 10/11/2020 06:38, Frank Lee wrote:
> From: Yangtao Li
>
> Declare A100's watchdog in the device-tree.
>
> Signed-off-by: Yangtao Li
I don't have any manual nor hardware, but this node looks alright, when
compared to the H6 one.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
On 10/11/2020 06:31, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> Add the Performance Monitoring Unit (PMU) device tree node to the A100
> .dtsi, which tells DT users which interrupts are triggered by PMU overflow
> events on each core.
Have you tested that the interrupts actually work? For
On 11/11/2020 22:50, Rob Herring wrote:
Hi,
> On Tue, Nov 10, 2020 at 02:39:42PM +0800, Frank Lee wrote:
>> From: Yangtao Li
>>
>> Add a device tree binding for the A100's USB PHY.
Not your fault, Yangto, but why do we actually have a separate binding
document per SoC, when the differences
On 10/11/2020 06:48, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> The A100 has 3 MMC controllers, one of them being especially targeted to
> eMMC. Let's add nodes on dts.
>
> Signed-off-by: Yangtao Li
I don't have a datasheet nor a device for testing, but at least I could
check the pins
On 10/11/2020 06:46, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> This patch adds support for A100 MMC controller, which use word address
> for internal dma.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/mmc/host/sunxi-mmc.c | 28 +---
> 1 file changed, 25
On 10/11/2020 06:40, Frank Lee wrote:
Hi,
> From: Yangtao Li
>
> Add support for a100's usb phy, which with 2 PHYs.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/phy/allwinner/phy-sun4i-usb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git
On 19/11/2020 13:41, Ard Biesheuvel wrote:
Hi,
> On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote:
>>
>> The ARM architected TRNG firmware interface, described in ARM spec
>> DEN0098, defines an ARM SMCCC based interface to a true random number
>> generator, provided by firmware.
>> This can
On 13/11/2020 23:05, Ard Biesheuvel wrote:
> On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote:
>>
>> Hi,
>>
>> an update to v2 with some fixes and a few tweaks. Ard's patch [1] should
>> significantly reduce the frequency of arch_get_random_seed_long() calls,
>> not sure if that is enough the
On 05/11/2020 14:38, Mark Rutland wrote:
Hi,
> On Thu, Nov 05, 2020 at 02:29:49PM +, Mark Brown wrote:
>> On Thu, Nov 05, 2020 at 02:03:22PM +, Mark Rutland wrote:
>>> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
>>
It isn't obvious to me why we don't fall through to
On 11/11/2020 17:44, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 11, 2020 at 04:20:26PM +, Andr� Przywara escreveu:
>> On 11/11/2020 16:15, Arnaldo Carvalho de Melo wrote:
>>> Em Wed, Nov 11, 2020 at 01:10:51PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 11, 2020 at
On 11/11/2020 16:15, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 11, 2020 at 01:10:51PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Nov 11, 2020 at 03:11:27PM +0800, Leo Yan escreveu:
>>> This is patch set v8 for refactoring Arm SPE trace decoding and dumping.
>>>
>>> This version
On 11/11/2020 15:35, Arnaldo Carvalho de Melo wrote:
Hi Arnaldo,
thanks for taking a look!
> Em Wed, Nov 11, 2020 at 03:11:33PM +0800, Leo Yan escreveu:
>> When outputs strings to the decoding buffer with function snprintf(),
>> SPE decoder needs to detects if any error returns from snprintf()
On 11/11/2020 10:05, Ard Biesheuvel wrote:
Hi,
> On Wed, 11 Nov 2020 at 10:45, André Przywara wrote:
>>
>> On 11/11/2020 08:19, Ard Biesheuvel wrote:
>>
>> Hi,
>>
>>> (+ Eric)
>>>
>>> On Thu, 5 Nov 2020 at 16:29, Ard Biesh
On 11/11/2020 07:11, Leo Yan wrote:
Hi Arnaldo, Ingo, Peter, (whoever feels responsible for taking this)
> This is patch set v8 for refactoring Arm SPE trace decoding and dumping.
I have reviewed every patch of this in anger, and am now fine with this
series. Given the bugs fixed, the
On 11/11/2020 08:19, Ard Biesheuvel wrote:
Hi,
> (+ Eric)
>
> On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel wrote:
>>
>> When reseeding the CRNG periodically, arch_get_random_seed_long() is
>> called to obtain entropy from an architecture specific source if one
>> is implemented. In most cases,
On 06/11/2020 01:41, Leo Yan wrote:
> arm_spe_pkt_desc() returns the length of consumed the buffer for
> the success case; otherwise, it delivers the return value from
> arm_spe_pkt_snprintf(), and returns the last return value if there have
> multiple calling arm_spe_pkt_snprintf().
>
> Since
On 06/11/2020 01:41, Leo Yan wrote:
> When outputs strings to the decoding buffer with function snprintf(),
> SPE decoder needs to detects if any error returns from snprintf() and if
> so needs to directly bail out. If snprintf() returns success, it needs
> to update buffer pointer and reduce the
On 05/11/2020 17:15, kernel test robot wrote:
> Hi Andre,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.10-rc2 next-20201105]
> [cannot apply to arm64/for-next/core kvmarm/next arm-perf/for-next/perf]
> [If your patch
On 05/11/2020 14:03, Mark Rutland wrote:
> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
>> On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
>>
>>> static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
>>> {
>>> + struct arm_smccc_res res;
>>>
On 03/11/2020 06:40, Leo Yan wrote:
Hi Dave, Leo,
> On Mon, Nov 02, 2020 at 05:06:53PM +, Dave Martin wrote:
>> On Fri, Oct 30, 2020 at 02:57:09AM +, Leo Yan wrote:
>>> When outputs strings to the decoding buffer with function snprintf(),
>>> SPE decoder needs to detects if any error
On 30/10/2020 02:57, Leo Yan wrote:
> When outputs strings to the decoding buffer with function snprintf(),
> SPE decoder needs to detects if any error returns from snprintf() and if
> so needs to directly bail out. If snprintf() returns success, it needs
> to update buffer pointer and reduce the
On 29/10/2020 10:51, Leo Yan wrote:
> Hi Andre,
>
> On Thu, Oct 29, 2020 at 10:23:39AM +, Andr� Przywara wrote:
>
> [...]
>
>>> +static int arm_spe_pkt_snprintf(int *err, char **buf_p, size_t *blen,
>>> + const char *fmt, ...)
>>> +{
>>> + va_list ap;
>>> +
On 29/10/2020 07:19, Leo Yan wrote:
Hi,
> When outputs strings to the decoding buffer with function snprintf(),
> SPE decoder needs to detects if any error returns from snprintf() and if
> so needs to directly bail out. If snprintf() returns success, it needs
> to update buffer pointer and
On 27/10/2020 03:09, Leo Yan wrote:
> This patch is to refactor address packet handling, it defines macros for
> address packet's header and payload, these macros are used by decoder
> and the dump flow.
>
> Signed-off-by: Leo Yan
Thanks for the changes!
Reviewed-by: Andre Przywara
Cheers,
On 27/10/2020 03:08, Leo Yan wrote:
> This patch defines macro to extract "sz" field from header, and renames
> the function payloadlen() to arm_spe_payload_len().
>
> Signed-off-by: Leo Yan
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c |
On 27/10/2020 03:09, Leo Yan wrote:
> This patch defines macros for counter packet header, and uses macros to
> replace hard code values in functions arm_spe_get_counter() and
> arm_spe_pkt_desc().
>
> In the function arm_spe_get_counter(), adds a new line for more
> readable.
>
> Signed-off-by:
On 27/10/2020 03:09, Leo Yan wrote:
Hi,
> From: Wei Li
>
> This patch is to support Armv8.3 extension for SPE, it adds alignment
> field in the Events packet and it supports the Scalable Vector Extension
> (SVE) for Operation packet and Events packet with two additions:
>
> - The vector
On 27/10/2020 03:09, Leo Yan wrote:
> To establish a valid address from the address packet payload and finally
> the address value can be used for parsing data symbol in DSO, current
> code uses 0xff to replace the tag in the top byte of data virtual
> address.
>
> So far the code only fixups top
On 27/10/2020 03:09, Leo Yan wrote:
> Defines macros for operation packet header and formats (support sub
> classes for 'other', 'branch', 'load and store', etc). Uses these
> macros for operation packet decoding and dumping.
>
> Signed-off-by: Leo Yan
Looks good now, thanks!
Reviewed-by:
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> From: Wei Li
>
> This patch is to support Armv8.3 extension for SPE, it adds alignment
> field in the Events packet and it supports the Scalable Vector Extension
> (SVE) for Operation packet and Events packet with two additions:
>
> - The vector
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> Defines macros for operation packet header and formats (support sub
> classes for 'other', 'branch', 'load and store', etc). Uses these
> macros for operation packet decoding and dumping.
>
> Signed-off-by: Leo Yan
> ---
>
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> This patch moves out the event packet parsing from arm_spe_pkt_desc()
> to the new function arm_spe_pkt_desc_event().
>
> Signed-off-by: Leo Yan
diff -w says this is correct, so:
Reviewed-by: Andre Przywara
Thanks!
Andre
> ---
>
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> From: Andre Przywara
>
> When SPE records a physical address, it can additionally tag the event
> with information from the Memory Tagging architecture extension.
>
> Decode the two additional fields in the SPE event payload.
>
> [leoy: Refined patch
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> For the operation type packet payload with load/store class, it misses
> to support these sub classes:
>
> - A load/store targeting the general-purpose registers;
> - A load/store targeting unspecified registers;
> - The ARMv8.4 nested
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> Move the enums of event types to arm-spe-pkt-decoder.h, thus function
> arm_spe_pkt_desc() can them for bitmasks.
>
> Suggested-by: Andre Przywara
> Signed-off-by: Leo Yan
The move is fine, and I checked the bitmasks as well.
Reviewed-by: Andre
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> This patch defines macros for counter packet header, and uses macros to
> replace hard code values in functions arm_spe_get_counter() and
> arm_spe_pkt_desc().
>
> In the function arm_spe_get_counter(), adds a new line for more
> readable.
>
>
On 22/10/2020 15:58, Leo Yan wrote:
Hi Leo,
> This patch is to refactor address packet handling, it defines macros for
> address packet's header and payload, these macros are used by decoder
> and the dump flow.
>
> Signed-off-by: Leo Yan
> ---
> .../util/arm-spe-decoder/arm-spe-decoder.c
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> The operation type packet is complex and contains subclass; the parsing
> flow causes deep indentation; for more readable, this patch introduces
> a new function arm_spe_pkt_desc_op_type() which is used for operation
> type parsing.
>
> Signed-off-by:
On 22/10/2020 15:58, Leo Yan wrote:
> In the Armv8 ARM (ARM DDI 0487F.c), chapter "D10.2.6 Events packet", it
> describes the event bit is valid with specific payload requirement. For
> example, the Last Level cache access event, the bit is defined as:
>
> E[8], byte 1 bit [0], when SZ == 0b01
On 22/10/2020 15:58, Leo Yan wrote:
> This patch moves out the address parsing code from arm_spe_pkt_desc()
> and uses the new introduced function arm_spe_pkt_desc_addr() to process
> address packet.
>
> Signed-off-by: Leo Yan
Can confirm the move is correct.
Reviewed-by: Andre Przywara
On 22/10/2020 15:58, Leo Yan wrote:
> This patch moves out the counter packet parsing code from
> arm_spe_pkt_desc() to the new function arm_spe_pkt_desc_counter().
>
> Signed-off-by: Leo Yan
Confirmed by diff'ing '-' vs. '+' to not introduce an actual change.
Reviewed-by: Andre Przywara
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> The packet header parsing uses the hard coded values and it uses nested
> if-else statements.
>
> To improve the readability, this patch refactors the macros for packet
> header format so it removes the hard coded values. Furthermore, based
> on the
On 22/10/2020 15:57, Leo Yan wrote:
Hi Leo,
> This patch defines macro to extract "sz" field from header, and renames
> the function payloadlen() to arm_spe_payload_len().
>
> Signed-off-by: Leo Yan
> ---
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 18 +-
>
On 22/10/2020 15:58, Leo Yan wrote:
> In function arm_spe_get_events(), the event packet's 'index' is assigned
> as payload length, but the flow is not directive: it firstly gets the
> packet length from the return value of arm_spe_get_payload(), the value
> includes header length (1) and payload
On 21/10/2020 11:17, Leo Yan wrote:
Hi Leo,
> On Wed, Oct 21, 2020 at 10:26:07AM +0100, Andr� Przywara wrote:
>> On 21/10/2020 06:10, Leo Yan wrote:
>>
>> Hi,
>>
>>> On Tue, Oct 20, 2020 at 10:54:44PM +0100, Andr� Przywara wrote:
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
On 21/10/2020 06:10, Leo Yan wrote:
Hi,
> On Tue, Oct 20, 2020 at 10:54:44PM +0100, Andr� Przywara wrote:
>> On 29/09/2020 14:39, Leo Yan wrote:
>>
>> Hi,
>>
>>> From: Wei Li
>>>
>>> This patch is to support Armv8.3 extension for SPE, it adds alignment
>>> field in the Events packet and it
On 21/10/2020 05:54, Leo Yan wrote:
Hi Leo,
> On Tue, Oct 20, 2020 at 10:54:16PM +0100, Andr� Przywara wrote:
>> On 29/09/2020 14:39, Leo Yan wrote:
>>
>> Hi,
>>
>>> Use macros instead of the enum values for event types, this is more
>>> directive and without bit shifting when parse packet.
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
> For the operation type packet payload with load/store class, it misses
> to support these sub classes:
>
> - A load/store targeting the general-purpose registers;
> - A load/store targeting unspecified registers;
> - The ARMv8.4 nested
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
> From: Wei Li
>
> This patch is to support Armv8.3 extension for SPE, it adds alignment
> field in the Events packet and it supports the Scalable Vector Extension
> (SVE) for Operation packet and Events packet with two additions:
>
> - The vector
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
> Use macros instead of the enum values for event types, this is more
> directive and without bit shifting when parse packet.
>
> Signed-off-by: Leo Yan
> ---
> .../util/arm-spe-decoder/arm-spe-decoder.c| 16 +++---
>
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
> This patch defines macros for counter packet header, and uses macro to
> replace hard code values for packet parsing.
>
> Signed-off-by: Leo Yan
> ---
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 17 ++---
>
On 29/09/2020 14:39, Leo Yan wrote:
> Minor refactoring to use macro for index mask.
>
> Signed-off-by: Leo Yan
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 2 +-
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h | 3 +++
>
On 29/09/2020 14:39, Leo Yan wrote:
Hi Leo,
> This patch is to refactor address packet handling, it defines macros for
> address packet's header and payload, these macros are used by decoder
> and the dump flow.
So I was thinking about these next few patches a bit. I understand that
it's common
On 29/09/2020 14:39, Leo Yan wrote:
Hi Leo,
> The packet header parsing uses the hard coded values and it uses nested
> if-else statements.
>
> To improve the readability, this patch refactors the macros for packet
> header format so it removes the hard coded values. Furthermore, based
> on
On 29/09/2020 14:39, Leo Yan wrote:
Hi,
> When outputs strings to the decoding buffer with function snprintf(),
> SPE decoder needs to detects if any error returns from snprintf() and if
> so needs to directly bail out. If snprintf() returns success, it needs
> to update buffer pointer and
On 29/09/2020 14:39, Leo Yan wrote:
> When process address packet and counter packet, if the packet contains
processing
> extended header, it misses to account the extra one byte for header
> length calculation, thus returns the wrong packet length.
>
> To correct the packet length
On 29/09/2020 14:39, Leo Yan wrote:
> Fix a typo: s/iff/if.
>
> Signed-off-by: Leo Yan
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 29/09/2020 14:39, Leo Yan wrote:
Hi Leo,
> Defines macro for payload length calculation instead of static function.
What is the reason for that? I thought the kernel's direction is more
the other way: replacing macros with static functions ("Don't write CPP,
write C")? Ideally the compiler
On 29/09/2020 14:39, Leo Yan wrote:
> Include header linux/bitops.h, directly use its BIT() macro and remove
> the self defined macros.
>
> Signed-off-by: Leo Yan
Reviewed-by: Andre Przywara
Thanks,
Andre
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-decoder.c | 5 +
>
On 07/10/2020 15:16, James Morse wrote:
Hi,
> On 06/10/2020 21:18, Andre Przywara wrote:
>> The ARM architected TRNG firmware interface, described in ARM spec
>> DEN0098[1], defines an ARM SMCCC based interface to a true random number
>> generator, provided by firmware.
>> This can be discovered
On 28/09/2020 14:21, Dave Martin wrote:
Hi Dave,
> On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
>> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
>> that introduces very long vector operations (up to 2048 bits).
>
> (8192, in fact, though don't expect
On 27/09/2020 04:30, Leo Yan wrote:
Hi Leo,
> On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
>> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
>> that introduces very long vector operations (up to 2048 bits).
>> The SPE profiling feature can tag SVE
On 08/09/2020 18:28, Rob Herring wrote:
> On Fri, 28 Aug 2020 15:20:13 +0100, Andre Przywara wrote:
>> This converts the DT binding documentation for the ARM SP-804 timer IP
>> over to json-schema.
>> Most properties are just carried over, the clocks property requirement
>> (either one or three
On 04/09/2020 16:29, Florian Fainelli wrote:
Hi,
> On 9/4/2020 1:58 AM, Linus Walleij wrote:>> On Fri, Aug 28, 2020 at 9:34 PM
> Florian Fainelli
>> wrote:
>>> On 8/28/20 6:05 AM, Andre Przywara wrote:
>>
>>> What is the plan for merging this series? Should Rob pick up all changes
>>> or since
On 02/09/2020 00:04, Florian Fainelli wrote:
Hi Florian,
sorry, the mail got swamped in my inbox...
> On 8/28/2020 10:12 AM, Florian Fainelli wrote:
>> On 8/28/20 7:20 AM, Andre Przywara wrote:
>>> The DT binding for SP804 requires to have an "arm,primecell" compatible
>>> string.
>>> Add this
On 28/08/2020 22:32, Florian Fainelli wrote:
Hi,
Florian, thanks for queueing the Broadcom specific patches!
> On 8/28/20 2:28 PM, Rob Herring wrote:
>> On Fri, Aug 28, 2020 at 1:34 PM Florian Fainelli
>> wrote:
>>>
>>> On 8/28/20 6:05 AM, Andre Przywara wrote:
This is an attempt to
On 28/08/2020 15:54, Linus Walleij wrote:
Hi,
> On Fri, Aug 28, 2020 at 4:20 PM Andre Przywara wrote:
>
>> This is the second attempt at converting the SP804 timer binding to yaml.
>> Compared to v1, I forbid additional properties, and included the primecell
>> binding. Also the clock-names
On 28/08/2020 15:03, Linus Walleij wrote:
Hi,
> On Wed, Aug 26, 2020 at 8:38 PM Andre Przywara wrote:
>
>> The SP804 DT nodes for Realview, MPS2 and VExpress were not complying
>> with the binding: it requires either one or three clocks, but does not
>> allow exactly two clocks.
>>
>> Simply
On 26/08/2020 21:55, Florian Fainelli wrote:
> On 8/26/20 11:59 AM, Florian Fainelli wrote:
>> On 8/26/20 11:53 AM, André Przywara wrote:
>>> On 26/08/2020 19:42, Florian Fainelli wrote:
Hi Florian,
>>>
>>> Hi,
>>>
>>>> On 8/26/20 11:38
On 26/08/2020 19:42, Florian Fainelli wrote:
Hi,
> On 8/26/20 11:38 AM, Andre Przywara wrote:
>> The DT binding for SP804 requires to have an "arm,primecell" compatible
>> string.
>> Add this string so that the Linux primecell bus driver picks the device
>> up and activates the clock.
>>
>>
On 24/08/2020 13:49, Robert Richter wrote:
> I do not have hardware anymore, nor there is ongoing development. So
> handover maintenance to Andre who already maintains the last
> remainings of Calxeda.
>
> Cc: Andre Przywara
> Signed-off-by: Robert Richter
Acked-by: Andre Przywara
Thanks!
On 12/07/2020 19:45, Amit Tomer wrote:
Hi,
> On Sun, Jul 12, 2020 at 11:00 PM Manivannan Sadhasivam
> wrote:
>>
>> On Thu, Jul 02, 2020 at 08:22:56PM +0530, Amit Singh Tomar wrote:
>>> This commit adds uSD support for Cubieboard7 board based on Actions Semi
>>> S700 SoC. SD0 is connected to uSD
On 03/07/2020 06:38, kernelci.org bot wrote:
Hi Guillaume,
is this report legit? The situation didn't change from Monday, I just
repeated the test with mainline compared to my patch reverted.
What is the actual failure here? You pointed to:
<2>GIC CPU mask not found - kernel will fail to boot.
On 29/06/2020 10:54, Vinod Koul wrote:
Hi Vinod,
> On 24-06-20, 10:35, Andr� Przywara wrote:
>> On 24/06/2020 07:15, Vinod Koul wrote:
>>> On 09-06-20, 15:47, Amit Singh Tomar wrote:
>>>
@@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
*vchan,
On 24/06/2020 07:15, Vinod Koul wrote:
Hi,
> On 09-06-20, 15:47, Amit Singh Tomar wrote:
>
>> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
>> *vchan,
>>struct dma_slave_config *sconfig,
>>bool
On 18/05/2020 12:08, Stephen Rothwell wrote:
> Commit
>
> 17a37ff76e95 ("arm64: dts: juno: Use proper DT node name for USB")
>
> is missing a Signed-off-by from its author.
Oh, sorry for that and thanks for spotting this!
Sudeep, many thanks for the quick fix and update!
Cheers,
Andre
>
>
On 23/09/2019 07:36, Peng Fan wrote:
Hi Peng,
thanks for the update!
> From: Peng Fan
>
> V7:
> Typo fix
> #mbox-cells changed to 0
> Add a new header file arm-smccc-mbox.h
> Use ARM_SMCCC_IS_64
>
> Andre,
> The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id
>
1 - 100 of 244 matches
Mail list logo
