* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 12:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On 12/04/14 09:53, Alexander Shiyan wrote:
> This adds support for the framebuffer available in the Cirrus
> Logic CLPS711X CPUs.
> FB features:
> - 1-2-4 bits per pixel.
> - Programmable panel size to a maximum of 1024x256 at 4 bps.
> - Relocatible Frame Buffer (SRAM or SDRAM).
> - Programmable refresh rates.
> - 16 gray scale values.
> This new driver supports usage with devicetree and as a general
> change it removes last user of <mach/hardware.h> for CLPS711X targets,
> so this subarch will fully prepared to switch to multiplatform.
> The driver have been tested with custom board equipped Cirrus Logic
> EP7312 in DT and non-DT mode.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/fbdev/clps711x-fb.c | 456 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 456 insertions(+)
> create mode 100644 drivers/video/fbdev/clps711x-fb.c
<snip>
> +
> +static int clps711x_fb_get_mode_dt(struct platform_device *pdev)
> +{
> + struct device_node *disp, *np = pdev->dev.of_node;
> + struct fb_info *info = platform_get_drvdata(pdev);
> + struct clps711x_fb_info *cfb = info->par;
> + int ret;
> +
> + cfb->syscon =
> + syscon_regmap_lookup_by_compatible("cirrus,clps711x-syscon1");
> + if (IS_ERR(cfb->syscon))
> + return PTR_ERR(cfb->syscon);
Hmm, what's the syscon stuff about? Looks like it's required, but the DT
documentation patch doesn't mention it at all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 12:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]
On 18/05/14 15:01, Alexander Shiyan wrote:
> Fri, 16 May 2014 15:56:26 -0700 от Olof Johansson <olof@lixom.net>:
>> On Thu, May 08, 2014 at 01:14:40PM +0300, Tomi Valkeinen wrote:
>>> On 08/05/14 11:27, Alexander Shiyan wrote:
>>>
>>>>>> At this time the driver has three user.
>>>>>> Only one of them should theoretically work.
>>>>>> clps711x-autcpu12 should not work in the absence of memblock_reserve().
>>>>>> clps711x-p720t should not work due to physical address limitation as i
>>>>>> noticed before. Board means to use SRAM instead of SDRAM.
>>>>>> Only clps711x-edb7211 should work fine (in theory).
>>>>>> Is this a good reason to replace the driver? I think yes.
>>>>>
>>>>> Ok, if the situation is that bad, maybe we can just switch to the new
>>>>> driver. Have you verified that those boards do not work from anyone? Or
>>>>> asked someone to test the new driver with those boards?
>>>>
>>>> I'm not familiar with other users of this platform .
>>>> I am do not have these boards, all that I have written before that it's just a theory.
>>>> Firm in which I work, uses its own board with CLPS711X CPU , this board is the
>>>> only way to check for changes on real hardware .
>>>
>>> Ok. That makes me a bit nervous... You're removing a driver, which may
>>> (or may not) have been working for other users. And adding a new one,
>>> which may not (or may) work for the other users.
>>
>> Keep the old one around under another Kconfig name, mark it BROKEN,
>> and if nobody speaks up in a couple of releases, remove it?
>
> I like this variant, Tomi are you agree with this?
I don't know. All options sound somewhat bad to me, except if it's clear
nobody uses the old driver.
Anyway, it's rather late for 3.16. I'd like the removal of the old
driver to sit in the linux-next for a while.
Would it be possible to add the new driver along the old driver, and use
the new driver only for the boards you have, and for boards for which
it's clear the the old driver is not working? This could be merged for 3.16.
It's not so nice to have two drivers for the same hardware, but in this
case maybe that's not an issue. The old driver doesn't support DT, so no
conflicts there, and for non-DT the driver names seem to be different.
For 3.17, we could remove the old driver, and push that change to
linux-next right after the 3.16 merge window has closed.
Or, if you're fine with it, we can also delay adding the new driver to
3.17, and do both right after the 3.16 merge window has closed. I
personally like this most, so that we have both removal of the old and
adding the new sitting in the linux-next longer, but you might possibly
want the new driver in sooner.
Maybe I'm being overly cautious here, but as I don't have any idea about
the driver and its users, I rather be too cautious than not.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 13:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNTo0Mzo0MCArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDE4LzA1LzE0IDE1OjAxLCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+ID4gRnJpLCAxNiBNYXkgMjAxNCAxNTo1NjoyNiAtMDcwMCDQvtGCIE9sb2YgSm9o
YW5zc29uIDxvbG9mQGxpeG9tLm5ldD46Cj4gPj4gT24gVGh1LCBNYXkgMDgsIDIwMTQgYXQgMDE6
MTQ6NDBQTSArMDMwMCwgVG9taSBWYWxrZWluZW4gd3JvdGU6Cj4gPj4+IE9uIDA4LzA1LzE0IDEx
OjI3LCBBbGV4YW5kZXIgU2hpeWFuIHdyb3RlOgo+ID4+Pgo+ID4+Pj4+PiBBdCB0aGlzIHRpbWUg
dGhlIGRyaXZlciBoYXMgdGhyZWUgdXNlci4KPiA+Pj4+Pj4gT25seSBvbmUgb2YgdGhlbSBzaG91
bGQgdGhlb3JldGljYWxseSB3b3JrLgo+ID4+Pj4+PiBjbHBzNzExeC1hdXRjcHUxMiBzaG91bGQg
bm90IHdvcmsgaW4gdGhlIGFic2VuY2Ugb2YgbWVtYmxvY2tfcmVzZXJ2ZSgpLgo+ID4+Pj4+PiBj
bHBzNzExeC1wNzIwdCBzaG91bGQgbm90IHdvcmsgZHVlIHRvIHBoeXNpY2FsIGFkZHJlc3MgbGlt
aXRhdGlvbiBhcyBpCj4gPj4+Pj4+IG5vdGljZWQgYmVmb3JlLiBCb2FyZCBtZWFucyB0byB1c2Ug
U1JBTSBpbnN0ZWFkIG9mIFNEUkFNLgo+ID4+Pj4+PiBPbmx5IGNscHM3MTF4LWVkYjcyMTEgc2hv
dWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5KS4KPiA+Pj4+Pj4gSXMgdGhpcyBhIGdvb2QgcmVhc29u
IHRvIHJlcGxhY2UgdGhlIGRyaXZlcj8gSSB0aGluayB5ZXMuCj4gPj4+Pj4KPiA+Pj4+PiBPaywg
aWYgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IGJhZCwgbWF5YmUgd2UgY2FuIGp1c3Qgc3dpdGNoIHRv
IHRoZSBuZXcKPiA+Pj4+PiBkcml2ZXIuIEhhdmUgeW91IHZlcmlmaWVkIHRoYXQgdGhvc2UgYm9h
cmRzIGRvIG5vdCB3b3JrIGZyb20gYW55b25lPyBPcgo+ID4+Pj4+IGFza2VkIHNvbWVvbmUgdG8g
dGVzdCB0aGUgbmV3IGRyaXZlciB3aXRoIHRob3NlIGJvYXJkcz8KPiA+Pj4+Cj4gPj4+PiBJJ20g
bm90IGZhbWlsaWFyIHdpdGggb3RoZXIgdXNlcnMgb2YgdGhpcyBwbGF0Zm9ybSAuCj4gPj4+PiBJ
IGFtIGRvIG5vdCBoYXZlIHRoZXNlIGJvYXJkcywgYWxsIHRoYXQgSSBoYXZlIHdyaXR0ZW4gYmVm
b3JlIHRoYXQgaXQncyBqdXN0IGEgdGhlb3J5Lgo+ID4+Pj4gRmlybSBpbiB3aGljaCBJIHdvcmss
IHVzZXMgaXRzIG93biBib2FyZCB3aXRoIENMUFM3MTFYIENQVSAsIHRoaXMgYm9hcmQgaXMgdGhl
Cj4gPj4+PiBvbmx5IHdheSB0byBjaGVjayBmb3IgY2hhbmdlcyBvbiByZWFsIGhhcmR3YXJlIC4K
PiA+Pj4KPiA+Pj4gT2suIFRoYXQgbWFrZXMgbWUgYSBiaXQgbmVydm91cy4uLiBZb3UncmUgcmVt
b3ZpbmcgYSBkcml2ZXIsIHdoaWNoIG1heQo+ID4+PiAob3IgbWF5IG5vdCkgaGF2ZSBiZWVuIHdv
cmtpbmcgZm9yIG90aGVyIHVzZXJzLiBBbmQgYWRkaW5nIGEgbmV3IG9uZSwKPiA+Pj4gd2hpY2gg
bWF5IG5vdCAob3IgbWF5KSB3b3JrIGZvciB0aGUgb3RoZXIgdXNlcnMuCj4gPj4KPiA+PiBLZWVw
IHRoZSBvbGQgb25lIGFyb3VuZCB1bmRlciBhbm90aGVyIEtjb25maWcgbmFtZSwgbWFyayBpdCBC
Uk9LRU4sCj4gPj4gYW5kIGlmIG5vYm9keSBzcGVha3MgdXAgaW4gYSBjb3VwbGUgb2YgcmVsZWFz
ZXMsIHJlbW92ZSBpdD8KPiA+IAo+ID4gSSBsaWtlIHRoaXMgdmFyaWFudCwgVG9taSBhcmUgeW91
IGFncmVlIHdpdGggdGhpcz8KPiAKPiBJIGRvbid0IGtub3cuIEFsbCBvcHRpb25zIHNvdW5kIHNv
bWV3aGF0IGJhZCB0byBtZSwgZXhjZXB0IGlmIGl0J3MgY2xlYXIKPiBub2JvZHkgdXNlcyB0aGUg
b2xkIGRyaXZlci4KPiAKPiBBbnl3YXksIGl0J3MgcmF0aGVyIGxhdGUgZm9yIDMuMTYuIEknZCBs
aWtlIHRoZSByZW1vdmFsIG9mIHRoZSBvbGQKPiBkcml2ZXIgdG8gc2l0IGluIHRoZSBsaW51eC1u
ZXh0IGZvciBhIHdoaWxlLgo+IAo+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGFkZCB0aGUgbmV3
IGRyaXZlciBhbG9uZyB0aGUgb2xkIGRyaXZlciwgYW5kIHVzZQo+IHRoZSBuZXcgZHJpdmVyIG9u
bHkgZm9yIHRoZSBib2FyZHMgeW91IGhhdmUsIGFuZCBmb3IgYm9hcmRzIGZvciB3aGljaAo+IGl0
J3MgY2xlYXIgdGhlIHRoZSBvbGQgZHJpdmVyIGlzIG5vdCB3b3JraW5nPyBUaGlzIGNvdWxkIGJl
IG1lcmdlZCBmb3IgMy4xNi4KCkF0IHRoaXMgdGltZSB5ZXMsIHdlIGNhbi4gQnV0IHNpbmNlIEkg
cGxhbiB0byBhZGQgbXVsdGlwbGF0Zm9ybSBzdXBwb3J0CmZvciB0aGlzIFNPQywgdGhpcyBzZWVt
cyBub3QgcG9zc2libGUuCkkgY2FuIHRyeSB0byBtYWtlIG11bHRpcGxhdGZvcm0gc3VwcG9ydCBv
cHRpb25hbCwgdGhlbiBpdCBjb3VsZCBiZSBkb25lLi4uCgo+IEl0J3Mgbm90IHNvIG5pY2UgdG8g
aGF2ZSB0d28gZHJpdmVycyBmb3IgdGhlIHNhbWUgaGFyZHdhcmUsIGJ1dCBpbiB0aGlzCj4gY2Fz
ZSBtYXliZSB0aGF0J3Mgbm90IGFuIGlzc3VlLiBUaGUgb2xkIGRyaXZlciBkb2Vzbid0IHN1cHBv
cnQgRFQsIHNvIG5vCj4gY29uZmxpY3RzIHRoZXJlLCBhbmQgZm9yIG5vbi1EVCB0aGUgZHJpdmVy
IG5hbWVzIHNlZW0gdG8gYmUgZGlmZmVyZW50Lgo+IAo+IEZvciAzLjE3LCB3ZSBjb3VsZCByZW1v
dmUgdGhlIG9sZCBkcml2ZXIsIGFuZCBwdXNoIHRoYXQgY2hhbmdlIHRvCj4gbGludXgtbmV4dCBy
aWdodCBhZnRlciB0aGUgMy4xNiBtZXJnZSB3aW5kb3cgaGFzIGNsb3NlZC4KPiAKPiBPciwgaWYg
eW91J3JlIGZpbmUgd2l0aCBpdCwgd2UgY2FuIGFsc28gZGVsYXkgYWRkaW5nIHRoZSBuZXcgZHJp
dmVyIHRvCj4gMy4xNywgYW5kIGRvIGJvdGggcmlnaHQgYWZ0ZXIgdGhlIDMuMTYgbWVyZ2Ugd2lu
ZG93IGhhcyBjbG9zZWQuIEkKPiBwZXJzb25hbGx5IGxpa2UgdGhpcyBtb3N0LCBzbyB0aGF0IHdl
IGhhdmUgYm90aCByZW1vdmFsIG9mIHRoZSBvbGQgYW5kCj4gYWRkaW5nIHRoZSBuZXcgc2l0dGlu
ZyBpbiB0aGUgbGludXgtbmV4dCBsb25nZXIsIGJ1dCB5b3UgbWlnaHQgcG9zc2libHkKPiB3YW50
IHRoZSBuZXcgZHJpdmVyIGluIHNvb25lci4KCklmIHRoZXJlIHdpbGwgYmUgdHdvIGRyaXZlcnMs
IEkgd2lsbCBkbyB0aGUgZm9sbG93aW5nOiByZW1vdmUgdGhlIG5vbi1EVApzdXBwb3J0IChmb3Ig
bmV3IGRyaXZlcikgYW5kIHdpbGwgY3JlYXRlIGEgcGF0Y2ggZm9yIDMuMTYgKHRoaXMgcGF0Y2gg
d2lsbApubyBhZmZlY3QgdG8gYXJtLXNvYykuCkFmdGVyIHRoYXQsIEkgd2lsbCBkbyBvcHRpb25h
bCBtdWx0aXBsYXRmb3JtIHN1cHBvcnQgZm9yIHRoaXMgQ1BVIGFuZCBtb3ZlCnRoZSBib2FyZHMs
IHdoaWNoIGRvIG5vdCB1c2UgRkIuCkFmdGVyIHRoaXMgYXJjaGl0ZWN0dXJlIHdpbGwgYmUgcmVh
ZHkgdG8gYWRkIERUIHN1cHBvcnQsIGFuZCBhZnRlciBhbGwgYm9hcmRzCndpbGwgYmUgY29udmVy
dGVkLCBJJ2xsIHJlbW92ZSB0aGUgb2xkIHZlcnNpb24gb2YgdGhlIGRyaXZlci4KCk9LPwoKLS0t
Cgo
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 13:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNTozMTo0NCArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDEyLzA0LzE0IDA5OjUzLCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+ID4gVGhpcyBhZGRzIHN1cHBvcnQgZm9yIHRoZSBmcmFtZWJ1ZmZlciBhdmFpbGFi
bGUgaW4gdGhlIENpcnJ1cwo+ID4gTG9naWMgQ0xQUzcxMVggQ1BVcy4KPiA+IEZCIGZlYXR1cmVz
Ogo+ID4gLSAxLTItNCBiaXRzIHBlciBwaXhlbC4KPiA+IC0gUHJvZ3JhbW1hYmxlIHBhbmVsIHNp
emUgdG8gYSBtYXhpbXVtIG9mIDEwMjR4MjU2IGF0IDQgYnBzLgo+ID4gLSBSZWxvY2F0aWJsZSBG
cmFtZSBCdWZmZXIgKFNSQU0gb3IgU0RSQU0pLgo+ID4gLSBQcm9ncmFtbWFibGUgcmVmcmVzaCBy
YXRlcy4KPiA+IC0gMTYgZ3JheSBzY2FsZSB2YWx1ZXMuCj4gPiBUaGlzIG5ldyBkcml2ZXIgc3Vw
cG9ydHMgdXNhZ2Ugd2l0aCBkZXZpY2V0cmVlIGFuZCBhcyBhIGdlbmVyYWwKPiA+IGNoYW5nZSBp
dCByZW1vdmVzIGxhc3QgdXNlciBvZiA8bWFjaC9oYXJkd2FyZS5oPiBmb3IgQ0xQUzcxMVggdGFy
Z2V0cywKPiA+IHNvIHRoaXMgc3ViYXJjaCB3aWxsIGZ1bGx5IHByZXBhcmVkIHRvIHN3aXRjaCB0
byBtdWx0aXBsYXRmb3JtLgo+ID4gVGhlIGRyaXZlciBoYXZlIGJlZW4gdGVzdGVkIHdpdGggY3Vz
dG9tIGJvYXJkIGVxdWlwcGVkIENpcnJ1cyBMb2dpYwo+ID4gRVA3MzEyIGluIERUIGFuZCBub24t
RFQgbW9kZS4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogQWxleGFuZGVyIFNoaXlhbiA8c2hjX3dv
cmtAbWFpbC5ydT4KPiA+IC0tLQo+ID4gIGRyaXZlcnMvdmlkZW8vZmJkZXYvY2xwczcxMXgtZmIu
YyB8IDQ1NiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+ID4gIDEgZmls
ZSBjaGFuZ2VkLCA0NTYgaW5zZXJ0aW9ucygrKQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2
ZXJzL3ZpZGVvL2ZiZGV2L2NscHM3MTF4LWZiLmMKPiAKPiA8c25pcD4KPiAKPiA+ICsKPiA+ICtz
dGF0aWMgaW50IGNscHM3MTF4X2ZiX2dldF9tb2RlX2R0KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug
KnBkZXYpCj4gPiArewo+ID4gKwlzdHJ1Y3QgZGV2aWNlX25vZGUgKmRpc3AsICpucCA9IHBkZXYt
PmRldi5vZl9ub2RlOwo+ID4gKwlzdHJ1Y3QgZmJfaW5mbyAqaW5mbyA9IHBsYXRmb3JtX2dldF9k
cnZkYXRhKHBkZXYpOwo+ID4gKwlzdHJ1Y3QgY2xwczcxMXhfZmJfaW5mbyAqY2ZiID0gaW5mby0+
cGFyOwo+ID4gKwlpbnQgcmV0Owo+ID4gKwo+ID4gKwljZmItPnN5c2NvbiA9Cj4gPiArCQlzeXNj
b25fcmVnbWFwX2xvb2t1cF9ieV9jb21wYXRpYmxlKCJjaXJydXMsY2xwczcxMXgtc3lzY29uMSIp
Owo+ID4gKwlpZiAoSVNfRVJSKGNmYi0+c3lzY29uKSkKPiA+ICsJCXJldHVybiBQVFJfRVJSKGNm
Yi0+c3lzY29uKTsKPiAKPiBIbW0sIHdoYXQncyB0aGUgc3lzY29uIHN0dWZmIGFib3V0PyBMb29r
cyBsaWtlIGl0J3MgcmVxdWlyZWQsIGJ1dCB0aGUgRFQKPiBkb2N1bWVudGF0aW9uIHBhdGNoIGRv
ZXNuJ3QgbWVudGlvbiBpdCBhdCBhbGwuCgpUaGlzIGRvZXMgbm90IHJlcXVpcmUgYW55IHNlcGFy
YXRlIHByb3BlcnR5IGZvciBGQi4KVGhlIHN5c2NvbiByZWdpc3RlcnMgaXMgZ2xvYmFsIHRvIHBs
YXRmb3JtLgoKLS0tCgo
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Arnd Bergmann @ 2014-05-23 13:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Friday 23 May 2014 17:13:58 Alexander Shiyan wrote:
> If there will be two drivers, I will do the following: remove the non-DT
> support (for new driver) and will create a patch for 3.16 (this patch will
> no affect to arm-soc).
> After that, I will do optional multiplatform support for this CPU and move
> the boards, which do not use FB.
> After this architecture will be ready to add DT support, and after all boards
> will be converted, I'll remove the old version of the driver.
>
> OK?
>
Sounds good to me.
Arnd
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 14:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]
On 23/05/14 16:13, Alexander Shiyan wrote:
>> Would it be possible to add the new driver along the old driver, and use
>> the new driver only for the boards you have, and for boards for which
>> it's clear the the old driver is not working? This could be merged for 3.16.
>
> At this time yes, we can. But since I plan to add multiplatform support
> for this SOC, this seems not possible.
> I can try to make multiplatform support optional, then it could be done...
Hmm, why is that not possible with multiplatform support? What do you
mean with multiplatform support here?
While the drivers would handle the same device, if they have different
names then they are different device drivers from Linux's perspective.
Why can't one board use the old driver, and an other board use the new
driver?
> If there will be two drivers, I will do the following: remove the non-DT
> support (for new driver) and will create a patch for 3.16 (this patch will
> no affect to arm-soc).
There would be no one using the driver in 3.16, then, right?
> After that, I will do optional multiplatform support for this CPU and move
> the boards, which do not use FB.
> After this architecture will be ready to add DT support, and after all boards
> will be converted, I'll remove the old version of the driver.
>
> OK?
I'm a bit unclear what the multiplatform stuff means here, but yes,
generally sounds ok.
But I don't want to make this more difficult for you than it needs to.
As I said, I'm fine with the current patches, if we skip 3.16 and get
them to linux-next right after the merge window. If nobody would use the
new driver in 3.16 anyway (in your proposal above), would this be the
easiest way?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Arnd Bergmann @ 2014-05-23 14:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Friday 23 May 2014 17:10:35 Tomi Valkeinen wrote:
> On 23/05/14 16:13, Alexander Shiyan wrote:
>
> >> Would it be possible to add the new driver along the old driver, and use
> >> the new driver only for the boards you have, and for boards for which
> >> it's clear the the old driver is not working? This could be merged for 3.16.
> >
> > At this time yes, we can. But since I plan to add multiplatform support
> > for this SOC, this seems not possible.
> > I can try to make multiplatform support optional, then it could be done...
>
> Hmm, why is that not possible with multiplatform support? What do you
> mean with multiplatform support here?
We are migrating all ARM platforms to allow building them into a single
kernel. However, that means that device drivers cannot access platform
specific header files any more and have to get hardware information from
DT or through platform data. The existing driver however uses mach/hardware.h.
Arnd
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 14:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNTo0ODo0MyArMDIwMCDQvtGCIEFybmQgQmVyZ21hbm4gPGFybmRA
YXJuZGIuZGU+Ogo+IE9uIEZyaWRheSAyMyBNYXkgMjAxNCAxNzoxMzo1OCBBbGV4YW5kZXIgU2hp
eWFuIHdyb3RlOgo+ID4gSWYgdGhlcmUgd2lsbCBiZSB0d28gZHJpdmVycywgSSB3aWxsIGRvIHRo
ZSBmb2xsb3dpbmc6IHJlbW92ZSB0aGUgbm9uLURUCj4gPiBzdXBwb3J0IChmb3IgbmV3IGRyaXZl
cikgYW5kIHdpbGwgY3JlYXRlIGEgcGF0Y2ggZm9yIDMuMTYgKHRoaXMgcGF0Y2ggd2lsbAo+ID4g
bm8gYWZmZWN0IHRvIGFybS1zb2MpLgo+ID4gQWZ0ZXIgdGhhdCwgSSB3aWxsIGRvIG9wdGlvbmFs
IG11bHRpcGxhdGZvcm0gc3VwcG9ydCBmb3IgdGhpcyBDUFUgYW5kIG1vdmUKPiA+IHRoZSBib2Fy
ZHMsIHdoaWNoIGRvIG5vdCB1c2UgRkIuCj4gPiBBZnRlciB0aGlzIGFyY2hpdGVjdHVyZSB3aWxs
IGJlIHJlYWR5IHRvIGFkZCBEVCBzdXBwb3J0LCBhbmQgYWZ0ZXIgYWxsIGJvYXJkcwo+ID4gd2ls
bCBiZSBjb252ZXJ0ZWQsIEknbGwgcmVtb3ZlIHRoZSBvbGQgdmVyc2lvbiBvZiB0aGUgZHJpdmVy
Lgo+ID4gCj4gPiBPSz8KPiA+IAo+IAo+IFNvdW5kcyBnb29kIHRvIG1lLgoKSSBhbSBnbGFkIHRo
YXQgYSBzbWFsbCBibG93LXVwIGNvZGUgZm9yIHRoaXMgKHRlbXBvcmFyeSkgcGVyaW9kIGlzIG5v
dCBjcml0aWNhbC4KT2YgY291cnNlIGl0J3MgYSBiaXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHdo
YXQgSSBoYWQgcGxhbm5lZCwgYnV0IEkgdGhpbmsKaXQgaXMgcG9zc2libGUgdG8gZG8uCgotLS0K
Cg=
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 14:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
On 23/05/14 17:14, Arnd Bergmann wrote:
> On Friday 23 May 2014 17:10:35 Tomi Valkeinen wrote:
>> On 23/05/14 16:13, Alexander Shiyan wrote:
>>
>>>> Would it be possible to add the new driver along the old driver, and use
>>>> the new driver only for the boards you have, and for boards for which
>>>> it's clear the the old driver is not working? This could be merged for 3.16.
>>>
>>> At this time yes, we can. But since I plan to add multiplatform support
>>> for this SOC, this seems not possible.
>>> I can try to make multiplatform support optional, then it could be done...
>>
>> Hmm, why is that not possible with multiplatform support? What do you
>> mean with multiplatform support here?
>
> We are migrating all ARM platforms to allow building them into a single
> kernel. However, that means that device drivers cannot access platform
> specific header files any more and have to get hardware information from
> DT or through platform data. The existing driver however uses mach/hardware.h.
Ah, I see. So the problem is not with two different drivers for the same
hardware device as such, but that in this case the older driver just
doesn't play well with multiplatform.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 14:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNzoxMDozNSArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDIzLzA1LzE0IDE2OjEzLCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+IAo+ID4+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGFkZCB0aGUgbmV3IGRyaXZl
ciBhbG9uZyB0aGUgb2xkIGRyaXZlciwgYW5kIHVzZQo+ID4+IHRoZSBuZXcgZHJpdmVyIG9ubHkg
Zm9yIHRoZSBib2FyZHMgeW91IGhhdmUsIGFuZCBmb3IgYm9hcmRzIGZvciB3aGljaAo+ID4+IGl0
J3MgY2xlYXIgdGhlIHRoZSBvbGQgZHJpdmVyIGlzIG5vdCB3b3JraW5nPyBUaGlzIGNvdWxkIGJl
IG1lcmdlZCBmb3IgMy4xNi4KPiA+IAo+ID4gQXQgdGhpcyB0aW1lIHllcywgd2UgY2FuLiBCdXQg
c2luY2UgSSBwbGFuIHRvIGFkZCBtdWx0aXBsYXRmb3JtIHN1cHBvcnQKPiA+IGZvciB0aGlzIFNP
QywgdGhpcyBzZWVtcyBub3QgcG9zc2libGUuCj4gPiBJIGNhbiB0cnkgdG8gbWFrZSBtdWx0aXBs
YXRmb3JtIHN1cHBvcnQgb3B0aW9uYWwsIHRoZW4gaXQgY291bGQgYmUgZG9uZS4uLgo+IAo+IEht
bSwgd2h5IGlzIHRoYXQgbm90IHBvc3NpYmxlIHdpdGggbXVsdGlwbGF0Zm9ybSBzdXBwb3J0PyBX
aGF0IGRvIHlvdQo+IG1lYW4gd2l0aCBtdWx0aXBsYXRmb3JtIHN1cHBvcnQgaGVyZT8KClRoZXJl
IGFyZSBzZXZlcmFsIHN0dWZmOgogLSA8bWFjaC8qLmg+Ci0gVXNlIFBBR0VfT0ZGU0VUCi0gVXNl
IHByaXZhdGUgY2xwc19yZWFkeC93cml0ZXgoKQoKPiBXaGlsZSB0aGUgZHJpdmVycyB3b3VsZCBo
YW5kbGUgdGhlIHNhbWUgZGV2aWNlLCBpZiB0aGV5IGhhdmUgZGlmZmVyZW50Cj4gbmFtZXMgdGhl
biB0aGV5IGFyZSBkaWZmZXJlbnQgZGV2aWNlIGRyaXZlcnMgZnJvbSBMaW51eCdzIHBlcnNwZWN0
aXZlLgo+IFdoeSBjYW4ndCBvbmUgYm9hcmQgdXNlIHRoZSBvbGQgZHJpdmVyLCBhbmQgYW4gb3Ro
ZXIgYm9hcmQgdXNlIHRoZSBuZXcKPiBkcml2ZXI/Cj4gCj4gPiBJZiB0aGVyZSB3aWxsIGJlIHR3
byBkcml2ZXJzLCBJIHdpbGwgZG8gdGhlIGZvbGxvd2luZzogcmVtb3ZlIHRoZSBub24tRFQKPiA+
IHN1cHBvcnQgKGZvciBuZXcgZHJpdmVyKSBhbmQgd2lsbCBjcmVhdGUgYSBwYXRjaCBmb3IgMy4x
NiAodGhpcyBwYXRjaCB3aWxsCj4gPiBubyBhZmZlY3QgdG8gYXJtLXNvYykuCj4gCj4gVGhlcmUg
d291bGQgYmUgbm8gb25lIHVzaW5nIHRoZSBkcml2ZXIgaW4gMy4xNiwgdGhlbiwgcmlnaHQ/CgpZ
ZXMuIFRoaXMgd2lsbCBiZSBpbnRlbmRlZCBqdXN0IGZvciBDT01QSUxFX1RFU1QgcmVhc29uLgoK
PiA+IEFmdGVyIHRoYXQsIEkgd2lsbCBkbyBvcHRpb25hbCBtdWx0aXBsYXRmb3JtIHN1cHBvcnQg
Zm9yIHRoaXMgQ1BVIGFuZCBtb3ZlCj4gPiB0aGUgYm9hcmRzLCB3aGljaCBkbyBub3QgdXNlIEZC
Lgo+ID4gQWZ0ZXIgdGhpcyBhcmNoaXRlY3R1cmUgd2lsbCBiZSByZWFkeSB0byBhZGQgRFQgc3Vw
cG9ydCwgYW5kIGFmdGVyIGFsbCBib2FyZHMKPiA+IHdpbGwgYmUgY29udmVydGVkLCBJJ2xsIHJl
bW92ZSB0aGUgb2xkIHZlcnNpb24gb2YgdGhlIGRyaXZlci4KPiA+IAo+ID4gT0s/Cj4gCj4gSSdt
IGEgYml0IHVuY2xlYXIgd2hhdCB0aGUgbXVsdGlwbGF0Zm9ybSBzdHVmZiBtZWFucyBoZXJlLCBi
dXQgeWVzLAo+IGdlbmVyYWxseSBzb3VuZHMgb2suCj4gCj4gQnV0IEkgZG9uJ3Qgd2FudCB0byBt
YWtlIHRoaXMgbW9yZSBkaWZmaWN1bHQgZm9yIHlvdSB0aGFuIGl0IG5lZWRzIHRvLgo+IEFzIEkg
c2FpZCwgSSdtIGZpbmUgd2l0aCB0aGUgY3VycmVudCBwYXRjaGVzLCBpZiB3ZSBza2lwIDMuMTYg
YW5kIGdldAo+IHRoZW0gdG8gbGludXgtbmV4dCByaWdodCBhZnRlciB0aGUgbWVyZ2Ugd2luZG93
LiBJZiBub2JvZHkgd291bGQgdXNlIHRoZQo+IG5ldyBkcml2ZXIgaW4gMy4xNiBhbnl3YXkgKGlu
IHlvdXIgcHJvcG9zYWwgYWJvdmUpLCB3b3VsZCB0aGlzIGJlIHRoZQo+IGVhc2llc3Qgd2F5PwoK
VGhpcyBpcyB0aGUgb25seSB3YXkgdG8gYW5ub3VuY2UgaW5pdGlhbCBtdWx0aXBsYXRmb3JtIHN1
cHBvcnQgKGluIGNhc2Ugd2Ugd2lsbAp1c2UgdHdvIGRpZmZlcnJlbnQgZHJpdmVycykuCkFub3Ro
ZXIgKGVhc2llc3QpIHdheSBpcyB0byB1c2UgdGhlIGN1cnJlbnQgcGF0Y2hzZXQuLi4KCi0tLQoK
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 14:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
On 23/05/14 17:27, Alexander Shiyan wrote:
>> But I don't want to make this more difficult for you than it needs to.
>> As I said, I'm fine with the current patches, if we skip 3.16 and get
>> them to linux-next right after the merge window. If nobody would use the
>> new driver in 3.16 anyway (in your proposal above), would this be the
>> easiest way?
>
> This is the only way to announce initial multiplatform support (in case we will
> use two differrent drivers).
> Another (easiest) way is to use the current patchset...
If the old driver doesn't even play well with multiplatform, and is thus
blocking moving the SoC to multiplatform, I'd just get done with it in
one go.
So I would recommend pushing the new driver and the removal of the old
one for 3.17, and having those changes in linux-next right after the
3.16 merge window.
Is that ok?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 14:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNzozMjowOCArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDIzLzA1LzE0IDE3OjI3LCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+IAo+ID4+IEJ1dCBJIGRvbid0IHdhbnQgdG8gbWFrZSB0aGlzIG1vcmUgZGlmZmlj
dWx0IGZvciB5b3UgdGhhbiBpdCBuZWVkcyB0by4KPiA+PiBBcyBJIHNhaWQsIEknbSBmaW5lIHdp
dGggdGhlIGN1cnJlbnQgcGF0Y2hlcywgaWYgd2Ugc2tpcCAzLjE2IGFuZCBnZXQKPiA+PiB0aGVt
IHRvIGxpbnV4LW5leHQgcmlnaHQgYWZ0ZXIgdGhlIG1lcmdlIHdpbmRvdy4gSWYgbm9ib2R5IHdv
dWxkIHVzZSB0aGUKPiA+PiBuZXcgZHJpdmVyIGluIDMuMTYgYW55d2F5IChpbiB5b3VyIHByb3Bv
c2FsIGFib3ZlKSwgd291bGQgdGhpcyBiZSB0aGUKPiA+PiBlYXNpZXN0IHdheT8KPiA+IAo+ID4g
VGhpcyBpcyB0aGUgb25seSB3YXkgdG8gYW5ub3VuY2UgaW5pdGlhbCBtdWx0aXBsYXRmb3JtIHN1
cHBvcnQgKGluIGNhc2Ugd2Ugd2lsbAo+ID4gdXNlIHR3byBkaWZmZXJyZW50IGRyaXZlcnMpLgo+
ID4gQW5vdGhlciAoZWFzaWVzdCkgd2F5IGlzIHRvIHVzZSB0aGUgY3VycmVudCBwYXRjaHNldC4u
Lgo+IAo+IElmIHRoZSBvbGQgZHJpdmVyIGRvZXNuJ3QgZXZlbiBwbGF5IHdlbGwgd2l0aCBtdWx0
aXBsYXRmb3JtLCBhbmQgaXMgdGh1cwo+IGJsb2NraW5nIG1vdmluZyB0aGUgU29DIHRvIG11bHRp
cGxhdGZvcm0sIEknZCBqdXN0IGdldCBkb25lIHdpdGggaXQgaW4KPiBvbmUgZ28uCj4gCj4gU28g
SSB3b3VsZCByZWNvbW1lbmQgcHVzaGluZyB0aGUgbmV3IGRyaXZlciBhbmQgdGhlIHJlbW92YWwg
b2YgdGhlIG9sZAo+IG9uZSBmb3IgMy4xNywgYW5kIGhhdmluZyB0aG9zZSBjaGFuZ2VzIGluIGxp
bnV4LW5leHQgcmlnaHQgYWZ0ZXIgdGhlCj4gMy4xNiBtZXJnZSB3aW5kb3cuCj4gCj4gSXMgdGhh
dCBvaz8KCkZvciBtZSBpdCBpcyBPSywgb2YgY291cnNlLiBEbyBJIHVuZGVyc3RhbmQgY29ycmVj
dGx5IHRoYXQgaW4gdGhpcyBjYXNlIEkgbmVlZAp0byB1cGRhdGUgcGF0Y2hzZXQgd2hpY2ggb25s
eSBhZGRzIG5ldyBkcml2ZXIgYW5kIG5ldyBLY29uZmlnIHN5bWJvbD8KClByb2JhYmx5IEkgYW0g
YWRkICJkZXBlbmQgb24gQlJPS0VOIGlmICFBUkNIX01VTFRJUExBVEZPUk0iIHRvCnRoZSBvbGQg
ZHJpdmVyLi4uCgotLS0KCg=
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: oma3-gta04: Add display support
From: Tony Lindgren @ 2014-05-23 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537F04D7.4000201@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140523 01:21]:
> On 08/05/14 23:16, Marek Belisko wrote:
> > This patch add support for lcd display on gta04 board. Display control
> > is connected to spi (used spi bitbang driver).
> >
> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> > ---
> > arch/arm/boot/dts/omap3-gta04.dts | 87 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 87 insertions(+)
>
> I can take this via my tree.
>
> Tony, can I have your ack on this?
Yes for the whole series:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Tony Lindgren @ 2014-05-23 14:46 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap,
peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <537F2ACD.6030603@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140523 04:03]:
> On 12/05/14 18:06, Tony Lindgren wrote:
> > * Jyri Sarha <jsarha@ti.com> [140512 02:13]:
> >> Since RFC version of the patch set:
> >> - Split callbacks removal patch away from "Integrated ASoC DAI
> >> component driver implementation" patches for easier reading
> >>
> >> This set of patches fixes OMAP4+ HDMI audio. The structure of the
> >> implementatin looks a bit different than before. Instead of creating a
> >> driver specific API for a separate ASoC component driver to connect
> >> to, this implementation integrates an the component driver into the
> >> HDMI driver.
> >>
> >> The idea is to use an existing ASoC component driver API instead of
> >> creating a new custom API for each HDMI IP and to avoid splitting the
> >> driver to half for separate video and audio parts connected with the
> >> API.
> >>
> >> The new implementation also uses simple-audio-card for a machine
> >> driver instead of having its own HW specific machine driver.
> >
> > Can you guys please post this split into the following separate
> > parts for the maintainers to merge:
> >
> > - ASoC changes
> > - DSS changes
> > - DTS changes
> >
> > And once those are all in, please post the defconfig changes.
>
> Tony, this series will get delayed until 3.17, but I'd like to merge the
> HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are
> patches 13 and 15.
>
> Those are very trivial, but I'd rather have acks from you for all the
> .dts changes I'll be sending.
OK fine with me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 00/13] Fix OMAP4+ HDMI audio
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
This patch set fixes the resource sharing problems between
omap-hdmi-dai driver and OMAPDSS HDMI driver. It does it by
registering the OMAP HDMI audio related ASoC drivers from OMAPDSS HDMI
driver. Platform data structs have been added for omap-hdmi-dai and
omap-hdmi-card drivers to pass the information and resources from
OMAPDSS HDMI driver.
The idea of this patch set is to fix HDMI audio for the next release
after it got broken by OMAPDSS DT changes. It does not mean that I
have abandoned the patch set that integrates the omap-hdmi-dai driver
into OMAPDSS HDMI driver. The OMAPDSS side of those patches just had
some dependencies to the recent ASoC side patches that would have
caused problems in the next merge. I'll mail a revised and rebased
version of those patches soon.
Best regards,
Jyri
Jyri Sarha (13):
ARM: omap4.dtsi: Add audio related parametes to hdmi node
ARM: omap5.dtsi: Add audio related parameters to hdmi node
ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base
address
OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio
support
ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai
driver
ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card
driver
ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS
ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS
OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver
ASoC: omap: Add Kconfig option for OMAP5 HDMI audio
arch/arm/boot/dts/omap4.dtsi | 2 +
arch/arm/boot/dts/omap5.dtsi | 2 +
arch/arm/mach-omap2/devices.c | 28 ---------
drivers/video/fbdev/omap2/dss/Makefile | 2 +-
drivers/video/fbdev/omap2/dss/hdmi.h | 17 ++++-
drivers/video/fbdev/omap2/dss/hdmi4.c | 15 +++++
drivers/video/fbdev/omap2/dss/hdmi5.c | 15 +++++
drivers/video/fbdev/omap2/dss/hdmi_audio.c | 92 ++++++++++++++++++++++++++++
drivers/video/fbdev/omap2/dss/hdmi_wp.c | 6 ++
include/sound/omap-hdmi-card-pdata.h | 28 +++++++++
include/sound/omap-hdmi-dai-pdata.h | 31 ++++++++++
sound/soc/omap/Kconfig | 13 +++-
sound/soc/omap/omap-hdmi-card.c | 20 ++++--
sound/soc/omap/omap-hdmi.c | 65 +++++---------------
14 files changed, 253 insertions(+), 83 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
create mode 100644 include/sound/omap-hdmi-card-pdata.h
create mode 100644 include/sound/omap-hdmi-dai-pdata.h
--
1.7.9.5
^ permalink raw reply
* [PATCH 01/13] ARM: omap4.dtsi: Add audio related parametes to hdmi node
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 649b5cd..335ed54 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -919,6 +919,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 02/13] ARM: omap5.dtsi: Add audio related parameters to hdmi node
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 32c02ce..279a9c7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -937,6 +937,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 03/13] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: peter.ujfalusi-l0cyMroinI0, broonie-DgEjT+Ai2ygdnm+yROfE0A,
liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
detheridge-l0cyMroinI0, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha-l0cyMroinI0@public.gmane.org>
This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/mach-omap2/devices.c | 28 ----------------------------
1 file changed, 28 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e58609b..4bab682 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -330,33 +330,6 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static struct platform_device omap_hdmi_audio = {
- .name = "omap-hdmi-audio",
- .id = -1,
-};
-
-static void __init omap_init_hdmi_audio(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- oh = omap_hwmod_lookup("dss_hdmi");
- if (!oh)
- return;
-
- pdev = omap_device_build("omap-hdmi-audio-dai", -1, oh, NULL, 0);
- WARN(IS_ERR(pdev),
- "Can't build omap_device for omap-hdmi-audio-dai.\n");
-
- platform_device_register(&omap_hdmi_audio);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
#if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include <linux/platform_data/spi-omap2-mcspi.h>
@@ -492,7 +465,6 @@ static int __init omap2_init_devices(void)
*/
omap_init_audio();
omap_init_camera();
- omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 04/13] OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base address
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
The hdmi_wp physical base address is needed for hdmi audio dma.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/hdmi.h | 2 ++
drivers/video/fbdev/omap2/dss/hdmi_wp.c | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
index fbee078..f644bc8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -341,6 +341,7 @@ struct hdmi_core_infoframe_avi {
struct hdmi_wp_data {
void __iomem *base;
+ phys_addr_t phys_base;
};
struct hdmi_pll_data {
@@ -410,6 +411,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param);
int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp);
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp);
/* HDMI PLL funcs */
int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
index a16a190..bee6df3 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -264,6 +264,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp)
temp_res.end = temp_res.start + WP_SIZE - 1;
res = &temp_res;
}
+ wp->phys_base = res->start;
wp->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (!wp->base) {
@@ -273,3 +274,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp)
return 0;
}
+
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp)
+{
+ return wp->phys_base;
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 05/13] OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio support
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
HDMI audio is implemented using ASoC component drivers. The drivers
were earlier registered from under mach-omap2 but that code had
problems with sharing the HDMI resources. This commit adds functions
for registering the ASoC drivers needed for HDMI audio from HDMI
driver itself.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/Makefile | 2 +-
drivers/video/fbdev/omap2/dss/hdmi.h | 12 ++++
drivers/video/fbdev/omap2/dss/hdmi_audio.c | 92 ++++++++++++++++++++++++++++
3 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
diff --git a/drivers/video/fbdev/omap2/dss/Makefile b/drivers/video/fbdev/omap2/dss/Makefile
index 390ab74..7ea2d7c 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -11,7 +11,7 @@ omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
- hdmi_phy.o
+ hdmi_phy.o hdmi_audio.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
index f644bc8..3ddb5f8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -434,6 +434,18 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep,
struct hdmi_phy_data *phy);
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+struct hdmi_audio_data {
+ struct platform_device *cpudai_pdev;
+ struct platform_device *codec_pdev;
+ struct platform_device *card_pdev;
+};
+
+int hdmi_audio_register(struct platform_device *pdev,
+ struct hdmi_audio_data *data,
+ struct omap_dss_device *hdmi,
+ struct hdmi_wp_data *wp);
+void hdmi_audio_unregister(struct hdmi_audio_data *data);
+
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_audio.c b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
new file mode 100644
index 0000000..2a485f7
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
@@ -0,0 +1,92 @@
+/*
+ * OMAP4+ HDMI audio
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated
+ *
+ * Authors: Jyri Sarha <jsarha@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/platform_device.h>
+#include <linux/of_dma.h>
+#include <linux/dmaengine.h>
+#include <sound/omap-hdmi-dai-pdata.h>
+#include <sound/omap-hdmi-card-pdata.h>
+
+#include "hdmi.h"
+
+static struct asoc_omap_hdmi_dai_pdata dai_pdata;
+struct asoc_omap_hdmi_card_pdata card_pdata;
+
+int hdmi_audio_register(struct platform_device *pdev,
+ struct hdmi_audio_data *data,
+ struct omap_dss_device *hdmi,
+ struct hdmi_wp_data *wp)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct dma_chan *dma_ch;
+ struct resource *res;
+
+ dai_pdata.dssdev = hdmi;
+ dai_pdata.dma_addr = hdmi_wp_get_phys_addr(wp) + HDMI_WP_AUDIO_DATA;
+
+ dma_ch = of_dma_request_slave_channel(np, "audio_tx");
+ if (IS_ERR(dma_ch)) {
+ dev_info(dev, "Could not get dma request channel from dts.\n");
+ /* Revert to hard coding. The DMA req channel is the
+ same on all supported hw. */
+ dai_pdata.dma_req = 76;
+ } else {
+ dai_pdata.dma_req = dma_ch->chan_id;
+ /* We only peeked the chan_id for pdata and let dai
+ driver take the DMA channel. */
+ dma_release_channel(dma_ch);
+ }
+
+ data->cpudai_pdev + platform_device_register_data(dev, "omap-hdmi-audio-dai", 0,
+ &dai_pdata, sizeof(dai_pdata));
+ if (IS_ERR(data->cpudai_pdev))
+ return PTR_ERR(data->cpudai_pdev);
+
+ data->codec_pdev + platform_device_register_data(dev, "hdmi-audio-codec",
+ 0, NULL, 0);
+ if (IS_ERR(data->codec_pdev)) {
+ platform_device_unregister(data->cpudai_pdev);
+ return PTR_ERR(data->codec_pdev);
+ }
+
+ card_pdata.cpudai_name = dev_name(&data->cpudai_pdev->dev);
+ card_pdata.codec_name = dev_name(&data->codec_pdev->dev);
+ data->card_pdev + platform_device_register_data(dev, "omap-hdmi-audio", 0,
+ &card_pdata, sizeof(card_pdata));
+ if (IS_ERR(data->card_pdev)) {
+ platform_device_unregister(data->cpudai_pdev);
+ platform_device_unregister(data->codec_pdev);
+ return PTR_ERR(data->card_pdev);
+ }
+ return 0;
+}
+
+void hdmi_audio_unregister(struct hdmi_audio_data *data)
+{
+ platform_device_unregister(data->cpudai_pdev);
+ platform_device_unregister(data->codec_pdev);
+ platform_device_unregister(data->card_pdev);
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 06/13] ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai driver
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
Provide the means to pass OMAPDSS HDMI resources over to omap-hdmi-dai
driver when the OMAPDSS driver registers the DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
include/sound/omap-hdmi-dai-pdata.h | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 include/sound/omap-hdmi-dai-pdata.h
diff --git a/include/sound/omap-hdmi-dai-pdata.h b/include/sound/omap-hdmi-dai-pdata.h
new file mode 100644
index 0000000..337c859
--- /dev/null
+++ b/include/sound/omap-hdmi-dai-pdata.h
@@ -0,0 +1,31 @@
+/*
+ * omap-hdmi-dai-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC DAI driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha <jsarha@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __OMAP_HDMI_DAI_PDATA_H__
+#define __OMAP_HDMI_DAI_PDATA_H__
+
+struct omap_dss_device;
+
+struct asoc_omap_hdmi_dai_pdata {
+ struct omap_dss_device *dssdev;
+ dma_addr_t dma_addr;
+ unsigned int dma_req;
+};
+
+#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 07/13] ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card driver
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
The names of the needed ASoC component drivers need to be passed to
the omap-hdmi-card driver for it to find them.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
include/sound/omap-hdmi-card-pdata.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 include/sound/omap-hdmi-card-pdata.h
diff --git a/include/sound/omap-hdmi-card-pdata.h b/include/sound/omap-hdmi-card-pdata.h
new file mode 100644
index 0000000..f70495b
--- /dev/null
+++ b/include/sound/omap-hdmi-card-pdata.h
@@ -0,0 +1,28 @@
+/*
+ * omap-hdmi-card-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC card driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha <jsarha@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __OMAP_HDMI_CARD_PDATA_H__
+#define __OMAP_HDMI_CARD_PDATA_H__
+
+struct asoc_omap_hdmi_card_pdata {
+ const char *cpudai_name;
+ const char *codec_name;
+};
+
+#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/13] ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
The old OMAP HDMI audio registering from arch/arm/mach-omap2/devices.c
was broken. The new approach is to register it from OMAPDSS HDMI
driver. The commit does the necessary changes for this approach to
omap-hdmi-dai driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
sound/soc/omap/omap-hdmi.c | 65 ++++++++++++--------------------------------
1 file changed, 17 insertions(+), 48 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 537a1ec..ed0a37c 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -35,6 +35,7 @@
#include <sound/dmaengine_pcm.h>
#include <video/omapdss.h>
+#include <sound/omap-hdmi-dai-pdata.h>
#include "omap-hdmi.h"
#include "omap-pcm.h"
@@ -65,7 +66,7 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream *substream,
return err;
}
- if (!priv->dssdev->driver->audio_supported(priv->dssdev)) {
+ if (!priv->dssdev->ops.hdmi->audio_supported(priv->dssdev)) {
dev_err(dai->dev, "audio not supported\n");
return -ENODEV;
}
@@ -80,7 +81,7 @@ static int omap_hdmi_dai_prepare(struct snd_pcm_substream *substream,
{
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
- return priv->dssdev->driver->audio_enable(priv->dssdev);
+ return priv->dssdev->ops.hdmi->audio_enable(priv->dssdev);
}
static int omap_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
@@ -206,7 +207,7 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream *substream,
priv->dss_audio.iec = iec;
priv->dss_audio.cea = cea;
- err = priv->dssdev->driver->audio_config(priv->dssdev,
+ err = priv->dssdev->ops.hdmi->audio_config(priv->dssdev,
&priv->dss_audio);
return err;
@@ -222,12 +223,12 @@ static int omap_hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- err = priv->dssdev->driver->audio_start(priv->dssdev);
+ err = priv->dssdev->ops.hdmi->audio_start(priv->dssdev);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- priv->dssdev->driver->audio_stop(priv->dssdev);
+ priv->dssdev->ops.hdmi->audio_stop(priv->dssdev);
break;
default:
err = -EINVAL;
@@ -240,7 +241,7 @@ static void omap_hdmi_dai_shutdown(struct snd_pcm_substream *substream,
{
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
- priv->dssdev->driver->audio_disable(priv->dssdev);
+ priv->dssdev->ops.hdmi->audio_disable(priv->dssdev);
}
static const struct snd_soc_dai_ops omap_hdmi_dai_ops = {
@@ -267,10 +268,14 @@ static const struct snd_soc_component_driver omap_hdmi_component = {
static int omap_hdmi_probe(struct platform_device *pdev)
{
- int ret;
- struct resource *hdmi_rsrc;
+ struct asoc_omap_hdmi_dai_pdata *pdata = pdev->dev.platform_data;
struct hdmi_priv *hdmi_data;
- bool hdmi_dev_found = false;
+ int ret;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform data, bailing out\n");
+ return -ENODEV;
+ }
hdmi_data = devm_kzalloc(&pdev->dev, sizeof(*hdmi_data), GFP_KERNEL);
if (hdmi_data = NULL) {
@@ -278,48 +283,12 @@ static int omap_hdmi_probe(struct platform_device *pdev)
return -ENOMEM;
}
- hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!hdmi_rsrc) {
- dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM HDMI\n");
- return -ENODEV;
- }
-
- hdmi_data->dma_data.addr = hdmi_rsrc->start + OMAP_HDMI_AUDIO_DMA_PORT;
-
- hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!hdmi_rsrc) {
- dev_err(&pdev->dev, "Cannot obtain IORESOURCE_DMA HDMI\n");
- return -ENODEV;
- }
-
- hdmi_data->dma_req = hdmi_rsrc->start;
+ hdmi_data->dma_data.addr = pdata->dma_addr;
+ hdmi_data->dma_req = pdata->dma_req;
hdmi_data->dma_data.filter_data = &hdmi_data->dma_req;
hdmi_data->dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
- /*
- * TODO: We assume that there is only one DSS HDMI device. Future
- * OMAP implementations may support more than one HDMI devices and
- * we should provided separate audio support for all of them.
- */
- /* Find an HDMI device. */
- for_each_dss_dev(hdmi_data->dssdev) {
- omap_dss_get_device(hdmi_data->dssdev);
-
- if (!hdmi_data->dssdev->driver) {
- omap_dss_put_device(hdmi_data->dssdev);
- continue;
- }
-
- if (hdmi_data->dssdev->type = OMAP_DISPLAY_TYPE_HDMI) {
- hdmi_dev_found = true;
- break;
- }
- }
-
- if (!hdmi_dev_found) {
- dev_err(&pdev->dev, "no driver for HDMI display found\n");
- return -ENODEV;
- }
+ hdmi_data->dssdev = pdata->dssdev;
dev_set_drvdata(&pdev->dev, hdmi_data);
ret = snd_soc_register_component(&pdev->dev, &omap_hdmi_component,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/13] ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
The old OMAP HDMI audio registering from arch/arm/mach-omap2/devices.c
was broken. The new approach is to register the drivers from OMAPDSS HDMI
driver. The commit does the necessary changes for this approach.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
sound/soc/omap/omap-hdmi-card.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
index f649fe8..56c0055 100644
--- a/sound/soc/omap/omap-hdmi-card.c
+++ b/sound/soc/omap/omap-hdmi-card.c
@@ -26,15 +26,13 @@
#include <sound/soc.h>
#include <asm/mach-types.h>
#include <video/omapdss.h>
+#include <sound/omap-hdmi-card-pdata.h>
#define DRV_NAME "omap-hdmi-audio"
static struct snd_soc_dai_link omap_hdmi_dai = {
.name = "HDMI",
.stream_name = "HDMI",
- .cpu_dai_name = "omap-hdmi-audio-dai",
- .platform_name = "omap-hdmi-audio-dai",
- .codec_name = "hdmi-audio-codec",
.codec_dai_name = "hdmi-hifi",
};
@@ -47,14 +45,28 @@ static struct snd_soc_card snd_soc_omap_hdmi = {
static int omap_hdmi_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct asoc_omap_hdmi_card_pdata *pdata = dev->platform_data;
struct snd_soc_card *card = &snd_soc_omap_hdmi;
int ret;
+ if (!pdata) {
+ dev_err(dev, "No platform data, bailing out\n");
+ return -ENODEV;
+ }
+
card->dev = &pdev->dev;
+ omap_hdmi_dai.cpu_dai_name + devm_kstrdup(dev, pdata->cpudai_name, GFP_KERNEL);
+ omap_hdmi_dai.platform_name + devm_kstrdup(dev, pdata->cpudai_name, GFP_KERNEL);
+ omap_hdmi_dai.codec_name + devm_kstrdup(dev, pdata->codec_name, GFP_KERNEL);
+
ret = snd_soc_register_card(card);
if (ret) {
- dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+ dev_err(dev, "snd_soc_register_card failed (%d)\n", ret);
card->dev = NULL;
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/13] OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
From: Jyri Sarha @ 2014-05-23 19:07 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1400871999.git.jsarha@ti.com>
The registering is best done here to share the resources owned by OMAPDSS
HDMI driver with ASoC DAI and platform drivers.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 626aad2..62ad1d9 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -52,6 +52,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_hdmi_dac_reg;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ struct hdmi_audio_data audio;
+#endif
bool core_enabled;
struct omap_dss_device output;
@@ -736,6 +739,15 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
hdmi_init_output(pdev);
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ r = hdmi_audio_register(pdev, &hdmi.audio, &hdmi.output, &hdmi.wp);
+ if (r) {
+ DSSERR("Registering HDMI audio failed\n");
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(&pdev->dev);
+ return r;
+ }
+#endif
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
return 0;
@@ -743,6 +755,9 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ hdmi_audio_unregister(&hdmi.audio);
+#endif
hdmi_uninit_output(pdev);
pm_runtime_disable(&pdev->dev);
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox