[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io
On Fri, Sep 19, 2014 at 09:26:58AM +1000, Dave Airlie wrote: > On 13 September 2014 00:28, Bjorn Helgaas wrote: > > On Fri, Sep 12, 2014 at 5:19 AM, Bruno Pr?mont > > wrote: > >> Bjorn, > >> > >> What is missing to get these two patches pushed to Linus? > > > > Sorry, I've been working on some other regressions and overlooked this > > one. If you open a bugzilla report and mark it as a regression, that > > will help keep this on my radar. > > My MBP is crying? can we get these merged, I can handle if if you want > to ack them for me! Yep, it's in linux-next and I'll send Linus a pull request for the tag [1] tomorrow. I meant to send it tonight, but I had to fix my for-linus branch to remove a duplicate commit and I don't want to send the pull request immediately afterwards. Bjorn [1] https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/tag/?h=for-linus&id=pci-v3.17-fixes-2
[PATCH 2/3] drm/radeon: add command submission IDs
On Thu, Sep 18, 2014 at 08:42:16PM -0400, Jerome Glisse wrote:
> On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> > From: Christian K?nig
> >
> > This patch adds a new 64bit ID as a result to each command submission.
>
> NAK for design reasons.
>
> First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
> I know that hooking up to fence make life easy but this is not how it
> should be done.
>
> What you want to expose is the per ring 32bit seq value and report to user
> space the value and the ring id. To handle the wrap around you add a uniq
> 32bit wrap counter which is incremented every 1 << 30 or some big number
> seq value number (but must be smaller than 1 << 31). Then you use arithmetic
> to determine if a cs seq number is done or not (ie the seq wrap around
> counter diff should not be bigger then 2 or 3) and the seq number should
> obviously be after again using arithmetic diff like jiffies code.
>
> All this being hidden in the kernel all the user space have to know is :
> 32 bit seq value per ring
> 32 bit ring uniq id
> 32 wrap counter per ring
>
> With such scheme you never allocate anything or worry about any fence.
> Way simpler and less code.
>
> Cheers,
> J?r?me
Because code is clearer than words attached is a patch of what i am thinking
about. The arithmetic should be right as well as the coherency and proper
memory barrier. Thought it is completely untested and will require couple
fixes for properly checking userspace arguments and other aspect (see FIXME
in patches).
There is no allocation, it is a pretty small patch, and it provide a fast
ligthweight solution. While the new ioctl argument and return value can be
improved (like reporting more information to userspace like for instance
warning userspace when it is querying very old fences). I think the overall
design is sound.
Let me know.
Cheers,
J?r?me
>
>
> >
> > Signed-off-by: Christian K?nig
> > ---
> > drivers/gpu/drm/radeon/Makefile | 2 +-
> > drivers/gpu/drm/radeon/radeon.h | 13 +-
> > drivers/gpu/drm/radeon/radeon_cs.c | 13 ++
> > drivers/gpu/drm/radeon/radeon_kms.c | 41 +++
> > drivers/gpu/drm/radeon/radeon_seq.c | 229
> >
> > include/uapi/drm/radeon_drm.h | 1 +
> > 6 files changed, 277 insertions(+), 22 deletions(-)
> > create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
> >
> > diff --git a/drivers/gpu/drm/radeon/Makefile
> > b/drivers/gpu/drm/radeon/Makefile
> > index 8cc9f68..21ee928 100644
> > --- a/drivers/gpu/drm/radeon/Makefile
> > +++ b/drivers/gpu/drm/radeon/Makefile
> > @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> > rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
> > \
> > trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> > ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
> > \
> > - radeon_sync.o
> > + radeon_sync.o radeon_seq.o
> >
> > # add async DMA block
> > radeon-y += \
> > diff --git a/drivers/gpu/drm/radeon/radeon.h
> > b/drivers/gpu/drm/radeon/radeon.h
> > index b3b4e96..dbfd346 100644
> > --- a/drivers/gpu/drm/radeon/radeon.h
> > +++ b/drivers/gpu/drm/radeon/radeon.h
> > @@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct
> > radeon_fence *a,
> > }
> >
> > /*
> > + * Userspace command submission identifier generation
> > + */
> > +struct radeon_seq;
> > +
> > +uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence
> > *fence);
> > +struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t id);
> > +void radeon_seq_destroy(struct radeon_seq **seq);
> > +
> > +/*
> > * Tiling registers
> > */
> > struct radeon_surface_reg {
> > @@ -946,7 +955,9 @@ struct radeon_vm_manager {
> > * file private structure
> > */
> > struct radeon_fpriv {
> > - struct radeon_vmvm;
> > + struct radeon_vmvm;
> > + struct mutexseq_lock;
> > + struct radeon_seq *seq;
> > };
> >
> > /*
> > diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> > b/drivers/gpu/drm/radeon/radeon_cs.c
> > index b8f20a5..0c0f0b3 100644
> > --- a/drivers/gpu/drm/radeon/radeon_cs.c
> > +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> > @@ -413,6 +413,19 @@ static void radeon_cs_parser_fini(struct
> > radeon_cs_parser *parser, int error, bo
> > unsigned i;
> >
> > if (!error) {
> > + if (parser->chunk_flags &&
> > + parser->chunk_flags->length_dw > 4) {
> > + struct radeon_fpriv *fpriv = parser->filp->driver_priv;
> > + uint32_t __user *to = parser->chunk_flags->user_ptr;
> > + uint64_t id;
> > +
> > + mutex_lock(&fpriv->seq_lock);
> > + id = radeon_seq_push(&fpriv->seq, parser->ib.fence);
> > + mutex_unlock(&fpriv->seq_lock);
> > +
> > + copy_
[pull] radeon drm-fixes-3.17
Hi Dave, One more fix for radeon. Fixes a regression on rs4xx/rs690/rs740 asics. The following changes since commit 235e6def762557fb209a785386653809451b: Merge tag 'drm-intel-fixes-2014-09-18' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-09-19 10:34:34 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.17 for you to fetch changes up to 226b6d88d0c38bd0817660c79e3bea870dfeee4b: drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page (2014-09-18 21:52:29 -0400) Michel D?nzer (1): drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page drivers/gpu/drm/radeon/rs400.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
On 09/18/2014 11:25 AM, Jean-Francois Moine wrote: > On Thu, 18 Sep 2014 00:13:09 +0300 > Jyri Sarha wrote: > >>> So, Jean-Francois is also trying to do things with the TDA998x - what's >>> the story with that, is this joined up at all? >> >> Not really. This basic functionality does not touch tda998x at all on >> the fly, but just sets i2s configuation in the beginning and bangs the >> bits trough McASP. But as long as the old platform data for tda998x >> still works after Jean-Francois' patches I should be safe. > > It should. And you may test it. > I tested by BBB HDMI audio patches with "[PATCH v5] ASoC: tda998x: Add a codec to the HDMI transmitter", and it works otherwise, but the default for CTS_N_K has changed from 3 to 2. I just needed to change the supported format from S32_LE to S24_LE to compensate the change. >> The problem with the Jean-Francois' patches is the DT support. The BBB >> HDMI video is implemented trough tilcdc-slave mechanism without a DT >> node for the tda encoder, which renders Jean-Francois' approach unusable >> for BBB. > > I used the TDA998x with DT support for a long time with a hack by using > parts of drm_i2c_encoder_init(). Now, I think that this function could > be used as it is just setting no platform_data in info. > >> The whole tilcdc slave approach may not be the most elegant way to use >> the tda driver, but it does not look like it is going to change any time >> soon. > > Right: I proposed a patch for that and it was rejected. > The tilcdc is not actively maintained by anybody ATM and that is why it is so hard to make any bigger changes to it. I hope we can change this at some point, but for now I am just trying to get a simple HDMI audio working on BBB with minimal changes. >> Best regards, >> Jyri >> >> ps. I have been thinking on something similar to Jean-Francois' patch >> for SiI9022 which I have been working on lately. Also I have been >> wondering if it would be possible to come up with a generic ASoC codec >> component driver or library that could be used with any HDMI encoder to >> produce the ASoC codec component. Unfortunately I am in too early stage >> to produce anything more concrete. > > Here are some thoughts about this topic. > > The video and audio worlds don't know about each other. > The only solution I found is to let the encoder create the codec as > a child device. Then, the codec knows from which encoder it depends. > This could have been done using Russell's components, but the codec > should have been declared in the DT. This is not useful. > There is anothere option of putting the ASoC codec code into an ASoC library module and registering the ASoC codec component under the HDMI encoder device. However, this approach does not allow building the ASoC as modules if the HDMI encoder driver is built in. So a separate platform device for the codec component is probably better. > The codec interacts with the encoder in 2 ways: > - it uses the HDMI parameters retrieved by the encoder, > - it gives the audio source type to the encoder. > I used exported functions for that, but, for a generic codec, theses > functions could be given through the codec platform_data. > > The codec declares the DAI(s) prior to know the encoder. The DAI table > must be in the codec because of the snd_soc_dai_ops. > For a generic codec, this DAI table could be built dynamically from > information (name, id) also given through the codec platform_data. > This is pretty much what I have been thinking too. The API between the generic ASoC HDMI codec could use already existing the linux headers derived HDMI standard. The ASoC side code should build the hdmi audio infoframe and configure the stream header bits etc, so basically do all the generic stuff coming from HDMI standard. Writing the bits to the appropriate registers in the encoder chip would be left to the HDMI encoder driver. Best regards, Jyri
[PATCH 2/3] drm/radeon: add command submission IDs
On Thu, Sep 18, 2014 at 05:30:12PM +0200, Christian K?nig wrote:
> From: Christian K?nig
>
> This patch adds a new 64bit ID as a result to each command submission.
NAK for design reasons.
First and foremost we DO NOT WANT TO ALLOCATE ANYTHING for submission id.
I know that hooking up to fence make life easy but this is not how it
should be done.
What you want to expose is the per ring 32bit seq value and report to user
space the value and the ring id. To handle the wrap around you add a uniq
32bit wrap counter which is incremented every 1 << 30 or some big number
seq value number (but must be smaller than 1 << 31). Then you use arithmetic
to determine if a cs seq number is done or not (ie the seq wrap around
counter diff should not be bigger then 2 or 3) and the seq number should
obviously be after again using arithmetic diff like jiffies code.
All this being hidden in the kernel all the user space have to know is :
32 bit seq value per ring
32 bit ring uniq id
32 wrap counter per ring
With such scheme you never allocate anything or worry about any fence.
Way simpler and less code.
Cheers,
J?r?me
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon.h | 13 +-
> drivers/gpu/drm/radeon/radeon_cs.c | 13 ++
> drivers/gpu/drm/radeon/radeon_kms.c | 41 +++
> drivers/gpu/drm/radeon/radeon_seq.c | 229
>
> include/uapi/drm/radeon_drm.h | 1 +
> 6 files changed, 277 insertions(+), 22 deletions(-)
> create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 8cc9f68..21ee928 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
> \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
> \
> - radeon_sync.o
> + radeon_sync.o radeon_seq.o
>
> # add async DMA block
> radeon-y += \
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b3b4e96..dbfd346 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct
> radeon_fence *a,
> }
>
> /*
> + * Userspace command submission identifier generation
> + */
> +struct radeon_seq;
> +
> +uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence
> *fence);
> +struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t id);
> +void radeon_seq_destroy(struct radeon_seq **seq);
> +
> +/*
> * Tiling registers
> */
> struct radeon_surface_reg {
> @@ -946,7 +955,9 @@ struct radeon_vm_manager {
> * file private structure
> */
> struct radeon_fpriv {
> - struct radeon_vmvm;
> + struct radeon_vmvm;
> + struct mutexseq_lock;
> + struct radeon_seq *seq;
> };
>
> /*
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index b8f20a5..0c0f0b3 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -413,6 +413,19 @@ static void radeon_cs_parser_fini(struct
> radeon_cs_parser *parser, int error, bo
> unsigned i;
>
> if (!error) {
> + if (parser->chunk_flags &&
> + parser->chunk_flags->length_dw > 4) {
> + struct radeon_fpriv *fpriv = parser->filp->driver_priv;
> + uint32_t __user *to = parser->chunk_flags->user_ptr;
> + uint64_t id;
> +
> + mutex_lock(&fpriv->seq_lock);
> + id = radeon_seq_push(&fpriv->seq, parser->ib.fence);
> + mutex_unlock(&fpriv->seq_lock);
> +
> + copy_to_user(&to[3], &id, sizeof(uint64_t));
> + }
> +
> /* Sort the buffer list from the smallest to largest buffer,
>* which affects the order of buffers in the LRU list.
>* This assures that the smallest buffers are added first
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 85ee6f7..38880af 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -578,39 +578,34 @@ void radeon_driver_lastclose_kms(struct drm_device *dev)
> */
> int radeon_driver_open_kms(struct drm_device *dev, struct drm_file
> *file_priv)
> {
> + struct radeon_fpriv *fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
> struct radeon_device *rdev = dev->dev_private;
> int r;
>
> - file_priv->driver_priv = NULL;
> + if (unlikely(!fpriv))
> + return -ENOMEM
[Bug 83996] [drm:r100_ring_test] *ERROR* radeon: ring test failed - since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]
https://bugs.freedesktop.org/show_bug.cgi?id=83996 --- Comment #4 from jospezial --- (In reply to comment #3) > Created attachment 106470 [details] [review] > Fix typo 'addr' -> 'entry' in rs400_gart_set_page > > Does this patch fix the problem? > > Please test it without Christian's patch, that one can't work correctly > because it doesn't set the correct GART page flags in all cases. This fixes the bug. Thank you all so much! Will I see the commit in -rc6 ? dmesg for linux-3.17_rc5 patched with rs400-gart_set_page-typo.diff: [6.929979] [drm] Initialized drm 1.1.0 20060810 [7.565290] [drm] radeon kernel modesetting enabled. [7.566263] [drm] initializing kernel modesetting (RS740 0x1002:0x796E 0x105B:0x0E13). [7.566289] [drm] register mmio base: 0xFEAF [7.566293] [drm] register mmio size: 65536 [7.566880] ATOM BIOS: ATI [7.566893] radeon :01:05.0: VRAM: 128M 0xD800 - 0xDFFF (128M used) [7.566895] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [7.566907] [drm] Detected VRAM RAM=128M, BAR=128M [7.566908] [drm] RAM width 128bits DDR [7.566971] [TTM] Zone kernel: Available graphics memory: 1959278 kiB [7.566972] [TTM] Initializing pool allocator [7.566976] [TTM] Initializing DMA pool allocator [7.566997] [drm] radeon: 128M of VRAM memory ready [7.566998] [drm] radeon: 512M of GTT memory ready. [7.567010] [drm] GART: num cpu pages 131072, num gpu pages 131072 [7.582020] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [7.582025] [drm] PCIE GART of 512M enabled (table at 0xD4F0). [7.582119] radeon :01:05.0: WB enabled [7.582138] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xa000 and cpu addr 0x8800d7077000 [7.582146] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [7.582149] [drm] Driver supports precise vblank timestamp query. [7.582173] [drm] radeon: irq initialized. [7.582201] [drm] Loading RS690/RS740 Microcode [7.734500] [drm] radeon: ring at 0xA0001000 [7.734530] [drm] ring test succeeded in 0 usecs [7.734793] [drm] ib test succeeded in 0 usecs [7.736412] [drm] Radeon Display Connectors [7.736416] [drm] Connector 0: [7.736418] [drm] VGA-1 [7.736421] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [7.736423] [drm] Encoders: [7.736425] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [7.736426] [drm] Connector 1: [7.736428] [drm] DVI-D-1 [7.736429] [drm] HPD2 [7.736432] [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c [7.736433] [drm] Encoders: [7.736435] [drm] DFP2: INTERNAL_DDI [7.736436] [drm] Connector 2: [7.736437] [drm] DVI-D-2 [7.736440] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [7.736441] [drm] Encoders: [7.736443] [drm] DFP3: INTERNAL_LVTM1 [7.788582] [drm] fb mappable at 0xF004 [7.788591] [drm] vram apper at 0xF000 [7.788595] [drm] size 9216000 [7.788598] [drm] fb depth is 24 [7.788601] [drm]pitch is 7680 [7.788796] fbcon: radeondrmfb (fb0) is primary device [7.818230] Console: switching to colour frame buffer device 240x75 [7.843203] radeon :01:05.0: fb0: radeondrmfb frame buffer device [7.843210] radeon :01:05.0: registered panic notifier [7.851229] [drm] Initialized radeon 2.40.0 20080528 for :01:05.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/c45ae879/attachment.html>
[Bug 84017] HD 4670 only works with MSI disabled
https://bugs.freedesktop.org/show_bug.cgi?id=84017 --- Comment #8 from Alex Deucher --- booting with pci=nomsi will disable MSIs globally on your system. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/590d0870/attachment.html>
[PATCH 1/3] drm/radeon: don't reset dma on NI/SI init
Am 18.09.2014 um 20:01 schrieb Alex Deucher:
> On Thu, Sep 18, 2014 at 1:51 PM, Christian K?nig
> wrote:
>> Am 18.09.2014 um 19:26 schrieb Alex Deucher:
>>> Otherwise we may lose the DMA golden settings which can
>>> lead to hangs, etc.
>>
>> Don't we still want the soft reset at some point, e.g. when the engine
>> hangs?
>>
>> I would rather move that to another function and call it before loading the
>> golden values.
> We have separate soft reset code for dma already. This is just a
> one-off soft reset in the dma init code. The golden registers are
> reloaded after a GPU reset so we should be fine.
Of course!
In this case the patches are Reviewed-by: Christian K?nig
>
> Alex
>
>> Christian.
>>
>>
>>> bug:
>>> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500
>>>
>>> Signed-off-by: Alex Deucher
>>> Cc: stable at vger.kernel.org
>>> ---
>>>drivers/gpu/drm/radeon/ni_dma.c | 6 --
>>>1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/ni_dma.c
>>> b/drivers/gpu/drm/radeon/ni_dma.c
>>> index 8a3e622..f26f0a9 100644
>>> --- a/drivers/gpu/drm/radeon/ni_dma.c
>>> +++ b/drivers/gpu/drm/radeon/ni_dma.c
>>> @@ -191,12 +191,6 @@ int cayman_dma_resume(struct radeon_device *rdev)
>>> u32 reg_offset, wb_offset;
>>> int i, r;
>>>- /* Reset dma */
>>> - WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
>>> - RREG32(SRBM_SOFT_RESET);
>>> - udelay(50);
>>> - WREG32(SRBM_SOFT_RESET, 0);
>>> -
>>> for (i = 0; i < 2; i++) {
>>> if (i == 0) {
>>> ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
>>
[Bug 84017] HD 4670 only works with MSI disabled
https://bugs.freedesktop.org/show_bug.cgi?id=84017 --- Comment #7 from Alex Deucher --- (In reply to comment #5) > The mainboard a MicroStar MS-7318. Based on the information on > http://www.medion.com/de/service/_lightbox/treiber.php?msn=10010251 I think > it is a VIA Hyperion Pro. I strongly suspect the VIA chipset has broken MSI support and probably needs a quirk to disable it. I don't see any MSIs getting triggered: 64: 0 0 PCI-MSI-edge aerdrv, PCIe PME, pciehp 65: 0 0 PCI-MSI-edge aerdrv, PCIe PME, pciehp 66: 0 0 PCI-MSI-edge aerdrv, PCIe PME 67: 0 0 PCI-MSI-edge aerdrv, PCIe PME 68: 0 0 PCI-MSI-edge snd_hda_intel 69: 0 0 PCI-MSI-edge snd_hda_intel Does sound work ok? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/47b6be3e/attachment.html>
[Bug 84017] HD 4670 only works with MSI disabled
>Handle 0x001B, DMI type 17, 27 bytes >Memory Device > Array Handle: 0x001A > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 1024 MB > Form Factor: DIMM > Set: None > Locator: A0 > Bank Locator: Bank0/1 > Type: Unknown > Type Detail: None > Speed: Unknown > Manufacturer: None > Serial Number: None > Asset Tag: None > Part Number: None > >Handle 0x001C, DMI type 17, 27 bytes >Memory Device > Array Handle: 0x001A > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 1024 MB > Form Factor: DIMM > Set: None > Locator: A1 > Bank Locator: Bank2/3 > Type: Unknown > Type Detail: None > Speed: Unknown > Manufacturer: None > Serial Number: None > Asset Tag: None > Part Number: None > >Handle 0x001D, DMI type 19, 15 bytes >Memory Array Mapped Address > Starting Address: 0x000 > Ending Address: 0x0007FFF > Range Size: 2 GB > Physical Array Handle: 0x001A > Partition Width: 1 > >Handle 0x001E, DMI type 20, 19 bytes >Memory Device Mapped Address > Starting Address: 0x000 > Ending Address: 0x0003FFF > Range Size: 1 GB > Physical Device Handle: 0x001B > Memory Array Mapped Address Handle: 0x001D > Partition Row Position: 1 > >Handle 0x001F, DMI type 20, 19 bytes >Memory Device Mapped Address > Starting Address: 0x0004000 > Ending Address: 0x0007FFF > Range Size: 1 GB > Physical Device Handle: 0x001C > Memory Array Mapped Address Handle: 0x001D > Partition Row Position: 1 > >Handle 0x0020, DMI type 32, 11 bytes >System Boot Information > Status: No errors detected > >Handle 0x0021, DMI type 127, 4 bytes >End Of Table > -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/1eb9c36b/attachment-0001.html>
[PATCH 1/3] drm/radeon: don't reset dma on NI/SI init
Am 18.09.2014 um 19:26 schrieb Alex Deucher:
> Otherwise we may lose the DMA golden settings which can
> lead to hangs, etc.
Don't we still want the soft reset at some point, e.g. when the engine
hangs?
I would rather move that to another function and call it before loading
the golden values.
Christian.
>
> bug:
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/ni_dma.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
> index 8a3e622..f26f0a9 100644
> --- a/drivers/gpu/drm/radeon/ni_dma.c
> +++ b/drivers/gpu/drm/radeon/ni_dma.c
> @@ -191,12 +191,6 @@ int cayman_dma_resume(struct radeon_device *rdev)
> u32 reg_offset, wb_offset;
> int i, r;
>
> - /* Reset dma */
> - WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
> - RREG32(SRBM_SOFT_RESET);
> - udelay(50);
> - WREG32(SRBM_SOFT_RESET, 0);
> -
> for (i = 0; i < 2; i++) {
> if (i == 0) {
> ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
[Bug 84017] HD 4670 only works with MSI disabled
https://bugs.freedesktop.org/show_bug.cgi?id=84017 --- Comment #5 from Christoph Brill --- Created attachment 106524 --> https://bugs.freedesktop.org/attachment.cgi?id=106524&action=edit dmidecode The mainboard a MicroStar MS-7318. Based on the information on http://www.medion.com/de/service/_lightbox/treiber.php?msn=10010251 I think it is a VIA Hyperion Pro. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/d19d464b/attachment.html>
[Bug 84017] HD 4670 only works with MSI disabled
https://bugs.freedesktop.org/show_bug.cgi?id=84017 --- Comment #4 from Christoph Brill --- Created attachment 106523 --> https://bugs.freedesktop.org/attachment.cgi?id=106523&action=edit /proc/interrupts Output of /proc/interrupts when booted using radeon.msi=-1, switched to VT before X11 kicked in. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/54eb9850/attachment.html>
[pull] radeon drm-fixes-3.17
Hi Dave, Radeon fixes for 3.17: - fix a resume hang on mullins - fix an oops on module unload with vgaswitcheroo (radeon and nouveau) - fix possible hangs DMA engine hangs due to hw bugs The following changes since commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a: drm/ast: AST2000 cannot be detected correctly (2014-09-12 13:41:39 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.17 for you to fetch changes up to 53beaa01e0fe8e4202f43485a03b32fcf5dfea74: drm/nouveau/runpm: fix module unload (2014-09-18 19:22:37 -0400) Alex Deucher (7): drm/radeon/dpm: fix resume on mullins drm/radeon: don't reset dma on NI/SI init drm/radeon: don't reset sdma on CIK init drm/radeon: don't reset dma on r6xx-evergreen init vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops drm/radeon/px: fix module unload drm/nouveau/runpm: fix module unload Kyle McMartin (1): drm/radeon: delete unused PTE_* defines Michel D?nzer (1): drm/radeon: Disable HDP flush before every CS again for < r600 drivers/gpu/drm/nouveau/nouveau_vga.c | 9 + drivers/gpu/drm/radeon/cik_sdma.c | 7 --- drivers/gpu/drm/radeon/kv_dpm.c| 28 +--- drivers/gpu/drm/radeon/ni_dma.c| 6 -- drivers/gpu/drm/radeon/r100.c | 28 ++-- drivers/gpu/drm/radeon/r600_dma.c | 9 - drivers/gpu/drm/radeon/r600d.h | 7 --- drivers/gpu/drm/radeon/radeon_asic.c | 2 -- drivers/gpu/drm/radeon/radeon_asic.h | 3 +-- drivers/gpu/drm/radeon/radeon_device.c | 11 +-- drivers/gpu/drm/radeon/radeon_drv.c| 2 +- drivers/gpu/vga/vga_switcheroo.c | 6 ++ include/linux/vga_switcheroo.h | 2 ++ 13 files changed, 63 insertions(+), 57 deletions(-)
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #27 from Alex Deucher --- They are written against 3.17. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/26e61400/attachment.html>
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #26 from Daniel Kirsten --- (In reply to comment #25) The pci-id of the VGA Controller is 01:00.0 for my Amilo. However, I cannot apply the patches to the 3.14.18-100.fc19 kernel: patch --dry-run -p1 < ~/software/0001-drm-radeon-add-a-module-parameter-for-backlight-cont.patch checking file drivers/gpu/drm/radeon/radeon.h Hunk #1 FAILED at 106. 1 out of 1 hunk FAILED checking file drivers/gpu/drm/radeon/radeon_drv.c Hunk #1 FAILED at 181. Hunk #2 succeeded at 237 with fuzz 2 (offset -26 lines). 1 out of 2 hunks FAILED checking file drivers/gpu/drm/radeon/radeon_encoders.c Exit 1 patch --dry-run -p1 < ~/software/0002-drm-radeon-add-a-backlight-quirk-for-Amilo-Xi-2550.patch checking file drivers/gpu/drm/radeon/radeon_encoders.c Hunk #1 FAILED at 173. 1 out of 1 hunk FAILED Exit 1 Which kernel should I use to test the patches? Daniel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/db13299a/attachment.html>
[pull] radeon drm-next-3.18
Hi Dave, Just a fix for 3.18 for AGP. The following changes since commit 8337486a8fda53e5f46b3cb2b4eb3272608348cb: Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next (2014-09-18 21:53:47 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.18 for you to fetch changes up to 3840a656f61fdc504f1b0c6617f6af800d551efe: drm/radeon: fix AGP userptr handling (2014-09-18 18:44:52 -0400) Christian K?nig (1): drm/radeon: fix AGP userptr handling drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-)
[PATCH 5/5] drm/radeon: disable audio when we disable hdmi
This should allow the audio driver to get a better
idea of whether the sink is connected or not.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 10 ++
drivers/gpu/drm/radeon/r600_hdmi.c | 5 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 8d5497e..2514d65 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -501,6 +501,8 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
void evergreen_hdmi_enable(struct drm_encoder *encoder, bool enable)
{
+ struct drm_device *dev = encoder->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
@@ -513,6 +515,14 @@ void evergreen_hdmi_enable(struct drm_encoder *encoder,
bool enable)
if (!enable && !dig->afmt->enabled)
return;
+ if (!enable && dig->afmt->pin) {
+ if (ASIC_IS_DCE6(rdev))
+ dce6_audio_enable(rdev, dig->afmt->pin, 0);
+ else
+ dce4_audio_enable(rdev, dig->afmt->pin, 0);
+ dig->afmt->pin = NULL;
+ }
+
dig->afmt->enabled = enable;
DRM_DEBUG("%sabling HDMI interface @ 0x%04X for encoder 0x%x\n",
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index a510689..7c7949f 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -691,6 +691,11 @@ void r600_hdmi_enable(struct drm_encoder *encoder, bool
enable)
if (!enable && !dig->afmt->enabled)
return;
+ if (!enable && dig->afmt->pin) {
+ r600_audio_enable(rdev, dig->afmt->pin, 0xf);
+ dig->afmt->pin = NULL;
+ }
+
/* Older chipsets require setting HDMI and routing manually */
if (!ASIC_IS_DCE3(rdev)) {
if (enable)
--
1.8.3.1
[PATCH 4/5] drm/radeon: split audio enable between eg and r600
Clean up the enable sequence as well.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 4 ++--
drivers/gpu/drm/radeon/dce6_afmt.c | 4 ++--
drivers/gpu/drm/radeon/evergreen_hdmi.c | 39 +
drivers/gpu/drm/radeon/evergreend.h | 13 +++
drivers/gpu/drm/radeon/r600_hdmi.c | 37 +++
drivers/gpu/drm/radeon/r600d.h | 15 +
drivers/gpu/drm/radeon/radeon.h | 4 ++--
7 files changed, 92 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
index 51800e3..950af15 100644
--- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -165,7 +165,7 @@ void dce3_1_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode *m
/* disable audio prior to setting up hw */
dig->afmt->pin = r600_audio_get_pin(rdev);
- r600_audio_enable(rdev, dig->afmt->pin, false);
+ r600_audio_enable(rdev, dig->afmt->pin, 0);
r600_audio_set_dto(encoder, mode->clock);
@@ -240,5 +240,5 @@ void dce3_1_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode *m
r600_hdmi_audio_workaround(encoder);
/* enable audio after to setting up hw */
- r600_audio_enable(rdev, dig->afmt->pin, true);
+ r600_audio_enable(rdev, dig->afmt->pin, 0xf);
}
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 088d19c..c0bbf68 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -284,13 +284,13 @@ static int dce6_audio_chipset_supported(struct
radeon_device *rdev)
void dce6_audio_enable(struct radeon_device *rdev,
struct r600_audio_pin *pin,
- bool enable)
+ u8 enable_mask)
{
if (!pin)
return;
WREG32_ENDPOINT(pin->offset, AZ_F0_CODEC_PIN_CONTROL_HOT_PLUG_CONTROL,
- enable ? AUDIO_ENABLED : 0);
+ enable_mask ? AUDIO_ENABLED : 0);
}
static const u32 pin_offsets[7] =
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 278c7a1..8d5497e 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -38,6 +38,37 @@ extern void dce6_afmt_select_pin(struct drm_encoder
*encoder);
extern void dce6_afmt_write_latency_fields(struct drm_encoder *encoder,
struct drm_display_mode *mode);
+/* enable the audio stream */
+static void dce4_audio_enable(struct radeon_device *rdev,
+ struct r600_audio_pin *pin,
+ u8 enable_mask)
+{
+ u32 tmp = RREG32(AZ_HOT_PLUG_CONTROL);
+
+ if (!pin)
+ return;
+
+ if (enable_mask) {
+ tmp |= AUDIO_ENABLED;
+ if (enable_mask & 1)
+ tmp |= PIN0_AUDIO_ENABLED;
+ if (enable_mask & 2)
+ tmp |= PIN1_AUDIO_ENABLED;
+ if (enable_mask & 4)
+ tmp |= PIN2_AUDIO_ENABLED;
+ if (enable_mask & 8)
+ tmp |= PIN3_AUDIO_ENABLED;
+ } else {
+ tmp &= ~(AUDIO_ENABLED |
+PIN0_AUDIO_ENABLED |
+PIN1_AUDIO_ENABLED |
+PIN2_AUDIO_ENABLED |
+PIN3_AUDIO_ENABLED);
+ }
+
+ WREG32(AZ_HOT_PLUG_CONTROL, tmp);
+}
+
/*
* update the N and CTS parameters for a given pixel clock rate
*/
@@ -318,10 +349,10 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
/* disable audio prior to setting up hw */
if (ASIC_IS_DCE6(rdev)) {
dig->afmt->pin = dce6_audio_get_pin(rdev);
- dce6_audio_enable(rdev, dig->afmt->pin, false);
+ dce6_audio_enable(rdev, dig->afmt->pin, 0);
} else {
dig->afmt->pin = r600_audio_get_pin(rdev);
- r600_audio_enable(rdev, dig->afmt->pin, false);
+ dce4_audio_enable(rdev, dig->afmt->pin, 0);
}
evergreen_audio_set_dto(encoder, mode->clock);
@@ -463,9 +494,9 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
struct drm_display_mode
/* enable audio after to setting up hw */
if (ASIC_IS_DCE6(rdev))
- dce6_audio_enable(rdev, dig->afmt->pin, true);
+ dce6_audio_enable(rdev, dig->afmt->pin, 1);
else
- r600_audio_enable(rdev, dig->afmt->pin, true);
+ dce4_audio_enable(rdev, dig->afmt->pin, 0xf);
}
void evergreen_hdmi_enable(struct drm_encoder *encoder, bool enable)
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index b066d67..83b7f59 100644
--- a/drivers
[PATCH 3/5] drm/radeon: consolidate r600_audio.c into r600_hdmi.c
Most of that functionality is only used by r600_hdmi.c
and I'm planning to change that further.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/r600_audio.c | 184 ---
drivers/gpu/drm/radeon/r600_hdmi.c | 154 +
drivers/gpu/drm/radeon/radeon_asic.h | 1 -
4 files changed, 155 insertions(+), 186 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/r600_audio.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index f77b713..43f63cf 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
- radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
+ radeon_pm.o atombios_dp.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
deleted file mode 100644
index 4c7163c..000
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Copyright 2008 Advanced Micro Devices, Inc.
- * Copyright 2008 Red Hat Inc.
- * Copyright 2009 Christian K?nig.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: Christian K?nig
- */
-#include
-#include "radeon.h"
-#include "radeon_reg.h"
-#include "radeon_asic.h"
-#include "atom.h"
-
-/*
- * check if the chipset is supported
- */
-static int r600_audio_chipset_supported(struct radeon_device *rdev)
-{
- return ASIC_IS_DCE2(rdev) && !ASIC_IS_NODCE(rdev);
-}
-
-struct r600_audio_pin r600_audio_status(struct radeon_device *rdev)
-{
- struct r600_audio_pin status;
- uint32_t value;
-
- value = RREG32(R600_AUDIO_RATE_BPS_CHANNEL);
-
- /* number of channels */
- status.channels = (value & 0x7) + 1;
-
- /* bits per sample */
- switch ((value & 0xF0) >> 4) {
- case 0x0:
- status.bits_per_sample = 8;
- break;
- case 0x1:
- status.bits_per_sample = 16;
- break;
- case 0x2:
- status.bits_per_sample = 20;
- break;
- case 0x3:
- status.bits_per_sample = 24;
- break;
- case 0x4:
- status.bits_per_sample = 32;
- break;
- default:
- dev_err(rdev->dev, "Unknown bits per sample 0x%x, using 16\n",
- (int)value);
- status.bits_per_sample = 16;
- }
-
- /* current sampling rate in HZ */
- if (value & 0x4000)
- status.rate = 44100;
- else
- status.rate = 48000;
- status.rate *= ((value >> 11) & 0x7) + 1;
- status.rate /= ((value >> 8) & 0x7) + 1;
-
- value = RREG32(R600_AUDIO_STATUS_BITS);
-
- /* iec 60958 status bits */
- status.status_bits = value & 0xff;
-
- /* iec 60958 category code */
- status.category_code = (value >> 8) & 0xff;
-
- return status;
-}
-
-/*
- * update all hdmi interfaces with current audio parameters
- */
-void r600_audio_update_hdmi(struct work_struct *work)
-{
- struct radeon_device *rdev = container_of(work, struct radeon_device,
- audio_work);
- struct drm_device *dev = rdev->ddev;
- struct r600_audio_pin audio_status = r600_audio_status(rdev);
- struct drm_encoder *encoder;
- bool changed = false;
-
-
[PATCH 2/5] drm/radeon: consolidate duplicate encode is digital function
Only need one copy.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 23 ---
drivers/gpu/drm/radeon/r600_audio.c| 25 +
drivers/gpu/drm/radeon/radeon_encoders.c | 21 +
drivers/gpu/drm/radeon/radeon_mode.h | 1 +
4 files changed, 23 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index a7f2ddf..b8cd797 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -291,29 +291,6 @@ static void radeon_atom_backlight_exit(struct
radeon_encoder *encoder)
bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
struct drm_display_mode *mode);
-
-static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
-{
- struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
- switch (radeon_encoder->encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_LVDS:
- case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- case ENCODER_OBJECT_ID_INTERNAL_DVO1:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
- case ENCODER_OBJECT_ID_INTERNAL_DDI:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
- return true;
- default:
- return false;
- }
-}
-
static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index bffac10..4c7163c 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -30,29 +30,6 @@
#include "atom.h"
/*
- * check if enc_priv stores radeon_encoder_atom_dig
- */
-static bool radeon_dig_encoder(struct drm_encoder *encoder)
-{
- struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
- switch (radeon_encoder->encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_LVDS:
- case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- case ENCODER_OBJECT_ID_INTERNAL_DVO1:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
- case ENCODER_OBJECT_ID_INTERNAL_DDI:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- return true;
- }
- return false;
-}
-
-/*
* check if the chipset is supported
*/
static int r600_audio_chipset_supported(struct radeon_device *rdev)
@@ -134,7 +111,7 @@ void r600_audio_update_hdmi(struct work_struct *work)
}
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- if (!radeon_dig_encoder(encoder))
+ if (!radeon_encoder_is_digital(encoder))
continue;
if (changed || r600_hdmi_buffer_status_changed(encoder))
r600_hdmi_update_audio_settings(encoder);
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 15edf23..9a19e52 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -410,3 +410,24 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder
*encoder,
}
}
+bool radeon_encoder_is_digital(struct drm_encoder *encoder)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+ case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_DDI:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
+ return true;
+ default:
+ return false;
+ }
+}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index e27608c..04db2fd 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -777,6 +777,7 @@ extern v
[PATCH 1/5] drm/radeon: fix register name to match internal name
no functional change. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/dce6_afmt.c | 2 +- drivers/gpu/drm/radeon/sid.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c b/drivers/gpu/drm/radeon/dce6_afmt.c index ab29f95..088d19c 100644 --- a/drivers/gpu/drm/radeon/dce6_afmt.c +++ b/drivers/gpu/drm/radeon/dce6_afmt.c @@ -289,7 +289,7 @@ void dce6_audio_enable(struct radeon_device *rdev, if (!pin) return; - WREG32_ENDPOINT(pin->offset, AZ_F0_CODEC_PIN_CONTROL_HOTPLUG_CONTROL, + WREG32_ENDPOINT(pin->offset, AZ_F0_CODEC_PIN_CONTROL_HOT_PLUG_CONTROL, enable ? AUDIO_ENABLED : 0); } diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h index fd414d3..6635da9 100644 --- a/drivers/gpu/drm/radeon/sid.h +++ b/drivers/gpu/drm/radeon/sid.h @@ -736,7 +736,7 @@ # define DESCRIPTION16(x) (((x) & 0xff) << 0) # define DESCRIPTION17(x) (((x) & 0xff) << 8) -#define AZ_F0_CODEC_PIN_CONTROL_HOTPLUG_CONTROL 0x54 +#define AZ_F0_CODEC_PIN_CONTROL_HOT_PLUG_CONTROL 0x54 # define AUDIO_ENABLED (1 << 31) #define AZ_F0_CODEC_PIN_CONTROL_RESPONSE_CONFIGURATION_DEFAULT 0x56 -- 1.8.3.1
[GIT PULL FOR v3.18] Renesas DRM changes
On Mon, Sep 15, 2014 at 12:09:55PM +0300, Laurent Pinchart wrote: > Hi Dave, > > Could you please pull the following changes for v3.18 ? > > Commit "drm/rcar-du: Use struct videomode in platform data" touches board > code > in arch/arm/mach-shmobile. There is, to the best of my knowledge, no risk of > conflict for v3.18. Simon, are you fine with getting those changes merged > through Dave's tree (and could you confirm that no conflict should occur) ? > > The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4: > > Merge tag 'topic/drm-header-rework-2014-09-12' of > git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 > +1000) > > are available in the git repository at: > > git://linuxtv.org/pinchartl/fbdev.git drm/next/du > > for you to fetch changes up to 96c026911890ceacee238da00a0b140ad634cc43: > > drm/rcar-du: Add OF support (2014-09-15 11:55:47 +0300) Hi Laurent, Hi Dave, I'm comfortable with these shmobile changes going via Dave's tree as they do not seem to conflict with anything queued up between for v3.18. I would however like these changes included in v3.18-rc1 so that I can manage any conflicts that may emerge in patches I queue up for v3.19. I'm not asking you to update the patches, but for the record, shmobile portion: Acked-by: Simon Horman > > Laurent Pinchart (10): > drm/rcar-du: Update copyright notice > drm/shmob: Update copyright notice > devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt > devicetree: Add vendor prefix "thine" to vendor-prefixes.txt > video: Add DT binding documentation for VGA connector > video: Add ADV7123 DT bindings documentation > video: Add THC63LVDM83D DT bindings documentation > video: Add DT bindings for the R-Car Display Unit > drm/rcar-du: Use struct videomode in platform data > drm/rcar-du: Add OF support > > Documentation/devicetree/bindings/vendor-prefixes.txt | 2 + > Documentation/devicetree/bindings/video/adi,adv7123.txt | 50 + > Documentation/devicetree/bindings/video/renesas,du.txt | 84 + > .../devicetree/bindings/video/thine,thc63lvdm83d| 50 + > .../devicetree/bindings/video/vga-connector.txt | 36 > arch/arm/mach-shmobile/board-koelsch-reference.c| 19 +- > arch/arm/mach-shmobile/board-koelsch.c | 19 +- > arch/arm/mach-shmobile/board-lager-reference.c | 19 +- > arch/arm/mach-shmobile/board-lager.c| 19 +- > arch/arm/mach-shmobile/board-marzen.c | 19 +- > drivers/gpu/drm/rcar-du/Kconfig | 1 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 172 --- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 13 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 5 +- > drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 233 +-- > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 45 +++-- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 5 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vgacon.h| 2 +- > drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c| 2 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.h| 2 +- > drivers/gpu/drm/shmobile/shmob_drm_kms.c| 2 +- > drivers/gpu/drm/shmobile/shmob_drm_kms.h| 2 +- > drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_plane.h | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_regs.h | 2 +- > include/linux/platform_data/rcar-du.h | 4 +- > 41 files changed, 645 insertions(+), 198 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/adi,adv7123.txt > create mode 100644 Documentation/de
rockchip and atmel kms drivers
Hi Boris, I have updated new version drm driver, you can review it. Thanks. On 2014?09?18? 02:00, Boris BREZILLON wrote: > Hi Yaozq, > > On Wed, 17 Sep 2014 13:50:26 +0800 > yaozq wrote: > >> Hi Boris & Dave, >> I will update the rockchip drm driver soon, we have many change about it. > I'll wait for the new version then, just keep me in the loop when you > send it. > > Thanks, > > Boris >
[PATCH] drm/exynos: factor out initial setting of each driver
>From fimd driver and vidi driver, dev->irq_enabled and
dev->vblank_disable_allowed are set and also mixer needs them even if
missed. It's duplicated so set them when loads drm driver.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 -
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 -
3 files changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 0d74e9b..bc87be3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -116,6 +116,23 @@ static int exynos_drm_load(struct drm_device *dev,
unsigned long flags)
/* force connectors detection */
drm_helper_hpd_irq_event(dev);
+ /*
+* enable drm irq mode.
+* - with irq_enabled = true, we can use the vblank feature.
+*
+* P.S. note that we wouldn't use drm irq handler but
+* just specific driver own one instead because
+* drm framework supports only one irq handler.
+*/
+ dev->irq_enabled = true;
+
+ /*
+* with vblank_disable_allowed = true, vblank interrupt will be disabled
+* by drm timer once a current process gives up ownership of
+* vblank event.(after drm_vblank_put function is called)
+*/
+ dev->vblank_disable_allowed = true;
+
return 0;
err_unbind_all:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 5d09e33..370abdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -237,23 +237,6 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
mgr->drm_dev = ctx->drm_dev = drm_dev;
mgr->pipe = ctx->pipe = priv->pipe++;
- /*
-* enable drm irq mode.
-* - with irq_enabled = true, we can use the vblank feature.
-*
-* P.S. note that we wouldn't use drm irq handler but
-* just specific driver own one instead because
-* drm framework supports only one irq handler.
-*/
- drm_dev->irq_enabled = true;
-
- /*
-* with vblank_disable_allowed = true, vblank interrupt will be disabled
-* by drm timer once a current process gives up ownership of
-* vblank event.(after drm_vblank_put function is called)
-*/
- drm_dev->vblank_disable_allowed = true;
-
/* attach this sub driver to iommu mapping if supported. */
if (is_drm_iommu_supported(ctx->drm_dev)) {
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 9528d81..2e6120b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -303,23 +303,6 @@ static int vidi_mgr_initialize(struct exynos_drm_manager
*mgr,
mgr->drm_dev = ctx->drm_dev = drm_dev;
mgr->pipe = ctx->pipe = priv->pipe++;
- /*
-* enable drm irq mode.
-* - with irq_enabled = 1, we can use the vblank feature.
-*
-* P.S. note that we wouldn't use drm irq handler but
-* just specific driver own one instead because
-* drm framework supports only one irq handler.
-*/
- drm_dev->irq_enabled = 1;
-
- /*
-* with vblank_disable_allowed = 1, vblank interrupt will be disabled
-* by drm timer once a current process gives up ownership of
-* vblank event.(after drm_vblank_put function is called)
-*/
- drm_dev->vblank_disable_allowed = 1;
-
return 0;
}
--
1.9.1
[PATCH v2 5/5] drm/rockchip: Add support for Rockchip Soc EDP
This adds support for Rockchip soc edp found on rk3288
Signed-off-by: Mark Yao
Signed-off-by: Jeff Chen
---
change in v2:
- fix code sytle
- use some define from drm_dp_helper.h
- use panel-simple driver for primary display.
- remove unnecessary clock clk_24m_parent.
drivers/gpu/drm/rockchip/Kconfig |9 +
drivers/gpu/drm/rockchip/Makefile|2 +
drivers/gpu/drm/rockchip/rockchip_edp_core.c | 853 ++
drivers/gpu/drm/rockchip/rockchip_edp_core.h | 309 +++
drivers/gpu/drm/rockchip/rockchip_edp_reg.c | 1202 ++
drivers/gpu/drm/rockchip/rockchip_edp_reg.h | 345
6 files changed, 2720 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_core.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_core.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_reg.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_edp_reg.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 7146c80..04b1f8c 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -17,3 +17,12 @@ config DRM_ROCKCHIP
management to userspace. This driver does not provides
2D or 3D acceleration; acceleration is performed by other
IP found on the SoC.
+
+config ROCKCHIP_EDP
+ bool "Rockchip edp support"
+ depends on DRM_ROCKCHIP
+ help
+ Choose this option if you have a Rockchip eDP.
+ Rockchip rk3288 SoC has eDP TX Controller can be used.
+ If you have an Embedded DisplayPort Panel, say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 6e6d468..a0fc3a1 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,4 +7,6 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o rockchip_drm_vop.o
+rockchipdrm-$(CONFIG_ROCKCHIP_EDP) += rockchip_edp_core.o rockchip_edp_reg.o
+
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_edp_core.c
b/drivers/gpu/drm/rockchip/rockchip_edp_core.c
new file mode 100644
index 000..4d9caee
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_edp_core.c
@@ -0,0 +1,853 @@
+/*
+* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+* Author:
+* Andy yan
+* Jeff chen
+*
+* based on exynos_dp_core.c
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the
+* Free Software Foundation; either version 2 of the License, or (at your
+* option) any later version.
+*/
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "rockchip_edp_core.h"
+
+#define connector_to_edp(c) \
+ container_of(c, struct rockchip_edp_device, connector)
+
+#define encoder_to_edp(c) \
+ container_of(c, struct rockchip_edp_device, encoder)
+
+static struct rockchip_edp_soc_data soc_data[2] = {
+ /* rk3288 */
+ {.grf_soc_con6 = 0x025c,
+.grf_soc_con12 = 0x0274},
+ /* no edp switching needed */
+ {.grf_soc_con6 = -1,
+.grf_soc_con12 = -1},
+};
+
+static const struct of_device_id rockchip_edp_dt_ids[] = {
+ {.compatible = "rockchip,rk3288-edp",
+.data = (void *)&soc_data[0] },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, rockchip_edp_dt_ids);
+
+static int rockchip_edp_clk_enable(struct rockchip_edp_device *edp)
+{
+ int ret = 0;
+
+ if (!edp->clk_on) {
+ ret = clk_prepare_enable(edp->pclk);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable edp pclk %d\n", ret);
+ goto err_pclk;
+ }
+
+ ret = clk_prepare_enable(edp->clk_edp);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable clk_edp %d\n", ret);
+ goto err_clk_edp;
+ }
+
+ ret = clk_set_rate(edp->clk_24m, 2400);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot set edp clk_24m %d\n",
+ ret);
+ goto err_clk_24m;
+ }
+
+ ret = clk_prepare_enable(edp->clk_24m);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable edp clk_24m %d\n",
+ ret);
+ goto err_clk_24m;
+ }
+
+ edp->clk_on = true;
+ }
+
+ return 0;
+
+err_clk_24m:
+ clk_disable_unprepare(edp->clk_edp);
+err_clk_edp:
+ clk_disable_unprepare(edp->pclk);
+err_pclk:
+ edp->clk_on = false;
+
+ return ret;
+}
+
+static int
[PATCH v2 4/5] dt-bindings: video: Add documentation for rockchip edp
Add binding documentation for Rockchip SoC EDP driver.
Signed-off-by: Jeff Chen
Signed-off-by: Mark Yao
---
changes in v2:
- add edp reset
- add panel node
- add port for display-subsystem
.../devicetree/bindings/video/rockchip-edp.txt | 50
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/rockchip-edp.txt
diff --git a/Documentation/devicetree/bindings/video/rockchip-edp.txt
b/Documentation/devicetree/bindings/video/rockchip-edp.txt
new file mode 100644
index 000..515e806
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-edp.txt
@@ -0,0 +1,50 @@
+Rockchip RK3288 EDP interface
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "clk_edp"
+ "clk_edp_24m"
+ "pclk_edp"
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the name "edp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- rockchip,panel: required a simple panel node as described by
+ Documentation/devicetree/bindings/panel/simple-panel.txt
+
+- ports: contain a port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+ edp: edp at ff97 {
+ compatible = "rockchip,rk3288-edp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru SCLK_EDP_24M>, <&cru
PCLK_EDP_CTRL>;
+ clock-names = "clk_edp", "clk_edp_24m", "pclk_edp";
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "edp";
+ rockchip,panel = <&panel>;
+ ports {
+ edp_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+ };
+ };
--
1.7.9.5
[PATCH v2 3/5] dt-bindings: video: Add documentation for rockchip vop
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
.../devicetree/bindings/video/rockchip-vop.txt | 58
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt
diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: Must contain
+ aclk_vop: for ddr buffer transfer.
+ hclk_vop: for ahb bus to R/W the phy regs.
+ dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - axi
+ - ahb
+ - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+ vopb: vopb at ff93 {
+ compatible = "rockchip,rk3288-vop";
+ reg = <0xff93 0x19c>;
+ interrupts = ;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ vopb_out_edp: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint=<&edp_in_vopb>;
+ };
+ vopb_out_hdmi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint=<&hdmi_in_vopb>;
+ };
+ };
+ };
--
1.7.9.5
[PATCH v2 2/5] dt-bindings: video: Add for rockchip display subsytem
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
.../devicetree/bindings/video/rockchip-drm.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt
diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+ of vop devices. vop definitions as defined in
+ Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+};
--
1.7.9.5
[PATCH v2 1/5] drm/rockchip: Add basic drm driver
This patch adds the basic structure of a DRM Driver for Rockchip Socs. Signed-off-by: Mark yao --- Changes in v2: - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master device and each vop device can shared the drm dma mapping. - use drm_crtc_init_with_planes and drm_universal_plane_init. - remove unnecessary middle layers. - add cursor set, move funcs to rockchip drm crtc. - use vop reset at first init - reference framebuffer when used and unreference when swap out vop drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/rockchip/Kconfig | 19 + drivers/gpu/drm/rockchip/Makefile | 10 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 502 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 120 ++ drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 201 drivers/gpu/drm/rockchip/rockchip_drm_fb.h| 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 231 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 405 +++ drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 76 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1442 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 187 include/uapi/drm/rockchip_drm.h | 97 ++ 15 files changed, 3341 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/Kconfig create mode 100644 drivers/gpu/drm/rockchip/Makefile create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h create mode 100644 include/uapi/drm/rockchip_drm.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b066bb3..7c4c3c6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -171,6 +171,8 @@ config DRM_SAVAGE source "drivers/gpu/drm/exynos/Kconfig" +source "drivers/gpu/drm/rockchip/Kconfig" + source "drivers/gpu/drm/vmwgfx/Kconfig" source "drivers/gpu/drm/gma500/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4a55d59..d03387a 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ obj-$(CONFIG_DRM_VIA) +=via/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig new file mode 100644 index 000..7146c80 --- /dev/null +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -0,0 +1,19 @@ +config DRM_ROCKCHIP + tristate "DRM Support for Rockchip" + depends on DRM && ROCKCHIP_IOMMU + select ARM_DMA_USE_IOMMU + select IOMMU_API + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select DRM_PANEL + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE + select VIDEOMODE_HELPERS + help + Choose this option if you have a Rockchip soc chipset. + This driver provides kernel mode setting and buffer + management to userspace. This driver does not provides + 2D or 3D acceleration; acceleration is performed by other + IP found on the SoC. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile new file mode 100644 index 000..6e6d468 --- /dev/null +++ b/drivers/gpu/drm/rockchip/Makefile @@ -0,0 +1,10 @@ +# +# Makefile for the drm device driver. This driver provides support for the +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. + +ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip + +rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \ + rockchip_drm_gem.o rockchip_drm_vop.o + +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c new file mode 100644 index 000..f84dcd8 --- /dev/null +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -0,0 +1,502 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author:Mark Yao + * + * based on
[PATCH v2 0/5] Add drm driver for Rockchip Socs
From: mark yao This a series of patches is a DRM Driver for Rockchip Socs, add support for vop devices, eDP. Future patches will add additional encoders/connectors, such as HDMI. The basic "crtc" for rockchip is a "VOP" - Video Output Processor. the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar Vop devices. Vop devices support iommu mapping, we use dma-mapping API with ARM_DMA_USE_IOMMU. Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master device and each vop device can shared the drm dma mapping. - use drm_crtc_init_with_planes and drm_universal_plane_init. - remove unnecessary middle layers. - add cursor set, move funcs to rockchip drm crtc. - use panel-simple driver for primary display. - add vop and edp reset. Tested on rk3288 pinky board, use eDP encoders/connector, boot and display OK Mark yao (5): drm/rockchip: Add basic drm driver dt-bindings: video: Add for rockchip display subsytem dt-bindings: video: Add documentation for rockchip vop dt-bindings: video: Add documentation for rockchip edp drm/rockchip: Add support for Rockchip Soc EDP -- 1.7.9.5
[PATCH 3/3] drm/radeon: add explicit command submission sync
From: Christian K?nig
The driver falls back to explicit synchronization as soon as
buffers move between clients or are moved by TTM.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 5
drivers/gpu/drm/radeon/radeon_cs.c | 49 ++---
drivers/gpu/drm/radeon/radeon_gem.c | 1 +
drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
include/uapi/drm/radeon_drm.h | 7 +++---
5 files changed, 57 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index dbfd346..44a8eec 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -474,6 +474,9 @@ struct radeon_bo_va {
struct radeon_bo*bo;
};
+#define RADEON_BO_OWNER_IMPLICIT_SYNC (0l)
+#define RADEON_BO_OWNER_FIRST_CS (~0l)
+
struct radeon_bo {
/* Protected by gem.mutex */
struct list_headlist;
@@ -489,6 +492,7 @@ struct radeon_bo {
u32 tiling_flags;
u32 pitch;
int surface_reg;
+ longowner;
/* list of all virtual address to which this bo
* is associated to
*/
@@ -1084,6 +1088,7 @@ struct radeon_cs_parser {
struct radeon_cs_chunk *chunk_relocs;
struct radeon_cs_chunk *chunk_flags;
struct radeon_cs_chunk *chunk_const_ib;
+ struct radeon_cs_chunk *chunk_wait_for;
struct radeon_ibib;
struct radeon_ibconst_ib;
void*track;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0c0f0b3..8f62698 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -183,7 +183,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
}
p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
- p->relocs[i].tv.shared = !r->write_domain;
+ p->relocs[i].tv.shared = !r->write_domain ||
+!!p->chunk_wait_for;
p->relocs[i].handle = r->handle;
radeon_cs_buckets_add(&buckets, &p->relocs[i].tv.head,
@@ -251,16 +252,40 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p,
u32 ring, s32 priority
static void radeon_cs_sync_rings(struct radeon_cs_parser *p)
{
+ long owner = p->chunk_wait_for ? (long)p->filp :
+ RADEON_BO_OWNER_IMPLICIT_SYNC;
int i;
+ if (p->chunk_wait_for) {
+ struct radeon_fpriv *fpriv = p->filp->driver_priv;
+
+ for (i = 0; i < p->chunk_wait_for->length_dw; ++i) {
+ struct radeon_fence *fence;
+ uint64_t *id;
+
+ id = (uint64_t *)&p->chunk_wait_for->kdata[i];
+
+ mutex_lock(&fpriv->seq_lock);
+ fence = radeon_seq_query(fpriv->seq, *id);
+ mutex_unlock(&fpriv->seq_lock);
+
+ radeon_sync_fence(&p->ib.sync, fence);
+ }
+ }
+
for (i = 0; i < p->nrelocs; i++) {
+ struct radeon_cs_reloc *reloc = &p->relocs[i];
struct reservation_object *resv;
- if (!p->relocs[i].robj)
+ if (!reloc->robj)
continue;
- resv = p->relocs[i].robj->tbo.resv;
- radeon_sync_resv(&p->ib.sync, resv, p->relocs[i].tv.shared);
+ if (reloc->robj->owner != owner &&
+ reloc->robj->owner != RADEON_BO_OWNER_FIRST_CS)
+ reloc->tv.shared = false;
+
+ resv = reloc->robj->tbo.resv;
+ radeon_sync_resv(&p->ib.sync, resv, reloc->tv.shared);
}
}
@@ -332,6 +357,10 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
if (p->chunks[i].length_dw == 0)
return -EINVAL;
}
+ if (user_chunk.chunk_id == RADEON_CHUNK_ID_WAIT_FOR) {
+ p->chunk_wait_for = &p->chunks[i];
+ /* zero length wait for list is actually useful */
+ }
size = p->chunks[i].length_dw;
cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
@@ -413,6 +442,18 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
unsigned i;
if (!error) {
+ long owner = parser->chunk_wait_for ? (long)parser->filp :
+ RADEON_BO_OWNER_IMPLICIT_SYNC;
+
+ for (i = 0; i < parser->nrelocs; i++) {
+ struct radeon_cs_reloc *reloc = &parser->relocs[i];
+
+ if (!reloc->robj)
+ continue;
+
+ rel
[PATCH 2/3] drm/radeon: add command submission IDs
From: Christian K?nig
This patch adds a new 64bit ID as a result to each command submission.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/radeon.h | 13 +-
drivers/gpu/drm/radeon/radeon_cs.c | 13 ++
drivers/gpu/drm/radeon/radeon_kms.c | 41 +++
drivers/gpu/drm/radeon/radeon_seq.c | 229
include/uapi/drm/radeon_drm.h | 1 +
6 files changed, 277 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 8cc9f68..21ee928 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
\
- radeon_sync.o
+ radeon_sync.o radeon_seq.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b3b4e96..dbfd346 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -423,6 +423,15 @@ static inline bool radeon_fence_is_earlier(struct
radeon_fence *a,
}
/*
+ * Userspace command submission identifier generation
+ */
+struct radeon_seq;
+
+uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence *fence);
+struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t id);
+void radeon_seq_destroy(struct radeon_seq **seq);
+
+/*
* Tiling registers
*/
struct radeon_surface_reg {
@@ -946,7 +955,9 @@ struct radeon_vm_manager {
* file private structure
*/
struct radeon_fpriv {
- struct radeon_vmvm;
+ struct radeon_vmvm;
+ struct mutexseq_lock;
+ struct radeon_seq *seq;
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index b8f20a5..0c0f0b3 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -413,6 +413,19 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
unsigned i;
if (!error) {
+ if (parser->chunk_flags &&
+ parser->chunk_flags->length_dw > 4) {
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ uint32_t __user *to = parser->chunk_flags->user_ptr;
+ uint64_t id;
+
+ mutex_lock(&fpriv->seq_lock);
+ id = radeon_seq_push(&fpriv->seq, parser->ib.fence);
+ mutex_unlock(&fpriv->seq_lock);
+
+ copy_to_user(&to[3], &id, sizeof(uint64_t));
+ }
+
/* Sort the buffer list from the smallest to largest buffer,
* which affects the order of buffers in the LRU list.
* This assures that the smallest buffers are added first
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 85ee6f7..38880af 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -578,39 +578,34 @@ void radeon_driver_lastclose_kms(struct drm_device *dev)
*/
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
{
+ struct radeon_fpriv *fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
struct radeon_device *rdev = dev->dev_private;
int r;
- file_priv->driver_priv = NULL;
+ if (unlikely(!fpriv))
+ return -ENOMEM;
+
+ file_priv->driver_priv = fpriv;
r = pm_runtime_get_sync(dev->dev);
if (r < 0)
- return r;
+ goto error;
/* new gpu have virtual address space support */
if (rdev->family >= CHIP_CAYMAN) {
- struct radeon_fpriv *fpriv;
struct radeon_vm *vm;
int r;
- fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
- if (unlikely(!fpriv)) {
- return -ENOMEM;
- }
-
vm = &fpriv->vm;
r = radeon_vm_init(rdev, vm);
- if (r) {
- kfree(fpriv);
- return r;
- }
+ if (r)
+ goto error;
if (rdev->accel_working) {
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
- kfree(fpriv);
- return r;
+ goto error;
}
/* map th
[PATCH 1/3] drm/radeon: use pointers instead of indexes for CS chunks
From: Christian K?nig
Nobody is interested at which index the chunk is. What's needed is
a pointer to the chunk. Remove unused chunk_id field as well.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen_cs.c | 6 ++--
drivers/gpu/drm/radeon/r100.c | 2 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 14 -
drivers/gpu/drm/radeon/radeon.h | 11 +++
drivers/gpu/drm/radeon/radeon_cs.c| 57 +--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 10 +++---
drivers/gpu/drm/radeon/radeon_vce.c | 4 +--
9 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 5c8b358..6c60e70 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2661,7 +2661,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
p->track = NULL;
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib.length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
@@ -2684,7 +2684,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
**/
int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
{
- struct radeon_cs_chunk *ib_chunk = &p->chunks[p->chunk_ib_idx];
+ struct radeon_cs_chunk *ib_chunk = p->chunk_ib;
struct radeon_cs_reloc *src_reloc, *dst_reloc, *dst2_reloc;
u32 header, cmd, count, sub_cmd;
volatile u32 *ib = p->ib.ptr;
@@ -3100,7 +3100,7 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
DRM_ERROR("Unknown packet type %d at %d !\n", cmd, idx);
return -EINVAL;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib->length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index c6b486f..43d129a 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2061,7 +2061,7 @@ int r100_cs_parse(struct radeon_cs_parser *p)
}
if (r)
return r;
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 1bc4704..b0a5ade 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1283,7 +1283,7 @@ int r300_cs_parse(struct radeon_cs_parser *p)
if (r) {
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index c47537a..654b38b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2316,7 +2316,7 @@ int r600_cs_parse(struct radeon_cs_parser *p)
p->track = NULL;
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib.length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
@@ -2351,7 +2351,7 @@ static void r600_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
static int r600_cs_parser_relocs_legacy(struct radeon_cs_parser *p)
{
- if (p->chunk_relocs_idx == -1) {
+ if (p->chunk_relocs == NULL) {
return 0;
}
p->relocs = kzalloc(sizeof(struct radeon_cs_reloc), GFP_KERNEL);
@@ -2398,7 +2398,7 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
/* Copy the packet into the IB, the parser will read from the
* input memory (cached) and write to the IB (which can be
* uncached). */
- ib_chunk = &parser.chunks[parser.chunk_ib_idx];
+ ib_chunk = parser.chunk_ib;
parser.ib.length_dw = ib_chunk->length_dw;
*l = parser.ib.length_dw;
if (copy_from_user(ib, ib_chunk->user_ptr, ib_chunk->length_dw * 4)) {
@@ -2441,11 +2441,11 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
unsigned idx;
*cs_reloc = NULL;
- if (p->chunk_relocs_idx == -1) {
+ if (p->chunk_relocs == NULL) {
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- relocs_chunk = &p->chunks[p->chunk_relocs_idx];
+ relocs_chunk = p->chunk_relocs;
[BUG] nouveau regression: ext monitor dead after resume
I have tried and reverted these commits but to no avail. 028791bb7d6 drm/nouveau/kms: restore fbcon after display has been resumed 456b0579fb0 drm/nouveau: use connector events for HPD instead of GPIO watching
[PATCH v2 1/5] drm/rockchip: Add basic drm driver
On Thu, Sep 18, 2014 at 04:52:14PM +0200, Daniel Vetter wrote:
> On Thu, Sep 18, 2014 at 05:36:31PM +0800, Mark yao wrote:
> > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> >
> > Signed-off-by: Mark yao
> > ---
> > Changes in v2:
> > - use the component framework to defer main drm driver probe
> > until all VOP devices have been probed.
> > - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
> > master device and each vop device can shared the drm dma mapping.
> > - use drm_crtc_init_with_planes and drm_universal_plane_init.
> > - remove unnecessary middle layers.
> > - add cursor set, move funcs to rockchip drm crtc.
> > - use vop reset at first init
> > - reference framebuffer when used and unreference when swap out vop
> >
>
> > +static const struct drm_crtc_funcs rockchip_crtc_funcs = {
> > + .set_config = drm_crtc_helper_set_config,
> > + .page_flip = rockchip_drm_crtc_page_flip,
> > + .destroy = rockchip_drm_crtc_destroy,
> > + .cursor_set = vop_crtc_cursor_set,
> > + .cursor_move = vop_crtc_cursor_move,
>
> If you expose your cursor plane as a universal you don't need to implement
> these two cursor functions at all. Actually the core never calls them, see
> drm_mode_cursor_universal. So if you want to expose cursors, please use
> universal cursor plane support (like i915).
>
> In general that's how new drivers should expose cursors since without
> universal planes support cursors will not be supported with the atomic
> ioctl. Since your cursor code just calls the relevant plane functions that
> should even simplify your driver ;-)
Actually you already initialize with cursor universal planes, so all this
code can simply be removed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/5] drm/rockchip: Add basic drm driver
On Thu, Sep 18, 2014 at 05:36:31PM +0800, Mark yao wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao
> ---
> Changes in v2:
> - use the component framework to defer main drm driver probe
> until all VOP devices have been probed.
> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
> master device and each vop device can shared the drm dma mapping.
> - use drm_crtc_init_with_planes and drm_universal_plane_init.
> - remove unnecessary middle layers.
> - add cursor set, move funcs to rockchip drm crtc.
> - use vop reset at first init
> - reference framebuffer when used and unreference when swap out vop
>
> +static const struct drm_crtc_funcs rockchip_crtc_funcs = {
> + .set_config = drm_crtc_helper_set_config,
> + .page_flip = rockchip_drm_crtc_page_flip,
> + .destroy = rockchip_drm_crtc_destroy,
> + .cursor_set = vop_crtc_cursor_set,
> + .cursor_move = vop_crtc_cursor_move,
If you expose your cursor plane as a universal you don't need to implement
these two cursor functions at all. Actually the core never calls them, see
drm_mode_cursor_universal. So if you want to expose cursors, please use
universal cursor plane support (like i915).
In general that's how new drivers should expose cursors since without
universal planes support cursors will not be supported with the atomic
ioctl. Since your cursor code just calls the relevant plane functions that
should even simplify your driver ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 5/5] drm/i915: remove intel_pipe_set_base()
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 79
1 file changed, 8 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c61c8f..2477587 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2763,74 +2763,6 @@ static void intel_update_pipe_size(struct intel_crtc
*crtc)
crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
}
-static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *fb)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- struct drm_framebuffer *old_fb = crtc->primary->fb;
- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
- int ret;
-
- if (intel_crtc_has_pending_flip(crtc)) {
- DRM_ERROR("pipe is still busy with an old pageflip\n");
- return -EBUSY;
- }
-
- /* no fb bound */
- if (!fb) {
- DRM_ERROR("No FB bound\n");
- return 0;
- }
-
- if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
- DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
- plane_name(intel_crtc->plane),
- INTEL_INFO(dev)->num_pipes);
- return -EINVAL;
- }
-
- mutex_lock(&dev->struct_mutex);
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- if (ret == 0)
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(&dev->struct_mutex);
- if (ret != 0) {
- DRM_ERROR("pin & fence failed\n");
- return ret;
- }
-
- intel_update_pipe_size(intel_crtc);
-
- dev_priv->display.update_primary_plane(crtc, fb, x, y);
-
- if (intel_crtc->active)
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
-
- crtc->primary->fb = fb;
- crtc->x = x;
- crtc->y = y;
-
- if (old_fb) {
- if (intel_crtc->active && old_fb != fb)
- intel_wait_for_vblank(dev, intel_crtc->pipe);
- mutex_lock(&dev->struct_mutex);
- intel_unpin_fb_obj(old_obj);
- mutex_unlock(&dev->struct_mutex);
- }
-
- mutex_lock(&dev->struct_mutex);
- intel_update_fbc(dev);
- mutex_unlock(&dev->struct_mutex);
-
- return 0;
-}
-
static void intel_fdi_normal_train(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -9797,6 +9729,7 @@ static int intel_crtc_commit_page_flip(struct drm_crtc
*crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_plane *primary = crtc->primary;
enum pipe pipe = intel_crtc->pipe;
struct intel_unpin_work *work;
struct intel_engine_cs *ring;
@@ -9938,7 +9871,9 @@ free_work:
if (ret == -EIO) {
out_hang:
intel_crtc_wait_for_pending_flips(crtc);
- ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
+ ret = primary->funcs->update_plane(primary, crtc, fb,
+ 0, 0, 0, 0,
+ crtc->x, crtc->y, 0, 0);
if (ret == 0 && event) {
spin_lock_irq(&dev->event_lock);
drm_send_vblank_event(dev, pipe, event);
@@ -11475,11 +11410,13 @@ static int intel_crtc_set_config(struct drm_mode_set
*set)
set->x, set->y, set->fb);
} else if (config->fb_changed) {
struct intel_crtc *intel_crtc = to_intel_crtc(set->crtc);
+ struct drm_plane *primary = set->crtc->primary;
intel_crtc_wait_for_pending_flips(set->crtc);
- ret = intel_pipe_set_base(set->crtc,
- set->x, set->y, set->fb);
+ ret = primary->funcs->update_plane(primary, set->crtc, set->fb,
+ 0, 0, 0, 0,
+ set->x, set->y, 0, 0);
/*
* We need to make sure the primary plane is re-enabled if it
--
1.9.3
[PATCH 4/5] drm/i915: split intel_crtc_page_flip() into check() and commit()
From: Daniel Stone
Start the work of splitting the intel_crtc_page_flip() for later use
by the atomic modesetting API.
Signed-off-by: Daniel Stone
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 51 ++--
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad86fa3..6c61c8f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9757,23 +9757,11 @@ void intel_check_page_flip(struct drm_device *dev, int
pipe)
spin_unlock(&dev->event_lock);
}
-static int intel_crtc_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event,
- uint32_t page_flip_flags)
+static int intel_crtc_check_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb)
{
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_framebuffer *old_fb = crtc->primary->fb;
- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- struct intel_unpin_work *work;
- struct intel_engine_cs *ring;
- int ret;
-
- //trigger software GT busyness calculation
- gen8_flip_interrupt(dev);
/*
* drm_mode_page_flip_ioctl() should already catch this, but double
@@ -9796,6 +9784,27 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
fb->pitches[0] != crtc->primary->fb->pitches[0]))
return -EINVAL;
+ return 0;
+}
+
+static int intel_crtc_commit_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_framebuffer *old_fb = crtc->primary->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct intel_unpin_work *work;
+ struct intel_engine_cs *ring;
+ int ret;
+
+ /* trigger software GT busyness calculation */
+ gen8_flip_interrupt(dev);
+
if (i915_terminally_wedged(&dev_priv->gpu_error))
goto out_hang;
@@ -9939,6 +9948,20 @@ out_hang:
return ret;
}
+static int intel_crtc_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+ int ret;
+
+ ret = intel_crtc_check_page_flip(crtc, fb);
+ if (ret)
+ return ret;
+
+ return intel_crtc_commit_page_flip(crtc, fb, event, page_flip_flags);
+}
+
static struct drm_crtc_helper_funcs intel_helper_funcs = {
.mode_set_base_atomic = intel_pipe_set_base_atomic,
.load_lut = intel_crtc_load_lut,
--
1.9.3
[PATCH 3/5] drm/i915: remove intel_crtc_cursor_set_obj()
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both paths into one.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 229 ---
1 file changed, 106 insertions(+), 123 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a68befb..ad86fa3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8362,117 +8362,6 @@ static bool cursor_size_ok(struct drm_device *dev,
return true;
}
-/*
- * intel_crtc_cursor_set_obj - Set cursor to specified GEM object
- *
- * Note that the object's reference will be consumed if the update fails. If
- * the update succeeds, the reference of the old object (if any) will be
- * consumed.
- */
-static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
-struct drm_i915_gem_object *obj,
-uint32_t width, uint32_t height)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- unsigned old_width;
- uint32_t addr;
- int ret;
-
- /* if we want to turn off the cursor ignore width and height */
- if (!obj) {
- DRM_DEBUG_KMS("cursor off\n");
- addr = 0;
- mutex_lock(&dev->struct_mutex);
- goto finish;
- }
-
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(&dev->struct_mutex);
- if (!INTEL_INFO(dev)->cursor_needs_physical) {
- unsigned alignment;
-
- /*
-* Global gtt pte registers are special registers which actually
-* forward writes to a chunk of system memory. Which means that
-* there is no risk that the register values disappear as soon
-* as we call intel_runtime_pm_put(), so it is correct to wrap
-* only the pin/unpin/fence and not more.
-*/
- intel_runtime_pm_get(dev_priv);
-
- /* Note that the w/a also requires 2 PTE of padding following
-* the bo. We currently fill all unused PTE with the shadow
-* page and so we should always have valid PTE following the
-* cursor preventing the VT-d warning.
-*/
- alignment = 0;
- if (need_vtd_wa(dev))
- alignment = 64*1024;
-
- ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
- if (ret) {
- DRM_DEBUG_KMS("failed to move cursor bo into the
GTT\n");
- intel_runtime_pm_put(dev_priv);
- goto fail_locked;
- }
-
- ret = i915_gem_object_put_fence(obj);
- if (ret) {
- DRM_DEBUG_KMS("failed to release fence for cursor");
- intel_runtime_pm_put(dev_priv);
- goto fail_unpin;
- }
-
- addr = i915_gem_obj_ggtt_offset(obj);
-
- intel_runtime_pm_put(dev_priv);
- } else {
- int align = IS_I830(dev) ? 16 * 1024 : 256;
- ret = i915_gem_object_attach_phys(obj, align);
- if (ret) {
- DRM_DEBUG_KMS("failed to attach phys object\n");
- goto fail_locked;
- }
- addr = obj->phys_handle->busaddr;
- }
-
- finish:
- if (intel_crtc->cursor_bo) {
- if (!INTEL_INFO(dev)->cursor_needs_physical)
-
i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
- }
-
- i915_gem_track_fb(intel_crtc->cursor_bo, obj,
- INTEL_FRONTBUFFER_CURSOR(pipe));
- mutex_unlock(&dev->struct_mutex);
-
- old_width = intel_crtc->cursor_width;
-
- intel_crtc->cursor_addr = addr;
- intel_crtc->cursor_bo = obj;
- intel_crtc->cursor_width = width;
- intel_crtc->cursor_height = height;
-
- if (intel_crtc->active) {
- if (old_width != width)
- intel_update_watermarks(crtc);
- intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
- }
-
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
-
- return 0;
-fail_unpin:
- i915_gem_object_unpin_from_display_plane(obj);
-fail_locked:
- mutex_unlock(&dev->struct_mutex);
- drm_gem_object_unreference_unlocked(&obj->base);
- retur
[PATCH 2/5] drm/i915: move checks of intel_crtc_cursor_set_obj() out
From: Gustavo Padovan
Move checks inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use they there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unification
of plane operations such pin/unpin of fb objects on i915.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 66
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1fd9b70..a68befb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8377,7 +8377,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- unsigned old_width, stride;
+ unsigned old_width;
uint32_t addr;
int ret;
@@ -8389,30 +8389,11 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
goto finish;
}
- /* Check for which cursor types we support */
- if (!cursor_size_ok(dev, width, height)) {
- DRM_DEBUG("Cursor dimension not supported\n");
- return -EINVAL;
- }
-
- stride = roundup_pow_of_two(width) * 4;
- if (obj->base.size < stride * height) {
- DRM_DEBUG_KMS("buffer is too small\n");
- ret = -ENOMEM;
- goto fail;
- }
-
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(&dev->struct_mutex);
if (!INTEL_INFO(dev)->cursor_needs_physical) {
unsigned alignment;
- if (obj->tiling_mode) {
- DRM_DEBUG_KMS("cursor cannot be tiled\n");
- ret = -EINVAL;
- goto fail_locked;
- }
-
/*
* Global gtt pte registers are special registers which actually
* forward writes to a chunk of system memory. Which means that
@@ -8488,7 +8469,6 @@ fail_unpin:
i915_gem_object_unpin_from_display_plane(obj);
fail_locked:
mutex_unlock(&dev->struct_mutex);
-fail:
drm_gem_object_unreference_unlocked(&obj->base);
return ret;
}
@@ -12039,16 +12019,58 @@ intel_check_cursor_plane(struct drm_plane *plane,
struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
+ struct drm_device *dev = crtc->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ int crtc_w, crtc_h;
+ unsigned stride;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
true, true, &state->visible);
+ if (ret)
+ return ret;
+
+ crtc_w = drm_rect_width(&state->orig_dst);
+ crtc_h = drm_rect_height(&state->orig_dst);
+
+ /* if we want to turn off the cursor ignore width and height */
+ if (!obj)
+ return 0;
+
+ if (fb == crtc->cursor->fb)
+ return 0;
+
+ /* Check for which cursor types we support */
+ if (!cursor_size_ok(dev, crtc_w, crtc_h)) {
+ DRM_DEBUG("Cursor dimension not supported\n");
+ return -EINVAL;
+ }
+
+ stride = roundup_pow_of_two(crtc_w) * 4;
+ if (obj->base.size < stride * crtc_h) {
+ DRM_DEBUG_KMS("buffer is too small\n");
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ /* we only need to pin inside GTT if cursor is non-phy */
+ mutex_lock(&dev->struct_mutex);
+ if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
+ DRM_DEBUG_KMS("cursor cannot be tiled\n");
+ ret = -EINVAL;
+ }
+ mutex_unlock(&dev->struct_mutex);
+
+fail:
+ drm_gem_object_unreference_unlocked(&obj->base);
+ return ret;
}
static int
--
1.9.3
[PATCH 1/5] drm/i915: Merge of visible and !visible paths for primary planes
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Ville's comments:
- remove unnecessary plane check
- move mutex lock to inside the conditional
- make the pin fail message a debug one
- add a fixme for the fastboot hack
- call intel_frontbuffer_flip() after FBC update
v3: take more Ville's comments:
- fold update code under if (intel_crtc->active), and do the
visible/!visible split inside.
- check ret inside the same conditional we assign it
v4: don't use intel_enable_primary_hw_plane(), the primary_enabled
check inside will break page flips
Suggested-by: Ville Syrj?l?
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 141 +--
1 file changed, 84 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5b05ddb..1fd9b70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11792,12 +11792,23 @@ intel_check_primary_plane(struct drm_plane *plane,
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true, &state->visible);
+ if (ret)
+ return ret;
+
+ /* no fb bound */
+ if (state->visible && !fb) {
+ DRM_ERROR("No FB bound\n");
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -11809,6 +11820,8 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -11817,67 +11830,28 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_crtc_wait_for_pending_flips(crtc);
- /*
-* If clipping results in a non-visible primary plane, we'll disable
-* the primary plane. Note that this is a bit different than what
-* happens if userspace explicitly disables the plane by passing fb=0
-* because plane->fb still gets set and pinned.
-*/
- if (!state->visible) {
- mutex_lock(&dev->struct_mutex);
-
- /*
-* Try to pin the new fb first so that we can bail out if we
-* fail.
-*/
- if (plane->fb != fb) {
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- if (ret) {
- mutex_unlock(&dev->struct_mutex);
- return ret;
- }
- }
-
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
-
- if (intel_crtc->primary_enabled)
- intel_disable_primary_hw_plane(plane, crtc);
-
-
- if (plane->fb != fb)
- if (plane->fb)
- intel_unpin_fb_obj(old_obj);
+ if (intel_crtc_has_pending_flip(crtc)) {
+ DRM_ERROR("pipe is still busy with an old pageflip\n");
+ return -EBUSY;
+ }
+ if (plane->fb != fb) {
+ mutex_lock(&dev->struct_mutex);
+ ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+ if (ret == 0)
+ i915_gem_track_fb(old_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
mutex_unlock(&dev->struct_mutex);
-
- } else {
- if (intel_crtc && intel_crtc->active &&
- intel_crtc->primary_enabled) {
- /*
-* FBC does not work on some platforms for rotated
-* planes, so disable it when rotation is not 0 and
-* update it when rotation is set back to 0.
-*
-* FIXME: This is redundant w
[BUG] nouveau regression: ext monitor dead after resume
Hi, Since 3.16 an external monitor stays dark after resume from sleep. I didn't manage to activate it again with xrand. According to xrandr it is "connected" and configured with a mode, but I get no signal. Happens since 3.16 and is still broken with 3.17-rc5. Hardware: HP EliteBook 8540w 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX 1800M] (rev a2) 0 External Monitor connected via DVI on the docking station. XRandR before amd after suspend looks the same: $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x60059.9 640x48059.4 720x40059.6 640x40060.0 640x35059.8 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) eDP-1 disconnected (normal left inverted right x axis y axis) DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 72.8 66.7 60.0 720x40070.1 VGA-1 disconnected (normal left inverted right x axis y axis) dmesg output of a suspend/resume cycle attached. -- next part -- [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.17.0-rc5 (root at ortwin-hp) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.3, pie-0.5.5) ) #2 SMP PREEMPT Thu Sep 18 12:27:26 CEST 2014 [0.00] Command line: BOOT_IMAGE=/boot/linux-3.17.0-rc5 root=/dev/sda1 rootfstype=ext4 nouveau.noaccel=1 net.ifnames=0 pcie_aspm=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbefc1fff] usable [0.00] BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved [0.00] BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data [0.00] BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable [0.00] BIOS-e820: [mem 0xbf80-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved [0.00] BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1b000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001fbff] usable [0.00] BIOS-e820: [mem 0x0001fc00-0x0001] reserved [0.00] BIOS-e820: [mem 0x0002-0x00023bff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Hewlett-Packard HP EliteBook 8540w/1521, BIOS 68CVD Ver. F.0E 11/25/2010 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC000 write-back [0.00] 3 base 1 mask F write-back [0.00] 4 base 2 mask FC000 write-back [0.00] 5 base 23C00 mask FFC00 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x02371000, 0x02371fff] PGTABLE [0.00] BRK [0x02
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #8 from Alex Deucher --- Created attachment 150801 --> https://bugzilla.kernel.org/attachment.cgi?id=150801&action=edit possible fix for mullins This patch may fix Hin-Tak's issue, but won't affect the original reporter. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #7 from Alex Deucher --- (In reply to Hin-Tak Leung from comment #6) > From mine (toshiba, but I believe the hp has similar graphic hardware): > > dmesg: > > [drm] Found VCE firmware/feedback version 40.2.2 / 15! > > # lspci | grep VGA > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Mullins [Radeon R3 Graphics] > > > I looked up that 'VCE firmware/feedback' line where it comes from in the > kernel code. It seems that Mullins support in new to kernel 3.15.x (?) and > still being actively worked on. Is that correct? This is a different chip than ?lvaro, so it's probably a different issue. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/exynos: switch to universal plane API
The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
I have tested this patch with trats board, it looks OK.
As a side effect it should solve fb refcounting issues
reported by me and Daniel Drake.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 ---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
4 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..d2f713e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,7 +32,6 @@ enum exynos_crtc_mode {
* Exynos specific crtc structure.
*
* @drm_crtc: crtc object.
- * @drm_plane: pointer of private plane object for this crtc
* @manager: the manager associated with this crtc
* @pipe: a crtc index created at load() with a new crtc object creation
* and the crtc object would be set to private->crtc array
@@ -46,7 +45,6 @@ enum exynos_crtc_mode {
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
- struct drm_plane*plane;
struct exynos_drm_manager *manager;
unsigned intpipe;
unsigned intdpms;
@@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
- exynos_plane_commit(exynos_crtc->plane);
+ exynos_plane_commit(crtc->primary);
if (manager->ops->commit)
manager->ops->commit(manager);
- exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
+ exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
}
static bool
@@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
- int ret;
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
@@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
*/
memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
if (manager->ops->mode_set)
manager->ops->mode_set(manager, &crtc->mode);
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
- if (ret)
- return ret;
-
- plane->crtc = crtc;
- plane->fb = crtc->primary->fb;
- drm_framebuffer_reference(plane->fb);
-
- return 0;
+ return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+crtc_w, crtc_h, x, y, crtc_w, crtc_h);
}
static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
@@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
drm_crtc *crtc, int x, int y,
return -EPERM;
}
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
+ ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, x, y, crtc_w, crtc_h);
if (ret)
return ret;
@@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
private->crtc[exynos_crtc->pipe] = NULL;
+ crtc->primary->funcs->destroy(crtc->primary);
drm_crtc_cleanup(crtc);
kfree(exynos_crtc);
}
@@ -304,8 +294,7 @@ static int exynos_drm_crtc_set_property(struct drm_crtc
*crtc,
exynos_drm_crtc_commit(crtc);
break;
case CRTC_MODE_BLANK:
-
[PATCH v2 7/8] drm/radeon: export reservation_object from dmabuf to ttm
Am 18.09.2014 um 14:11 schrieb Maarten Lankhorst:
> drm/radeon: export reservation_object from dmabuf to ttm
>
> Adds an extra argument to radeon_bo_create, which is only used in
> radeon_prime.c.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian K?nig
> ---
> v2:
> robj -> resv
> fix typo in commit description
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 1440b6e9281e..1f8484284b47 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -4690,7 +4690,7 @@ static int cik_mec_init(struct radeon_device *rdev)
> r = radeon_bo_create(rdev,
>rdev->mec.num_mec *rdev->mec.num_pipe *
> MEC_HPD_SIZE * 2,
>PAGE_SIZE, true,
> - RADEON_GEM_DOMAIN_GTT, 0, NULL,
> + RADEON_GEM_DOMAIN_GTT, 0, NULL, NULL,
>&rdev->mec.hpd_eop_obj);
> if (r) {
> dev_warn(rdev->dev, "(%d) create HDP EOP bo failed\n",
> r);
> @@ -4861,7 +4861,7 @@ static int cik_cp_compute_resume(struct radeon_device
> *rdev)
>sizeof(struct bonaire_mqd),
>PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_GTT, 0, NULL,
> - &rdev->ring[idx].mqd_obj);
> + NULL, &rdev->ring[idx].mqd_obj);
> if (r) {
> dev_warn(rdev->dev, "(%d) create MQD bo
> failed\n", r);
> return r;
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index dbca60c7d097..c6ccef6c3596 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -4023,7 +4023,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
> if (rdev->rlc.save_restore_obj == NULL) {
> r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> - &rdev->rlc.save_restore_obj);
> + NULL, &rdev->rlc.save_restore_obj);
> if (r) {
> dev_warn(rdev->dev, "(%d) create RLC sr bo
> failed\n", r);
> return r;
> @@ -4102,7 +4102,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
> if (rdev->rlc.clear_state_obj == NULL) {
> r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> - &rdev->rlc.clear_state_obj);
> + NULL, &rdev->rlc.clear_state_obj);
> if (r) {
> dev_warn(rdev->dev, "(%d) create RLC c bo
> failed\n", r);
> sumo_rlc_fini(rdev);
> @@ -4179,7 +4179,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
> r = radeon_bo_create(rdev, rdev->rlc.cp_table_size,
>PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> - &rdev->rlc.cp_table_obj);
> + NULL, &rdev->rlc.cp_table_obj);
> if (r) {
> dev_warn(rdev->dev, "(%d) create RLC cp table
> bo failed\n", r);
> sumo_rlc_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 35c22ee9bc4a..a82eaa81cd07 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1430,7 +1430,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
> if (rdev->vram_scratch.robj == NULL) {
> r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
>PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
> - 0, NULL, &rdev->vram_scratch.robj);
> + 0, NULL, NULL, &rdev->vram_scratch.robj);
> if (r) {
> return r;
> }
> @@ -3368,7 +3368,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
> r = radeon_bo_create(rdev, rdev->ih.ring_size,
>PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_GTT, 0,
> - NULL, &rdev->ih.ring_obj);
> + NULL, NULL, &rdev->ih.ring_obj);
> if (r) {
> DRM_ERROR("radeon: failed to create ih ring buffer
> (%d).\n", r);
>
[PULL] drm-intel-fixes
Hi Dave, a couple of small display fixes for 3.17. There was another bdw ips fix that I'd already pushed, but I had to drop it just now as it regressed. We'll need to come back to that later, details at https://bugs.freedesktop.org/show_bug.cgi?id=83497. BR, Jani. The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-09-18 for you to fetch changes up to 8c875fca1a8d76665c60fa141c220cee65f44f5e: drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv (2014-09-18 14:52:14 +0300) Chris Wilson (1): drm/i915: Fix SRC_COPY width on 830/845g Ville Syrj?l? (1): drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv drivers/gpu/drm/i915/intel_dp.c | 4 drivers/gpu/drm/i915/intel_hdmi.c | 7 ++- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- 3 files changed, 11 insertions(+), 2 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH v2] drm/exynos: use drm generic mmap interface
This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.
We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.
This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.
Changelog v2:
- do not set VM_IO, VM_DONTEXPEND and VM_DONTDUMP. These flags were already
set by drm_gem_mmap
- do not include , which isn't needed anymore.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 89 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
include/uapi/drm/exynos_drm.h | 22
5 files changed, 16 insertions(+), 132 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..928c514 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -15,7 +15,6 @@
#include
#include
-#include
#include
#include
@@ -149,10 +148,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
}
-static const struct file_operations exynos_drm_gem_fops = {
- .mmap = exynos_drm_gem_mmap_buffer,
-};
-
static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_connector *connector;
@@ -191,7 +186,6 @@ static int exynos_drm_resume(struct drm_device *dev)
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
- struct file *anon_filp;
int ret;
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +198,8 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
if (ret)
goto err_file_priv_free;
- anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
- NULL, 0);
- if (IS_ERR(anon_filp)) {
- ret = PTR_ERR(anon_filp);
- goto err_subdrv_close;
- }
-
- anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
- file_priv->anon_filp = anon_filp;
-
return ret;
-err_subdrv_close:
- exynos_drm_subdrv_close(dev, file);
-
err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +215,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +240,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
spin_unlock_irqrestore(&dev->event_lock, flags);
- file_priv = file->driver_priv;
- if (file_priv->anon_filp)
- fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -282,8 +258,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
- exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
struct device *ipp_dev;
- struct file *anon_filp;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..0d5b969 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,16 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
struct vm_area_str
[PATCH 2/2] drm/exynos: use drm generic mmap interface
Thanks for review.
Below trivial things you pointed out will be fixed soon.
On 2014? 09? 18? 13:56, Joonyoung Shim wrote:
> Hi,
>
> On 09/17/2014 10:48 PM, Inki Dae wrote:
>> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
>> to Exynos drm and instead uses drm generic mmap.
>>
>> We had used the interface specific to Exynos drm to do mmap directly,
>> not to use demand paging which maps each page with physical memory
>> at page fault handler. We don't need the specific mmap interface
>> because the drm generic mmap which uses vm offset manager stuff can
>> also do mmap directly.
>>
>> This patch makes a userspace region to be mapped with whole physical
>> memory region allocated by userspace request when mmap system call is
>> requested.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
>> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 84
>> ++-
>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
>> include/uapi/drm/exynos_drm.h | 22
>> 5 files changed, 14 insertions(+), 128 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 10ad3d4..a7819eb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
> Because anymore anon file doesn't use, you can remove to include
> .
Right, I missed it while taking away the direct mmap stuff specific to
Exynos drm.
>
>> @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
>> return 0;
>> }
>>
>> -static const struct file_operations exynos_drm_gem_fops = {
>> -.mmap = exynos_drm_gem_mmap_buffer,
>> -};
>> -
>> static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
>> {
>> struct drm_connector *connector;
>> @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
>> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> {
>> struct drm_exynos_file_private *file_priv;
>> -struct file *anon_filp;
>> int ret;
>>
>> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
>> @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev,
>> struct drm_file *file)
>> if (ret)
>> goto err_file_priv_free;
>>
>> -anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
>> -NULL, 0);
>> -if (IS_ERR(anon_filp)) {
>> -ret = PTR_ERR(anon_filp);
>> -goto err_subdrv_close;
>> -}
>> -
>> -anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
>> -file_priv->anon_filp = anon_filp;
>> -
>> return ret;
>>
>> -err_subdrv_close:
>> -exynos_drm_subdrv_close(dev, file);
>> -
>> err_file_priv_free:
>> kfree(file_priv);
>> file->driver_priv = NULL;
>> @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
>> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
>> *file)
>> {
>> struct exynos_drm_private *private = dev->dev_private;
>> -struct drm_exynos_file_private *file_priv;
>> struct drm_pending_vblank_event *v, *vt;
>> struct drm_pending_event *e, *et;
>> unsigned long flags;
>> @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device
>> *dev, struct drm_file *file)
>> }
>> spin_unlock_irqrestore(&dev->event_lock, flags);
>>
>> -file_priv = file->driver_priv;
>> -if (file_priv->anon_filp)
>> -fput(file_priv->anon_filp);
>> -
>> kfree(file->driver_priv);
>> file->driver_priv = NULL;
>> }
>> @@ -282,8 +259,6 @@ static const struct vm_operations_struct
>> exynos_drm_gem_vm_ops = {
>> static const struct drm_ioctl_desc exynos_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>> DRM_UNLOCKED | DRM_AUTH),
>> -DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
>> -exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
>> exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
>> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 69a6fa3..d22e640 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
>> struct drm_exynos_file_private {
>> struct exynos_drm_g2d_private *g2d_priv;
>> struct device *ipp_dev;
>> -struct file *anon_filp;
>> };
>>
>> /*
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 2f3665d..3cf6494 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exyn
[PATCH v2 7/8] drm/radeon: export reservation_object from dmabuf to ttm
drm/radeon: export reservation_object from dmabuf to ttm
Adds an extra argument to radeon_bo_create, which is only used in
radeon_prime.c.
Signed-off-by: Maarten Lankhorst
---
v2:
robj -> resv
fix typo in commit description
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 1440b6e9281e..1f8484284b47 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4690,7 +4690,7 @@ static int cik_mec_init(struct radeon_device *rdev)
r = radeon_bo_create(rdev,
rdev->mec.num_mec *rdev->mec.num_pipe *
MEC_HPD_SIZE * 2,
PAGE_SIZE, true,
-RADEON_GEM_DOMAIN_GTT, 0, NULL,
+RADEON_GEM_DOMAIN_GTT, 0, NULL, NULL,
&rdev->mec.hpd_eop_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create HDP EOP bo failed\n",
r);
@@ -4861,7 +4861,7 @@ static int cik_cp_compute_resume(struct radeon_device
*rdev)
sizeof(struct bonaire_mqd),
PAGE_SIZE, true,
RADEON_GEM_DOMAIN_GTT, 0, NULL,
-&rdev->ring[idx].mqd_obj);
+NULL, &rdev->ring[idx].mqd_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create MQD bo
failed\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index dbca60c7d097..c6ccef6c3596 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4023,7 +4023,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
if (rdev->rlc.save_restore_obj == NULL) {
r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
RADEON_GEM_DOMAIN_VRAM, 0, NULL,
-&rdev->rlc.save_restore_obj);
+NULL, &rdev->rlc.save_restore_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC sr bo
failed\n", r);
return r;
@@ -4102,7 +4102,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
if (rdev->rlc.clear_state_obj == NULL) {
r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
RADEON_GEM_DOMAIN_VRAM, 0, NULL,
-&rdev->rlc.clear_state_obj);
+NULL, &rdev->rlc.clear_state_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC c bo
failed\n", r);
sumo_rlc_fini(rdev);
@@ -4179,7 +4179,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev->rlc.cp_table_size,
PAGE_SIZE, true,
RADEON_GEM_DOMAIN_VRAM, 0, NULL,
-&rdev->rlc.cp_table_obj);
+NULL, &rdev->rlc.cp_table_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC cp table
bo failed\n", r);
sumo_rlc_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 35c22ee9bc4a..a82eaa81cd07 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1430,7 +1430,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
if (rdev->vram_scratch.robj == NULL) {
r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
-0, NULL, &rdev->vram_scratch.robj);
+0, NULL, NULL, &rdev->vram_scratch.robj);
if (r) {
return r;
}
@@ -3368,7 +3368,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev->ih.ring_size,
PAGE_SIZE, true,
RADEON_GEM_DOMAIN_GTT, 0,
-NULL, &rdev->ih.ring_obj);
+NULL, NULL, &rdev->ih.ring_obj);
if (r) {
DRM_ERROR("radeon: failed to create ih ring buffer
(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 1e8855060fc7..9e7f23dd14bd 100644
-
nouveau regression: read fault PAGE_NOT_PRESENT with new fence interface
Hi, I noticed a regression in the next-20140903 kernel that was not present in next-20140902. When Xorg starts up, the display is garbled (or contains old image bits) and I see a page fault in the kernel log. X is not usable in this state - there is no pointer and gdm doesn't come up. It works fine after Xorg (gdm3) is restarted. The fault is still present in next-20140918. [drm] Initialized nouveau 1.2.0 20120801 for :01:00.0 on minor 0 nouveau E[ PFIFO][:01:00.0] read fault at 0x000126 [PAGE_NOT_PRESENT] from PGRAPH/GPC0/TEX on channel 0x001fcd1000 [Xorg[3874]] nouveau E[ PFIFO][:01:00.0] PGRAPH engine fault on channel 2, recovering... nouveau E[ PGRAPH][:01:00.0] TRAP ch 2 [0x001fcd1000 Xorg[3874]] nouveau E[ PGRAPH][:01:00.0] GPC0/TPC0/TEX: 0x8041 My hardware is: NVIDIA Corporation GF119 [Quadro NVS 4200M] (rev a1) I bisected it down to this commit: commit 29ba89b2371d466ca68973525816cf10debc2655 Author: Maarten Lankhorst Date: Thu Jan 9 11:03:11 2014 +0100 drm/nouveau: rework to new fence interface Signed-off-by: Maarten Lankhorst Acked-by: Ben Skeggs I tried tracing the DEVICE, PGRAPH, PFIFO & PCE0 engines but nothing obvious stood out before the read fault shown above. Is there any other information I can provide to help track this down? paranoia or spam level logging, for example?
[PATCH 1/3] drm/radeon: don't reset dma on NI/SI init
On Thu, Sep 18, 2014 at 1:51 PM, Christian K?nig
wrote:
> Am 18.09.2014 um 19:26 schrieb Alex Deucher:
>>
>> Otherwise we may lose the DMA golden settings which can
>> lead to hangs, etc.
>
>
> Don't we still want the soft reset at some point, e.g. when the engine
> hangs?
>
> I would rather move that to another function and call it before loading the
> golden values.
We have separate soft reset code for dma already. This is just a
one-off soft reset in the dma init code. The golden registers are
reloaded after a GPU reset so we should be fine.
Alex
>
> Christian.
>
>
>>
>> bug:
>> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500
>>
>> Signed-off-by: Alex Deucher
>> Cc: stable at vger.kernel.org
>> ---
>> drivers/gpu/drm/radeon/ni_dma.c | 6 --
>> 1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/ni_dma.c
>> b/drivers/gpu/drm/radeon/ni_dma.c
>> index 8a3e622..f26f0a9 100644
>> --- a/drivers/gpu/drm/radeon/ni_dma.c
>> +++ b/drivers/gpu/drm/radeon/ni_dma.c
>> @@ -191,12 +191,6 @@ int cayman_dma_resume(struct radeon_device *rdev)
>> u32 reg_offset, wb_offset;
>> int i, r;
>> - /* Reset dma */
>> - WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
>> - RREG32(SRBM_SOFT_RESET);
>> - udelay(50);
>> - WREG32(SRBM_SOFT_RESET, 0);
>> -
>> for (i = 0; i < 2; i++) {
>> if (i == 0) {
>> ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
>
>
[PATCH 2/2] drm/exynos: use drm generic mmap interface
Hi,
On 09/17/2014 10:48 PM, Inki Dae wrote:
> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
> to Exynos drm and instead uses drm generic mmap.
>
> We had used the interface specific to Exynos drm to do mmap directly,
> not to use demand paging which maps each page with physical memory
> at page fault handler. We don't need the specific mmap interface
> because the drm generic mmap which uses vm offset manager stuff can
> also do mmap directly.
>
> This patch makes a userspace region to be mapped with whole physical
> memory region allocated by userspace request when mmap system call is
> requested.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 84
> ++-
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
> include/uapi/drm/exynos_drm.h | 22
> 5 files changed, 14 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 10ad3d4..a7819eb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
Because anymore anon file doesn't use, you can remove to include
.
> @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
> return 0;
> }
>
> -static const struct file_operations exynos_drm_gem_fops = {
> - .mmap = exynos_drm_gem_mmap_buffer,
> -};
> -
> static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
> {
> struct drm_connector *connector;
> @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
> {
> struct drm_exynos_file_private *file_priv;
> - struct file *anon_filp;
> int ret;
>
> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
> @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev,
> struct drm_file *file)
> if (ret)
> goto err_file_priv_free;
>
> - anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
> - NULL, 0);
> - if (IS_ERR(anon_filp)) {
> - ret = PTR_ERR(anon_filp);
> - goto err_subdrv_close;
> - }
> -
> - anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
> - file_priv->anon_filp = anon_filp;
> -
> return ret;
>
> -err_subdrv_close:
> - exynos_drm_subdrv_close(dev, file);
> -
> err_file_priv_free:
> kfree(file_priv);
> file->driver_priv = NULL;
> @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
> *file)
> {
> struct exynos_drm_private *private = dev->dev_private;
> - struct drm_exynos_file_private *file_priv;
> struct drm_pending_vblank_event *v, *vt;
> struct drm_pending_event *e, *et;
> unsigned long flags;
> @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
> struct drm_file *file)
> }
> spin_unlock_irqrestore(&dev->event_lock, flags);
>
> - file_priv = file->driver_priv;
> - if (file_priv->anon_filp)
> - fput(file_priv->anon_filp);
> -
> kfree(file->driver_priv);
> file->driver_priv = NULL;
> }
> @@ -282,8 +259,6 @@ static const struct vm_operations_struct
> exynos_drm_gem_vm_ops = {
> static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> DRM_UNLOCKED | DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
> - exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
> exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 69a6fa3..d22e640 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
> struct drm_exynos_file_private {
> struct exynos_drm_g2d_private *g2d_priv;
> struct device *ipp_dev;
> - struct file *anon_filp;
> };
>
> /*
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 2f3665d..3cf6494 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
> drm_gem_object_unreference_unlocked(obj);
> }
>
> -int exynos_drm_gem_mmap_buffer(struct file *filp,
> +int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
>
[PATCH 3/3] drm/radeon: don't reset dma on r6xx-evergreen init
Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/r600_dma.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_dma.c b/drivers/gpu/drm/radeon/r600_dma.c index 51fd985..a908daa 100644 --- a/drivers/gpu/drm/radeon/r600_dma.c +++ b/drivers/gpu/drm/radeon/r600_dma.c @@ -124,15 +124,6 @@ int r600_dma_resume(struct radeon_device *rdev) u32 rb_bufsz; int r; - /* Reset dma */ - if (rdev->family >= CHIP_RV770) - WREG32(SRBM_SOFT_RESET, RV770_SOFT_RESET_DMA); - else - WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA); - RREG32(SRBM_SOFT_RESET); - udelay(50); - WREG32(SRBM_SOFT_RESET, 0); - WREG32(DMA_SEM_INCOMPLETE_TIMER_CNTL, 0); WREG32(DMA_SEM_WAIT_FAIL_TIMER_CNTL, 0); -- 1.8.3.1
[PATCH 2/3] drm/radeon: don't reset sdma on CIK init
Otherwise we may lose the DMA golden settings which can
lead to hangs, etc.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik_sdma.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
b/drivers/gpu/drm/radeon/cik_sdma.c
index 192278b..c4ffa54 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -489,13 +489,6 @@ int cik_sdma_resume(struct radeon_device *rdev)
{
int r;
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_SDMA | SOFT_RESET_SDMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
- RREG32(SRBM_SOFT_RESET);
-
r = cik_sdma_load_microcode(rdev);
if (r)
return r;
--
1.8.3.1
[PATCH 1/3] drm/radeon: don't reset dma on NI/SI init
Otherwise we may lose the DMA golden settings which can
lead to hangs, etc.
bug:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ni_dma.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
index 8a3e622..f26f0a9 100644
--- a/drivers/gpu/drm/radeon/ni_dma.c
+++ b/drivers/gpu/drm/radeon/ni_dma.c
@@ -191,12 +191,6 @@ int cayman_dma_resume(struct radeon_device *rdev)
u32 reg_offset, wb_offset;
int i, r;
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
for (i = 0; i < 2; i++) {
if (i == 0) {
ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
--
1.8.3.1
[PATCH 3/3] drm/nouveau/runpm: fix module unload
On Sun, Sep 14, 2014 at 3:33 PM, Alex Deucher wrote:
> Use the new vga_switcheroo_fini_domain_pm_ops function
> to unregister the pm ops.
>
> Based on a patch from:
> Pali Roh?r
>
> bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=84431
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> Cc: Ben Skeggs
Dave or Ben any comment on this patch? I'd like the merge the radeon
parts for -fixes and this one seems logic too.
Alex
> ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index 18d55d4..c7592ec 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -108,7 +108,16 @@ void
> nouveau_vga_fini(struct nouveau_drm *drm)
> {
> struct drm_device *dev = drm->dev;
> + bool runtime = false;
> +
> + if (nouveau_runtime_pm == 1)
> + runtime = true;
> + if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() ||
> nouveau_is_v1_dsm()))
> + runtime = true;
> +
> vga_switcheroo_unregister_client(dev->pdev);
> + if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> + vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
> vga_client_register(dev->pdev, NULL, NULL, NULL);
> }
>
> --
> 1.8.3.1
>
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #25 from Alex Deucher --- (In reply to comment #24) > Apply them both together. Well, assuming your laptop has the same pci ids as Patrick. If not, just append radeon.backlight=0 to the kernel command line in grub and attach your lspci -vnn output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/2a5e9c1e/attachment.html>
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #24 from Alex Deucher --- Apply them both together. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/40187cbb/attachment-0001.html>
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, On Wednesday 17 September 2014 15:43:04 Ajay kumar wrote: > Hi Laurent, > > Please find the latest series here: > http://www.spinics.net/lists/dri-devel/msg66740.html Thank you. My comment was meant to be general though, not just for your patch series. > On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart wrote: > > On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote: [snip] > >> One other thing: how does the bridge know which mode to drive? I suspect > >> that it can drive more than one mode? Can it freely be configured or > >> does it have a predefined set of modes? If the latter, then according to > >> what you said above there needs to be a way to configure the bridge (via > >> DT?) so that it reports the mode matching the panel. I wonder if that > >> should be handled completely in code, so that for example a bridge has a > >> panel attached it can use the panel's .get_modes() and select a matching > >> mode among the set that it supports. > > > > Yes, pretty please :-) I don't think it would be a good idea to duplicate > > mode information in the bridge DT node, as that's not a property of the > > bridge. Querying the mode at runtime is in my opinion a much better > > option, and would also allow switching between different modes at runtime > > when that makes sense. > > > > Now, I'm not sure whether it should be the bridge driver querying the > > panel driver directly, or the display controller driver doing it and then > > configuring the bridge accordingly. The latter seems more generic to me > > and doesn't rely on the assumption that the bridge output will always be > > directly connected to a panel. -- Regards, Laurent Pinchart
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #8 from Jack --- (In reply to comment #7) > Looks like maybe ttm_bo_ioremap() doesn't work correctly. Which path does it > take? which path does it take? you mean... but I get the start = reloc->lobj.gpu_offset, start is 0x182c000, this address is gpu address,base address is 0x0. when do ttm_bo_ioremap the cpu virtual address is 0x00ca1182c000, reference as radeon.log ,the address mapping seems good. By the way, when I do the ring_ib_test on ring 5, also failed, unhandle request address come out. Next I will do some trace for ring_ib_test,because this not depend on libdrm.only construct msg and send. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/7b3907db/attachment.html>
[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object
On 17.09.2014 21:35, Maarten Lankhorst wrote: > diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c > b/drivers/gpu/drm/radeon/radeon_semaphore.c > index 4d4b0773638a..68311da39c09 100644 > --- a/drivers/gpu/drm/radeon/radeon_semaphore.c > +++ b/drivers/gpu/drm/radeon/radeon_semaphore.c > @@ -124,27 +124,39 @@ void radeon_semaphore_sync_fence(struct > radeon_semaphore *semaphore, >* >* Sync to the fence using this semaphore object >*/ > -void radeon_semaphore_sync_resv(struct radeon_semaphore *sema, > - struct reservation_object *resv, > - bool shared) > +int radeon_semaphore_sync_resv(struct radeon_device *rdev, > +struct radeon_semaphore *sema, > +struct reservation_object *resv, > +bool shared, bool intr) The callers of this function would be more readable if it took flags instead of the shared and intr bools. -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH 7/8] drm/radeon: export reservation_object from dmabuf to ttm
On 17.09.2014 21:35, Maarten Lankhorst wrote: > Adds an extra argument to ttm_bo_create, which is only used in radeon_prime.c. Typo: 'ttm_bo_create' -> 'radeon_bo_create' -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object
Hey, Op 18-09-14 om 05:26 schreef Michel D?nzer: > On 17.09.2014 21:35, Maarten Lankhorst wrote: >> diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c >> b/drivers/gpu/drm/radeon/radeon_semaphore.c >> index 4d4b0773638a..68311da39c09 100644 >> --- a/drivers/gpu/drm/radeon/radeon_semaphore.c >> +++ b/drivers/gpu/drm/radeon/radeon_semaphore.c >> @@ -124,27 +124,39 @@ void radeon_semaphore_sync_fence(struct >> radeon_semaphore *semaphore, >>* >>* Sync to the fence using this semaphore object >>*/ >> -void radeon_semaphore_sync_resv(struct radeon_semaphore *sema, >> -struct reservation_object *resv, >> -bool shared) >> +int radeon_semaphore_sync_resv(struct radeon_device *rdev, >> + struct radeon_semaphore *sema, >> + struct reservation_object *resv, >> + bool shared, bool intr) > > The callers of this function would be more readable if it took flags instead > of the shared and intr bools. This does not match the rest of the TTM design. Things like ttm_bo_reserve take separate bools, not flags. ~Maarten
[GIT PULL FOR v3.18] Renesas DRM changes
Hi Simon, On Thursday 18 September 2014 18:11:31 Simon Horman wrote: > On Mon, Sep 15, 2014 at 12:09:55PM +0300, Laurent Pinchart wrote: > > Hi Dave, > > > > Could you please pull the following changes for v3.18 ? > > > > Commit "drm/rcar-du: Use struct videomode in platform data" touches board > > code in arch/arm/mach-shmobile. There is, to the best of my knowledge, no > > risk of conflict for v3.18. Simon, are you fine with getting those > > changes merged through Dave's tree (and could you confirm that no > > conflict should occur) ? > > > > The following changes since commit > > 98faa78ce7f1f986e11e7805d31b409782a6d2d4: > > Merge tag 'topic/drm-header-rework-2014-09-12' of > > > > git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 > > +1000) > > > > are available in the git repository at: > > git://linuxtv.org/pinchartl/fbdev.git drm/next/du > > > > for you to fetch changes up to 96c026911890ceacee238da00a0b140ad634cc43: > > drm/rcar-du: Add OF support (2014-09-15 11:55:47 +0300) > > Hi Laurent, Hi Dave, > > I'm comfortable with these shmobile changes going via Dave's tree > as they do not seem to conflict with anything queued up between > for v3.18. I would however like these changes included in v3.18-rc1 > so that I can manage any conflicts that may emerge in patches I queue > up for v3.19. > > I'm not asking you to update the patches, but for the record, > shmobile portion: > > Acked-by: Simon Horman Thank you. Dave, if you haven't pulled the patches yet, could you apply Simon's ack when you do ? > > > > > > Laurent Pinchart (10): > > drm/rcar-du: Update copyright notice > > drm/shmob: Update copyright notice > > devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt > > devicetree: Add vendor prefix "thine" to vendor-prefixes.txt > > video: Add DT binding documentation for VGA connector > > video: Add ADV7123 DT bindings documentation > > video: Add THC63LVDM83D DT bindings documentation > > video: Add DT bindings for the R-Car Display Unit > > drm/rcar-du: Use struct videomode in platform data > > drm/rcar-du: Add OF support > > > > Documentation/devicetree/bindings/vendor-prefixes.txt | 2 + > > Documentation/devicetree/bindings/video/adi,adv7123.txt | 50 + > > Documentation/devicetree/bindings/video/renesas,du.txt | 84 + > > .../devicetree/bindings/video/thine,thc63lvdm83d| 50 + > > .../devicetree/bindings/video/vga-connector.txt | 36 > > arch/arm/mach-shmobile/board-koelsch-reference.c| 19 +- > > arch/arm/mach-shmobile/board-koelsch.c | 19 +- > > arch/arm/mach-shmobile/board-lager-reference.c | 19 +- > > arch/arm/mach-shmobile/board-lager.c| 19 +- > > arch/arm/mach-shmobile/board-marzen.c | 19 +- > > drivers/gpu/drm/rcar-du/Kconfig | 1 + > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 172 ++- > > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +- > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 13 +- > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 5 +- > > drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 233 +-- > > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 45 +++-- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 5 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c| 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_vgacon.h| 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c| 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_drv.h| 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_kms.c| 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_kms.h| 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_plane.
[PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register
On Thursday 18 September 2014 08:55 AM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I
> wrote:
>>
>>
>> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>>> and accessed to control power to the PHY.
>>> With mfd-syscon and regmap interface available at our disposal,
>>> it's wise to use that instead of using a 'reg' property for the
>>> controller and allocating a memory resource for that.
>>>
>>> To facilitate this, we have added another compatible string
>>> for Exynso5420 SoC to acquire driver data which contains
>>> different DP-PHY-CONTROL register offset.
>>>
>>> Signed-off-by: Vivek Gautam
>>> Cc: Jingoo Han
>>> Cc: Kishon Vijay Abraham I
>>
>> Taking this in linux-phy tree. If someone has already taken this patch,
>> please
>> let me know.
>
> Thanks for taking this. But just one check, i think i need to separate
> out the Documentation
> to a separate patch even before this driver patch. Isn't it ?
no.. that's alright.
Thanks
Kishon
>
>>
>> Thanks
>> Kishon
>>
>>> ---
>>>
>>> Changes since v2:
>>> - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>>
>>> Changes since v1:
>>> - state->regs should have been "struct regmap *" instead of
>>>"void __iomem *". So corrected the same.
>>>
>>> .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>> drivers/phy/phy-exynos-dp-video.c | 79
>>> +---
>>> 2 files changed, 59 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 7a6feea..15e0f2c 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>> -
>>>
>>> Required properties:
>>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>>> -- reg : offset and length of the Display Port PHY register set;
>>> +- compatible : should be one of the following supported values:
>>> + - "samsung,exynos5250-dp-video-phy"
>>> + - "samsung,exynos5420-dp-video-phy"
>>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>>> + control pmu registers for power isolation.
>>> - #phy-cells : from the generic PHY bindings, must be 0;
>>>
>>> Samsung S5P/EXYNOS SoC series USB PHY
>>> diff --git a/drivers/phy/phy-exynos-dp-video.c
>>> b/drivers/phy/phy-exynos-dp-video.c
>>> index 8b3026e..53f44a0 100644
>>> --- a/drivers/phy/phy-exynos-dp-video.c
>>> +++ b/drivers/phy/phy-exynos-dp-video.c
>>> @@ -13,44 +13,55 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> -/* DPTX_PHY_CONTROL register */
>>> -#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
>>> +struct exynos_dp_video_phy_drvdata {
>>> + u32 phy_ctrl_offset;
>>> +};
>>>
>>> struct exynos_dp_video_phy {
>>> - void __iomem *regs;
>>> + struct regmap *regs;
>>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>> };
>>>
>>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
>>> on)
>>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>>> + unsigned int on)
>>> {
>>> - u32 reg;
>>> + unsigned int val;
>>> +
>>> + if (IS_ERR(state->regs))
>>> + return;
>>>
>>> - reg = readl(state->regs);
>>> - if (on)
>>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>>> - else
>>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>>> - writel(reg, state->regs);
>>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>>
>>> - return 0;
>>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>>> +EXYNOS5_PHY_ENABLE, val);
>>> }
>>>
>>> static int exynos_dp_video_phy_power_on(struct phy *phy)
>>> {
>>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 1);
>>> + /* Disable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 0);
>>> +
>>> + return 0;
>>> }
>>>
>>> static int exynos_dp_video_phy_power_off(struct phy *phy)
>>> {
>>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 0);
>>> + /* Enable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 1);
>>> +
>>> + return 0;
>>> }
>>>
>>> static struct phy_ops exynos_dp_video_phy_ops = {
>>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>> .owner = THI
[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen
wrote:
> On 17/09/14 17:29, Ajay kumar wrote:
>> Hi Tomi,
>>
>> Thanks for your comments.
>>
>> On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen
>> wrote:
>>> On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8622" or "parade,ps8625"
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
>>>
>>> What does this mean? That the backlight support from ps8625 is not used?
>>> If so, maybe "disable-pwm" or something?
>> "use-external-pwm" or "disable-bridge-pwm" would be better.
>
> Well, the properties are about the bridge. "use-external-pwm" means that
> the bridge uses an external PWM, which, if I understood correctly, is
> not what the property is about.
>
> "disable-bridge-pwm" is ok, but the "bridge" there is extra. The
> properties are about the bridge, so it's implicit.
Ok. I will use "disable-pwm".
+
+Example:
+ lvds-bridge at 48 {
+ compatible = "parade,ps8622";
+ reg = <0x48>;
+ sleep-gpios = <&gpc3 6 1 0 0>;
+ reset-gpios = <&gpc3 1 1 0 0>;
+ lane-count = <1>;
+ };
>>>
>>> I wish all new display component bindings would use the video
>>> ports/endpoints to describe the connections. It will be very difficult
>>> to improve the display driver model later if we're missing such critical
>>> pieces from the DT bindings.
>> Why do we need a complex graph when it can be handled using a simple phandle?
>
> Maybe in your case you can handle it with simple phandle. Can you
> guarantee that it's enough for everyone, on all platforms?
Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
this. In case of both, the phandle to bridge node is passed to the
exynos_dp node.
> The point of the ports/endpoint graph is to also support more
> complicated scenarios. If you now create ps8622 bindings that do not
> support those graphs, the no one else using ps8622 can use
> ports/endpoint graphs either.
>
> Btw, is there an example how the bridge with these bindings is used in a
> board's .dts file? I couldn't find any example with a quick search. So
> it's unclear to me what the "simple phandle" actually is.
Please refer to the following link:
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
Let me know if you still think we would need to describe it as a complex graph!
Ajay
[BUG] nouveau regression: ext monitor dead after resume
On Thu, Sep 18, 2014 at 10:07 AM, Ortwin Gl?ck wrote: > Hi, > > Since 3.16 an external monitor stays dark after resume from sleep. I didn't > manage to activate it > again with xrand. According to xrandr it is "connected" and configured with a > mode, but I get no signal. > > Happens since 3.16 and is still broken with 3.17-rc5. > > Hardware: > HP EliteBook 8540w > 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX > 1800M] (rev a2) > 0 > > External Monitor connected via DVI on the docking station. This has been reported a few times already -- probably the same thing as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550 Sorry, no resolution as of yet. If you could verify that the commit that got bisected to in that bug indeed causes your problem, it would be nice to have before and after logs from a kernel compiled with NOUVEAU_DEBUG set to 7 (spam) booted with nouveau.debug=trace,PDISP=spam . That should hopefully help isolate the issue. (Don't use a kernel with NOUVEAU_DEBUG set that high for daily use -- it introduces a ton of debug code everywhere.) If the commit that got bisected to in the bug is not the cause of your issues, you'll need to do your own bisect. Cheers, -ilia > > XRandR before amd after suspend looks the same: > > $ xrandr > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 > LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 345mm x 194mm >1920x1080 59.9*+ 60.0 >1680x1050 60.0 >1400x1050 60.0 >1280x1024 59.9 >1280x960 59.9 >1152x864 60.0 >1024x768 59.9 >800x60059.9 >640x48059.4 >720x40059.6 >640x40060.0 >640x35059.8 > DP-1 disconnected (normal left inverted right x axis y axis) > DP-2 disconnected (normal left inverted right x axis y axis) > eDP-1 disconnected (normal left inverted right x axis y axis) > DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm > x 336mm >1920x1080 60.0*+ >1680x1050 59.9 >1280x1024 75.0 60.0 >1440x900 75.0 59.9 >1024x768 75.1 60.0 >800x60075.0 60.3 >640x48075.0 72.8 66.7 60.0 >720x40070.1 > VGA-1 disconnected (normal left inverted right x axis y axis) > > dmesg output of a suspend/resume cycle attached.
[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
On Thu, 18 Sep 2014 00:13:09 +0300 Jyri Sarha wrote: > > So, Jean-Francois is also trying to do things with the TDA998x - what's > > the story with that, is this joined up at all? > > Not really. This basic functionality does not touch tda998x at all on > the fly, but just sets i2s configuation in the beginning and bangs the > bits trough McASP. But as long as the old platform data for tda998x > still works after Jean-Francois' patches I should be safe. It should. And you may test it. > The problem with the Jean-Francois' patches is the DT support. The BBB > HDMI video is implemented trough tilcdc-slave mechanism without a DT > node for the tda encoder, which renders Jean-Francois' approach unusable > for BBB. I used the TDA998x with DT support for a long time with a hack by using parts of drm_i2c_encoder_init(). Now, I think that this function could be used as it is just setting no platform_data in info. > The whole tilcdc slave approach may not be the most elegant way to use > the tda driver, but it does not look like it is going to change any time > soon. Right: I proposed a patch for that and it was rejected. > Best regards, > Jyri > > ps. I have been thinking on something similar to Jean-Francois' patch > for SiI9022 which I have been working on lately. Also I have been > wondering if it would be possible to come up with a generic ASoC codec > component driver or library that could be used with any HDMI encoder to > produce the ASoC codec component. Unfortunately I am in too early stage > to produce anything more concrete. Here are some thoughts about this topic. The video and audio worlds don't know about each other. The only solution I found is to let the encoder create the codec as a child device. Then, the codec knows from which encoder it depends. This could have been done using Russell's components, but the codec should have been declared in the DT. This is not useful. The codec interacts with the encoder in 2 ways: - it uses the HDMI parameters retrieved by the encoder, - it gives the audio source type to the encoder. I used exported functions for that, but, for a generic codec, theses functions could be given through the codec platform_data. The codec declares the DAI(s) prior to know the encoder. The DAI table must be in the codec because of the snd_soc_dai_ops. For a generic codec, this DAI table could be built dynamically from information (name, id) also given through the codec platform_data. -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH] drm/exynos: fix plane-framebuffer linkage
Hi, On 09/18/2014 01:41 AM, Daniel Drake wrote: > On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote: >> I think fb refcounting in exynos is just plain busted. If you look at >> other drivers the only place the refcount framebuffers or backing >> storage objects is for pageflips to make sure the memory doesn't go >> away while the hw is still scanning out the old framebuffer. If you >> refcount anywhere else you either do something really crazy or your >> driver is broken. > > With my patch actually the behaviour is much more similar to omapdrm, Your patch will occur fb reference count problem when setplane. > which also doesn't quite match your description of "other drivers". > See omap_plane.c. > > There is a fb reference taken for "pinning" in update_pin() which > presumably is what you describe - avoid destroying the fb while it is > being scanned out. (Maybe exynos should have something equivalent too, > but thats a separate issue) > > However there is *another* fb reference taken in > omap_plane_mode_set(). And my patch is modelled to do the same in > exynos-drm. > > I believe this is necessary under the current model. At least, when > drm_mode_rmfb() is running for the last user of the active > framebuffer, it expects to drop 3 references from the framebuffer > before dropping the 4th causes the object to be destroyed, as follows: > > 1. drm_mode_rmfb explicitly drops a reference - it calls > __drm_framebuffer_unregister which then calls > __drm_framebuffer_unreference > /* Mark fb as reaped, we still have a ref from fpriv->fbs. */ > __drm_framebuffer_unregister(dev, fb); > > 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls > drm_mode_set_config_internal() in order to turn off the CRTC, dropping > another reference in the process. > if (tmp->old_fb) > drm_framebuffer_unreference(tmp->old_fb); > > 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops > another reference: > /* disconnect the plane from the fb and crtc: */ > __drm_framebuffer_unreference(old_fb); This call is new path, before universal planes merged, private plane of exynos crtc wasn't included in dev->mode_config.plane_list because private plane wasn't exposed to userspace so this path wasn't called. > > 4. drm_framebuffer drops the final reference itself, to cause freeing > of the object: > drm_framebuffer_unreference(fb); > > > So ordinarily, after a fb is created by drm core (with refcnt at 1), > there would have to be 3 references added to it by the time it is the > primary fb so that when we do rmfb, it has a refcnt of 4, and gets > freed correctly. > (The second bug I was seeing with pageflips was that refcnt was 3, > which means that the final reference was dropped in (3) above, but > __drm_framebuffer_unreference doesn't like that at all - it calls > drm_framebuffer_free_bug) > > Not being overly familiar with DRM internals I tried to go backwards > to find out where these 3 references would be created during normal > operation. 2 are clear: > > 1. drm_framebuffer_init() explicitly grabs one: > /* Grab the idr reference. */ > drm_framebuffer_reference(fb) > > 2. drm_mode_set_config_internal() takes one: > if (tmp->primary->fb) > drm_framebuffer_reference(tmp->primary->fb); > > Where should the 3rd one be created? I don't know, but looking at > previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm > driver should take one, both on crtc mode set and crtc page flip. So Andrzej added fb reference count increasing in crtc modeset path, but i think we can take away this workaround if remove private plane for exynos crtc. Thanks. > >>> However, I'll be happy if universal planes means the driver does not >>> have to care about this any more. Andrej, please go ahead if you are >>> interested, I'll be happy to test your results. >> >> universal planes will fix up the mess with 2 drm plane objects >> (primary plane + exonys internal primary). So should help to untangle >> this not, but it will not magically fix the refcounting bugs itself. > > So even when we move to universal planes (fixing 1 of the issues), its > good that we're having this refcount discussion (which we need to > understand to confidently solve the 2nd issue). Thanks for your input! > > Daniel >
[PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register
Hi Kishon,
On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I
wrote:
>
>
> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>> and accessed to control power to the PHY.
>> With mfd-syscon and regmap interface available at our disposal,
>> it's wise to use that instead of using a 'reg' property for the
>> controller and allocating a memory resource for that.
>>
>> To facilitate this, we have added another compatible string
>> for Exynso5420 SoC to acquire driver data which contains
>> different DP-PHY-CONTROL register offset.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Jingoo Han
>> Cc: Kishon Vijay Abraham I
>
> Taking this in linux-phy tree. If someone has already taken this patch, please
> let me know.
Thanks for taking this. But just one check, i think i need to separate
out the Documentation
to a separate patch even before this driver patch. Isn't it ?
>
> Thanks
> Kishon
>
>> ---
>>
>> Changes since v2:
>> - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>
>> Changes since v1:
>> - state->regs should have been "struct regmap *" instead of
>>"void __iomem *". So corrected the same.
>>
>> .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>> drivers/phy/phy-exynos-dp-video.c | 79
>> +---
>> 2 files changed, 59 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 7a6feea..15e0f2c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>> -
>>
>> Required properties:
>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>> -- reg : offset and length of the Display Port PHY register set;
>> +- compatible : should be one of the following supported values:
>> + - "samsung,exynos5250-dp-video-phy"
>> + - "samsung,exynos5420-dp-video-phy"
>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>> + control pmu registers for power isolation.
>> - #phy-cells : from the generic PHY bindings, must be 0;
>>
>> Samsung S5P/EXYNOS SoC series USB PHY
>> diff --git a/drivers/phy/phy-exynos-dp-video.c
>> b/drivers/phy/phy-exynos-dp-video.c
>> index 8b3026e..53f44a0 100644
>> --- a/drivers/phy/phy-exynos-dp-video.c
>> +++ b/drivers/phy/phy-exynos-dp-video.c
>> @@ -13,44 +13,55 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> +#include
>>
>> -/* DPTX_PHY_CONTROL register */
>> -#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
>> +struct exynos_dp_video_phy_drvdata {
>> + u32 phy_ctrl_offset;
>> +};
>>
>> struct exynos_dp_video_phy {
>> - void __iomem *regs;
>> + struct regmap *regs;
>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>> };
>>
>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
>> on)
>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>> + unsigned int on)
>> {
>> - u32 reg;
>> + unsigned int val;
>> +
>> + if (IS_ERR(state->regs))
>> + return;
>>
>> - reg = readl(state->regs);
>> - if (on)
>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>> - else
>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>> - writel(reg, state->regs);
>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>
>> - return 0;
>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>> +EXYNOS5_PHY_ENABLE, val);
>> }
>>
>> static int exynos_dp_video_phy_power_on(struct phy *phy)
>> {
>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 1);
>> + /* Disable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 0);
>> +
>> + return 0;
>> }
>>
>> static int exynos_dp_video_phy_power_off(struct phy *phy)
>> {
>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 0);
>> + /* Enable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 1);
>> +
>> + return 0;
>> }
>>
>> static struct phy_ops exynos_dp_video_phy_ops = {
>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>> .owner = THIS_MODULE,
>> };
>>
>> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
>> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
>> +};
>> +
>> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
>> +
[PATCH RESEND] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig
From: Fabio Estevam SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry. Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig index 2f228a2..8696d20 100644 --- a/drivers/gpu/ipu-v3/Kconfig +++ b/drivers/gpu/ipu-v3/Kconfig @@ -1,6 +1,6 @@ config IMX_IPUV3_CORE tristate "IPUv3 core support" - depends on SOC_IMX5 || SOC_IMX6Q || SOC_IMX6SL || ARCH_MULTIPLATFORM + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM depends on RESET_CONTROLLER help Choose this if you have a i.MX5/6 system and want to use the Image -- 1.8.3.2
[PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: > 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls > drm_mode_set_config_internal() in order to turn off the CRTC, dropping > another reference in the process. > if (tmp->old_fb) > drm_framebuffer_unreference(tmp->old_fb); > > 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops > another reference: > /* disconnect the plane from the fb and crtc: */ > __drm_framebuffer_unreference(old_fb); If 3. here is about the primary plane then this won't happen, since the primary plane pointer&reference has already been cleared in step 2. And even if their would be a bug in here, you _certainly_ should not try to paper over this in your driver, but instead fix up the refcounting done in the drm core. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: > However there is *another* fb reference taken in > omap_plane_mode_set(). And my patch is modelled to do the same in > exynos-drm. This is because omapdrm does _everything_ asynchrously, even plain modesets. Unfortunately that async modeset support is broken, so the latest omapdrm patches insert a synchronization point. So picking omap's mode_set logic as a reference because it also does fb refcounting is not a good idea - that code does something crazy and gets it wrong. And really, if you do modeset synchronously the drm core will take care of your refcounting needs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 Hin-Tak Leung changed: What|Removed |Added CC||htl10 at users.sourceforge.net --- Comment #6 from Hin-Tak Leung --- >From mine (toshiba, but I believe the hp has similar graphic hardware): dmesg: [drm] Found VCE firmware/feedback version 40.2.2 / 15! # lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] I looked up that 'VCE firmware/feedback' line where it comes from in the kernel code. It seems that Mullins support in new to kernel 3.15.x (?) and still being actively worked on. Is that correct? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #23 from Daniel Kirsten --- I can test the patches from 2014-09-17 on my amilo. Can I apply them to the current fedora kernel code 3.14.18-100? Should I apply both patches or test each patch separately? Daniel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/689b1376/attachment.html>
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #7 from Michel D?nzer --- Looks like maybe ttm_bo_ioremap() doesn't work correctly. Which path does it take? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/1702029f/attachment-0001.html>
[PATCH] drm/exynos: fix plane-framebuffer linkage
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter wrote: > On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: >> 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls >> drm_mode_set_config_internal() in order to turn off the CRTC, dropping >> another reference in the process. >> if (tmp->old_fb) >> drm_framebuffer_unreference(tmp->old_fb); >> >> 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops >> another reference: >> /* disconnect the plane from the fb and crtc: */ >> __drm_framebuffer_unreference(old_fb); > > If 3. here is about the primary plane then this won't happen, since > the primary plane pointer&reference has already been cleared in step > 2. I just checked - as Joonyoung suspects, the plane being force disabled in step 3 is the private exynos-drm plane. So thats an issue - but at least now I have a complete understanding of the problem. Sounds like that will also be fixed by moving to universal planes. I'll wait for Andrzej's patch. Thanks! Daniel
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #6 from Jack --- (In reply to comment #1) > (In reply to comment #1) > > Hi, I try to using gpu hardware accelerate to play video from mplayer > > (vdpau+uvd) . The machine architecture is sparc64,video card is radeon > > HD7450,OS version is redhat7,kernel version is 3.10.0, mplayer version is > > 1.1-21,mesa version is 9.2.5-6. > > Please attach the output of dmesg (showing at least all radeon driver > related initialization), the /var/log/Xorg.0.log file and the output of > vdpauinfo. > > Can you try newer versions of the kernel and Mesa? > > P.S. AFAICT the 7450 is Northern Islands generation (Caicos) based, not > Southern Islands based, otherwise I'd be very surprised you even got this > far, given bug 82455. :) Hi, attachment are the logs of xort,radeon init,vdpauinfo, the output seem to be ok. I try to trace the code ,found that it execute radeon_uvd_cs_reloc func to get the start address of the relocs in GPU RAM. reloc = p->relocs_ptr[idx/4] (idx is 0) start = reloc->lobj.gpu_offset and the start address is start:0x182c000, the radeon_uvd_cs_msg func can remap the gpu address to cpu virtual address use radeon_bo_kmap(bo, &ptr)->ttm_bo_ioremap, the return cpu virtual address is [zd radeon_uvd_cs_msg] ptr:00ca1182c000, msg:00ca1182c000. and this address is the unhandle address, see the error log. I try to change the PAGE_SHIFT to 12(gpu page shift) in the ttm_bo_ioremap(cpu is 8K page size ,gpu is 4K page size) ,but no effects. I think the bo store in gpu ram has the wrong gpu_offset.But I don't know the reason. the only way can effect this is the remap,base the different cpu page size and gpu page size. Can give me any idea about this? Or maybe have some ways to verified? Tks By the way, where can download the document about the ttm and gem ? I am puzzled about the principle of gpu memory managerment . -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/12ab8654/attachment.html>
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #5 from Jack --- Created attachment 106482 --> https://bugs.freedesktop.org/attachment.cgi?id=106482&action=edit error log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/f80cd4ea/attachment.html>
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #4 from Jack --- Created attachment 106481 --> https://bugs.freedesktop.org/attachment.cgi?id=106481&action=edit radeon init log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/98698519/attachment.html>
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #3 from Jack --- Created attachment 106480 --> https://bugs.freedesktop.org/attachment.cgi?id=106480&action=edit vdpau log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/b5414ab0/attachment.html>
[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=83708 --- Comment #2 from Jack --- Created attachment 106479 --> https://bugs.freedesktop.org/attachment.cgi?id=106479&action=edit xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/6c60d4b9/attachment.html>
[Bug 84771] nouveau MMIO read write FAULT HUB_INIT timed out errors
https://bugzilla.kernel.org/show_bug.cgi?id=84771 --- Comment #2 from christtchin at gmail.com --- I had errors in 3.16 as well. I'm not sure if the errors are related. I was getting different errors during boot. Here's a few dmesg logs from that kernel. Unresponsive but numlock key works: http://pastebin.com/kzbWdZ0W Boots with one MMIO error: http://pastebin.com/jdSnrzN7 Boots with multiple errors: http://pastebin.com/yRxvh5bB -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84771] nouveau MMIO read write FAULT HUB_INIT timed out errors
https://bugzilla.kernel.org/show_bug.cgi?id=84771 Ilia Mirkin changed: What|Removed |Added CC||imirkin at alum.mit.edu --- Comment #1 from Ilia Mirkin --- Did this work with older kernels? If so, a bisect would be useful. Most reports of pgraph timeouts are on GK104/GK106 chips while you have a GK107... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84771] New: nouveau MMIO read write FAULT HUB_INIT timed out errors
https://bugzilla.kernel.org/show_bug.cgi?id=84771 Bug ID: 84771 Summary: nouveau MMIO read write FAULT HUB_INIT timed out errors Product: Drivers Version: 2.5 Kernel Version: 3.17-rc4 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: christtchin at gmail.com Regression: No Created attachment 150771 --> https://bugzilla.kernel.org/attachment.cgi?id=150771&action=edit dmesg of regular boot + startx Trying to run Arch Linux on a Lenovo Y400 with an nvidia GT750M graphics card. When trying to boot the nouveau drivers consistently spit out multiple errors. Computer continues the boot process. Errors also occur whenever I try to run anything with hardware acceleration, such as Xorg. It is a similar output to the one that occurs during boot: PBUS, PIBUS, and PGRAPH errors. Attached is a dmesg log of a regular boot and startx. Also a log of opening up Xorg: http://pastebin.com/w48Dx4qq And a log of opening up weston: http://pastebin.com/1VPFgapP -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"
https://bugs.freedesktop.org/show_bug.cgi?id=83748 --- Comment #10 from John --- Just in case, I tried with Alex's linux drm-next tree, but it didn't make a difference. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/8e4c6421/attachment.html>
[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers
https://bugs.freedesktop.org/show_bug.cgi?id=83998 --- Comment #4 from Michel D?nzer --- (In reply to comment #3) > I wanna see if you have other same symptoms I have with random crashing on my > system. Aaron, I don't think this bug is related to yours. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/3c875c80/attachment-0001.html>
[PATCH] drm: drm_pci: Include "drm_internal.h"
From: Fabio Estevam Include "drm_internal.h" to fix the following sparse warnings: drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static? drivers/gpu/drm/drm_pci.c:216:5: warning: symbol 'drm_irq_by_busid' was not declared. Should it be static? Signed-off-by: Fabio Estevam --- drivers/gpu/drm/drm_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index fd29f03..8985f48 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -28,6 +28,7 @@ #include #include #include "drm_legacy.h" +#include "drm_internal.h" /** * drm_pci_alloc - Allocate a PCI consistent memory block, for DMA. -- 1.9.1
[Bug 83996] [drm:r100_ring_test] *ERROR* radeon: ring test failed - since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]
https://bugs.freedesktop.org/show_bug.cgi?id=83996 Michel D?nzer changed: What|Removed |Added Attachment #106432|0 |1 is obsolete|| --- Comment #3 from Michel D?nzer --- Created attachment 106470 --> https://bugs.freedesktop.org/attachment.cgi?id=106470&action=edit Fix typo 'addr' -> 'entry' in rs400_gart_set_page Does this patch fix the problem? Please test it without Christian's patch, that one can't work correctly because it doesn't set the correct GART page flags in all cases. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/522803f0/attachment.html>
[Bug 84021] [game][the cave] not rendered properly
https://bugs.freedesktop.org/show_bug.cgi?id=84021 --- Comment #1 from smoki --- (In reply to comment #0) > The intro screen is mainly white and we hardly can see anything Works fine for me. Do you have some sort of s3tc solution available? Like: force_s3tc_enable=true ./run_game.sh -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140918/40043ee7/attachment.html>
[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
On 09/17/2014 10:41 PM, Mark Brown wrote: > On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote: >> Adds configuration option for HDMI audio support for AM33XX based >> boards with NXP TDA998x HDMI transmitter. The audio is connected to >> NXP TDA998x trough McASP running in i2s mode. > > So, Jean-Francois is also trying to do things with the TDA998x - what's > the story with that, is this joined up at all? > Not really. This basic functionality does not touch tda998x at all on the fly, but just sets i2s configuation in the beginning and bangs the bits trough McASP. But as long as the old platform data for tda998x still works after Jean-Francois' patches I should be safe. The problem with the Jean-Francois' patches is the DT support. The BBB HDMI video is implemented trough tilcdc-slave mechanism without a DT node for the tda encoder, which renders Jean-Francois' approach unusable for BBB. The whole tilcdc slave approach may not be the most elegant way to use the tda driver, but it does not look like it is going to change any time soon. Best regards, Jyri ps. I have been thinking on something similar to Jean-Francois' patch for SiI9022 which I have been working on lately. Also I have been wondering if it would be possible to come up with a generic ASoC codec component driver or library that could be used with any HDMI encoder to produce the ASoC codec component. Unfortunately I am in too early stage to produce anything more concrete.
