search for: deassert

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....

...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...

...tch, having a boolean "enable" argument is suboptimal here. Now according to documentation the proper reset sequence for clients is something like this: 1) set the FLUSH_ENABLE bit for the client 2) poll the FLUSH_DONE bit for the client 3) assert reset to the client using the CAR 4) deassert reset to the client using the CAR 5) clear the FLUSH_ENABLE bit for the client This is really inconvenient because we can't flush the client using a single operation. So I think we'll need two functions here, something like: tegra_mc_flush_enable/disable(), or tegra_mc_flush_{,de}assert()...

...quot; argument is suboptimal here. Now according to > documentation the proper reset sequence for clients is something like > this: > > 1) set the FLUSH_ENABLE bit for the client > 2) poll the FLUSH_DONE bit for the client > 3) assert reset to the client using the CAR > 4) deassert reset to the client using the CAR > 5) clear the FLUSH_ENABLE bit for the client > Do we ever need to do this outside a powergating or railgating sequence? > This is really inconvenient because we can't flush the client using a > single operation. So I think we'll need two f...

...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 >>> >>>...

...domain need to be asserted and the memory clients need to > be flushed. All this needs to be done with module clocks enabled (resets are > synchronous). Then all module clocks need to be disabled and then the > partition can be powergated. After ungating, the module resets need to be > deasserted and the FLUSH bit cleared with clocks enabled. Yeah. I plan to have the information of all the clock client of the partitions and the memory clients be defined statically in c source, e.g. pmc-tegra124.c. All modules can declare which domain they belong to in DT. One domain can be really power g...

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...

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) -

...emory clients need to > > >be flushed. All this needs to be done with module clocks enabled (resets are > > >synchronous). Then all module clocks need to be disabled and then the > > >partition can be powergated. After ungating, the module resets need to be > > >deasserted and the FLUSH bit cleared with clocks enabled. > > Yeah. I plan to have the information of all the clock client of the > > partitions and > > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > > All modules can declare which domain they belong to...

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...

...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 expl...

...of all modules in a domain need to be asserted and the memory clients need to be flushed. All this needs to be done with module clocks enabled (resets are synchronous). Then all module clocks need to be disabled and then the partition can be powergated. After ungating, the module resets need to be deasserted and the FLUSH bit cleared with clocks enabled. Cheers, Peter.

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...

...e asserted and the memory clients need to > >be flushed. All this needs to be done with module clocks enabled (resets are > >synchronous). Then all module clocks need to be disabled and then the > >partition can be powergated. After ungating, the module resets need to be > >deasserted and the FLUSH bit cleared with clocks enabled. > Yeah. I plan to have the information of all the clock client of the > partitions and > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > All modules can declare which domain they belong to in DT. One domain ca...

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

...e asserted and the memory clients need to > >be flushed. All this needs to be done with module clocks enabled (resets are > >synchronous). Then all module clocks need to be disabled and then the > >partition can be powergated. After ungating, the module resets need to be > >deasserted and the FLUSH bit cleared with clocks enabled. > Yeah. I plan to have the information of all the clock client of the > partitions and > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > All modules can declare which domain they belong to in DT. One domain ca...

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