* Re: [PATCH] video: amba-clcd: Make CLCD driver available on more platforms
From: Geert Uytterhoeven @ 2013-12-12 17:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1386868390-12231-1-git-send-email-broonie@kernel.org>
On Thu, Dec 12, 2013 at 6:13 PM, Mark Brown <broonie@kernel.org> wrote:
> The CLCD driver is used on ARM reference models for ARMv8 so add ARM64
> to the list of dependencies. The driver also has no build time dependencies
> on ARM (stubs are provided for ARM-specific DMA functions in the code) so
> make it available with COMPILE_TEST in order to maximise build coverage.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
> ---
> drivers/video/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4f2e1b35eb38..e6c7fb1a389b 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -312,7 +312,8 @@ config FB_PM2_FIFO_DISCONNECT
>
> config FB_ARMCLCD
> tristate "ARM PrimeCell PL110 support"
> - depends on FB && ARM && ARM_AMBA
> + depends on ARM || ARM64 || COMPILE_TEST
> + depends on FB && ARM_AMBA
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
Currently ARM_AMBA exists on arm/arm64 only.
Is there a patch in the pipeline to change that? Without such a change,
this patch doesn't make any difference.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] video: amba-clcd: Make CLCD driver available on more platforms
From: Mark Brown @ 2013-12-12 18:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1386868390-12231-1-git-send-email-broonie@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On Thu, Dec 12, 2013 at 06:48:49PM +0100, Geert Uytterhoeven wrote:
> Currently ARM_AMBA exists on arm/arm64 only.
> Is there a patch in the pipeline to change that? Without such a change,
I don't know but it's plausible given how common AMBA is.
> this patch doesn't make any difference.
No, it does mean that ARM64 is included - previously the dependency was
only on ARM so it wasn't available on ARM64. COMPILE_TEST won't have an
impact though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: amba-clcd: Make CLCD driver available on more platforms
From: Geert Uytterhoeven @ 2013-12-12 18:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1386868390-12231-1-git-send-email-broonie@kernel.org>
On Thu, Dec 12, 2013 at 7:07 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Dec 12, 2013 at 06:48:49PM +0100, Geert Uytterhoeven wrote:
>
>> Currently ARM_AMBA exists on arm/arm64 only.
>> Is there a patch in the pipeline to change that? Without such a change,
>
> I don't know but it's plausible given how common AMBA is.
>
>> this patch doesn't make any difference.
>
> No, it does mean that ARM64 is included - previously the dependency was
Sure.
> only on ARM so it wasn't available on ARM64. COMPILE_TEST won't have an
> impact though.
Sorry, I meant it doesn't have any impact on COMPILE_TEST.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Tony Lindgren @ 2013-12-12 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv35wKAK2PNjcXcNan9GC0x-MmH5k4xmzj_vKKhPeztHV-A@mail.gmail.com>
On Thu, Dec 12, 2013 at 09:31:02AM +0100, Belisko Marek wrote:
> Hi Tony,
>
> On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Belisko Marek <marek.belisko@gmail.com> [131210 14:13]:
> >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> >
> >> > It would be best to set it up as omap-ctrl.c driver under drivers
> >> > somewhere with few functions exported for DSS and MMC drivers.
> >>
> >> I create small dummy driver based on phy-omap-control which can be
> >> used but before sending patch (with more updates) I would like to get
> >> some feedback if my direction is correct.
> >
> > Cool thanks. Yeah what you have can easily be combined with the patches
> > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap
> > for the SCM register access. Maybe take a look at the work in progress
> > patches in thread:
> >
> > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup
> >
> > And also see my comments regarding using the SCM GENERAL register area
> > as base for the syscon.c driver. That should work for your driver too,
> > right? And then you can access the SYSCON1 register that way from your
> > consumer driver ;)
>
> If I understand correclty I can use syscon driver (it will have in
> range also devconf1 register) ad get rid of my custom driver
> and then get regmap from syscon and update bits that I need for venc, right?
Yeah something like that. Or since the sysconf1 register is shared, it might
be best to still provide specific functions to access it if we cannot map
just specific bits of it separately for drivers using regmap.
But anyways this should for most part remove the need for a custom driver(s)
unless the register is a regulator or a clock.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tony Lindgren @ 2013-12-12 21:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, Tony Lindgren, linux-omap, linux-fbdev,
devicetree, Archit Taneja, Darren Etheridge
In-Reply-To: <52A9760A.3000801@ti.com>
On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> On 2013-12-12 01:44, Laurent Pinchart wrote:
>
> So, are they independent? I don't know =). I think they lean on the
> independent side. dss_core is always needed for the submodules to work,
> but for example DSI could be used without DISPC, using system DMA to
> transfer data from memory to DSI. Not a very useful thing to do, but
> still, there are dedicated DMA channels for that.
If they have separate hwmod entries, they should be considered separate
independent devices for sure.
To summarize, here are few reasons why they need to be treated as
separate devices:
1. The modules maybe clocked/powered/idled separately and can have their
own idle configuration so they can do the hardware based idling
separately.
2. Doing a readback after a write to one module will not flush the write
to the other modules on the (bus depending on the SoC version AFAIK).
That can lead to nasty bugs caused by the ordering.
3. If the devices are described in a different way in the .dts files
from the hwmod data, we will not have 1-to-1 mapping and will never
be able to replace ti,hwmods with just the compatible string.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 10/26] OMAPDSS: add of helpers
From: Laurent Pinchart @ 2013-12-13 2:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <52A96A4E.1010006@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Hi Tomi,
On Thursday 12 December 2013 09:48:30 Tomi Valkeinen wrote:
> On 2013-12-12 01:19, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> >> Add helpers to get ports and endpoints from DT data.
> >>
> >> While all the functions in dss-of.c might be useful for panel drivers if
> >> they need to parse full port/endpoint data, at the moment we only need a
> >> few of them outside dss-of.c, so only those functions are exported.
> >
> > I totally understand that it was easier to add this code to the OMAP DSS
> > driver, but I believe we should refactor the existing drivers/media/v4l2-
> > core/v4l2-of.c and move it to a non V4L2-specific location (what about
> > drivers/media ?) sooner rather than later. That's on my to-do list for
> > Saturday.
>
> I agree. I just didn't want to go that way yet =).
>
> Have you thought of the API? You had one version in your CDF series, but
> I think that was a bit too limited (I don't remember right now how), so
> I wrote my own versions.
>
> What I tried to do here is to add simple ways for the drivers to iterate
> the ports and endpoints with omapdss_of_get_next_port and
> omapdss_of_get_next_endpoint.
>
> But I'm not sure what the use pattern would be. If in most of the cases
> the driver always goes through all the ports and all the endpoints, we
> could as well have a helper function that goes through all the endpoints
> in all the ports, and returns both the port and endpoint for each iteration.
My plan is to keep it simple. I'll take the V4L2 code and add helpers needed
by this patch series and by my Renesas KMS drivers. I'll then see whether
refactoring makes sense, and will post the result. We will then add new
helpers whenever needed on a case by case basis.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Laurent Pinchart @ 2013-12-13 3:24 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <52A9760A.3000801@ti.com>
[-- Attachment #1: Type: text/plain, Size: 7493 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:38:34 Tomi Valkeinen wrote:
> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> >> for any of the subdevices to work. This is done automatically by the
> >> runtime PM when the subdevices are children of the dss_core.
> >
> > I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
> > organized in a seemingly similar way, with the hardware subdivided in
> > high-level more-or-less independent modules. However, from a system point
> > of view, the ISP submodules are not standalone: they're part of the same
> > power domain as the ISP core, with subclocks management and interrupts
> > being handled by the ISP core. For those reasons we've modeled the ISP as
> > a single platform device.
> >
> > Are the DSS submodules really independent, or are they organized similarly
> > ? For instance do they each have a clock handled by the OMAP core clock
> > IP, or are the clocks gated by the DSS core ? Do they have interrupts
> > routed to the GIC, or does the DSS core driver demux the interrupts ?
>
> The DSS is "interesting". The TRM for various OMAP versions are the best
> source of information, there's integration section in the very beginning
> of the DSS chapter.
>
> We have the main dss_core (just DSS in the TRM, but for clarity we use
> dss_core) module, which is kind of a wrapper/glue for all the
> submodules. dss_core contains things like controlling muxes for signals
> between submodules, or clocks coming from outside. And there's the DSS
> power domain, containing all the DSS modules.
>
> Then we have DISPC, which reads the pixel data, manipulates it, and
> outputs raw RGB data to encoder submodules.
>
> Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have
> separate address spaces, some have dedicated PLLs, PHYs, and interrupts.
The separate address spaces are not by themselves a clear indication that the
submodules should be considered as separate devices, as the hardware might
just group registers related to submodules together.
The dedicated interrupts (for DSI and HDMI) and PRCM clocks (for VENC if I'm
not mistaken, and HDMI on the OMAP4) are a clearer sign.
> Then DPI, which I think is mostly just level shifters. It's really just
> a port, as you say.
>
> SDI is a bit unclear to me. The registers for it are in the dss_core.
> There's only a few registers, but it does have a PHY and a PLL. But I
> guess it's also more of a port than a separate module.
After a quick look at the documentation I would say so. I would be tempted to
consider RFBI as part of the DSS core, but that's less clear.
> As for the clocks, I'm not sure what the actual point is that you want
> to clarify. DSS gets one "main" func clock from PRCM, which is used by
> DISPC and in some cases other submodules. But then we have dedicated DSI
> and HDMI PLLs, which, at least in DSI's case, can be used to fully
> satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the
> PRCM clock is not needed in all cases.
>
> The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have
> their own interrupt line. In OMAP3, DISPC and DSI shared the same
> interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt
> status/enable is handled via the respective IP.
>
> The DSS submodules also are not really designed together. For example,
> the HDMI IP is from one vendor, not TI. And the HDMI IP is different in
> OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's
> not like all the IPs were designed to work together, that's why we have
> wrappers/glue blocks (e.g. around HDMI).
>
> So, are they independent? I don't know =). I think they lean on the
> independent side.
I agree with that, except for DPI, SDI and possibly RFBI.
> dss_core is always needed for the submodules to work, but for example DSI
> could be used without DISPC, using system DMA to transfer data from memory
> to DSI. Not a very useful thing to do, but still, there are dedicated DMA
> channels for that.
Right. The real question is whether the DSI or HDMI IPs can be used in a
system without the DSS core. If not, it might make sense to just merge the
drivers into a single module (of course with a clear interface between the
different parts to avoid spaghetti code).
> > If the submodules are not independent, would it make sense to have a
> > single DT node that would be matched with the DSS core driver ? You could
> > list information about the submodules in subnodes, and possibly create
> > platform devices internally in the DSS core, but a single platform device
> > would be instantiated from DT, and the DSS core wouldn't need a
> > "simple-bus" compatible string. My gut feeling is that this would be a
> > better representation of the hardware, but I might not known enough about
> > the DSS and be completely wrong.
>
> I have been wondering about this for a long time. The DSS modules have
> dependencies, and splitting them into separate devices/drivers brings
> the issue of probe order. We side-step that by having the virtual
> omapdss driver
Given that the DSS core has a set of registers not dedicated to any of the
submodules I believe it should be represented by a device. The omapdss driver
thus doesn't look virtual to me, it supports a real piece of hardware.
> add the drivers for DSS modules in proper order.
>
> But then, I feel that they are quite independent and probably should be
> separate devices.
Even if they're separate devices they could be instantiated by DSS core based
on DT nodes. I'm not sure whether that's the best idea, but it might be worth
thinking about it.
> And we've had omap hwmods, which I believe force us to have separate devices
> (although afaik hwmods are going away).
>
> >>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> >>> property and do the lookup based on the compatible property instead ;)
> >>> So from that point of view we need to get the device mapping right in
> >>> the .dtsi files, and don't want to start mixing up separate devices into
> >>> single .dtsi entry.
> >>
> >> Hmm, was that just a general comment, or something that affects the DSS
> >> DT data I have in my patch? As far as I understand, the DSS nodes
> >> reflect the current hwmods correctly.
> >>
> >> With the exception that DPI and SDI do not have a matching hwmod, as
> >> they are really part of dss_core/dispc. They are separate nodes as they
> >> are "video outputs" the same way as the other subnodes.
> >>
> >> I could perhaps remove the DPI and SDI nodes, and have them as direct
> >> video ports from DISPC, but... That's easier said than done.
> >
> > DPI and SDI indeed seem like ports to me, node devices. Have you given the
> > implementation a thought ? How difficult would it be ?
>
> I have not though too much about the implementation. I'll spend some time on
> that to see how it goes.
>
> There's also the question where do the ports belong to. DISPC outputs the
> pixels.
>
> For DPI, I don't see dss_core really doing anything.
>
> For SDI, the dss_core contains the control for the SDI PLL and PHY. But
> SDI PLL and PHY are not parts of dss_core, just the control is done via
> dss_core.
If the PLL and PHY are solely controlled through registers part of the DSS
core register space, they would seem like part of the DSS core to me.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Laurent Pinchart @ 2013-12-13 3:27 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
In-Reply-To: <20131212215913.GB29072@muru.com>
Hi Tony,
On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> > On 2013-12-12 01:44, Laurent Pinchart wrote:
> >
> > So, are they independent? I don't know =). I think they lean on the
> > independent side. dss_core is always needed for the submodules to work,
> > but for example DSI could be used without DISPC, using system DMA to
> > transfer data from memory to DSI. Not a very useful thing to do, but
> > still, there are dedicated DMA channels for that.
>
> If they have separate hwmod entries, they should be considered separate
> independent devices for sure.
>
> To summarize, here are few reasons why they need to be treated as
> separate devices:
Are you talking generally here, or about the DSS modules in particular ?
> 1. The modules maybe clocked/powered/idled separately and can have their
> own idle configuration so they can do the hardware based idling
> separately.
I don't think this applies to the DSS modules.
> 2. Doing a readback after a write to one module will not flush the write
> to the other modules on the (bus depending on the SoC version AFAIK).
> That can lead to nasty bugs caused by the ordering.
How does separate devices solve this ?
> 3. If the devices are described in a different way in the .dts files
> from the hwmod data, we will not have 1-to-1 mapping and will never
> be able to replace ti,hwmods with just the compatible string.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Laurent Pinchart @ 2013-12-13 3:45 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52A979D8.3040604@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote:
> On 2013-12-12 02:39, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> Here's a new version for DT support to OMAP Display Subsystem. See
> >> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro
> >> of the previous version, which contains thoughts about the related
> >> problems.
> >>
> >> The major change in this version is the use of V4L2 and CDF style
> >> port/endpoint style in the DT data.
> >
> > That's great, and I fully support that. This also calls for refactoring
> > the V4L2 DT bindings and support code to share them with display devices.
> > A bikeshedding question is where to put the common code.
>
> Thanks very much for review!
>
> I know drivers/video is in practice "fbdev", but drivers/video (the
> words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev and
generic video in a single directory. We could use a subdirectory of
drivers/video.
> We should establish a committee to ponder this important question.
>
> Btw, I don't know if you noticed (or did I mention it somewhere): I use
> a bit shortened form of the V4L2 bindings. If there's just one endpoint,
> I omit the port node. I think that's always unambiguous (compared to
> also omitting the endpoint node, and having the properties in the main
> node, as was mentioned in some other thread).
Yes, I've seen that. I need to analyze this in detail, that's planned for when
I'll work on sharing the DT parsing code.
> I also don't supply the same data for both endpoints, when the data is about
> the link. E.g. I think the V4L2 binding doc suggests to supply things like
> bus-width for both endpoints. I only supply the data for the endpoint that
> uses that data. With some encoders/panels the same data could be needed on
> both ends, but not in these patches.
How do you handle the situation where the two drivers (for each end of the
link) need to know the bus width for instance ?
> >> However, note that even if the DT data contains proper port & endpoint
> >> data, the drivers only use the first endpoint. This is to simplify the
> >> patches, as adding full support for the ports and endpoints to the
> >> drivers will be a big task.
> >
> > That's perfectly fine, there's no need to implement unused features just
> > for the sake of it, as long as the bindings are forward-compatible in
> > that respect.
> >
> >> This approach still works with more or less all the boards, as the only
> >> cases where the simpler model is an issue are the boards with multiple
> >> display devices connected to a single output.
> >>
> >> Laurent, I'd appreciate if you could have a look at the .dts changes, to
> >> see if there's anything that's clearly not CDF compatible.
> >
> > I've quickly reviewed the patch set, concentrating on the .dts changes.
> > Overall it looks good to me, but I suspect that we will need quite some
> > time to finalize standard bindings as there's lots of small details that
> > need to be taken care of.
>
> Yes. I want to get this forward as it's becoming too much pain to manage
> things without DSS DT support, when the rest of the OMAP platform code is
> using DT.
>
> The most important thing in the DSS DT bindings for now is that they should
> contain enough information so that any future DT bindings changes can be
> handled with a boot-time conversion code.
I'm afraid I can't give you any guarantee here. The bindings will be unstable
for some time, and we'll have to deal with that somehow.
> Actually, even the endpoint/port stuff is extra, as that could be deduced
> even from the "video-source" method I used in earlier DT versions.
>
> > The major point that bothers we, as explained in my reply to one of the
> > patches, is that I feel like the multi-device model (virtual DSS core +
> > DSS modules) might not accurately represent the hardware. Departing from
> > it probably sounds scary but might not be such a large change.
>
> There are actually two separate things here. One is the multi-device model,
> having separate device for each DSS submodule. The other is having the
> 'omapdss' "virtual" platform device.
>
> Note that the "dss_core" device is a real HW block, and depicted as the
> "dss" node in DT data, whereas "omapdss" device is not present in the DT
> data, and is created dynamically at boot time.
That's a distinction I've missed.
> The omapdss device is a legacy thing, but nowadays it is mainly used to pass
> platform data. Removing omapdss device is not easy, but the only questions
> around that is how to implement the required platform-data functionalities,
> and it doesn't affect the DT data.
The omapdss platform data structure contains the following fields
- get_context_loss_count: What is that used for ?
- num_devices, devices, default_device: What are those used for ?
- default_display_name: This should be easy to move to DT.
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
What's their purpose, and how are they implemented on platforms that make use
of them ? Is the pinmux API an option ?
- set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
solution is needed here.
- version: Given that we detect the DSS revision based on the SoC revision,
I'm tempted to either explicitly encode the DSS revision in the compatible
string, or let the DSS driver query the SoC revision somehow. The later is
considered as a layering violation, but let's face it, I can't see the DSS
being used on a non-OMAP platform.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Geert Uytterhoeven @ 2013-12-13 8:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tomi Valkeinen,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Fbdev development list,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <1703598.NbqXAMAFOI@avalon>
On Fri, Dec 13, 2013 at 4:45 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> > That's great, and I fully support that. This also calls for refactoring
>> > the V4L2 DT bindings and support code to share them with display devices.
>> > A bikeshedding question is where to put the common code.
>>
>> Thanks very much for review!
>>
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Or reshuffle the various graphics/video/fb/console directories (more
bikeshedding). With git it's not that painful.
Frame buffer devices ended up in drivers/video because at that time, graphics
cards were called video cards. Moving video only entered the picture later.
drivers/fb/ (currently most of drivers/video/)
drivers/console/ (currently drivers/video/console/)
...
Or should fb be under gpu?
What about drivers/media? Video and audio are multi-media, too...
Baah, bad idea... too much bikeshedding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-12-13 8:40 UTC (permalink / raw)
To: Archit Taneja, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge,
Tony Lindgren
In-Reply-To: <52AAC615.504@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
On 2013-12-13 10:32, Archit Taneja wrote:
> On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
>> On 2013-12-12 01:10, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>>> omapdss driver uses a omapdss platform device to pass platform specific
>>>> function pointers and DSS hardware version from the arch code to the
>>>> driver. This device is needed also when booting with DT.
>>>>
>>>> This patch adds omapdss_init_of() function, called from
>>>> board-generic at
>>>> init time, which creates the omapdss device.
>>>
>>> Is this a temporary solution that you plan to later replace with DT-only
>>> device instantiation ?
>>
>> It's a long term task to remove the "virtual" omapdss device. Removing
>> the platform data that we pass has been very difficult.
>
> Even if we remove the platform data, what would be the right place to
> register the drm, fb and vout devices? We need to make sure their
> drivers are probed only after omapdss is initialised.
That's the same issue as we have already, so removing omapdss doesn't
affect that.
I don't think we have any good way to ensure those devices are not
probed before omapdss. We just have to manage the case that omapdss has
not been probed yet, by checking if omapdss is there and if not, return
EPROBE_DEFER.
>> For example, we need to get the OMAP revision to know which OMAP DSS
>> hardware we have. We can't get that information from the DSS hardware
>> (thank you, HW designers! ;).
>>
>
>> Another is DSI pin muxing. I think we need a new pinmuxing driver for
>> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
>> very simple, but the register fields are varying lengths and at varying
>> positions, so pinmux-single doesn't work for it.
>
> I have seen other OMAP drivers passing control module register info to
> their DT node. Instead of having a pinmux driver for a single register,
> we might want to consider just passing the control module register, and
> take care of the reg fields and masks in the OMAP DSI driver itself.
Yes, that's also one option. Quite ugly, though =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Archit Taneja @ 2013-12-13 8:44 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge,
Tony Lindgren
In-Reply-To: <52A96603.5030709@ti.com>
On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
> On 2013-12-12 01:10, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>> omapdss driver uses a omapdss platform device to pass platform specific
>>> function pointers and DSS hardware version from the arch code to the
>>> driver. This device is needed also when booting with DT.
>>>
>>> This patch adds omapdss_init_of() function, called from board-generic at
>>> init time, which creates the omapdss device.
>>
>> Is this a temporary solution that you plan to later replace with DT-only
>> device instantiation ?
>
> It's a long term task to remove the "virtual" omapdss device. Removing
> the platform data that we pass has been very difficult.
Even if we remove the platform data, what would be the right place to
register the drm, fb and vout devices? We need to make sure their
drivers are probed only after omapdss is initialised.
>
> For example, we need to get the OMAP revision to know which OMAP DSS
> hardware we have. We can't get that information from the DSS hardware
> (thank you, HW designers! ;).
>
> Another is DSI pin muxing. I think we need a new pinmuxing driver for
> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
> very simple, but the register fields are varying lengths and at varying
> positions, so pinmux-single doesn't work for it.
I have seen other OMAP drivers passing control module register info to
their DT node. Instead of having a pinmux driver for a single register,
we might want to consider just passing the control module register, and
take care of the reg fields and masks in the OMAP DSI driver itself.
The parsing of the DSI pins from DT, however, can be kept generic.
Archit
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-12-13 9:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <14299863.f0rzOyPfdL@avalon>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On 2013-12-13 05:24, Laurent Pinchart wrote:
> Right. The real question is whether the DSI or HDMI IPs can be used in a
> system without the DSS core. If not, it might make sense to just merge the
> drivers into a single module (of course with a clear interface between the
> different parts to avoid spaghetti code).
The drivers are already in single kernel module, omapdss.ko.
The HDMI IP is used on another SoC, without DSS. They have their own
display architecture. DSI IP might need some small modifications to work
without DSS, but not much. It doesn't have any strict DSS/DISPC
dependencies.
> Given that the DSS core has a set of registers not dedicated to any of the
> submodules I believe it should be represented by a device. The omapdss driver
> thus doesn't look virtual to me, it supports a real piece of hardware.
As noted in another mail, dss_core and omapdss devices are different
things. dss_core is not virtual, omapdss is.
>> But then, I feel that they are quite independent and probably should be
>> separate devices.
>
> Even if they're separate devices they could be instantiated by DSS core based
> on DT nodes. I'm not sure whether that's the best idea, but it might be worth
> thinking about it.
What would be the difference to the one in this series? In this series,
the submodules are instantiated automatically by the driver framework.
The only difference I see is that the submodule devices would
appear/disappear dynamically, but... what would be the benefit?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
From: Archit Taneja @ 2013-12-13 9:39 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
In-Reply-To: <1386160133-24026-17-git-send-email-tomi.valkeinen@ti.com>
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 91 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5fc3f43c5a81..e3048f849612 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -550,3 +550,94 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +
> + dsi1_out_ep: endpoint {
> + remote-endpoint = <&lcd0_in>;
> + lanes = <0 1 2 3 4 5>;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
> + };
> +
> + lcd0: display@0 {
> + compatible = "tpo,taal", "panel-dsi-cm";
> +
> + gpios = <&gpio4 6 0>; /* 102, reset */
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> + };
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Archit
^ permalink raw reply
* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
From: Tomi Valkeinen @ 2013-12-13 9:39 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
In-Reply-To: <52AAD2F1.2040208@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
On 2013-12-13 11:27, Archit Taneja wrote:
> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap4-sdp.dts | 91
>> +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 91 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>> b/arch/arm/boot/dts/omap4-sdp.dts
>> index 5fc3f43c5a81..e3048f849612 100644
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -550,3 +550,94 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dsi1 {
>> + vdds_dsi-supply = <&vcxio>;
>> +
>> + dsi1_out_ep: endpoint {
>> + remote-endpoint = <&lcd0_in>;
>> + lanes = <0 1 2 3 4 5>;
>
> In the previous revision omapdss DT patchset, the lanes node was a
> member of the panel DT node, and not the dsi DT node. Any reason to
> change this? Does it make more sense this way?
Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.
In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.
My reasoning where a property belongs to:
If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.
If a property is about the link between two devices, like "lanes" here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.
> I suppose it's more suitable for dsi to hold the property if 2 panels
> are connected on the same bus. Say, one with 4 data lanes, and other
> with 2. It would be tricky for the dsi driver to get lane params from 2
> different places and merge them somehow.
It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.
If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.
But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.
>> + };
>> +
>> + lcd0: display@0 {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> +
>> + gpios = <&gpio4 6 0>; /* 102, reset */
>> +
>> + lcd0_in: endpoint {
>> + remote-endpoint = <&dsi1_out_ep>;
>> + };
>> + };
>
> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
> respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
From: Archit Taneja @ 2013-12-13 9:58 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
In-Reply-To: <52AAD5CE.3010609@ti.com>
On Friday 13 December 2013 03:09 PM, Tomi Valkeinen wrote:
> On 2013-12-13 11:27, Archit Taneja wrote:
>> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 91
>>> +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 91 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5fc3f43c5a81..e3048f849612 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -550,3 +550,94 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dsi1 {
>>> + vdds_dsi-supply = <&vcxio>;
>>> +
>>> + dsi1_out_ep: endpoint {
>>> + remote-endpoint = <&lcd0_in>;
>>> + lanes = <0 1 2 3 4 5>;
>>
>> In the previous revision omapdss DT patchset, the lanes node was a
>> member of the panel DT node, and not the dsi DT node. Any reason to
>> change this? Does it make more sense this way?
>
> Well, the lane configuration is programmed into the DSI HW. So DSI needs
> to know them. Thus the lanes can be considered a property of the DSI.
>
> In some cases, the external encoder or panel also needs to know about
> the lanes. In that case, both DSI and the encoder/panel would contain
> the same data.
>
> My reasoning where a property belongs to:
>
> If a property is clearly internal to a device, it belongs there. For
> example, in this case vdds_dsi-supply is clearly a property of the DSI.
>
> If a property is about the link between two devices, like "lanes" here,
> it belongs to both devices. If a device does not need that data for
> anything, it can be omitted.
>
>> I suppose it's more suitable for dsi to hold the property if 2 panels
>> are connected on the same bus. Say, one with 4 data lanes, and other
>> with 2. It would be tricky for the dsi driver to get lane params from 2
>> different places and merge them somehow.
>
> It doesn't matter, both would work fine. If the lanes property is in the
> DSI node, then the DSI driver finds out the lane config by finding out
> which endpoint is used for the panel that's being enabled.
>
> If the lanes property would be in the panel, the panel would pass the
> lane config to the DSI when it's enabled.
>
> But I think passing the lane config from panel to DSI (like we do
> currently) is not so nice.
Okay, that makes sense.
>
>>> + };
>>> +
>>> + lcd0: display@0 {
>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>> +
>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>> +
>>> + lcd0_in: endpoint {
>>> + remote-endpoint = <&dsi1_out_ep>;
>>> + };
>>> + };
>>
>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>> respectively? I don't see this for panels on other boards.
>
> Yes. The panels are _controlled_ with DSI. We model the child-parent
> relationships in DT data based on the control. So an i2c peripheral is
> controlled via i2c master, and is thus a child of the i2c master. Same
> here. The ports/endpoints are used to define the data path, which is
> separate thing from the control path.
>
> DPI panels which don't have any way to control them (except basic things
> like gpios) are platform devices without any parent.
>
> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
> master.
Ah, I thought the port/endpoint stuff had something to do with this. I
forgot about the parent-child relationship for the control path.
In that case, for the sake of accuracy, the dsi-cm panel could get the
"in" parameter via the parent node wherever it's used for control, like
setting a DCS command for sleep out. And via
omapdss_of_find_source_for_first_ep() when it's used to start data
transfer, even though both the "in's" are finally the same dsi device?
Archit
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Tomi Valkeinen @ 2013-12-13 10:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <1703598.NbqXAMAFOI@avalon>
[-- Attachment #1: Type: text/plain, Size: 4702 bytes --]
On 2013-12-13 05:45, Laurent Pinchart wrote:
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Right, that's what I meant.
>> I also don't supply the same data for both endpoints, when the data is about
>> the link. E.g. I think the V4L2 binding doc suggests to supply things like
>> bus-width for both endpoints. I only supply the data for the endpoint that
>> uses that data. With some encoders/panels the same data could be needed on
>> both ends, but not in these patches.
>
> How do you handle the situation where the two drivers (for each end of the
> link) need to know the bus width for instance ?
Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
That's what I mean with "I only supply the data for the endpoint that
uses that data". If both ends use the data, I supply it for both.
>> The most important thing in the DSS DT bindings for now is that they should
>> contain enough information so that any future DT bindings changes can be
>> handled with a boot-time conversion code.
>
> I'm afraid I can't give you any guarantee here. The bindings will be unstable
> for some time, and we'll have to deal with that somehow.
I'm not asking for a guarantee. Just "yes, feels fine" =).
> The omapdss platform data structure contains the following fields
>
> - get_context_loss_count: What is that used for ?
To find out if a HW block has been turned off and it has lost its
registers contents. It's an optimization, without it we need to restore
registers each time when runtime_resume() hook is called.
However, that's on its way out. I've already made new PM code for dispc
which doesn't use that. But I can't merge it before omapdrm has been
fixed to properly set things up when enabling a display.
> - num_devices, devices, default_device: What are those used for ?
Nothing anymore. They can be removed.
> - default_display_name: This should be easy to move to DT.
How? I handled it so that I assign the aliases for displays, and
display0 is always the default display. "default display name" is not
really a hw property =).
I think this should not be used for DT, and just use the display0 as
default (if we use aliases). If we don't use aliases, and instead use
the label properties as discussed in other thread, then there has to be
some other mechanism to tell which display should be used.
> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
> What's their purpose, and how are they implemented on platforms that make use
> of them ? Is the pinmux API an option ?
They are used in mainline, grep again =). They set pinmuxing for DSI.
Pinmux API is an option, but I think it would require a new driver. The
DSI pins for DSI1 and DSI2 are configured in a single register, where
the fields go in seemingly random order with varying widths.
pinmux-single cannot be used.
> - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
> solution is needed here.
>
> - version: Given that we detect the DSS revision based on the SoC revision,
> I'm tempted to either explicitly encode the DSS revision in the compatible
> string, or let the DSS driver query the SoC revision somehow. The later is
> considered as a layering violation, but let's face it, I can't see the DSS
> being used on a non-OMAP platform.
I also would just use the compatible string, but we need to separate
between different OMAP ES versions. Doing that would mean we'd need
different .dtsi and .dts files for the different OMAP ES versions. It
would be a mess.
I have a TODO item to study this. There are only a few things that are
problematic (changed between ES versions without changing DSS HW
revision). If I can find a way around those, the compatible string
should be enough.
One example is the width of a blanking interval. Newer OMAP3 revisions
have a slightly wider field. I didn't try, but maybe I can write 1-bits
to the register, then read it, and if only part of those 1 bits "stick",
I know it's an old revision.
Anyway, I think this platform data thing is not strictly related. None
of these items affect the DT data (except the pinmuxing, but I think
it's fine to add that later). So while the above issues need to be fixed
at some point, I think they don't affect this series (well, the default
display is there which may affect).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
From: Tomi Valkeinen @ 2013-12-13 10:15 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
In-Reply-To: <52AADA55.20309@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]
On 2013-12-13 11:58, Archit Taneja wrote:
>>>> + };
>>>> +
>>>> + lcd0: display@0 {
>>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>>> +
>>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>>> +
>>>> + lcd0_in: endpoint {
>>>> + remote-endpoint = <&dsi1_out_ep>;
>>>> + };
>>>> + };
>>>
>>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>>> respectively? I don't see this for panels on other boards.
>>
>> Yes. The panels are _controlled_ with DSI. We model the child-parent
>> relationships in DT data based on the control. So an i2c peripheral is
>> controlled via i2c master, and is thus a child of the i2c master. Same
>> here. The ports/endpoints are used to define the data path, which is
>> separate thing from the control path.
>>
>> DPI panels which don't have any way to control them (except basic things
>> like gpios) are platform devices without any parent.
>>
>> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
>> master.
>
> Ah, I thought the port/endpoint stuff had something to do with this. I
> forgot about the parent-child relationship for the control path.
>
> In that case, for the sake of accuracy, the dsi-cm panel could get the
> "in" parameter via the parent node wherever it's used for control, like
> setting a DCS command for sleep out. And via
> omapdss_of_find_source_for_first_ep() when it's used to start data
> transfer, even though both the "in's" are finally the same dsi device?
Don't mix the DT data and the current driver =). The current driver does
not handle things properly. The driver still uses the current model,
where we don't have separate control and data path handling. I.e. both
control and data are handled via the single API, using the "in" field.
The important thing with this DT data is that in the future we can
change the driver model, if we so want, to manage data and control
separately. Or maybe add a DSI bus, as has been proposed elsewhere.
It's true that we could change the driver as you describe, but I don't
think it helps anything, as the current model in the driver only has a
single control-data path.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-12-13 10:18 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <1933495.zHe4JMYZyB@avalon>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On 2013-12-13 05:27, Laurent Pinchart wrote:
> Hi Tony,
>
> On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
>> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
>>> On 2013-12-12 01:44, Laurent Pinchart wrote:
>>>
>>> So, are they independent? I don't know =). I think they lean on the
>>> independent side. dss_core is always needed for the submodules to work,
>>> but for example DSI could be used without DISPC, using system DMA to
>>> transfer data from memory to DSI. Not a very useful thing to do, but
>>> still, there are dedicated DMA channels for that.
>>
>> If they have separate hwmod entries, they should be considered separate
>> independent devices for sure.
>>
>> To summarize, here are few reasons why they need to be treated as
>> separate devices:
>
> Are you talking generally here, or about the DSS modules in particular ?
>
>> 1. The modules maybe clocked/powered/idled separately and can have their
>> own idle configuration so they can do the hardware based idling
>> separately.
>
> I don't think this applies to the DSS modules.
The DSS submodules have their own SYSCONFIG register, and idle settings
can be set per module. So I think they idle separately, even if they are
in a common power domain.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
From: Tomi Valkeinen @ 2013-12-13 12:01 UTC (permalink / raw)
To: Sebastian Reichel, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Florian Vaussard
In-Reply-To: <52A9C470.2030102@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
On 2013-12-12 16:13, Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
>> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>>> A label property is still an option.
>>>
>>> Hmm, what do you mean? Label as in:
>>>
>>> foo : node {
>>> };
>>>
>>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>>
>> Some driver use a "label" property like this:
>>
>> foo : node {
>> label = "lcd";
>>
>> ...
>> };
>>
>> See for example
>>
>> Documentation/devicetree/bindings/leds/common.txt
>> Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
I came to the conclusion that it's better to add the label to keep
backward compatibility, especially as it was very easy to add.
So we'll have 'name' and 'alias' for each display (as we have already).
In the current non-DT boot (which is going away):
- 'alias' is created by omapdss dynamically (first display to be
registered is display0, etc.)
- 'name' comes from platform data
In the DT boot:
- 'alias' comes from the DT aliases node, or if there are no display
aliases, it's created the same way as to non-DT. The code presumes that
there either is a DT alias for all displays, or there are none.
- 'name' comes from 'label' property
In both non-DT and DT cases, if 'name' is NULL (i.e. not set in platform
data or no 'label' property), the alias is used as a name.
I think this works fine, and was a trivial change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch 1/2] video: mmp: delete a stray mutex_unlock()
From: Dan Carpenter @ 2013-12-13 13:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20131114081918.GB8150@elgon.mountain>
Ping.
regards,
dan carpenter
On Thu, Nov 14, 2013 at 11:19:18AM +0300, Dan Carpenter wrote:
> We aren't holding the disp_lock so we shouldn't release it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
> index 84de263..c8d4265 100644
> --- a/drivers/video/mmp/core.c
> +++ b/drivers/video/mmp/core.c
> @@ -173,7 +173,7 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
> + sizeof(struct mmp_overlay) * info->overlay_num;
> path = kzalloc(size, GFP_KERNEL);
> if (!path)
> - goto failed;
> + return NULL;
>
> /* path set */
> mutex_init(&path->access_ok);
> @@ -219,11 +219,6 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
>
> mutex_unlock(&disp_lock);
> return path;
> -
> -failed:
> - kfree(path);
> - mutex_unlock(&disp_lock);
> - return NULL;
> }
> EXPORT_SYMBOL_GPL(mmp_register_path);
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Laurent Pinchart @ 2013-12-13 14:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52AADBE0.3030203@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5366 bytes --]
Hi Tomi,
On Friday 13 December 2013 12:05:20 Tomi Valkeinen wrote:
> On 2013-12-13 05:45, Laurent Pinchart wrote:
> >> I know drivers/video is in practice "fbdev", but drivers/video (the
> >> words) sound like the best place for things related to video.
> >
> > That's an option as well, but I'm not sure I like the idea of mixing fbdev
> > and generic video in a single directory. We could use a subdirectory of
> > drivers/video.
>
> Right, that's what I meant.
>
> >> I also don't supply the same data for both endpoints, when the data is
> >> about the link. E.g. I think the V4L2 binding doc suggests to supply
> >> things like bus-width for both endpoints. I only supply the data for the
> >> endpoint that uses that data. With some encoders/panels the same data
> >> could be needed on both ends, but not in these patches.
> >
> > How do you handle the situation where the two drivers (for each end of the
> > link) need to know the bus width for instance ?
>
> Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
> That's what I mean with "I only supply the data for the endpoint that
> uses that data". If both ends use the data, I supply it for both.
That sounds good to me.
> >> The most important thing in the DSS DT bindings for now is that they
> >> should contain enough information so that any future DT bindings changes
> >> can be handled with a boot-time conversion code.
> >
> > I'm afraid I can't give you any guarantee here. The bindings will be
> > unstable for some time, and we'll have to deal with that somehow.
>
> I'm not asking for a guarantee. Just "yes, feels fine" =).
>
> > The omapdss platform data structure contains the following fields
> >
> > - get_context_loss_count: What is that used for ?
>
> To find out if a HW block has been turned off and it has lost its
> registers contents. It's an optimization, without it we need to restore
> registers each time when runtime_resume() hook is called.
>
> However, that's on its way out. I've already made new PM code for dispc
> which doesn't use that. But I can't merge it before omapdrm has been
> fixed to properly set things up when enabling a display.
OK.
> > - num_devices, devices, default_device: What are those used for ?
>
> Nothing anymore. They can be removed.
>
> > - default_display_name: This should be easy to move to DT.
>
> How? I handled it so that I assign the aliases for displays, and
> display0 is always the default display. "default display name" is not
> really a hw property =).
>
> I think this should not be used for DT, and just use the display0 as
> default (if we use aliases). If we don't use aliases, and instead use
> the label properties as discussed in other thread, then there has to be
> some other mechanism to tell which display should be used.
Another option would be to add a phandle that references the default display.
I don't have a strong preference at the moment.
> > - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> > mainline. What's their purpose, and how are they implemented on platforms
> > that make use of them ? Is the pinmux API an option ?
>
> They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
> They set pinmuxing for DSI. Pinmux API is an option, but I think it would
> require a new driver. The DSI pins for DSI1 and DSI2 are configured in a
> single register, where the fields go in seemingly random order with varying
> widths. pinmux-single cannot be used.
Or, as Archit mentioned, we could pass the SYSCONF registers as resources.
That might not be very clean though.
> > - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a
> > generic solution is needed here.
> >
> > - version: Given that we detect the DSS revision based on the SoC
> > revision, I'm tempted to either explicitly encode the DSS revision in the
> > compatible string, or let the DSS driver query the SoC revision somehow.
> > The later is considered as a layering violation, but let's face it, I
> > can't see the DSS being used on a non-OMAP platform.
>
> I also would just use the compatible string, but we need to separate between
> different OMAP ES versions. Doing that would mean we'd need different .dtsi
> and .dts files for the different OMAP ES versions. It would be a mess.
>
> I have a TODO item to study this. There are only a few things that are
> problematic (changed between ES versions without changing DSS HW revision).
> If I can find a way around those, the compatible string should be enough.
>
> One example is the width of a blanking interval. Newer OMAP3 revisions have
> a slightly wider field. I didn't try, but maybe I can write 1-bits to the
> register, then read it, and if only part of those 1 bits "stick", I know
> it's an old revision.
>
> Anyway, I think this platform data thing is not strictly related. None of
> these items affect the DT data (except the pinmuxing, but I think it's fine
> to add that later). So while the above issues need to be fixed at some
> point, I think they don't affect this series (well, the default display is
> there which may affect).
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Tomi Valkeinen @ 2013-12-13 15:47 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Stefan Roese, Sebastian Reichel, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <3426377.keoaFgiZkl@avalon>
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
>>> mainline. What's their purpose, and how are they implemented on platforms
>>> that make use of them ? Is the pinmux API an option ?
>>
>> They are used in mainline, grep again =).
>
> The only implementations I can find in arch/arm/mach-omap2/display.c are
>
> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> {
> return 0;
> }
>
> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> {
> }
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Tony Lindgren @ 2013-12-13 17:07 UTC (permalink / raw)
To: Archit Taneja
Cc: Tomi Valkeinen, Laurent Pinchart, linux-omap, linux-fbdev,
devicetree, Darren Etheridge
In-Reply-To: <52AAC615.504@ti.com>
* Archit Taneja <archit@ti.com> [131213 00:33]:
>
> I have seen other OMAP drivers passing control module register info
> to their DT node. Instead of having a pinmux driver for a single
> register, we might want to consider just passing the control module
> register, and take care of the reg fields and masks in the OMAP DSI
> driver itself.
See the PBIAS control module patches and their comments from Balaji.
We can map the misc registers of SCM using drivers/mfd/syscon.c and
that way drivers can access them via syscon.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tony Lindgren @ 2013-12-13 17:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge
In-Reply-To: <52AADEF3.9040808-l0cyMroinI0@public.gmane.org>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 02:19]:
> On 2013-12-13 05:27, Laurent Pinchart wrote:
> > Hi Tony,
> >
> > On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> >> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> >>> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >>>
> >>> So, are they independent? I don't know =). I think they lean on the
> >>> independent side. dss_core is always needed for the submodules to work,
> >>> but for example DSI could be used without DISPC, using system DMA to
> >>> transfer data from memory to DSI. Not a very useful thing to do, but
> >>> still, there are dedicated DMA channels for that.
> >>
> >> If they have separate hwmod entries, they should be considered separate
> >> independent devices for sure.
> >>
> >> To summarize, here are few reasons why they need to be treated as
> >> separate devices:
> >
> > Are you talking generally here, or about the DSS modules in particular ?
> >
> >> 1. The modules maybe clocked/powered/idled separately and can have their
> >> own idle configuration so they can do the hardware based idling
> >> separately.
> >
> > I don't think this applies to the DSS modules.
>
> The DSS submodules have their own SYSCONFIG register, and idle settings
> can be set per module. So I think they idle separately, even if they are
> in a common power domain.
Yes. Please see the current omap_hwmod_*_data.c files, if they are separate
entries there, that means we need to treat them as separate devices to
avoid the issues I listed.
We do have some entries still missing from omap_hwmod_*_data.c files, like
the SSI entries as they are undocumented. But for the existing ones there
please follow the same layout for the .dts entries.
Regards,
Tony
^ 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