* [PATCH 6/7] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-11-17 10:41 UTC (permalink / raw)
To: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
horms-/R6kz+dDXgpPR4JQBCEnsQ, geert-Td1EMuHUCqxL1ZNQvxDV9g,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ, Ulrich Hecht
In-Reply-To: <1510915289-15059-1-git-send-email-ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 06bb7cc..f7d0358 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -11,6 +11,7 @@ Required properties:
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
"renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
+ "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
@@ -25,12 +26,12 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
-and can be used by both CAN and CAN FD controller at the same time. It needs to
-be scaled to maximum frequency if any of these controllers use it. This is done
-using the below properties:
+Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
+"renesas,can-r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, "clkp2" can be CANFD clock. This is a
+div6 clock and can be used by both CAN and CAN FD controller at the same
+time. It needs to be scaled to maximum frequency if any of these
+controllers use it. This is done using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
- assigned-clock-rates: maximum frequency of this clock.
--
2.7.4
--
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 related
* [PATCH 7/7] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-11-17 10:41 UTC (permalink / raw)
To: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
horms-/R6kz+dDXgpPR4JQBCEnsQ, geert-Td1EMuHUCqxL1ZNQvxDV9g,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ, Ulrich Hecht
In-Reply-To: <1510915289-15059-1-git-send-email-ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6a..5617892 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
+ - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -24,12 +25,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each
child node supports the "status" property only, which is used to
enable/disable the respective channel.
-Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
-compatible:
-In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both
-CAN and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the below
-properties:
+Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and
+"renesas,r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, canfd clock is a div6 clock and can
+be used by both CAN and CAN FD controller at the same time. It needs to be
+scaled to maximum frequency if any of these controllers use it. This is
+done using the below properties:
- assigned-clocks: phandle of canfd clock.
- assigned-clock-rates: maximum frequency of this clock.
--
2.7.4
--
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 related
* Re: [PATCH] gpio: pca953x: fix vendor prefix for PCA9654
From: Sergei Shtylyov @ 2017-11-17 10:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Rob Herring, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, Mark Rutland, Linux-Renesas
In-Reply-To: <CAMuHMdVAD5saFjnkMViTeCm2vDYfEraq9DdHqNLet3YHjo0UeQ@mail.gmail.com>
On 11/17/2017 12:06 PM, Geert Uytterhoeven wrote:
>> Despite commit 55020c8056a8 ("of: Add vendor prefix for ON Semiconductor
>> Corp.") was made long ago, the latter commit 9f49f6dd0473 ("gpio: pca953x:
>> add onsemi,pca9654 id") made use of another, undocumented vendor prefix.
>
> Ouch...
>
>> Since such prefix doesn't seem to be used in any device trees, I think we
>> can just fix the "compatible" string in the driver and the bindings and be
>> done with that...
>>
>> Fixes: 9f49f6dd0473 ("gpio: pca953x: add onsemi,pca9654 id")
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against the 'fixes' branch of LinusW's 'linux-gpio.git' repo.
>>
>> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 2 +-
>> drivers/gpio/gpio-pca953x.c | 2 +-
>
> There's another (different) one in
> Documentation/devicetree/bindings/misc/idt_89hpesx.txt
Saw that. Do you think it also should be fixed (in this patch)?
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
^ permalink raw reply
* Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver
From: kgunda @ 2017-11-17 11:01 UTC (permalink / raw)
To: Lee Jones
Cc: Bjorn Andersson, linux-arm-msm, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <20171117083342.usr4t7olsgarn4kp@dell>
On 2017-11-17 14:03, Lee Jones wrote:
> On Thu, 16 Nov 2017, Bjorn Andersson wrote:
>
>> On Thu 16 Nov 22:36 PST 2017, kgunda@codeaurora.org wrote:
>>
>> > On 2017-11-16 22:25, Bjorn Andersson wrote:
>> > > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>> > >
>> > > > WLED driver provides the interface to the display driver to
>> > > > adjust the brightness of the display backlight.
>> > > >
>> > >
>> > > Hi Kiran,
>> > >
>> > > This driver has a lot in common with the already upstream pm8941-wled.c,
>> > > because it's just a new revision of the same block.
>> > >
>> > > Please extend the existing driver rather than providing a new one
>> > > (and yes, renaming the file is okay).
>> > >
>> > > Regards,
>> > > Bjorn
>> >
>> > Hi Bjorn,
>> >
>> > Yes this driver design is similar to pm8941, however the WLED HW block
>> > has undergone quite a few changes in analog and digital from PM8941 to
>> > PM8998.
>>
>> I can see that, looking at the documentation.
>>
>> > Few of them include splitting one module into wled-ctrl and wled-sink
>> > peripherals, changes in the register offsets and the bit
>> > interpretation.
>>
>> This is typical and something we need to handle in all these drivers,
>> to
>> avoid having one driver per platform.
>>
>> > Hence we concluded that it was better to have a new driver to support
>> > this new gen WELD module and decouple it from the pm8941.
>>
>> Okay, I can see how it's easier to not have to case about anything but
>> pmi8998 in this driver, but where do you add the support for other
>> WLED
>> versions? What about PMI8994? Will there not be similar differences
>> (registers that has moved around) in the future?
>>
>> > Also, going forward this driver will support AMOLED AVDD rail (not
>> > supported by pm8941) touching a few more registers/configuration and
>> > newer PMICs.
>>
>> Is this a feature that was introduced in PMI8998? Will this support
>> not
>> be dependent on the pmic version?
>>
>> > So spinning off a new driver would make it cleaner and easier to
>> > extend further.
>> >
>>
>> It's for sure easier at this point in time, but your argumentation
>> implies that PMI8998+1 should go into it's own driver as well.
>>
>> I suspect that if you're going to reuse this driver for future PMIC
>> versions you will have to deal with register layout differences and
>> new
>> feature set, and as such I'm not convinced that a new driver is
>> needed.
>>
>> Can you give any concrete examples of where it is not possible or
>> undesirable to maintain the pm8941 support in the same driver?
>
> I agree with Bjorn. If you can support multiple devices in a single
> driver with a couple of simple ddata struct differences and a slightly
> different regmap, you should.
Hi Lee,
Thanks for the feedback! The regmap difference is not confined to couple
of registers.
Except the one register all the registers have some difference in offset
or bitmap or
config values as compared to the pm8941. Below is the table for the
reference. The below
table covers only the registers those exist in the pm8941 driver, if we
keep adding the
other features the changes may be huge. Apart from this I have mentioned
other feature
differences between pm8941 and pm8998 as well in response to Bjorn.
Please refer that
as well.
Register Compatibility between 8998 Vs 8941
========
===================================================
WLED_MODULE_ENABLE Register address offset is same and config
values match
WLED1_ILED_SYNC_BIT Register address offset and config values not
matching.
WLED1_SWITCHING_FREQUENCY Register address offset and config values
are matching.
But there is an extra override bit in
pm8998.
WLED1_WLED_OVP Register address offset same. But config
values are not matching.
WLED1_WLED_ILIM Register address offset is same. But
config values are not matching
WLED1_EN_CURRENT_SINK Both register address offset and config
values are not matching.
WLED1_LED1_MODULATOR_EN Both register address offset and config
values are not matching.
WLED1_LED1_FULL_SCALE_CURRENT Both register address offset and config
values are not matching.
WLED1_LED1_MODULATOR_SRC_SE Register address offset not matching, but
the config values are matching
WLED1_LED1_CABC_EN Register address offset not matching, but the
config values are not matching.
Thanks,
Kiran
^ permalink raw reply
* Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Pavel Machek @ 2017-11-17 11:20 UTC (permalink / raw)
To: Dan Murphy
Cc: Jacek Anaszewski, robh+dt, mark.rutland, rpurdie, devicetree,
linux-kernel, linux-leds, Lee Jones, Daniel Thompson, Jingoo Han
In-Reply-To: <16189eab-5541-9550-c027-1c9d2b5fa6d7@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
Hi!
> >> If that does not yet exist... you want to create glue layer to be able
> >> to use LED as a display backlight. (It may already exist, no idea).
> >>
> >> ...
> >>
> >> Actually or maybe a LED trigger. Just set LED's trigger to "this is
> >> display backlight".
> >
> > There is one already:
> >
> > drivers/leds/trigger/ledtrig-backlight.c
> >
> > It adds a LED class device to the fb_notifier_list
> > (drivers/video/fbdev/core/fb_notify.c)
> >
> > using fb_register_client(). The same is used in
> > backlight_device_register (drivers/video/backlight/backlight.c).
> >
> > Actually why do you want to have this driver in the LED subsystem,
> > if it is advertised as "designed for LCD display backlighting"?
>
> Well this is also advertised as a driver for Smart phone and tablet devices. And having worked with the Android lighting
> solutions this is the preferred subsystem for Android. The Android OS manages the led brightness based on ALS values and in
> turn calls into the driver to control the brightness register through the vendor provided lighting HAL.
>
Well.. if it can control other LEDs than just backlight, I believe it
can stay in the LED subsystem.
> I am going to look at the backlight source to figure out how to get the same functionality using the backlight subsystem.
> Otherwise I will plug in this driver to the backlight subsystem through the notifier.
>
The backlight trigger should be ok.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Thierry Reding @ 2017-11-17 11:36 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland, devicetree, David Airlie, linux-kernel, dri-devel,
Rob Herring
In-Reply-To: <20171107153058.5554-1-lukma@denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 4150 bytes --]
On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>
> ---
> Changes for v2:
> - Provide more detailed ./Documentation/devicetree/bindings/display/panel
> entry to describe this panel device.
> ---
> .../bindings/display/panel/tianma,tm070rvhg71.txt | 29 ++++++++++++++++++++++
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++
> 2 files changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
I've applied this, though I had to make a few modifications. First, I
added a commit message. Commits should always have one.
Also, please send DT bindings and driver changes as separate patches in
the future.
Device tree bindings should have a subject prefixed with any of these:
dt-bindings:
dt-bindings: display:
dt-bindings: display: panel:
Though the latter two are fairly long by themselves, so you don't have a
lot of room for the important bits.
Please also prefix the subject of panel driver patches with a:
drm/panel:
Which makes it easier to identify relevant patches among loads and loads
of other email.
>
> diff --git a/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> new file mode 100644
> index 000000000000..02562867444d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> @@ -0,0 +1,29 @@
> +Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "tianma,tm070rvhg71
Added a missing " at the end here.
> +- power-supply: single regulator to provide the supply voltage
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Required nodes:
> +- port: LVDS port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is conntrolled
> +via PWM signal.
> +
> +Example:
> +--------
> +
> +Example device-tree definition when connected to iMX6Q based board
> +
> + panel: panel-lvds0 {
> + compatible = "tianma,tm070rvhg71";
> + backlight = <&backlight_lvds>;
> + power-supply = <®_lvds>;
> +
> + port {
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 3d2cb8bc4d94..07188dc084df 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1831,6 +1831,30 @@ static const struct panel_desc tianma_tm070jdhg30 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> };
>
> +static const struct display_timing tianma_tm070rvhg71_timing = {
> + .pixelclock = { 27700000, 29200000, 39600000 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 12, 40, 212 },
> + .hback_porch = { 88, 88, 88 },
> + .hsync_len = { 1, 1, 40 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 1, 13, 88 },
> + .vback_porch = { 32, 32, 32 },
> + .vsync_len = { 1, 1, 3 },
> + .flags = DISPLAY_FLAGS_DE_HIGH,
> +};
> +
> +static const struct panel_desc tianma_tm070rvhg71 = {
> + .timings = &tianma_tm070rvhg71_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> +};
> +
> static const struct drm_display_mode tpk_f07a_0102_mode = {
> .clock = 33260,
> .hdisplay = 800,
> @@ -2113,6 +2137,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "tianma,tm070jdhg30",
> .data = &tianma_tm070jdhg30,
> }, {
> + .compatible = "tianma,tm070rvhg71",
> + .data = &tianma_tm070rvhg71,
> + }, {
> .compatible = "tpk,f07a-0102",
> .data = &tpk_f07a_0102,
> }, {
Looks like these are actually sorted correctly in your patch. However,
when applying these got added after the Toshiba panel that was recently
added, so I resorted again.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFCv2 PATCH 31/36] iommu/arm-smmu-v3: Add support for PCI ATS
From: Jean-Philippe Brucker @ 2017-11-17 11:39 UTC (permalink / raw)
To: Bharat Kumar Gogada,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: Mark Rutland,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
Catalin Marinas, Will Deacon,
okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, Sudeep Holla
In-Reply-To: <BLUPR0201MB1505BC86D3838D13F38665E7A52F0-hRBPhS1iNj/g9tdZWAsUFxrHTHEw16jenBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On 17/11/17 06:11, Bharat Kumar Gogada wrote:
[...]
> Thanks Jean, I see that currently vfio_group_fops_open does not allow multiple instances.
> If a device supports multiple PASID there might be different applications running parallel.
> So why is multiple instances restricted ?
You can't have multiple processes owning the same PCI device, it's
unmanageable.
For using multiple PASIDs, my idea was that the userspace driver ("the
server"), that owns the device, would have a way to partition it into
smaller frames. It forks to create "clients" and assigns a PASID to each
of them (by issuing VFIO_BIND(client_pid) -> pasid, then writing the PASID
into a privileged MMIO frame that defines the partition properties). Each
client accesses an unprivileged MMIO frame to use a device partition (or
sends commands to the server via IPC), and can perform DMA on its own
virtual memory.
This is complete speculation of course, we have very little information on
how PASID-capable devices will be designed, so I'm trying to imagine
likely scenarios.
Thanks,
Jean
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Thierry Reding @ 2017-11-17 11:41 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Rob Herring, Mark Rutland, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117110247.5d7737bc@jawa>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> Dear All,
>
> > On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > >
> > > ---
> > > Changes for v2:
> > > - Provide more
> > > detailed ./Documentation/devicetree/bindings/display/panel entry to
> > > describe this panel device. ---
> > > .../bindings/display/panel/tianma,tm070rvhg71.txt | 29
> > > ++++++++++++++++++++++
> > > drivers/gpu/drm/panel/panel-simple.c | 27
> > > ++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode
> > > 100644
> > > Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> >
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Is there a chance that this patch will find its way to v4.15-rc1 ?
No, that's very unlikely. We're in the middle of the merge window, no
new patches are accepted at that point.
If you want to make sure a patch goes into the next release, make sure
it is posted and reviewed at least a few days before -rc6 of the prior
release. -rc6 is a common cut-off point for subsystems (though not all)
in the kernel.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Mitsubishi aa070mc01 display support (800x480)
From: Thierry Reding @ 2017-11-17 11:45 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland, devicetree, David Airlie, linux-kernel, dri-devel,
Rob Herring
In-Reply-To: <1508537169-402-1-git-send-email-lukma@denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 755 bytes --]
On Sat, Oct 21, 2017 at 12:06:09AM +0200, Lukasz Majewski wrote:
> This commit adds support for Mitsubishi aa070mc01 TFT panel working
> with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> ---
> Changes for v2:
> - Place the code sorted alphabetically
> - Add missing ./Documentation/devicetree/binding/display properties
> description
> ---
> .../display/panel/mitsubishi,aa070mc01.txt | 7 +++++
> drivers/gpu/drm/panel/panel-simple.c | 35 ++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa070mc01.txt
Applied to drm-misc-next, thanks.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Lukasz Majewski @ 2017-11-17 12:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Rob Herring, Mark Rutland, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117113616.GA1062@ulmo>
[-- Attachment #1: Type: text/plain, Size: 4819 bytes --]
Hi Thierry,
> On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> >
> > ---
> > Changes for v2:
> > - Provide more
> > detailed ./Documentation/devicetree/bindings/display/panel entry to
> > describe this panel device. ---
> > .../bindings/display/panel/tianma,tm070rvhg71.txt | 29
> > ++++++++++++++++++++++
> > drivers/gpu/drm/panel/panel-simple.c | 27
> > ++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode
> > 100644
> > Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
>
> I've applied this, though I had to make a few modifications.
Thanks :-)
> First, I
> added a commit message. Commits should always have one.
>
> Also, please send DT bindings and driver changes as separate patches
> in the future.
>
> Device tree bindings should have a subject prefixed with any of these:
>
> dt-bindings:
> dt-bindings: display:
> dt-bindings: display: panel:
>
> Though the latter two are fairly long by themselves, so you don't
> have a lot of room for the important bits.
>
> Please also prefix the subject of panel driver patches with a:
>
> drm/panel:
>
> Which makes it easier to identify relevant patches among loads and
> loads of other email.
Ok. I see. Thanks for explanation.
>
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > new file mode 100644 index 000000000000..02562867444d --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > @@ -0,0 +1,29 @@ +Tianma Micro-electronics TM070RVHG71 7.0" WXGA
> > TFT LCD panel +
> > +Required properties:
> > +- compatible: should be "tianma,tm070rvhg71
>
> Added a missing " at the end here.
Ok.
>
> > +- power-supply: single regulator to provide the supply voltage
> > +- backlight: phandle of the backlight device attached to the panel
> > +
> > +Required nodes:
> > +- port: LVDS port mapping to connect this display
> > +
> > +This panel needs single power supply voltage. Its backlight is
> > conntrolled +via PWM signal.
> > +
> > +Example:
> > +--------
> > +
> > +Example device-tree definition when connected to iMX6Q based board
> > +
> > + panel: panel-lvds0 {
> > + compatible = "tianma,tm070rvhg71";
> > + backlight = <&backlight_lvds>;
> > + power-supply = <®_lvds>;
> > +
> > + port {
> > + panel_in_lvds0: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c index
> > 3d2cb8bc4d94..07188dc084df 100644 ---
> > a/drivers/gpu/drm/panel/panel-simple.c +++
> > b/drivers/gpu/drm/panel/panel-simple.c @@ -1831,6 +1831,30 @@
> > static const struct panel_desc tianma_tm070jdhg30 = { .bus_format =
> > MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, };
> >
> > +static const struct display_timing tianma_tm070rvhg71_timing = {
> > + .pixelclock = { 27700000, 29200000, 39600000 },
> > + .hactive = { 800, 800, 800 },
> > + .hfront_porch = { 12, 40, 212 },
> > + .hback_porch = { 88, 88, 88 },
> > + .hsync_len = { 1, 1, 40 },
> > + .vactive = { 480, 480, 480 },
> > + .vfront_porch = { 1, 13, 88 },
> > + .vback_porch = { 32, 32, 32 },
> > + .vsync_len = { 1, 1, 3 },
> > + .flags = DISPLAY_FLAGS_DE_HIGH,
> > +};
> > +
> > +static const struct panel_desc tianma_tm070rvhg71 = {
> > + .timings = &tianma_tm070rvhg71_timing,
> > + .num_timings = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 154,
> > + .height = 86,
> > + },
> > + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> > +};
> > +
> > static const struct drm_display_mode tpk_f07a_0102_mode = {
> > .clock = 33260,
> > .hdisplay = 800,
> > @@ -2113,6 +2137,9 @@ static const struct of_device_id
> > platform_of_match[] = { .compatible = "tianma,tm070jdhg30",
> > .data = &tianma_tm070jdhg30,
> > }, {
> > + .compatible = "tianma,tm070rvhg71",
> > + .data = &tianma_tm070rvhg71,
> > + }, {
> > .compatible = "tpk,f07a-0102",
> > .data = &tpk_f07a_0102,
> > }, {
>
> Looks like these are actually sorted correctly in your patch. However,
> when applying these got added after the Toshiba panel that was
> recently added, so I resorted again.
Thanks one more time.
>
> Thierry
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v11 02/10] i2c: i2c-smbus: Move i2c_setup_smbus_alert from i2c-smbus to i2c-core-smbus
From: Phil Reid @ 2017-11-17 12:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: Jean Delvare, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, sre-DgEjT+Ai2ygdnm+yROfE0A,
jdelvare-IBi9RG/b67k, jglauber-YGCgFSpz5w/QT0dZR+AlfA,
david.daney-YGCgFSpz5w/QT0dZR+AlfA, peda-koto5C5qi+TLoDKTGw+V6w,
benjamin.tissoires-H+wXaHxf7aLQT0dZR+AlfA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171107072254.s43mwpyplx3hdkyo@ninjato>
On 7/11/2017 15:22, Wolfram Sang wrote:
>
>> I was just thinking that all that's in the file now is smbus-alert code.
>> The other smbus (host notify) code was moved to i2c-core
>> So maybe i2c-core-smbus-alert and as you say use makefile to include it.
>
> Aaaah, i2c-core-smbus-alert.c. Yes, that probably makes sense. I was
> wondering about i2c-smbus-alert.c (without -core)...
>
>> I've tried this and it seems to work for the various combinations.
>> I'll wait a bit for Jean to offer an opinion.
>
> Well, if you have code already, can you post it as RFC and CC Jean?
> It usually is easier to talk over code, even if it is not perfect yet...
>
Yes will do. Was hoping to clean it up into some incremental patches and post this week.
But it looks like next week now.
--
Regards
Phil Reid
--
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] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Lukasz Majewski @ 2017-11-17 12:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Mark Rutland, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117114126.GB1062@ulmo>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
Hi Thierry,
> On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> > Dear All,
> >
> > > On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > >
> > > > ---
> > > > Changes for v2:
> > > > - Provide more
> > > > detailed ./Documentation/devicetree/bindings/display/panel
> > > > entry to describe this panel device. ---
> > > > .../bindings/display/panel/tianma,tm070rvhg71.txt | 29
> > > > ++++++++++++++++++++++
> > > > drivers/gpu/drm/panel/panel-simple.c | 27
> > > > ++++++++++++++++++++ 2 files changed, 56 insertions(+) create
> > > > mode 100644
> > > > Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > >
> > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Is there a chance that this patch will find its way to v4.15-rc1 ?
>
> No, that's very unlikely. We're in the middle of the merge window, no
> new patches are accepted at that point.
Ok. I see. I should have sent the ping earlier.
>
> If you want to make sure a patch goes into the next release, make sure
> it is posted and reviewed at least a few days before -rc6 of the prior
> release. -rc6 is a common cut-off point for subsystems (though not
> all) in the kernel.
Understood, thanks.
>
> Thierry
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Thierry Reding @ 2017-11-17 12:27 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland, devicetree, David Airlie, linux-kernel, dri-devel
In-Reply-To: <20171117131712.0f2a0a4f@jawa>
[-- Attachment #1.1: Type: text/plain, Size: 1497 bytes --]
On Fri, Nov 17, 2017 at 01:17:12PM +0100, Lukasz Majewski wrote:
> Hi Thierry,
>
> > On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> > > Dear All,
> > >
> > > > On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > > >
> > > > > ---
> > > > > Changes for v2:
> > > > > - Provide more
> > > > > detailed ./Documentation/devicetree/bindings/display/panel
> > > > > entry to describe this panel device. ---
> > > > > .../bindings/display/panel/tianma,tm070rvhg71.txt | 29
> > > > > ++++++++++++++++++++++
> > > > > drivers/gpu/drm/panel/panel-simple.c | 27
> > > > > ++++++++++++++++++++ 2 files changed, 56 insertions(+) create
> > > > > mode 100644
> > > > > Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > > >
> > > > Acked-by: Rob Herring <robh@kernel.org>
> > >
> > > Is there a chance that this patch will find its way to v4.15-rc1 ?
> >
> > No, that's very unlikely. We're in the middle of the merge window, no
> > new patches are accepted at that point.
>
> Ok. I see. I should have sent the ping earlier.
Looking at the timeline of this patch even that wouldn't have been
enough. You sent the original patch on October 21, which is one day
after the final drm-misc feature pull request was tagged. So this
wouldn't have made it into v4.15-rc1 no matter how early you would
have pinged. =)
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Mitsubishi aa070mc01 display support (800x480)
From: Lukasz Majewski @ 2017-11-17 12:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Mark Rutland, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117114505.GC1062@ulmo>
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
Hi Thierry,
> On Sat, Oct 21, 2017 at 12:06:09AM +0200, Lukasz Majewski wrote:
> > This commit adds support for Mitsubishi aa070mc01 TFT panel working
> > with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
> >
> > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > ---
> > Changes for v2:
> > - Place the code sorted alphabetically
> > - Add missing ./Documentation/devicetree/binding/display properties
> > description
> > ---
> > .../display/panel/mitsubishi,aa070mc01.txt | 7 +++++
> > drivers/gpu/drm/panel/panel-simple.c | 35
> > ++++++++++++++++++++++ 2 files changed, 42 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/mitsubishi,aa070mc01.txt
>
> Applied to drm-misc-next, thanks.
>
> Thierry
Thanks :-)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)
From: Lukasz Majewski @ 2017-11-17 12:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Mark Rutland, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117122713.GA22989@ulmo>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
On Fri, 17 Nov 2017 13:27:13 +0100
Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Nov 17, 2017 at 01:17:12PM +0100, Lukasz Majewski wrote:
> > Hi Thierry,
> >
> > > On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> > > > Dear All,
> > > >
> > > > > On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski
> > > > > wrote:
> > > > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > > > >
> > > > > > ---
> > > > > > Changes for v2:
> > > > > > - Provide more
> > > > > > detailed ./Documentation/devicetree/bindings/display/panel
> > > > > > entry to describe this panel device. ---
> > > > > > .../bindings/display/panel/tianma,tm070rvhg71.txt | 29
> > > > > > ++++++++++++++++++++++
> > > > > > drivers/gpu/drm/panel/panel-simple.c | 27
> > > > > > ++++++++++++++++++++ 2 files changed, 56 insertions(+)
> > > > > > create mode 100644
> > > > > > Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> > > > >
> > > > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > >
> > > > Is there a chance that this patch will find its way to
> > > > v4.15-rc1 ?
> > >
> > > No, that's very unlikely. We're in the middle of the merge
> > > window, no new patches are accepted at that point.
> >
> > Ok. I see. I should have sent the ping earlier.
>
> Looking at the timeline of this patch even that wouldn't have been
> enough. You sent the original patch on October 21, which is one day
> after the final drm-misc feature pull request was tagged. So this
> wouldn't have made it into v4.15-rc1 no matter how early you would
> have pinged. =)
Time's flying :-)
Anyway, thanks for help.
>
> Thierry
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1088a: add fsl-mc hardware resource manager node
From: Shawn Guo @ 2017-11-17 12:35 UTC (permalink / raw)
To: Ioana Ciornei
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <DB6PR0401MB2264A182C4048471B53BFF89E02E0-2mNvjAGDOPl4towakvZX7o3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Thu, Nov 16, 2017 at 02:24:49PM +0000, Ioana Ciornei wrote:
...
> > > + fsl_mc: fsl-mc@80c000000 {
> >
> > The unit-address of the node should be somehow related to 'reg'
> > property. Can you please help me understand how they are related?
>
> The unit-address of the fsl-mc node is the base address of the MC portal described in the first region of the 'reg' property and formed using the 2 address cells.
> Hope this helps.
Ah, sorry, I forgot that the address-cells is 2.
>
> >
> > > + compatible = "fsl,qoriq-mc";
> > > + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
> > > + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> > > + msi-parent = <&its>;
> > > + #address-cells = <3>;
> > > + #size-cells = <1>;
> > > +
> > > + /*
> > > + * Region type 0x0 - MC portals
> > > + * Region type 0x1 - QBMAN portals
> > > + */
> > > + ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
> > > + 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
> > > +
> > > + dpmacs {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + dpmac1: dpmac@1 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <1>;
> > > + };
> >
> > Please have a newline in between nodes.
>
> Will do.
>
> Should I send a rework of this patch right away or better to wait for the merge window to close?
Either way is fine, as I will rebase my branch to v4.15-rc1 after merge
window closes.
> > > + dpmac2: dpmac@2 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <2>;
> > > + };
> > > + dpmac3: dpmac@3 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <3>;
> > > + };
> > > + dpmac4: dpmac@4 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <4>;
> > > + };
> > > + dpmac5: dpmac@5 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <5>;
> > > + };
> > > + dpmac6: dpmac@6 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <6>;
> > > + };
> > > + dpmac7: dpmac@7 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <7>;
> > > + };
> > > + dpmac8: dpmac@8 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <8>;
> > > + };
> > > + dpmac9: dpmac@9 {
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <9>;
> > > + };
> > > + dpmac10: dpmac@10 {
Just noticed this - the unit-address should be hex number, so it should
be dpmac@a rather than dpmac@10, I think.
Shawn
> > > + compatible = "fsl,qoriq-mc-dpmac";
> > > + reg = <0xa>;
> > > + };
> > > + };
> > > + };
> > > +
> > > psci {
> > > compatible = "arm,psci-0.2";
> > > method = "smc";
> > > --
> > > 1.9.1
> > >
> > >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [PACTH v2] arm64: dts: ls1088a: Added dcfg node in ls1088a dtsi
From: Shawn Guo @ 2017-11-17 12:40 UTC (permalink / raw)
To: Ashish Kumar
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Amrita Kumari
In-Reply-To: <1509684461-7432-1-git-send-email-Ashish.Kumar-3arQi8VN3Tc@public.gmane.org>
On Fri, Nov 03, 2017 at 10:17:41AM +0530, Ashish Kumar wrote:
> Add debug configuration node(DCFG) in dtsi, helps guts driver to
> print the following information in kernel boot log
>
> [ 0.526649] Machine: LS1088A RDB Board
> [ 0.530430] SoC family: QorIQ LS1088A
> [ 0.534115] SoC ID: svr:0x87030010, Revision: 1.0
>
> Signed-off-by: Amrita Kumari <amrita.kumari-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <Ashish.Kumar-3arQi8VN3Tc@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
* Re: [PATCH] omapdrm: hdmi4: Correct the SoC revision matching
From: Tomi Valkeinen @ 2017-11-17 12:55 UTC (permalink / raw)
To: Peter Ujfalusi, laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jsarha-l0cyMroinI0
Cc: airlied-cv59FeDIM0c, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117080043.19010-1-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
On 17/11/17 10:00, Peter Ujfalusi wrote:
> I believe the intention of the commit 2c9fc9bf45f8
> ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
> was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
> like omap4460.
>
> By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
> same way as it would treat omap4430 ES1.x
>
> This breaks HDMI audio on OMAP4460 devices (PandaES for example).
>
> Correct the match rule so we are not going to get false positive match.
>
> Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
>
> CC: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.14
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
> ---
> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> index 62e451162d96..07945a40c33a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> @@ -902,9 +902,20 @@ static const struct hdmi4_features hdmi4_es3_features = {
> };
>
> static const struct soc_device_attribute hdmi4_soc_devices[] = {
> - { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features },
> - { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features },
> - { .family = "OMAP4", .data = &hdmi4_es3_features },
> + {
> + .machine = "OMAP4430",
> + .revision = "ES1.?",
> + .data = &hdmi4_es1_features,
> + },
> + {
> + .machine = "OMAP4430",
> + .revision = "ES2.?",
> + .data = &hdmi4_es2_features,
> + },
> + {
> + .family = "OMAP4",
> + .data = &hdmi4_es3_features,
> + },
> { /* sentinel */ }
> };
>
>
Looks good to me.
Was there are reason to change the format from single-line to multi-line?
While at it, I think it would make sense to rename hdmi4_es3_features
to... hdmi4_features? It's not "ES3" in any way.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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 resend] arm: dts: ls1021a: add "fsl, ls1021a-esdhc" compatible string to esdhc node
From: Shawn Guo @ 2017-11-17 12:56 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, yinbo.zhu, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1510834526-32730-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Thu, Nov 16, 2017 at 01:15:26PM +0100, Rasmus Villemoes wrote:
> Commit a22950c888e3 (mmc: sdhci-of-esdhc: add quirk
> SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for ls1021a) added logic to the driver to
> enable the broken timeout val quirk for ls1021a, but did not add the
> corresponding compatible string to the device tree, so it didn't really
> have any effect. Fix that.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@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
* Re: [PATCH 1/5] dt-bindings: i2c: update documentation for the Meson-AXG
From: Neil Armstrong @ 2017-11-17 13:02 UTC (permalink / raw)
To: Yixun Lan, Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c,
devicetree, Kevin Hilman
Cc: Jerome Brunet, Carlo Caione, Jian Hu, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-2-yixun.lan@amlogic.com>
On 17/11/2017 09:02, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Update the doc to explicitly add Meson-AXG to support list
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
> index 611b934c7e10..3097d2b44dad 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
> @@ -2,6 +2,7 @@ Amlogic Meson I2C controller
>
> Required properties:
> - compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c"
> + "amlogic,meson-axg-i2c"
Hi Yixun, Jian,
Maybe you should reformat by using :
- compatible: must be :
"amlogic,meson6-i2c" for Meson8 and compatible SoCs
"amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs
"amlogic,meson-axg-i2c"for AXG and compatible SoCs
Neil
> - reg: physical address and length of the device registers
> - interrupts: a single interrupt specifier
> - clocks: clock for the device
>
^ permalink raw reply
* Re: [PATCH 2/5] i2c: meson: add configurable divider factors
From: Neil Armstrong @ 2017-11-17 13:02 UTC (permalink / raw)
To: Yixun Lan, Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c,
devicetree, Kevin Hilman
Cc: Jerome Brunet, Carlo Caione, Jian Hu, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-3-yixun.lan@amlogic.com>
On 17/11/2017 09:02, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> This patch try to add support for I2C controller in Meson-AXG SoC,
> Due to the IP changes between I2C controller, we need to introduce
> a compatible data to make the divider factor configurable.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> drivers/i2c/busses/i2c-meson.c | 32 ++++++++++++++++++++++++++++----
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
> index 88d15b92ec35..517f2cddeff3 100644
> --- a/drivers/i2c/busses/i2c-meson.c
> +++ b/drivers/i2c/busses/i2c-meson.c
> @@ -16,6 +16,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/types.h>
>
> @@ -57,6 +58,10 @@ enum {
> STATE_WRITE,
> };
>
> +struct meson_i2c_data {
> + unsigned char div_factor;
> +};
> +
> /**
> * struct meson_i2c - Meson I2C device private data
> *
> @@ -93,6 +98,8 @@ struct meson_i2c {
> struct completion done;
> u32 tokens[2];
> int num_tokens;
> +
> + struct meson_i2c_data *data;
> };
>
> static void meson_i2c_set_mask(struct meson_i2c *i2c, int reg, u32 mask,
> @@ -128,7 +135,7 @@ static void meson_i2c_set_clk_div(struct meson_i2c *i2c, unsigned int freq)
> unsigned long clk_rate = clk_get_rate(i2c->clk);
> unsigned int div;
>
> - div = DIV_ROUND_UP(clk_rate, freq * 4);
> + div = DIV_ROUND_UP(clk_rate, freq * i2c->data->div_factor);
>
> /* clock divider has 12 bits */
> if (div >= (1 << 12)) {
> @@ -376,6 +383,9 @@ static int meson_i2c_probe(struct platform_device *pdev)
> spin_lock_init(&i2c->lock);
> init_completion(&i2c->done);
>
> + i2c->data = (struct meson_i2c_data *)
> + of_device_get_match_data(&pdev->dev);
> +
> i2c->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(i2c->clk)) {
> dev_err(&pdev->dev, "can't get device clock\n");
> @@ -440,11 +450,25 @@ static int meson_i2c_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct meson_i2c_data i2c_meson6_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_gxbb_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_axg_data = {
> + .div_factor = 3,
> +};
> +
> static const struct of_device_id meson_i2c_match[] = {
> - { .compatible = "amlogic,meson6-i2c" },
> - { .compatible = "amlogic,meson-gxbb-i2c" },
> - { },
> + { .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
> + { .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
> + { .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
> + {},
> };
> +
> MODULE_DEVICE_TABLE(of, meson_i2c_match);
>
> static struct platform_driver meson_i2c_driver = {
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 3/5] ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
From: Neil Armstrong @ 2017-11-17 13:05 UTC (permalink / raw)
To: Yixun Lan, Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c,
devicetree, Kevin Hilman
Cc: Jerome Brunet, Carlo Caione, Jian Hu, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-4-yixun.lan@amlogic.com>
Hi Yixun, Jian,
On 17/11/2017 09:02, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> There are four I2C masters in EE domain, and one I2C Master in
> AO domain, the DT info here should describe them all.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 59 ++++++++++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 57faaa9d8013..99e967aff439 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -129,6 +129,54 @@
> #reset-cells = <1>;
> };
>
> + i2c_m0: i2c@1f000 {
Can you use a more simple "i2c0" phandle naming instead ? or get back to the "i2c_A/B/C/D" naming like in meson_gx to keep consistency ?
[...]
> + };
> +
> + i2c_m1: i2c@1e000 {
[...]
> + };
> +
> + i2c_m2: i2c@1d000 {
[...]
> + };
> +
> + i2c_m3: i2c@1c000 {
[...]
> + };
> +
> uart_A: serial@24000 {
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> reg = <0x0 0x24000 0x0 0x14>;
> @@ -312,6 +360,17 @@
> };
> };
>
> + i2c_ao: i2c@5000 {
Can you keep the same "i2c_AO" as in meson-gx ?
[...]
> + };
> +
> uart_AO: serial@3000 {
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
> reg = <0x0 0x3000 0x0 0x18>;
>
Neil
^ permalink raw reply
* Re: [PATCH 4/5] ARM64: dts: meson-axg: describe pin DT info for I2C controller
From: Neil Armstrong @ 2017-11-17 13:06 UTC (permalink / raw)
To: Yixun Lan, Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c,
devicetree, Kevin Hilman
Cc: Jerome Brunet, Carlo Caione, Jian Hu, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-5-yixun.lan@amlogic.com>
On 17/11/2017 09:02, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Describe all the pin mux for the I2C controller which found in
> Meson-AXG SoC.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 64 ++++++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 99e967aff439..edbfd6022078 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -304,6 +304,70 @@
> function = "eth";
> };
> };
> +
> + i2c_m0_pins: i2c_m0 {
> + mux {
> + groups = "i2c_sck_m0",
> + "i2c_sda_m0";
> + function = "i2c_m0";
> + };
> + };
> +
> + i2c_m1_z_pins: i2c_m1_z {
> + mux {
> + groups = "i2c_sck_m1_z",
> + "i2c_sda_m1_z";
> + function = "i2c_m1";
> + };
> + };
> +
> + i2c_m1_x_pins: i2c_m1_x {
> + mux {
> + groups = "i2c_sck_m1_x",
> + "i2c_sda_m1_x";
> + function = "i2c_m1";
> + };
> + };
> +
> + i2c_m2_x_pins: i2c_m2_x {
> + mux {
> + groups = "i2c_sck_m2_x",
> + "i2c_sda_m2_x";
> + function = "i2c_m2";
> + };
> + };
> +
> + i2c_m2_a_pins: i2c_m2_a {
> + mux {
> + groups = "i2c_sck_m2_a",
> + "i2c_sda_m2_a";
> + function = "i2c_m2";
> + };
> + };
> +
> + i2c_m3_a6_pins: i2c_m3_a6 {
> + mux {
> + groups = "i2c_sda_m3_a6",
> + "i2c_sck_m3_a7";
> + function = "i2c_m3";
> + };
> + };
> +
> + i2c_m3_a12_pins: i2c_m3_a12 {
> + mux {
> + groups = "i2c_sda_m3_a12",
> + "i2c_sck_m3_a13";
> + function = "i2c_m3";
> + };
> + };
> +
> + i2c_m3_a19_pins: i2c_m3_a19 {
> + mux {
> + groups = "i2c_sda_m3_a19",
> + "i2c_sck_m3_a20";
> + function = "i2c_m3";
> + };
> + };
> };
> };
>
>
Same here fore the naming of the i2c nodes.
Neil
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: meson-axg: add new reset DT node
From: Neil Armstrong @ 2017-11-17 13:08 UTC (permalink / raw)
To: Yixun Lan, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Kevin Hilman
Cc: Philipp Zabel, Jerome Brunet, Carlo Caione,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171110084659.31641-1-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On 10/11/2017 09:46, Yixun Lan wrote:
> Add reset DT node for Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index e0fb860e12c5..65945c6c8b65 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -123,6 +123,12 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
>
> + reset: reset-controller@1004 {
> + compatible = "amlogic,meson-axg-reset";
> + reg = <0x0 0x01004 0x0 0x9c>;
> + #reset-cells = <1>;
> + };
> +
> uart_A: serial@24000 {
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
> reg = <0x0 0x24000 0x0 0x14>;
>
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@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] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Shawn Guo @ 2017-11-17 13:10 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Rob Herring, Rob Herring, Mark Rutland, Russell King,
Sascha Hauer, Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117102404.6678-1-lukma-ynQEQJNshbs@public.gmane.org>
On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> This is the support for aa070mc01-ca1 Mitsubishi display.
>
> Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d9d0c82e7d20..10b3ad078dea 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-cm-fx6.dtb \
> imx6q-cubox-i.dtb \
> imx6q-dfi-fs700-m60.dtb \
> + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> imx6q-display5-tianma-tm070-1280x768.dtb \
> imx6q-dmo-edmqmx6.dtb \
> imx6q-evi.dtb \
<snip>
> +#include "imx6q-display5.dtsi"
> +
> +&panel {
> + compatible = "mitsubishi,aa070mc01-ca1";
> +};
How many DTB files do you want to add for this display5 board? It's
obvious no fun to maintain a bunch of DTB files for all the panels this
board can support. Let's stop right here.
Shawn
> +
> +&ldb {
> + lvds0: lvds-channel@0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <24>;
> + };
> +};
> --
> 2.11.0
>
--
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