[Bug 96532] [BISECTED: 0955c1250e] 4.7-rc1 oops at drm_connector_cleanup+0x5c/0x1d0
https://bugs.freedesktop.org/show_bug.cgi?id=96532 --- Comment #1 from Thorsten Leemhuis --- George, have you seen the mail from Lucas, who wrote: "Probably the same bug as https://bugzilla.kernel.org/show_bug.cgi?id=119861 and already fixed in the last -rc." Can you confirm if this issue is fixed? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/982fd82e/attachment.html>
[GIT PULL] drm/mediatek: MT8173 gamma & dither support
On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote: > > On 06/24/2016 09:27 AM, Bibby Hsieh wrote: > > Hi Dave, > > > > Please consider merging this tag, which contains the v2 MT8173 gamma & > > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. There > > have been no further comments. > > > > Thanks > > Bibby > > > > The following changes since commit 1a695a905c18548062509178b98bc91e67510864: > > > > Linux 4.7-rc1 (2016-05-29 16:29:24 GMT) > > > > are available in the git repository at: > > > > git at github.com:BibbyHsieh/linux4.7-rc1.git > > > > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9: > > > > drm/mediatek: Add gamma correction > > > > - > > As far as I can see, your branch has 3 patches on top from Eddie. It > seems to me as if you didn't send your patches to the mailinglist before? > Anyway this branch does not fulfill the rules to get merged into the > linux kernel. > > Why do you send a pull request? The normal process is to send the > patches via email and if the maintainer wants you can send a pull > request once the patches are ready to be merged. > > Regards, > Matthias > I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8]. After I made some modifications according to Daniel Vetter's comments, there had been no further comments and I sent the pull request as the other sub-sys. I'm sorry for my mistake, I will re-arrange the tree for upstream. Next time, I will check with maintainer by email first, and sent the pull request. Thanks. Bibby [0]https://patchwork.kernel.org/patch/9174941/ [1]https://patchwork.kernel.org/patch/9174855/ [2]https://patchwork.kernel.org/patch/9182361/ [3]https://patchwork.kernel.org/patch/9182367/ [4]https://lists.freedesktop.org/archives/dri-devel/2016-June/78.html [5]https://lists.freedesktop.org/archives/dri-devel/2016-June/77.html [6]https://lists.freedesktop.org/archives/dri-devel/2016-June/76.html [7]https://lists.freedesktop.org/archives/dri-devel/2016-June/110781.html [8]https://lists.freedesktop.org/archives/dri-devel/2016-June/110782.html [9]https://lists.freedesktop.org/archives/dri-devel/2016-June/110784.html > > This is MT8173 gamma & dither support PATCH v2, based on 4.7-rc1. > > > > Changes since v1: > > -According to the suggestion from Daniel, > > we used the new atomic color management. > > -Applied gamma function at GAMMA engine (path 2). > > -Made dithering function support hardware mirroring well. > > -Removed the bpc variable from mtk_drm_crtc struct. > > - > > > > Bibby Hsieh (2): > > drm/mediatek: Add gamma correction > > drm/mediatek: set mt8173 dithering function > > > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +- > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 26 - > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 147 > > ++- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16 ++- > > 6 files changed, 184 insertions(+), 12 deletions(-) > >
[PATCH] drm: Fix broken use of _PAGE_NO_CACHE on powerpc
That constant isn't meant to be used outside of arch mm code
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_memory.c | 2 +-
drivers/gpu/drm/drm_scatter.c | 2 +-
drivers/gpu/drm/drm_vm.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index 87a8cb7..fc0ebd2 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -44,7 +44,7 @@
# include
#else
# ifdef __powerpc__
-# define PAGE_AGP __pgprot(_PAGE_KERNEL | _PAGE_NO_CACHE)
+# define PAGE_AGP pgprot_noncached_wc(PAGE_KERNEL)
# else
# define PAGE_AGP PAGE_KERNEL
# endif
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index 4f0f3b3..bf70431 100644
--- a/drivers/gpu/drm/drm_scatter.c
+++ b/drivers/gpu/drm/drm_scatter.c
@@ -41,7 +41,7 @@
static inline void *drm_vmalloc_dma(unsigned long size)
{
#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
- return __vmalloc(size, GFP_KERNEL, PAGE_KERNEL | _PAGE_NO_CACHE);
+ return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
#else
return vmalloc_32(size);
#endif
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index ac9f4b3..7e9f642 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -80,7 +80,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct
vm_area_struct *vma)
pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
- tmp |= _PAGE_NO_CACHE;
+ tmp = pgprot_noncached_wc(tmp);
#endif
return tmp;
}
@@ -593,7 +593,7 @@ static int drm_mmap_locked(struct file *filp, struct
vm_area_struct *vma)
* pages and mappings in fault()
*/
#if defined(__powerpc__)
- pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
#endif
vma->vm_ops = &drm_vm_ops;
break;
Applied "ASoC: hdmi-codec: callback function will be called with private data" to the asoc tree
The patch
ASoC: hdmi-codec: callback function will be called with private data
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From efc9194bcff84666832c6493bafa92029ac6634c Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto
Date: Fri, 24 Jun 2016 02:47:55 +
Subject: [PATCH] ASoC: hdmi-codec: callback function will be called with
private data
Current hdmi-codec driver is assuming that it will be registered
from HDMI driver. Because of this assumption, each callback function
has struct device pointer which is parent device (= HDMI).
Then, it can use dev_get_drvdata() to get private data.
OTOH, on some SoC/HDMI case, SoC has VIDEO/SOUND and HDMI IPs.
This case, it needs SoC VIDEO, SoC SOUND and HDMI video, HDMI codec
driver. In DesignWare HDMI IP case, SoC VIDEO (= DRM/KMS) driver tries
to bind DesignWare HDMI video driver, and HDMI codec driver
(= hdmi-codec). This case, above "parent device" of HDMI codec driver
is DRM/KMS driver and its "device" already has private data.
And, from DT and ASoC CPU/Codec/Card binding point of view, HDMI codec
(= hdmi-codec) needs to have "parent device" (= DRM/KMS), otherwise,
it never detect sound card.
Because of these reasons, some driver can't use dev_get_drvdata() to
get private data on hdmi-codec driver. This patch add new void pointer
on hdmi_codec_pdata for private data, and callback function will be
called with it.
Signed-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown
---
include/sound/hdmi-codec.h| 13 -
sound/soc/codecs/hdmi-codec.c | 15 ---
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index fc3a481ad91e..530c57bdefa0 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -53,18 +53,19 @@ struct hdmi_codec_params {
int channels;
};
+struct hdmi_codec_pdata;
struct hdmi_codec_ops {
/*
* Called when ASoC starts an audio stream setup.
* Optional
*/
- int (*audio_startup)(struct device *dev);
+ int (*audio_startup)(struct device *dev, void *data);
/*
* Configures HDMI-encoder for audio stream.
* Mandatory
*/
- int (*hw_params)(struct device *dev,
+ int (*hw_params)(struct device *dev, void *data,
struct hdmi_codec_daifmt *fmt,
struct hdmi_codec_params *hparms);
@@ -72,19 +73,20 @@ struct hdmi_codec_ops {
* Shuts down the audio stream.
* Mandatory
*/
- void (*audio_shutdown)(struct device *dev);
+ void (*audio_shutdown)(struct device *dev, void *data);
/*
* Mute/unmute HDMI audio stream.
* Optional
*/
- int (*digital_mute)(struct device *dev, bool enable);
+ int (*digital_mute)(struct device *dev, void *data, bool enable);
/*
* Provides EDID-Like-Data from connected HDMI device.
* Optional
*/
- int (*get_eld)(struct device *dev, uint8_t *buf, size_t len);
+ int (*get_eld)(struct device *dev, void *data,
+ uint8_t *buf, size_t len);
};
/* HDMI codec initalization data */
@@ -93,6 +95,7 @@ struct hdmi_codec_pdata {
uint i2s:1;
uint spdif:1;
int max_i2s_channels;
+ void *data;
};
#define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 8e36e883e453..f27d115626db 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -112,7 +112,7 @@ static int hdmi_codec_startup(struct snd_pcm_substream
*substream,
return ret;
if (hcp->hcd.ops->audio_startup) {
- ret = hcp->hcd.ops->audio_startup(dai->dev->parent);
+ ret = hcp->hcd.ops->audio_startup(dai->dev->parent,
hcp->hcd.data);
if (ret) {
mutex_lock(&hcp->current_stream_lock);
hcp->current_stream = NULL;
@@ -122,8 +122,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream
*substream,
}
if (hcp->hcd.
[PATCH v3] drm/vgem: Enable dmabuf interface for export
gem_prime_pin = vgem_prime_pin, > + .gem_prime_export = drm_gem_prime_export, > + .gem_prime_get_sg_table = vgem_prime_get_sg_table, > + .gem_prime_vmap = vgem_prime_vmap, > + .gem_prime_vunmap = vgem_prime_vunmap, > + .gem_prime_mmap = vgem_prime_mmap, > + > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > .date = DRIVER_DATE, > -- > 2.8.1 > > Acked-by: Zach Reizner -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/7e4066b1/attachment.html>
[RFC v2 3/3] dma-buf/sync_file: rework fence storage in struct file
From: Gustavo Padovan
Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.
This change cleans up sync_file a bit. We don't need to have sync_file_cb
array anymore. Instead, as we always have one fence, only one fence
callback is registered per sync_file.
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 148 +++
drivers/staging/android/sync_debug.c | 9 ++-
include/linux/sync_file.h| 15 ++--
3 files changed, 111 insertions(+), 61 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 9aaa608..ca19d3a 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -28,11 +28,11 @@
static const struct file_operations sync_file_fops;
-static struct sync_file *sync_file_alloc(int size)
+static struct sync_file *sync_file_alloc(void)
{
struct sync_file *sync_file;
- sync_file = kzalloc(size, GFP_KERNEL);
+ sync_file = kzalloc(sizeof(*sync_file), GFP_KERNEL);
if (!sync_file)
return NULL;
@@ -45,6 +45,8 @@ static struct sync_file *sync_file_alloc(int size)
init_waitqueue_head(&sync_file->wq);
+ INIT_LIST_HEAD(&sync_file->cb.node);
+
return sync_file;
err:
@@ -54,11 +56,9 @@ err:
static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
{
- struct sync_file_cb *check;
struct sync_file *sync_file;
- check = container_of(cb, struct sync_file_cb, cb);
- sync_file = check->sync_file;
+ sync_file = container_of(cb, struct sync_file, cb);
if (atomic_dec_and_test(&sync_file->status))
wake_up_all(&sync_file->wq);
@@ -76,21 +76,19 @@ struct sync_file *sync_file_create(struct fence *fence)
{
struct sync_file *sync_file;
- sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
+ sync_file = sync_file_alloc();
if (!sync_file)
return NULL;
- sync_file->num_fences = 1;
+ sync_file->fence = fence;
+
atomic_set(&sync_file->status, 1);
snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
fence->ops->get_driver_name(fence),
fence->ops->get_timeline_name(fence), fence->context,
fence->seqno);
- sync_file->cbs[0].fence = fence;
- sync_file->cbs[0].sync_file = sync_file;
- if (fence_add_callback(fence, &sync_file->cbs[0].cb,
- fence_check_cb_func))
+ if (fence_add_callback(fence, &sync_file->cb, fence_check_cb_func))
atomic_dec(&sync_file->status);
return sync_file;
@@ -121,14 +119,42 @@ err:
return NULL;
}
-static void sync_file_add_pt(struct sync_file *sync_file, int *i,
-struct fence *fence)
+static int sync_file_set_fence(struct sync_file *sync_file,
+ struct fence **fences, int num_fences)
{
- sync_file->cbs[*i].fence = fence;
- sync_file->cbs[*i].sync_file = sync_file;
+ struct fence_array *array;
+
+ if (num_fences == 1) {
+ sync_file->fence = fences[0];
+ } else {
+ array = fence_array_create(num_fences, fences,
+ fence_context_alloc(1), 1, false);
+ if (!array)
+ return -ENOMEM;
+
+ sync_file->fence = (struct fence *)array;
+ }
+
+ return 0;
+}
- if (!fence_add_callback(fence, &sync_file->cbs[*i].cb,
- fence_check_cb_func)) {
+static struct fence **get_fences(struct sync_file *sync_file, int *num_fences)
+{
+ if (fence_is_array(sync_file->fence)) {
+ struct fence_array *array = to_fence_array(sync_file->fence);
+ *num_fences = array->num_fences;
+ return array->fences;
+ } else {
+ *num_fences = 1;
+ return &sync_file->fence;
+ }
+}
+
+static void add_fence(struct fence **fences, int *i, struct fence *fence)
+{
+ fences[*i] = fence;
+
+ if (!fence_is_signaled(fence)) {
fence_get(fence);
(*i)++;
}
@@ -147,16 +173,23 @@ static void sync_file_add_pt(struct sync_file *sync_file,
int *i,
static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
struct sync_file *b)
{
- int num_fences = a->num_fences + b->num_fences;
struct sync_file *sync_file;
- int i, i_a, i_b;
- unsigned long size = offsetof(struct sync_file, cbs[num_fences]);
+ struct fence **fences, **a_fences, **b_fences;
+ int i, i_a, i_b, num_fences, a_num_fences,
[RFC v2 2/3] dma-buf/fence-array: add fence_array_teardown()
From: Gustavo Padovan
As the array of fence callbacks held by an active struct fence_array
each has a reference to the struct fence_array, when the owner of the
fence_array is freed it must dispose of the callback references before
it can free the fence_array. This can not happen simply during
fence_release() because of the extra references and so we need a new
function to run before the final fence_put().
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/fence-array.c | 25 +
include/linux/fence-array.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index a8731c8..8891357 100644
--- a/drivers/dma-buf/fence-array.c
+++ b/drivers/dma-buf/fence-array.c
@@ -142,3 +142,28 @@ struct fence_array *fence_array_create(int num_fences,
struct fence **fences,
return array;
}
EXPORT_SYMBOL(fence_array_create);
+
+/**
+ * fence_array_teardown - Teardown and clean up a fence array
+ * @array: [in]the fence array to teardown
+ *
+ * This function removes callbacks and extra references to the base fence on
+ * the fence_array for each unsignalled fence in the array. It should be called
+ * before calling fence_put() to remove the last reference on a fence_array,
+ * otherwise the fence won't be released due to extra references holded by the
+ * the fences that still have signalling enabled.
+ */
+void fence_array_teardown(struct fence_array *array)
+{
+ struct fence_array_cb *cb = (void *)(&array[1]);
+ int i;
+
+ for (i = 0; i < array->num_fences; i++) {
+ if (fence_is_signaled(array->fences[i]))
+ continue;
+
+ fence_remove_callback(array->fences[i], &cb[i].cb);
+ fence_put(&array->base);
+ }
+}
+EXPORT_SYMBOL(fence_array_teardown);
diff --git a/include/linux/fence-array.h b/include/linux/fence-array.h
index d2e9f40..9f1b923 100644
--- a/include/linux/fence-array.h
+++ b/include/linux/fence-array.h
@@ -79,5 +79,6 @@ static inline struct fence_array *to_fence_array(struct fence
*fence)
struct fence_array *fence_array_create(int num_fences, struct fence **fences,
u64 context, unsigned seqno,
bool signal_on_any);
+void fence_array_teardown(struct fence_array *array);
#endif /* __LINUX_FENCE_ARRAY_H */
--
2.5.5
[RFC v2 1/3] dma-buf/fence-array: add fence_is_array()
From: Gustavo Padovan
Add helper to check if fence is array.
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
---
include/linux/fence-array.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/fence-array.h b/include/linux/fence-array.h
index 86baaa4..d2e9f40 100644
--- a/include/linux/fence-array.h
+++ b/include/linux/fence-array.h
@@ -52,6 +52,16 @@ struct fence_array {
extern const struct fence_ops fence_array_ops;
/**
+ * fence_is_array - check if a fence is from the array subsclass
+ *
+ * Return true if it is a fence_array and false otherwise.
+ */
+static inline bool fence_is_array(struct fence *fence)
+{
+ return (fence->ops == &fence_array_ops) ? true : false;
+}
+
+/**
* to_fence_array - cast a fence to a fence_array
* @fence: fence to cast to a fence_array
*
--
2.5.5
[RFC v2 0/3] dma-buf/sync_file: rework fences on struct sync_file
From: Gustavo Padovan Hi all, This is an attempt to improve fence support on Sync File. The basic idea is to have only sync_file->fence and store all fences there, either as normal fences or fence_arrays. That way we can remove some potential duplication when using fence_array with sync_file: the duplication of the array of fences and the duplication of fence_add_callback() for all fences. Now when creating a new sync_file during the merge process sync_file_set_fence() will set sync_file->fence based on the number of fences for that sync_file. If there is more than one fence a fence_array is created. One important advantage approach is that we only add one fence callback now, no matter how many fences there are in a sync_file - the individual callbacks are added by fence_array. Please review! Thanks! Gustavo Changes since v1 (Comments from Chris Wilson and Christian König): - Not using fence_ops anymore. - fence_is_array() was created to differentiate fence from fence_array - fence_array_teardown() is now exported and used under fence_is_array() - struct sync_file lost num_fences member Gustavo Padovan (3): dma-buf/fence-array: add fence_is_array() dma-buf/fence-array: add fence_array_teardown() dma-buf/sync_file: rework fence storage in struct file drivers/dma-buf/fence-array.c| 25 ++ drivers/dma-buf/sync_file.c | 148 +++ drivers/staging/android/sync_debug.c | 9 ++- include/linux/fence-array.h | 11 +++ include/linux/sync_file.h| 15 ++-- 5 files changed, 147 insertions(+), 61 deletions(-) -- 2.5.5
[PATCH] drm: fix some spelling mistakes
On Fri, 24 Jun 2016, Alex Deucher wrote: > On Fri, Jun 24, 2016 at 6:15 AM, Frank Binns > wrote: >> Signed-off-by: Frank Binns > > Reviewed-by: Alex Deucher Pushed to drm-misc, thanks for the patch and review. BR, Jani. > >> --- >> drivers/gpu/drm/drm_irq.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c >> index 8ca3d2b..149453c 100644 >> --- a/drivers/gpu/drm/drm_irq.c >> +++ b/drivers/gpu/drm/drm_irq.c >> @@ -532,7 +532,7 @@ int drm_irq_uninstall(struct drm_device *dev) >> >> /* >> * Wake up any waiters so they don't hang. This is just to paper over >> -* isssues for UMS drivers which aren't in full control of their >> +* issues for UMS drivers which aren't in full control of their >> * vblank/irq handling. KMS drivers must ensure that vblanks are all >> * disabled when uninstalling the irq handler. >> */ >> @@ -594,7 +594,7 @@ int drm_control(struct drm_device *dev, void *data, >> return 0; >> if (drm_core_check_feature(dev, DRIVER_MODESET)) >> return 0; >> - /* UMS was only ever support on pci devices. */ >> + /* UMS was only ever supported on pci devices. */ >> if (WARN_ON(!dev->pdev)) >> return -EINVAL; >> >> -- >> 2.7.4 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center
[PATCH 1/5] drm: Unexport drm_connector_register_all()
On Fri, 24 Jun 2016, Chris Wilson wrote:
> This has now been removed from all drivers as it is performed centrally
> as a part of device registration for modesetting drivers. With the last
> user gone, we can unexport it from the DRM module.
>
> Signed-off-by: Chris Wilson
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_crtc.c | 19 +--
> include/drm/drm_crtc.h | 1 -
> 2 files changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 1190638a3d53..c660ea28cf26 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1109,23 +1109,7 @@ void drm_connector_unregister(struct drm_connector
> *connector)
> }
> EXPORT_SYMBOL(drm_connector_unregister);
>
> -/**
> - * drm_connector_register_all - register all connectors
> - * @dev: drm device
> - *
> - * This function registers all connectors in sysfs and other places so that
> - * userspace can start to access them. drm_connector_register_all() is called
> - * automatically from drm_dev_register() to complete the device registration,
Bikeshed, why throw away the documentation when you could just tweak it
to reflect reality?
Just cut from here...
> - * if they don't call drm_connector_register() on each connector
> individually.
> - *
> - * When a device is unplugged and should be removed from userspace access,
> - * call drm_connector_unregister_all(), which is the inverse of this
> - * function.
> - *
...to here?
BR,
Jani.
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_connector_register_all(struct drm_device *dev)
> +static int drm_connector_register_all(struct drm_device *dev)
> {
> struct drm_connector *connector;
> int ret;
> @@ -1147,7 +1131,6 @@ err:
> drm_connector_unregister_all(dev);
> return ret;
> }
> -EXPORT_SYMBOL(drm_connector_register_all);
>
> /**
> * drm_connector_unregister_all - unregister connector userspace interfaces
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e6ed7018e290..ddaa7243af55 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2589,7 +2589,6 @@ static inline unsigned drm_connector_index(struct
> drm_connector *connector)
> }
>
> /* helpers to {un}register all connectors from sysfs for device */
> -extern int drm_connector_register_all(struct drm_device *dev);
> extern void drm_connector_unregister_all(struct drm_device *dev);
>
> extern __printf(5, 6)
--
Jani Nikula, Intel Open Source Technology Center
[RFC PATCH 4/4] CHROMIUM: devicetree: Add GPIO display mux binding
Signed-off-by: Nicolas Boichat
---
.../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt
b/Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt
new file mode 100644
index 000..cce410c
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt
@@ -0,0 +1,59 @@
+Generic display mux (1 input, 2 outputs)
+
+
+This bindings describes a simple display (e.g. HDMI) mux, that has 2
+inputs, and 1 output. The mux status is controlled by hardware, and
+its status is read back using a GPIO.
+
+Required properties:
+
+ - compatible : "gpio-display-mux"
+ - detect-gpios: GPIO that indicates the active output
+
+ - Video port for input, using the DT bindings defined in [1].
+ - 2 video port for output, using the DT bindings defined in [1].
+ The reg value in the endpoints matches the GPIO status: when
+ GPIO is active, endpoint with reg value <1> is selected,.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ hdmi_mux: hdmi_mux {
+ compatible = "gpio-display-mux";
+ status = "okay";
+ detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_mux_pins>;
+ ddc-i2c-bus = <&hdmiddc0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 { /* input */
+ reg = <0>;
+
+ hdmi_mux_in: endpoint {
+ remote-endpoint = <&hdmi0_out>;
+ };
+ };
+
+ port at 1 { /* output */
+ reg = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_mux_out_anx: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&anx7688_in>;
+ };
+
+ hdmi_mux_out_hdmi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
--
2.8.0.rc3.226.g39d4020
[RFC PATCH 3/4] CHROMIUM: drm: bridge: Generic GPIO mux driver
This driver supports single input, 2 output display mux (e.g.
HDMI mux), that provides its status via a GPIO.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/bridge/Kconfig| 11 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 ++
3 files changed, 359 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index da489f0..f1f6fc6 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,6 +41,17 @@ config DRM_DW_HDMI_AHB_AUDIO
Designware HDMI block. This is used in conjunction with
the i.MX6 HDMI driver.
+config DRM_GENERIC_GPIO_MUX
+ tristate "Generic GPIO-controlled mux"
+ depends on DRM
+ depends on OF
+ select DRM_KMS_HELPER
+ ---help---
+ This bridge driver models a GPIO-controlled display mux with one
+ input, 2 outputs (e.g. an HDMI mux). The hardware decides which output
+ is active, reports it as a GPIO, and the driver redirects calls to the
+ appropriate downstream bridge (if any).
+
config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4846465..cb97274fd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c
b/drivers/gpu/drm/bridge/generic-gpio-mux.c
new file mode 100644
index 000..d3367e2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c
@@ -0,0 +1,347 @@
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_display_mux {
+ struct device *dev;
+
+ struct gpio_desc *gpiod_detect;
+ int detect_irq;
+
+ struct drm_bridge bridge;
+
+ struct drm_bridge *next[2];
+
+ struct mutex lock;
+ int active;
+ bool enabled;
+};
+
+static inline struct gpio_display_mux *bridge_to_gpio_display_mux(
+ struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct gpio_display_mux, bridge);
+}
+
+static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void
*data)
+{
+ struct gpio_display_mux *gpio_display_mux = data;
+ struct drm_bridge *next;
+ int active;
+
+ active = gpiod_get_value(gpio_display_mux->gpiod_detect);
+
+ dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active);
+
+ if (active == gpio_display_mux->active)
+ return IRQ_HANDLED;
+
+ /* Disable previous bridge */
+ mutex_lock(&gpio_display_mux->lock);
+ if (gpio_display_mux->enabled) {
+ next = gpio_display_mux->next[gpio_display_mux->active];
+ if (next && next->funcs->disable)
+ next->funcs->disable(next);
+ }
+ mutex_unlock(&gpio_display_mux->lock);
+
+ if (gpio_display_mux->bridge.dev)
+ drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev);
+
+ /* Enable current bridge */
+ mutex_lock(&gpio_display_mux->lock);
+ if (gpio_display_mux->enabled) {
+ next = gpio_display_mux->next[active];
+ if (next && next->funcs->enable)
+ next->funcs->enable(next);
+ }
+ gpio_display_mux->active = active;
+ mutex_unlock(&gpio_display_mux->lock);
+
+ return IRQ_HANDLED;
+}
+
+static int gpio_display_mux_attach(struct drm_bridge *bridge)
+{
+ struct gpio_display_mux *gpio_display_mux =
+ bridge_to_gpio_display_mux(bridge);
+ struct drm_bridge *next;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) {
+ next = gpio_display_mux->next[i];
+ if (next)
+ next->encoder = bridge->enco
[RFC PATCH 2/4] devicetree: Add ANX7688 transmitter binding
Signed-off-by: Nicolas Boichat
Change-Id: I618ddf114bb93700daf6572d954191e10b6961c8
---
.../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/anx7688.txt
b/Documentation/devicetree/bindings/drm/bridge/anx7688.txt
new file mode 100644
index 000..78b55bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/anx7688.txt
@@ -0,0 +1,32 @@
+Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C)
+-
+
+The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per
+second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video
+resolution from a smartphone or tablet with full function USB-C.
+
+This binding only describes the HDMI to DP display bridge.
+
+Required properties:
+
+ - compatible : "analogix,anx7688"
+ - reg : I2C address of the device (fixed at 0x2c)
+
+Optional properties:
+
+ - Video port for HDMI input, using the DT bindings defined in [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ anx7688: anx7688 at 2c {
+ compatible = "analogix,anx7688";
+ reg = <0x2c>;
+
+ port {
+ anx7688_in: endpoint {
+ remote-endpoint = <&hdmi0_out>;
+ };
+ };
+ };
--
2.8.0.rc3.226.g39d4020
[RFC PATCHv2 1/4] FROMLIST: drm: bridge: anx7688: Add anx7688 bridge driver support.
ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.
The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.
Change-Id: Icd19a6784317563be671f1c9c007df90e9c5e3c5
---
v2: Fix Archit's review comments, and a few other minor changes.
drivers/gpu/drm/bridge/Kconfig| 9 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++
3 files changed, 243 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index a1419214..da489f0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -7,6 +7,15 @@ config DRM_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
+config DRM_ANALOGIX_ANX7688
+ tristate "Analogix ANX7688 bridge"
+ depends on DRM
+ select DRM_KMS_HELPER
+ ---help---
+ ANX7688 is a transmitter to support DisplayPort over USB-C for
+ smartphone and tablets.
+ This driver only supports the HDMI to DP component of the chip.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index bfec9f8..4846465 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c
b/drivers/gpu/drm/bridge/analogix-anx7688.c
new file mode 100644
index 000..cc995c8
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
@@ -0,0 +1,233 @@
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+/* Register addresses */
+#define VENDOR_ID_REG 0x00
+#define DEVICE_ID_REG 0x02
+
+#define FW_VERSION_REG 0x80
+
+#define DP_BANDWIDTH_REG 0x85
+#define DP_LANE_COUNT_REG 0x86
+
+#define VENDOR_ID 0x1f29
+#define DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define MINIMUM_FW_VERSION 0x0085
+
+struct anx7688 {
+ struct drm_bridge bridge;
+ struct i2c_client *client;
+
+ bool filter;
+};
+
+static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
+ u16 data_len)
+{
+ int ret;
+ struct i2c_msg msgs[] = {
+ {
+.addr = client->addr,
+.flags = 0,
+.len = 1,
+.buf = ®,
+},
+ {
+.addr = client->addr,
+.flags = I2C_M_RD,
+.len = data_len,
+.buf = data,
+}
+ };
+
+ ret = i2c_transfer(client->adapter, msgs, 2);
+
+ if (ret == 2)
+ return 0;
+ if (ret < 0)
+ return ret;
+ else
+ return -EIO;
+}
+
+static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
+ u8 regs[2];
+ u8 dpbw, lanecount;
+ int totalbw, requiredbw;
+ int ret;
+
+ if (!anx7688->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = anx7688_read(anx7688->client, DP_BANDWIDTH_REG, regs, 2);
+ if (ret < 0) {
+ dev_err(&anx7688->client->dev,
+ "Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ dev_err(&anx7688->client->dev,
+
[RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
Hi all, This is a follow up to the 2 patches to add support for ANX7688 sent here: https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for the comments. I also added 2 patches to add support for a simple display MUX, as I'm facing similar issues while trying to implement it, i.e. the current DRM core does not seem to support this kind of simple pass-thru bridge very well: it is not very clear where connectors should be defined and attached. In this case, not defining any connectors in the 2 bridges (and reusing the connector in MTK HDMI driver) seem to work best, but makes little logical sense as the physical connectors are actually attached to the bridges. In any case, the board has the following layout: - MT8173 HDMI bridge - HDMI mux with 2 ports 1. ANX7688 for HDMI->DP over USB-C conversion 2. Native HDMI The mux is controlled by hardware, looking at the HPD signals from both ANX7688 and native HDMI, with a priority on the native HDMI output. The whole setup works fairly well without any Linux kernel drivers, except the 2 following cases: 1. When ANX7688 is active, DP bandwidth may be limited, so we need to filter resolutions that would exceed the available bandwidth. 2. When both outputs HPD signals are active, the kernel does not receive an HPD pulse when the HDMI input is unplugged. ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel to re-read the EDID on mux output change, and also issue 1 by filtering only when ANX7688 is active. I understand this patch series might not be acceptable as-is, but I hope this sort of setup can be taken into account when better support for connector drivers is introduced. Thanks! Best, Nicolas Nicolas Boichat (4): drm: bridge: anx7688: Add anx7688 bridge driver support. devicetree: Add ANX7688 transmitter binding drm: bridge: Generic GPIO mux driver devicetree: Add GPIO display mux binding .../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++ .../devicetree/bindings/drm/bridge/gpio-mux.txt| 59 drivers/gpu/drm/bridge/Kconfig | 20 ++ drivers/gpu/drm/bridge/Makefile| 2 + drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++ drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 + 6 files changed, 693 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c -- 2.8.0.rc3.226.g39d4020
[Bug 95545] [amdgpu][tonga] mplayer -vo=gl:yuv=2 causes VM fault
https://bugs.freedesktop.org/show_bug.cgi?id=95545 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Marek Olšák --- This seems to be fixed. Possible fix: commit 54f755fa0fda14c578022767bcef2f27b2e89707 Author: Bas Nieuwenhuizen Date: Mon Jun 6 22:36:35 2016 +0200 radeonsi: Reinitialize all descriptors in CE preamble. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/11a43668/attachment-0001.html>
iommu/rockchip: Fix bugs and enable on ARM64
On Fri, Jun 24, 2016 at 10:13:25AM +0800, Shunqian Zheng wrote: > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 100 +++-- > drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 221 > ++-- > drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 9 ++ > drivers/iommu/Kconfig | 2 +- > drivers/iommu/rockchip-iommu.c | 181 +-- > 6 files changed, 413 insertions(+), 103 deletions(-) Applied the IOMMU patches, thanks. Joerg
[PATCH] drm/i915: fix build errors when ACPI is not enabled
From: Randy Dunlap
Fix build errors when ACPI is not enabled by adding function stubs:
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of
function 'intel_opregion_unregister' [-Werror=implicit-function-declaration]
intel_opregion_unregister(dev_priv);
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume':
../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of
function 'intel_opregion_register' [-Werror=implicit-function-declaration]
intel_opregion_register(dev_priv);
Signed-off-by: Randy Dunlap
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
Fixes: 03d92e4779b8 ("drm/i915/opregion: Rename init/fini functions to
register/unregister")
Cc: drm-intel-fixes at lists.freedesktop.org
Cc: Chris Wilson
[Jani: dropped the stale init/fini declarations]
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ef491975812..724d34b00196 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3694,8 +3694,8 @@ extern int intel_opregion_notify_adapter(struct
drm_i915_private *dev_priv,
extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
#else
static inline int intel_opregion_setup(struct drm_i915_private *dev) { return
0; }
-static inline void intel_opregion_init(struct drm_i915_private *dev) { }
-static inline void intel_opregion_fini(struct drm_i915_private *dev) { }
+static inline void intel_opregion_register(struct drm_i915_private *dev_priv)
{ }
+static inline void intel_opregion_unregister(struct drm_i915_private
*dev_priv) { }
static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)
{
}
--
2.1.4
[PATCH 2/4] input: touchscreen: crtouch_ts: Add driver
t; > + crtouch_ts_reg_init(data);
> > +
> > + irq_gpio = of_get_named_gpio(client->dev.of_node, "irq-gpio", 0);
> > + if (!gpio_is_valid(irq_gpio))
> > + goto err_free_mem;
> > +
> > + error = gpio_request_one(irq_gpio, GPIOF_IN, "TS_IRQ");
> > + if (error) {
> > + dev_err(&client->dev, "Failed to request gpio\n");
> > + goto err_free_mem;
> > + }
> > +
> > + error = request_threaded_irq(gpio_to_irq(irq_gpio), NULL,
> > + crtouch_ts_interrupt,
> > + IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
> > + "crtouch_ts", data);
>
> As i mentioned above replace everything starting with of_get_named_gpio
> with:
>
> error = devm_request_threaded_irq(&cleint->dev, client->irq,
> NULL, crtouch_ts_interrupt,
> IRQF_ONESHOT,
> "crtouch_ts", data);
>
> > +
> > + if (error) {
> > + dev_err(&client->dev, "Failed to register interrupt\n");
> > + goto err_free_mem;
> > + }
> > +
> > + error = input_register_device(data->input_dev);
> > + if (error)
> > + goto err_free_irq;
> > +
> > + i2c_set_clientdata(client, data);
> > + return 0;
> > +
> > +err_free_irq:
> > + free_irq(client->irq, data);
> > +err_free_mem:
> > + input_free_device(input_dev);
> > + kfree(data);
> > + return error;
> > +}
> > +
> > +static int crtouch_ts_remove(struct i2c_client *client)
> > +{
> > + struct crtouch_ts_data *data = i2c_get_clientdata(client);
> > +
> > + free_irq(client->irq, data);
> > + input_unregister_device(data->input_dev);
> > + kfree(data);
>
> With devm it can all be dropped.
>
> > +
> > + return 0;
> > +}
> > +
> > +static const struct i2c_device_id crtouch_ts_id[] = {
> > + {"crtouch_ts", 0},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, crtouch_ts_id);
> > +
> > +static const struct of_device_id crtouch_ts_dt_ids[] = {
> > + { .compatible = "fsl,crtouch_ts", },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, crtouch_ts_dt_ids);
> > +
> > +static struct i2c_driver crtouch_ts_i2c_driver = {
> > + .driver = {
> > +.name = "crtouch_ts",
> > +.owner = THIS_MODULE,
>
> No need to set owner.
>
> > +.of_match_table = crtouch_ts_dt_ids,
>
> .of_match_table = of_match_ptr(crtouch_ts_dt_ids),
>
> Also, no PM methods?
>
>
Well, the main reason for no PM methods is the original driver did not have
PM methods. I can implement sleep/resume methods, and if all is working
well will submit as part of V2.
> > +},
> > + .probe = crtouch_ts_probe,
> > + .remove = crtouch_ts_remove,
> > + .id_table = crtouch_ts_id,
> > +};
> > +
> > +module_i2c_driver(crtouch_ts_i2c_driver);
> > +
> > +MODULE_AUTHOR("Alison Wang ");
> > +MODULE_DESCRIPTION("Touchscreen driver for Freescale CRTOUCH");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.7.4
> >
>
> Thanks.
>
> --
> Dmitry
>
--
Tony Felice
Support Engineering Manager
Timesys Corporation
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/5a5e6817/attachment-0001.html>
[PATCH 07/12] dt-bindings: i2c: Add support for 'i2c-bus' subnode
On 2016-06-23 17:59, Jon Hunter wrote: > The I2C driver core for boards using device-tree assumes any subnode of > an I2C adapter in the device-tree blob as being a I2C slave device. > Although this makes complete sense, some I2C adapters may have subnodes > which are not I2C slaves but subnodes presenting other features. For > example some Tegra devices have an I2C interface which may share its > pins with other devices and to share these pins subnodes for > representing these pins so they have be shared via the pinctrl framework > are needed. > > To allow I2C adapters to have non-I2C specific subnodes in device-tree > that are not parsed by the I2C driver core by adding support for a > 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus' > subnode is present then all I2C slaves must be placed under this subnode. > > Signed-off-by: Jon Hunter > Acked-by: Thierry Reding > --- > Documentation/devicetree/bindings/i2c/i2c.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt > b/Documentation/devicetree/bindings/i2c/i2c.txt > index f31b2ad1552b..71bea55d4c1b 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt > @@ -32,6 +32,14 @@ wants to support one of the below features, it should > adapt the bindings below. > - clock-frequency > frequency of bus clock in Hz. > > +- i2c-bus > + For I2C adapters that have child nodes that are a mixture of both I2C > + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' > + subnode can be used for populating I2C devices. If the 'i2c-bus' > + subnode is present, only subnodes of this will be considered as I2C > + slaves. The properties, '#address-cells' and '#size-cells' must be > + defined under this subnode if present. Hmmm, those #-properties are listed above, under "Required properties", which is no longer 100% true. Maybe rephrase to slaves. The required properties '#address-cells' and '#size-cells' must be defined under this subnode instead, if this subnode is present. to make the rules (even) clearer? Cheers, Peter > + > - i2c-scl-falling-time-ns > Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C > specification. >
[PATCH 1/2] drm: Add drm driver for OpenCores VGA/LCD display controller
On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote: >> This driver supports the VGA/LCD core available from OpenCores: >> http://opencores.org/project,vga_lcd >> >> It's intended as a replacement for the "ocfb" framebuffer driver >> >> Signed-off-by: Andrea Merello >> Cc: Stefan Kristiansson >> Cc: Tomi Valkeinen >> Cc: Francesco Diotalevi >> Cc: Claudio Lorini > > Bunch of comments below, but this driver might be a good candidate for the > drm_simple_display_pipe helpers that Noralf Tronnes is working on. Would > allow you to cut down a pile more boilerplate I think. Please take a look. > I think the only thing you'd need is a new small function to set the > drm_bridge for the encoder in struct drm_simple_display_pipe Yes, it seems a good option. I'll look into it. Beside this, OK for all your comments below. BTW I forgot to mention that, beside we are using it with a HDMI bridge, it would need something like the "RGB to VGA bridge" patch from Maxime Ripard [1] to actually replace the old "ocfb" driver. Is it likely to be accepted for merge sooner or later ? [1] https://patchwork.kernel.org/patch/9102271/ > -Daniel > >> --- >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/ocdrm/Kconfig | 7 + >> drivers/gpu/drm/ocdrm/Makefile| 7 + >> drivers/gpu/drm/ocdrm/ocdrm_crtc.c| 336 >> ++ >> drivers/gpu/drm/ocdrm/ocdrm_crtc.h| 48 + >> drivers/gpu/drm/ocdrm/ocdrm_drv.c | 312 +++ >> drivers/gpu/drm/ocdrm/ocdrm_drv.h | 89 + >> drivers/gpu/drm/ocdrm/ocdrm_encoder.c | 95 ++ >> drivers/gpu/drm/ocdrm/ocdrm_encoder.h | 48 + >> 10 files changed, 945 insertions(+) >> create mode 100644 drivers/gpu/drm/ocdrm/Kconfig >> create mode 100644 drivers/gpu/drm/ocdrm/Makefile >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_crtc.c >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_crtc.h >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_drv.c >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_drv.h >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_encoder.c >> create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_encoder.h >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index fc35731..48f56e4 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -290,3 +290,5 @@ source "drivers/gpu/drm/arc/Kconfig" >> source "drivers/gpu/drm/hisilicon/Kconfig" >> >> source "drivers/gpu/drm/mediatek/Kconfig" >> + >> +source "drivers/gpu/drm/ocdrm/Kconfig" >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index be43afb..871da6a 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -82,3 +82,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ >> obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ >> obj-$(CONFIG_DRM_ARCPGU)+= arc/ >> obj-y+= hisilicon/ >> +obj-$(CONFIG_DRM_OCDRM) += ocdrm/ >> diff --git a/drivers/gpu/drm/ocdrm/Kconfig b/drivers/gpu/drm/ocdrm/Kconfig >> new file mode 100644 >> index 000..a918503 >> --- /dev/null >> +++ b/drivers/gpu/drm/ocdrm/Kconfig >> @@ -0,0 +1,7 @@ >> +config DRM_OCDRM >> + tristate "DRM Support for opencores OCFB" >> + depends on DRM >> + default n >> + select DRM_KMS_HELPER >> + select DRM_KMS_CMA_HELPER >> + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE >> diff --git a/drivers/gpu/drm/ocdrm/Makefile b/drivers/gpu/drm/ocdrm/Makefile >> new file mode 100644 >> index 000..4ea17d2 >> --- /dev/null >> +++ b/drivers/gpu/drm/ocdrm/Makefile >> @@ -0,0 +1,7 @@ >> +# >> +# Makefile for the drm device driver. This driver provides support for the >> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. >> + >> +ocdrm-y := ocdrm_crtc.o ocdrm_drv.o ocdrm_encoder.o >> + >> +obj-$(CONFIG_DRM_OCDRM) += ocdrm.o >> diff --git a/drivers/gpu/drm/ocdrm/ocdrm_crtc.c >> b/drivers/gpu/drm/ocdrm/ocdrm_crtc.c >> new file mode 100644 >> index 000..ebfe03e >> --- /dev/null >> +++ b/drivers/gpu/drm/ocdrm/ocdrm_crtc.c >> @@ -0,0 +1,336 @@ >> +/* >> + * Open cores VGA/LCD 2.0 core DRM driver >> + * Copyright (c) 2016 Istituto Italiano di Tecnologia >> + * Electronic Design Lab. >> + * >> + * Author: Andrea Merello >> + * >> + * Based on the following drivers: >> + * - Analog Devices AXI HDMI DRM driver, which is >> + * Copyright 2012 Analog Devices Inc. >> + * >> + * - ARC PGU DRM driver. >> + * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com) >> + * >> + * - ARM HDLCD Driver >> + * Copyright (C) 2013-2015 ARM Limited >> + * >> + * - Atmel atmel-hlcdc driver, which is >> + * Copyright (C) 2014 Traphandler >> + * Copyright (C) 2014 Free Electrons >> + * >> + * - OpenCores VGA/LCD 2.0 core frame buffer driver >> + * Copyright (C) 2013 Stefan Kristiansson, stefan.kristians
[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1
https://bugs.freedesktop.org/show_bug.cgi?id=93652 Adam Bolte changed: What|Removed |Added CC||boltronics at gmail.com --- Comment #11 from Adam Bolte --- Confirming this same behaviour on an Asus Radeon R9 285 OC 2GB card: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] As others have said, Gallium Nine seems to run reliably. Vanilla Wine causes regular crashes, where I always have to SSH into the host from a laptop to reboot it. No problem with fglrx on Ubuntu 14.04.4. echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level does help a lot while active, but somehow this keeps getting reset back to auto which causes crashes again. I even have a cron job to run the above command every minute, but it's not enough. [ 6960.948175] INFO: task Xorg:5192 blocked for more than 120 seconds. [ 6960.948177] Tainted: G OE 4.7.0-rc2+ #2 [ 6960.948177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 6960.948178] XorgD 88086ec56d80 0 5192 5169 0x0004 [ 6960.948180] 880820e5c0c0 0011f5f8 81327b2d 88082620c000 [ 6960.948181] 880847c45780 8808453274e8 0001 0011f5f8 [ 6960.948182] 880842e8d9c8 815cd641 880407949400 c0b10c0f [ 6960.948183] Call Trace: [ 6960.948186] [] ? __kfifo_in+0x2d/0x40 [ 6960.948187] [] ? schedule+0x31/0x80 [ 6960.948200] [] ? amd_sched_entity_push_job+0x6f/0x110 [amdgpu] [ 6960.948202] [] ? wake_atomic_t_function+0x60/0x60 [ 6960.948211] [] ? amdgpu_job_submit+0x9f/0xf0 [amdgpu] [ 6960.948218] [] ? amdgpu_vm_bo_update_mapping+0x2bf/0x430 [amdgpu] [ 6960.948225] [] ? amdgpu_vm_bo_split_mapping+0x15a/0x1a0 [amdgpu] [ 6960.948231] [] ? amdgpu_vm_clear_freed+0x4f/0x90 [amdgpu] [ 6960.948237] [] ? amdgpu_gem_va_update_vm+0x188/0x1c0 [amdgpu] [ 6960.948239] [] ? ttm_bo_add_to_lru+0x8a/0xf0 [ttm] [ 6960.948245] [] ? amdgpu_gem_va_ioctl+0x22c/0x2e0 [amdgpu] [ 6960.948251] [] ? drm_gem_object_handle_unreference_unlocked+0x11/0xa0 [drm] [ 6960.948254] [] ? drm_ioctl+0x131/0x4c0 [drm] [ 6960.948260] [] ? amdgpu_gem_metadata_ioctl+0x1c0/0x1c0 [amdgpu] [ 6960.948262] [] ? do_readv_writev+0x149/0x240 [ 6960.948263] [] ? timerqueue_add+0x54/0xa0 [ 6960.948267] [] ? amdgpu_drm_ioctl+0x46/0x80 [amdgpu] [ 6960.948269] [] ? do_vfs_ioctl+0x9d/0x5c0 [ 6960.948270] [] ? __sys_recvmsg+0x7d/0x90 [ 6960.948271] [] ? SyS_ioctl+0x74/0x80 [ 6960.948272] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 drm: 625d1810ad1f61dd4f4b2b2ee7e5cc67e1fdc2f1 on master. xf86-video-amdgpu: d96dabc71b1b32dc4b422a9633cdd4e0e95da052 on master. mesa: d93bacc1fa4bf1d6d358da3615b00305e8518f33 on master. linux: 0812a945fbb814e7946fbe6ddcc81d054c8b6c91 on polaris-test (from git://people.freedesktop.org/~agd5f/linux) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/431a13f3/attachment.html>
[Bug 119831] "acpi=off" required to boot - MSI laptop G72 6QE - Intel Skylake
https://bugzilla.kernel.org/show_bug.cgi?id=119831 --- Comment #10 from Jani Nikula --- [ 14.841410] nouveau :01:00.0: DRM: evicting buffers... [ 14.841411] nouveau :01:00.0: DRM: waiting for kernel channels to go idle... [ 14.841425] nouveau :01:00.0: DRM: suspending client object trees... [ 14.844180] nouveau :01:00.0: DRM: suspending kernel object tree... [ 16.953255] pci_raw_set_power_state: 36 callbacks suppressed [ 16.953262] nouveau :01:00.0: Refused to change power state, currently in D3 [ 17.028340] nouveau :01:00.0: Refused to change power state, currently in D3 [ 17.044404] nouveau :01:00.0: Refused to change power state, currently in D3 [ 17.044421] nouveau :01:00.0: DRM: resuming kernel object tree... [ 17.044479] nouveau :01:00.0: pci: failed to adjust cap speed [ 17.044496] nouveau :01:00.0: pci: failed to adjust lnkctl speed -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm: Add DT bindings documentation for OpenCores VGA/LCD controller
On Fri, Jun 10, 2016 at 7:36 PM, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 03:33:19PM +0200, Andrea Merello wrote:
>> Signed-off-by: Andrea Merello
>> Cc: Stefan Kristiansson
>> Cc: Tomi Valkeinen
>> Cc: Francesco Diotalevi
>> Cc: Claudio Lorini
>> ---
>> .../bindings/display/opencores,ocdrm.txt | 27
>> ++
>> 1 file changed, 27 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/opencores,ocdrm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/opencores,ocdrm.txt
>> b/Documentation/devicetree/bindings/display/opencores,ocdrm.txt
>> new file mode 100644
>> index 000..8d36de5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/opencores,ocdrm.txt
>> @@ -0,0 +1,27 @@
>> +OpenCores VGA/LCD controller
>> +
>> +Required properties:
>> +- compatible: "opencores,ocdrm"
>
> Name this based on what the h/w block is called, not a Linux subsystem.
Ok.
Something like "opencores,video" ?
The older framebuffer driver has "opencores,ocfb"; I assumed the
suffix -fb was because of it is a "framebuffer" _driver_, but maybe it
is because they consider it a "framebuffer" _device_.
Maybe I can keep the same "compatible" string? Is it ok to have two
drivers (maybe temporarily, until the older one fades out) with the
same "compatible" ?
> Is there any sort of versioning for OpenCore IP that you can include in
> the name?
Not sure about this. I'll check.
>> +- reg: Physical base address and length of the controller's registers.
>> +- clocks: Must contain an entry for the pixelclock generator.
>> + See ../clocks/clock-bindings.txt for details.
>> +
>> +Required sub-nodes:
>> +- port: the connection to a DRM bridge. The connection is modelled
>
> Don't include Linux driver details (DRM) in bindings.
You mean telling that the port must be a connection to a DRM bridge,
leaving out further details?
>> + using the OF graph bindings specified in
>> + Documentation/devicetree/bindings/graph.txt.
>> +
>> +Example:
>> +
>> +ocdrm at 43c1 {
>> + compatible = "opencores,ocfb-drm";
>
> Doesn't match the above and even worse naming.
OK.
>> + reg = <0x43c1 0x1>;
>> + clocks = <&pix_clock>;
>> + ports {
>> + port at 0 {
>
> Single port doesn't need a unit address.
OK.
>> + rgb_out: endpoint {
>> + remote-endpoint = <&bridge_in>;
>> + };
>> + };
>> + };
>> +};
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: vf610-twr: Enable display controller
Hi Stefan,
Yes, these changes do work for the Tower board!
-Tony
On Sat, Jun 25, 2016 at 4:53 PM, Stefan Agner wrote:
> On 2016-06-24 12:44, Anthony Felice wrote:
> > This adds nodes to enable tcon0 and dcu0 for the Vybrid Tower. These
> > are used to drive the Vybrid Tower TWR-LCD-RGB display. Also, a node
> > for the nec nl4827hc19-05b panel on the TWR-LCD-RGB display has been
> > added.
>
> So my pixel clock polarity changes which will be part of 4.7 work for
> Tower? I could never actually test that since I don't have the display
> here...
> https://patchwork.kernel.org/patch/8874971/
>
> This patch looks good to me:
> Acked-by: Stefan Agner
>
> --
> Stefan
>
> >
> > Signed-off-by: Anthony Felice
> > ---
> > arch/arm/boot/dts/vf610-twr.dts | 48
> +
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/vf610-twr.dts
> b/arch/arm/boot/dts/vf610-twr.dts
> > index cdc1007..ad1aff9 100644
> > --- a/arch/arm/boot/dts/vf610-twr.dts
> > +++ b/arch/arm/boot/dts/vf610-twr.dts
> > @@ -66,6 +66,10 @@
> > clock-frequency = <5000>;
> > };
> >
> > + panel: panel {
> > + compatible = "nec,nl4827hc19-05b";
> > + };
> > +
> > regulators {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > @@ -134,6 +138,13 @@
> ><&clks VF610_CLK_ENET_EXT>;
> > };
> >
> > +&dcu0 {
> > + fsl,panel = <&panel>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_dcu0>;
> > + status = "okay";
> > +};
> > +
> > &dspi0 {
> > bus-num = <0>;
> > pinctrl-names = "default";
> > @@ -210,6 +221,39 @@
> >
> > &iomuxc {
> > vf610-twr {
> > + pinctrl_dcu0: dcu0grp {
> > + fsl,pins = <
> > + VF610_PAD_PTE0__DCU0_HSYNC 0x42
> > + VF610_PAD_PTE1__DCU0_VSYNC 0x42
> > + VF610_PAD_PTE2__DCU0_PCLK 0x42
> > + VF610_PAD_PTE4__DCU0_DE 0x42
> > + VF610_PAD_PTE5__DCU0_R0 0x42
> > + VF610_PAD_PTE6__DCU0_R1 0x42
> > + VF610_PAD_PTE7__DCU0_R2 0x42
> > + VF610_PAD_PTE8__DCU0_R3 0x42
> > + VF610_PAD_PTE9__DCU0_R4 0x42
> > + VF610_PAD_PTE10__DCU0_R50x42
> > + VF610_PAD_PTE11__DCU0_R60x42
> > + VF610_PAD_PTE12__DCU0_R70x42
> > + VF610_PAD_PTE13__DCU0_G00x42
> > + VF610_PAD_PTE14__DCU0_G10x42
> > + VF610_PAD_PTE15__DCU0_G20x42
> > + VF610_PAD_PTE16__DCU0_G30x42
> > + VF610_PAD_PTE17__DCU0_G40x42
> > + VF610_PAD_PTE18__DCU0_G50x42
> > + VF610_PAD_PTE19__DCU0_G60x42
> > + VF610_PAD_PTE20__DCU0_G70x42
> > + VF610_PAD_PTE21__DCU0_B00x42
> > + VF610_PAD_PTE22__DCU0_B10x42
> > + VF610_PAD_PTE23__DCU0_B20x42
> > + VF610_PAD_PTE24__DCU0_B30x42
> > + VF610_PAD_PTE25__DCU0_B40x42
> > + VF610_PAD_PTE26__DCU0_B50x42
> > + VF610_PAD_PTE27__DCU0_B60x42
> > + VF610_PAD_PTE28__DCU0_B70x42
> > + >;
> > + };
> > +
> > pinctrl_adc0_ad5: adc0ad5grp {
> > fsl,pins = <
> > VF610_PAD_PTC30__ADC0_SE5
> 0xa1
> > @@ -370,6 +414,10 @@
> > status = "okay";
> > };
> >
> > +&tcon0 {
> > + status = "okay";
> > +};
> > +
> > &uart1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_uart1>;
>
--
Tony Felice
Support Engineering Manager
Timesys Corporation
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160627/85c17d71/attachment-0001.html>
[PATCH 2/2] drm/amdgpu: sanitice fence numbers
On 25.06.2016 04:51, Christian König wrote: > From: Christian König Typo in the subject: Choose "sanitize" or "sanitise", depending on your preference. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Precise vblank timestamping for VC4 kms.
On 06/23/2016 09:28 AM, Daniel Vetter wrote: > On Thu, Jun 23, 2016 at 8:17 AM, Mario Kleiner > wrote: >> The following patch implements precise vblank timestamping >> for RaspberryPi's VC4, at least for standard progressive >> scan display modes. >> >> It has been tested on the HDMI output with half a dozen different >> video modes using special hardware measurement equipment to compare >> generated time stamps against reality. According to the tests it >> works well in its current form. >> >> Due to hw limitations of the VC4, timestamps can't be scanline >> accurate when taken within vblank, as explained in the patch, >> but at least they will never be off by more than 1 vblank >> duration, and are typically still accurate to ~0.1 msecs >> for the common case when the timestamping is triggered from >> vblank interrupt. >> >> The patch exposed some problems with how the drm core handles >> calculation of vblank timestamping constants for interlaced >> video modes in drm_calc_timestamping_constants(). Seems it cuts >> the expected frame duration framedur_ns into half for interlaced >> modes two times, so it ends up expecting a field duration half >> of what it should be and then miscalculates vblank counter increments >> as soon as vblank timestamping is supported and the core tries to >> derive vblank counts from it. To work around this bug, for the >> moment the vblank timestamping will disable itself for interlaced >> modes and only work for regular progressive scan. >> >> Eric: In the patch i need to calculate fifo_lines as the capacity >> of what seems to be a multi-line fifo line buffer for composited output >> scanlines between the HVS and the PV, or maybe an input fifo between >> the framebuffer(s) and the HVS? The formula i currently use is ad-hoc, >> found by trial and error. It works reasonably well for a range of >> video modes i could test with my measurement equipment, but it would >> be good to replace it by one that is actually accurately derived from >> your hardware docs. >> >> Other than that, this should be good to go. > > Just out of curiosity: Is there no timestamp register that samples a > refclock on each vblank that could be used instead? That seems to be a > somewhat common feature afaict (but I don't know about vc4). > -Daniel > Not according to what Eric told me. I also couldn't find anything in the documented register set from vc4_regs.h, or poking around the neighborhood of those regs. The HVS register i use now seems to be the only thing one can use to approximate the typical scanoutpos method well enough to be useful and precise enough. It would be good to know what other SoCs support such timetamp regs. Using them probably wouldn't be much more simple than the current scanoutpos method, with the need to then synchronize/map the gpu clocks time to the hosts CLOCK_MONOTONIC time, but having the precision timestamps would be valuable, also for modern compositors. -mario
[PATCH] rnndb: mdp5: Remove MDP offsets
MDSS and MDP5 have been separated out in the kernel driver. We no longer need to keep a track of the start of MDP addesses within MDSS. Also, clean up the MDP5 register name prefix. Change it from "REG_MDP5_MDP_" to "REG_MDP5_". Signed-off-by: Archit Taneja --- Used by the "Enable DT Support" kernel patchset: https://lists.freedesktop.org/archives/dri-devel/2016-June/111837.html rnndb/mdp/mdp5.xml | 127 ++--- 1 file changed, 62 insertions(+), 65 deletions(-) diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml index c829737..de9560b 100644 --- a/rnndb/mdp/mdp5.xml +++ b/rnndb/mdp/mdp5.xml @@ -139,74 +139,71 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + + + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[GIT PULL] drm/mediatek: MT8173 gamma & dither support
On 06/24/2016 09:27 AM, Bibby Hsieh wrote: > Hi Dave, > > Please consider merging this tag, which contains the v2 MT8173 gamma & dither > function patches I sent on 2016-06-17, rebased onto v4.7-rc1. There have been > no further comments. > > Thanks > Bibby > > The following changes since commit 1a695a905c18548062509178b98bc91e67510864: > > Linux 4.7-rc1 (2016-05-29 16:29:24 GMT) > > are available in the git repository at: > > git at github.com:BibbyHsieh/linux4.7-rc1.git > > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9: > > drm/mediatek: Add gamma correction > > - As far as I can see, your branch has 3 patches on top from Eddie. It seems to me as if you didn't send your patches to the mailinglist before? Anyway this branch does not fulfill the rules to get merged into the linux kernel. Why do you send a pull request? The normal process is to send the patches via email and if the maintainer wants you can send a pull request once the patches are ready to be merged. Regards, Matthias > This is MT8173 gamma & dither support PATCH v2, based on 4.7-rc1. > > Changes since v1: > -According to the suggestion from Daniel, > we used the new atomic color management. > -Applied gamma function at GAMMA engine (path 2). > -Made dithering function support hardware mirroring well. > -Removed the bpc variable from mtk_drm_crtc struct. > - > > Bibby Hsieh (2): > drm/mediatek: Add gamma correction > drm/mediatek: set mt8173 dithering function > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 26 - > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 147 > ++- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16 ++- > 6 files changed, 184 insertions(+), 12 deletions(-) >
[PATCH 3/6] drm/amd/amdgpu: Set DRIVER_MODESET feature flag at build time
On Mon, Jun 27, 2016 at 5:37 AM, Frank Binns wrote:
> On 24/06/16 23:08, Alex Deucher wrote:
>>
>> On Fri, Jun 24, 2016 at 1:15 PM, Frank Binns
>> wrote:
>>>
>>> This flag was being set unconditionally at runtime so just set it at
>>> compile time instead.
>>>
>>> Signed-off-by: Frank Binns
>>
>> Reviewed-by: Alex Deucher
>>
>> Do you want to take this as part of the patch set, or should I apply
>> this to my tree?
>>
>> Alex
>
>
> This patch is independent of the rest so I'm happy for you to
> apply it to your tree.
>
Applied. thanks!
Alex
> Thanks
> Frank
>
>
>>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> index f888c01..7fe7f3c 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> @@ -515,7 +515,7 @@ static struct drm_driver kms_driver = {
>>> .driver_features =
>>> DRIVER_USE_AGP |
>>> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
>>> - DRIVER_PRIME | DRIVER_RENDER,
>>> + DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET,
>>> .dev_priv_size = 0,
>>> .load = amdgpu_driver_load_kms,
>>> .open = amdgpu_driver_open_kms,
>>> @@ -590,7 +590,6 @@ static int __init amdgpu_init(void)
>>> DRM_INFO("amdgpu kernel modesetting enabled.\n");
>>> driver = &kms_driver;
>>> pdriver = &amdgpu_kms_pci_driver;
>>> - driver->driver_features |= DRIVER_MODESET;
>>> driver->num_ioctls = amdgpu_max_kms_ioctl;
>>> amdgpu_register_atpx_handler();
>>> /* let modprobe override vga console setting */
>>> --
>>> 2.7.4
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
[PATCH] drm/mediatek: add ARM_SMCCC dependency
On 06/27/2016 11:22 AM, Arnd Bergmann wrote:
> ARM SMCCC is only set for ARMv7 and ARMv8 CPUs, but we currently
> allow the driver to be build for older architecture levels as
> well, which results in a link failure:
>
> drivers/gpu/built-in.o: In function `mtk_hdmi_hw_make_reg_writable':
> :(.text+0x1e737c): undefined reference to `arm_smccc_smc'
>
> This adds a Kconfig dependency. The patch applies on my two
> previous fixes that are not yet applied, so please apply all
> three to get randconfig builds to work correctly.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
> ---
> drivers/gpu/drm/mediatek/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Matthias Brugger
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/drivers/gpu/drm/mediatek/Kconfig
> index 96ebf8bb6024..294de4549922 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -3,6 +3,7 @@ config DRM_MEDIATEK
> depends on DRM
> depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
> depends on COMMON_CLK
> + depends on HAVE_ARM_SMCCC
> depends on OF
> select DRM_GEM_CMA_HELPER
> select DRM_KMS_HELPER
>
[PATCH] drm/mediatek: add ARM_SMCCC dependency
ARM SMCCC is only set for ARMv7 and ARMv8 CPUs, but we currently
allow the driver to be build for older architecture levels as
well, which results in a link failure:
drivers/gpu/built-in.o: In function `mtk_hdmi_hw_make_reg_writable':
:(.text+0x1e737c): undefined reference to `arm_smccc_smc'
This adds a Kconfig dependency. The patch applies on my two
previous fixes that are not yet applied, so please apply all
three to get randconfig builds to work correctly.
Signed-off-by: Arnd Bergmann
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
---
drivers/gpu/drm/mediatek/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 96ebf8bb6024..294de4549922 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -3,6 +3,7 @@ config DRM_MEDIATEK
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
depends on COMMON_CLK
+ depends on HAVE_ARM_SMCCC
depends on OF
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
--
2.9.0
drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c:1812: possible pointless variable ?
Hello there, linux-4.7-rc5/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c:1812]: (style) Variable 'stretch_amount2' is assigned a value that is never used. Source code is else if (stretch_amount == 3 || stretch_amount == 4) stretch_amount2 = 1; Suggest either use the variable in some way, or delete it. Regards David Binderman
[PATCH v3 14/15] drm: vmwgfx: Replace drm_fb_get_bpp_depth() with drm_format_info()
This patch looks good to me:
Reviewed-by: Sinclair Yeh
On Thu, Jun 09, 2016 at 02:32:18AM +0300, Laurent Pinchart wrote:
> The driver is the last users of the drm_fb_get_bpp_depth() function. It
> should ideally be converted to use struct drm_mode_fb_cmd2 instead of
> the legacy struct drm_mode_fb_cmd internally, but that will require
> broad changes across the code base. As a first step, replace
> drm_fb_get_bpp_depth() with drm_format_info() in order to stop exporting
> the function to drivers.
>
> The new DRM_ERROR() message comes from the vmw_create_dmabuf_proxy(),
> vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_dmabuf()
> functions that currently print an error if the pixel format is
> unsupported.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 55231cce73a0..1a7187f472de 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -980,14 +980,22 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
> drm_device *dev,
> struct vmw_dma_buffer *bo = NULL;
> struct ttm_base_object *user_obj;
> struct drm_mode_fb_cmd mode_cmd;
> + const struct drm_format_info *info;
> int ret;
>
> + info = drm_format_info(mode_cmd2->pixel_format);
> + if (!info || !info->depth) {
> + DRM_ERROR("Unsupported framebuffer format %s\n",
> + drm_get_format_name(mode_cmd2->pixel_format));
> + return ERR_PTR(-EINVAL);
> + }
> +
> mode_cmd.width = mode_cmd2->width;
> mode_cmd.height = mode_cmd2->height;
> mode_cmd.pitch = mode_cmd2->pitches[0];
> mode_cmd.handle = mode_cmd2->handles[0];
> - drm_fb_get_bpp_depth(mode_cmd2->pixel_format, &mode_cmd.depth,
> - &mode_cmd.bpp);
> + mode_cmd.depth = info->depth;
> + mode_cmd.bpp = info->cpp[0] * 8;
>
> /**
>* This code should be conditioned on Screen Objects not being used.
> --
> Regards,
>
> Laurent Pinchart
>
[PATCH 3/6] drm/amd/amdgpu: Set DRIVER_MODESET feature flag at build time
On 24/06/16 23:08, Alex Deucher wrote:
> On Fri, Jun 24, 2016 at 1:15 PM, Frank Binns
> wrote:
>> This flag was being set unconditionally at runtime so just set it at
>> compile time instead.
>>
>> Signed-off-by: Frank Binns
> Reviewed-by: Alex Deucher
>
> Do you want to take this as part of the patch set, or should I apply
> this to my tree?
>
> Alex
This patch is independent of the rest so I'm happy for you to
apply it to your tree.
Thanks
Frank
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index f888c01..7fe7f3c 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -515,7 +515,7 @@ static struct drm_driver kms_driver = {
>> .driver_features =
>> DRIVER_USE_AGP |
>> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
>> - DRIVER_PRIME | DRIVER_RENDER,
>> + DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET,
>> .dev_priv_size = 0,
>> .load = amdgpu_driver_load_kms,
>> .open = amdgpu_driver_open_kms,
>> @@ -590,7 +590,6 @@ static int __init amdgpu_init(void)
>> DRM_INFO("amdgpu kernel modesetting enabled.\n");
>> driver = &kms_driver;
>> pdriver = &amdgpu_kms_pci_driver;
>> - driver->driver_features |= DRIVER_MODESET;
>> driver->num_ioctls = amdgpu_max_kms_ioctl;
>> amdgpu_register_atpx_handler();
>> /* let modprobe override vga console setting */
>> --
>> 2.7.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Add DT bindings documentation for OpenCores VGA/LCD controller
On Mon, Jun 27, 2016 at 6:21 AM, Andrea Merello wrote: > On Fri, Jun 10, 2016 at 7:36 PM, Rob Herring wrote: >> On Thu, Jun 09, 2016 at 03:33:19PM +0200, Andrea Merello wrote: >>> Signed-off-by: Andrea Merello >>> Cc: Stefan Kristiansson >>> Cc: Tomi Valkeinen >>> Cc: Francesco Diotalevi >>> Cc: Claudio Lorini >>> --- >>> .../bindings/display/opencores,ocdrm.txt | 27 >>> ++ >>> 1 file changed, 27 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/opencores,ocdrm.txt >>> >>> diff --git a/Documentation/devicetree/bindings/display/opencores,ocdrm.txt >>> b/Documentation/devicetree/bindings/display/opencores,ocdrm.txt >>> new file mode 100644 >>> index 000..8d36de5 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/display/opencores,ocdrm.txt >>> @@ -0,0 +1,27 @@ >>> +OpenCores VGA/LCD controller >>> + >>> +Required properties: >>> +- compatible: "opencores,ocdrm" >> >> Name this based on what the h/w block is called, not a Linux subsystem. > > Ok. > > Something like "opencores,video" ? The VGA/LCD controller IP block is just called "video"? > The older framebuffer driver has "opencores,ocfb"; I assumed the > suffix -fb was because of it is a "framebuffer" _driver_, but maybe it > is because they consider it a "framebuffer" _device_. Could be either. The FB and DRM "bindings" have been flawed in general. The bindings should describe hardware blocks and the connections between them, not what the kernel subsystem wants. > Maybe I can keep the same "compatible" string? Is it ok to have two > drivers (maybe temporarily, until the older one fades out) with the > same "compatible" ? In principal, that is exactly how it should work. However, the FB binding is probably incomplete or flawed. If keeping the compatible string is enough for it to work, then that is fine. >> Is there any sort of versioning for OpenCore IP that you can include in >> the name? > > Not sure about this. I'll check. > >>> +- reg: Physical base address and length of the controller's registers. >>> +- clocks: Must contain an entry for the pixelclock generator. >>> + See ../clocks/clock-bindings.txt for details. >>> + >>> +Required sub-nodes: >>> +- port: the connection to a DRM bridge. The connection is modelled >> >> Don't include Linux driver details (DRM) in bindings. > > You mean telling that the port must be a connection to a DRM bridge, > leaving out further details? The binding itself and description should not contain the word DRM. Just say connection to bridge chip or connector. Rob
[Bug 119831] "acpi=off" required to boot - MSI laptop G72 6QE - Intel Skylake
https://bugzilla.kernel.org/show_bug.cgi?id=119831 Zhang Rui changed: What|Removed |Added Component|Other |Video(DRI - non Intel) Assignee|rui.zhang at intel.com |drivers_video-dri at kernel-bu ||gs.osdl.org Product|ACPI|Drivers --- Comment #9 from Zhang Rui --- This seems to be a graphics issue to me. Reassign to the graphics expert. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 121021] drm/i915: kernel suspend during booting up
https://bugzilla.kernel.org/show_bug.cgi?id=121021 zhiquan.lee at gmail.com changed: What|Removed |Added Component|Video(DRI - non Intel) |Video(Other) Hardware|Intel |i386 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 121021] drm/i915: kernel suspend during booting up
https://bugzilla.kernel.org/show_bug.cgi?id=121021 --- Comment #3 from zhiquan.lee at gmail.com --- I've added debug kernel command line parameters: drm.debug=0xf when captured the log. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 121021] drm/i915: kernel suspend during booting up
https://bugzilla.kernel.org/show_bug.cgi?id=121021 --- Comment #2 from zhiquan.lee at gmail.com --- Created attachment 221261 --> https://bugzilla.kernel.org/attachment.cgi?id=221261&action=edit kernel 3.14.48 boot up log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 121021] drm/i915: kernel suspend during booting up
https://bugzilla.kernel.org/show_bug.cgi?id=121021 --- Comment #1 from zhiquan.lee at gmail.com --- Created attachment 221251 --> https://bugzilla.kernel.org/attachment.cgi?id=221251&action=edit kernel 4.6.2 boot up log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 121021] New: drm/i915: kernel suspend during booting up
https://bugzilla.kernel.org/show_bug.cgi?id=121021 Bug ID: 121021 Summary: drm/i915: kernel suspend during booting up Product: Drivers Version: 2.5 Kernel Version: 4.7-rc3, 4.6.2, 3.14.48, Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: zhiquan.lee at gmail.com Regression: No Created attachment 221241 --> https://bugzilla.kernel.org/attachment.cgi?id=221241&action=edit kernel 4.7-rc3 boot up log Kernel cannot boot up on my machine, I've tried to upgrade kernel from 3.14.48 to 4.6.2 and 4.7-rc3, the problem still cannot be solved. After I disabled KMS via the kernel command line parameters: nomodeset i915.modeset=0, the issue was bypassed. Therefore, I doubt the problem in DRM/i915 driver. Here is my machine hardware info: CPU: Intel Celeron M 373 1.0Ghz, FANLESS 400 MHz FSB, 512KB L2 Chipsets: Intel 910GMLE/ICH6M Chipset Codenames: Alviso-GM Video: Intel "Integrated Graphics Device" with integrated Dual Independent output Video Adapter: Intel® Integrated 82915GM Express Chipset And the boot up trace can be find in attachments, with kernel command line parameters: -- You are receiving this mail because: You are watching the assignee of the bug.
