the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/99ea4de3/attachment-0001.html>
Hi Sergei,
On Wednesday 20 August 2014 01:18:27 Sergei Shtylyov wrote:
> On 08/20/2014 01:04 AM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > MAINTAINERS | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > Hi Dave,
> >
> > Could you please pick
Signed-off-by: Laurent Pinchart
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
Hi Dave,
Could you please pick this patch up, or let me know if you would like it to go
through a different tree ?
diff --git a/MAINTAINERS b/MAINTAINERS
index 6813d0a..375c019 100644
--- a/MAINT
On Tue, Aug 19, 2014 at 03:59:38PM +0200, Philipp Zabel wrote:
> > diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
> > b/drivers/staging/imx-drm/ipuv3-plane.c
> > index 6f393a11f44d..a79ae7731a03 100644
> > --- a/drivers/staging/imx-drm/ipuv3-plane.c
> > +++ b/drivers/staging/imx-drm/ipuv3-plan
On 08/19/2014 04:16 PM, Mark Rutland wrote:
> On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote:
>> Add machine driver support for BeagleBone-Black HDMI audio. BBB has
>> NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
>> 44100 Hz sample-rate and it's multiples can no
ound any "real" opencl use to benchmark yet - x264 would be nice, but
it seems it needs things not yet implemented.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists
* CS execution
--
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/20140819/40b63eb3/attachment.html>
On Mon, Aug 18, 2014 at 02:02:14PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be 720 horizontal pixel and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel dupl
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/20140819/0278a42a/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/c2e6b62e/attachment.html>
On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
wrote:
> On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>> wrote:
>> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> >> Register exynos_dp_panel befor
ng 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/20140819/7c025c6f/attachment.html>
is 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/20140819/bdc6fa4f/attachment.html>
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/20140819/0a6110e7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #13 from Christian Birchinger ---
The GTF one is unusable. I see a totaly desyncd image and lines are only
flickering around.
The CVT one works, altough with huge black borders. However, it still flickers
every 20-60 seconds. So longe
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #12 from Alex Deucher ---
I'm not sure what's going on. Maybe a gcc bug? Can you try a modeline with a
longer vblank period? E.g.,
xrandr --newmode 1600x1200_gtf 234.76 1600 1720 1896 2192 1200 1201 1204
1260 -HSync +Vsync
xran
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #11 from Christian Birchinger ---
Simply doing this also works:
ni_dpm.c:
bool ni_dpm_vblank_too_short(struct radeon_device *rdev)
{
struct rv7xx_power_info *pi = rv770_get_pi(rdev);
u32 vblank_time = r600_dpm_get_vblank_time(rde
shader variant (type=1) 1
--
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/20140819/39251d08/attachment.html>
achments/20140819/95c6e94c/attachment.html>
uld fix one of
your errors.
--
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/20140819/2c29eee5/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #10 from Christian Birchinger ---
I don't know why but the only way i can stop it from chaning mclk is doing
this:
si_dpm.c
/*
if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
ni_dpm_vblank_too_short(rdev))
*/
disable_mclk
This patch adds support for the HannStar Display Corp. HSD070PWW1 7.0"
WXGA TFT LCD panel to the simple-panel driver. The binding documentation
is included.
Signed-off-by: Philipp Zabel
---
.../bindings/panel/hannstar,hsd070pww1.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c
Signed-off-by: Philipp Zabel
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..23b0bee 100644
--- a/Documentati
Unbinding imx-hdmi or imx-ldb driver triggers a kernel Oops in function
ipu_dp_put() as below.
$ echo 12.hdmi >
/sys/devices/soc0/soc/200.aips-bus/12.hdmi/driver/unbind
[ 66.411700] Console: switching to colour dummy device 80x30
[ 66.432543] drm_kms_helper: drm: unregistered pani
Unbinding imx-ldb driver on imx6q-sabresd board triggers a kernel Oops
as below.
$ echo 200.aips-bus\:ldb\@020e0008 > unbind
[ 423.031003] Console: switching to colour dummy device 80x30
[ 423.052505] drm_kms_helper: drm: unregistered panic notifier
[ 423.137082] Unable to handle kernel NUL
In my testing of bind/unbind (and insmod/rmmod) on imx-drm drivers,
a couple of kernel Oops are seen. These two patches are trying to
fix them.
Shawn Guo (2):
imx-drm: imx-ldb: fix kernel Oops in imx_ldb_unbind()
imx-drm: ipuv3-plane: fix kernel Oops in ipu_dp_put()
drivers/staging/imx-drm/
On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont
wrote:
> This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
> vga_default_device() initialization to pci_vga_fixup()):
> - cleanup remaining but always-true #ifndefs
> - fix boot regression on dual-GPU Macs
>
> Andreas, can you please
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #9 from Alex Deucher ---
(In reply to Christian Birchinger from comment #7)
> Yes, that patch would indeed fix it in my case.
>
> I was pretty sure i took standard VESA modes and the fact that Windows
> Generic Monitor (no overrides o
From: "Y.C. Chen"
---
drivers/gpu/drm/ast/ast_mode.c | 27 +-
drivers/gpu/drm/ast/ast_tables.h | 42 ++--
2 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #8 from Christian Birchinger ---
I've applied your patch, booted and still see the mclk changing.
I know i'm doing something wrong but i cannot see what.
I've checke the source .. and "vblank_time <= switch_limit" is there.
Also 450
https://bugzilla.kernel.org/show_bug.cgi?id=78661
--- Comment #15 from Nikolaus Waxweiler ---
The amount of hangs has increased since 3.16 :(
--
You are receiving this mail because:
You are watching the assignee of the bug.
My Toshiba A50 with graphics adapter described by
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller [8086:0416] (rev 06) gets the following
warning on 3.17-rc1:
[ 1271.563533] [ cut here ]
[ 1271.563568] WARN
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #7 from Christian Birchinger ---
Yes, that patch would indeed fix it in my case.
I was pretty sure i took standard VESA modes and the fact that Windows Generic
Monitor (no overrides or "hacks" there) values also using the same timings
Am Dienstag, den 19.08.2014, 17:49 +0800 schrieb Shawn Guo:
> Unbinding imx-ldb driver on imx6q-sabresd board triggers a kernel Oops
> as below.
>
> $ echo 200.aips-bus\:ldb\@020e0008 > unbind
[...]
> Fix the issue by checking if the LDB channel is actually created/valid
> before calling into
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #6 from Alex Deucher ---
Since you seem to be using a custom edid, you can also adjust the modelines to
increase (to give the GPU more time to switch the mclk) or decrease (to disable
mclk switching) the vblank_time. I suspect the vbla
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #5 from Alex Deucher ---
Created attachment 147331
--> https://bugzilla.kernel.org/attachment.cgi?id=147331&action=edit
possible fix
As you can see from your log, the vblank time for the mode you've selected is
right at the mclk swi
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #4 from Christian Birchinger ---
Created attachment 147321
--> https://bugzilla.kernel.org/attachment.cgi?id=147321&action=edit
EDID info
EDID info for the monitor
The Monitor is an EIZO F930 connected over BNC (so no real EDID fro
Hi Shawn,
Am Dienstag, den 19.08.2014, 17:49 +0800 schrieb Shawn Guo:
> Unbinding imx-hdmi or imx-ldb driver triggers a kernel Oops in function
> ipu_dp_put() as below.
>
> $ echo 12.hdmi >
> /sys/devices/soc0/soc/200.aips-bus/12.hdmi/driver/unbind
[...]
> From the call stack, the is
Op 19-08-14 om 15:06 schreef Christian K?nig:
> Am 19.08.2014 um 14:22 schrieb Maarten Lankhorst:
>> This is needed for the next commit, because the lockup detection
>> will need the read lock to run.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> radeon_pm_compute_clocks already checks if dpm i
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #3 from Christian Birchinger ---
Created attachment 147311
--> https://bugzilla.kernel.org/attachment.cgi?id=147311&action=edit
Xorg log file
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=82781
--- Comment #2 from Christian Birchinger ---
Created attachment 147301
--> https://bugzilla.kernel.org/attachment.cgi?id=147301&action=edit
dmesg output
Ok i've attached the dmesg output.
Back with the 5570 i've corrected my sync timings after
HDMI currently stops working after a system suspend/resume cycle. The
cause is that the mode setting states in hardware gets lost and isn't
restored across the suspend/resume cycle.
The patch adds a very basic suspend/resume support to imx-drm driver,
and calls drm_helper_resume_force_mode() in .
https://bugzilla.kernel.org/show_bug.cgi?id=82781
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
On 08/19/2014 02:32 PM, Mark Rutland wrote:
> On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
>> The added ti,gpio-clock 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 regis
On Mon, Aug 18, 2014 at 03:11:54PM +0200, Andrzej Hajda wrote:
> On 08/18/2014 02:58 PM, Andrzej Hajda wrote:
> > .load hook is called after all components are attached to the master.
> > So if suspend happen after probe of the master and before attaching the last
> > component you will have NULL h
https://bugzilla.kernel.org/show_bug.cgi?id=82781
Bug ID: 82781
Summary: Option to disable mclk reclocking with AMD R9 280X
(TAHITI) to avoid screen flickering on VGA/CRT
Product: Drivers
Version: 2.5
Kernel Version: 3.16.1
Am 19.08.2014 um 14:22 schrieb Maarten Lankhorst:
> This is needed for the next commit, because the lockup detection
> will need the read lock to run.
>
> Signed-off-by: Maarten Lankhorst
> ---
> radeon_pm_compute_clocks already checks if dpm is enabled, so no need to
> check a second time.
>
> B
On 19.08.2014 00:02, Alex Deucher wrote:
> On Mon, Aug 18, 2014 at 10:30 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> Fixes lockups due to CP read GPUVM faults when running piglit on Cape
>> Verde.
>>
>> v2 (chk): apply the fix to R600+ as well, on CIK only the GFX CP has
>>
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 54 ---
1 file changed, 31 insertions(+), 23 deletions(-)
dif
Signed-off-by: Maarten Lankhorst
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
V2 used delayed work that ran during lockup recovery, but required
read lock. I've fixe
This is needed for the next commit, because the lockup detection
will need the read lock to run.
Signed-off-by: Maarten Lankhorst
---
radeon_pm_compute_clocks already checks if dpm is enabled, so no need to check
a second time.
Because of locking and waiting stuff the radeon_pm_compute_clocks a
From: Clint Taylor
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently
> > I'll try to follow up with a patch some time next week.
>
> And next week became 4 months later, sorry :-/
>
> Meelis, I've coded up a patch series that should take care of this
> issue, which I'll post to sparclinux with you CC:'d right now.
Tested them yesterday.
PCI ROM allocation seems
t any problems.
Basically first try to get the most simple use case working, e.g. X with just
glxgears.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.or
On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote:
> Add machine driver support for BeagleBone-Black HDMI audio. BBB has
> NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
> 44100 Hz sample-rate and it's multiples can not be accurately produced
> on BBB. The only suppo
tp://lists.freedesktop.org/archives/dri-devel/attachments/20140819/34aea302/attachment.html>
On Tue, Aug 19, 2014 at 01:23:12PM +0100, Jyri Sarha wrote:
> On 08/19/2014 02:32 PM, Mark Rutland wrote:
> > On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
> >> The added ti,gpio-clock is a basic clock that can be enabled and
> >> disabled trough a gpio output. The DT binding document
On Tue, Aug 19, 2014 at 6:32 AM, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau
Thanks Pierre, I've pulled both patches.
> ---
> drm/core/include/subdev/fb/regsnv04.h | 1 +
> nvkm/include/subdev/fb/regsnv04.h | 21 +
> nvkm/subdev/devinit/fbmem.h | 18 +
On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
> The added ti,gpio-clock 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_
On Tue, Aug 19, 2014 at 1:57 AM, Michel D?nzer wrote:
> On 19.08.2014 00:02, Alex Deucher wrote:
>> On Mon, Aug 18, 2014 at 10:30 AM, Christian K?nig
>> wrote:
>>> From: Christian K?nig
>>>
>>> Fixes lockups due to CP read GPUVM faults when running piglit on Cape
>>> Verde.
>>>
>>> v2 (chk): app
On Mon, Aug 18, 2014 at 10:25 PM, Michel D?nzer wrote:
> On 19.08.2014 06:12, Alex Deucher wrote:
>> Need to initialize the mask to 0 on init, otherwise it
>> keeps increasing.
>>
>> bug:
>> https://bugzilla.kernel.org/show_bug.cgi?id=82581
>>
>> v2: also fix cu count
>
> Might be even nicer to ke
On 19.08.2014 06:12, Alex Deucher wrote:
> Need to initialize the mask to 0 on init, otherwise it
> keeps increasing.
>
> bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=82581
>
> v2: also fix cu count
Might be even nicer to keep the two fixes separate, but either way:
Reviewed-by: Michel D?
On 08/18/2014 06:40 AM, Philipp Zabel wrote:
> From: Steve Longerbeam
>
> Adds the Camera Sensor Interface (CSI) unit required for video capture.
>
> Signed-off-by: Steve Longerbeam
>
> Removed the unused clk_get_rate in ipu_csi_init_interface and the
> ipu_csi_ccir_err_detection_enable/disable f
On Tue, Aug 19, 2014 at 04:16:41AM -0500, Greg KH wrote:
> On Tue, Aug 19, 2014 at 09:08:08AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Aug 18, 2014 at 02:25:34PM +0800, Shawn Guo wrote:
> > > On Fri, Jul 25, 2014 at 02:20:40PM +0800, Shawn Guo wrote:
> > > > HDMI currently stops working a
On 08/18/2014 06:39 AM, Philipp Zabel wrote:
> Hi,
>
> this series of patches adds IPUv3 core code in preparation for
> video capture support and cleans up the CPMEM handling a bit.
>
> The first version of this series has been sent to the
> linux-media at vger.kernel.org list. I'm sending to dri-d
but the support got removed for DMA with CIK.
VCE never could do it.
--
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/201408
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/03d5d486/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/41b2b18b/attachment.html>
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/20140819/b73e3a97/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82581
--- Comment #4 from Christoph Haag ---
OpenCL Number of compute units: 20
Works for me.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Aug 18, 2014 at 02:25:34PM +0800, Shawn Guo wrote:
> On Fri, Jul 25, 2014 at 02:20:40PM +0800, Shawn Guo wrote:
> > HDMI currently stops working after a system suspend/resume cycle. The
> > cause is that the mode setting states in hardware gets lost and isn't
> > restored across the suspen
Hi,
Did anybody get a chance to review other patches in this series?
I got r-b for 2 patches (patches with changes in drm and i915) from Damien.
Thanks,
Sonika
-Original Message-
From: Jindal, Sonika
Sent: Friday, August 8, 2014 4:24 PM
To: intel-gfx at lists.freedesktop.org
Cc: dri-dev
pectively, to see if one of them alone fixes the problem
in Valley?
--
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/2
On Tue, Aug 19, 2014 at 09:08:08AM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 18, 2014 at 02:25:34PM +0800, Shawn Guo wrote:
> > On Fri, Jul 25, 2014 at 02:20:40PM +0800, Shawn Guo wrote:
> > > HDMI currently stops working after a system suspend/resume cycle. The
> > > cause is that the
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140819/cf8d49e5/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/2f68cca7/attachment.html>
g it just in case.
--
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/20140819/cc636c42/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/e25ff424/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140819/cf9032f9/attachment.html>
lated to other GPU locks I've been experiencing with
Mesa 10.2.x, but this is the only repeatable instance of it so far.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://l
Select CONFIG_SND_EDMA_SOC=m and CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
for BBB HDMI audio.
Signed-off-by: Jyri Sarha
---
arch/arm/configs/omap2plus_defconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 9
Select CONFIG_DRM=m, CONFIG_DRM_I2C_NXP_TDA998X=m, and
CONFIG_DRM_TILCDC=m, for Beaglebone-Black HDMI video support.
Signed-off-by: Jyri Sarha
---
arch/arm/configs/omap2plus_defconfig |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/confi
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 | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boo
Add external clock provider for am33xx devices.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am33xx.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..d2cc397 100644
--- a/arch/arm/boot/dts/am33xx
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
1 file changed, 12 insertions(+)
diff
Add machine driver support for BeagleBone-Black HDMI audio. BBB has
NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
44100 Hz sample-rate and it's multiples can not be accurately produced
on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significa
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
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++-
1 file changed, 23 i
The added ti,gpio-clock 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
---
.../devicetree
Changes since v1 of the patch set:
- Move gpio-clock under drivers drivers/clk/ti/ and change compatible
string to "ti,gpio-clock" to get it accepted
- Drop already applied "ASoC: mcasp: Fix implicit BLCK divider setting"
- Fix typo from "ARM: dts: am33xx: Add external clock provider" commit
me
89 matches
Mail list logo
