Hi,
converting the IPU IRQ handling to use irq_domain_add_linear is listed in
drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
and add a linear irq domain.
regards
Philipp
---
drivers/staging
The IPU has a lot of interrupts. Instead of allocating descs for all
of them, register a linear irq domain and create mappings as needed.
This was listed in the TODO as a prerequisite to move the IPU driver
out of staging.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/TODO
There are 15 32-bit registers altogether.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-prv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
index 5518028..12d7eaf 1006
Am Freitag, den 21.06.2013, 10:27 +0200 schrieb Philipp Zabel:
> Hi,
>
Sorry, copy & paste error.
The correct subject is IPU linear irq domain:
> converting the IPU IRQ handling to use irq_domain_add_linear is listed in
> drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
[...]
> > > > You already need some kind of IPC between the two tasks, as I suspect
> > > > even in your example it wouldn't make much sense to queue the buffer
> > > > over and over again in task B without task A writing anything to it.
Since commit 8cf1e9811471f2910fa38dc1b28e1789080ba961
("drm: Add consistency check for page-flipping") drm_mode_page_flip_ioctl
contains a WARN_ON that triggers if the .page_flip callback didn't update
the crtc->fb pointer to the new framebuffer immediately.
Signed-off-by: Philipp Zabel
---
driv
Hi,
the following patches remove some unused variables, replace some
hard-coded channel numbers with existing descriptive defines, fix
the DMFC bandwidth (or rather: FIFO space) allocation, and update
ipu_page_flip() to immediately set crtc->fb.
regards
Philipp
---
drivers/staging/imx-drm/i
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-drm-core.c | 3 ---
drivers/staging/imx-drm/ipuv3-crtc.c | 5 -
2 files changed, 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 6455305..56d6bc4 100644
--- a/dri
The IPU can request up to four pixels per access, which gives four
times the bandwidth compared to what the driver currently assumes.
After correcting this, we have to increase safety margins for
bandwidth requirement calculations.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 1dc9817..2e97c33 100644
--- a/drivers/staging/imx-drm/i
2013/6/21 Lucas Stach
> Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
> [...]
> > > > > You already need some kind of IPC between the two tasks, as I
> suspect
> > > > > even in your example it wouldn't make much sense to queue the
> buffer
> > > > > over and over again in task B w
On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
> There is a report on RT about "BUG: scheduling while atomic" because the
> sleeping lock is taken in tracing context. This patch simply moves
> locking operation out of the tracing macro.
No. This enables the IRQ, as well
On Wed, Apr 03, 2013 at 01:33:09PM +0200, Maarten Lankhorst wrote:
> Op 03-04-13 10:05, Dan Carpenter schreef:
> > The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
> >
> > Signed-off-by: Dan Carpenter
> Acked-by: Maarten Lankhorst
We still need this patch in linux-next.
re
Hello Alex Deucher,
The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
from Dec 4, 2009, leads to the following warning:
"drivers/gpu/drm/radeon/radeon_atombios.c:950
radeon_get_atom_connector_info_from_supported_devices_table()
error: buffer overflow 'supported_devic
Hi Inki,
please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.
Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
[...]
> Yeah, you'll some knowledge and understanding about the API
> you are
> working
This depends on the patch "genirq: Generic chip: Add linear irq domain support"
and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
irq chip implementation is reused.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 90 +-
This depends on the patch "genirq: irqchip: Add mask to block out invalid irqs"
and masks out reserved bits using the unused interrupt bitfield.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/s
Hi,
with linear domain support in the generic irq chip framework, we can drop the
custom irq_chip / irq_domain_ops altogether and use the generic irq chip
implementation instead. The following two patches depend on
"genirq: Generic chip: Add linear irq domain support" and
"genirq: irqchip: Add mas
On Fri, Jun 21, 2013 at 8:25 AM, Dan Carpenter wrote:
> Hello Alex Deucher,
>
> The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
> from Dec 4, 2009, leads to the following warning:
> "drivers/gpu/drm/radeon/radeon_atombios.c:950
> radeon_get_atom_connector_info_from_supported_
2013/6/21 Lucas Stach :
> Hi Inki,
>
> please refrain from sending HTML Mails, it makes proper quoting without
> messing up the layout everywhere pretty hard.
>
Sorry about that. I should have used text mode.
> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
> [...]
>
>> Yeah, y
On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae wrote:
> 2013/6/21 Lucas Stach :
>> Hi Inki,
>>
>> please refrain from sending HTML Mails, it makes proper quoting without
>> messing up the layout everywhere pretty hard.
>>
>
> Sorry about that. I should have used text mode.
>
>> Am Freitag, den 21.06.2
The series of patches that follow are intended to address issues that
have been found in the tilcdc drm driver. The patchset enables support
for screen resolutions with horizontal resolutions greater than 1024
pixels. The patchset also addresses a limitation where certain
monitor timings would ove
TI LCD controller version 2 has an extended eleventh
bit that enables horizontal resolutions greater than
1024 pixels to be specified (upto 2048). This patch
adds support for setting this bit on LCDC V2.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 15 +++
Adding support for max-pixelclock and max-width device tree
entries. As some devices that use the tilcdc hardware module
have restrictions on the allowed/tested values. Also update DT
bindings document to reflect new parameters.
Signed-off-by: Darren Etheridge
---
.../devicetree/bindings/drm/ti
The tilcdc has a number of limitations for the allowed sizes of
the various adjustable timing parameter. Some modes are outside
of these timings. This commit will prune modes that report timings
that will overflow the allowed sizes in the tilcdc.
Signed-off-by: Darren Etheridge
---
drivers/gpu
When hooking up to an HDMI analyzer noticed some timings were
off by one. Referring to the hardware technical reference manual
for the lcd controller some of the timing registers use 0 to
represent 1. This patch addresses that issue.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/t
keeping checkpatch happy.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 283e0a6..6118651 100644
-
In certain senarios drm will initialize before i2c this means that i2c
slave devices like the nxp tda998x will fail to be probed. This patch
detects this condition then defers the probe of the slave device and
the tilcdc main driver.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/ti
From: Pantelis Antoniou
Bits weren't cleared so resolution changes didn't work.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crt
Hey,
I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
(3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
I found that i915 would halt with a
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set m
Common properties for I2C and Hdmi Subsystem is moved to exynos5
dtsi file. It also adds Device tree nodes and clocks information
for exynos5420 SoC. It adds pinctrl node for hdmi hpd gpio and
update binding documents.
This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
at http://git.k
I2C nodes shares many properties across exynos5 SoCs (exynos5250
and exyno5420). Common code is moved to exynos5.dtsi which is
included in exyno5250 and exynos5420 SoC files.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5.dtsi| 36 +
arch/arm/
From: Andrew Bresticker
This adds device-tree nodes for the i2c busses on Exynos
5420 platforms.
Signed-off-by: Andrew Bresticker
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/
On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> >
> > > -Original Message-
> > > From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> > > [mailto:dri-devel-bounces+inki.dae=samsung@lists.freed
* Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes si
* Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]
'TTM' here reads like a person - but in reality it's the TTM graphics
subsystem, right?
Please clarify this portion of the text.
Thanks,
Ingo
___
* Maarten Lankhorst wrote:
> Well they've helped me with some of the changes and contributed some
> code and/or fixes, but if acked-by is preferred I'll use that..
Such contributions can be credited in the changelog, and/or copyright
notices, and/or the code itself. The signoff chain on the o
Hdmi Subsystem nodes shares many properties across exynos5 SoCs
(exynos5250 and exyno5420). Common code is moved to exynos5.dtsi
which is included in exyno5250 and exynos5420 SoC files.
It also renames the hdmi and mixer nodes as per dt naming
convention in the format name@phy_add.
Signed-off-by:
Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 20
arch/arm/boot/dts/exynos5420.dtsi |8
2 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/exynos54
Add clocks for hdmi and mixer for exynos5420 SoC.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 93caef7..5fa4093 100644
--- a/arch/arm/boo
Add pinctrl node for hdmi-hpd gpio pin to exynos5420
device tree files.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.
From: Sachin Kamat
Exynos SoCs use pinctrl to configure GPIOs. Update the document
to reflect this change.
Signed-off-by: Sachin Kamat
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -
Adding information about clocks to the binding documentation
for exynos mixer and hdmi.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt | 14 +-
Documentation/devicetree/bindings/video/exynos_mixer.txt |4
2 files changed, 17 insert
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive and interlaced modes. Sync timings for a
bunch of modes have also been verified with an oscilloscope near-end
(TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
> + ref_pix = 3 + mode->hsync_start - mode->hdisplay;
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
>
On 06/20/2013 10:06 PM, Russell King - ARM Linux wrote:
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
+ ref_pix = 3 + mode->hsync_start - mode->hdisplay;
+ de_pix_s = mode->htotal - mode->hdisplay;
+ de_pix_e = de_pix_s + mode->hdisplay;
+
Quoting Kukjin Kim (2013-06-19 07:01:17)
> On 06/19/13 13:04, Rahul Sharma wrote:
> > + mike
> >
> Mike, I'm waiting for your reply on this. If you're OK, let me take this
> series on top of exynos5420 stuff in samsung tree.
>
> Of course, if any concerns, please let me know.
I never got these p
There is a report on RT about "BUG: scheduling while atomic" because the
sleeping lock is taken in tracing context. This patch simply moves
locking operation out of the tracing macro.
Reported-by: Joakim Hernberg
[c.e...@osadl.org: pull out seqno and define it so it compiled]
Signed-off-by: Sebas
On 06/21/2013 01:08 PM, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
>> There is a report on RT about "BUG: scheduling while atomic" because the
>> sleeping lock is taken in tracing context. This patch simply moves
>> locking operation out of the
Hey Dave,
Do we care about these warnings? I'm not sure how to get around them.
thanks,
Chris
P.S, this is my last day at Matrox, but I'll maintain it from another
email.
On Fri, Jun 21 2013, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next mast
Quoting Rahul Sharma (2013-06-20 21:47:35)
> On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette
> wrote:
> > Quoting Kukjin Kim (2013-06-19 07:01:17)
> >> On 06/19/13 13:04, Rahul Sharma wrote:
> >> > + mike
> >> >
> >> Mike, I'm waiting for your reply on this. If you're OK, let me take this
> >> s
It is generally considered bad style to enclose function prototypes
in header files in #ifdef. This case illustrates why that is:
The tegra host1x driver calls into the debugfs functions if
CONFIG_DEBUG_FS is enabled, but that code is otherwise already
discarded by the compiler, so leaving the prot
2013/6/22 Jerome Glisse :
> On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae wrote:
>> 2013/6/21 Lucas Stach :
>>> Hi Inki,
>>>
>>> please refrain from sending HTML Mails, it makes proper quoting without
>>> messing up the layout everywhere pretty hard.
>>>
>>
>> Sorry about that. I should have used tex
On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
CC-ing Imre,
Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") is the cause
of the regression.
If I revert your patch it boots fine without any tro
> git://anongit.freedesktop.org/tegra/linux.git drm/fixes
>
> for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
>
> gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
>
> I know this comes awfully late and is much bigger than I'd like. It's
> all my f
Hi Linus,
one core fix, but mostly radeon fixes for s/r and big endian UVD support,
and a fix to stop the GPU being reset for no good reason, and crashing
people's machines.
Dave.
The following changes since commit df63d3ecbca514bad99513b2401448d19a9bb92e:
Merge tag 'drm-intel-fixes-2013-06
On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette
wrote:
> Quoting Kukjin Kim (2013-06-19 07:01:17)
>> On 06/19/13 13:04, Rahul Sharma wrote:
>> > + mike
>> >
>> Mike, I'm waiting for your reply on this. If you're OK, let me take this
>> series on top of exynos5420 stuff in samsung tree.
>>
>> Of
+Mike
On Mon, Jun 10, 2013 at 4:17 PM, Rahul Sharma wrote:
> This patch is already posted at
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg18331.html
> and
>
> Reviewed-by: Doug Anderson
>
> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma
> wrote:
>> From: Arun Kumar K
>
+Mike
On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma
wrote:
> hdmi driver needs to change the parent of hdmi clock
> frequently between pixel clock and hdmiphy clock. hdmiphy is
> not stable after power on and for a short interval while changing
> the phy configuration. For this duration pixel cl
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma
wrote:
> hdmi driver needs hdmiphy clock which is one of the parent
> for hdmi mux clock. This is required while changing the parent
> of mux clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5250-cl
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma
wrote:
> Adding sysmmu clock for tv for exynos5250 SoC. It also
> adds aclk200_disp1 mux which is the actual parent of the
> disp1 block (contains hdmi, mixer, sysmmu_tv).
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindi
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma
wrote:
> parent of hdmi and mixer block is mentioned as aclk200 which is
> not correct. It is clocked by the ouput of aclk200_disp1. Hence
> parent for mixer and hdmi clocks is changed to aclk200_disp1.
>
> Signed-off-by: Rahul Sharma
> ---
>
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma
wrote:
> Add sclk_hdmiphy to the list of exposed clocks. This is required
> by hdmi driver to change the parent of hdmi clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> dr
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma
wrote:
> Adding sysmmu clock for tv for exynos5420.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> drivers/clk/samsung/clk-exynos5420.c |3 ++-
> 2
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma
wrote:
> Listing sclk_hdmiphy at 0th position in the list of parents is
> causing wrong configuration in reg SRC_DISP10.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/clk/samsung/clk-exynos5420.c |2 +-
> 1 file changed, 1 insertion(+),
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma
wrote:
> hdmi driver needs to change the parent of hdmi clock
> to pixel clock or hdmiphy clock, based on the stability
> of hdmiphy. This patch is exposing the mux for changing
> the parent.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentat
+Mike
On Tue, Jun 18, 2013 at 7:54 PM, Rahul Sharma wrote:
> With this patch, it is at par with Exynos5250 and Exynos4 clocks
> where sclk_pixel ID is assigned to a divider clock but in real,
> sclk_pixel is listed under gate clocks (enum value).
>
> Alternate to this, I can allocate a new ID, di
gt;> - compatible = "samsung,exynos5-hdmiphy";
> >>> + compatible = "samsung,exynos4212-hdmiphy";
> >>> reg =<0x38>;
> >>> };
> >>> };
> >>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> >>>
Thanks Mr. Dae, nothing else for this series.
On Fri, Jun 21, 2013 at 10:47 AM, Inki Dae wrote:
>
>
>
> 2013/6/20 Rahul Sharma
>>
>> Thanks Mr. Kim,
>>
>> I will post v4 with aforesaid change.
>>
>
> You don't need to re-post it. I gonna change it to "ARM/dts: change
> compatible strings for Ex
Hi,
converting the IPU IRQ handling to use irq_domain_add_linear is listed in
drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
and add a linear irq domain.
regards
Philipp
---
drivers/staging
The IPU has a lot of interrupts. Instead of allocating descs for all
of them, register a linear irq domain and create mappings as needed.
This was listed in the TODO as a prerequisite to move the IPU driver
out of staging.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/TODO
There are 15 32-bit registers altogether.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-prv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
index 5518028..12d7eaf 1006
Am Freitag, den 21.06.2013, 10:27 +0200 schrieb Philipp Zabel:
> Hi,
>
Sorry, copy & paste error.
The correct subject is IPU linear irq domain:
> converting the IPU IRQ handling to use irq_domain_add_linear is listed in
> drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
[...]
> > > > You already need some kind of IPC between the two tasks, as I suspect
> > > > even in your example it wouldn't make much sense to queue the buffer
> > > > over and over again in task B without task A writing anything to it.
Since commit 8cf1e9811471f2910fa38dc1b28e1789080ba961
("drm: Add consistency check for page-flipping") drm_mode_page_flip_ioctl
contains a WARN_ON that triggers if the .page_flip callback didn't update
the crtc->fb pointer to the new framebuffer immediately.
Signed-off-by: Philipp Zabel
---
driv
Hi,
the following patches remove some unused variables, replace some
hard-coded channel numbers with existing descriptive defines, fix
the DMFC bandwidth (or rather: FIFO space) allocation, and update
ipu_page_flip() to immediately set crtc->fb.
regards
Philipp
---
drivers/staging/imx-drm/i
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-drm-core.c | 3 ---
drivers/staging/imx-drm/ipuv3-crtc.c | 5 -
2 files changed, 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 6455305..56d6bc4 100644
--- a/dri
The IPU can request up to four pixels per access, which gives four
times the bandwidth compared to what the driver currently assumes.
After correcting this, we have to increase safety margins for
bandwidth requirement calculations.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 1dc9817..2e97c33 100644
--- a/drivers/staging/imx-drm/i
4. kick off V4L2 processing
>
>
That seems like very specific to Desktop GPU. isn't it?
> So you don't need to wait in userspace and potentially avoid some
> context switches,
Also not true.
> but you still have to make sure that GPU commands are
> queued before you queue the V4L2 operation to make sure things get
> operated on in the right order.
>
>
>
I'd like to say you that my approach is not perfact so may definietly
have many problems and addition works - actually, I found some problems and
are solving them, in addition, the implememtation to generic user side
interfacing mechanism is in progress for the destination - , and thanks to
your comments. However, I think we can try to do for more better something.
Lastly, I'll look forward to keeping up your good advices.
Thanks,
Inki Dae
> Regards,
> Lucas
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130621/71d8da2d/attachment.html>
On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
> There is a report on RT about "BUG: scheduling while atomic" because the
> sleeping lock is taken in tracing context. This patch simply moves
> locking operation out of the tracing macro.
No. This enables the IRQ, as well
On Wed, Apr 03, 2013 at 01:33:09PM +0200, Maarten Lankhorst wrote:
> Op 03-04-13 10:05, Dan Carpenter schreef:
> > The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
> >
> > Signed-off-by: Dan Carpenter
> Acked-by: Maarten Lankhorst
We still need this patch in linux-next.
re
Hello Alex Deucher,
The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
from Dec 4, 2009, leads to the following warning:
"drivers/gpu/drm/radeon/radeon_atombios.c:950
radeon_get_atom_connector_info_from_supported_devices_table()
error: buffer overflow 'supported_devic
Hi Inki,
please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.
Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
[...]
> Yeah, you'll some knowledge and understanding about the API
> you are
> working
This depends on the patch "genirq: Generic chip: Add linear irq domain support"
and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
irq chip implementation is reused.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 90 +-
This depends on the patch "genirq: irqchip: Add mask to block out invalid irqs"
and masks out reserved bits using the unused interrupt bitfield.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/s
Hi,
with linear domain support in the generic irq chip framework, we can drop the
custom irq_chip / irq_domain_ops altogether and use the generic irq chip
implementation instead. The following two patches depend on
"genirq: Generic chip: Add linear irq domain support" and
"genirq: irqchip: Add mas
On Fri, Jun 21, 2013 at 8:25 AM, Dan Carpenter
wrote:
> Hello Alex Deucher,
>
> The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
> from Dec 4, 2009, leads to the following warning:
> "drivers/gpu/drm/radeon/radeon_atombios.c:950
> radeon_get_atom_connector_info_from_supported
On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae wrote:
> 2013/6/21 Lucas Stach :
>> Hi Inki,
>>
>> please refrain from sending HTML Mails, it makes proper quoting without
>> messing up the layout everywhere pretty hard.
>>
>
> Sorry about that. I should have used text mode.
>
>> Am Freitag, den 21.06.2
The series of patches that follow are intended to address issues that
have been found in the tilcdc drm driver. The patchset enables support
for screen resolutions with horizontal resolutions greater than 1024
pixels. The patchset also addresses a limitation where certain
monitor timings would ove
TI LCD controller version 2 has an extended eleventh
bit that enables horizontal resolutions greater than
1024 pixels to be specified (upto 2048). This patch
adds support for setting this bit on LCDC V2.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 15 +++
Adding support for max-pixelclock and max-width device tree
entries. As some devices that use the tilcdc hardware module
have restrictions on the allowed/tested values. Also update DT
bindings document to reflect new parameters.
Signed-off-by: Darren Etheridge
---
.../devicetree/bindings/drm/ti
The tilcdc has a number of limitations for the allowed sizes of
the various adjustable timing parameter. Some modes are outside
of these timings. This commit will prune modes that report timings
that will overflow the allowed sizes in the tilcdc.
Signed-off-by: Darren Etheridge
---
drivers/gpu
When hooking up to an HDMI analyzer noticed some timings were
off by one. Referring to the hardware technical reference manual
for the lcd controller some of the timing registers use 0 to
represent 1. This patch addresses that issue.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/t
keeping checkpatch happy.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 283e0a6..6118651 100644
-
In certain senarios drm will initialize before i2c this means that i2c
slave devices like the nxp tda998x will fail to be probed. This patch
detects this condition then defers the probe of the slave device and
the tilcdc main driver.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/ti
From: Pantelis Antoniou
Bits weren't cleared so resolution changes didn't work.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crt
Hey,
I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
(3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
I found that i915 would halt with a
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set m
There is a report on RT about "BUG: scheduling while atomic" because the
sleeping lock is taken in tracing context. This patch simply moves
locking operation out of the tracing macro.
Reported-by: Joakim Hernberg
[C.Emde at osadl.org: pull out seqno and define it so it compiled]
Signed-off-by: Se
On 06/21/2013 01:08 PM, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
>> There is a report on RT about "BUG: scheduling while atomic" because the
>> sleeping lock is taken in tracing context. This patch simply moves
>> locking operation out of the
1 - 100 of 104 matches
Mail list logo
