On Wed, 10 Dec 2014, Ville Syrjälä wrote:
> On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
>> irq_mask should include all IRQ bits that we want to mask, but atm we
>> set it incorrectly to the inverse of this. If the mask is used
>> subsequently to enable/disable some IRQ bits, we may
On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
On Thu, 2014-11-20 at 15:11 +0100, Daniel Vetter wrote:
> On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> > irq_mask should include all IRQ bits that we want to mask, but atm we
> > set it incorrectly to the inverse of this. If the mask is used
> > subsequently to enable/disable some I
On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't
irq_mask should include all IRQ bits that we want to mask, but atm we
set it incorrectly to the inverse of this. If the mask is used
subsequently to enable/disable some IRQ bits, we may unintentionally
unmask unrelated IRQs. I can't see any way that this can lead to a real
problem in the current -n
