On Mon, 2013-11-18 at 15:38 +0100, Marek Ol??k wrote:
> From: Michel D?nzer
>
> Signed-off-by: Marek Ol??k
Reviewed-and-Tested-by: Michel D?nzer
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X develop
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/da64d77b/attachment.html>
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/20131119/97055fa0/attachment.html>
s.
--
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/20131119/3a1cc7d8/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/7ec2a30b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/647b7798/attachment.html>
Update the defines to match the kernel drm_mode.h
Signed-off-by: Thomas Hellstrom
---
xf86drmMode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 7fc52b6..9bcb1d1 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -128,6 +128,8 @@ extern "C" {
#defi
; >> Not sure about strictly tying it to kernel releases would be ideal.
> > > >> Not *everything* in libdrm is about new kernel APIs. It tends to be
> > > >> the place for things needed both by xorg ddx and mesa driver, which I
> > > >> suppose is why it ends up a bit of a free-for-all.
> > > >
> > > > I didn't mean that every release would need to be tied to the Linux
> > > > kernel. But whenever a new Linux kernel release was made, relevant
> > > > changes from the public headers could be pulled into libdrm and a
> > > > release be made. I could even imagine a matching of version numbers.
> > > > libdrm releases could be numbered using the same major and minor as
> > > > Linux kernels that they support. Micro version numbers could be used
> > > > in intermediate releases.
> > >
> > > maybe an update-kernel-headers.sh script to grab the headers from
> > > drm-next and update libdrm wouldn't be a bad idea?
> >
> > Perhaps. But I think it could even be a manual step. It's not something
> > that one person should be doing alone, but rather something that driver
> > maintainers should be doing, since they know best what will be needed
> > in a new version of libdrm.
> >
> > Like I mentioned in another subthread, I think a subtree-oriented model
> > could work well.
> >
> > Thierry
>
> Please stop asking for more process bureaucracy. libdrm development model
> works fine. Everyone is free to commit and release when needed. The recent
> hickup is just that a hickup and does not warrant any changes.
It didn't sound like everything was fine. From the above, the same has
happened before. Also more process doesn't necessarily mean more
bureaucracy. It helps with coordinating work and avoid stepping on each
other's toes. That's not something I consider bad or unnecessary
overhead.
That said, I don't have a particular problem with how libdrm is
developed. I wasn't asking for anything. It seemed like people weren't
happy with the way things are working right now and a discussion about
possible ways to remedy the situation ensued. I don't consider any of
those proposals to make things more difficult in any significant way,
just perhaps more structured and organized.
Now if everybody is indeed fine with the way things work then there's no
point in this discussion and I'll just shut up.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/9ff12076/attachment.pgp>
able length.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/28ace7aa/attachment.pgp>
/dri-devel/attachments/20131119/f3ced5b6/attachment.html>
Always use "void *" for arbitrary memory buffers, as this allows to drop
casts in assignments.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_edid_load.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load
vel/attachments/20131119/f2c68b42/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/9b614197/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=53471
--- Comment #4 from Alex Deucher ---
It's more likely due to ongoing development in the userspace drivers than the
kernel.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Nov 19, 2013 at 1:52 AM, Thomas Hellstrom
wrote:
> Update the defines to match the kernel drm_mode.h
>
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Alex Deucher
> ---
> xf86drmMode.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/8a995b75/attachment.html>
.org/archives/dri-devel/attachments/20131119/d677508a/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/9b9629c8/attachment.html>
Having patches on a mailing list is good enough, but generally if
people *trust* you that you will have an open userspace, that's good
enough too if you have people's trust.
In my opinion, the required kernel code must land in Linus's tree
first. If it's not there, it's like it didn't exist at all
For merging the patches for new hardware and/or features I agree on the
process of merging things bottom up. (e.g kernel first, then libdrm,
mesa last). But to give reasons for the merge into Linus tree it's
usually better to have a "big picture" you can validate the code against.
So I think th
Le 19/11/2013 16:04, Christian K?nig a ?crit :
> So I think the very first step should be to publish everything on the
> appropriate lists, and not try an approach like releasing the kernel
> code first and waiting for it to show up upstream and then try to
> release the userspace code build on
k seems unaffected.
--
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/20131119/90c9a759/attachment.html>
On 11/19/2013 02:34 PM, Alex Deucher wrote:
> On Tue, Nov 19, 2013 at 1:52 AM, Thomas Hellstrom
> wrote:
>> Update the defines to match the kernel drm_mode.h
>>
>> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Alex Deucher
>
>
Thanks for reviewing. Pushed.
/Thomas
https://bugzilla.kernel.org/show_bug.cgi?id=51581
Alan changed:
What|Removed |Added
Kernel Version|3.7.0 |3.8
--
You are receiving this mail because:
You a
https://bugzilla.kernel.org/show_bug.cgi?id=50881
Alan changed:
What|Removed |Added
Summary|Error compiling nouveau |[TRIVIAL]Error compiling
|inside
e the udev code actually dropped instead of #if 0ed.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/0a0cffc7/attachment.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=50091
Alan changed:
What|Removed |Added
Kernel Version|3.7.0-rc4 |3.9.9
--
You are receiving this mail because:
You
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/2939f32d/attachment.pgp>
r system someday?
I hate build options.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/76464694/attachment.pgp>
ease say so :)
--
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/20131119/26b967b9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/97313571/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/0ccede20/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/91c06a0f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/98ec1701/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=49121
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=49121
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=47801
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=47351
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=46931
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=46711
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=46471
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=46231
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=46161
Alan changed:
What|Removed |Added
Summary|divide error on radeon |[BISECTED]divide error on
|modpr
https://bugzilla.kernel.org/show_bug.cgi?id=45121
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Summary|Not
Signed-off-by: Jyri Sarha
---
Documentation/devicetree/bindings/sound/hdmi.txt | 17 +
sound/soc/codecs/hdmi.c | 10 ++
2 files changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
diff --git a/Documen
Hi Mark,
I have uploaded patch set 5 and 6 back to back, but unfortunately
still nr-configs is stuck in the example explanation in the
exynos_hdmi.txt, just to inform you that am waiting for your review
comments so that i can rectify it along with them in the next patch
set.
Regards,
Shirish S
On
sktop.org/archives/dri-devel/attachments/20131119/9ced3eda/attachment-0001.pgp>
The new playback format is needed for tda998x HDMI audio support. At
the moment the only other user of this codec is omap-hdmi-audio. This
change should not break anything because omap-hdmi-audio-dai, the
cpu-dai of omap-hdmi-audio, enforces sufficient constraints to
available sample formats.
Sign
Hi,
On Sat, Nov 16, 2013 at 12:29 AM, Adam Jackson wrote:
> On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
>> The current solution checks for the existing RB mode,
>> if available in the edid block returns by adding it,
>> but does not populate the connector with the modes
>> of same resolut
The referenced clock is used to get codec clock rate and the clock is
disabled and enabled in startup and shutdown snd_soc_ops call
backs. The change is also documented in DT bindigs document.
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-evm-audio.txt |9 ++-
sound/soc/
The configuration is needed for HDMI audio. The "swap" and "mirr"
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha
cc: airlied at linux.ie
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++
This enables HDMI video support on Beaglebone-Black.
Signed-off-by: Jyri Sarha
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 254cf05..52
Dear Jyri Sarha,
On Tue, 19 Nov 2013 14:12:23 +0200, Jyri Sarha wrote:
> -- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
> +- compatible : "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx
> + "ti,am33xx-beaglebone-black" : for Beaglebone-black HDMI audio
T
This set of patches implements PCM HDMI audio driver for
Beaglebone-Black HDMI output. The patches have been rebased
on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound topic/davinci
There is couple of earlier RFC versions of the clk patch floating
around, but the one here is th
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha
cc: mturquette at linaro
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.
Signed-off-by: Jyri Sarha
---
sound/soc/davinci/Kconfig | 12
sound/soc/davinci/Makefile |1 +
2
The associated code changes can be found here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-November/068920.html
Jyri Sarha (1):
ARM/dts: am335x-boneblack: Add HDMI audio support
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 ins
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boo
Hi Jyri,
A side question related to audio cape support on BBB. In the "official"
3.8.13 CircuitCo version the HDMI audio support was breaking the
audio-cape support due to some bad hacks in the mcasp driver.
Is this still the case with you series?
Thanks,
Benoit
On 19/11/2013 13:21, Jyri Sar
vel/attachments/20131119/3c108448/attachment-0001.pgp>
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/25594087/attachment-0001.pgp>
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
be supported on Beaglebone-Black because of limited clock-rate
support. The only supported s
Select following:
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
Signed-off-by: Jyri Sarha
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_def
On 11/19/2013 03:02 PM, Benoit Cousson wrote:
> A side question related to audio cape support on BBB. In the "official"
> 3.8.13 CircuitCo version the HDMI audio support was breaking the
> audio-cape support due to some bad hacks in the mcasp driver.
>
> Is this still the case with you series?
My
64 matches
Mail list logo
