On 4/4/23 00:55, Paul Cercueil wrote:
[...]
+ priv = attach->importer_priv;
+ list_del_init(&priv->entry);
+
+ iio_buffer_dmabuf_put(attach);
+ iio_buffer_dmabuf_put(attach);
+
Is this intended? Looks suspicious...
It is intended, yes. You want to release the dma_buf_at
On 11/27/21 5:05 PM, Jonathan Cameron wrote:
Non-coherent mapping with no cache sync:
- fileio:
read: 156 MiB/s
write: 123 MiB/s
- dmabuf:
read: 234 MiB/s (capped by sample rate)
write: 182 MiB/s
Non-coherent reads with no cache sync + write-combine writes:
On 11/22/21 4:16 PM, Paul Cercueil wrote:
Hi Lars,
Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars
On 11/21/21 9:08 PM, Paul Cercueil wrote:
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.
While this totally
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.
While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check eac
On 11/15/21 11:42 AM, Arnd Bergmann wrote:
On Mon, Nov 15, 2021 at 11:14 AM Lars-Peter Clausen wrote:
On 11/15/21 9:53 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
This field is never set, and serves no purpose, so remove it.
I agree that we should remove it. Its been legacy support code
On 11/15/21 9:53 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
This field is never set, and serves no purpose, so remove it.
I agree that we should remove it. Its been legacy support code for a
while, but the description that there is no user is not right.
The tegra20_spdif driver obviously
On 02/12/2018 07:11 PM, Kieran Bingham wrote:
[...]
> + /*
> + * The adv75xx resets its addresses to defaults during low power power
> + * mode. Because we have two ADV7513 devices on the same bus, we must
> + * change both of them away from the defaults so that they do not
> +
On 01/22/2018 01:50 PM, Kieran Bingham wrote:
> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
>
> Allow a device tree node to override the default addresses so that
> address c
after the EDID check handle the case where
the EDID is NULL just fine and exhibit the expected behavior, so just drop
the check.
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511
The HDMI codec platform data is global driver state shared by all
instances. As such it should not be modified (and is not), to make this
explicit declare it as const.
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 +-
1 file changed, 1 insertion(+), 1
-Peter Clausen
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 --
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 16 ++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index
Fall back to polling the connector for connect and disconnect events when
no interrupt is specified. Otherwise these events will not be noticed and
monitor hotplug does not work.
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
1 file changed, 5
On 09/07/2016 01:22 AM, John Stultz wrote:
> This patch adds support to Audio for both adv7511 and adv7533
> bridge chips.
>
> This patch was originally from [1] by Lars-Peter Clausen
> and was adapted by Archit Taneja and
> Srinivas Kandagatla .
>
> Then I heavily rew
On 04/11/2016 04:08 PM, Jose Abreu wrote:
[...]
>> Currently there is also zero support of of-graph in ASoC, so a bit of work
>> is required to get this integrated properly.
>>
>
> I also believe this would be the better option but in the meantime can't I
> integrate the audio like it is being don
On 04/11/2016 01:32 PM, Jose Abreu wrote:
> Hi Lars,
>
>
> On 11-04-2016 10:33, Lars-Peter Clausen wrote:
>> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>>> Hi Lars,
>>>
>>>
>>> On 09-04-2016 16:02, Lars-Peter Clause
On 04/11/2016 11:27 AM, Jose Abreu wrote:
> Hi Lars,
>
>
> On 09-04-2016 16:02, Lars-Peter Clausen wrote:
>> On 04/08/2016 06:12 PM, Jose Abreu wrote:
>> [...]
>>>> [...]
>>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec
On 04/08/2016 06:12 PM, Jose Abreu wrote:
[...]
>>
>> [...]
>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec
>>> interface
>>> + into ALSA SoC.
>> This is not a description of the hardware.
>
> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
> trans
On 04/08/2016 06:08 PM, Jose Abreu wrote:
> Hi Lars,
>
>
> On 08-04-2016 16:52, Lars-Peter Clausen wrote:
>> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>>> Hi Mark,
>>>
>>>
>>> On 07-04-2016 18:53, Mark Brown wrote:
>>&
On 04/08/2016 12:06 PM, Jose Abreu wrote:
> Hi Mark,
>
>
> On 07-04-2016 18:53, Mark Brown wrote:
>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>>
>>> + Optional properties:
>>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
>>> + it is required to u
On 04/07/2016 06:53 PM, Jose Abreu wrote:
> This patch adds audio support for the ADV7511 HDMI transmitter
> using ALSA SoC.
>
> The code was ported from Analog Devices linux tree from
> commit 1770c4a1e32b ("Merge remote-tracking branch
> 'xilinx/master' into xcomm_zynq"), which is available at:
On 02/04/2016 04:22 PM, Carlos Palminha wrote:
> Hi guys,
>
> any feedback? patch will be accepted for adv7511 driver?
Hi,
Thanks for the patch, but please try to find and fix the call site that is
trying to invoke the callback even though it does not exist.
This is most likely drm_i2c_encoder_
On 01/04/2016 03:33 AM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Fix this typo, consequently used over both files :)
>
> Signed-off-by: Wolfram Sang
Acked-by: Lars-Peter Clausen
Thanks.
On 11/25/2015 09:27 AM, Wolfram Sang wrote:
>
>> I guess you mean that the GPIO callbacks include Runtime PM handling
>> however for irq_chip Runtime PM may not be hooked up so the GPIO block
>> is in such case is not powered on / get clock enabled?
>
> Yes. There is another drawback when GPIOs a
On 10/16/2015 01:50 PM, Jyri Sarha wrote:
> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> audio was not discussed after all.
It was discussed, but rather shortly and only in the context of the HDA.
(Adding Vinod to Cc, who presented yet another approach to the problem las
Added Hans, who's working a lot on the HDMI transmitter drivers (including
audio support) as well as the media list to Cc.
On 10/07/2015 10:19 AM, Arnaud Pouliquen wrote:
>
>
>>> My approach is the reverse: DRM driver does not need to know anything
>>> about audio side. As ALSA is the client of
> @@ -134,6 +136,7 @@ config DRM_AMDGPU
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> + select DRM_AMD_GNB_BUS
Here you select the symbol.
[...]
> +config DRM_AMD_GNB_BUS
> + tristate "AMD GNB bus - used for GNB IPs such as ACP and ISP"
Here y
>
> Fix this by ignoring hot plug detection IRQs when no encoder is
> associated yet.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Lars-Peter Clausen
> ---
> drivers/gpu/drm/i2c/adv7511.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/d
On 05/07/2015 12:41 PM, Russell King - ARM Linux wrote:
[...]
>>> What I'm concerned about is that when the ALSA parameter refining
>>> starts, we start with (eg) 2-8 channels, 32-192kHz. Given that,
>>> if we invoke the channel restriction before the rate restriction,
>>> we would end up limiting
latest right before reading EDID data.
>
> Signed-off-by: Laurent Pinchart
Tested-by: Lars-Peter Clausen
Acked-by: Lars-Peter Clausen
Thanks.
On 12/15/2014 03:55 AM, Yakir Yang wrote:
[...]
> +- codec-name: the dw-hdmi codec's device name
> +- codec-dai-name: the dw-hdmi codec's dai name
Please you phandles for this, the names are Linux driver and framework
specific details. That should not leak into the DT bindings.
[..]
On 11/24/2014 09:01 PM, Dave Airlie wrote:
> On 25 November 2014 at 00:18, Lars-Peter Clausen wrote:
>> On 11/24/2014 03:00 PM, Laurent Pinchart wrote:
>>>
>>> Hi Daniel,
>>>
>>> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussi
On 11/24/2014 03:00 PM, Laurent Pinchart wrote:
> Hi Daniel,
>
> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm:
> Decouple EDID parsing from I2C adapter" patch available at
> git://linuxtv.org/pinchartl/fbdev.git drm/next/du)
>
> On Monday 24 November 2014 14:09:39 Danie
On 07/28/2014 06:17 PM, Andreas F?rber wrote:
> Hi Lars-Peter,
>
> Am 25.07.2014 01:00, schrieb Andreas F?rber:
>> most notably I'm missing
>> ADI ADV7513 and AXI-HDMI support
> [...]
>> Cc: Lars-Peter Clausen (HDMI)
>
> Could you please enlighten us
On 02/05/2014 07:07 PM, Jean-Francois Moine wrote:
> On Wed, 05 Feb 2014 10:19:22 +0100
> Lars-Peter Clausen wrote:
>
>>> So, in the CODEC, I don't see how I could update the parameters
>>> dictated by the EDID otherwise in changing the DAI driver parameters.
>&
On 02/05/2014 12:18 PM, Mark Brown wrote:
> On Wed, Feb 05, 2014 at 10:19:22AM +0100, Lars-Peter Clausen wrote:
[..]
>> Bonus points for making this a generic helper function that takes a
>> runtime and a EDID and then applies the EDID constraints on the
>> runtime.
>
>
On 02/05/2014 10:11 AM, Jean-Francois Moine wrote:
> On Tue, 4 Feb 2014 18:06:25 +
> Mark Brown wrote:
>
>> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
>>
>>> + /* change the snd_soc_pcm_stream values of the driver */
>>> + stream->rates = rate_mask
On 02/04/2014 02:30 PM, Mark Brown wrote:
[...]
>
> What does this actually do? No information is being passed in to the
> core function here, not even any information on if it's starting or
> stopping. Looking at the rest of the code I can't help thinking it
> might be clearer to inline this pos
On 01/27/2014 08:40 PM, Jyri Sarha wrote:
> On 01/27/2014 06:32 PM, Lars-Peter Clausen wrote:
>> On 01/27/2014 05:17 PM, Jyri Sarha wrote:
>>> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>>>> Hi,
>>>>
>>>> I think you should
On 01/27/2014 05:17 PM, Jyri Sarha wrote:
> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>> Hi,
>>
>> I think you should try to get this in sync with the work Jean-Francois is
>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>&
Hi,
I think you should try to get this in sync with the work Jean-Francois is
currently doing[1]. Having the HDMI transmitter register a CODEC device is
definitely the right approach, compared to the rather 'interesting'
constraints stuff you do in patch 4.
- Lars
[1] http://lkml.org/lkml/2014/1
removes the 'driver' field from the
i2c_client struct.
Signed-off-by: Lars-Peter Clausen
---
drivers/i2c/i2c-core.c | 21 -
drivers/i2c/i2c-smbus.c | 10 ++
include/linux/i2c.h | 2 --
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Check i2c_client->dev.driver instead to see if a driver is bound to the
device.
Signed-off-by: Lars-Peter Clausen
---
sound/soc/fsl/imx-wm8962.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct
access to the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen
---
sound/ppc/keywest.c | 4 ++--
1 file changed, 2 ins
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct access to
the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen
Cc: Martin Peres
---
drivers/gpu/drm/nouveau/core/subde
get direct access to the i2c_driver struct use
'to_i2c_driver(client->dev.driver)'.
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/drm_encoder_slave.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gp
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the lat
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the lat
nd of course also the runtime memory footprint of the
i2c_client struct is reduced.
- Lars
Lars-Peter Clausen (8):
[media] s5c73m3: Don't use i2c_client->driver
[media] exynos4-is: Don't use i2c_client->driver
[media] core: Don't use i2c_client->driver
drm: encoder_slav
[...]
>> +
>> +/**
>> + * enum adv7511_input_color_depth - Selects the input format color depth
>> + * @ADV7511_INPUT_COLOR_DEPTH_8BIT: Input format color depth is 8 bits per
> channel
>> + * @ADV7511_INPUT_COLOR_DEPTH_10BIT: Input format color dpeth is 10 bits
> per channel
>> + * @ADV7511_INPUT
)
@@
position p != r2.p;
@@
*free_irq at p(...)
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bbfc384..7e99853 100644
)
@@
position p != r2.p;
@@
*free_irq@p(...)
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bbfc384..7e99853 100644
--- a
On 01/31/2013 11:53 AM, Laurent Pinchart wrote:
> On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the
On 01/31/2013 11:53 AM, Laurent Pinchart wrote:
> On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the
On 12/06/2012 08:28 AM, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote:
>> On 12/05/2012 05:45 PM, Thierry Reding wrote:
>>> Add a generic helper to fill in an HDMI AVI infoframe with data
>>> extracted from a DRM display mod
On 12/06/2012 08:28 AM, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote:
>> On 12/05/2012 05:45 PM, Thierry Reding wrote:
>>> Add a generic helper to fill in an HDMI AVI infoframe with data
>>> extracted from a DRM display mod
On 12/05/2012 05:45 PM, Thierry Reding wrote:
> Add a generic helper to fill in an HDMI AVI infoframe with data
> extracted from a DRM display mode.
That's a very nice patch series, comes in pretty handy. Thanks :)
I've just one comment.
> [...]
> +static inline enum hdmi_picture_aspect
> +drm_d
On 12/05/2012 05:45 PM, Thierry Reding wrote:
> Add a generic helper to fill in an HDMI AVI infoframe with data
> extracted from a DRM display mode.
That's a very nice patch series, comes in pretty handy. Thanks :)
I've just one comment.
> [...]
> +static inline enum hdmi_picture_aspect
> +drm_d
On 09/15/2012 01:28 AM, Dave Airlie wrote:
> On Fri, Sep 14, 2012 at 10:38 PM, Laurent Pinchart
> wrote:
>> Hi Dave,
>>
>> The SH Mobile DRM driver is now (in my opinion) ready for mainline. It
>> requires GEM and KMS/FB helpers that have been reviewed on the list and
>> tested. Sascha is waiting
On 09/15/2012 01:28 AM, Dave Airlie wrote:
> On Fri, Sep 14, 2012 at 10:38 PM, Laurent Pinchart
> wrote:
>> Hi Dave,
>>
>> The SH Mobile DRM driver is now (in my opinion) ready for mainline. It
>> requires GEM and KMS/FB helpers that have been reviewed on the list and
>> tested. Sascha is waiting
args->width * args->bpp, 8) to calculate the pitch
>> - make drm_gem_cma_vm_ops const
>> - add missing #include
>> changes since v1:
>> - map whole buffer at mmap time, not page by page at fault time
>> - several cleanups as suggested by Lars-Peter Clau
args->width * args->bpp, 8) to calculate the pitch
>> - make drm_gem_cma_vm_ops const
>> - add missing #include
>> changes since v1:
>> - map whole buffer at mmap time, not page by page at fault time
>> - several cleanups as suggested by Lars-Peter Clau
On 07/20/2012 01:44 PM, RAHUL SHARMA wrote:
>
> On Fri, Jul 20, 2012 at 11:40 AM, RAHUL SHARMA
> wrote:
>>
>>
>> --- Original Message -------
>> Sender : Lars-Peter Clausen
>> Date : Jul 19, 2012 19:12 (GMT+05:30)
>> Title : Re: exynos drm hd
On 07/20/2012 01:44 PM, RAHUL SHARMA wrote:
>
> On Fri, Jul 20, 2012 at 11:40 AM, RAHUL SHARMA
> wrote:
>>
>>
>> --- Original Message -------
>> Sender : Lars-Peter Clausen
>> Date : Jul 19, 2012 19:12 (GMT+05:30)
>> Title : Re: exynos drm hd
On 07/19/2012 05:46 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 17:12:28 Lars-Peter Clausen wrote:
>> On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
>>> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>>>> On Thursday 19 July
On 07/19/2012 05:01 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 16:57:15 Lars-Peter Clausen wrote:
>> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>>> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>>>> On Thursday 19 J
On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>>> On Thursday 19 July 2012 15:55:56 Lars-Peter Clausen wrote:
>>>> On 07/19/2012 03:33 PM, Laurent Pincha
On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
> And well something similar for horizontal subsampling.
s/horizontal/vertical/
On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>> On Thursday 19 July 2012 15:55:56 Lars-Peter Clausen wrote:
>>> On 07/19/2012 03:33 PM, Laurent Pinchart wrote:
>>>> On Thursday 19 July 2012 15:34:26 Lars
On 07/19/2012 03:33 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 15:34:26 Lars-Peter Clausen wrote:
>> On 07/19/2012 02:46 PM, Laurent Pinchart wrote:
>>> On Monday 02 July 2012 16:37:47 Lars-Peter Clausen wrote:
>>>> This patchset int
On 07/19/2012 02:22 PM, Rob Clark wrote:
> On Tue, Jul 17, 2012 at 1:12 AM, RAHUL SHARMA
> wrote:
>> hi,
>>
>> I am adding support for hdmi audio, inside exynos drm hdmi driver. Hdmi
>> audio is initialized with default parameters. I want to implement the
>> mechanism to update hdmi registers,
On 07/19/2012 02:46 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> Thank you for the patch.
>
> On Monday 02 July 2012 16:37:47 Lars-Peter Clausen wrote:
>> This patchset introduces a set of helper function for implementing the KMS
>> framebuffer layer for drivers which
On 07/19/2012 05:46 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 17:12:28 Lars-Peter Clausen wrote:
>> On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
>>> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>>>> On Thursday 19 July
On 07/19/2012 05:01 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 16:57:15 Lars-Peter Clausen wrote:
>> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>>> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>>>> On Thursday 19 J
On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>>> On Thursday 19 July 2012 15:55:56 Lars-Peter Clausen wrote:
>>>> On 07/19/2012 03:33 PM, Laurent Pincha
On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
> And well something similar for horizontal subsampling.
s/horizontal/vertical/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>> On Thursday 19 July 2012 15:55:56 Lars-Peter Clausen wrote:
>>> On 07/19/2012 03:33 PM, Laurent Pinchart wrote:
>>>> On Thursday 19 July 2012 15:34:26 Lars
On 07/19/2012 03:33 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> On Thursday 19 July 2012 15:34:26 Lars-Peter Clausen wrote:
>> On 07/19/2012 02:46 PM, Laurent Pinchart wrote:
>>> On Monday 02 July 2012 16:37:47 Lars-Peter Clausen wrote:
>>>> This patchset int
On 07/19/2012 02:22 PM, Rob Clark wrote:
> On Tue, Jul 17, 2012 at 1:12 AM, RAHUL SHARMA
> wrote:
>> hi,
>>
>> I am adding support for hdmi audio, inside exynos drm hdmi driver. Hdmi
>> audio is initialized with default parameters. I want to implement the
>> mechanism to update hdmi registers,
On 07/19/2012 02:46 PM, Laurent Pinchart wrote:
> Hi Lars,
>
> Thank you for the patch.
>
> On Monday 02 July 2012 16:37:47 Lars-Peter Clausen wrote:
>> This patchset introduces a set of helper function for implementing the KMS
>> framebuffer layer for drivers which
de. The code technically does
> not depend on CMA as the backend allocator, the name has been chosen
> because cma makes for a nice, short but still descriptive function
> prefix.
>
> Signed-off-by: Sascha Hauer
Tested-by: Lars-Peter Clausen
... for quite some time now.
There are n
de. The code technically does
> not depend on CMA as the backend allocator, the name has been chosen
> because cma makes for a nice, short but still descriptive function
> prefix.
>
> Signed-off-by: Sascha Hauer
Tested-by: Lars-Peter Clausen
... for quite some time now.
There are n
This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Note: This patch depends on Sascha's "DRM: add drm gem CMA helper" patch
Changes since v2:
This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Note: This patch depends on Sascha's "DRM: add drm gem CMA helper" patch
Changes since v2:
On 06/27/2012 10:27 PM, Laurent Pinchart wrote:
> Hi Lars-Peter,
>
> On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote:
>> On 06/27/2012 02:40 PM, Laurent Pinchart wrote:
>>> Hi Lars-Peter,
>>>
>>> [...]
>>>
>>> Do you plan to
On 06/27/2012 02:40 PM, Laurent Pinchart wrote:
> Hi Lars-Peter,
>
> [...]
>
> Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in
> the
> near future ?
Hi Laurent,
I don't think there have been any changes since v2 except for adjusting to the
renamed functions in Sasch
On 06/27/2012 10:27 PM, Laurent Pinchart wrote:
> Hi Lars-Peter,
>
> On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote:
>> On 06/27/2012 02:40 PM, Laurent Pinchart wrote:
>>> Hi Lars-Peter,
>>>
>>> [...]
>>>
>>> Do you plan to
On 06/27/2012 02:40 PM, Laurent Pinchart wrote:
> Hi Lars-Peter,
>
> [...]
>
> Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in
> the
> near future ?
Hi Laurent,
I don't think there have been any changes since v2 except for adjusting to the
renamed functions in Sasch
On 05/31/2012 10:08 AM, Sascha Hauer wrote:
> [...]
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
> new file mode 100644
> index 000..d8c0dc7
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -0,0 +1,243 @@
> +/*
> + * drm gem cma (co
On 05/31/2012 08:11 PM, Sascha Hauer wrote:
> On Thu, May 31, 2012 at 11:34:37AM +0200, Lars-Peter Clausen wrote:
>>>> + drm_helper_mode_fill_fb_struct(&fb_cma->fb, mode_cmd);
>>>> +
>>>> + for (i = 0; i < num_planes; i++)
>>>>
On 05/31/2012 10:08 AM, Sascha Hauer wrote:
> [...]
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
> new file mode 100644
> index 000..d8c0dc7
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -0,0 +1,243 @@
> +/*
> + * drm gem cma (co
On 05/31/2012 08:11 PM, Sascha Hauer wrote:
> On Thu, May 31, 2012 at 11:34:37AM +0200, Lars-Peter Clausen wrote:
>>>> + drm_helper_mode_fill_fb_struct(&fb_cma->fb, mode_cmd);
>>>> +
>>>> + for (i = 0; i < num_planes; i++)
>>>>
On 05/31/2012 10:13 AM, Sascha Hauer wrote:
> On Wed, May 30, 2012 at 05:30:15PM +0200, Lars-Peter Clausen wrote:
>> This patch introduces a set of helper function for implementing the KMS
>> framebuffer layer for drivers which use the drm gem CMA helper function.
>>
>>
On 05/31/2012 10:13 AM, Sascha Hauer wrote:
> On Wed, May 30, 2012 at 05:30:15PM +0200, Lars-Peter Clausen wrote:
>> This patch introduces a set of helper function for implementing the KMS
>> framebuffer layer for drivers which use the drm gem CMA helper function.
>>
>>
This patch introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Changes since v1:
* Some spelling fixes
* Add missing kfree in drm_fb_cma_alloc error path
On 05/30/2012 04:45 PM, Lars-Peter Clausen wrote:
> On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
>> [...]
>> +for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
>> +obj = drm_gem_object_lookup(dev, file_priv,
>> +
On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
> [...]
> + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> + obj = drm_gem_object_lookup(dev, file_priv,
> + mode_cmd->handles[i]);
> + if (obj == NULL) {
> + dev
On 05/30/2012 03:43 PM, Sascha Hauer wrote:
> Hi Laurent,
>
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
>> The SH Mobile LCD controller (LCDC) DRM driver supports the main
>> graphics plane in RGB and YUV formats, as well as the overlay planes (in
>> alpha-blending mode onl
1 - 100 of 134 matches
Mail list logo
