* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537A540E.8070302@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 11:58]:
> On 19/05/14 18:57, Tony Lindgren wrote:
>
> >> I'm not sure if it's even possible to load both of those drivers at the
> >> same time, but if it was, and the first one would get probe() called for
> >> a device, and the driver would return an error, I'm quite sure the
> >> driver framework won't continue trying with the other driver, as the
> >> first driver already matched for the device.
> >
> > No need to load multiple drivers at this point. That's why I'm saying
> > you can bail out on the undesired display controller probes using
> > of_machine_is_compatible test. It's not that uncommon for drivers to do:
>
> Hmm, I don't follow. If both, say, omap and exynos have a panel driver
> for the same sharp panel, both need a driver for it (presuming exynos
> has a proper display component driver system, which may not be true).
>
> Both drivers would be loaded at boot time for the probe to be even to be
> possible. Even if the other one bails out from a device probe using
> of_machine_is_compatible, afaik the driver framework will stop probing
> at that point, as that driver reports being compatible with the device
> in question.
>
> ...
>
> Ah, ok, now I see. I think you mean module init, not probe? For some
> reason I was just thinking about the probe stage.
>
> Maybe that would work. I need to test tomorrow.
Ah right probe is too late as the match has been made already by then :)
> >>> it would be quite silly for each display controller to have to do
> >>> their own remapping for shared panels?
> >>
> >> It would, but wouldn't it be just as silly (well, even more silly in my
> >> opinion) to have each display controller require driver specific
> >> compatible strings for the panels used?
> >
> > Not driver specific, but hardware package specific. That's being done
> > all the time. For example, compatible strings like "nvidia,tegra124",
> > "ti,omap5" describe a package of an ARM core and various devices.
>
> It feels to me rather wrong if I'd specify the compatible string for an
> external piece of hardware based on the SoC it's connected to.
>
> > But by using of_machine_is_compatible in the display drivers, you
> > can use the right compatible flags from the start if you want to go
> > that way.
>
> Yes, with that we could have right compatible flags in the .dts.
>
> >> Well, I sure hope nobody else has to implement similar thing.
> >
> > Suuuure.. I've heard that about 20 times before and guess what
> > happenened? Things never got fixed until some poor maintainer
> > had to start fixing it all over the place about three years later.
>
> The poor maintainer here being me =). And it's still a case of
> pick-your-poison. We need to hack around the issue, in some form or
> another. So in any case the poor maintainer has to fix it at some point
> in the future.
Yeah I agree none of the options so far have been very nice.
> But all this is fixed when we have a common display framework. And
> that's something that is really badly needed in some form or another,
> the sooner the better.
>
> So the "fix" here is not just some internal thing that could be left at
> that and forgotten.
Yes..
> >> To open that up a bit, traditionally other display driver architectures
> >> have not had drivers for each display "entity", like the panels. So you
> >> would really just have the display subsystem in the .dts, and some raw
> >> data there (panel timings) to get the panel running.
> >
> > Right, I believe that is the way to go, no doubt about it.
>
> No, that's exactly _not_ the way to go =). We need proper drivers for
> display components, instead of trying to avoid that and embed panel data
> into the display controller's data.
Right, sorry I misread it :)
> > Here's a list of things that bothers me:
> >
> > 1. Searching through the dtb from a driver instead of relying on the
> > driver probe mechanism for the components in question. If the parsing
> > of the dtb needs to be done it should be done in a Linux generic way
> > from some framework instead.
>
> The reason I haven't made the conversion code available for others to
> use is that there are no other users at the moment. And I hope there
> will be no other user until we get the common display framework. If
> there is, we'll need to move the code to a generic place.
>
> > 2. Having to do this all early before we even have any debug console
> > available. We are trying to move everything to happen later on to avoid
> > all the issues related to initializing things early.
>
> It worked fine for me when doing it as subsys_init level. Why do you say
> it'd be early, before debug console?
The debug console should not be needed for debugging drivers.. Just
the serial console. This is because it's hard for users to produce
decent error information when the system does not boot if DEBUG_LL
and earlyprintk need to be enabled.
> All the drivers with converted compatible strings are normal drivers, so
> afaik things work fine if we just convert the strings before the module
> init level.
Yes that seems like the right place to do the workarounds.
> > 3. Having to maintain a database in kernel of display mappings separately
> > in addition to the .dts files.
>
> Yes, that's slightly annoying. Not really a big burden, though, as it's
> quite rare to get a new encoder or panel driver.
>
> > 4. Having this hack limited to device tree based booting while we are
> > trying to unify the functions for drivers to use to get their
> > resources.
>
> I don't understand this one. With non-DT boot we don't have the issue at
> all, there's no need for hacks.
Hmm can't we still have multiarch booting happening with the same
panel name being used by two different display drivers?
> > 5. Seeing the possibility of this spreading to other drivers.
>
> Well, until we have a common display framework, one of the hacky options
> we've discussed will spread to other drivers if they need to have their
> own drivers for the same hardware devices.
>
> Which is not nice, but not something we can escape. And using the
> of_machine_is_compatible or having the compatible strings in .dts
> appended with "dss" or such doesn't change that, it just changes which
> hack may spread.
Yes I agree they are all hacks, but your version seems to carry some
extra early init baggage with it as I noted above :)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519160447.GB4849@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On 19/05/14 19:04, Tony Lindgren wrote:
> In many cases however we do have multiple compatible strings that
> describe how the device is wired. See drivers/tty/serial/of_serial.c
> for example. It has "ns16550" but then it also has additional
> "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
All those sound like SoC components. In that case it sounds fine to have
the device compatible contain the SoC name. We're talking here about
external, detachable devices.
>>> Not use what you're after with the SPI example though, but sounds
>>> like that's something different.
>>
>> I think Sebastien's example is just like the issue here.
>
> Hmm is there some existing example in the kernel like that?
No, Sebastien's example was just a hypothetical case. Here, using your
way of having SoC specific data in the .dts, we would have
"sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
sensor we'd have, say, "synaptics,xyz123-omap-spi".
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519155732.GA4849@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 5571 bytes --]
On 19/05/14 18:57, Tony Lindgren wrote:
>> I'm not sure if it's even possible to load both of those drivers at the
>> same time, but if it was, and the first one would get probe() called for
>> a device, and the driver would return an error, I'm quite sure the
>> driver framework won't continue trying with the other driver, as the
>> first driver already matched for the device.
>
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:
Hmm, I don't follow. If both, say, omap and exynos have a panel driver
for the same sharp panel, both need a driver for it (presuming exynos
has a proper display component driver system, which may not be true).
Both drivers would be loaded at boot time for the probe to be even to be
possible. Even if the other one bails out from a device probe using
of_machine_is_compatible, afaik the driver framework will stop probing
at that point, as that driver reports being compatible with the device
in question.
...
Ah, ok, now I see. I think you mean module init, not probe? For some
reason I was just thinking about the probe stage.
Maybe that would work. I need to test tomorrow.
>>> it would be quite silly for each display controller to have to do
>>> their own remapping for shared panels?
>>
>> It would, but wouldn't it be just as silly (well, even more silly in my
>> opinion) to have each display controller require driver specific
>> compatible strings for the panels used?
>
> Not driver specific, but hardware package specific. That's being done
> all the time. For example, compatible strings like "nvidia,tegra124",
> "ti,omap5" describe a package of an ARM core and various devices.
It feels to me rather wrong if I'd specify the compatible string for an
external piece of hardware based on the SoC it's connected to.
> But by using of_machine_is_compatible in the display drivers, you
> can use the right compatible flags from the start if you want to go
> that way.
Yes, with that we could have right compatible flags in the .dts.
>> Well, I sure hope nobody else has to implement similar thing.
>
> Suuuure.. I've heard that about 20 times before and guess what
> happenened? Things never got fixed until some poor maintainer
> had to start fixing it all over the place about three years later.
The poor maintainer here being me =). And it's still a case of
pick-your-poison. We need to hack around the issue, in some form or
another. So in any case the poor maintainer has to fix it at some point
in the future.
But all this is fixed when we have a common display framework. And
that's something that is really badly needed in some form or another,
the sooner the better.
So the "fix" here is not just some internal thing that could be left at
that and forgotten.
>> To open that up a bit, traditionally other display driver architectures
>> have not had drivers for each display "entity", like the panels. So you
>> would really just have the display subsystem in the .dts, and some raw
>> data there (panel timings) to get the panel running.
>
> Right, I believe that is the way to go, no doubt about it.
No, that's exactly _not_ the way to go =). We need proper drivers for
display components, instead of trying to avoid that and embed panel data
into the display controller's data.
> Here's a list of things that bothers me:
>
> 1. Searching through the dtb from a driver instead of relying on the
> driver probe mechanism for the components in question. If the parsing
> of the dtb needs to be done it should be done in a Linux generic way
> from some framework instead.
The reason I haven't made the conversion code available for others to
use is that there are no other users at the moment. And I hope there
will be no other user until we get the common display framework. If
there is, we'll need to move the code to a generic place.
> 2. Having to do this all early before we even have any debug console
> available. We are trying to move everything to happen later on to avoid
> all the issues related to initializing things early.
It worked fine for me when doing it as subsys_init level. Why do you say
it'd be early, before debug console?
All the drivers with converted compatible strings are normal drivers, so
afaik things work fine if we just convert the strings before the module
init level.
> 3. Having to maintain a database in kernel of display mappings separately
> in addition to the .dts files.
Yes, that's slightly annoying. Not really a big burden, though, as it's
quite rare to get a new encoder or panel driver.
> 4. Having this hack limited to device tree based booting while we are
> trying to unify the functions for drivers to use to get their
> resources.
I don't understand this one. With non-DT boot we don't have the issue at
all, there's no need for hacks.
> 5. Seeing the possibility of this spreading to other drivers.
Well, until we have a common display framework, one of the hacky options
we've discussed will spread to other drivers if they need to have their
own drivers for the same hardware devices.
Which is not nice, but not something we can escape. And using the
of_machine_is_compatible or having the compatible strings in .dts
appended with "dss" or such doesn't change that, it just changes which
hack may spread.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Arnd Bergmann @ 2014-05-19 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140519155732.GA4849@atomide.com>
On Monday 19 May 2014 08:57:33 Tony Lindgren wrote:
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:
>
> $ git grep of_machine_is_compatible drivers/ | wc -l
> 116
I think this is widely seen as bad style, and most of the examples are
testing for Power Mac specific workarounds for stuff that Apple didn't
put in DT elsewhere.
Arnd
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5379CD24.6040508@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:22]:
> On 16/05/14 21:01, Tony Lindgren wrote:
>
> >> IMHO appending -omap-dss to a random device is an even bigger hack,
> >> since its adding lots of bloat to the API. Let's assume there is
> >> another OS using DT for ARM, but has no proper API for SPI
> >> controllers and it introduces your hack to SPI devices. That would
> >> mean each SPI device has -omap-spi appended (or -exynos-spi,
> >> -foo-spi, ...). At least I would blame them for creating a huge
> >> unmaintainable mess.
> >
> > I think you're misunderstanding. I do not want the naming to
> > be Linux specific. The naming should naturally be as hardware
> > specific as possible. In this case something like:
> >
> > compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
> >
> > Or we should probably use:
> >
> > compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
> >
> > As dpi here reflects the hardware it's connected to. The dss
> > is probably a Linux name.
>
> Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
> wouldn't really be a good extension, as what we want is an omapdss
> driver specific compatible string. So I think "-omapdss" is the best
> extension if that method is used.
>
> But I don't think that's really the point. The point is that the panel's
> compatible string should be "sharp,ls037v7dw01", nothing else.
>
> All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
> only made for Linux SW reasons. So I would say they are Linux specific
> SW names, even if the words themselves are also HW terms.
If you really want to use only "sharp,ls037v7dw01" as the compatible
string, then you can still do that and bail out from the undesired
drivers by using of_machine_is_compatible check.
In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
> > Not use what you're after with the SPI example though, but sounds
> > like that's something different.
>
> I think Sebastien's example is just like the issue here.
Hmm is there some existing example in the kernel like that?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-19 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5379D35F.8040207@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:49]:
> On 17/05/14 00:39, Tony Lindgren wrote:
>
> >> AFAIK that remapping not needed at all. All that is already
> >> available with the compatible flags.
> >
> > And alternatively we can also just use the sharp,ls037v7dw01
> > in the panel driver(s). We can have the panels bail out in driver
> > probe based on of_machine_is_compatible if nothing else is available.
>
> I don't think that would work. Then we could have two panel drivers,
> both loaded into the kernel and both having the same driver name and the
> same compatible-string.
>
> I'm not sure if it's even possible to load both of those drivers at the
> same time, but if it was, and the first one would get probe() called for
> a device, and the driver would return an error, I'm quite sure the
> driver framework won't continue trying with the other driver, as the
> first driver already matched for the device.
No need to load multiple drivers at this point. That's why I'm saying
you can bail out on the undesired display controller probes using
of_machine_is_compatible test. It's not that uncommon for drivers to do:
$ git grep of_machine_is_compatible drivers/ | wc -l
116
> > Also, currently the remapping code also probably keeps prepending
> > more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
>
> I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
> match for "omapdss,ti,tfp410".
OK
> > it would be quite silly for each display controller to have to do
> > their own remapping for shared panels?
>
> It would, but wouldn't it be just as silly (well, even more silly in my
> opinion) to have each display controller require driver specific
> compatible strings for the panels used?
Not driver specific, but hardware package specific. That's being done
all the time. For example, compatible strings like "nvidia,tegra124",
"ti,omap5" describe a package of an ARM core and various devices.
But by using of_machine_is_compatible in the display drivers, you
can use the right compatible flags from the start if you want to go
that way.
> Until we have a common display framework, we need _some_ way to handle
> this problem. Either we mess up the .dts files as you suggest, or we
> have a driver internal hack.
It seems that there's no need to mess up the .dts files here by
using the of_machine_is_compatible check in the drivers.
> > If we still still despite all these reasons decide to go with
> > the remapping of the compatible strings, it should really be a
> > Linux generic (or drivers/video generic function), not implemented
> > for each display controller.
>
> Well, I sure hope nobody else has to implement similar thing.
Suuuure.. I've heard that about 20 times before and guess what
happenened? Things never got fixed until some poor maintainer
had to start fixing it all over the place about three years later.
> The reason why we have this code, and others do not, is mainly that
> omapdss is maybe the first driver to implement the display components
> properly, both in the SW side and in the .dts side, and that I wanted
> omapdss to behave correctly even if there are other display
> subsystems/panels compiled into the same kernel.
>
> To open that up a bit, traditionally other display driver architectures
> have not had drivers for each display "entity", like the panels. So you
> would really just have the display subsystem in the .dts, and some raw
> data there (panel timings) to get the panel running.
Right, I believe that is the way to go, no doubt about it.
> Now, with omapdss, we have separate drivers for each display entity.
> Unfortunately those drivers are all tied to the omapdss driver's API
> (and cannot thus be used on anything else than OMAP), as there's not yet
> a driver framework for display entities (DRM is a bit different thing,
> in my opinion).
>
> Everything with that was simple with platform data, as the omap board
> files created the panel devices, and there were no name clashing
> problems with other platforms.
>
> With DT that changed, as the bindings are common, and thus the
> compatible strings are common also. But we still have omapdss specific
> panel drivers. This is the reason we do the compatible-string conversion
> hack. As soon as we can create platform agnostic panel drivers, we can
> remove the hack.
>
> And, I want to remind, it's an omapdss internal hack (after the patch I
> sent), not visible to anyone else. The .dts files, the arch/arm files,
> they are all not touched. So I don't quite understand why you see it as
> such a bad thing. It's ugly, sure, but what harm does it do (except some
> maintainer burden, for me)?
Here's a list of things that bothers me:
1. Searching through the dtb from a driver instead of relying on the
driver probe mechanism for the components in question. If the parsing
of the dtb needs to be done it should be done in a Linux generic way
from some framework instead.
2. Having to do this all early before we even have any debug console
available. We are trying to move everything to happen later on to avoid
all the issues related to initializing things early.
3. Having to maintain a database in kernel of display mappings separately
in addition to the .dts files.
4. Having this hack limited to device tree based booting while we are
trying to unify the functions for drivers to use to get their
resources.
5. Seeing the possibility of this spreading to other drivers.
Regards,
Tony
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-05-19 14:44 UTC (permalink / raw)
To: Joachim Eastwood
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VyxKWZ9KSWoYkhf8KeUJnMKJO=b0kG=upC7uojNLHVObw@mail.gmail.com>
On 05/17/2014 12:16 PM, Joachim Eastwood wrote:
> On 17 May 2014 10:51, Joachim Eastwood <manabian@gmail.com> wrote:
>> On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
...
>>
>> I did some more testing over here.
>>
>> My HTPC (nVidia ION2 based) works good with speaker-test and all
>> channels are where they are suppose to be.
>>
>> On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
>> 1; done" and this had an interesting effect.
>> Most of the time FL (Front Left) is swapped with BL (Back Left) but
>> about every 10th time the sound comes out in the FL speaker... So
>> there something weird going on here. Same story for the right channel.
>>
>> I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
>> [ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
>> [ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
>> interface 58006000.encoder: -19
>>
>> But after replugging the HDMI connector a couple of times it starts to work.
>>
That is weird I can not reproduce this problem. I rebooted my panda
several times and the audio device was always there. Could it be that
the connector is in DVI mode or something?
>> I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
>
> On the 3.4 Variscite kernel:
> Linux version 3.4.0-1489-omap4 (uri@pluto) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10
> IDT 2013
> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git +
> Variscite vendor patches
>
> Both speaker-test -c 4 and -c 8 works. All channels are where they are
> suppose to be.
>
> Hot plugging is broken, though. So the HDMI must be connected on boot,
> but that might be the Variscite board setup.
>
I checked the ubuntu branch implementation and found that it is quite
different in many places, but the one place that affects the i2s channel
mapping to HDMI looks exactly the same. So there must be a bug some
where else and there is no point trying to fix it by changing the
mapping (it would be impossible anyway). I'll compare the
implementations further when I have time.
Thanks for your testing. Now I at least now where the bug is not.
Best regards,
Jyri
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Lee Jones @ 2014-05-19 13:50 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel, linux-fbdev, linux-omap, Bryan Wu, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <20140509012454.GL2198@atomide.com>
> If the GPIO for the backlight is on an I2C chip, we currently
> get nasty warnings like this during the boot:
>
> WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> Workqueue: deferwq deferred_probe_work_func
> [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
>
> Fix this by using gpio_set_value_cansleep() as suggested in
> drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> are also doing.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] video: delete unneeded call to platform_get_drvdata
From: Tomi Valkeinen @ 2014-05-19 13:04 UTC (permalink / raw)
To: Julia Lawall, Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1400308369-24375-2-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On 17/05/14 09:32, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Platform_get_drvdata is an accessor function, and has no purpose if its
> result is not used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> identifier x;
> type T;
> @@
> - T x = platform_get_drvdata(...);
> ... when != x
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/fbdev/bf54x-lq043fb.c | 2 --
> 1 file changed, 2 deletions(-)
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516213907.GL12881@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]
On 17/05/14 00:39, Tony Lindgren wrote:
>> AFAIK that remapping not needed at all. All that is already
>> available with the compatible flags.
>
> And alternatively we can also just use the sharp,ls037v7dw01
> in the panel driver(s). We can have the panels bail out in driver
> probe based on of_machine_is_compatible if nothing else is available.
I don't think that would work. Then we could have two panel drivers,
both loaded into the kernel and both having the same driver name and the
same compatible-string.
I'm not sure if it's even possible to load both of those drivers at the
same time, but if it was, and the first one would get probe() called for
a device, and the driver would return an error, I'm quite sure the
driver framework won't continue trying with the other driver, as the
first driver already matched for the device.
> Also, currently the remapping code also probably keeps prepending
> more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
match for "omapdss,ti,tfp410".
> it would be quite silly for each display controller to have to do
> their own remapping for shared panels?
It would, but wouldn't it be just as silly (well, even more silly in my
opinion) to have each display controller require driver specific
compatible strings for the panels used?
Until we have a common display framework, we need _some_ way to handle
this problem. Either we mess up the .dts files as you suggest, or we
have a driver internal hack.
> If we still still despite all these reasons decide to go with
> the remapping of the compatible strings, it should really be a
> Linux generic (or drivers/video generic function), not implemented
> for each display controller.
Well, I sure hope nobody else has to implement similar thing.
The reason why we have this code, and others do not, is mainly that
omapdss is maybe the first driver to implement the display components
properly, both in the SW side and in the .dts side, and that I wanted
omapdss to behave correctly even if there are other display
subsystems/panels compiled into the same kernel.
To open that up a bit, traditionally other display driver architectures
have not had drivers for each display "entity", like the panels. So you
would really just have the display subsystem in the .dts, and some raw
data there (panel timings) to get the panel running.
Now, with omapdss, we have separate drivers for each display entity.
Unfortunately those drivers are all tied to the omapdss driver's API
(and cannot thus be used on anything else than OMAP), as there's not yet
a driver framework for display entities (DRM is a bit different thing,
in my opinion).
Everything with that was simple with platform data, as the omap board
files created the panel devices, and there were no name clashing
problems with other platforms.
With DT that changed, as the bindings are common, and thus the
compatible strings are common also. But we still have omapdss specific
panel drivers. This is the reason we do the compatible-string conversion
hack. As soon as we can create platform agnostic panel drivers, we can
remove the hack.
And, I want to remind, it's an omapdss internal hack (after the patch I
sent), not visible to anyone else. The .dts files, the arch/arm files,
they are all not touched. So I don't quite understand why you see it as
such a bad thing. It's ugly, sure, but what harm does it do (except some
maintainer burden, for me)?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-19 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516180154.GG22031@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On 16/05/14 21:01, Tony Lindgren wrote:
>> IMHO appending -omap-dss to a random device is an even bigger hack,
>> since its adding lots of bloat to the API. Let's assume there is
>> another OS using DT for ARM, but has no proper API for SPI
>> controllers and it introduces your hack to SPI devices. That would
>> mean each SPI device has -omap-spi appended (or -exynos-spi,
>> -foo-spi, ...). At least I would blame them for creating a huge
>> unmaintainable mess.
>
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
>
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
>
> Or we should probably use:
>
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
>
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.
Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
wouldn't really be a good extension, as what we want is an omapdss
driver specific compatible string. So I think "-omapdss" is the best
extension if that method is used.
But I don't think that's really the point. The point is that the panel's
compatible string should be "sharp,ls037v7dw01", nothing else.
All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
only made for Linux SW reasons. So I would say they are Linux specific
SW names, even if the words themselves are also HW terms.
> Not use what you're after with the SPI example though, but sounds
> like that's something different.
I think Sebastien's example is just like the issue here.
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-18 12:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAxNiBNYXkgMjAxNCAxNTo1NjoyNiAtMDcwMCDQvtGCIE9sb2YgSm9oYW5zc29uIDxvbG9m
QGxpeG9tLm5ldD46Cj4gT24gVGh1LCBNYXkgMDgsIDIwMTQgYXQgMDE6MTQ6NDBQTSArMDMwMCwg
VG9taSBWYWxrZWluZW4gd3JvdGU6Cj4gPiBPbiAwOC8wNS8xNCAxMToyNywgQWxleGFuZGVyIFNo
aXlhbiB3cm90ZToKPiA+IAo+ID4gPj4+IEF0IHRoaXMgdGltZSB0aGUgZHJpdmVyIGhhcyB0aHJl
ZSB1c2VyLgo+ID4gPj4+IE9ubHkgb25lIG9mIHRoZW0gc2hvdWxkIHRoZW9yZXRpY2FsbHkgd29y
ay4KPiA+ID4+PiBjbHBzNzExeC1hdXRjcHUxMiBzaG91bGQgbm90IHdvcmsgaW4gdGhlIGFic2Vu
Y2Ugb2YgbWVtYmxvY2tfcmVzZXJ2ZSgpLgo+ID4gPj4+IGNscHM3MTF4LXA3MjB0IHNob3VsZCBu
b3Qgd29yayBkdWUgdG8gcGh5c2ljYWwgYWRkcmVzcyBsaW1pdGF0aW9uIGFzIGkKPiA+ID4+PiBu
b3RpY2VkIGJlZm9yZS4gQm9hcmQgbWVhbnMgdG8gdXNlIFNSQU0gaW5zdGVhZCBvZiBTRFJBTS4K
PiA+ID4+PiBPbmx5IGNscHM3MTF4LWVkYjcyMTEgc2hvdWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5
KS4KPiA+ID4+PiBJcyB0aGlzIGEgZ29vZCByZWFzb24gdG8gcmVwbGFjZSB0aGUgZHJpdmVyPyBJ
IHRoaW5rIHllcy4KPiA+ID4+Cj4gPiA+PiBPaywgaWYgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IGJh
ZCwgbWF5YmUgd2UgY2FuIGp1c3Qgc3dpdGNoIHRvIHRoZSBuZXcKPiA+ID4+IGRyaXZlci4gSGF2
ZSB5b3UgdmVyaWZpZWQgdGhhdCB0aG9zZSBib2FyZHMgZG8gbm90IHdvcmsgZnJvbSBhbnlvbmU/
IE9yCj4gPiA+PiBhc2tlZCBzb21lb25lIHRvIHRlc3QgdGhlIG5ldyBkcml2ZXIgd2l0aCB0aG9z
ZSBib2FyZHM/Cj4gPiA+IAo+ID4gPiBJJ20gbm90IGZhbWlsaWFyIHdpdGggb3RoZXIgdXNlcnMg
b2YgdGhpcyBwbGF0Zm9ybSAuCj4gPiA+IEkgYW0gZG8gbm90IGhhdmUgdGhlc2UgYm9hcmRzLCBh
bGwgdGhhdCBJIGhhdmUgd3JpdHRlbiBiZWZvcmUgdGhhdCBpdCdzIGp1c3QgYSB0aGVvcnkuCj4g
PiA+IEZpcm0gaW4gd2hpY2ggSSB3b3JrLCB1c2VzIGl0cyBvd24gYm9hcmQgd2l0aCBDTFBTNzEx
WCBDUFUgLCB0aGlzIGJvYXJkIGlzIHRoZQo+ID4gPiBvbmx5IHdheSB0byBjaGVjayBmb3IgY2hh
bmdlcyBvbiByZWFsIGhhcmR3YXJlIC4KPiA+IAo+ID4gT2suIFRoYXQgbWFrZXMgbWUgYSBiaXQg
bmVydm91cy4uLiBZb3UncmUgcmVtb3ZpbmcgYSBkcml2ZXIsIHdoaWNoIG1heQo+ID4gKG9yIG1h
eSBub3QpIGhhdmUgYmVlbiB3b3JraW5nIGZvciBvdGhlciB1c2Vycy4gQW5kIGFkZGluZyBhIG5l
dyBvbmUsCj4gPiB3aGljaCBtYXkgbm90IChvciBtYXkpIHdvcmsgZm9yIHRoZSBvdGhlciB1c2Vy
cy4KPiAKPiBLZWVwIHRoZSBvbGQgb25lIGFyb3VuZCB1bmRlciBhbm90aGVyIEtjb25maWcgbmFt
ZSwgbWFyayBpdCBCUk9LRU4sCj4gYW5kIGlmIG5vYm9keSBzcGVha3MgdXAgaW4gYSBjb3VwbGUg
b2YgcmVsZWFzZXMsIHJlbW92ZSBpdD8KCkkgbGlrZSB0aGlzIHZhcmlhbnQsIFRvbWkgYXJlIHlv
dSBhZ3JlZSB3aXRoIHRoaXM/CgotLS0KCg=
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-17 9:16 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VwY_qeOLsa_oAUuL3XT2tmn-mLg0WBtOdL8JL6u+0PQcw@mail.gmail.com>
On 17 May 2014 10:51, Joachim Eastwood <manabian@gmail.com> wrote:
> On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
>> On 14 May 2014 12:02, Jyri Sarha <jsarha@ti.com> wrote:
>>> On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
>>>>
>>>> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
>>>
>>> ...
>>>
>>>>
>>>> hey, this worked straight away :)
>>>>
>>>> But there seems to be something wrong with the channel mapping.
>>>>
>>>> For stereo (speaker-test -c 2) the mapping is correct.
>>>>
>>>> But for -c 4 and -c 8 it gets weird:
>>>> speaker-test -c 4 -s X # where X is 1-4
>>>> 1: Front Left is Rear Left
>>>> 2: Front Right is Rear Right
>>>> 3: Rear Right is Front Right
>>>> 4: Rear Left is Front Left
>>>>
>>>> speaker-test -c 8 -s X # where X is 1-8
>>>> 1: Front Left is Rear Left
>>>> 2: Center is Rear Left
>>>> 3: Front Right is Rear Right
>>>> 4: Side Right is Front Right
>>>> 5: Rear Right is silent
>>>> 6: Rear Left is Center
>>>> 7: Side Left is Front Left
>>>> 8: LFE - Rear Right
>>>>
>>>> I think you need to check what channel order ALSA expects. I believe
>>>> speaker-test does the right thing on my HTPC normally connected to my
>>>> receiver.
>>>>
>>>
>>> I checked the implementation and there was indeed something weird there, but
>>> the implementation can not explain the FL and FR channels jumping around. FL
>>> and FL should always be the first two channels in all configurations and the
>>> implementation does not touch them.
>>>
>>> The implementation uses 8ch HDMI setup for anything above 2ch with "Audio
>>> InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means
>>> following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
>>>
>>> This is a closest match to ALSA 8ch mapping (according to
>>> sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
>>
>> hm, okey. I haven't look at the code but it do seem strange. But with
>> speaker-test -c 4 the front and back are surely swapped here.
>>
>> I'll do some more testing and also check with my HTPC. btw, I only
>> have a 5.1 setup over here so I can't test all the discrete channels.
>>
>>> Current implementation has FLE and FC channels correctly swapped, but it
>>> shifts them to last two channels and RL, RR, SL, SR are shifted down to fill
>>> the place. This is all wrong and I'll try to come up with a fix for that.
>>> Unfortunately I can not test anything beyond 2 ch myself so I would need
>>> someone to volunteer to test my patch.
>>
>> I have the dev kit setup up over here so I can test your patches.
>
> I did some more testing over here.
>
> My HTPC (nVidia ION2 based) works good with speaker-test and all
> channels are where they are suppose to be.
>
> On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
> 1; done" and this had an interesting effect.
> Most of the time FL (Front Left) is swapped with BL (Back Left) but
> about every 10th time the sound comes out in the FL speaker... So
> there something weird going on here. Same story for the right channel.
>
> I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
> [ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
> [ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
> interface 58006000.encoder: -19
>
> But after replugging the HDMI connector a couple of times it starts to work.
>
> I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
On the 3.4 Variscite kernel:
Linux version 3.4.0-1489-omap4 (uri@pluto) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10
IDT 2013
git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git +
Variscite vendor patches
Both speaker-test -c 4 and -c 8 works. All channels are where they are
suppose to be.
Hot plugging is broken, though. So the HDMI must be connected on boot,
but that might be the Variscite board setup.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-17 8:51 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VzkGDPiQF7TiqiMgZY_oc9dyrW66yGsZR6ei2ejX-EXcw@mail.gmail.com>
On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
> On 14 May 2014 12:02, Jyri Sarha <jsarha@ti.com> wrote:
>> On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
>>>
>>> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
>>
>> ...
>>
>>>
>>> hey, this worked straight away :)
>>>
>>> But there seems to be something wrong with the channel mapping.
>>>
>>> For stereo (speaker-test -c 2) the mapping is correct.
>>>
>>> But for -c 4 and -c 8 it gets weird:
>>> speaker-test -c 4 -s X # where X is 1-4
>>> 1: Front Left is Rear Left
>>> 2: Front Right is Rear Right
>>> 3: Rear Right is Front Right
>>> 4: Rear Left is Front Left
>>>
>>> speaker-test -c 8 -s X # where X is 1-8
>>> 1: Front Left is Rear Left
>>> 2: Center is Rear Left
>>> 3: Front Right is Rear Right
>>> 4: Side Right is Front Right
>>> 5: Rear Right is silent
>>> 6: Rear Left is Center
>>> 7: Side Left is Front Left
>>> 8: LFE - Rear Right
>>>
>>> I think you need to check what channel order ALSA expects. I believe
>>> speaker-test does the right thing on my HTPC normally connected to my
>>> receiver.
>>>
>>
>> I checked the implementation and there was indeed something weird there, but
>> the implementation can not explain the FL and FR channels jumping around. FL
>> and FL should always be the first two channels in all configurations and the
>> implementation does not touch them.
>>
>> The implementation uses 8ch HDMI setup for anything above 2ch with "Audio
>> InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means
>> following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
>>
>> This is a closest match to ALSA 8ch mapping (according to
>> sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
>
> hm, okey. I haven't look at the code but it do seem strange. But with
> speaker-test -c 4 the front and back are surely swapped here.
>
> I'll do some more testing and also check with my HTPC. btw, I only
> have a 5.1 setup over here so I can't test all the discrete channels.
>
>> Current implementation has FLE and FC channels correctly swapped, but it
>> shifts them to last two channels and RL, RR, SL, SR are shifted down to fill
>> the place. This is all wrong and I'll try to come up with a fix for that.
>> Unfortunately I can not test anything beyond 2 ch myself so I would need
>> someone to volunteer to test my patch.
>
> I have the dev kit setup up over here so I can test your patches.
I did some more testing over here.
My HTPC (nVidia ION2 based) works good with speaker-test and all
channels are where they are suppose to be.
On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
1; done" and this had an interesting effect.
Most of the time FL (Front Left) is swapped with BL (Back Left) but
about every 10th time the sound comes out in the FL speaker... So
there something weird going on here. Same story for the right channel.
I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
[ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
[ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
interface 58006000.encoder: -19
But after replugging the HDMI connector a couple of times it starts to work.
I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 2/2] video: delete unneeded call to platform_get_drvdata
From: Julia Lawall @ 2014-05-17 6:32 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, Tomi Valkeinen, linux-fbdev, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
Platform_get_drvdata is an accessor function, and has no purpose if its
result is not used.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
- T x = platform_get_drvdata(...);
... when != x
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/bf54x-lq043fb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/bf54x-lq043fb.c b/drivers/video/fbdev/bf54x-lq043fb.c
index e2c42ad..adbef54 100644
--- a/drivers/video/fbdev/bf54x-lq043fb.c
+++ b/drivers/video/fbdev/bf54x-lq043fb.c
@@ -717,8 +717,6 @@ static int bfin_bf54x_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int bfin_bf54x_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct fb_info *fbinfo = platform_get_drvdata(pdev);
-
bfin_write_EPPI0_CONTROL(bfin_read_EPPI0_CONTROL() & ~EPPI_EN);
disable_dma(CH_EPPI0);
bfin_write_EPPI0_STATUS(0xFFFF);
^ permalink raw reply related
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Olof Johansson @ 2014-05-16 22:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
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'm still not really happy about it, and I'd much rather see the current
> >> driver fixed. But if no one having those boards is up to the task
> >> (probably not if they have not been working at all), maybe just ditching
> >> the old driver and adding a new is the only way forward.
> >>
> >> One change that I think would be good is to change the series to first
> >> remove the old driver, and then add the new one, with the same file name
> >> as the old one. That way git log will show the history for both the new
> >> and the old driver.
> >
> > In this case git-bisect will be broken. Is this OK?
>
> I think this is such a big change for the users of the driver that it's
> not an issue. Of course, kernel should still build at all steps, but I
> think it's fine if the fb driver in question will be out for a commit or
> two.
Agreed.
-Olof
^ permalink raw reply
* [PATCH 2/8] radeonfb: Out of line errata workarounds
From: Andi Kleen @ 2014-05-16 21:43 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, Andi Kleen, Benjamin Herrenschmidt, linux-fbdev
In-Reply-To: <1400276595-6965-1-git-send-email-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Out of lining _radeon_msleep and radeon_pll_errata_* saves about 40k text.
14193673 2003976 1507328 17704977 10e2811 vmlinux-before-radeon
14152713 2003976 1507328 17664017 10d8811 vmlinux-radeon
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/video/fbdev/aty/radeon_base.c | 57 ++++++++++++++++++++++++++++++++++
drivers/video/fbdev/aty/radeonfb.h | 58 ++---------------------------------
2 files changed, 60 insertions(+), 55 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 26d80a4..abd89a9 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -282,6 +282,63 @@ static int backlight = 1;
static int backlight = 0;
#endif
+/* Note about this function: we have some rare cases where we must not schedule,
+ * this typically happen with our special "wake up early" hook which allows us to
+ * wake up the graphic chip (and thus get the console back) before everything else
+ * on some machines that support that mechanism. At this point, interrupts are off
+ * and scheduling is not permitted
+ */
+void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms)
+{
+ if (rinfo->no_schedule || oops_in_progress)
+ mdelay(ms);
+ else
+ msleep(ms);
+}
+
+/*
+ * Note about PLL register accesses:
+ *
+ * I have removed the spinlock on them on purpose. The driver now
+ * expects that it will only manipulate the PLL registers in normal
+ * task environment, where radeon_msleep() will be called, protected
+ * by a semaphore (currently the console semaphore) so that no conflict
+ * will happen on the PLL register index.
+ *
+ * With the latest changes to the VT layer, this is guaranteed for all
+ * calls except the actual drawing/blits which aren't supposed to use
+ * the PLL registers anyway
+ *
+ * This is very important for the workarounds to work properly. The only
+ * possible exception to this rule is the call to unblank(), which may
+ * be done at irq time if an oops is in progress.
+ */
+void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
+{
+ if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
+ return;
+
+ (void)INREG(CLOCK_CNTL_DATA);
+ (void)INREG(CRTC_GEN_CNTL);
+}
+
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
+{
+ if (rinfo->errata & CHIP_ERRATA_PLL_DELAY) {
+ /* we can't deal with posted writes here ... */
+ _radeon_msleep(rinfo, 5);
+ }
+ if (rinfo->errata & CHIP_ERRATA_R300_CG) {
+ u32 save, tmp;
+ save = INREG(CLOCK_CNTL_INDEX);
+ tmp = save & ~(0x3f | PLL_WR_EN);
+ OUTREG(CLOCK_CNTL_INDEX, tmp);
+ tmp = INREG(CLOCK_CNTL_DATA);
+ OUTREG(CLOCK_CNTL_INDEX, save);
+ }
+}
+
+
/*
* prototypes
*/
diff --git a/drivers/video/fbdev/aty/radeonfb.h b/drivers/video/fbdev/aty/radeonfb.h
index cb84604..bb73446 100644
--- a/drivers/video/fbdev/aty/radeonfb.h
+++ b/drivers/video/fbdev/aty/radeonfb.h
@@ -370,20 +370,7 @@ struct radeonfb_info {
* IO macros
*/
-/* Note about this function: we have some rare cases where we must not schedule,
- * this typically happen with our special "wake up early" hook which allows us to
- * wake up the graphic chip (and thus get the console back) before everything else
- * on some machines that support that mechanism. At this point, interrupts are off
- * and scheduling is not permitted
- */
-static inline void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms)
-{
- if (rinfo->no_schedule || oops_in_progress)
- mdelay(ms);
- else
- msleep(ms);
-}
-
+void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms);
#define INREG8(addr) readb((rinfo->mmio_base)+addr)
#define OUTREG8(addr,val) writeb(val, (rinfo->mmio_base)+addr)
@@ -408,47 +395,8 @@ static inline void _OUTREGP(struct radeonfb_info *rinfo, u32 addr,
#define OUTREGP(addr,val,mask) _OUTREGP(rinfo, addr, val,mask)
-/*
- * Note about PLL register accesses:
- *
- * I have removed the spinlock on them on purpose. The driver now
- * expects that it will only manipulate the PLL registers in normal
- * task environment, where radeon_msleep() will be called, protected
- * by a semaphore (currently the console semaphore) so that no conflict
- * will happen on the PLL register index.
- *
- * With the latest changes to the VT layer, this is guaranteed for all
- * calls except the actual drawing/blits which aren't supposed to use
- * the PLL registers anyway
- *
- * This is very important for the workarounds to work properly. The only
- * possible exception to this rule is the call to unblank(), which may
- * be done at irq time if an oops is in progress.
- */
-static inline void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
-{
- if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
- return;
-
- (void)INREG(CLOCK_CNTL_DATA);
- (void)INREG(CRTC_GEN_CNTL);
-}
-
-static inline void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
-{
- if (rinfo->errata & CHIP_ERRATA_PLL_DELAY) {
- /* we can't deal with posted writes here ... */
- _radeon_msleep(rinfo, 5);
- }
- if (rinfo->errata & CHIP_ERRATA_R300_CG) {
- u32 save, tmp;
- save = INREG(CLOCK_CNTL_INDEX);
- tmp = save & ~(0x3f | PLL_WR_EN);
- OUTREG(CLOCK_CNTL_INDEX, tmp);
- tmp = INREG(CLOCK_CNTL_DATA);
- OUTREG(CLOCK_CNTL_INDEX, save);
- }
-}
+void radeon_pll_errata_after_index(struct radeonfb_info *rinfo);
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo);
static inline u32 __INPLL(struct radeonfb_info *rinfo, u32 addr)
{
--
1.9.0
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516180154.GG22031@atomide.com>
* Tony Lindgren <tony@atomide.com> [140516 11:02]:
> * Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> > On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > > >> strings.
> > > > >
> > > > > Well it avoid you parsing through all the nodes during booting
> > > > > and leaves out the function to do remapping. And removes the need
> > > > > for maintaining a custom display mapping table. I'd say that's a
> > > > > pretty good list of advantages right there :)
> > > >
> > > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > > things with .dts. I just like it more if any hacks are in kernel code,
> > > > which I can remove without anyone noticing.
> > > >
> > > > Anyway, we already have board.dts files using the non-omapified
> > > > compatible strings in the mainline, so if I would now add the omapified
> > > > compatible strings to .dts files, those old board.dts files would break.
> > > >
> > > > So I guess the choice has already been made.
> > >
> > > I really think you should remove this misuse of device tree code ASAP.
> > > It's better to fix it up now than carry the hack for next two years
> > > and keep on adding to it.
> >
> > IMHO appending -omap-dss to a random device is an even bigger hack,
> > since its adding lots of bloat to the API. Let's assume there is
> > another OS using DT for ARM, but has no proper API for SPI
> > controllers and it introduces your hack to SPI devices. That would
> > mean each SPI device has -omap-spi appended (or -exynos-spi,
> > -foo-spi, ...). At least I would blame them for creating a huge
> > unmaintainable mess.
>
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
>
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
>
> Or we should probably use:
>
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
>
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.
>
> Not use what you're after with the SPI example though, but sounds
> like that's something different.
>
> > I think Tomi's workaround is a much better hack, since it keeps the
> > API clean. If the code simply prefixes "omapdss," to all
> > "child"-devices of omapdss it can be left mostly untouched, too.
>
> AFAIK that remapping not needed at all. All that is already
> available with the compatible flags.
And alternatively we can also just use the sharp,ls037v7dw01
in the panel driver(s). We can have the panels bail out in driver
probe based on of_machine_is_compatible if nothing else is available.
Also, currently the remapping code also probably keeps prepending
more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
it would be quite silly for each display controller to have to do
their own remapping for shared panels?
If we still still despite all these reasons decide to go with
the remapping of the compatible strings, it should really be a
Linux generic (or drivers/video generic function), not implemented
for each display controller.
Cheers,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516174158.GA11733@earth.universe>
* Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > >> strings.
> > > >
> > > > Well it avoid you parsing through all the nodes during booting
> > > > and leaves out the function to do remapping. And removes the need
> > > > for maintaining a custom display mapping table. I'd say that's a
> > > > pretty good list of advantages right there :)
> > >
> > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > things with .dts. I just like it more if any hacks are in kernel code,
> > > which I can remove without anyone noticing.
> > >
> > > Anyway, we already have board.dts files using the non-omapified
> > > compatible strings in the mainline, so if I would now add the omapified
> > > compatible strings to .dts files, those old board.dts files would break.
> > >
> > > So I guess the choice has already been made.
> >
> > I really think you should remove this misuse of device tree code ASAP.
> > It's better to fix it up now than carry the hack for next two years
> > and keep on adding to it.
>
> IMHO appending -omap-dss to a random device is an even bigger hack,
> since its adding lots of bloat to the API. Let's assume there is
> another OS using DT for ARM, but has no proper API for SPI
> controllers and it introduces your hack to SPI devices. That would
> mean each SPI device has -omap-spi appended (or -exynos-spi,
> -foo-spi, ...). At least I would blame them for creating a huge
> unmaintainable mess.
I think you're misunderstanding. I do not want the naming to
be Linux specific. The naming should naturally be as hardware
specific as possible. In this case something like:
compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
Or we should probably use:
compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
As dpi here reflects the hardware it's connected to. The dss
is probably a Linux name.
Not use what you're after with the SPI example though, but sounds
like that's something different.
> I think Tomi's workaround is a much better hack, since it keeps the
> API clean. If the code simply prefixes "omapdss," to all
> "child"-devices of omapdss it can be left mostly untouched, too.
AFAIK that remapping not needed at all. All that is already
available with the compatible flags.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Sebastian Reichel @ 2014-05-16 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516160717.GD22031@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > On 15/05/14 21:21, Tony Lindgren wrote:
> > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > >> alternative for the compatible-string conversion we do now. I guess it's
> > >> a matter of taste, but I rather hide it inside the kernel, in an
> > >> internal omapdss file, than pollute the .dts files with those compatible
> > >> strings.
> > >
> > > Well it avoid you parsing through all the nodes during booting
> > > and leaves out the function to do remapping. And removes the need
> > > for maintaining a custom display mapping table. I'd say that's a
> > > pretty good list of advantages right there :)
> >
> > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > things with .dts. I just like it more if any hacks are in kernel code,
> > which I can remove without anyone noticing.
> >
> > Anyway, we already have board.dts files using the non-omapified
> > compatible strings in the mainline, so if I would now add the omapified
> > compatible strings to .dts files, those old board.dts files would break.
> >
> > So I guess the choice has already been made.
>
> I really think you should remove this misuse of device tree code ASAP.
> It's better to fix it up now than carry the hack for next two years
> and keep on adding to it.
IMHO appending -omap-dss to a random device is an even bigger hack,
since its adding lots of bloat to the API. Let's assume there is
another OS using DT for ARM, but has no proper API for SPI
controllers and it introduces your hack to SPI devices. That would
mean each SPI device has -omap-spi appended (or -exynos-spi,
-foo-spi, ...). At least I would blame them for creating a huge
unmaintainable mess.
I think Tomi's workaround is a much better hack, since it keeps the
API clean. If the code simply prefixes "omapdss," to all
"child"-devices of omapdss it can be left mostly untouched, too.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: sharp-ls037v7dw01 DT support
From: Tony Lindgren @ 2014-05-16 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400225402-18274-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140516 00:31]:
> Hi,
>
> These are slightly reworked versions of the patches Tony sent:
>
> * Split the DT doc into separate patch
> * Handle errors from gpio functions
> * Remove QVGA support
> * Removed the change to arch/arm/mach-omap2/display.c. I'll add that to my
> patch which moves the conversion code to omapdss. Note that if you test this
> version, you need to add the panel name to the conversion list for now.
> * Set MO gpio GPIO_ACTIVE_HIGH in omap3-evm-common.dtsi
> * Set the GPIO default values the same way for DT and non-DT versions.
>
> Tony, I removed the QVGA support as it was a new feature, not supported by the
> non-DT version. Also, I don't think it should be done as you had implemented
> it, but rather either have a flag in the DT data in case the pin is hardwired
> in the hardware, or let the user select the mode at runtime.
OK. Probably should have both options eventually.
> Also, I didn't quite understand the implementation. You had set initial values
> in the driver for MO and RESB differently than on the non-DT version. Was that
> on purpose?
I just configured things to what we had earlier for the legacy booting,
QVGA for ldp and VGA for omap3-evm.
> You said in a comment: "The LCD is sideways, so we want the VGA mode instead of
> QVGA mode.". Why is that? How does the resolution affect the orientation?
Yeah that's pretty confusing and probably written before I got the
image working properly. I probably initially thought the VGA mode also
switches the panel to 640x480, while it really sets it to 480x640.
> With my version, the panel (should) always be in VGA mode, like the non-DT
> version does.
>
> Only compile tested, I don't have boards with the panel.
Works for me on omap3-evm and ldp after patching in the mode to your
panel compatible translation database system.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5375A8A8.7080306@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> On 15/05/14 21:21, Tony Lindgren wrote:
>
> >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> >> alternative for the compatible-string conversion we do now. I guess it's
> >> a matter of taste, but I rather hide it inside the kernel, in an
> >> internal omapdss file, than pollute the .dts files with those compatible
> >> strings.
> >
> > Well it avoid you parsing through all the nodes during booting
> > and leaves out the function to do remapping. And removes the need
> > for maintaining a custom display mapping table. I'd say that's a
> > pretty good list of advantages right there :)
>
> Yep... I don't know. Maybe I'm being too careful about doing wrong
> things with .dts. I just like it more if any hacks are in kernel code,
> which I can remove without anyone noticing.
>
> Anyway, we already have board.dts files using the non-omapified
> compatible strings in the mainline, so if I would now add the omapified
> compatible strings to .dts files, those old board.dts files would break.
>
> So I guess the choice has already been made.
I really think you should remove this misuse of device tree code ASAP.
It's better to fix it up now than carry the hack for next two years
and keep on adding to it.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5375A713.7030409@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:51]:
> On 15/05/14 21:25, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 01:42]:
> >> On 14/05/14 00:26, Tony Lindgren wrote:
> >>
> >>> + /* lcd MO */
> >>> + ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> >>> + if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> +
> >>> + if (!IS_ERR(ddata->mo_gpio))
> >>> + if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> >>> + ddata->flags |= SHARP_LS_QVGA;
> >>
> >> Shouldn't there be an explicit flag in the DT data for this? If the
> >> panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
> >> have MO gpio, right? So something like:
> >>
> >>
> >> mode-gpios = <0 /* high, lcd MO */
> >> &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> >> &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
> >>
> >> vga-mode; /* MO hardwired high */
> >
> > Yeah holes there are just fine. I figured let's keep the custom
> > vga-mode property out of the way until we actually run into a panel
> > that's not using a GPIO for mode.
>
> Ok, I'm fine with that, but in that case I think we have to use all the
> panels in the same mode, i.e. the driver either sets the MO gpio always
> low and uses VGA mode, or sets the MO always high and uses QVGA mode.
OK let's default to VGA mode for now.
> In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to
> change the mode, even if it really should be ACTIVE_HIGH. But if you do
> that, and we later add the support to the panel driver to manage the MO
> gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then
> the panel won't work as the driver uses wrong polarity for the pin.
Getting the configured value seemed to work just fine with
gpiod_get_raw_value_cansleep(ddata->mo_gpio). But yeah I agree the
lack and confusion between polarity and desired default value for
a GPIO is is sucky. The ACTIVE_HIGH probably should mean polarity.
I don't know if there's an easy solution to that short of adding a
new GPIO binding that contains both the polarity and the desired
default value.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
From: Jyri Sarha @ 2014-05-16 11:56 UTC (permalink / raw)
To: Tomi Valkeinen, alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <5375EE07.4090802@ti.com>
On 05/16/2014 01:52 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 12/05/14 12:12, Jyri Sarha wrote:
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>> ---
>> drivers/video/fbdev/omap2/dss/Kconfig | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
>> index 8921a7a..ecc2f50 100644
>> --- a/drivers/video/fbdev/omap2/dss/Kconfig
>> +++ b/drivers/video/fbdev/omap2/dss/Kconfig
>> @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
>> HDMI support for OMAP4 based SoCs.
>>
>> config OMAP4_DSS_HDMI_AUDIO
>> - bool
>> + bool "HDMI audio support for OMAP4"
>> + depends on OMAP4_DSS_HDMI
>> + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
>> + default y
>> + help
>> + HDMI audio support for OMAP4 based SoCs. Adds integrated
>> + ASoC Digital Audio Interface component driver into OMAPDSS
>> + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
>> + devicetree description for full HDMI audio support.
>
> What does "for full HDMI audio support" mean? What's the partial support? =)
>
The hdmi driver provides a digital audio interface (DAI) which can be
used to transmit audio over the HDMI cable. The ASoC DAI component
driver provides just that functionality. A machine, platform, and (in
this case a dummy) codec component driver is also needed for a complete
ALSA device functionality.
Anyway, I look into Mark's suggestion of instantiating all the necessary
component drivers from the HDMI driver.
Best regards,
Jyri
^ permalink raw reply
* Re: [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
From: Mark Brown @ 2014-05-16 11:08 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap,
peter.ujfalusi, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <5375F0CC.8090507@ti.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Fri, May 16, 2014 at 02:04:44PM +0300, Tomi Valkeinen wrote:
> So all of the above .dts changes are already implied when we have HDMI
> video on the board. Is there no way to prevent every board needing to
> add those exact same nodes to get HDMI audio?
You can always instantiate devices directly from the HDMI controller
code, there's no need to put things in DT at all.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
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