search for: deassertion

Attached is a patch for shared interrupt between dom0 and HVM domain for vtd. Most of problem is caused by that we should inject interrupt to both domains and the physical interrupt deassertion then may be delayed by the device assigned to the HVM. The patch adds a timer, and the time out value is sufficient large to tolerant the delaying used to wait for the physical interrupt deassertion. The patch works well with the situation that SATA disk shares interrupt with PCIe NIC. An...

...ly. - It is implemented by introducing a new hw_interrupt_type, which is exactly the same as the ioapic_level_type hw_interrupt_type with its end() callback replaced (see io_apic.c for more details). - State machine: Whenever an interrupt occur (both for an assertion or deassertion): 1. Ack & Mask the interrupt 2. Assert/Deassert virtual line of NativeDom (Interrupt action). 3. Change pin''s polarity 4. EOI & Unmask Signed-off-by: Guy Zana <guy@neocleus.com> _______________________________________________ Xen-de...

On Tue, Dec 23, 2014 at 06:39:55PM +0800, Vince Hsu wrote: > The flush operation of memory clients is needed for various IP blocks in > the Tegra SoCs to perform a clean reset. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drivers/memory/tegra/mc.c | 21 +++++++++++++++++++++ > include/soc/tegra/mc.h | 23 ++++++++++++++++++++++- > 2 files changed,

On Tue, Jan 06, 2015 at 03:18:22PM +0100, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Dec 23, 2014 at 06:39:55PM +0800, Vince Hsu wrote: > > The flush operation of memory clients is needed for various IP blocks in > > the Tegra SoCs to perform a clean reset. > > > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > > --- >

...ly accept > the GPU partition as valid parameter for now. So at least the interface > stays symmetric and can be easily extended if any future partitions have > similar characteristics as the GPU one. The register APBDEV_PMC_GPU_RG_CNTRL_0 is only for GPU and can be used for assertion and deassertion. The APBDEV_PMC_REMOVE_CLAMPING_CMD_0 is only used for deassertion. If we have any future partitions that can be asserted by SW like GPU, we can improve the interface then. > >>> Other comments inline. >>> >>> Regards, >>> Lucas >>> >>>&gt...

On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: >> * PGP Signed by an unknown key >> >> On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >>> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>>> The

The reset control API has two modes: exclusive access, where the driver expects to have full and immediate control over the state of the reset line, and shared (clock-like) access, where drivers only request reset deassertion while active, but don't care about the state of the reset line while inactive. Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or sh...

Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu: > On 12/24/2014 09:16 PM, Lucas Stach wrote: > > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >> The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >> to enable/disable the clamp. The original function > >> tegra_powergate_remove_clamping() is not sufficient for

Hi, I need a help with tracking down following issue: When trying to boot Xen on a system with Ivy Bridge stepping C0 CPU, it is stuck on CPU initialization. I''ve added some tracing to apic writes/reads and traced it so far to sending INIT IPI. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Setting warm reset code and vector. (XEN) apic_wrmsr (0x280,0x0)

The following 5 patches are re-submissions of the vt-d patch. This set of patches has been tested against cs# 15080 and is now much more mature and tested against more environments than the original patch. Specifically, we have successfully tested the patch with following environements: - 32/64-bit Linux HVM guest - 32-bit Windows XP/Vista (64-bit should work but did not test) -

On 04:12:54PM Jan 07, Peter De Schrijver wrote: > On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > > >>* PGP Signed by an unknown key > > >> > > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu

On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive. > > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the dri...

...Jul 2017 17:25:04 +0200, Philipp Zabel wrote: > > The reset control API has two modes: exclusive access, where the driver > > expects to have full and immediate control over the state of the reset > > line, and shared (clock-like) access, where drivers only request reset > > deassertion while active, but don't care about the state of the reset line > > while inactive. > > > > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > > reset lines") started to transition the reset control request API calls > > to explici...

On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > > On 12/24/2014 09:16 PM, Lucas Stach wrote: > > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > > >>The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >

Hello, On Wed, 19 Jul 2017 17:25:04 +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive. > > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the dri...

On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > >>* PGP Signed by an unknown key > >> > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>>On 12/24/2014 09:16 PM, Lucas Stach wrote: >

On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > On 12/24/2014 09:16 PM, Lucas Stach wrote: > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >>to enable/disable the clamp. The original function > >>tegra_powergate_remove_clamping() is not sufficient for the

On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > >>* PGP Signed by an unknown key > >> > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>>On 12/24/2014 09:16 PM, Lucas Stach wrote: >

I really need to have the ability to tie event channel port''s to interrupts for my gplpv drivers under Windows. Is anyone working on anything like this? Does MSI allow more than one interrupt per PCI device? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I tried to attach passrough io device to domU, the command (ended successfully in dom0), but when I entered the domU and typed the "lspci" command I didn''t see the new device, although the dom0 removed it from the "pci-list-assignable-devices". When I tried to detach it from the domU, the detach command returned with timeout error. What did I miss? perhaps I