[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On 03/06/2013 05:40 PM, Joe Perches wrote: > On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote: >> On 03/06/2013 05:30 PM, Joe Perches wrote: >>> On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: From: Stephen Warren This reverts most of eb90d08 "get_maintainer: allow keywords to match filenames"; all except the parts that are required to implement the new N: entry type. >>> >>> Just combine patches 1 and 3 into a single patch. >> >> That would break bisectability; using MAINTAINERS after applying a >> squashed 1+3 but without patch 2 applied would not operate as desired. > > > > Which is why I showed the whole thing in a single patch. > No worries if it's simply to increase the patch count... I'm not sure what showed refers to? I guess if I squashed /everything/ into a single commit (i.e. the change to the Tegra section in MAINTAINERS too) then there wouldn't be any bisect issues. I really don't care about patch count. The reason for >1 patch is that there's often push-back if doing logically separate things (adding N: feature, modifying a MAINTAINERS entry to use it, removing part of K: feature) in a single patch...
Re: [PATCH 3/4] drm/omap: Make fixed resolution panels work
On Wednesday 06 March 2013 06:15 AM, Rob Clark wrote:
On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_connector.c | 10 --
drivers/gpu/drm/omapdrm/omap_encoder.c |6 --
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..c952324 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index d48df71..9aed178 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -135,13 +135,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ ret = dssdrv->check_timings ?
+ dssdrv->check_timings(dssdev, timings) : 0;
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
maybe either here or _mode_valid(), for panels that don't have
set_timings(), we should double check that the new timings match what
we get from the panel's get_timings(). Other than that, it looks
fine.
Yeah, we should do that. I guess it makes more sense to do it earlier,
i.e, in mode_vaild.
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/exynos: modify the compatible string for exynos fimd
Already merged. :)
> -Original Message-
> From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
> Sent: Thursday, March 07, 2013 4:09 PM
> To: InKi Dae
> Cc: dri-devel@lists.freedesktop.org; linux-me...@vger.kernel.org;
> kgene@samsung.com; Joonyoung Shim; sunil joshi
> Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
> fimd
>
> Hi Mr Inki Dae,
>
> On 28 February 2013 08:12, Joonyoung Shim wrote:
> > On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
> >>
> >> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
> >> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
> >> value should be named after first specific SoC model in which this
> >> particular IP version was included as discussed at
> >> https://patchwork.kernel.org/patch/2144861/
> >>
> >> Signed-off-by: Vikas Sajjan
> >> ---
> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> index 9537761..433ed35 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> @@ -109,9 +109,9 @@ struct fimd_context {
> >> #ifdef CONFIG_OF
> >> static const struct of_device_id fimd_driver_dt_match[] = {
> >> - { .compatible = "samsung,exynos4-fimd",
> >> + { .compatible = "samsung,exynos4210-fimd",
> >> .data = &exynos4_fimd_driver_data },
> >> - { .compatible = "samsung,exynos5-fimd",
> >> + { .compatible = "samsung,exynos5250-fimd",
> >> .data = &exynos5_fimd_driver_data },
> >> {},
> >> };
> >
> >
> > Acked-by: Joonyoung Shim
>
> Can you please apply this patch.
>
> >
> > Thanks.
>
>
>
> --
> Thanks and Regards
> Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae wrote: > 2013/3/7 김승우 : >> >> >> On 2013년 03월 04일 23:05, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma wrote: > Right now hdmiphy operations and configs are kept inside hdmi driver. > hdmiphy related > code is tightly coupled with hdmi ip driver. Physicaly they are different > devices and s/Physicaly/Physically/ > should be instantiated independently. > > In terms of versions/mapping/configurations Hdmi and hdmiphy are > independent of each > other. It is preferred to isolate them and maintained independently. > > This implementations is tested for: > 1) Resolutions supported by exynos4 and 5 hdmi. > 2) Runtime PM and S2R scenarions for exynos5. > I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. >>> >>> I agree to it. splitting phy to a new driver will complicate the power >>> related >>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >>> config values, mapping (i2c/platform bus) etc. Handling this diversity >>> inside hdmi driver is complicating it with unrelated changes. >> >> Basically, I agree with the idea to split hdmiphy from hdmi. And it >> seems that already existing hdmiphy i2c device is just reused and >> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >> flow of power operations is reordered. >> >> But I'm not sure exynos_hdmiphy_driver_register() really need to be >> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >> is only used from hdmi. >> > > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. > But this is probably going to break dpms and/or suspend/resume functionality. Has that been tested? Stéphane > Thanks, > Inki Dae > >> Thanks and Regards, >> - Seung-Woo Kim >> >>> >>> I have tested this RFC for Runtime PM / S2R. But if we see any major >>> roadblock >>> we should re-factor this by explicitly calling power related callbacks >>> of mixer, phy, >>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >>> device. AFAIR something like this is already in place in chrome-kernel. >>> I've made some comments below. > This patch is dependent on > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html > > Signed-off-by: Rahul Sharma > --- > It is based on exynos-drm-next-todo branch at > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 > ++- > drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 > 8 files changed, 738 insertions(+), 368 deletions(-) > create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > >> >> >> >> -- >> Seung-Woo Kim >> Samsung Software R&D Center >> -- >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae wrote: > 2013/3/7 ??? : >> >> >> On 2013? 03? 04? 23:05, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >>> samsung.com> wrote: > Right now hdmiphy operations and configs are kept inside hdmi driver. > hdmiphy related > code is tightly coupled with hdmi ip driver. Physicaly they are different > devices and s/Physicaly/Physically/ > should be instantiated independently. > > In terms of versions/mapping/configurations Hdmi and hdmiphy are > independent of each > other. It is preferred to isolate them and maintained independently. > > This implementations is tested for: > 1) Resolutions supported by exynos4 and 5 hdmi. > 2) Runtime PM and S2R scenarions for exynos5. > I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. >>> >>> I agree to it. splitting phy to a new driver will complicate the power >>> related >>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >>> config values, mapping (i2c/platform bus) etc. Handling this diversity >>> inside hdmi driver is complicating it with unrelated changes. >> >> Basically, I agree with the idea to split hdmiphy from hdmi. And it >> seems that already existing hdmiphy i2c device is just reused and >> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >> flow of power operations is reordered. >> >> But I'm not sure exynos_hdmiphy_driver_register() really need to be >> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >> is only used from hdmi. >> > > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. > But this is probably going to break dpms and/or suspend/resume functionality. Has that been tested? St?phane > Thanks, > Inki Dae > >> Thanks and Regards, >> - Seung-Woo Kim >> >>> >>> I have tested this RFC for Runtime PM / S2R. But if we see any major >>> roadblock >>> we should re-factor this by explicitly calling power related callbacks >>> of mixer, phy, >>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >>> device. AFAIR something like this is already in place in chrome-kernel. >>> I've made some comments below. > This patch is dependent on > http://www.mail-archive.com/dri-devel at > lists.freedesktop.org/msg34733.html > http://www.mail-archive.com/dri-devel at > lists.freedesktop.org/msg34861.html > http://www.mail-archive.com/dri-devel at > lists.freedesktop.org/msg34862.html > > Signed-off-by: Rahul Sharma > --- > It is based on exynos-drm-next-todo branch at > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 > ++- > drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 > 8 files changed, 738 insertions(+), 368 deletions(-) > create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > >> >> >> >> -- >> Seung-Woo Kim >> Samsung Software R&D Center >> -- >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On 2013년 03월 07일 15:45, Rahul Sharma wrote: > Thanks Seung Woo, Mr. Dae, > > On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae wrote: >> 2013/3/7 김승우 : >>> >>> >>> On 2013년 03월 04일 23:05, Rahul Sharma wrote: Thanks Sean, On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: > On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma > wrote: >> Right now hdmiphy operations and configs are kept inside hdmi driver. >> hdmiphy related >> code is tightly coupled with hdmi ip driver. Physicaly they are >> different devices and > > s/Physicaly/Physically/ > >> should be instantiated independently. >> >> In terms of versions/mapping/configurations Hdmi and hdmiphy are >> independent of each >> other. It is preferred to isolate them and maintained independently. >> >> This implementations is tested for: >> 1) Resolutions supported by exynos4 and 5 hdmi. >> 2) Runtime PM and S2R scenarions for exynos5. >> > > I don't like the idea of spawning off yet another driver in here. It > adds more globals, more suspend/resume ordering issues, and more > implicit dependencies. I understand, however, that this is the Chosen > Way for the exynos driver, so I will save my rant. > I agree to it. splitting phy to a new driver will complicate the power related scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of config values, mapping (i2c/platform bus) etc. Handling this diversity inside hdmi driver is complicating it with unrelated changes. >>> >>> Basically, I agree with the idea to split hdmiphy from hdmi. And it >>> seems that already existing hdmiphy i2c device is just reused and >>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >>> flow of power operations is reordered. >>> >>> But I'm not sure exynos_hdmiphy_driver_register() really need to be >>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >>> is only used from hdmi. >>> >> >> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. >> > > I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by > hdmi driver. But in this RFC, hdmi-phy is not called by hdmi driver > anymore. Phy > ops will be called from drm-common-hdmi platform driver along with mixer and > hdmi ops. Considering this, exynos_drm_hdmi_probe() is more proper position. > > The rational behind my implementation is that I am projecting hdmi-phy as > a device which is peer to hdmi ip and mixer. These 3 devices together makes > DRM HDMI subsystem. > > Even physically hdmi-phy doesn't seems to be a part of hdmi ip though > configurations are listed under hdmi ip user manual. It looks like a > isolated module accessed by i2c. > > Though I don't find anything wrong with Seung Woo suggestion but above > placement of hdmi-phy (parallel to hdmi and mixer) makes more sense > to me. > > Please have a another look at it and let me know your opinion. > > Another things which bothers me is registering mixer, hdmi driver inside > exynos_drm_init(). If we strictly follow the hierarchy inside drm, > exynos_drm_init() > should register drm-common-hdmi only. drm-common-hdmi should register > mixer and hdmi (or hdmi-phy as well). Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi, and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi for exynos). Thanks and Regards, - Seung-Woo Kim > > regards, > Rahul Sharma. > >> Thanks, >> Inki Dae >> >>> Thanks and Regards, >>> - Seung-Woo Kim >>> I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock we should re-factor this by explicitly calling power related callbacks of mixer, phy, hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf device. AFAIR something like this is already in place in chrome-kernel. > I've made some comments below. > >> This patch is dependent on >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html >> >> Signed-off-by: Rahul Sharma >> --- >> It is based on exynos-drm-next-todo branch at >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + >> drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- >> drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - >> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 >>
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 23:47 -0700, Stephen Warren wrote: > On 03/06/2013 05:40 PM, Joe Perches wrote: > > Which is why I showed the whole thing in a single patch. > > No worries if it's simply to increase the patch count... > > I'm not sure what showed refers to? The changes I posted with the suggestion https://lkml.org/lkml/2013/3/6/468 > I guess if I squashed /everything/ into a single commit (i.e. the change > to the Tegra section in MAINTAINERS too) then there wouldn't be any > bisect issues. I really don't care about patch count. The reason for >1 > patch is that there's often push-back if doing logically separate things > (adding N: feature, modifying a MAINTAINERS entry to use it, removing > part of K: feature) in a single patch... Not from me anyway. I think it's a single logical change and it's trivial too. No worries whatever happens. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 23:47 -0700, Stephen Warren wrote: > On 03/06/2013 05:40 PM, Joe Perches wrote: > > Which is why I showed the whole thing in a single patch. > > No worries if it's simply to increase the patch count... > > I'm not sure what showed refers to? The changes I posted with the suggestion https://lkml.org/lkml/2013/3/6/468 > I guess if I squashed /everything/ into a single commit (i.e. the change > to the Tegra section in MAINTAINERS too) then there wouldn't be any > bisect issues. I really don't care about patch count. The reason for >1 > patch is that there's often push-back if doing logically separate things > (adding N: feature, modifying a MAINTAINERS entry to use it, removing > part of K: feature) in a single patch... Not from me anyway. I think it's a single logical change and it's trivial too. No worries whatever happens.
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On 03/06/2013 05:40 PM, Joe Perches wrote: > On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote: >> On 03/06/2013 05:30 PM, Joe Perches wrote: >>> On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: From: Stephen Warren This reverts most of eb90d08 "get_maintainer: allow keywords to match filenames"; all except the parts that are required to implement the new N: entry type. >>> >>> Just combine patches 1 and 3 into a single patch. >> >> That would break bisectability; using MAINTAINERS after applying a >> squashed 1+3 but without patch 2 applied would not operate as desired. > > > > Which is why I showed the whole thing in a single patch. > No worries if it's simply to increase the patch count... I'm not sure what showed refers to? I guess if I squashed /everything/ into a single commit (i.e. the change to the Tegra section in MAINTAINERS too) then there wouldn't be any bisect issues. I really don't care about patch count. The reason for >1 patch is that there's often push-back if doing logically separate things (adding N: feature, modifying a MAINTAINERS entry to use it, removing part of K: feature) in a single patch... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
Thanks Seung Woo, Mr. Dae, On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae wrote: > 2013/3/7 김승우 : >> >> >> On 2013년 03월 04일 23:05, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma wrote: > Right now hdmiphy operations and configs are kept inside hdmi driver. > hdmiphy related > code is tightly coupled with hdmi ip driver. Physicaly they are different > devices and s/Physicaly/Physically/ > should be instantiated independently. > > In terms of versions/mapping/configurations Hdmi and hdmiphy are > independent of each > other. It is preferred to isolate them and maintained independently. > > This implementations is tested for: > 1) Resolutions supported by exynos4 and 5 hdmi. > 2) Runtime PM and S2R scenarions for exynos5. > I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. >>> >>> I agree to it. splitting phy to a new driver will complicate the power >>> related >>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >>> config values, mapping (i2c/platform bus) etc. Handling this diversity >>> inside hdmi driver is complicating it with unrelated changes. >> >> Basically, I agree with the idea to split hdmiphy from hdmi. And it >> seems that already existing hdmiphy i2c device is just reused and >> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >> flow of power operations is reordered. >> >> But I'm not sure exynos_hdmiphy_driver_register() really need to be >> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >> is only used from hdmi. >> > > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. > I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by hdmi driver. But in this RFC, hdmi-phy is not called by hdmi driver anymore. Phy ops will be called from drm-common-hdmi platform driver along with mixer and hdmi ops. The rational behind my implementation is that I am projecting hdmi-phy as a device which is peer to hdmi ip and mixer. These 3 devices together makes DRM HDMI subsystem. Even physically hdmi-phy doesn't seems to be a part of hdmi ip though configurations are listed under hdmi ip user manual. It looks like a isolated module accessed by i2c. Though I don't find anything wrong with Seung Woo suggestion but above placement of hdmi-phy (parallel to hdmi and mixer) makes more sense to me. Please have a another look at it and let me know your opinion. Another things which bothers me is registering mixer, hdmi driver inside exynos_drm_init(). If we strictly follow the hierarchy inside drm, exynos_drm_init() should register drm-common-hdmi only. drm-common-hdmi should register mixer and hdmi (or hdmi-phy as well). regards, Rahul Sharma. > Thanks, > Inki Dae > >> Thanks and Regards, >> - Seung-Woo Kim >> >>> >>> I have tested this RFC for Runtime PM / S2R. But if we see any major >>> roadblock >>> we should re-factor this by explicitly calling power related callbacks >>> of mixer, phy, >>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >>> device. AFAIR something like this is already in place in chrome-kernel. >>> I've made some comments below. > This patch is dependent on > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html > > Signed-off-by: Rahul Sharma > --- > It is based on exynos-drm-next-todo branch at > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 > ++- > drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 > 8 files changed, 738 insertions(+), 368 deletions(-) > create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > >> >> >> >> -- >> Seung-Woo Kim >> Samsung Software R&D Center >> -- >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Regar
[pull] drm-intel-fixes
Hi Dave, A bunch of fixes, nothing truely horrible: - Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs and subsequent fallout (Paulo) - Fixup off-by-one in our hsw id table (Kenneth) - Fixup ilk rc6 support (disabled by default), regression introduced in 3.8 - g4x plane w/a from Egbert Eich - gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson - Workaround dying ivb machines with less aggressive rc6 values (St?phane Marchesin) Most of the patches are cc: stable, one with a note about an additional patch which needs to be backported as prerequisite. Cheers, Daniel The following changes since commit 202adf4b9f5957b26a1cb97267d78e0edb319c5e: drm/i915: Revert hdmi HDP pin checks (2013-02-22 13:04:33 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to f40ebd6bcbbd0d30591f42dc16be52b5086a366b: drm/i915: Turn off hsync and vsync on ADPA when disabling crt (2013-03-06 18:03:07 +0100) Daniel Vetter (1): drm/i915: enable irqs earlier when resuming Egbert Eich (1): DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. Kenneth Graunke (1): drm/i915: Fix Haswell/CRW PCI IDs. Patrik Jakobsson (2): drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits drm/i915: Turn off hsync and vsync on ADPA when disabling crt Paulo Zanoni (2): drm/i915: wait_event_timeout's timeout is in jiffies drm/i915: also disable south interrupts when handling them St?phane Marchesin (1): drm/i915: Increase the RC6p threshold. Syam Sidhardhan (1): drm/i915: Fix missing variable initilization Ville Syrj?l? (1): drm/i915: Don't clobber crtc->fb when queue_flip fails drivers/gpu/drm/i915/i915_drv.c | 25 --- drivers/gpu/drm/i915/i915_irq.c | 26 ++-- drivers/gpu/drm/i915/i915_reg.h |4 ++-- drivers/gpu/drm/i915/intel_crt.c |2 +- drivers/gpu/drm/i915/intel_ddi.c |2 +- drivers/gpu/drm/i915/intel_display.c | 37 +++--- drivers/gpu/drm/i915/intel_dp.c |3 ++- drivers/gpu/drm/i915/intel_pm.c |2 +- 8 files changed, 79 insertions(+), 22 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #9 from Alex Deucher --- Possibly a duplicate of bug 59592 or bug 60848. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/f3d1c549/attachment-0001.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 Alex Deucher changed: What|Removed |Added Summary|[r600g] GPU lockup when |[r600g] GPU lockup when |playing WoW with HD6450 and |playing WoW with HD6450 |3.8.1 kernel|with htile enabled -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/6d48a5d8/attachment.html>
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
2013/3/7 김승우 : > > > On 2013년 03월 04일 23:05, Rahul Sharma wrote: >> Thanks Sean, >> >> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: >>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >>> wrote: Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy related code is tightly coupled with hdmi ip driver. Physicaly they are different devices and >>> >>> s/Physicaly/Physically/ >>> should be instantiated independently. In terms of versions/mapping/configurations Hdmi and hdmiphy are independent of each other. It is preferred to isolate them and maintained independently. This implementations is tested for: 1) Resolutions supported by exynos4 and 5 hdmi. 2) Runtime PM and S2R scenarions for exynos5. >>> >>> I don't like the idea of spawning off yet another driver in here. It >>> adds more globals, more suspend/resume ordering issues, and more >>> implicit dependencies. I understand, however, that this is the Chosen >>> Way for the exynos driver, so I will save my rant. >>> >> >> I agree to it. splitting phy to a new driver will complicate the power >> related >> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >> config values, mapping (i2c/platform bus) etc. Handling this diversity >> inside hdmi driver is complicating it with unrelated changes. > > Basically, I agree with the idea to split hdmiphy from hdmi. And it > seems that already existing hdmiphy i2c device is just reused and > hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling > flow of power operations is reordered. > > But I'm not sure exynos_hdmiphy_driver_register() really need to be > called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to > call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy > is only used from hdmi. > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. Thanks, Inki Dae > Thanks and Regards, > - Seung-Woo Kim > >> >> I have tested this RFC for Runtime PM / S2R. But if we see any major >> roadblock >> we should re-factor this by explicitly calling power related callbacks >> of mixer, phy, >> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >> device. AFAIR something like this is already in place in chrome-kernel. >> >>> I've made some comments below. >>> This patch is dependent on http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html Signed-off-by: Rahul Sharma --- It is based on exynos-drm-next-todo branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 ++- drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 8 files changed, 738 insertions(+), 368 deletions(-) create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > > > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau lockdep splat
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote: > get_maintainer.pl could always look at file contents IIRC. The change > was that I added keyword "tegra" to the Tegra section that now matches > this file's contents. > > ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau > > ... might be a better invocation, although perhaps I should add an > explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS. No, you should add a pattern which matches only tegra. If there's no such pattern, you should simply drop the "K:" thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
nouveau lockdep splat
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > > ... > > linux-tegra at vger.kernel.org (open list:TEGRA SUPPORT) > > > > Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... > > TEGRA SUPPORT > M:Stephen Warren > L:linux-tegra at vger.kernel.org > Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ > T:git > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > S:Supported > K:(?i)[^a-z]tegra > > Note the last line and this: > > $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c > u32 rekey = 56; /* binary driver, and tegra constant */ > max_ac_packet -= 18; /* constant from tegra */ > > Fun. Yeah, and a lot of it, thanks for digging this out. So obviously this regex is a bit... unfortunate. Although the idea of grepping the files for unique patterns is not bad, I have to admit. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #8 from Chris Rankin --- (In reply to comment #7) > Does disabling htile support help? Set env var R600_HYPERZ=0 Yes, this prevents the GPU from locking up. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/4b7b4c4a/attachment.html>
nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > ... > linux-tegra at vger.kernel.org (open list:TEGRA SUPPORT) > > Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow keywords to match filenames") of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren L: linux-tegra at vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On 2013년 03월 04일 23:05, Rahul Sharma wrote: > Thanks Sean, > > On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: >> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >> wrote: >>> Right now hdmiphy operations and configs are kept inside hdmi driver. >>> hdmiphy related >>> code is tightly coupled with hdmi ip driver. Physicaly they are different >>> devices and >> >> s/Physicaly/Physically/ >> >>> should be instantiated independently. >>> >>> In terms of versions/mapping/configurations Hdmi and hdmiphy are >>> independent of each >>> other. It is preferred to isolate them and maintained independently. >>> >>> This implementations is tested for: >>> 1) Resolutions supported by exynos4 and 5 hdmi. >>> 2) Runtime PM and S2R scenarions for exynos5. >>> >> >> I don't like the idea of spawning off yet another driver in here. It >> adds more globals, more suspend/resume ordering issues, and more >> implicit dependencies. I understand, however, that this is the Chosen >> Way for the exynos driver, so I will save my rant. >> > > I agree to it. splitting phy to a new driver will complicate the power related > scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of > config values, mapping (i2c/platform bus) etc. Handling this diversity > inside hdmi driver is complicating it with unrelated changes. Basically, I agree with the idea to split hdmiphy from hdmi. And it seems that already existing hdmiphy i2c device is just reused and hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling flow of power operations is reordered. But I'm not sure exynos_hdmiphy_driver_register() really need to be called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy is only used from hdmi. Thanks and Regards, - Seung-Woo Kim > > I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock > we should re-factor this by explicitly calling power related callbacks > of mixer, phy, > hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf > device. AFAIR something like this is already in place in chrome-kernel. > >> I've made some comments below. >> >>> This patch is dependent on >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html >>> >>> Signed-off-by: Rahul Sharma >>> --- >>> It is based on exynos-drm-next-todo branch at >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + >>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- >>> drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - >>> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 >>> ++- >>> drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 >>> 8 files changed, 738 insertions(+), 368 deletions(-) >>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h >>> -- Seung-Woo Kim Samsung Software R&D Center -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/exynos: fimd: calculate the correct address offset
On 03/06/2013 02:20 PM, Leela Krishna Amudala wrote:
> Calculate the correct address offset values for alpha and color key
> control registers and clear size control register for window 0
>
> Signed-off-by: Leela Krishna Amudala
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..78bab4a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -38,21 +38,22 @@
> /* position control register for hardware window 0, 2 ~ 4.*/
> #define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
> #define VIDOSD_B(win) (VIDOSD_BASE + 0x04 + (win) * 16)
> +/* size control register is avaliable only for windows 0, 1 and 2. */
> /* size control register for hardware window 0. */
> #define VIDOSD_C_SIZE_W0(VIDOSD_BASE + 0x08)
> -/* alpha control register for hardware window 1 ~ 4. */
> -#define VIDOSD_C(win)(VIDOSD_BASE + 0x18 + (win) * 16)
> -/* size control register for hardware window 1 ~ 4. */
> +/* size control register for hardware window 1 ~ 2. */
> #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
> +/* alpha control register for hardware window 1 ~ 4. */
> +#define VIDOSD_C(win)(VIDOSD_BASE + 0x08 + (win) * 16)
>
> #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
> #define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8)
> #define VIDWx_BUF_SIZE(win, buf)(VIDW_BUF_SIZE(buf) + (win) * 4)
>
> /* color key control register for hardware window 1 ~ 4. */
> -#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8))
> +#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8))
> /* color key value register for hardware window 1 ~ 4. */
> -#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8))
> +#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
>
> /* FIMD has totally five hardware windows. */
> #define WINDOWS_NR 5
> @@ -782,11 +783,14 @@ static void fimd_clear_win(struct fimd_context *ctx,
> int win)
> writel(0, ctx->regs + WINCON(win));
> writel(0, ctx->regs + VIDOSD_A(win));
> writel(0, ctx->regs + VIDOSD_B(win));
> - writel(0, ctx->regs + VIDOSD_C(win));
> + if (win != 0)
> + writel(0, ctx->regs + VIDOSD_C(win));
>
> if (win == 1 || win == 2)
> writel(0, ctx->regs + VIDOSD_D(win));
>
> + if (win == 0)
> + writel(0, ctx->regs + VIDOSD_C_SIZE_W0);
> val = readl(ctx->regs + SHADOWCON);
> val &= ~SHADOWCON_WINx_PROTECT(win);
> writel(val, ctx->regs + SHADOWCON);
As i said at v1 patch, i prefer to remove VIDOSD_C_SIZE_W0 and it makes
codes are simple. Even if VIDOSD_C_SIZE_W0 is defined, it's not good
that VIDOSD_C(0) can mean VIDOSD_C_SIZE_W0.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7514bee..a4356b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -40,11 +40,12 @@
/* position control register for hardware window 0, 2 ~ 4.*/
#define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
#define VIDOSD_B(win) (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win) (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win) (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware window 1 ~ 2. */
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
@@ -52,9 +53,9 @@
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
/* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8))
/* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR5
@@ -583,7 +584,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
- offset = VIDOSD_C_SIZE_W0;
+ offse
[PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
2013/3/1 Vikas Sajjan :
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> Acked-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..e323cf9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -20,6 +20,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
> + OF_USE_NATIVE_MODE);
Add "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" to
drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
selected, these two configs should also be selected.
Thanks,
Inki Dae
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
> ret);
> + return ret;
> + }
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On 03/06/2013 05:30 PM, Joe Perches wrote: > On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: >> From: Stephen Warren >> >> This reverts most of eb90d08 "get_maintainer: allow keywords to match >> filenames"; all except the parts that are required to implement the new >> N: entry type. > > Just combine patches 1 and 3 into a single patch. That would break bisectability; using MAINTAINERS after applying a squashed 1+3 but without patch 2 applied would not operate as desired.
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
From: Stephen Warren
This reverts most of eb90d08 "get_maintainer: allow keywords to match
filenames"; all except the parts that are required to implement the new
N: entry type.
The rationale is that it's better to have K: match just patch or file
content as it previously did, and N: match just filenames, rather than
have K: math all three cases. This gives more explicit control, and
removes the temptation to use K: for filenames, and then have those
keywords accidentally match unexpected patch or file content.
Signed-off-by: Stephen Warren
---
v2: New patch.
---
MAINTAINERS |9 -
scripts/get_maintainer.pl |2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2d02ab5..e68a07a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -100,13 +100,12 @@ Descriptions of section entries:
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
- "of_get_profile"
+ matches patches or files that contain "of_get_profile"
K: \b(printk|pr_(info|err))\b
- matches patch or file content, or filenames, that contain one or
- more of the words printk, pr_info or pr_err
+ matches patches or files that contain one or more of the words
+ printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Note: For the hard of thinking, this list is meant to remain in alphabetical
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 27dc5cb..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K' || $type eq 'N') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
[PATCH V2 2/3] MAINTAINERS: tegra: match related files using N: not K:
From: Stephen Warren This causes the regex to be applied to filenames only, and not patch or file content (such as comments). This should prevent e.g. drivers/gpu/drm/nouveau/nv50_display.c from matching this entry. Reported-by: Marcin Slusarz Signed-off-by: Stephen Warren --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c9b1e37..2d02ab5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7851,7 +7851,7 @@ L:linux-tegra at vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported -K: (?i)[^a-z]tegra +N: [^a-z]tegra TEHUTI ETHERNET DRIVER M: Andy Gospodarek -- 1.7.10.4
[PATCH V2 1/3] get_maintainer: create filename-only regex match type
From: Stephen Warren
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
match filenames"), but without the disadvantage that "random" file
content, such as comments, will ever match the regex.
Suggested-by: Joe Perches
Signed-off-by: Stephen Warren
---
v2: Corrected typo in MAINTAINERS documentation
---
MAINTAINERS |3 +++
scripts/get_maintainer.pl |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..c9b1e37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ N: [^a-z]tegra all files whose patch contains the word tegra
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..27dc5cb 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'K' || $type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
[PATCH 2/2] drm: add new QXL driver.
QXL is a paravirtual graphics device used by the Spice virtual desktop interface. The drivers uses GEM and TTM to manage memory, the qxl hw fencing however is quite different than normal TTM expects, we have to keep track of a number of non-linear fence ids per bo that we need to have released by the hardware. The releases are freed from a workqueue that wakes up and processes the release ring. releases are suballocated from a BO, there are 3 release categories, drawables, surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling. The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface ids. This requires a newer version of the QXL userspace driver, so shouldn't be enabled until that has been placed into your distro of choice. Authors: Dave Airlie, Alon Levy Signed-off-by: Alon Levy Signed-off-by: Dave Airlie --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/qxl/Kconfig | 10 + drivers/gpu/drm/qxl/Makefile | 9 + drivers/gpu/drm/qxl/qxl_cmd.c | 711 +++ drivers/gpu/drm/qxl/qxl_debugfs.c | 135 ++ drivers/gpu/drm/qxl/qxl_dev.h | 879 ++ drivers/gpu/drm/qxl/qxl_display.c | 981 ++ drivers/gpu/drm/qxl/qxl_draw.c| 378 +++ drivers/gpu/drm/qxl/qxl_drv.c | 131 + drivers/gpu/drm/qxl/qxl_drv.h | 566 ++ drivers/gpu/drm/qxl/qxl_dumb.c| 76 +++ drivers/gpu/drm/qxl/qxl_fb.c | 567 ++ drivers/gpu/drm/qxl/qxl_fence.c | 97 drivers/gpu/drm/qxl/qxl_gem.c | 178 +++ drivers/gpu/drm/qxl/qxl_image.c | 120 + drivers/gpu/drm/qxl/qxl_ioctl.c | 411 drivers/gpu/drm/qxl/qxl_irq.c | 97 drivers/gpu/drm/qxl/qxl_kms.c | 300 drivers/gpu/drm/qxl/qxl_object.c | 365 ++ drivers/gpu/drm/qxl/qxl_object.h | 112 + drivers/gpu/drm/qxl/qxl_release.c | 307 drivers/gpu/drm/qxl/qxl_ttm.c | 580 ++ include/uapi/drm/Kbuild | 1 + include/uapi/drm/qxl_drm.h| 151 ++ 25 files changed, 7165 insertions(+) create mode 100644 drivers/gpu/drm/qxl/Kconfig create mode 100644 drivers/gpu/drm/qxl/Makefile create mode 100644 drivers/gpu/drm/qxl/qxl_cmd.c create mode 100644 drivers/gpu/drm/qxl/qxl_debugfs.c create mode 100644 drivers/gpu/drm/qxl/qxl_dev.h create mode 100644 drivers/gpu/drm/qxl/qxl_display.c create mode 100644 drivers/gpu/drm/qxl/qxl_draw.c create mode 100644 drivers/gpu/drm/qxl/qxl_drv.c create mode 100644 drivers/gpu/drm/qxl/qxl_drv.h create mode 100644 drivers/gpu/drm/qxl/qxl_dumb.c create mode 100644 drivers/gpu/drm/qxl/qxl_fb.c create mode 100644 drivers/gpu/drm/qxl/qxl_fence.c create mode 100644 drivers/gpu/drm/qxl/qxl_gem.c create mode 100644 drivers/gpu/drm/qxl/qxl_image.c create mode 100644 drivers/gpu/drm/qxl/qxl_ioctl.c create mode 100644 drivers/gpu/drm/qxl/qxl_irq.c create mode 100644 drivers/gpu/drm/qxl/qxl_kms.c create mode 100644 drivers/gpu/drm/qxl/qxl_object.c create mode 100644 drivers/gpu/drm/qxl/qxl_object.h create mode 100644 drivers/gpu/drm/qxl/qxl_release.c create mode 100644 drivers/gpu/drm/qxl/qxl_ttm.c create mode 100644 include/uapi/drm/qxl_drm.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1e82882..19b8e0d 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -220,3 +220,5 @@ source "drivers/gpu/drm/tegra/Kconfig" source "drivers/gpu/drm/omapdrm/Kconfig" source "drivers/gpu/drm/tilcdc/Kconfig" + +source "drivers/gpu/drm/qxl/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 0d59b24..6a42115 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -52,4 +52,5 @@ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ +obj-$(CONFIG_DRM_QXL) += qxl/ obj-y += i2c/ diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig new file mode 100644 index 000..2f1a57e --- /dev/null +++ b/drivers/gpu/drm/qxl/Kconfig @@ -0,0 +1,10 @@ +config DRM_QXL + tristate "QXL virtual GPU" + depends on DRM && PCI + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT +select DRM_KMS_HELPER +select DRM_TTM + help + QXL virtual GPU for Spice virtualization desktop integration. Do not enable this driver unless your distro ships a corresponding X.org QXL driver that can handle kernel modesetting. diff --git a/drivers/gpu/drm/qxl/Makefile b/drivers/gpu/drm/qxl/Makefile new file mode 100644 index 000..ea046ba --- /dev/null +++ b/drivers/gpu/drm/qxl/Makefile @@ -0,0 +1,9 @@ +#
[PATCH 1/2] ttm: export functions to allow qxl do its own iomapping
qxl wants to use io mapping like i915 gem does, for now
just export the symbols so the driver can implement atomic
page maps using io mapping.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +
include/drm/ttm/ttm_bo_driver.h | 4
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 44420fc..aaf6f47 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -86,6 +86,7 @@ int ttm_mem_io_lock(struct ttm_mem_type_manager *man, bool
interruptible)
mutex_lock(&man->io_reserve_mutex);
return 0;
}
+EXPORT_SYMBOL(ttm_mem_io_lock);
void ttm_mem_io_unlock(struct ttm_mem_type_manager *man)
{
@@ -94,6 +95,7 @@ void ttm_mem_io_unlock(struct ttm_mem_type_manager *man)
mutex_unlock(&man->io_reserve_mutex);
}
+EXPORT_SYMBOL(ttm_mem_io_unlock);
static int ttm_mem_io_evict(struct ttm_mem_type_manager *man)
{
@@ -111,8 +113,9 @@ static int ttm_mem_io_evict(struct ttm_mem_type_manager
*man)
return 0;
}
-static int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem)
+
+int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
+ struct ttm_mem_reg *mem)
{
struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
int ret = 0;
@@ -134,9 +137,10 @@ retry:
}
return ret;
}
+EXPORT_SYMBOL(ttm_mem_io_reserve);
-static void ttm_mem_io_free(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem)
+void ttm_mem_io_free(struct ttm_bo_device *bdev,
+struct ttm_mem_reg *mem)
{
struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
@@ -149,6 +153,7 @@ static void ttm_mem_io_free(struct ttm_bo_device *bdev,
bdev->driver->io_mem_free(bdev, mem);
}
+EXPORT_SYMBOL(ttm_mem_io_free);
int ttm_mem_io_reserve_vm(struct ttm_buffer_object *bo)
{
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 0fbd046..9c8dca7 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -902,6 +902,10 @@ extern void ttm_bo_unreserve_locked(struct
ttm_buffer_object *bo);
* ttm_bo_util.c
*/
+int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
+ struct ttm_mem_reg *mem);
+void ttm_mem_io_free(struct ttm_bo_device *bdev,
+struct ttm_mem_reg *mem);
/**
* ttm_bo_move_ttm
*
--
1.8.1.4
qemu qxl kms driver
Hi, This is a KMS driver for the QXL virtual hw device shipped in qemu. The first patch just adds some ttm symbol exports, the second contains the driver. Its also in my git repo here http://cgit.freedesktop.org/~airlied/linux/log/?h=qxl-upstream The userspace driver is here http://cgit.freedesktop.org/~airlied/xf86-video-qxl/log/?h=qxl-kms There is also a header file addition to libdrm: http://cgit.freedesktop.org/~airlied/drm/log/?h=qxl-kms though I could probably drop it into the ddx at this point, since there isn't really any DRI usefulness on this hw yet. Though maybe we can save a copy or two in some fast paths. Dave.
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote: > On 03/06/2013 05:30 PM, Joe Perches wrote: > > On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> This reverts most of eb90d08 "get_maintainer: allow keywords to match > >> filenames"; all except the parts that are required to implement the new > >> N: entry type. > > > > Just combine patches 1 and 3 into a single patch. > > That would break bisectability; using MAINTAINERS after applying a > squashed 1+3 but without patch 2 applied would not operate as desired. Which is why I showed the whole thing in a single patch. No worries if it's simply to increase the patch count... cheers, Joe ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote: > On 03/06/2013 05:30 PM, Joe Perches wrote: > > On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> This reverts most of eb90d08 "get_maintainer: allow keywords to match > >> filenames"; all except the parts that are required to implement the new > >> N: entry type. > > > > Just combine patches 1 and 3 into a single patch. > > That would break bisectability; using MAINTAINERS after applying a > squashed 1+3 but without patch 2 applied would not operate as desired. Which is why I showed the whole thing in a single patch. No worries if it's simply to increase the patch count... cheers, Joe
Re: [PATCH] drm/mgag200: Reject modes that are too big for VRAM
On Wed, Feb 27, 2013 at 1:55 AM, Christopher Harvey wrote: > A monitor or a user could request a resolution greater than the > available VRAM for the backing framebuffer. This change checks the > required framebuffer size against the max VRAM size and rejects modes > if they are too big. This change can also remove a mode request passed > in via the video= parameter. I can't say I like the bpp finding code, but my brain is failing to come up with something better, so yeah I think this is fine, those cards with 1.5MB VRAM always piss me off :-) I'll apply these, send on any others! Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libdrm/exynos: add test application for 2d gpu.
2013/3/3 Rob Clark : > On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae wrote: >> Actually, we have already implemented the EXA part of X server and >> that has being used on our linux platform. But I think we could more >> improvement this. So are you writting user side g2d drivers for Chrome >> book(based on Exynos5250 SoC)? And do you want to improment this? > > Oh, ok.. I was under the impression that this did not exist. > > Well, when I receive my chromebook, I'll take a look, and see what > else is needed for a more traditional x11 desktop. Where is the git > tree? > Sorry for late answer. Unfurtunately, the EXA module isn't published yet so I'm checking if that module could be published now. so much complicated. :( As soon as checked, I'll let you know. Thanks, Inki Dae > BR, > -R > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] MAINTAINERS: tegra: match related files using N: not K:
From: Stephen Warren This causes the regex to be applied to filenames only, and not patch or file content (such as comments). This should prevent e.g. drivers/gpu/drm/nouveau/nv50_display.c from matching this entry. Reported-by: Marcin Slusarz Signed-off-by: Stephen Warren --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1671842..8b986e2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7851,7 +7851,7 @@ L:linux-tegra at vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported -K: (?i)[^a-z]tegra +N: [^a-z]tegra TEHUTI ETHERNET DRIVER M: Andy Gospodarek -- 1.7.10.4
[PATCH 1/2] get_maintainer: create filename-only regex match type
From: Stephen Warren
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
match filenames"), but without the disadvantage that "random" file
content, such as comments, will ever match the regex.
Suggested-by: Joe Perches
Signed-off-by: Stephen Warren
---
MAINTAINERS |3 +++
scripts/get_maintainer.pl |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..1671842 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ K: [^a-z]tegra all files whose patch contains the word tegra
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..27dc5cb 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'K' || $type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On 03/06/2013 05:30 PM, Joe Perches wrote: > On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: >> From: Stephen Warren >> >> This reverts most of eb90d08 "get_maintainer: allow keywords to match >> filenames"; all except the parts that are required to implement the new >> N: entry type. > > Just combine patches 1 and 3 into a single patch. That would break bisectability; using MAINTAINERS after applying a squashed 1+3 but without patch 2 applied would not operate as desired. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: > From: Stephen Warren > > This reverts most of eb90d08 "get_maintainer: allow keywords to match > filenames"; all except the parts that are required to implement the new > N: entry type. Just combine patches 1 and 3 into a single patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
From: Stephen Warren
This reverts most of eb90d08 "get_maintainer: allow keywords to match
filenames"; all except the parts that are required to implement the new
N: entry type.
The rationale is that it's better to have K: match just patch or file
content as it previously did, and N: match just filenames, rather than
have K: math all three cases. This gives more explicit control, and
removes the temptation to use K: for filenames, and then have those
keywords accidentally match unexpected patch or file content.
Signed-off-by: Stephen Warren
---
v2: New patch.
---
MAINTAINERS |9 -
scripts/get_maintainer.pl |2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2d02ab5..e68a07a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -100,13 +100,12 @@ Descriptions of section entries:
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
- "of_get_profile"
+ matches patches or files that contain "of_get_profile"
K: \b(printk|pr_(info|err))\b
- matches patch or file content, or filenames, that contain one or
- more of the words printk, pr_info or pr_err
+ matches patches or files that contain one or more of the words
+ printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Note: For the hard of thinking, this list is meant to remain in alphabetical
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 27dc5cb..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K' || $type eq 'N') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames
On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote: > From: Stephen Warren > > This reverts most of eb90d08 "get_maintainer: allow keywords to match > filenames"; all except the parts that are required to implement the new > N: entry type. Just combine patches 1 and 3 into a single patch.
[PATCH V2 2/3] MAINTAINERS: tegra: match related files using N: not K:
From: Stephen Warren This causes the regex to be applied to filenames only, and not patch or file content (such as comments). This should prevent e.g. drivers/gpu/drm/nouveau/nv50_display.c from matching this entry. Reported-by: Marcin Slusarz Signed-off-by: Stephen Warren --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c9b1e37..2d02ab5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7851,7 +7851,7 @@ L:linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported -K: (?i)[^a-z]tegra +N: [^a-z]tegra TEHUTI ETHERNET DRIVER M: Andy Gospodarek -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 1/3] get_maintainer: create filename-only regex match type
From: Stephen Warren
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
match filenames"), but without the disadvantage that "random" file
content, such as comments, will ever match the regex.
Suggested-by: Joe Perches
Signed-off-by: Stephen Warren
---
v2: Corrected typo in MAINTAINERS documentation
---
MAINTAINERS |3 +++
scripts/get_maintainer.pl |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..c9b1e37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ N: [^a-z]tegra all files whose patch contains the word tegra
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..27dc5cb 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'K' || $type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] get_maintainer: create filename-only regex match type
On Wed, 2013-03-06 at 16:36 -0700, Stephen Warren wrote:
> From: Stephen Warren
>
> Create a new N: entry type in MAINTAINERS which performs a regex match
> against filenames; either those extracted from patch +++ or --- lines,
> or those specified on the command-line using the -f option.
NAK
At least get the prefix right and remove the
now incorrect filename matches in K:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9561658..1671842 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -90,6 +90,9 @@ Descriptions of section entries:
> F: drivers/net/* all files in drivers/net, but not below
> F: */net/* all files in "any top level directory"/net
> One pattern per line. Multiple F: lines acceptable.
> + N: Files and directories with regex patterns.
> +K: [^a-z]tegra all files whose patch contains the word tegra
N: not K:
> +One pattern per line. Multiple N: lines acceptable.
> X: Files and directories that are NOT maintained, same rules as F:
> Files exclusions are tested before file matches.
> Can be useful for excluding a specific subdirectory, for instance:
and remove the K: descriptions that show filename too.
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index ce4cc83..27dc5cb 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -611,7 +611,7 @@ sub get_maintainers {
> $hash{$tvi} = $value_pd;
> }
> }
> - } elsif ($type eq 'K') {
> + } elsif ($type eq 'K' || $type eq 'N') {
> if ($file =~ m/$value/x) {
> $hash{$tvi} = 0;
> }
Remove K: It has no value here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] get_maintainer: create filename-only regex match type
On Wed, 2013-03-06 at 16:36 -0700, Stephen Warren wrote:
> From: Stephen Warren
>
> Create a new N: entry type in MAINTAINERS which performs a regex match
> against filenames; either those extracted from patch +++ or --- lines,
> or those specified on the command-line using the -f option.
NAK
At least get the prefix right and remove the
now incorrect filename matches in K:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9561658..1671842 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -90,6 +90,9 @@ Descriptions of section entries:
> F: drivers/net/* all files in drivers/net, but not below
> F: */net/* all files in "any top level directory"/net
> One pattern per line. Multiple F: lines acceptable.
> + N: Files and directories with regex patterns.
> +K: [^a-z]tegra all files whose patch contains the word tegra
N: not K:
> +One pattern per line. Multiple N: lines acceptable.
> X: Files and directories that are NOT maintained, same rules as F:
> Files exclusions are tested before file matches.
> Can be useful for excluding a specific subdirectory, for instance:
and remove the K: descriptions that show filename too.
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index ce4cc83..27dc5cb 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -611,7 +611,7 @@ sub get_maintainers {
> $hash{$tvi} = $value_pd;
> }
> }
> - } elsif ($type eq 'K') {
> + } elsif ($type eq 'K' || $type eq 'N') {
> if ($file =~ m/$value/x) {
> $hash{$tvi} = 0;
> }
Remove K: It has no value here.
[Bug 61883] wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 --- Comment #3 from Victor Aur?lio --- Created attachment 76025 --> https://bugs.freedesktop.org/attachment.cgi?id=76025&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/d2cae4e5/attachment.html>
[Bug 61883] wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 --- Comment #2 from Victor Aur?lio --- Created attachment 76024 --> https://bugs.freedesktop.org/attachment.cgi?id=76024&action=edit full dmesg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/aad052b5/attachment.html>
[PATCH 2/2] MAINTAINERS: tegra: match related files using N: not K:
From: Stephen Warren This causes the regex to be applied to filenames only, and not patch or file content (such as comments). This should prevent e.g. drivers/gpu/drm/nouveau/nv50_display.c from matching this entry. Reported-by: Marcin Slusarz Signed-off-by: Stephen Warren --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1671842..8b986e2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7851,7 +7851,7 @@ L:linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported -K: (?i)[^a-z]tegra +N: [^a-z]tegra TEHUTI ETHERNET DRIVER M: Andy Gospodarek -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 6 March 2013 14:12, Inki Dae wrote:
> 2013/3/1 Vikas Sajjan :
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing is done only if 'dev.of_node'
>> exists and the NON-DT logic is still maintained under the 'else' part.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> Acked-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..e323cf9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>>
>> +#include
>> #include
>> #include
>>
>> @@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
>>
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>
>> - pdata = pdev->dev.platform_data;
>> - if (!pdata) {
>> - dev_err(dev, "no platform data specified\n");
>> - return -EINVAL;
>> + if (pdev->dev.of_node) {
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + DRM_ERROR("memory allocation for pdata failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
>> + OF_USE_NATIVE_MODE);
>
> Add "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" to
> drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
> selected, these two configs should also be selected.
>
Sure. Will add and resend.
> Thanks,
> Inki Dae
>
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
>> ret);
>> + return ret;
>> + }
>> + } else {
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + DRM_ERROR("no platform data specified\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> panel = &pdata->panel;
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thanks and Regards
Vikas Sajjan
[PATCH 1/2] get_maintainer: create filename-only regex match type
From: Stephen Warren
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
match filenames"), but without the disadvantage that "random" file
content, such as comments, will ever match the regex.
Suggested-by: Joe Perches
Signed-off-by: Stephen Warren
---
MAINTAINERS |3 +++
scripts/get_maintainer.pl |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..1671842 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ K: [^a-z]tegra all files whose patch contains the word tegra
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..27dc5cb 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'K' || $type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61529] [ATI RV710] r600_pcie_gart_tlb_flush+0xf5/0x110
https://bugs.freedesktop.org/show_bug.cgi?id=61529 Michel D?nzer changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/376b2e27/attachment.html>
[Bug 61446] [r600-llvm + mesa] on Evergreen & compiz 0.8: exposé-like feature & zoom lead to black screen
https://bugs.freedesktop.org/show_bug.cgi?id=61446 --- Comment #2 from Michel D?nzer --- Does it work better if you switch Mesa to the 9.1 branch or LLVM to the main trunk? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/79ddb468/attachment.html>
Re: [PATCH] drm: fix new kernel-doc warnings
On 03/05/2013 11:08:16 AM, Randy Dunlap wrote: From: Randy Dunlap Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to kernel-doc to match the rest of the file's documentation. I've been feeding this stuff through triv...@kernel.org. (I just got my kernel.org account re-enabled yesterday, and hope to set up a tree to feed into linux-next this weekend, but this is probably still trivial@ material anyway since it's scattered around the tree outside of the documentation directory.) Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/edid: kernel-doc minimal cleanup
On 10:27-20130304, Nishanth Menon wrote: > On 18:09-20130302, Paul Menzel wrote: > > Am Freitag, den 01.03.2013, 08:00 -0600 schrieb Nishanth Menon: > > > Some basic cleanups for kernel-doc errors or missing documentation > > > parameters. [..] > > > index c194f4e..bd864b5 100644 > > > --- a/drivers/gpu/drm/drm_edid.c > > > +++ b/drivers/gpu/drm/drm_edid.c > > > @@ -982,14 +982,14 @@ EXPORT_SYMBOL(drm_edid_is_valid); > > > > > > #define DDC_SEGMENT_ADDR 0x30 > > > /** > > > - * Get EDID information via I2C. > > > - * > > > - * \param adapter : i2c device adaptor > > > - * \param buf : EDID data buffer to be filled > > > - * \param len : EDID data buffer length > > > - * \return 0 on success or -1 on failure. > > > + * drm_do_probe_ddc_edid() - Get EDID information via I2C. > > > > Some already existing entries do not use »()« behind the function name > > in the comment. Not sure what the correct way is though. > I followed the format as in: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n55 just a ping to confirm if there are any further changes required? -- Regards, Nishanth Menon ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 6 March 2013 14:12, Inki Dae wrote:
> 2013/3/1 Vikas Sajjan :
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing is done only if 'dev.of_node'
>> exists and the NON-DT logic is still maintained under the 'else' part.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> Acked-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..e323cf9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>>
>> +#include
>> #include
>> #include
>>
>> @@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
>>
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>
>> - pdata = pdev->dev.platform_data;
>> - if (!pdata) {
>> - dev_err(dev, "no platform data specified\n");
>> - return -EINVAL;
>> + if (pdev->dev.of_node) {
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + DRM_ERROR("memory allocation for pdata failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
>> + OF_USE_NATIVE_MODE);
>
> Add "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" to
> drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
> selected, these two configs should also be selected.
>
Sure. Will add and resend.
> Thanks,
> Inki Dae
>
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
>> ret);
>> + return ret;
>> + }
>> + } else {
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + DRM_ERROR("no platform data specified\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> panel = &pdata->panel;
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] mgag200: some cleanup and a fix for corrupted output
On Tue, Feb 26, 2013 at 10:52:55AM -0500, Christopher Harvey wrote: > Patches 1 to 4 are just cleanup. Maybe these should should be rolled > into one patch? > > Patch 5 is a bit more complicated. > On cards with very little video memory, (e.g 8MB) higher resolutions > at 32bit framebuffer depths will get corrupted because the required > memory is larger than what the framebuffer has. DRM has "max_height" > and "max_width" but no "max_bytes" for limiting resolutions, so the > patch is a little hacky. The first for loop tries to associate a > connector with the mode being tested. From the connector I can get the > bpp if the user specified one on the video= commandline. After that I > do 2 things: > 1) Invalidate the requested mode from the video= parameter > 2) Return MODE_BAD if the framebuffer would be too large > I feel this patch plays with structures it shouldn't have to touch to > get the bpp. An alternative fix would be to include a "max_bytes" in > the DRM core and then do these checks there. > > I'm also wondering, did I miss the 3.9.0 merge window? > > Thanks, > > Christopher Harvey (5): > drm/mgag200: Cleanup: Remove pointless call to drm_fb_get_bpp_depth > drm/mgag200: Cleanup: 'fbdev_list' in 'struct mga_fbdev' is not used > drm/mgag200: Cleanup: Pass driver specific mga_device in driver > functions > drm/mgag200: Cleanup: Remove extra variable assigns > drm/mgag200: Reject modes that are too big for VRAM > > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - > drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- > drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- > drivers/gpu/drm/mgag200/mgag200_mode.c | 34 > ++ > 4 files changed, 30 insertions(+), 10 deletions(-) > > -- > 1.7.12.4 > Ping. I've got more patches queuing up. Should I re-submit these along with the new ones? So far I've only gotten commit message feedback. -Chris
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #9 from Alex Deucher --- Possibly a duplicate of bug 59592 or bug 60848. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 Alex Deucher changed: What|Removed |Added Summary|[r600g] GPU lockup when |[r600g] GPU lockup when |playing WoW with HD6450 and |playing WoW with HD6450 |3.8.1 kernel|with htile enabled -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 1/4] drm: Add struct drm_region and assorted utility functions
On Wed, Mar 06, 2013 at 10:56:05AM +, Chris Wilson wrote: > On Thu, Feb 21, 2013 at 11:35:00PM +0200, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > struct drm_region represents a two dimensional region. The utility > > functions are there to help driver writers. > > > > v2: Moved the region stuff into its own file, made the smaller funcs > > static inline, used 64bit maths in the scaled clipping function to > > avoid overflows (instead it will saturate to INT_MIN or INT_MAX). > > > > Signed-off-by: Ville Syrj?l? > > My criticisms here are mainly that the function names are different than > what I am used to for a region API. Namely drm_region_clip, > drm_region_subsample would more conventionally be drm_region_intersect, > drm_region_downscale. And that a region to me is an ordered list of > rectangles, whereas here you just have a single rectangle. I'm fine with renaming stuff. Ideally the names should be so obvious that people never have to look at the documentation. -- Ville Syrj?l? Intel OTC
Re: [PATCH] mgag200: some cleanup and a fix for corrupted output
On Thu, Mar 7, 2013 at 4:51 AM, Christopher Harvey wrote: > On Tue, Feb 26, 2013 at 10:52:55AM -0500, Christopher Harvey wrote: >> Patches 1 to 4 are just cleanup. Maybe these should should be rolled >> into one patch? >> >> Patch 5 is a bit more complicated. >> On cards with very little video memory, (e.g 8MB) higher resolutions >> at 32bit framebuffer depths will get corrupted because the required >> memory is larger than what the framebuffer has. DRM has "max_height" >> and "max_width" but no "max_bytes" for limiting resolutions, so the >> patch is a little hacky. The first for loop tries to associate a >> connector with the mode being tested. From the connector I can get the >> bpp if the user specified one on the video= commandline. After that I >> do 2 things: >> 1) Invalidate the requested mode from the video= parameter >> 2) Return MODE_BAD if the framebuffer would be too large >> I feel this patch plays with structures it shouldn't have to touch to >> get the bpp. An alternative fix would be to include a "max_bytes" in >> the DRM core and then do these checks there. >> >> I'm also wondering, did I miss the 3.9.0 merge window? >> >> Thanks, >> >> Christopher Harvey (5): >> drm/mgag200: Cleanup: Remove pointless call to drm_fb_get_bpp_depth >> drm/mgag200: Cleanup: 'fbdev_list' in 'struct mga_fbdev' is not used >> drm/mgag200: Cleanup: Pass driver specific mga_device in driver >> functions >> drm/mgag200: Cleanup: Remove extra variable assigns >> drm/mgag200: Reject modes that are too big for VRAM >> >> drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - >> drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- >> drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- >> drivers/gpu/drm/mgag200/mgag200_mode.c | 34 >> ++ >> 4 files changed, 30 insertions(+), 10 deletions(-) >> >> -- >> 1.7.12.4 >> > > Ping. > > I've got more patches queuing up. Should I re-submit these along with > the new ones? > > So far I've only gotten commit message feedback. > Sorry been off sick, and this fell off my radar, I'll get to it today, the first 4 seem fine, I'll check the last one today., they all look like fixes so I can probably merge them at any time. Thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau lockdep splat
On Wed, 2013-03-06 at 12:31 -0700, Stephen Warren wrote:
> On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
> > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
> >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> >>> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> >>
> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
> >> ...
> >> linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
> >>
> >> Maybe get_maintainer.pl patterns need correction...
> >
> > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer:
> > allow
> > keywords to match filenames") of get_maintainer.pl which now can look at
> > file
> > contents...
>
> get_maintainer.pl could always look at file contents IIRC. The change
> was that I added keyword "tegra" to the Tegra section that now matches
> this file's contents.
>
> ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
>
> ... might be a better invocation, although perhaps I should add an
> explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS.
Another option might be avoid overloading the "K:"
entry and use a different letter for the file name
pattern match (maybe "N") and avoid looking for
tegra in the file or patch without another specific
"K:" keyword match.
Maybe:
---
MAINTAINERS | 10 +++---
scripts/get_maintainer.pl | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..76e0223 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,10 +96,14 @@ Descriptions of section entries:
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
+ N: Filename wildcard pattern match, for instance:
+ N: (?i)[^a-z]tegra
+ matches any filename with case insensitive "tegra" but not
+ any other word like integrate
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
+ matches patch or file content, that contain
"of_get_profile"
K: \b(printk|pr_(info|err))\b
matches patch or file content, or filenames, that contain one or
@@ -7866,7 +7870,7 @@ L:linux-te...@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-K: (?i)[^a-z]tegra
+N: (?i)[^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm-intel-fixes
Hi Dave, A bunch of fixes, nothing truely horrible: - Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs and subsequent fallout (Paulo) - Fixup off-by-one in our hsw id table (Kenneth) - Fixup ilk rc6 support (disabled by default), regression introduced in 3.8 - g4x plane w/a from Egbert Eich - gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson - Workaround dying ivb machines with less aggressive rc6 values (Stéphane Marchesin) Most of the patches are cc: stable, one with a note about an additional patch which needs to be backported as prerequisite. Cheers, Daniel The following changes since commit 202adf4b9f5957b26a1cb97267d78e0edb319c5e: drm/i915: Revert hdmi HDP pin checks (2013-02-22 13:04:33 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to f40ebd6bcbbd0d30591f42dc16be52b5086a366b: drm/i915: Turn off hsync and vsync on ADPA when disabling crt (2013-03-06 18:03:07 +0100) Daniel Vetter (1): drm/i915: enable irqs earlier when resuming Egbert Eich (1): DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. Kenneth Graunke (1): drm/i915: Fix Haswell/CRW PCI IDs. Patrik Jakobsson (2): drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits drm/i915: Turn off hsync and vsync on ADPA when disabling crt Paulo Zanoni (2): drm/i915: wait_event_timeout's timeout is in jiffies drm/i915: also disable south interrupts when handling them Stéphane Marchesin (1): drm/i915: Increase the RC6p threshold. Syam Sidhardhan (1): drm/i915: Fix missing variable initilization Ville Syrjälä (1): drm/i915: Don't clobber crtc->fb when queue_flip fails drivers/gpu/drm/i915/i915_drv.c | 25 --- drivers/gpu/drm/i915/i915_irq.c | 26 ++-- drivers/gpu/drm/i915/i915_reg.h |4 ++-- drivers/gpu/drm/i915/intel_crt.c |2 +- drivers/gpu/drm/i915/intel_ddi.c |2 +- drivers/gpu/drm/i915/intel_display.c | 37 +++--- drivers/gpu/drm/i915/intel_dp.c |3 ++- drivers/gpu/drm/i915/intel_pm.c |2 +- 8 files changed, 79 insertions(+), 22 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/exynos: fimd: calculate the correct address offset
Dear Leela, thank you for your patch. Am Mittwoch, den 06.03.2013, 00:20 -0500 schrieb Leela Krishna Amudala: > Calculate the correct address offset values for alpha and color key > control registers and clear size control register for window 0 1. The *and* implies this should be split up into two patches, right? 2. Why was it incorrect before and why is it correct now? 3. What were the indications of the incorrect calculation (command line to check?)? How can be verified that they are correct now? Could you please send two patches with an updated commit message and the comments below fixed? > Signed-off-by: Leela Krishna Amudala > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index 9537761..78bab4a 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -38,21 +38,22 @@ > /* position control register for hardware window 0, 2 ~ 4.*/ > #define VIDOSD_A(win)(VIDOSD_BASE + 0x00 + (win) * 16) > #define VIDOSD_B(win)(VIDOSD_BASE + 0x04 + (win) * 16) > +/* size control register is avaliable only for windows 0, 1 and 2. */ *available > /* size control register for hardware window 0. */ > #define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08) > -/* alpha control register for hardware window 1 ~ 4. */ > -#define VIDOSD_C(win)(VIDOSD_BASE + 0x18 + (win) * 16) > -/* size control register for hardware window 1 ~ 4. */ > +/* size control register for hardware window 1 ~ 2. */ > #define VIDOSD_D(win)(VIDOSD_BASE + 0x0C + (win) * 16) > +/* alpha control register for hardware window 1 ~ 4. */ > +#define VIDOSD_C(win)(VIDOSD_BASE + 0x08 + (win) * 16) The commit message should explain why 0x18 is wrong and 0x08 is right. > #define VIDWx_BUF_START(win, buf)(VIDW_BUF_START(buf) + (win) * 8) > #define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8) > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4) > > /* color key control register for hardware window 1 ~ 4. */ > -#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8)) > +#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8)) > /* color key value register for hardware window 1 ~ 4. */ > -#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8)) > +#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8)) Same here. > /* FIMD has totally five hardware windows. */ > #define WINDOWS_NR 5 > @@ -782,11 +783,14 @@ static void fimd_clear_win(struct fimd_context *ctx, > int win) > writel(0, ctx->regs + WINCON(win)); > writel(0, ctx->regs + VIDOSD_A(win)); > writel(0, ctx->regs + VIDOSD_B(win)); > - writel(0, ctx->regs + VIDOSD_C(win)); > + if (win != 0) > + writel(0, ctx->regs + VIDOSD_C(win)); > > if (win == 1 || win == 2) > writel(0, ctx->regs + VIDOSD_D(win)); > > + if (win == 0) > + writel(0, ctx->regs + VIDOSD_C_SIZE_W0); Separate patch? Use a `switch` statement (or (else if`)? > val = readl(ctx->regs + SHADOWCON); > val &= ~SHADOWCON_WINx_PROTECT(win); > writel(val, ctx->regs + SHADOWCON); Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #8 from Chris Rankin --- (In reply to comment #7) > Does disabling htile support help? Set env var R600_HYPERZ=0 Yes, this prevents the GPU from locking up. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau lockdep splat
On 03/06/2013 12:14 PM, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: >>> Dropping Tegra ML, it's not the place where Nouveau mails should go. >> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c >> ... >> linux-tegra at vger.kernel.org (open list:TEGRA SUPPORT) >> >> Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword "tegra" to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS.
nouveau lockdep splat
On Wed, 2013-03-06 at 12:31 -0700, Stephen Warren wrote:
> On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
> > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
> >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> >>> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> >>
> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
> >> ...
> >> linux-tegra at vger.kernel.org (open list:TEGRA SUPPORT)
> >>
> >> Maybe get_maintainer.pl patterns need correction...
> >
> > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer:
> > allow
> > keywords to match filenames") of get_maintainer.pl which now can look at
> > file
> > contents...
>
> get_maintainer.pl could always look at file contents IIRC. The change
> was that I added keyword "tegra" to the Tegra section that now matches
> this file's contents.
>
> ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
>
> ... might be a better invocation, although perhaps I should add an
> explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS.
Another option might be avoid overloading the "K:"
entry and use a different letter for the file name
pattern match (maybe "N") and avoid looking for
tegra in the file or patch without another specific
"K:" keyword match.
Maybe:
---
MAINTAINERS | 10 +++---
scripts/get_maintainer.pl | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..76e0223 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,10 +96,14 @@ Descriptions of section entries:
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
+ N: Filename wildcard pattern match, for instance:
+ N: (?i)[^a-z]tegra
+ matches any filename with case insensitive "tegra" but not
+ any other word like integrate
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
+ matches patch or file content, that contain
"of_get_profile"
K: \b(printk|pr_(info|err))\b
matches patch or file content, or filenames, that contain one or
@@ -7866,7 +7870,7 @@ L:linux-tegra at vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-K: (?i)[^a-z]tegra
+N: (?i)[^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote: > get_maintainer.pl could always look at file contents IIRC. The change > was that I added keyword "tegra" to the Tegra section that now matches > this file's contents. > > ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau > > ... might be a better invocation, although perhaps I should add an > explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS. No, you should add a pattern which matches only tegra. If there's no such pattern, you should simply drop the "K:" thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > > ... > > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > > > Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... > > TEGRA SUPPORT > M:Stephen Warren > L:linux-te...@vger.kernel.org > Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ > T:git > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > S:Supported > K:(?i)[^a-z]tegra > > Note the last line and this: > > $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c > u32 rekey = 56; /* binary driver, and tegra constant */ > max_ac_packet -= 18; /* constant from tegra */ > > Fun. Yeah, and a lot of it, thanks for digging this out. So obviously this regex is a bit... unfortunate. Although the idea of grepping the files for unique patterns is not bad, I have to admit. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau lockdep splat
On 03/06/2013 12:14 PM, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: >>> Dropping Tegra ML, it's not the place where Nouveau mails should go. >> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c >> ... >> linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) >> >> Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword "tegra" to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: v3.9-rc1 instability on Chromebook Pixel with gmbus irq
Hi Daniel, I've just tried drm-intel-fixes merged into v3.9-rc1, and so far it's looking good. No suspicious timeouts. Thanks for the quick response! Benson On Wed, Mar 6, 2013 at 12:14 AM, Daniel Vetter wrote: > On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: >> I'm working on touch devices Chromium OS, and I've noticed a >> regression between 3.8 and 3.9-rc1, which was posted yesterday. >> >> The hardware in question is a Chromebook Pixel. For this device, we >> have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s >> touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The >> touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. >> >> I was testing v3.9-rc1 on the Pixel and the touchscreen driver is >> being returned -110 (-ETIMEDOUT) on an i2c_transfer after several >> seconds of both touch devices working correctly. At the time of the >> failure, there are no error messages from GMBUS that I can see, but >> the bus never recovers. I can keep interacting with the touchscreen or >> touchpad, and the interrupts trigger reads, but all subsequent reads >> return -110. >> >> I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus >> irq support was merged. After bisecting, I found that this commit >> seems to be causing the timeout problem. Reverting it makes the >> problem go away, and the bus is stable. > > Can you please retest with latest drm-intel-fixes merged into -rc1? > Paulo's patch fixes a race in handling PCH interrupts (where the gmbus > hw is) which matches rather well with your description here. > > Thanks, Daniel > >> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 >> Author: Daniel Vetter >> Date: Sat Dec 1 13:53:46 2012 +0100 >> >> drm/i915: use gmbus irq to wait for gmbus idle >> >> GMBUS_ACTIVE has inverted sense and so doesn't fit into the >> wait_hw_status helper, hence create a new gmbus_wait_idle functions. >> Also, we only care about the idle irq event and nothing else, which >> allows us to use the wait_event_timeout helper directly without >> jumping through hoops to catch NAKs. >> >> Since gen2/3 don't have gmbus interrupts, handle them separately with >> the old wait_for macro. >> >> This shaves another few ms off reading EDID from a hdmi screen on my >> testbox here. EDID reading with interrupt driven gmbus is now as fast >> as with busy-looping gmbus at 28 ms here (with negligible cpu >> overhead). >> >> Reviewed-by: Imre Deak >> Signed-off-by: Daniel Vetter >> >> >> Is there anything I can do to help debug this some more? >> >> -- >> Benson Leung >> Software Engineer, Chrom* OS >> ble...@chromium.org > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
v3.9-rc1 instability on Chromebook Pixel with gmbus irq
Hi Daniel, I've just tried drm-intel-fixes merged into v3.9-rc1, and so far it's looking good. No suspicious timeouts. Thanks for the quick response! Benson On Wed, Mar 6, 2013 at 12:14 AM, Daniel Vetter wrote: > On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: >> I'm working on touch devices Chromium OS, and I've noticed a >> regression between 3.8 and 3.9-rc1, which was posted yesterday. >> >> The hardware in question is a Chromebook Pixel. For this device, we >> have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s >> touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The >> touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. >> >> I was testing v3.9-rc1 on the Pixel and the touchscreen driver is >> being returned -110 (-ETIMEDOUT) on an i2c_transfer after several >> seconds of both touch devices working correctly. At the time of the >> failure, there are no error messages from GMBUS that I can see, but >> the bus never recovers. I can keep interacting with the touchscreen or >> touchpad, and the interrupts trigger reads, but all subsequent reads >> return -110. >> >> I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus >> irq support was merged. After bisecting, I found that this commit >> seems to be causing the timeout problem. Reverting it makes the >> problem go away, and the bus is stable. > > Can you please retest with latest drm-intel-fixes merged into -rc1? > Paulo's patch fixes a race in handling PCH interrupts (where the gmbus > hw is) which matches rather well with your description here. > > Thanks, Daniel > >> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 >> Author: Daniel Vetter >> Date: Sat Dec 1 13:53:46 2012 +0100 >> >> drm/i915: use gmbus irq to wait for gmbus idle >> >> GMBUS_ACTIVE has inverted sense and so doesn't fit into the >> wait_hw_status helper, hence create a new gmbus_wait_idle functions. >> Also, we only care about the idle irq event and nothing else, which >> allows us to use the wait_event_timeout helper directly without >> jumping through hoops to catch NAKs. >> >> Since gen2/3 don't have gmbus interrupts, handle them separately with >> the old wait_for macro. >> >> This shaves another few ms off reading EDID from a hdmi screen on my >> testbox here. EDID reading with interrupt driven gmbus is now as fast >> as with busy-looping gmbus at 28 ms here (with negligible cpu >> overhead). >> >> Reviewed-by: Imre Deak >> Signed-off-by: Daniel Vetter >> >> >> Is there anything I can do to help debug this some more? >> >> -- >> Benson Leung >> Software Engineer, Chrom* OS >> bleung at chromium.org > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Benson Leung Software Engineer, Chrom* OS bleung at chromium.org
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #10 from Michel D?nzer --- The segfault looks like some kind of LLVM issue on shutdown, we can probably ignore that for now. The real problem is that your GPU hangs even while running the trivial shaders egltri_screen uses. Alex, could it be we're trying to use a missing/disabled shader engine or something like that? Hristo, can you also attach the kernel output corresponding to egltri_screen? I expect it'll be basically the same as for starting X, but just in case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/99a0a52c/attachment.html>
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > ... > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow keywords to match filenames") of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Radeon HDMI question
Hi, 2013-03-06 10:50 keltez?ssel, Christian K?nig ?rta: > Hi, > > Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan: >> OK, a new problem now with 5.1 sound, it can be reproduced. >> >> I still have the same setup as described above. >> I started watching a video. Initially, HDMI audio just works nicely. >> I had to do something else so I paused Xine. >> During this time, X went to DPMS blanking. >> The TV switches itself off to save power if it sees no input. >> So, after waking up the monitor from DPMS and turning on the >> TV again, I pressed play on the video. It continues playing but >> without the sound. >> >> It seems to be the same with Linux 3.8.1 and earlier kernels. > > Does that also happen with just plain stereo playback? If yes then this is a > bug with > restoring the correct audio settings after DPMS blanking. I will try to test it later, also with mplayer. > > If not (and that's what I think is more likely) than that's because DPMS > blanking causes > a desync between xine and your TV. Unfortunately there isn't much we can do > about it > (maybe expect disabling DPMS all together), Cause from the hardware point of > view it's > just not possible to tell the audio codec to stop playback because the > display isn't > turned on any more. > > Does it work when you close xine and restart it? If yes than it might be > worth a try to > tell xine to close and reopen the audio device on pause/restart of playback. Unfortunately, after HDMI audio goes away, restarting Xine doesn't help at all. The audio driver is pulseaudio in Xine, so I can switch between the built-in audio with stereo speakers and the HDMI output and the speakers produce the expected sounds. Also, the vumeter in pavucontrol shows that sound is generated from Xine, no matter which hardware is selected and even when HDMI is selected but there is no sound on the TV after it went out. The sound only comes back when I reboot the computer. > >> >> There is nothing in dmesg, only: >> >> ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128 >> ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0 > > That's unrelated, the alsa driver just assumes the standard ELD informations > for the > HDMI audio codec, but AMD hardware is actually not using it. > > The real solution to your problem is to finally implement 8 channel PCM > audio, instead > of just using this ugly 5.1 pass through workaround. But so far nobody had > time to do so. Thanks for the information. Best regards, Zolt?n B?sz?rm?nyi
[Intel-gfx] [PATCH 1/4] drm: Add struct drm_region and assorted utility functions
On Thu, Feb 21, 2013 at 11:35:00PM +0200, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > struct drm_region represents a two dimensional region. The utility > functions are there to help driver writers. > > v2: Moved the region stuff into its own file, made the smaller funcs > static inline, used 64bit maths in the scaled clipping function to > avoid overflows (instead it will saturate to INT_MIN or INT_MAX). > > Signed-off-by: Ville Syrj?l? My criticisms here are mainly that the function names are different than what I am used to for a region API. Namely drm_region_clip, drm_region_subsample would more conventionally be drm_region_intersect, drm_region_downscale. And that a region to me is an ordered list of rectangles, whereas here you just have a single rectangle. -Chris -- Chris Wilson, Intel Open Source Technology Centre
Radeon HDMI question
Hi, Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan: > OK, a new problem now with 5.1 sound, it can be reproduced. > > I still have the same setup as described above. > I started watching a video. Initially, HDMI audio just works nicely. > I had to do something else so I paused Xine. > During this time, X went to DPMS blanking. > The TV switches itself off to save power if it sees no input. > So, after waking up the monitor from DPMS and turning on the > TV again, I pressed play on the video. It continues playing but > without the sound. > > It seems to be the same with Linux 3.8.1 and earlier kernels. Does that also happen with just plain stereo playback? If yes then this is a bug with restoring the correct audio settings after DPMS blanking. If not (and that's what I think is more likely) than that's because DPMS blanking causes a desync between xine and your TV. Unfortunately there isn't much we can do about it (maybe expect disabling DPMS all together), Cause from the hardware point of view it's just not possible to tell the audio codec to stop playback because the display isn't turned on any more. Does it work when you close xine and restart it? If yes than it might be worth a try to tell xine to close and reopen the audio device on pause/restart of playback. > > There is nothing in dmesg, only: > > ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128 > ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0 That's unrelated, the alsa driver just assumes the standard ELD informations for the HDMI audio codec, but AMD hardware is actually not using it. The real solution to your problem is to finally implement 8 channel PCM audio, instead of just using this ugly 5.1 pass through workaround. But so far nobody had time to do so. Christian.
Re: [PATCH] mgag200: some cleanup and a fix for corrupted output
On Tue, Feb 26, 2013 at 10:52:55AM -0500, Christopher Harvey wrote: > Patches 1 to 4 are just cleanup. Maybe these should should be rolled > into one patch? > > Patch 5 is a bit more complicated. > On cards with very little video memory, (e.g 8MB) higher resolutions > at 32bit framebuffer depths will get corrupted because the required > memory is larger than what the framebuffer has. DRM has "max_height" > and "max_width" but no "max_bytes" for limiting resolutions, so the > patch is a little hacky. The first for loop tries to associate a > connector with the mode being tested. From the connector I can get the > bpp if the user specified one on the video= commandline. After that I > do 2 things: > 1) Invalidate the requested mode from the video= parameter > 2) Return MODE_BAD if the framebuffer would be too large > I feel this patch plays with structures it shouldn't have to touch to > get the bpp. An alternative fix would be to include a "max_bytes" in > the DRM core and then do these checks there. > > I'm also wondering, did I miss the 3.9.0 merge window? > > Thanks, > > Christopher Harvey (5): > drm/mgag200: Cleanup: Remove pointless call to drm_fb_get_bpp_depth > drm/mgag200: Cleanup: 'fbdev_list' in 'struct mga_fbdev' is not used > drm/mgag200: Cleanup: Pass driver specific mga_device in driver > functions > drm/mgag200: Cleanup: Remove extra variable assigns > drm/mgag200: Reject modes that are too big for VRAM > > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - > drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- > drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- > drivers/gpu/drm/mgag200/mgag200_mode.c | 34 > ++ > 4 files changed, 30 insertions(+), 10 deletions(-) > > -- > 1.7.12.4 > Ping. I've got more patches queuing up. Should I re-submit these along with the new ones? So far I've only gotten commit message feedback. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
v3.9-rc1 instability on Chromebook Pixel with gmbus irq
On Wed, 06 Mar 2013, Daniel Vetter wrote: > On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: >> I'm working on touch devices Chromium OS, and I've noticed a >> regression between 3.8 and 3.9-rc1, which was posted yesterday. >> >> The hardware in question is a Chromebook Pixel. For this device, we >> have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s >> touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The >> touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. >> >> I was testing v3.9-rc1 on the Pixel and the touchscreen driver is >> being returned -110 (-ETIMEDOUT) on an i2c_transfer after several >> seconds of both touch devices working correctly. At the time of the >> failure, there are no error messages from GMBUS that I can see, but >> the bus never recovers. I can keep interacting with the touchscreen or >> touchpad, and the interrupts trigger reads, but all subsequent reads >> return -110. >> >> I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus >> irq support was merged. After bisecting, I found that this commit >> seems to be causing the timeout problem. Reverting it makes the >> problem go away, and the bus is stable. > > Can you please retest with latest drm-intel-fixes merged into -rc1? > Paulo's patch fixes a race in handling PCH interrupts (where the gmbus > hw is) which matches rather well with your description here. Also, some error paths only print with debug on. Did you try with drm.debug=0xe? BR, Jani. > > Thanks, Daniel > >> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 >> Author: Daniel Vetter >> Date: Sat Dec 1 13:53:46 2012 +0100 >> >> drm/i915: use gmbus irq to wait for gmbus idle >> >> GMBUS_ACTIVE has inverted sense and so doesn't fit into the >> wait_hw_status helper, hence create a new gmbus_wait_idle functions. >> Also, we only care about the idle irq event and nothing else, which >> allows us to use the wait_event_timeout helper directly without >> jumping through hoops to catch NAKs. >> >> Since gen2/3 don't have gmbus interrupts, handle them separately with >> the old wait_for macro. >> >> This shaves another few ms off reading EDID from a hdmi screen on my >> testbox here. EDID reading with interrupt driven gmbus is now as fast >> as with busy-looping gmbus at 28 ms here (with negligible cpu >> overhead). >> >> Reviewed-by: Imre Deak >> Signed-off-by: Daniel Vetter >> >> >> Is there anything I can do to help debug this some more? >> >> -- >> Benson Leung >> Software Engineer, Chrom* OS >> bleung at chromium.org > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fimd: calculate the correct address offset
Hi On Tue, Mar 5, 2013 at 5:47 PM, Joonyoung Shim wrote: > On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote: >> >> Hi, >> >> On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim >> wrote: >>> >>> Hi Leela, >>> >>> >>> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: Calculate the correct address offset values for alpha and color key control registers Signed-off-by: Leela Krishna Amudala --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..71f4176 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -41,7 +41,7 @@ /* size control register for hardware window 0. */ #define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08) >>> >>> >>> How about just use VIDOSD_C(win) instead of this macro for size control >>> register of windows0? >>> I think it's better if writes comments properly here. >>> >> Then in that case >> VIDOSD_C(0) will refer to Window 0 Size Control register >> VIDOSD_C(1) will refer to Window 1 Alpha Control register >> VIDOSD_C(2) will refer to Window 2 Alpha Control register >> VIDOSD_C(3) will refer to Window 3 Alpha Control register >> VIDOSD_C(4) will refer to Window 4 Alpha Control register >> Which leads to a confusion. > > > Because of confusion, we need correct comments. > Added appropriate comments and posted V2 > >> IMHO keeping VIDOSD_C_SIZE_W0 separate for win 0 is good. >> >> Best Wishes, >> Leela Krishna Amudala >> /* alpha control register for hardware window 1 ~ 4. */ -#define VIDOSD_C(win) (VIDOSD_BASE + 0x18 + (win) * 16) +#define VIDOSD_C(win) (VIDOSD_BASE + 0x08 + (win) * 16) /* size control register for hardware window 1 ~ 4. */ #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16) @@ -50,9 +50,9 @@ #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4) /* color key control register for hardware window 1 ~ 4. */ -#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8)) +#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8)) /* color key value register for hardware window 1 ~ 4. */ -#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8)) +#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8)) /* FIMD has totally five hardware windows. */ #define WINDOWS_NR5 @@ -782,7 +782,8 @@ static void fimd_clear_win(struct fimd_context *ctx, int win) writel(0, ctx->regs + WINCON(win)); writel(0, ctx->regs + VIDOSD_A(win)); writel(0, ctx->regs + VIDOSD_B(win)); - writel(0, ctx->regs + VIDOSD_C(win)); + if (win != 0) + writel(0, ctx->regs + VIDOSD_C(win)); > > > Then you need also to initialize VIDOSD_C_SIZE_W0 register. > Initialized and posted V2 Best Wishes, Leela Krishna Amudala. > >>> >>> If use VIDOSD_C(win) macro for size control register of windows0 then >>> this >>> fix will be unnecessary. >>> >>> Thanks. >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/exynos: fimd: calculate the correct address offset
Dear Leela, thank you for your patch. Am Mittwoch, den 06.03.2013, 00:20 -0500 schrieb Leela Krishna Amudala: > Calculate the correct address offset values for alpha and color key > control registers and clear size control register for window 0 1. The *and* implies this should be split up into two patches, right? 2. Why was it incorrect before and why is it correct now? 3. What were the indications of the incorrect calculation (command line to check?)? How can be verified that they are correct now? Could you please send two patches with an updated commit message and the comments below fixed? > Signed-off-by: Leela Krishna Amudala > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index 9537761..78bab4a 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -38,21 +38,22 @@ > /* position control register for hardware window 0, 2 ~ 4.*/ > #define VIDOSD_A(win)(VIDOSD_BASE + 0x00 + (win) * 16) > #define VIDOSD_B(win)(VIDOSD_BASE + 0x04 + (win) * 16) > +/* size control register is avaliable only for windows 0, 1 and 2. */ *available > /* size control register for hardware window 0. */ > #define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08) > -/* alpha control register for hardware window 1 ~ 4. */ > -#define VIDOSD_C(win)(VIDOSD_BASE + 0x18 + (win) * 16) > -/* size control register for hardware window 1 ~ 4. */ > +/* size control register for hardware window 1 ~ 2. */ > #define VIDOSD_D(win)(VIDOSD_BASE + 0x0C + (win) * 16) > +/* alpha control register for hardware window 1 ~ 4. */ > +#define VIDOSD_C(win)(VIDOSD_BASE + 0x08 + (win) * 16) The commit message should explain why 0x18 is wrong and 0x08 is right. > #define VIDWx_BUF_START(win, buf)(VIDW_BUF_START(buf) + (win) * 8) > #define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8) > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4) > > /* color key control register for hardware window 1 ~ 4. */ > -#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8)) > +#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8)) > /* color key value register for hardware window 1 ~ 4. */ > -#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8)) > +#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8)) Same here. > /* FIMD has totally five hardware windows. */ > #define WINDOWS_NR 5 > @@ -782,11 +783,14 @@ static void fimd_clear_win(struct fimd_context *ctx, > int win) > writel(0, ctx->regs + WINCON(win)); > writel(0, ctx->regs + VIDOSD_A(win)); > writel(0, ctx->regs + VIDOSD_B(win)); > - writel(0, ctx->regs + VIDOSD_C(win)); > + if (win != 0) > + writel(0, ctx->regs + VIDOSD_C(win)); > > if (win == 1 || win == 2) > writel(0, ctx->regs + VIDOSD_D(win)); > > + if (win == 0) > + writel(0, ctx->regs + VIDOSD_C_SIZE_W0); Separate patch? Use a `switch` statement (or (else if`)? > val = readl(ctx->regs + SHADOWCON); > val &= ~SHADOWCON_WINx_PROTECT(win); > writel(val, ctx->regs + SHADOWCON); Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/4d6d3508/attachment.pgp>
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 Daniel Kiper changed: What|Removed |Added CC||dkiper at net-space.pl --- Comment #22 from Daniel Kiper 2013-03-06 09:15:46 --- Now I have added myself to the bug. Please follow LKML and Xen-devel for more details. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
v3.9-rc1 instability on Chromebook Pixel with gmbus irq
On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: > I'm working on touch devices Chromium OS, and I've noticed a > regression between 3.8 and 3.9-rc1, which was posted yesterday. > > The hardware in question is a Chromebook Pixel. For this device, we > have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s > touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The > touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. > > I was testing v3.9-rc1 on the Pixel and the touchscreen driver is > being returned -110 (-ETIMEDOUT) on an i2c_transfer after several > seconds of both touch devices working correctly. At the time of the > failure, there are no error messages from GMBUS that I can see, but > the bus never recovers. I can keep interacting with the touchscreen or > touchpad, and the interrupts trigger reads, but all subsequent reads > return -110. > > I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus > irq support was merged. After bisecting, I found that this commit > seems to be causing the timeout problem. Reverting it makes the > problem go away, and the bus is stable. Can you please retest with latest drm-intel-fixes merged into -rc1? Paulo's patch fixes a race in handling PCH interrupts (where the gmbus hw is) which matches rather well with your description here. Thanks, Daniel > commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 > Author: Daniel Vetter > Date: Sat Dec 1 13:53:46 2012 +0100 > > drm/i915: use gmbus irq to wait for gmbus idle > > GMBUS_ACTIVE has inverted sense and so doesn't fit into the > wait_hw_status helper, hence create a new gmbus_wait_idle functions. > Also, we only care about the idle irq event and nothing else, which > allows us to use the wait_event_timeout helper directly without > jumping through hoops to catch NAKs. > > Since gen2/3 don't have gmbus interrupts, handle them separately with > the old wait_for macro. > > This shaves another few ms off reading EDID from a hdmi screen on my > testbox here. EDID reading with interrupt driven gmbus is now as fast > as with busy-looping gmbus at 28 ms here (with negligible cpu > overhead). > > Reviewed-by: Imre Deak > Signed-off-by: Daniel Vetter > > > Is there anything I can do to help debug this some more? > > -- > Benson Leung > Software Engineer, Chrom* OS > bleung at chromium.org -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #158 from Chris Wilson --- (In reply to comment #157) > In regards to comment 145, is it recommended to use SNA? We are not using > SNA and have seen GPU hangs on the 845G. Is it better to use SNA and apply > the SNA patch to xorg-x11-drv-intel? comment 145 is stale, superseded by the genuine fixes in comments 152 and 153. I would recommend using SNA on gen2 as UXA pales in comparison. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/c54d883d/attachment.html>
[Bug 61883] wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 Pavel Ondra?ka changed: What|Removed |Added CC||pavel.ondracka at email.cz Component|Drivers/DRI/r300|Drivers/Gallium/r300 --- Comment #1 from Pavel Ondra?ka --- This is a known issue. Wine internally needs some extra uniforms for doing fixups, and when the shader already uses all of them, there isn't anything you can do about it. Wine still generates the shader in blind hope, that the constants near the end, which are removed, aren't actually used... On the other side, in my experience this usually causes only corruption (r300g driver produces dummy shaders in place of the failed ones), not complete system freeze, so maybe there is more going on. You should try to obtain dmesg after the freeze and also the Xorg.0.log and attach them here. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/fc21b328/attachment.html>
[PATCH V2] drm/edid: kernel-doc minimal cleanup
On 10:27-20130304, Nishanth Menon wrote: > On 18:09-20130302, Paul Menzel wrote: > > Am Freitag, den 01.03.2013, 08:00 -0600 schrieb Nishanth Menon: > > > Some basic cleanups for kernel-doc errors or missing documentation > > > parameters. [..] > > > index c194f4e..bd864b5 100644 > > > --- a/drivers/gpu/drm/drm_edid.c > > > +++ b/drivers/gpu/drm/drm_edid.c > > > @@ -982,14 +982,14 @@ EXPORT_SYMBOL(drm_edid_is_valid); > > > > > > #define DDC_SEGMENT_ADDR 0x30 > > > /** > > > - * Get EDID information via I2C. > > > - * > > > - * \param adapter : i2c device adaptor > > > - * \param buf : EDID data buffer to be filled > > > - * \param len : EDID data buffer length > > > - * \return 0 on success or -1 on failure. > > > + * drm_do_probe_ddc_edid() - Get EDID information via I2C. > > > > Some already existing entries do not use ?()? behind the function name > > in the comment. Not sure what the correct way is though. > I followed the format as in: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n55 just a ping to confirm if there are any further changes required? -- Regards, Nishanth Menon
[PATCH] drm/tegra: drop "select DRM_HDMI"
On Tue, Mar 05, 2013 at 10:07:36PM +0100, Paul Bolle wrote:
> Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic
> HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
> Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
> statement for that symbol is a nop. Drop it.
>
> What was needed to use HDMI functionality was to select HDMI (which this
> entry already did through depending on DRM) and to include linux/hdmi.h
> (which this commit also did).
>
> Signed-off-by: Paul Bolle
> ---
> Untested.
>
> drivers/gpu/drm/tegra/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index c92955d..be1daf7 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -4,7 +4,6 @@ config DRM_TEGRA
> select DRM_KMS_HELPER
> select DRM_GEM_CMA_HELPER
> select DRM_KMS_CMA_HELPER
> - select DRM_HDMI
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
Good catch! I think what happened here is that the DRM HDMI helpers used
to be in a separate file and DRM_HDMI enabled that file to be built. The
helpers were moved into drm_edid.c at some point, though, and the symbol
was dropped and I forgot to remove it from the Tegra DRM Kconfig.
Acked-by:
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/faf85a39/attachment.pgp>
[Bug 61883] wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 --- Comment #3 from Victor Aurélio --- Created attachment 76025 --> https://bugs.freedesktop.org/attachment.cgi?id=76025&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61883] wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 --- Comment #2 from Victor Aurélio --- Created attachment 76024 --> https://bugs.freedesktop.org/attachment.cgi?id=76024&action=edit full dmesg output -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61529] [ATI RV710] r600_pcie_gart_tlb_flush+0xf5/0x110
https://bugs.freedesktop.org/show_bug.cgi?id=61529 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61446] [r600-llvm + mesa] on Evergreen & compiz 0.8: exposé-like feature & zoom lead to black screen
https://bugs.freedesktop.org/show_bug.cgi?id=61446 --- Comment #2 from Michel Dänzer --- Does it work better if you switch Mesa to the 9.1 branch or LLVM to the main trunk? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #10 from Michel Dänzer --- The segfault looks like some kind of LLVM issue on shutdown, we can probably ignore that for now. The real problem is that your GPU hangs even while running the trivial shaders egltri_screen uses. Alex, could it be we're trying to use a missing/disabled shader engine or something like that? Hristo, can you also attach the kernel output corresponding to egltri_screen? I expect it'll be basically the same as for starting X, but just in case. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61419] r600g: No OpenGL Core 3.1 available on Cayman
https://bugs.freedesktop.org/show_bug.cgi?id=61419 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Alexandre Demers --- Made a big Arch update two days ago, reinstalled mesa, drm, ddx from git and now it works correctly. Closing this bug. I still don't know what was wrong but it is now fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/02fbcf08/attachment.html>
Re: [Intel-gfx] [PATCH 1/4] drm: Add struct drm_region and assorted utility functions
On Wed, Mar 06, 2013 at 10:56:05AM +, Chris Wilson wrote: > On Thu, Feb 21, 2013 at 11:35:00PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > struct drm_region represents a two dimensional region. The utility > > functions are there to help driver writers. > > > > v2: Moved the region stuff into its own file, made the smaller funcs > > static inline, used 64bit maths in the scaled clipping function to > > avoid overflows (instead it will saturate to INT_MIN or INT_MAX). > > > > Signed-off-by: Ville Syrjälä > > My criticisms here are mainly that the function names are different than > what I am used to for a region API. Namely drm_region_clip, > drm_region_subsample would more conventionally be drm_region_intersect, > drm_region_downscale. And that a region to me is an ordered list of > rectangles, whereas here you just have a single rectangle. I'm fine with renaming stuff. Ideally the names should be so obvious that people never have to look at the documentation. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/4] drm: Add struct drm_region and assorted utility functions
On Thu, Feb 21, 2013 at 11:35:00PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > struct drm_region represents a two dimensional region. The utility > functions are there to help driver writers. > > v2: Moved the region stuff into its own file, made the smaller funcs > static inline, used 64bit maths in the scaled clipping function to > avoid overflows (instead it will saturate to INT_MIN or INT_MAX). > > Signed-off-by: Ville Syrjälä My criticisms here are mainly that the function names are different than what I am used to for a region API. Namely drm_region_clip, drm_region_subsample would more conventionally be drm_region_intersect, drm_region_downscale. And that a region to me is an ordered list of rectangles, whereas here you just have a single rectangle. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/exynos: fimd: calculate the correct address offset
On 03/06/2013 02:20 PM, Leela Krishna Amudala wrote:
Calculate the correct address offset values for alpha and color key
control registers and clear size control register for window 0
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..78bab4a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,21 +38,22 @@
/* position control register for hardware window 0, 2 ~ 4.*/
#define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
#define VIDOSD_B(win) (VIDOSD_BASE + 0x04 + (win) * 16)
+/* size control register is avaliable only for windows 0, 1 and 2. */
/* size control register for hardware window 0. */
#define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win) (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/* size control register for hardware window 1 ~ 2. */
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
+/* alpha control register for hardware window 1 ~ 4. */
+#define VIDOSD_C(win) (VIDOSD_BASE + 0x08 + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
#define VIDWx_BUF_END(win, buf) (VIDW_BUF_END(buf) + (win) * 8)
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
/* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8))
/* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR5
@@ -782,11 +783,14 @@ static void fimd_clear_win(struct fimd_context *ctx, int
win)
writel(0, ctx->regs + WINCON(win));
writel(0, ctx->regs + VIDOSD_A(win));
writel(0, ctx->regs + VIDOSD_B(win));
- writel(0, ctx->regs + VIDOSD_C(win));
+ if (win != 0)
+ writel(0, ctx->regs + VIDOSD_C(win));
if (win == 1 || win == 2)
writel(0, ctx->regs + VIDOSD_D(win));
+ if (win == 0)
+ writel(0, ctx->regs + VIDOSD_C_SIZE_W0);
val = readl(ctx->regs + SHADOWCON);
val &= ~SHADOWCON_WINx_PROTECT(win);
writel(val, ctx->regs + SHADOWCON);
As i said at v1 patch, i prefer to remove VIDOSD_C_SIZE_W0 and it makes
codes are simple. Even if VIDOSD_C_SIZE_W0 is defined, it's not good
that VIDOSD_C(0) can mean VIDOSD_C_SIZE_W0.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7514bee..a4356b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -40,11 +40,12 @@
/* position control register for hardware window 0, 2 ~ 4.*/
#define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
#define VIDOSD_B(win) (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0 (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win) (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win) (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware window 1 ~ 2. */
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
@@ -52,9 +53,9 @@
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
/* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x) ((WKEYCON0 + 0x140) + ((x - 1) * 8))
/* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR 5
@@ -583,7 +584,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
- offset = VIDOSD_C_SIZE_W0;
+ offset = VIDOSD_C(win);
val = win_data->ovl_width * win_data->ovl_height;
writel(va
Re: Radeon HDMI question
Hi, 2013-03-06 10:50 keltezéssel, Christian König írta: Hi, Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan: OK, a new problem now with 5.1 sound, it can be reproduced. I still have the same setup as described above. I started watching a video. Initially, HDMI audio just works nicely. I had to do something else so I paused Xine. During this time, X went to DPMS blanking. The TV switches itself off to save power if it sees no input. So, after waking up the monitor from DPMS and turning on the TV again, I pressed play on the video. It continues playing but without the sound. It seems to be the same with Linux 3.8.1 and earlier kernels. Does that also happen with just plain stereo playback? If yes then this is a bug with restoring the correct audio settings after DPMS blanking. I will try to test it later, also with mplayer. If not (and that's what I think is more likely) than that's because DPMS blanking causes a desync between xine and your TV. Unfortunately there isn't much we can do about it (maybe expect disabling DPMS all together), Cause from the hardware point of view it's just not possible to tell the audio codec to stop playback because the display isn't turned on any more. Does it work when you close xine and restart it? If yes than it might be worth a try to tell xine to close and reopen the audio device on pause/restart of playback. Unfortunately, after HDMI audio goes away, restarting Xine doesn't help at all. The audio driver is pulseaudio in Xine, so I can switch between the built-in audio with stereo speakers and the HDMI output and the speakers produce the expected sounds. Also, the vumeter in pavucontrol shows that sound is generated from Xine, no matter which hardware is selected and even when HDMI is selected but there is no sound on the TV after it went out. The sound only comes back when I reboot the computer. There is nothing in dmesg, only: ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128 ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0 That's unrelated, the alsa driver just assumes the standard ELD informations for the HDMI audio codec, but AMD hardware is actually not using it. The real solution to your problem is to finally implement 8 channel PCM audio, instead of just using this ugly 5.1 pass through workaround. But so far nobody had time to do so. Thanks for the information. Best regards, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon HDMI question
Hi, Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan: OK, a new problem now with 5.1 sound, it can be reproduced. I still have the same setup as described above. I started watching a video. Initially, HDMI audio just works nicely. I had to do something else so I paused Xine. During this time, X went to DPMS blanking. The TV switches itself off to save power if it sees no input. So, after waking up the monitor from DPMS and turning on the TV again, I pressed play on the video. It continues playing but without the sound. It seems to be the same with Linux 3.8.1 and earlier kernels. Does that also happen with just plain stereo playback? If yes then this is a bug with restoring the correct audio settings after DPMS blanking. If not (and that's what I think is more likely) than that's because DPMS blanking causes a desync between xine and your TV. Unfortunately there isn't much we can do about it (maybe expect disabling DPMS all together), Cause from the hardware point of view it's just not possible to tell the audio codec to stop playback because the display isn't turned on any more. Does it work when you close xine and restart it? If yes than it might be worth a try to tell xine to close and reopen the audio device on pause/restart of playback. There is nothing in dmesg, only: ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128 ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0 That's unrelated, the alsa driver just assumes the standard ELD informations for the HDMI audio codec, but AMD hardware is actually not using it. The real solution to your problem is to finally implement 8 channel PCM audio, instead of just using this ugly 5.1 pass through workaround. But so far nobody had time to do so. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61883] New: wine shader_generate_glsl_declarations fail
https://bugs.freedesktop.org/show_bug.cgi?id=61883 Priority: medium Bug ID: 61883 Assignee: dri-devel at lists.freedesktop.org Summary: wine shader_generate_glsl_declarations fail Severity: normal Classification: Unclassified OS: Linux (All) Reporter: victoraur.santos at gmail.com Hardware: All Status: NEW Version: 9.1 Component: Drivers/DRI/r300 Product: Mesa Trying to run RE4 on my r300 freeze completely system Submitted on wine bug tracker and suggested to report here. err:winediag:shader_generate_glsl_declarations The hardware does not support enough uniform components to run this shader, it may not render correctly. and lot of: r300: ERROR: FS input fog unassigned, not enough hardware slots. (it's not a bug, do not report it) for more details and full log see: http://bugs.winehq.org/show_bug.cgi?id=33129 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130306/cb28c146/attachment.html>
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 Daniel Kiper changed: What|Removed |Added CC||dki...@net-space.pl --- Comment #22 from Daniel Kiper 2013-03-06 09:15:46 --- Now I have added myself to the bug. Please follow LKML and Xen-devel for more details. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #158 from Chris Wilson --- (In reply to comment #157) > In regards to comment 145, is it recommended to use SNA? We are not using > SNA and have seen GPU hangs on the 845G. Is it better to use SNA and apply > the SNA patch to xorg-x11-drv-intel? comment 145 is stale, superseded by the genuine fixes in comments 152 and 153. I would recommend using SNA on gen2 as UXA pales in comparison. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-tegra at vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Re: [PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
2013/3/1 Vikas Sajjan :
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> Acked-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..e323cf9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -20,6 +20,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
> + OF_USE_NATIVE_MODE);
Add "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" to
drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
selected, these two configs should also be selected.
Thanks,
Inki Dae
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
> ret);
> + return ret;
> + }
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: v3.9-rc1 instability on Chromebook Pixel with gmbus irq
On Wed, 06 Mar 2013, Daniel Vetter wrote: > On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: >> I'm working on touch devices Chromium OS, and I've noticed a >> regression between 3.8 and 3.9-rc1, which was posted yesterday. >> >> The hardware in question is a Chromebook Pixel. For this device, we >> have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s >> touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The >> touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. >> >> I was testing v3.9-rc1 on the Pixel and the touchscreen driver is >> being returned -110 (-ETIMEDOUT) on an i2c_transfer after several >> seconds of both touch devices working correctly. At the time of the >> failure, there are no error messages from GMBUS that I can see, but >> the bus never recovers. I can keep interacting with the touchscreen or >> touchpad, and the interrupts trigger reads, but all subsequent reads >> return -110. >> >> I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus >> irq support was merged. After bisecting, I found that this commit >> seems to be causing the timeout problem. Reverting it makes the >> problem go away, and the bus is stable. > > Can you please retest with latest drm-intel-fixes merged into -rc1? > Paulo's patch fixes a race in handling PCH interrupts (where the gmbus > hw is) which matches rather well with your description here. Also, some error paths only print with debug on. Did you try with drm.debug=0xe? BR, Jani. > > Thanks, Daniel > >> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 >> Author: Daniel Vetter >> Date: Sat Dec 1 13:53:46 2012 +0100 >> >> drm/i915: use gmbus irq to wait for gmbus idle >> >> GMBUS_ACTIVE has inverted sense and so doesn't fit into the >> wait_hw_status helper, hence create a new gmbus_wait_idle functions. >> Also, we only care about the idle irq event and nothing else, which >> allows us to use the wait_event_timeout helper directly without >> jumping through hoops to catch NAKs. >> >> Since gen2/3 don't have gmbus interrupts, handle them separately with >> the old wait_for macro. >> >> This shaves another few ms off reading EDID from a hdmi screen on my >> testbox here. EDID reading with interrupt driven gmbus is now as fast >> as with busy-looping gmbus at 28 ms here (with negligible cpu >> overhead). >> >> Reviewed-by: Imre Deak >> Signed-off-by: Daniel Vetter >> >> >> Is there anything I can do to help debug this some more? >> >> -- >> Benson Leung >> Software Engineer, Chrom* OS >> ble...@chromium.org > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
