Hi Dave,
This hasn't shown up in one of your branches, yet. Do you want me to
change something or was this patch simply lost somewhere?
Thanks, Daniel
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too lat
Hi Dave,
This hasn't shown up in one of your branches, yet. Do you want me to
change something or was this patch simply lost somewhere?
Thanks, Daniel
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too lat
On Wed, Oct 06, 2010 at 08:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> > On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
> > > +{
> > > + struct apertur
On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
> > +{
> > + struct apertures_struct *ap;
> > + bool primary = false;
> > +
> > + ap = alloc_a
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too late, the firmware fb
> might be accessing the chip simultaneously to us re-initializing
> various parts of it, which might frighten babies or cause all sort
From: Benjamin Herrenschmidt
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Cc: stable at kernel.org
Signed-
On Wed, Oct 06, 2010 at 08:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> > On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
> > > +{
> > > + struct apertur
On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
> > +{
> > + struct apertures_struct *ap;
> > + bool primary = false;
> > +
> > + ap = alloc_a
On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> From: Benjamin Herrenschmidt
>
> Without this, we attempt the handover too late, the firmware fb
> might be accessing the chip simultaneously to us re-initializing
> various parts of it, which might frighten babies or cause all sort
From: Benjamin Herrenschmidt
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Cc: sta...@kernel.org
Signed-off
On Mon, 2010-08-16 at 09:00 +0200, Rafa? Mi?ecki wrote:
> 2010/8/10 Benjamin Herrenschmidt :
> > +#ifdef CONFIG_X86
> > + primary = dev->pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> > +#endif
>
> It won't compile for CONFIG_X86, no "dev".
Ah right, I've done more fixe
2010/8/10 Benjamin Herrenschmidt :
> +#ifdef CONFIG_X86
> + ? ? ? primary = dev->pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> +#endif
It won't compile for CONFIG_X86, no "dev".
--
Rafa?
On Mon, 2010-08-16 at 09:00 +0200, Rafał Miłecki wrote:
> 2010/8/10 Benjamin Herrenschmidt :
> > +#ifdef CONFIG_X86
> > + primary = dev->pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> > +#endif
>
> It won't compile for CONFIG_X86, no "dev".
Ah right, I've done more fixe
2010/8/10 Benjamin Herrenschmidt :
> +#ifdef CONFIG_X86
> + primary = dev->pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> +#endif
It won't compile for CONFIG_X86, no "dev".
--
Rafał
___
dri-devel mailing list
dri-devel@lists
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/rad
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/rad
16 matches
Mail list logo
