Having registered debugfs files globally causes
the files to not show up on the second, third
etc.. card in the system.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|8
drivers/gpu/drm/radeon/radeon_device.c | 26 ++--
Only check the previously checked relocs for
duplicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_
The following three patches are just minor bug fixes.
I've send them to the list previously, but this time they are based upon
drm-next instead of drm-fixes and I also fixed some spelling mistakes in the
commit messages.
Please commit. Thanks,
Christian.
___
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel Dänzer wrote:
> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> > On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >
> > > So I think the right thing to do is
> > > - Kill dev->last_vblank_wait (in a prep patch).
> >
> > Agreed. Also drm_vblan
On Thu, Oct 27, 2011 at 10:19:39PM -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >The only really hairy thing going on is racing modeset ioctls against
> >vblank waiters. But modeset is protected by the dev->mode_config.mutex
> >and hence already races against wait_vblank
On Fri, 28 Oct 2011, Daniel Vetter wrote:
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel Dänzer wrote:
On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
On Thu, 27 Oct 2011, Daniel Vetter wrote:
So I think the right thing to do is
- Kill dev->last_vblank_wait (in a prep patch).
Ag
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #49 from Siganderson 2011-10-28 05:39:21 PDT ---
(In reply to comment #48)
> > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
>
> Typo, it should be
>
>
> patch -p1 < name_of_the_patch.patch
> ^
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #50 from Siganderson 2011-10-28 05:42:37 PDT ---
I forgot to say that without touching anything in the window there are no
changes (60 fps... obviously 60 is the maximum when vsync is on).
--
Configure bugmail: https://bugs.freedesk
On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang wrote:
> Hi,
>
> Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> and after that my screen can't show normally.
> No sure if it's a known issue.
No, that is the first time I've seen that. It looks as if the fence was
not released,
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #51 from Ilija Hadzic 2011-10-28
06:25:40 PDT ---
(In reply to comment #49)
> (In reply to comment #48)
> > > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
> >
> > Typo, it should be
> >
> >
> > patch -p1 < nam
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #13 from Roland Scheidegger 2011-10-28
06:49:59 PDT ---
(In reply to comment #12)
> csm->gart_limit and csm->vram_limit are correct.
>
> With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
> In ETRacer, wh
2011/10/28 Christian König :
> Only check the previously checked relocs for
> duplicates. Also leaving the handle uninitialized
> isn't such a good idea.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
> 1 files changed, 3
On Fri, Oct 28, 2011 at 07:10:51AM -0500, Ilija Hadzic wrote:
> I'll keep it then and figure out the best mutex/spinlock to use. It
> can be anything that exists on one-per-CRTC basis (vblank waits on
> different CTCs are not contending). The critical section is from
> that switch in which vblwait-
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #14 from Michal 2011-10-28 09:44:56 PDT ---
Minimum GARTSize which don't return fallbacks is 16MB.
Now, the problem is somewhere at the kernel side.
samples| %|
--
1295082 93.6410 vmlinux
30154 2.1803 r2
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #15 from Michal 2011-10-28 10:13:15 PDT ---
FBTexPercent to 97
bash-4.1$ cat /var/log/Xorg.0.log|grep text
[ 8077.238] (II) RADEON(0): Will use 114688 kb for textures at offset
0x00c08000
etracer runs smoothly at 40 fps(with mesa 7.
Looks like this patch got missed. Dave can you add it and CC: stable?
Alex
On Wed, May 25, 2011 at 2:02 PM, Alex Deucher wrote:
> This should make eDP more reliable.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_dp.c | 11 +++
> include/drm/drm_dp_helper.h
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
drivers/char/agp/intel-gtt.c |4
1 files chang
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
Here's a shorter patch which just elides the body of th
Message: 5
Date: Fri, 28 Oct 2011 11:30:38 +0200
From: Daniel Vetter
Subject: Re: [PATCH 3/3] drm: do not sleep on vblank while holding a
mutex
To: Ilija Hadzic
Cc: dri-devel@lists.freedesktop.org
Message-ID: <20111028093038.GB2919@phenom.ffwll.local>
Content-Type: text/plain; charset=us
On Fri, 28 Oct 2011 10:56:29 -0700
Keith Packard wrote:
> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #17 from aux...@gmail.com 2011-10-28 11:26:57 PDT ---
I'm afraid the virtualbox modules have nothing to do with this.
A hopefully helpful observation:
When I first load the large image in firefox, zooming in and out several times
wo
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
> be careful with vblank_refcount. I think it probably should stay
> atomic. The drm_vblank_put() is often used in interrupt handlers of
> the kms drivers where you don't want to uneccessary wait on a lock,
> but be as quick as possible
On Oct 28, 2011, at 9:15 PM, Daniel Vetter wrote:
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
be careful with vblank_refcount. I think it probably should stay
atomic. The drm_vblank_put() is often used in interrupt handlers of
the kms drivers where you don't want to uneccessa
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
CC||f...@tuttu.info
--- Comment #4 from Alex
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #6 from Alex Deucher 2011-10-28 13:17:15 PDT ---
Created attachment 52866
--> https://bugs.freedesktop.org/attachment.cgi?id=52866
possible fix
patch 2/2. Do these patches help?
--
Configure bugmail: https://bugs.freedesktop.org
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
drm_getclient, drm_getstats and drm_getmap (with a few minor
adjustments) do not need global mutex, so fix that and
make the said ioctls DRM_UNLOCKED. Details:
drm_getclient: the only thing that should be protected here
is dev->filelist and that is already protected everywhere with
dev->stru
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
From: Jerome Glisse
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up at module init so first hotplug works
reliably no matter what is the initial set of connector.
Signed-off-by: Jerome Glisse
cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeo
On Fri, Oct 28, 2011 at 5:52 PM, wrote:
> From: Jerome Glisse
>
> Polarity needs to be set accordingly to connector status (connected
> or disconnected). Set it up at module init so first hotplug works
> reliably no matter what is the initial set of connector.
>
> Signed-off-by: Jerome Glisse
>
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter wrote:
...
> @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, struct
> drm_file *file,
...
> +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> + item->req.size = mem->size;
> + sis_malloc(
From: Tormod Volden
---
On top of danvet's kill-with-fire ad83cc3.
Tormod
drivers/gpu/drm/sis/sis_mm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 112a43b..63c2f75 100644
--- a/drivers/gpu/drm/si
On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter wrote:
> ...
> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev,
> > struct drm_file *file,
> ...
> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
On Fri, Oct 28, 2011 at 05:42:23PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
https://bugs.freedesktop.org/show_bug.cgi?id=36386
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, Oct 28, 2011 at 05:43:28PM -0400, Ilija Hadzic wrote:
> drm_getclient, drm_getstats and drm_getmap (with a few minor
> adjustments) do not need global mutex, so fix that and
> make the said ioctls DRM_UNLOCKED. Details:
>
> drm_getclient: the only thing that should be protected here
>
https://bugs.freedesktop.org/show_bug.cgi?id=36609
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29951
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sat, 29 Oct 2011, Daniel Vetter wrote:
+ /* the lock protects this section from itself executed in */
+ /* the context of another PID, ensuring that the process that */
+ /* wrote dev->last_vblank_wait is really the last process */
+ /* that was here; processes waitin
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter wrote:
> On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
>> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter
>> wrote:
>> ...
>> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev,
>> > struct drm_file *file,
>> ...
https://bugs.freedesktop.org/show_bug.cgi?id=42090
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
>
> > So I think the right thing to do is
> > - Kill dev->last_vblank_wait (in a prep patch).
>
> Agreed. Also drm_vblank_info function can go away
Actually, I was rather going to submit a patch t
Having registered debugfs files globally causes
the files to not show up on the second, third
etc.. card in the system.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|8
drivers/gpu/drm/radeon/radeon_device.c | 26 ++--
Only check the previously checked relocs for
duplicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_
The following three patches are just minor bug fixes.
I've send them to the list previously, but this time they are based upon
drm-next instead of drm-fixes and I also fixed some spelling mistakes in the
commit messages.
Please commit. Thanks,
Christian.
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel D?nzer wrote:
> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> > On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >
> > > So I think the right thing to do is
> > > - Kill dev->last_vblank_wait (in a prep patch).
> >
> > Agreed. Also drm_vblan
On Thu, Oct 27, 2011 at 10:19:39PM -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >The only really hairy thing going on is racing modeset ioctls against
> >vblank waiters. But modeset is protected by the dev->mode_config.mutex
> >and hence already races against wait_vblank
On Fri, 28 Oct 2011, Daniel Vetter wrote:
> On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel D?nzer wrote:
>> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
>>> On Thu, 27 Oct 2011, Daniel Vetter wrote:
>>>
So I think the right thing to do is
- Kill dev->last_vblank_wait (in a
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #49 from Siganderson 2011-10-28 05:39:21 PDT
---
(In reply to comment #48)
> > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
>
> Typo, it should be
>
>
> patch -p1 < name_of_the_patch.patch
> ^
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #50 from Siganderson 2011-10-28 05:42:37 PDT
---
I forgot to say that without touching anything in the window there are no
changes (60 fps... obviously 60 is the maximum when vsync is on).
--
Configure bugmail: https://bugs.freedes
On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang wrote:
> Hi,
>
> Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> and after that my screen can't show normally.
> No sure if it's a known issue.
No, that is the first time I've seen that. It looks as if the fence was
not released,
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #51 from Ilija Hadzic
2011-10-28 06:25:40 PDT ---
(In reply to comment #49)
> (In reply to comment #48)
> > > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
> >
> > Typo, it should be
> >
> >
> > patch -p1 < nam
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #13 from Roland Scheidegger 2011-10-28
06:49:59 PDT ---
(In reply to comment #12)
> csm->gart_limit and csm->vram_limit are correct.
>
> With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
> In ETRacer, wh
2011/10/28 Christian K?nig :
> Only check the previously checked relocs for
> duplicates. Also leaving the handle uninitialized
> isn't such a good idea.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon_cs.c | ? ?5 +++--
> ?1 files changed, 3
On Fri, Oct 28, 2011 at 07:10:51AM -0500, Ilija Hadzic wrote:
> I'll keep it then and figure out the best mutex/spinlock to use. It
> can be anything that exists on one-per-CRTC basis (vblank waits on
> different CTCs are not contending). The critical section is from
> that switch in which vblwait-
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #14 from Michal 2011-10-28 09:44:56 PDT
---
Minimum GARTSize which don't return fallbacks is 16MB.
Now, the problem is somewhere at the kernel side.
samples| %|
--
1295082 93.6410 vmlinux
30154 2.1803 r
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #15 from Michal 2011-10-28 10:13:15 PDT
---
FBTexPercent to 97
bash-4.1$ cat /var/log/Xorg.0.log|grep text
[ 8077.238] (II) RADEON(0): Will use 114688 kb for textures at offset
0x00c08000
etracer runs smoothly at 40 fps(with mesa 7
Looks like this patch got missed. Dave can you add it and CC: stable?
Alex
On Wed, May 25, 2011 at 2:02 PM, Alex Deucher wrote:
> This should make eDP more reliable.
>
> Signed-off-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/atombios_dp.c | ? 11 +++
> ?include/drm/drm_dp_helper.h
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
drivers/char/agp/intel-gtt.c |4
1 files chang
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
Here's a shorter patch which just elides the body of th
> Message: 5
> Date: Fri, 28 Oct 2011 11:30:38 +0200
> From: Daniel Vetter
> Subject: Re: [PATCH 3/3] drm: do not sleep on vblank while holding a
> mutex
> To: Ilija Hadzic
> Cc: dri-devel at lists.freedesktop.org
> Message-ID: <20111028093038.GB2919 at phenom.ffwll.local>
> Content-Type: t
On Fri, 28 Oct 2011 10:56:29 -0700
Keith Packard wrote:
> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #17 from auxsvr at gmail.com 2011-10-28 11:26:57 PDT ---
I'm afraid the virtualbox modules have nothing to do with this.
A hopefully helpful observation:
When I first load the large image in firefox, zooming in and out several times
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
> be careful with vblank_refcount. I think it probably should stay
> atomic. The drm_vblank_put() is often used in interrupt handlers of
> the kms drivers where you don't want to uneccessary wait on a lock,
> but be as quick as possible
On Oct 28, 2011, at 9:15 PM, Daniel Vetter wrote:
> On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
>> be careful with vblank_refcount. I think it probably should stay
>> atomic. The drm_vblank_put() is often used in interrupt handlers of
>> the kms drivers where you don't want to u
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
CC||feth at tuttu.info
--- Comment #4 from Al
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #6 from Alex Deucher 2011-10-28 13:17:15 PDT
---
Created attachment 52866
--> https://bugs.freedesktop.org/attachment.cgi?id=52866
possible fix
patch 2/2. Do these patches help?
--
Configure bugmail: https://bugs.freedesktop.or
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
drm_getclient, drm_getstats and drm_getmap (with a few minor
adjustments) do not need global mutex, so fix that and
make the said ioctls DRM_UNLOCKED. Details:
drm_getclient: the only thing that should be protected here
is dev->filelist and that is already protected everywhere with
dev->stru
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
From: Jerome Glisse
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up at module init so first hotplug works
reliably no matter what is the initial set of connector.
Signed-off-by: Jerome Glisse
cc: stable at kernel.org
---
drivers/gpu/drm/radeon/ra
On Fri, Oct 28, 2011 at 5:52 PM, wrote:
> From: Jerome Glisse
>
> Polarity needs to be set accordingly to connector status (connected
> or disconnected). Set it up at module init so first hotplug works
> reliably no matter what is the initial set of connector.
>
> Signed-off-by: Jerome Glisse
>
https://bugs.freedesktop.org/show_bug.cgi?id=36609
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Sat, 29 Oct 2011, Daniel Vetter wrote:
>> +/* the lock protects this section from itself executed in */
>> +/* the context of another PID, ensuring that the process that */
>> +/* wrote dev->last_vblank_wait is really the last process */
>> +/* that was here; processes waiting
Hi,
Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
and after that my screen can't show normally.
No sure if it's a known issue.
[169509.080020] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed...
GPU hung
[169509.080026] [drm] capturing error event; look for more in
On Fri, Oct 28, 2011 at 01:56:39PM +0100, Chris Wilson wrote:
> On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang
> wrote:
> > Hi,
> >
> > Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> > and after that my screen can't show normally.
> > No sure if it's a known issue.
>
> No, t
79 matches
Mail list logo
