Hi, Stefano
On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com>
>>
>> First implementation of the cpufreq dr
Hi Stefano
On Tue, Dec 5, 2017 at 12:18 AM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
> On Sat, 2 Dec 2017, Oleksandr Tyshchenko wrote:
>> On Sat, Dec 2, 2017 at 3:06 AM, Stefano Stabellini
>> <sstabell...@kernel.org> wrote:
>> > On Thu, 9 Nov 2017, Ol
Hi Stefano
On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
> On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
>> Hi, Stefano
>>
>> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
>> <sstabell...@kernel.org> wrote:
>&g
On Tue, Dec 5, 2017 at 7:08 PM, Volodymyr Babchuk
<volodymyr_babc...@epam.com> wrote:
> Hi Julien,
Hi Julien, Volodymyr.
>
> On 05.12.17 16:58, Julien Grall wrote:
>>
>> Hi Oleksandr,
>>
>> On 09/11/17 17:10, Oleksandr Tyshchenko wrote:
>>>
>>
e chunk of memory is being
>>> handed to it.)
>>
>> As I understand, the current patch was tested on x86 with PV dom0
>> (thanks for doing that),
>
> This sounds as if you believe I would have tested anything. I
> certainly didn't (or at least I don't recall), and never meant to.
>
>> but wasn't
>> tested with PVH dom0 since the latter wasn't ready. And there is some
>> activity for bringing PVH dom0
>> which the current patch may affect in a negative way (complicate, brake,
>> etc).
>>
>> What pending patch(es) or a part of already existing code on x86
>> should I pay special attention to?
>
> The question is not so much pending patches, but making sure your
> changes don't adversely affect what's already in the tree.
Sure.
> Beyond that I'll defer to Roger.
>
>> Sorry for the maybe naive question, but what should be done from my
>> side for this patch to be accepted,
>> except addressing comments regarding the patch itself?
>
> You will want (need) to assess the impact of your changes on
> code paths you can't possibly test.
Sure.
I would like to clarify: I haven't tested this patch on x86. Only on ARM.
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
to be called from the non-hypercall context.
>> Or I missed something?
>
> Without looking at the details of this, please again use common
> sense. If there are good reasons for the two functions to not
> follow the same model, please simply state so
On Thu, Dec 7, 2017 at 12:49 AM, Julien Grall <julien.gr...@linaro.org> wrote:
> Hi,
Hi Julien, Jan
>
>
> On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote:
>>
>> On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich <jbeul...@suse.com> wrote:
>>>>>
t; handed to it.)
As I understand, the current patch was tested on x86 with PV dom0
(thanks for doing that), but wasn't
tested with PVH dom0 since the latter wasn't ready. And there is some
activity for bringing PVH dom0
which the current patch may affect in a negative way (complicate, brake, etc).
What pending patch(es) or a part of already existing code on x86
should I pay special attention to?
I haven't worked with "non-shared IOMMU support on ARM" patch series
for last 3-4 months, so I could lose the context.
Sorry for the maybe naive question, but what should be done from my
side for this patch to be accepted,
except addressing comments regarding the patch itself?
Sure, I will CC Roger on future versions of this patch.
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
e_probe() too, since
all these function have arguments which contain XEN_GUEST_HANDLE. I am
wondering is it worth
doing such rework taking into the account that set_cx_pminfo() is not
going to be called from the non-hypercall context.
Or I missed something?
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ithout having to
> dig out old discussions (which would be even more difficult for
> future archaeologists running into this change in a few years time).
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
- Stefano
>
>
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
>>
>> Hi, all.
>>
>> The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM.
>> Motivation of hype
Hi Julien, Stefano
On Tue, Dec 5, 2017 at 11:41 PM, Julien Grall <julien.gr...@linaro.org> wrote:
>
>
> On 05/12/2017 21:20, Stefano Stabellini wrote:
>>
>> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>>>
>>> From: Oleksandr Tyshchenko <oleksand
Hi, Julien.
On Tue, Dec 5, 2017 at 1:26 PM, Julien Grall <julien.gr...@linaro.org> wrote:
>
>
> On 09/11/17 17:10, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
>
>
> Please explain the rationale behind addin
Hi Stefano
On Sat, Dec 2, 2017 at 3:21 AM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com>
>>
>> ACPI-specific parts are moved under
Hi, Stefano
On Tue, Dec 5, 2017 at 1:24 AM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
>>
>> This is a port from Linux.
>
> When you p
ed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Andrew Cooper <andrew.coop...@citrix.com>
>> CC: Stefano Stabellini
index; /* any */
unsigned intfrequency; /* kHz - doesn't need to be in ascending
* order */
Both existing on x86 CPUFreq drivers just need to mark P0 frequency as
a turbo-frequency if turbo mode "is supported".
>
>
wever during patch discussion we decided to move this function to arch/x86.
>> It is called from arch/x86/platform_hypercall.c and pulls a bunch of
>> #define-s from pdc_intel.h
>
> Not sure - the function may be used by x86 only right now, but is what it
> does really x86-speci
Hi, Roger
On Thu, Jan 18, 2018 at 2:09 PM, Roger Pau Monné <roger@citrix.com> wrote:
> Sorry for the delay in the reply.
No problem.
>
> On Tue, Jul 25, 2017 at 08:26:49PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshche...@epam
, including MMU configuration
I think that saving/restoring IOMMU registers/context should be
implemented as well.
In other words, each involved platform device driver in Xen on ARM
(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
implemented.
--
Regards,
Oleksandr Tyshchenko
2679.html
>>
>> Presumably that driver would be needed in Xen.
>>
>> Are there any gotchas I'm missing? Is GPU passthrough on ARM something
>> that is "theoretically doable" or something that has been done already and
>> shown to be performant?
>>
>> Thanks again,
>> Martin
>
>
> --
> Julien Grall
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi, Martin
On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko
<olekst...@gmail.com> wrote:
> On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall <julien.gr...@linaro.org> wrote:
>> Hi,
>>
>> I am CCing Oleksandr. He knows better than me this platform.
>
> Hi
Hi
On Tue, Jan 30, 2018 at 2:22 AM, Martin Kelly <mke...@xevo.com> wrote:
> On 01/29/2018 08:31 AM, Oleksandr Tyshchenko wrote:
>>
>> Hi
>>
>> On Sat, Jan 27, 2018 at 2:41 AM, Martin Kelly <mke...@xevo.com> wrote:
>>>
>>> On 01/26/201
Hi
On Sat, Jan 27, 2018 at 2:41 AM, Martin Kelly <mke...@xevo.com> wrote:
> On 01/26/2018 10:13 AM, Oleksandr Tyshchenko wrote:
>>
>> Hi, Martin
>>
>> On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko
>> <olekst...@gmail.com> wrote:
>>
Hi
On Wed, Feb 14, 2018 at 4:47 PM, Oleksandr Tyshchenko
<olekst...@gmail.com> wrote:
> Hi, Julien.
>
> On Wed, Feb 14, 2018 at 4:17 PM, Julien Grall <julien.gr...@arm.com> wrote:
>> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
>> will
ata.midr.bits,
> + boot_cpu_data.midr.bits);
> +stop_cpu();
> +}
> +
> mmu_init_secondary_cpu();
>
> gic_init_secondary_cpu();
> --
> 2.11.0
>
>
> _______
> Xen-devel mailing list
&
On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>
>> Hi, Julien
>
>
> Hi Oleksandr,
Hi Julien
>
>
>>
>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
>>>
>>&g
On Tue, Aug 7, 2018 at 4:43 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Extend existing driver to be able to handle SCIFA interface as well.
>> SCIF and
On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall wrote:
> Hi,
Hi, Julien
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Add support for Renesas "Stout" development board based on
>> R-Car H2 SoC which h
On Tue, Aug 7, 2018 at 6:22 PM, Julien Grall wrote:
>
>
> On 07/08/18 15:28, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall wrote:
>>>
>>> Hi,
Hi, Julien
>>
>>
>> Hi, Julien
>>
>>>
>>&
Hi, Julien
On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
> Hi,
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Renesas "Stout" development board (with different expansion boards)
>> is als
On Fri, Aug 10, 2018 at 3:50 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien.
>
> On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
>>
>> On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall
>> wrote:
>>>
>>> On 08/09/2018 07:18 PM, Oleksandr Tyshche
On Thu, Aug 9, 2018 at 7:18 PM, Oleksandr Tyshchenko
wrote:
> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
>> Hi Oleksandr,
> Hi Julien.
Hi.
>
>>
>>
>> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>>
>>> On Tue, Aug 7, 2018 at
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien.
>
>
> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
>>>
>>> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
&g
Hi Julien.
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
>
>
> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>
>> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
>>>
>>> Somehow I thought the platform was 64-bit and found a SOC
On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall wrote:
> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>
>> Hi Julien.
>
>
> Hi Oleksandr,
Hi Julien
>
>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
>>>
>>>
>>
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/drivers/char/scif-uart.c| 4
xen/include/asm-arm/scif-uart.h | 11 ---
2 files changed, 15 deletions(-)
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on
Renesas Stout board [1] which uses SCIFA compatible UART as a console interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
Use compatible string to recognize what interface is present
on a target board.
Signed-off
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) differ only
in registers offsets.
From: Oleksandr Tyshchenko
Renesas "Stout" development board (with different expansion boards)
is also based on R-Car Gen2 SoC. So extend compat array with
board's compatible strings.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm
On Wed, Aug 22, 2018 at 6:48 PM, Julien Grall wrote:
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> Hi, all.
>
>
> Hi,
Hi, Julien
>
> Can you CC relevant people on the cover letter? It would save me time to dig
> into my e-mail :).
Sure.
>
&g
On Mon, Apr 16, 2018 at 2:56 PM, Juergen Gross <jgr...@suse.com> wrote:
> On 16/04/18 13:54, Jan Beulich wrote:
>>>>> On 16.04.18 at 13:52, <jbeul...@suse.com> wrote:
>>>>>> On 16.04.18 at 13:29, <olekst...@gmail.com> wrote:
>>
From: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
The "end" address must be rounded down before shifting,
otherwise we will insert wrong page range to a heap if address isn't
page aligned.
It seems that a copy-paste mistake took place in the
ain at most once */
> +if (libxl__xs_read(gc, xt, dom_role_path)) {
> +SSHM_ERROR(domid, sshm->id,
> + "domain tried to map the same ID twice.");
> +rc = ERROR_FAIL;
> +goto o
trncmp(role, "slave", 5))
> +libxl__sshm_del_slave(gc, xt, domid, sshm_ents[i],
> isretry);
> +
> +libxl__sshm_decref(gc, xt, SSHM_PATH(sshm_ents[i]));
> +}
> +}
> +
> +rc = libxl__xs_transaction_commit(gc, );
> +if (!rc) break;
> +if (rc < 0) goto out;
> +isretry = true;
> +}
> +
> +rc = 0;
> +out:
> +libxl__xs_transaction_abort(gc, );
> +return rc;
> +}
> +
> /* libxl__sshm_do_map -- map pages into slave's physmap
> *
> * This functions maps
> --
> 1.9.1
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
gin", "size" and "offset" properties.
Wouldn't be better to operate with page numbers rather than addresses
like it is done for "iomem"?
I see that in many functions (libxl_sshm.c) these addresses are being
transformed into page numbers the first.
Moreover if the Xen shared memory feature can deal with 4K page
aligned addresses only, why we provide
possibility for user to set any addresses and then check them for
alignment rules?
The only one place where we need addresses is the device tree code
where we insert memory regions (here we could transform page numbers
into addresses on the fly).
Or I missed something?
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
reak;
> }
> -#if 0
> +#ifdef CONFIG_SBSA_VUART_CONSOLE
> default:
> {
> struct domain *d = rcu_lock_domain_by_any_id(console_rx - 1);
> diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
> index 42d7a24..5eb6d25 100644
>
On Mon, Oct 29, 2018 at 10:03 PM Stefano Stabellini
wrote:
>
> On Wed, 24 Oct 2018, Oleksandr Tyshchenko wrote:
> > Hi, Stefano
> >
> > On Tue, Oct 23, 2018 at 5:04 AM Stefano Stabellini
> > wrote:
> > >
> > > Make vpl011 being able
Hi, Julien.
On Wed, Oct 24, 2018 at 5:25 PM Julien Grall wrote:
>
>
>
> On 10/24/18 3:15 PM, Oleksandr Tyshchenko wrote:
> > Hi, Stefano
> >
> > On Sat, Oct 20, 2018 at 12:07 AM Stefano Stabellini
> > wrote:
> >>
> >> Hi Wei,
> >>
From: Oleksandr Tyshchenko
Hi, all.
This is small patch series for ARM32 which needed to be able to bring
secondary CPUs up not only during the initial boot, but at runtime also.
For example, during CPU hotplug.
Actually these are follow-up patches to the following series [1], which covers
From: Oleksandr Tyshchenko
This is a follow-up patch to
commit 01a7e8ccef6e7d5718a251ad587567afbe723330
xen/arm: Remove __initdata and __init to enable CPU hotplug
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/arm32/smpboot.c | 2 +-
xen/arch/arm/platform.c | 2 +-
2 files changed
From: Oleksandr Tyshchenko
To be able to use it for the hot pluged CPUs as well.
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/xen.lds.S | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 245a0e0..003301a
On Tue, Dec 4, 2018 at 7:13 PM Julien Grall wrote:
> Hi,
>
Hi, Julien
>
> Title: xen/arm: link: ...
>
ok
>
> On 12/4/18 11:42 AM, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > To be able to use it for the hot pluged CPUs as w
From: Oleksandr Tyshchenko
To be able to use it for the hot-plugged CPUs as well.
The reason why we link proc_info_list in ".rodata" section is that
it context should never be modified.
This patch also renames ".init.proc.info" section to ".proc.info"
as "
On Fri, Dec 7, 2018 at 12:05 PM Julien Grall wrote:
> Hi Oleksandr,
>
Hi Julien
>
> On 07/12/2018 09:45, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > To be able to use it for the hot-plugged CPUs as well.
>
> You need to explain
From: Oleksandr Tyshchenko
This is a follow-up patch to
commit 01a7e8ccef6e7d5718a251ad587567afbe723330
xen/arm: Remove __initdata and __init to enable CPU hotplug
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
xen/arch/arm/arm32/smpboot.c | 2 +-
xen/arch/arm/platform.c
From: Oleksandr Tyshchenko
To be able to use it for the hot-plugged CPUs as well.
Signed-off-by: Oleksandr Tyshchenko
---
Changes in v2:
- Fix typoes
- Rename ".init.proc.info" to ".data.proc.info"
---
xen/arch/arm/arm32/proc-v7.S | 6 +++---
xe
From: Oleksandr Tyshchenko
Hi, all.
This is small patch series for ARM32 which needed to be able to bring
secondary CPUs up not only during the initial boot, but at runtime also.
For example, during CPU hotplug.
Actually these are follow-up patches to the following series [1], which covers
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
docs
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c40000,A
Signed-off-by: Oleksandr Tyshchen
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatible string
This patch makes possible to use exist
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "port_params" array to keep interface specific things.
The "data&q
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_PRINTK_VERSION" config option to choose which
interfa
ср, 20 февр. 2019 г., 22:14 Julien Grall :
> Hi Amit,
Hi, Julien, Amit.
Sorry for formatting, writing from my mobile.
If I am not mistaken, the diff between BSP's and mainline device trees is
in reserved memory area. BSP device tree (1) contains reserved memory
regions, but the mainline one
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
The "data" field in struct dt_device_match is used for recognizing
what interface
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) differ only
in registers offsets.
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Oleksandr Tyshchenko
---
docs/misc/arm/early-printk.txt
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Please note, this helper is ported from Linux v4.6.
Signed-off-by: Oleksandr Tyshchenko
---
Changes RFC -> V1:
- Add Linux version which is used as the b
From: Oleksandr Tyshchenko
Hello, all.
The purpose of this small series is to add minimal required support for Xen to
be able
to handle device-tree nodes with "interrupts-extended" property [1].
The "interrupts-extended" property is a special form for use when a nod
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents.
According to the:
Linux/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
But, there are cases when "inte
From: Oleksandr Tyshchenko
Hello, all.
The purpose of this small series is to add minimal required support for Xen to
be able to
handle device-tree nodes with "interrupts-extended" property [1].
The reason:
Xen expects to see "interrupts" property when pars
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
---
xen/common/device_tree.c | 7 +++
xen/include/xen/device_tree.h | 19 +++
2 files changed, 26 insertions
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family,
which is mand
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_PRINTK_VERSION" config option to choose which
interfa
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c40000,A
Signed-off-by: Oleksandr Tyshchen
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main difference between SCIF and SCIFA interfaces
from "scif-uart"
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatible string
This patch makes possible to use exist
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
Gen3 SoCs
From: Oleksandr Tyshchenko
The purpose of this patch is to add IPMMU-VMSA support to Xen on ARM.
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main difference between SCIF and SCIFA interfaces
from "scif-uart"
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
docs
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_PRINTK_VERSION" config option to choose which
interfa
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatible string
This patch makes possible to use exist
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c40000,A
Signed-off-by: Oleksandr Tyshchen
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Next patch in this series will make use of it.
Original patch was initially posted by Sameer Goel:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg00858.html
This could be considered as another attempt to add it:
https://www.mail-archive.com/kexec
From: Oleksandr Tyshchenko
The purpose of this patch series is to add IPMMU-VMSA support to Xen on ARM.
Besides new IOMMU driver, this series contains "iommu_fwspec" support
and new API iommu_add_dt_device() for adding DT device to IOMMU.
The IPMMU-VMSA is VMSA-compatible I/O Memory
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
Gen3 SoCs
From: Oleksandr Tyshchenko
This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_fwspec" support.
New function parses the DT binding, prepares "dev->iommu_fwspec"
with correct informat
From: Oleksandr Tyshchenko
Introduce a separate file to keep various helpers which could be used
by more than one IOMMU driver in order not to duplicate code.
The first condidates to be moved to the new file are SMMU driver's
"map_page/unmap_page" callbacks. There callbacks neither c
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.
In order not to pull Linux's error code (-EPROBE_DEFER) to Xen
we have chosen -EAGAIN to be used for indicating
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now) and ACPI (in future).
For that reason we can borrow the idea used in Linux these days
called "iommu_fwspec&quo
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The maximum supported by the IOMMU
Stage-2 input size must be greater or equal to the P2M IPA size.
So, first initialize the IOMMU and gather the requirements
From: Oleksandr Tyshchenko
According to the generic IOMMU DT bindings [1] the context of
required properties for IOMMU device/master node (#iommu-cells, iommus)
depends on many factors and is really driver depended thing.
We need some way to provide the driver with DT IOMMU specifier which
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.
In order not to pull Linux's error code (-EPROBE_DEFER) to Xen
we have chosen -EAGAIN to be used for indicating
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
Gen3 SoCs
1 - 100 of 686 matches
Mail list logo
