* Re: [PATCH 1/3] Documentation: DT: Add entry for FSL LS1012A RDB, FRDM, QDS boards
From: Rob Herring @ 2016-11-14 23:35 UTC (permalink / raw)
To: Harninder Rai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, Bhaskar Upadhaya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478714651-12679-1-git-send-email-harninder.rai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 09, 2016 at 11:34:11PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels
From: Laurent Pinchart @ 2016-11-14 23:39 UTC (permalink / raw)
To: dri-devel
Cc: Laurent Pinchart, devicetree@vger.kernel.org,
open list:MEDIA DRIVERS FOR RENESAS - FCP, Tomi Valkeinen,
linux-media@vger.kernel.org
In-Reply-To: <1488637.i0jADhlNmg@avalon>
Hi Rob,
Ping ?
On Monday 17 Oct 2016 15:42:56 Laurent Pinchart wrote:
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> > On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> >> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >>> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> >>>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>>> Multiple incompatible data link layers have been used over time to
> >>>> transmit image data to LVDS panels. This binding supports display
> >>>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> >>>> specifications.
> >>>>
> >>>> Signed-off-by: Laurent Pinchart
> >>>> <laurent.pinchart+renesas@ideasonboard.com>
> >>>> ---
> >>>>
> >>>> .../bindings/display/panel/panel-lvds.txt | 119 ++++++++++++
> >>>> 1 file changed, 119 insertions(+)
> >>>> create mode 100644
> >>>> Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>>> new file mode 100644
> >>>> index 000000000000..250861f2673e
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>>> @@ -0,0 +1,119 @@
> >>>> +Generic LVDS Panel
> >>>> +==================
> >>>> +
> >>>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>>> Multiple
> >>>> +incompatible data link layers have been used over time to transmit
> >>>> image data
> >>>> +to LVDS panels. This bindings supports display panels compatible with
> >>>> the
> >>>> +following specifications.
> >>>> +
> >>>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> >>>> February
> >>>> +1999 (Version 1.0), Japan Electronic Industry Development Association
> >>>> (JEIDA)
> >>>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95),
> >>>> National
> >>>> +Semiconductor
> >>>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> >>>> Video
> >>>> +Electronics Standards Association (VESA)
> >>>> +
> >>>> +Device compatible with those specifications have been marketed under
> >>>> the
> >>>> +FPD-Link and FlatLink brands.
> >>>> +
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: shall contain "panel-lvds"
> >>>
> >>> Maybe as a fallback, but on its own, no way.
> >>
> >> Which brings an interesting question: when designing generic DT
> >> bindings, what's the rule regarding
>
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?
>
> For instance (but perhaps not the best example), the
> input/rotary-encoder.txt bindings define a "rotary-encoder" compatible
> string, with no other bindings defining more precise compatible strings for
> the exact rotary encoder model. When it comes to panels I believe it makes
> sense to define model-specific compatible strings even if they're unused by
> drivers. I'm however wondering what the rule is there, and where those
> device-specific compatible strings should be defined. I'd like to avoid
> using one file per panel model as done today for the simple-panel bindings.
>
> > Call it "simple" so I can easily NAK it. :)
> >
> > Define a generic structure, not a single binding trying to serve all.
> >
> >>> > +- width-mm: panel display width in millimeters
> >>> > +- height-mm: panel display height in millimeters
> >>>
> >>> This is already documented for all panels IIRC.
> >>
> >> Note that this DT binding has nothing to do with the simple-panel
> >> binding. It is instead similar to the panel-dpi and panel-dsi-cm bindings
> >> (which currently don't but should specify the panel size in DT). The LVDS
> >> panel driver will *not* include any panel-specific information such as
> >> size or timings, these are specified in DT.
> >
> > The panel bindings aren't really different. The biggest difference was
> > location in the tree, but we now generally allow panels to be either a
> > child of the LCD controller or connected with OF graph. We probably
> > need to work on restructuring the panel bindings a bit. We should have
> > an inheritance with a base panel binding of things like size, label,
> > graph, backlight, etc, then perhaps an interface specific bindings for
> > LVDS, DSI, and parallel, then a panel specific binding. With this the
> > panel specific binding is typically just a compatible string and which
> > inherited properties apply to it.
>
> That sounds good to me, but we have multiple models for panel bindings.
>
> As you mentioned panels can be referenced through an LCD controller node
> property containing a phandle to the panel node, or through OF graph. That's
> a situation we have today, and we need to keep supporting both (at least
> for existing panels, perhaps not for the new ones).
>
> Another difference is how to express panel data such as size and timings.
> The simple-panel DT bindings don't contain such data and expects the
> drivers to contain a table of panel data for all models supported, while
> the DPI, DSI and now the proposed LVDS panel bindings contain properties
> for panel data.
>
> How would you like to reconcile all that ?
>
> >>>> +- data-mapping: the color signals mapping order, "jeida-18",
> >>>> "jeida-24"
> >>>> + or "vesa-24"
> >>>
> >>> Maybe this should be part of the compatible.
> >>
> >> I've thought about it, but given that some panels support selecting
> >> between multiple modes (through a mode pin that is usually hardwired), I
> >> believe a separate DT property makes sense.
> >
> > Okay.
> >
> >> Furthermore, LVDS data organization is controlled by the combination of
> >> both data-mapping and data-mirror. It makes little sense from my point
> >> of view to handle one as part of the compatible string and the other one
> >> as a separate property.
> >>
> >>> > +Optional properties:
> >>> > +- label: a symbolic name for the panel
> >>>
> >>> Could be for any panel or display connector.
> >>
> >> Yes, but I'm not sure to understand how that's relevant :-)
> >
> > Meaning it should be a common property.
>
> Sure. So you expect me to reorganize all the panels and connectors DT
> bindings in order to get this one merged ? :-)
>
> >>>> +- avdd-supply: reference to the regulator that powers the panel
> >>>> analog supply
> >>>> +- dvdd-supply: reference to the regulator that powers the panel
> >>>> digital supply
> >>>
> >>> Which one has to be powered on first, what voltage, and with what time
> >>> in between? This is why "generic" or "simple" bindings don't work.
> >>
> >> The above-mentioned specifications also define connectors, pinouts and
> >> power supplies, but many LVDS panels compatible with the LVDS physical
> >> and data layers use a different connector with small differences in
> >> power
> >> supplies.
> >>
> >> I believe the voltage is irrelevant here, it doesn't need to be
> >> controlled by the operating system. Power supplies order and timing is
> >> relevant, I'll investigate the level of differences between panels. I'm
> >> also fine with dropping those properties for now.
> >
> > Whether you have control of the supplies is dependent on the board.
> > Dropping them is just puts us in the simple binding trap. The simple
> > bindings start out that way and then people keep adding to them.
>
> Damn, you can't be fooled easily ;-)
>
> On a more serious note, I'd like to design the bindings in a way that
> wouldn't require adding device-specific code in the driver for each panel
> model, given that in most cases power supply handling will be generic.
> What's your opinion about a generic power supply model that would be used
> in the default case, with the option to override it with device-specific
> code when needed ?
>
> >>>> +- data-mirror: if set, reverse the bit order on all data lanes (6 to
> >>>> 0 instead
> >>>> + of 0 to 6)
> >
> > On this one, make the name describe the order. "mirror" requires that
> > I know what is normal ordering. Perhaps "data-msb-first".
>
> Sounds good to me, I'll use that.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: DT: add LS1012A compatible for SCFG and DCFG
From: Rob Herring @ 2016-11-15 0:03 UTC (permalink / raw)
To: Harninder Rai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, Bhaskar Upadhaya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478714679-12724-1-git-send-email-harninder.rai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 09, 2016 at 11:34:39PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: clockgen: Add compatible string for LS1012A
From: Rob Herring @ 2016-11-15 0:03 UTC (permalink / raw)
To: Harninder Rai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, Bhaskar Upadhaya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478715053-12790-1-git-send-email-harninder.rai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 09, 2016 at 11:40:53PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 01/30] usb: dwc2: Deprecate g-use-dma binding
From: Rob Herring @ 2016-11-15 0:05 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Caesar Wang, Shawn Lin,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Russell King,
Matthias Brugger, Wei Xu, Eduardo Valentin, Andy Yan,
Mark Rutland, Will Deacon, Catalin Marinas, Heiko Stuebner
In-Reply-To: <966d342a5a7fee9ac3ef8140b60c228c4a87c7d3.1478748145.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, Nov 09, 2016 at 07:27:40PM -0800, John Youn wrote:
> This is not needed as the gadget now fully supports DMA and it can
> autodetect it. This was initially added because gadget DMA mode was only
> partially implemented so could not be automatically enabled.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 4 +++-
> arch/arm/boot/dts/rk3036.dtsi | 1 -
> arch/arm/boot/dts/rk3288.dtsi | 1 -
> arch/arm/boot/dts/rk3xxx.dtsi | 1 -
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 -
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
> drivers/usb/dwc2/core.h | 4 +---
> drivers/usb/dwc2/params.c | 17 ++++++++++++++---
> drivers/usb/dwc2/pci.c | 1 -
> 9 files changed, 18 insertions(+), 13 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 02/14] clk: qcom: Move all sdcc rcgs to use clk_rcg2_floor_ops
From: Jeremy McNicoll @ 2016-11-15 0:06 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, adrian.hunter, shawn.lin,
sboyd, andy.gross
Cc: devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-3-git-send-email-riteshh@codeaurora.org>
On 2016-11-13 10:00 PM, Ritesh Harjani wrote:
> From: Rajendra Nayak <rnayak@codeaurora.org>
>
> The sdcc driver for msm8996/msm8916/msm8974 and apq8084
> expects a clk_set_rate() on the sdcc rcg clk to set
> a floor value of supported clk rate closest to the requested
> rate, by looking up the frequency table.
> So move all the sdcc rcgs on all these platforms to use the
> newly introduced clk_rcg2_floor_ops
>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> drivers/clk/qcom/gcc-apq8084.c | 8 ++++----
> drivers/clk/qcom/gcc-msm8916.c | 4 ++--
> drivers/clk/qcom/gcc-msm8974.c | 8 ++++----
> drivers/clk/qcom/gcc-msm8996.c | 8 ++++----
Can you please include the same changes for gcc-msm8994.c as it should
be in sboyd's tree?
If not I will send a patch directly, either way works for me.
-jeremy
^ permalink raw reply
* Re: [PATCH v7 00/14] mmc: sdhci-msm: Add clk-rates, DDR, HS400 support
From: Jeremy McNicoll @ 2016-11-15 0:06 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, adrian.hunter, shawn.lin,
sboyd, andy.gross
Cc: devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-1-git-send-email-riteshh@codeaurora.org>
On 2016-11-13 10:00 PM, Ritesh Harjani wrote:
> Hi,
>
> This is v7 version of the patch series which adds support for MSM8996.
> Adds HS400 driver support as well.
> These are tested on internal msm8996 & db410c HW.
>
> Below are the changes in v7.
>
After adding the associated changes to
drivers/clk/qcom/gcc-msm8994.c (2/14) this version of the series work fine
on my Nexus 5X (msm8992). All partitions have been found and can be
mounted as expected. Reading files seems to work as well, I didn't
try writing anything as I didn't want to mess up my phone at this
point.
So,
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
-jeremy
^ permalink raw reply
* Re: [PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
From: Tony Lindgren @ 2016-11-15 0:08 UTC (permalink / raw)
To: Keerthy
Cc: lee.jones, robh+dt, linux-omap, linux-kernel, devicetree,
linux-gpio, nm, t-kristo
In-Reply-To: <1478754560-27923-5-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [161109 21:10]:
> The PMICs have POWERHOLD set by default which prevents PMIC shutdown
> even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
> So to enable pmic power off this property lets one over ride the default
> value and enable pmic power off.
This should not cause merge conflicts so probably best to merge along
with the driver changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If you guys want me to pick up this separately let me know.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property
From: Tony Lindgren @ 2016-11-15 0:09 UTC (permalink / raw)
To: Keerthy
Cc: lee.jones, robh+dt, linux-omap, linux-kernel, devicetree,
linux-gpio, nm, t-kristo
In-Reply-To: <1478754560-27923-6-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [161109 21:10]:
> The PMICs have POWERHOLD set by default which prevents PMIC shutdown
> even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
> So to enable pmic power off this property lets one over ride the default
> value and enable pmic power off.
This too:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
From: Shawn Guo @ 2016-11-15 0:13 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Fabio Estevam
In-Reply-To: <1479138250-17780-3-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 03:44:09PM +0000, Sudeep Holla wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi panels
From: Laurent Pinchart @ 2016-11-15 0:27 UTC (permalink / raw)
To: dri-devel; +Cc: linux-renesas-soc, linux-media, devicetree
The aa104xd12 and aa121td01 panels are LVDS panels, not DPI panels.
Use the correct DT bindings.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi | 3 ++-
arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
Hello,
This patch is an example of how the panel-lvds bindings should be used for
display panels. It isn't meant to be merged upstream at the moment as the
bindings haven't been accepted yet but can already be used as both an example
and a test base for LVDS mode selection.
diff --git a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
index 65cb50f0c29f..238d14bb0ebe 100644
--- a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
@@ -10,10 +10,11 @@
/ {
panel {
- compatible = "mitsubishi,aa104xd12", "panel-dpi";
+ compatible = "mitsubishi,aa104xd12", "panel-lvds";
width-mm = <210>;
height-mm = <158>;
+ data-mapping = "jeida-18";
panel-timing {
/* 1024x768 @65Hz */
diff --git a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
index a07ebf8f6938..04aafd479775 100644
--- a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
@@ -10,10 +10,11 @@
/ {
panel {
- compatible = "mitsubishi,aa121td01", "panel-dpi";
+ compatible = "mitsubishi,aa121td01", "panel-lvds";
width-mm = <261>;
height-mm = <163>;
+ data-mapping = "jeida-18";
panel-timing {
/* 1280x800 @60Hz */
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-15 0:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161114220824.GC4082@atomide.com>
* Tony Lindgren <tony@atomide.com> [161114 14:09]:
> * Tony Lindgren <tony@atomide.com> [161114 12:54]:
> > * Tony Lindgren <tony@atomide.com> [161111 12:27]:
> > > * Linus Walleij <linus.walleij@linaro.org> [161111 12:17]:
> > > > On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > >
> > > > I don't see why this is necessary?
> > >
> > > It's needed because the pin controller driver has not yet
> > > finished it's probe at this point. We end up calling functions
> > > in the device driver where no struct pinctrl_dev is yet known
> > > to the driver. Asking a device driver to do something before
> > > it's probe is done does not quite follow the Linux driver model :)
> > >
> > > > The hogging was placed inside pinctrl_register() so that any hogs
> > > > would be taken before it returns, so nothing else can take it
> > > > before the controller itself has the first chance. This semantic
> > > > needs to be preserved I think.
> > > >
> > > > > + schedule_delayed_work(&pctldev->hog_work,
> > > > > + msecs_to_jiffies(100));
> > > >
> > > > If we arbitrarily delay, something else can go in and take the
> > > > pins used by the hogs before the pinctrl core? That is what
> > > > we want to avoid.
> > > >
> > > > Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms?
> > > > 1 ns?
> > >
> > > Yeah well seems like it should not matter but the race we need
> > > to remove somehow.
> > >
> > > > I'm pretty sure that whatever it is that needs to happen before
> > > > the hog work runs can race with this delayed work under
> > > > some circumstances (such as slow external expanders
> > > > on i2c). It should be impossible for that to happen
> > > > and I don't think it is?
> > >
> > > Yes it's totally possible even with delay set to 0.
> > >
> > > Maybe we could add some trigger on the first consumer request
> > > and if that does not happen use the timer?
> >
> > Below is what I came up with for removing the race for hogs. We
> > can do it by not registering the pctldev until in the deferred
> > work, does that seem OK to you?
>
> Oops, that does not yet work, will have to look into it more.
We need to pass pctldev to the parsers if we want to not add the
the controller to the list until hogs are claimed. Otherwise the
device tree parsers won't find the controller. The patch below has
that added.
Regards,
Tony
8< --------------------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:35 -0700
Subject: [PATCH] pinctrl: core: Use delayed work for hogs
Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.
Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/pinctrl/core.c | 87 ++++++++++++++++++++++++++++----------------
drivers/pinctrl/core.h | 2 +
drivers/pinctrl/devicetree.c | 13 ++++---
drivers/pinctrl/devicetree.h | 5 ++-
4 files changed, 68 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -720,7 +720,8 @@ static struct pinctrl_state *create_state(struct pinctrl *p,
return state;
}
-static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
+static int add_setting(struct pinctrl *p, struct pinctrl_dev *pctldev,
+ struct pinctrl_map const *map)
{
struct pinctrl_state *state;
struct pinctrl_setting *setting;
@@ -744,7 +745,11 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
setting->type = map->type;
- setting->pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
+ if (pctldev)
+ setting->pctldev = pctldev;
+ else
+ setting->pctldev =
+ get_pinctrl_dev_from_devname(map->ctrl_dev_name);
if (setting->pctldev == NULL) {
kfree(setting);
/* Do not defer probing of hogs (circular loop) */
@@ -800,7 +805,8 @@ static struct pinctrl *find_pinctrl(struct device *dev)
static void pinctrl_free(struct pinctrl *p, bool inlist);
-static struct pinctrl *create_pinctrl(struct device *dev)
+static struct pinctrl *create_pinctrl(struct device *dev,
+ struct pinctrl_dev *pctldev)
{
struct pinctrl *p;
const char *devname;
@@ -823,7 +829,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
INIT_LIST_HEAD(&p->states);
INIT_LIST_HEAD(&p->dt_maps);
- ret = pinctrl_dt_to_map(p);
+ ret = pinctrl_dt_to_map(p, pctldev);
if (ret < 0) {
kfree(p);
return ERR_PTR(ret);
@@ -838,7 +844,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
if (strcmp(map->dev_name, devname))
continue;
- ret = add_setting(p, map);
+ ret = add_setting(p, pctldev, map);
/*
* At this point the adding of a setting may:
*
@@ -899,7 +905,7 @@ struct pinctrl *pinctrl_get(struct device *dev)
return p;
}
- return create_pinctrl(dev);
+ return create_pinctrl(dev, NULL);
}
EXPORT_SYMBOL_GPL(pinctrl_get);
@@ -1738,6 +1744,46 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
}
/**
+ * pinctrl_late_init() - finish pin controller device registration
+ * @work: work struct
+ */
+static void pinctrl_late_init(struct work_struct *work)
+{
+ struct pinctrl_dev *pctldev;
+
+ pctldev = container_of(work, struct pinctrl_dev, late_init.work);
+
+ pctldev->p = create_pinctrl(pctldev->dev, pctldev);
+ if (!IS_ERR(pctldev->p)) {
+ kref_get(&pctldev->p->users);
+ pctldev->hog_default =
+ pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(pctldev->hog_default)) {
+ dev_dbg(pctldev->dev,
+ "failed to lookup the default state\n");
+ } else {
+ if (pinctrl_select_state(pctldev->p,
+ pctldev->hog_default))
+ dev_err(pctldev->dev,
+ "failed to select default state\n");
+ }
+
+ pctldev->hog_sleep =
+ pinctrl_lookup_state(pctldev->p,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(pctldev->hog_sleep))
+ dev_dbg(pctldev->dev,
+ "failed to lookup the sleep state\n");
+ }
+
+ mutex_lock(&pinctrldev_list_mutex);
+ list_add_tail(&pctldev->node, &pinctrldev_list);
+ mutex_unlock(&pinctrldev_list_mutex);
+
+ pinctrl_init_device_debugfs(pctldev);
+}
+
+/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
* @dev: parent device for this pin controller
@@ -1766,6 +1812,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
pctldev->driver_data = driver_data;
INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
INIT_LIST_HEAD(&pctldev->gpio_ranges);
+ INIT_DELAYED_WORK(&pctldev->late_init, pinctrl_late_init);
pctldev->dev = dev;
mutex_init(&pctldev->mutex);
@@ -1800,32 +1847,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
goto out_err;
}
- mutex_lock(&pinctrldev_list_mutex);
- list_add_tail(&pctldev->node, &pinctrldev_list);
- mutex_unlock(&pinctrldev_list_mutex);
-
- pctldev->p = pinctrl_get(pctldev->dev);
-
- if (!IS_ERR(pctldev->p)) {
- pctldev->hog_default =
- pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
- if (IS_ERR(pctldev->hog_default)) {
- dev_dbg(dev, "failed to lookup the default state\n");
- } else {
- if (pinctrl_select_state(pctldev->p,
- pctldev->hog_default))
- dev_err(dev,
- "failed to select default state\n");
- }
-
- pctldev->hog_sleep =
- pinctrl_lookup_state(pctldev->p,
- PINCTRL_STATE_SLEEP);
- if (IS_ERR(pctldev->hog_sleep))
- dev_dbg(dev, "failed to lookup the sleep state\n");
- }
-
- pinctrl_init_device_debugfs(pctldev);
+ schedule_delayed_work(&pctldev->late_init, 0);
return pctldev;
@@ -1848,6 +1870,7 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
if (pctldev == NULL)
return;
+ cancel_delayed_work_sync(&pctldev->late_init);
mutex_lock(&pctldev->mutex);
pinctrl_remove_device_debugfs(pctldev);
mutex_unlock(&pctldev->mutex);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -33,6 +33,7 @@ struct pinctrl_gpio_range;
* @p: result of pinctrl_get() for this device
* @hog_default: default state for pins hogged by this device
* @hog_sleep: sleep state for pins hogged by this device
+ * @late_init: delayed work for pin controller to finish registration
* @mutex: mutex taken on each pin controller specific action
* @device_root: debugfs root for this device
*/
@@ -47,6 +48,7 @@ struct pinctrl_dev {
struct pinctrl *p;
struct pinctrl_state *hog_default;
struct pinctrl_state *hog_sleep;
+ struct delayed_work late_init;
struct mutex mutex;
#ifdef CONFIG_DEBUG_FS
struct dentry *device_root;
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -100,11 +100,12 @@ struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
return get_pinctrl_dev_from_of_node(np);
}
-static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
+static int dt_to_map_one_config(struct pinctrl *p,
+ struct pinctrl_dev *pctldev,
+ const char *statename,
struct device_node *np_config)
{
struct device_node *np_pctldev;
- struct pinctrl_dev *pctldev;
const struct pinctrl_ops *ops;
int ret;
struct pinctrl_map *map;
@@ -121,7 +122,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
/* OK let's just assume this will appear later then */
return -EPROBE_DEFER;
}
- pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
+ if (!pctldev)
+ pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
if (pctldev)
break;
/* Do not defer probing of hogs (circular loop) */
@@ -166,7 +168,7 @@ static int dt_remember_dummy_state(struct pinctrl *p, const char *statename)
return dt_remember_or_free_map(p, statename, NULL, map, 1);
}
-int pinctrl_dt_to_map(struct pinctrl *p)
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev)
{
struct device_node *np = p->dev->of_node;
int state, ret;
@@ -233,7 +235,8 @@ int pinctrl_dt_to_map(struct pinctrl *p)
}
/* Parse the node */
- ret = dt_to_map_one_config(p, statename, np_config);
+ ret = dt_to_map_one_config(p, pctldev, statename,
+ np_config);
of_node_put(np_config);
if (ret < 0)
goto err;
diff --git a/drivers/pinctrl/devicetree.h b/drivers/pinctrl/devicetree.h
--- a/drivers/pinctrl/devicetree.h
+++ b/drivers/pinctrl/devicetree.h
@@ -21,7 +21,7 @@ struct of_phandle_args;
#ifdef CONFIG_OF
void pinctrl_dt_free_maps(struct pinctrl *p);
-int pinctrl_dt_to_map(struct pinctrl *p);
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev);
int pinctrl_count_index_with_args(const struct device_node *np,
const char *list_name);
@@ -32,7 +32,8 @@ int pinctrl_parse_index_with_args(const struct device_node *np,
#else
-static inline int pinctrl_dt_to_map(struct pinctrl *p)
+static inline int pinctrl_dt_to_map(struct pinctrl *p,
+ struct pinctrl_dev *pctldev)
{
return 0;
}
--
2.10.2
^ permalink raw reply
* Re: [PATCH v7 11/14] mmc: sdhci-msm: Add HS400 platform support
From: Fengguang Wu @ 2016-11-15 0:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ritesh Harjani, kbuild-all-JC7UmRfGjtg@public.gmane.org,
linux-mmc, Adrian Hunter, Shawn Lin, Stephen Boyd, Andy Gross,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, kdorfman-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
David Griego
In-Reply-To: <CAPDyKFoUiGgXhLtW9-+iAxdV6sy4+wgQfW8P5+VwsqHc3QwkqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 14, 2016 at 04:44:19PM +0100, Ulf Hansson wrote:
>Hi,
>
>On 14 November 2016 at 14:53, kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Venkat,
>>
>> [auto build test ERROR on ulf.hansson-mmc/next]
>> [also build test ERROR on v4.9-rc5]
>> [cannot apply to next-20161114]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
>Here we go...
>
>>
>> url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161114-142815
>> base: https://git.linaro.org/people/ulf.hansson/mmc next
>
>This above is the old tree, here's the new:
>git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>
>Could you please update the path in the build system?
OK, done.
Regards,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-15 0:58 UTC (permalink / raw)
To: Peter Chen
Cc: sboyd-sgV2jX0FEOL9JmXXK+q4OQ, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479107062-15365-2-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
On Mon, Nov 14, 2016 at 03:04:20PM +0800, Peter Chen wrote:
> diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h
> new file mode 100644
> index 0000000..580b5c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
> @@ -0,0 +1,56 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __DTS_IMX6ULL_PINFUNC_H
> +#define __DTS_IMX6ULL_PINFUNC_H
> +
> +#include "imx6ul-pinfunc.h"
> +/*
> + * The pin function ID is a tuple of
> + * <mux_reg conf_reg input_reg mux_mode input_val>
> + */
> +#define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO08 0x00E4 0x0370 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO09 0x00E8 0x0374 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_TX_DATA0__EPDC_SDDO11 0x00F0 0x037C 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_TX_DATA1__EPDC_SDDO12 0x00F4 0x0380 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_TX_EN__EPDC_SDDO13 0x00F8 0x0384 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_TX_CLK__EPDC_SDDO14 0x00FC 0x0388 0x0000 0x9 0x0
> +#define MX6ULL_PAD_ENET2_RX_ER__EPDC_SDDO15 0x0100 0x038C 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_CLK__EPDC_SDCLK 0x0104 0x0390 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_ENABLE__EPDC_SDLE 0x0108 0x0394 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_HSYNC__EPDC_SDOE 0x010C 0x0398 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_VSYNC__EPDC_SDCE0 0x0110 0x039C 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_RESET__EPDC_GDOE 0x0114 0x03A0 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA00__EPDC_SDDO00 0x0118 0x03A4 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA01__EPDC_SDDO01 0x011C 0x03A8 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA02__EPDC_SDDO02 0x0120 0x03AC 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA03__EPDC_SDDO03 0x0124 0x03B0 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA04__EPDC_SDDO04 0x0128 0x03B4 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA05__EPDC_SDDO05 0x012C 0x03B8 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA06__EPDC_SDDO06 0x0130 0x03BC 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA07__EPDC_SDDO07 0x0134 0x03C0 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA14__EPDC_SDSHR 0x0150 0x03DC 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA15__EPDC_GDRL 0x0154 0x03E0 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x0000 0x9 0x0
> +#define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x0000 0x9 0x0
Not sure why the indentation goes bad from here. I fixed it up and
applied all 3 patches.
Shawn
> +#define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX1 0x01DC 0x0468 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_HSYNC__ESAI_TX1 0x01E0 0x046C 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA00__ESAI_TX_HF_CLK 0x01E4 0x0470 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA01__ESAI_RX_HF_CLK 0x01E8 0x0474 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA02__ESAI_RX_FS 0x01EC 0x0478 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA03__ESAI_RX_CLK 0x01F0 0x047C 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
> +#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
> +
> +#endif /* __DTS_IMX6ULL_PINFUNC_H */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] PCI: rockchip: cleanup bit definition for PCIE_RC_CONFIG_LCS
From: Shawn Lin @ 2016-11-15 1:09 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114222604.GJ9868-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
Hi Bjorn,
On 2016/11/15 6:26, Bjorn Helgaas wrote:
> On Mon, Nov 14, 2016 at 12:11:05PM +0800, Shawn Lin wrote:
>> PCIE_RC_CONFIG_LCS contains control and status bits specific
>> to the PCIe link. The layout for this register looks the same
>> as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
>> reuse them.
>>
>> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Did something change since the version you posted yesterday?
> Resending a patch with no changes or with no hint about what changed
> doesn't speed things up; in fact, it slows things down.
>
Sorry for that, mea culpa. I was finding I had sent a wrong patch which
couldn't be compiled cleanly, so I resent a new one. I should directly
respin a new version for that case.
>> ---
>>
>> drivers/pci/host/pcie-rockchip.c | 14 ++++----------
>> 1 file changed, 4 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
>> index 7f238af..1dba698 100644
>> --- a/drivers/pci/host/pcie-rockchip.c
>> +++ b/drivers/pci/host/pcie-rockchip.c
>> @@ -141,12 +141,6 @@
>> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
>> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
>> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
>> -#define PCIE_RC_CONFIG_LCS_RETRAIN_LINK BIT(5)
>> -#define PCIE_RC_CONFIG_LCS_CCC BIT(6)
>> -#define PCIE_RC_CONFIG_LCS_LBMIE BIT(10)
>> -#define PCIE_RC_CONFIG_LCS_LABIE BIT(11)
>> -#define PCIE_RC_CONFIG_LCS_LBMS BIT(30)
>> -#define PCIE_RC_CONFIG_LCS_LAMS BIT(31)
>> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
>> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
>> #define PCIE_RC_CONFIG_THP_CAP_NEXT_MASK GENMASK(31, 20)
>> @@ -229,7 +223,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
>> u32 status;
>>
>> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> - status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
>> + status |= (PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
>> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> }
>>
>> @@ -238,7 +232,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
>> u32 status;
>>
>> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> - status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
>> + status |= (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_LABS) << 16;
>> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> }
>>
>> @@ -540,7 +534,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>
>> /* Set RC's clock architecture as common clock */
>> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> - status |= PCIE_RC_CONFIG_LCS_CCC;
>> + status |= PCI_EXP_LNKCTL_CCC;
>> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>>
>> /* Enable Gen1 training */
>> @@ -575,7 +569,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>> * gen1 finished.
>> */
>> status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> - status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
>> + status |= PCI_EXP_LNKCTL_RL;
>> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>>
>> timeout = jiffies + msecs_to_jiffies(500);
>> --
>> 1.9.1
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 05/30] usb: dwc2: Add bindings to disable gadget DMA modes
From: Rob Herring @ 2016-11-15 1:11 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <16733114b9252b8163c11cc7ca95b2b152b66e0e.1478748145.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, Nov 09, 2016 at 07:27:50PM -0800, John Youn wrote:
> Now that the gadget driver automatically detects DMA modes, we need to
> provide a way to disable them. Certain platforms may still have issues
> with DMA and require it to be disabled. It is also needed for IP
> validation purposes.
I don't think IP validation is reason enough for these properties. If
there is IP that is broken and lies about it, then yes we should have
these.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: Add DTS support for FSL's LS1012A SoC
From: Shawn Guo @ 2016-11-15 1:18 UTC (permalink / raw)
To: Harninder Rai
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
Bhaskar Upadhaya, oss-fOR+EgIDQEHk1uMJSBkQmQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161114071308.GL3310@dragon>
On Mon, Nov 14, 2016 at 03:13:10PM +0800, Shawn Guo wrote:
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 6602718..39db645 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -1,3 +1,6 @@
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-qds.dtb
>
> It seems that the patch is not generated against mainline kernel. We do
> not have fsl-ls1046a-qds.dtb target in mainline kernel.
Sorry, forgot that we just added it in this development cycle.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 05/30] usb: dwc2: Add bindings to disable gadget DMA modes
From: John Youn @ 2016-11-15 1:26 UTC (permalink / raw)
To: Rob Herring, John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
In-Reply-To: <20161115011110.b32eljlv42mhbocr@rob-hp-laptop>
On 11/14/2016 5:11 PM, Rob Herring wrote:
> On Wed, Nov 09, 2016 at 07:27:50PM -0800, John Youn wrote:
>> Now that the gadget driver automatically detects DMA modes, we need to
>> provide a way to disable them. Certain platforms may still have issues
>> with DMA and require it to be disabled. It is also needed for IP
>> validation purposes.
>
> I don't think IP validation is reason enough for these properties. If
> there is IP that is broken and lies about it, then yes we should have
> these.
>
> Rob
>
Ok. Mark said basically the same thing in a previous thread that lead
to this patch.
Until they are needed by hardware, I'll remove these bindings.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] [media] mtk-mdp: allocate video_device dynamically
From: Minghsiu Tsai @ 2016-11-15 1:34 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, devicetree,
linux-kernel, linux-arm-kernel, linux-media, linux-mediatek,
Minghsiu Tsai
It can fix known problems with embedded video_device structs.
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
Changes in v2:
. Call video_device_release() instead of video_unregister_device()
in mtk_mdp_register_m2m_device()
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 33 ++++++++++++++++-----------
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index 848569d..ad1cff3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -167,7 +167,7 @@ struct mtk_mdp_dev {
struct mtk_mdp_comp *comp[MTK_MDP_COMP_ID_MAX];
struct v4l2_m2m_dev *m2m_dev;
struct list_head ctx_list;
- struct video_device vdev;
+ struct video_device *vdev;
struct v4l2_device v4l2_dev;
struct workqueue_struct *job_wq;
struct platform_device *vpu_dev;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 9a747e7..13afe48 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -1236,16 +1236,22 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
int ret;
mdp->variant = &mtk_mdp_default_variant;
- mdp->vdev.device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
- mdp->vdev.fops = &mtk_mdp_m2m_fops;
- mdp->vdev.ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
- mdp->vdev.release = video_device_release_empty;
- mdp->vdev.lock = &mdp->lock;
- mdp->vdev.vfl_dir = VFL_DIR_M2M;
- mdp->vdev.v4l2_dev = &mdp->v4l2_dev;
- snprintf(mdp->vdev.name, sizeof(mdp->vdev.name), "%s:m2m",
+ mdp->vdev = video_device_alloc();
+ if (!mdp->vdev) {
+ dev_err(dev, "failed to allocate video device\n");
+ ret = -ENOMEM;
+ goto err_video_alloc;
+ }
+ mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
+ mdp->vdev->fops = &mtk_mdp_m2m_fops;
+ mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
+ mdp->vdev->release = video_device_release;
+ mdp->vdev->lock = &mdp->lock;
+ mdp->vdev->vfl_dir = VFL_DIR_M2M;
+ mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
+ snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
MTK_MDP_MODULE_NAME);
- video_set_drvdata(&mdp->vdev, mdp);
+ video_set_drvdata(mdp->vdev, mdp);
mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
if (IS_ERR(mdp->m2m_dev)) {
@@ -1254,26 +1260,27 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
goto err_m2m_init;
}
- ret = video_register_device(&mdp->vdev, VFL_TYPE_GRABBER, 2);
+ ret = video_register_device(mdp->vdev, VFL_TYPE_GRABBER, 2);
if (ret) {
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
- mdp->vdev.num);
+ mdp->vdev->num);
return 0;
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(&mdp->vdev);
+ video_device_release(mdp->vdev);
+err_video_alloc:
return ret;
}
void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
{
- video_device_release(&mdp->vdev);
+ video_unregister_device(mdp->vdev);
v4l2_m2m_release(mdp->m2m_dev);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] [media] mtk-mdp: allocate video_device dynamically
From: Minghsiu Tsai @ 2016-11-15 1:37 UTC (permalink / raw)
To: Hans Verkuil
Cc: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Eddie Huang,
Yingjoe Chen, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d21cd419-e1fc-4d2e-a2a9-74c535865762-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Fri, 2016-11-11 at 11:51 +0100, Hans Verkuil wrote:
> Almost correct:
>
> On 11/07/2016 01:42 PM, Minghsiu Tsai wrote:
> > It can fix known problems with embedded video_device structs.
> >
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 33 ++++++++++++++++-----------
> > 2 files changed, 21 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > index 848569d..ad1cff3 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > @@ -167,7 +167,7 @@ struct mtk_mdp_dev {
> > struct mtk_mdp_comp *comp[MTK_MDP_COMP_ID_MAX];
> > struct v4l2_m2m_dev *m2m_dev;
> > struct list_head ctx_list;
> > - struct video_device vdev;
> > + struct video_device *vdev;
> > struct v4l2_device v4l2_dev;
> > struct workqueue_struct *job_wq;
> > struct platform_device *vpu_dev;
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > index 9a747e7..b8dee1c 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > @@ -1236,16 +1236,22 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
> > int ret;
> >
> > mdp->variant = &mtk_mdp_default_variant;
> > - mdp->vdev.device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
> > - mdp->vdev.fops = &mtk_mdp_m2m_fops;
> > - mdp->vdev.ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
> > - mdp->vdev.release = video_device_release_empty;
> > - mdp->vdev.lock = &mdp->lock;
> > - mdp->vdev.vfl_dir = VFL_DIR_M2M;
> > - mdp->vdev.v4l2_dev = &mdp->v4l2_dev;
> > - snprintf(mdp->vdev.name, sizeof(mdp->vdev.name), "%s:m2m",
> > + mdp->vdev = video_device_alloc();
> > + if (!mdp->vdev) {
> > + dev_err(dev, "failed to allocate video device\n");
> > + ret = -ENOMEM;
> > + goto err_video_alloc;
> > + }
> > + mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
> > + mdp->vdev->fops = &mtk_mdp_m2m_fops;
> > + mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
> > + mdp->vdev->release = video_device_release;
> > + mdp->vdev->lock = &mdp->lock;
> > + mdp->vdev->vfl_dir = VFL_DIR_M2M;
> > + mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
> > + snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
> > MTK_MDP_MODULE_NAME);
> > - video_set_drvdata(&mdp->vdev, mdp);
> > + video_set_drvdata(mdp->vdev, mdp);
> >
> > mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
> > if (IS_ERR(mdp->m2m_dev)) {
> > @@ -1254,26 +1260,27 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
> > goto err_m2m_init;
> > }
> >
> > - ret = video_register_device(&mdp->vdev, VFL_TYPE_GRABBER, 2);
> > + ret = video_register_device(mdp->vdev, VFL_TYPE_GRABBER, 2);
> > if (ret) {
> > dev_err(dev, "failed to register video device\n");
> > goto err_vdev_register;
> > }
> >
> > v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
> > - mdp->vdev.num);
> > + mdp->vdev->num);
> > return 0;
> >
> > err_vdev_register:
> > v4l2_m2m_release(mdp->m2m_dev);
> > err_m2m_init:
> > - video_device_release(&mdp->vdev);
> > + video_unregister_device(mdp->vdev);
>
> This should remain video_device_release: the video_register_device call failed, so
> the device hasn't been registered. In that case just release the device (i.e.
> free the allocated memory).
>
Hi Hans,
I have uploaded patch v2 for this. Thanks for your review.
Best regards,
Ming Hsiu
> > +err_video_alloc:
> >
> > return ret;
> > }
> >
> > void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
> > {
> > - video_device_release(&mdp->vdev);
> > + video_unregister_device(mdp->vdev);
> > v4l2_m2m_release(mdp->m2m_dev);
> > }
> >
>
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels
From: Rob Herring @ 2016-11-15 1:40 UTC (permalink / raw)
To: Laurent Pinchart, Thierry Reding
Cc: Laurent Pinchart, dri-devel,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:MEDIA DRIVERS FOR RENESAS - FCP, Tomi Valkeinen,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1488637.i0jADhlNmg@avalon>
On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hi Rob,
>
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
>> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
>> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple incompatible data link layers have been used over time to
>> >>> transmit image data to LVDS panels. This binding supports display
>> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>> >>> specifications.
>> >>>
>> >>> Signed-off-by: Laurent Pinchart
>> >>> <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> >>> ---
>> >>>
>> >>> .../bindings/display/panel/panel-lvds.txt | 119 ++++++++++++++
>> >>> 1 file changed, 119 insertions(+)
>> >>> create mode 100644
>> >>> Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> new file mode 100644
>> >>> index 000000000000..250861f2673e
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> @@ -0,0 +1,119 @@
>> >>> +Generic LVDS Panel
>> >>> +==================
>> >>> +
>> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple
>> >>> +incompatible data link layers have been used over time to transmit
>> >>> image data
>> >>> +to LVDS panels. This bindings supports display panels compatible with
>> >>> the
>> >>> +following specifications.
>> >>> +
>> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>> >>> February
>> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
>> >>> (JEIDA)
>> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
>> >>> +Semiconductor
>> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>> >>> Video
>> >>> +Electronics Standards Association (VESA)
>> >>> +
>> >>> +Device compatible with those specifications have been marketed under
>> >>> the
>> >>> +FPD-Link and FlatLink brands.
>> >>> +
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: shall contain "panel-lvds"
>> >>
>> >> Maybe as a fallback, but on its own, no way.
>> >
>> > Which brings an interesting question: when designing generic DT bindings,
>> > what's the rule regarding
>
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?
When in doubt, always have one. If there's any chance at all that s/w
will need to know or care, then we should have one.
> For instance (but perhaps not the best example), the input/rotary-encoder.txt
> bindings define a "rotary-encoder" compatible string, with no other bindings
> defining more precise compatible strings for the exact rotary encoder model.
> When it comes to panels I believe it makes sense to define model-specific
> compatible strings even if they're unused by drivers. I'm however wondering
> what the rule is there, and where those device-specific compatible strings
> should be defined. I'd like to avoid using one file per panel model as done
> today for the simple-panel bindings.
There's a few exceptions like this where there is not any sort of
model to base a compatible on. For example, a GPIO connected LED is
truly generic. The only way to have a more specific compatible would
be something with the board name in it.
Your case here is in the middle. It seems like it's generic and
passive, but perhaps power control is not. Rather than trying to
decide, we can just cover our ass and put both a generic and specific
compatible in.
>> Call it "simple" so I can easily NAK it. :)
>>
>> Define a generic structure, not a single binding trying to serve all.
>>
>> >> > +- width-mm: panel display width in millimeters
>> >> > +- height-mm: panel display height in millimeters
>> >>
>> >> This is already documented for all panels IIRC.
>> >
>> > Note that this DT binding has nothing to do with the simple-panel binding.
>> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
>> > currently don't but should specify the panel size in DT). The LVDS panel
>> > driver will *not* include any panel-specific information such as size or
>> > timings, these are specified in DT.
>>
>> The panel bindings aren't really different. The biggest difference was
>> location in the tree, but we now generally allow panels to be either a
>> child of the LCD controller or connected with OF graph. We probably
>> need to work on restructuring the panel bindings a bit. We should have
>> an inheritance with a base panel binding of things like size, label,
>> graph, backlight, etc, then perhaps an interface specific bindings for
>> LVDS, DSI, and parallel, then a panel specific binding. With this the
>> panel specific binding is typically just a compatible string and which
>> inherited properties apply to it.
>
> That sounds good to me, but we have multiple models for panel bindings.
>
> As you mentioned panels can be referenced through an LCD controller node
> property containing a phandle to the panel node, or through OF graph. That's a
> situation we have today, and we need to keep supporting both (at least for
> existing panels, perhaps not for the new ones).
>
> Another difference is how to express panel data such as size and timings. The
> simple-panel DT bindings don't contain such data and expects the drivers to
> contain a table of panel data for all models supported, while the DPI, DSI and
> now the proposed LVDS panel bindings contain properties for panel data.
>
> How would you like to reconcile all that ?
Thierry has outlined the position[1] that simple-panel follows many
times and I generally agree. I could be convinced that perhaps panel
timings could go into DT. However, you can't really describe
*everything*, so we're not going to get away from panel specific
compatible strings and panel specifics in the kernel.
>> >>> +- data-mapping: the color signals mapping order, "jeida-18",
>> >>> "jeida-24"
>> >>> + or "vesa-24"
>> >>
>> >> Maybe this should be part of the compatible.
>> >
>> > I've thought about it, but given that some panels support selecting
>> > between multiple modes (through a mode pin that is usually hardwired), I
>> > believe a separate DT property makes sense.
>>
>> Okay.
>>
>> > Furthermore, LVDS data organization is controlled by the combination of
>> > both data-mapping and data-mirror. It makes little sense from my point of
>> > view to handle one as part of the compatible string and the other one as
>> > a separate property.
>> >
>> >> > +Optional properties:
>> >> > +- label: a symbolic name for the panel
>> >>
>> >> Could be for any panel or display connector.
>> >
>> > Yes, but I'm not sure to understand how that's relevant :-)
>>
>> Meaning it should be a common property.
>
> Sure. So you expect me to reorganize all the panels and connectors DT bindings
> in order to get this one merged ? :-)
No, because I don't think label is widely defined. Just put it in a
common place and reference it. Any other panels can be fixed later.
Really, the "simple panel" binding should probably morph into the
common binding.
>> >>> +- avdd-supply: reference to the regulator that powers the panel
>> >>> analog supply
>> >>> +- dvdd-supply: reference to the regulator that powers the panel
>> >>> digital supply
>> >>
>> >> Which one has to be powered on first, what voltage, and with what time
>> >> in between? This is why "generic" or "simple" bindings don't work.
>> >
>> > The above-mentioned specifications also define connectors, pinouts and
>> > power supplies, but many LVDS panels compatible with the LVDS physical
>> > and data layers use a different connector with small differences in power
>> > supplies.
>> >
>> > I believe the voltage is irrelevant here, it doesn't need to be controlled
>> > by the operating system. Power supplies order and timing is relevant,
>> > I'll investigate the level of differences between panels. I'm also fine
>> > with dropping those properties for now.
>>
>> Whether you have control of the supplies is dependent on the board.
>> Dropping them is just puts us in the simple binding trap. The simple
>> bindings start out that way and then people keep adding to them.
>
> Damn, you can't be fooled easily ;-)
I guess you can count all the simple bindings to see how many times I
can be fooled. :)
> On a more serious note, I'd like to design the bindings in a way that wouldn't
> require adding device-specific code in the driver for each panel model, given
> that in most cases power supply handling will be generic. What's your opinion
> about a generic power supply model that would be used in the default case,
> with the option to override it with device-specific code when needed ?
I don't agree. Read Thierry's post on the subject[1].
Rob
[1] http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
From: Rob Herring @ 2016-11-15 1:43 UTC (permalink / raw)
To: Keerthy
Cc: tony, lee.jones, linux-omap, linux-kernel, devicetree, linux-gpio,
nm, t-kristo
In-Reply-To: <1478754560-27923-2-git-send-email-j-keerthy@ti.com>
On Thu, Nov 10, 2016 at 10:39:16AM +0530, Keerthy wrote:
> GPIO7 is configured in POWERHOLD mode which has higher priority
> over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
> bit is turned off. This property enables driver to over ride the
> POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
> scenarios.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCHv3 1/2] gpio: xilinx: dt-binding: Add clock node
From: Rob Herring @ 2016-11-15 1:44 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-gpio, devicetree, soren.brinkmann, michal.simek,
shubhrajyoti.datta
In-Reply-To: <1478757365-3311-1-git-send-email-shubhrajyoti.datta@xilinx.com>
On Thu, Nov 10, 2016 at 11:26:04AM +0530, Shubhrajyoti Datta wrote:
> Add the clock node to the dt binding.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> ---
> v2:
> Make clocks optional
> Add clock name
> v3:
> No change
>
> .../devicetree/bindings/gpio/gpio-xilinx.txt | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RESEND PATCH] regulator: pwm: fix syntax errors in the examples
From: Rob Herring @ 2016-11-15 1:47 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Liam Girdwood, Mark Brown, Mark Rutland, devicetree
In-Reply-To: <1478773527-10936-1-git-send-email-peda@axentia.se>
qOn Thu, Nov 10, 2016 at 11:25:27AM +0100, Peter Rosin wrote:
> While at it, clean up some other things as well.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../devicetree/bindings/regulator/pwm-regulator.txt | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
As this is just DT docs, I've applied.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Rob Herring @ 2016-11-15 1:49 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Martin Strbačka, Tomas Hlavacek, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161110135721.13098-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
On Thu, Nov 10, 2016 at 02:57:20PM +0100, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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