* [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
From: Rob Herring @ 2018-01-03 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-7-jernej.skrabec@siol.net>
On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
> This commit adds all necessary compatibles and descriptions needed to
> implement A83T HDMI pipeline.
>
> Mixer is already properly described, so only compatible is added.
>
> However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,
> contrary to all TCONs currently described. Because of that, TCON
> documentation is extended.
>
> A83T features Synopsys DW HDMI controller with a custom PHY which looks
> like Synopsys Gen2 PHY with few additions. Since there is no
> documentation, needed properties were found out through experimentation
> and reading BSP code.
>
> At the end, example is added for newer SoCs, which features DE2 and DW
> HDMI.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 188 ++++++++++++++++++++-
> 1 file changed, 181 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 9f073af4c711..3eca258096a5 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -64,6 +64,40 @@ Required properties:
> first port should be the input endpoint. The second should be the
> output, usually to an HDMI connector.
>
> +DWC HDMI TX Encoder
> +-----------------------------
> +
> +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> +
> +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> +following device-specific properties.
> +
> +Required properties:
> +
> + - compatible: value must be one of:
> + * "allwinner,sun8i-a83t-dw-hdmi"
> + - reg: two pairs of base address and size of memory-mapped region, first
> + for controller and second for PHY
> + registers.
Seems like the phy should be a separate node and use the phy binding.
You can use the phy binding even if you don't use the kernel phy
framework...
> + - reg-io-width: See dw_hdmi.txt. Shall be 1.
> + - interrupts: HDMI interrupt number
> + - clocks: phandles to the clocks feeding the HDMI encoder
> + * iahb: the HDMI bus clock
> + * isfr: the HDMI register clock
> + * tmds: the HDMI tmds clock
> + - clock-names: the clock names mentioned above
> + - resets: phandles to the reset controllers driving the encoder
> + * ctrl: the reset line for the controller
> + * phy: the reset line for the PHY
> + - reset-names: the reset names mentioned above
> +
> + - ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> + first port should be the input endpoint. The second should be the
> + output, usually to an HDMI connector.
> +
> TV Encoder
> ----------
>
> @@ -94,18 +128,17 @@ Required properties:
> * allwinner,sun7i-a20-tcon
> * allwinner,sun8i-a33-tcon
> * allwinner,sun8i-a83t-tcon-lcd
> + * allwinner,sun8i-a83t-tcon-tv
> * allwinner,sun8i-v3s-tcon
> - reg: base address and size of memory-mapped region
> - interrupts: interrupt associated to this IP
> - - clocks: phandles to the clocks feeding the TCON. Three are needed:
> + - clocks: phandles to the clocks feeding the TCON. One is needed:
> - 'ahb': the interface clocks
> - - 'tcon-ch0': The clock driving the TCON channel 0
> - resets: phandles to the reset controllers driving the encoder
> - "lcd": the reset line for the TCON channel 0
>
> - clock-names: the clock names mentioned above
> - reset-names: the reset names mentioned above
> - - clock-output-names: Name of the pixel clock created
>
> - ports: A ports node with endpoint definitions as defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt. The
> @@ -119,11 +152,31 @@ Required properties:
> channel the endpoint is associated to. If that property is not
> present, the endpoint number will be used as the channel number.
>
> -On SoCs other than the A33 and V3s, there is one more clock required:
> +Following compatibles:
> + * allwinner,sun4i-a10-tcon
> + * allwinner,sun5i-a13-tcon
> + * allwinner,sun6i-a31-tcon
> + * allwinner,sun6i-a31s-tcon
> + * allwinner,sun7i-a20-tcon
> + * allwinner,sun8i-a33-tcon
> + * allwinner,sun8i-a83t-tcon-lcd
> + * allwinner,sun8i-v3s-tcon
> +have additional required properties:
> + - 'tcon-ch0': The clock driving the TCON channel 0
tcon-ch0 is a clock name, not a property.
> + - clock-output-names: Name of the pixel clock created
> +
> +For following compatibles:
> + * allwinner,sun4i-a10-tcon
> + * allwinner,sun5i-a13-tcon
> + * allwinner,sun6i-a31-tcon
> + * allwinner,sun6i-a31s-tcon
> + * allwinner,sun7i-a20-tcon
> + * allwinner,sun8i-a83t-tcon-tv
> +there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
^ permalink raw reply
* [PATCH 4/4] ARM: dts: bcm2837-rpi-3-b: add GPIO expander
From: Phil Elwell @ 2018-01-03 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <804535329.243555.1515010649018@email.1und1.de>
Hi Stefan,
On 03/01/2018 20:17, Stefan Wahren wrote:
> Hi Baruch,
>
>> Stefan Wahren <stefan.wahren@i2se.com> hat am 2. Januar 2018 um 20:03 geschrieben:
>>
>>
>> Hi Baruch,
>>
>>> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19 geschrieben:
>>
>>> + expgpio: expgpio {
>>> + compatible = "brcm,bcm2835-expgpio";
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + firmware = <&firmware>;
>>
>> Please add the gpio-line-names from Eric's patch [1].
>>
>> Thanks
>> Stefan
>>
>> [1] - https://patchwork.kernel.org/patch/9339857/
>>
>
> sorry i missed the fact that the same GPIO expander is on the CM3. So please move the exgpio node to bcm2837.dtsi and only define the gpio-line-names in this file.
The GPIO expander is not a part of the BCM2837 SoC, and not all BCM2837-based Pis have a GPIO expander - see the Pi 2+.
Phil
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2018-01-03 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103211028.619cd16d@bbrezillon>
On Wed, 3 Jan 2018 21:10:28 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Wed, 03 Jan 2018 20:58:29 +0100
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
> > Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
> >
> > > On Tue, 02 Jan 2018 20:21:09 +0100
> > > Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> > >
> > >> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
> > >>
> > >> > I think the ECC issue you faced was related to pages being written
> > >> > *and* empty. If this guess is right, the board should boot fine with
> > >> > these changes.
> > >> >
> > >> > Otherwise, please add the DEBUG define as before in both the core
> > >> > and the driver and do not hesitate to add another dump_stack()
> > >> > where it crashes (if applicable).
> > >>
> > >> The problem looks still the same :
> > >> [ 3.560163] Bad block table not found for chip 0
> > >
> > > Mmmmh ok.
> > >
> > > Can you please add this patch:
> > > http://code.bulix.org/61at9p-254626
> >
> > Well, it looks a bit better, see attached log in [1].
> > Now the BBT is detected ...
> > [ 3.310841] Bad block table found at page 131008, version 0x01
> > ...
> > [ 3.354944] Bad block table found at page 130944, version 0x01
> >
> > But all blocks are considered bad ... as if the bit logic was inverted for the
> > meaning of "bad" or "good" block, see :
> > [ 3.379825] nand_read_bbt: bad block at 0x000000000000
>
> Hm, that's weird. Can you try with the old driver (pxa3xx)?
Alternatively, you can type 'nand bad' from uboot to check if it
detects the same bad blocks.
^ permalink raw reply
* [PATCH 1/5] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Rob Herring @ 2018-01-03 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514883738-16297-1-git-send-email-jagan@amarulasolutions.com>
On Tue, Jan 02, 2018 at 02:32:14PM +0530, Jagan Teki wrote:
> This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
> which can be supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> .../display/panel/ampire,am-800480aytzqw-00h.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
> new file mode 100644
> index 0000000..bfa7a70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-800480AYTZQW-00H 7.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-800480aytzqw-00h"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
You need to be explicit as to which properties from it you are using.
Rob
^ permalink raw reply
* [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
From: Jernej Škrabec @ 2018-01-03 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103202154.eeajt3234w3adqjq@rob-hp-laptop>
Hi Rob,
Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
> On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
> > This commit adds all necessary compatibles and descriptions needed to
> > implement A83T HDMI pipeline.
> >
> > Mixer is already properly described, so only compatible is added.
> >
> > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,
> > contrary to all TCONs currently described. Because of that, TCON
> > documentation is extended.
> >
> > A83T features Synopsys DW HDMI controller with a custom PHY which looks
> > like Synopsys Gen2 PHY with few additions. Since there is no
> > documentation, needed properties were found out through experimentation
> > and reading BSP code.
> >
> > At the end, example is added for newer SoCs, which features DE2 and DW
> > HDMI.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > .../bindings/display/sunxi/sun4i-drm.txt | 188
> > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 9f073af4c711..3eca258096a5 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> >
> > @@ -64,6 +64,40 @@ Required properties:
> > first port should be the input endpoint. The second should be the
> > output, usually to an HDMI connector.
> >
> > +DWC HDMI TX Encoder
> > +-----------------------------
> > +
> > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> > +
> > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> > +following device-specific properties.
> > +
> > +Required properties:
> > +
> > + - compatible: value must be one of:
> > + * "allwinner,sun8i-a83t-dw-hdmi"
> > + - reg: two pairs of base address and size of memory-mapped region,
> > first
> > + for controller and second for PHY
> > + registers.
>
> Seems like the phy should be a separate node and use the phy binding.
> You can use the phy binding even if you don't use the kernel phy
> framework...
Unfortunately, it's not so straighforward. Phy is actually accessed through
I2C implemented in HDMI controller. Second memory region in this case has
small influence on phy. However, it has big influence on controller. For
example, magic number has to be written in one register in second memory
region in order to unlock read access to any register from first memory region
(controller). However, they shouldn't be merged to one region, because first
memory region requires byte access while second memory region can be accessed
per byte or word.
To complicate things more, later I want to add support for another SoC which
has same glue layer (unlocking read access, etc.) and uses memory mapped phy
registers in second memory region.
I think current binding is the least complicated way to represent this.
>
> > + - reg-io-width: See dw_hdmi.txt. Shall be 1.
> > + - interrupts: HDMI interrupt number
> > + - clocks: phandles to the clocks feeding the HDMI encoder
> > + * iahb: the HDMI bus clock
> > + * isfr: the HDMI register clock
> > + * tmds: the HDMI tmds clock
> > + - clock-names: the clock names mentioned above
> > + - resets: phandles to the reset controllers driving the encoder
> > + * ctrl: the reset line for the controller
> > + * phy: the reset line for the PHY
> > + - reset-names: the reset names mentioned above
> > +
> > + - ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > + first port should be the input endpoint. The second should be the
> > + output, usually to an HDMI connector.
> > +
> >
> > TV Encoder
> > ----------
> >
> > @@ -94,18 +128,17 @@ Required properties:
> > * allwinner,sun7i-a20-tcon
> > * allwinner,sun8i-a33-tcon
> > * allwinner,sun8i-a83t-tcon-lcd
> >
> > + * allwinner,sun8i-a83t-tcon-tv
> >
> > * allwinner,sun8i-v3s-tcon
> >
> > - reg: base address and size of memory-mapped region
> > - interrupts: interrupt associated to this IP
> >
> > - - clocks: phandles to the clocks feeding the TCON. Three are needed:
> >
> > + - clocks: phandles to the clocks feeding the TCON. One is needed:
> > - 'ahb': the interface clocks
> >
> > - - 'tcon-ch0': The clock driving the TCON channel 0
> >
> > - resets: phandles to the reset controllers driving the encoder
> >
> > - "lcd": the reset line for the TCON channel 0
> >
> > - clock-names: the clock names mentioned above
> > - reset-names: the reset names mentioned above
> >
> > - - clock-output-names: Name of the pixel clock created
> >
> > - ports: A ports node with endpoint definitions as defined in
> >
> > Documentation/devicetree/bindings/media/video-interfaces.txt. The
> >
> > @@ -119,11 +152,31 @@ Required properties:
> > channel the endpoint is associated to. If that property is not
> > present, the endpoint number will be used as the channel number.
> >
> > -On SoCs other than the A33 and V3s, there is one more clock required:
> > +Following compatibles:
> > + * allwinner,sun4i-a10-tcon
> > + * allwinner,sun5i-a13-tcon
> > + * allwinner,sun6i-a31-tcon
> > + * allwinner,sun6i-a31s-tcon
> > + * allwinner,sun7i-a20-tcon
> > + * allwinner,sun8i-a33-tcon
> > + * allwinner,sun8i-a83t-tcon-lcd
> > + * allwinner,sun8i-v3s-tcon
> > +have additional required properties:
> > + - 'tcon-ch0': The clock driving the TCON channel 0
>
> tcon-ch0 is a clock name, not a property.
right.
Best regards,
Jernej
^ permalink raw reply
* [PATCH] s3mci: mark debug_regs[] as static
From: Arnd Bergmann @ 2018-01-03 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoxizZ5vJ4h_hSo=WaqzjMc7Zq59njuESTdeMaXCV1YQA@mail.gmail.com>
On Wed, Jan 3, 2018 at 5:47 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 3 January 2018 at 10:26, Arnd Bergmann <arnd@arndb.de> wrote:
>> The global array clashes with a newly added symbol of the same name:
>>
>> drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of `debug_regs'
>> drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
>>
>> We should fix both, this one addresses the s3cmci driver by removing
>> the symbol from the global namespace.
>>
>> Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and hardware state")
>
> Seems like we need a stable tag as well, would you mind adding it in
> the next re-spin?
It doesn't seem necessary here, this only causes problems on the latest
linux-next kernel that has the b3ec9a6736f2 commit as well.
Obviously, you can just add the Cc:stable tag when applying the patch
when you consider it appropriate.
>> Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs interface")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> drivers/mmc/host/s3cmci.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
>> index 36daee1e6588..24b27e0957e7 100644
>> --- a/drivers/mmc/host/s3cmci.c
>> +++ b/drivers/mmc/host/s3cmci.c
>> @@ -1421,7 +1421,7 @@ static const struct file_operations s3cmci_fops_state = {
>>
>> #define DBG_REG(_r) { .addr = S3C2410_SDI##_r, .name = #_r }
>>
>> -struct s3cmci_reg {
>> +static struct s3cmci_reg {
>> unsigned short addr;
>> unsigned char *name;
>> } debug_regs[] = {
>
> I am not very fond of these kind of declarations/definitions. How
> about if we instead move the declaration of debug_regs[] to a separate
> line? Moreover, should it be const?
>
> static struct s3cmci_reg debug_regs[] = {
Ok, I'll resend with that changed.
Arnd
^ permalink raw reply
* [PATCH] [v2] s3mci: mark debug_regs[] as static
From: Arnd Bergmann @ 2018-01-03 22:49 UTC (permalink / raw)
To: linux-arm-kernel
The global array clashes with a newly added symbol of the same name:
drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of `debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
We should fix both, this one addresses the s3cmci driver by removing
the symbol from the global namespace. While at it, this separates
the declaration from the type definition and makes the variable const.
Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/mmc/host/s3cmci.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 36daee1e6588..f77493604312 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -1424,7 +1424,9 @@ static const struct file_operations s3cmci_fops_state = {
struct s3cmci_reg {
unsigned short addr;
unsigned char *name;
-} debug_regs[] = {
+};
+
+static const struct s3cmci_reg debug_regs[] = {
DBG_REG(CON),
DBG_REG(PRE),
DBG_REG(CMDARG),
@@ -1446,7 +1448,7 @@ struct s3cmci_reg {
static int s3cmci_regs_show(struct seq_file *seq, void *v)
{
struct s3cmci_host *host = seq->private;
- struct s3cmci_reg *rptr = debug_regs;
+ const struct s3cmci_reg *rptr = debug_regs;
for (; rptr->name; rptr++)
seq_printf(seq, "SDI%s\t=0x%08x\n", rptr->name,
--
2.9.0
^ permalink raw reply related
* [PATCH] clk: samsung: s3c: Remove unneeded enumeration
From: Chanwoo Choi @ 2018-01-03 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e178400d-12b5-7836-6fe0-cdd3b5a68107@samsung.com>
On 2018? 01? 04? 02:29, Sylwester Nawrocki wrote:
> On 11/27/2017 03:31 AM, Chanwoo Choi wrote:
>> This patch just removes the unneeded enumeration for PLL index.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>
>
> Thanks for the patch Chanwoo, I have applied it to my tree but
> I'm afraid it will now need to wait until v4.17.
No problem. Thanks.
>
> Stephen, if you decide to apply it directly for v4.16-rc1
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> --
> Thanks,
> Sylwester
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding
From: Wolfram Sang @ 2018-01-03 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-2-git-send-email-jun.gao@mediatek.com>
On Tue, Dec 19, 2017 at 02:51:01PM +0800, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> Add MT2712 i2c binding to binding file. Compare to MT8173 i2c
> controller, MT2712 has timing adjust registers which can adjust
> the internal divider of i2c source clock, SCL duty cycle, SCL
> compare point, start(repeated start) and stop time, SDA change
> time.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/e33cf956/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712
From: Wolfram Sang @ 2018-01-03 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-3-git-send-email-jun.gao@mediatek.com>
On Tue, Dec 19, 2017 at 02:51:02PM +0800, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> Add i2c compatible for MT2712. Compare to MT8173 i2c controller,
> internal divider of i2c source clock need to be configured for
> MT2712 i2c speed calculation.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/9aae6901/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.
From: Wolfram Sang @ 2018-01-03 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-4-git-send-email-jun.gao@mediatek.com>
On Tue, Dec 19, 2017 at 02:51:03PM +0800, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> Make sure i2c module clock has been enabled before i2c registers
> access.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/55e8bcab/attachment.sig>
^ permalink raw reply
* [RFC] pwm-backlight: Allow backlight to remain disabled on boot
From: hl @ 2018-01-04 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com>
Hi All,
??? Since many panel power sequence request backlight stay disable
before panel power ready, but with now pwm-backlight drvier, it default to
enable backlight when pwm-backlight probe, it mess up the panel power
sequence.
So we need this patch. This patch have been fly for a long time, does
anyone have plan
to merge it?
On Thursday, July 31, 2014 07:42 PM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The default for backlight devices is to be enabled immediately when
> registering with the backlight core. This can be useful for setups that
> use a simple framebuffer device and where the backlight cannot otherwise
> be hooked up to the panel.
>
> However, when dealing with more complex setups, such as those of recent
> ARM SoCs, this can be problematic. Since the backlight is usually setup
> separately from the display controller, the probe order is not usually
> deterministic. That can lead to situations where the backlight will be
> powered up and the panel will show an uninitialized framebuffer.
>
> Furthermore, subsystems such as DRM have advanced functionality to set
> the power mode of a panel. In order to allow such setups to power up the
> panel at exactly the right moment, a way is needed to prevent the
> backlight core from powering the backlight up automatically when it is
> registered.
>
> This commit introduces a new boot_off field in the platform data (and
> also implements getting the same information from device tree). When set
> the initial backlight power mode will be set to "off".
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> I've been meaning to send this for a while but was always holding back
> because of the indoctrination that this type of configuration shouldn't
> be part of device tree. However this issue was recently raised again in
> the context of power up sequences for display panels. As described above
> the issue is that panel datasheets recommend that the backlight attached
> to a panel be turned on at the very last step to avoid visual glitches
> during the panel's power up sequence. With the current implementation it
> is typical for the backlight to be probed before the display panel. That
> has, in many cases, the side-effect of enabling the backlight, therefore
> making the screen content visible before it's actually initialized.
>
> Some panels come up with random garbage when uninitialized, others show
> all white. With some luck the panel will be all black and users won't
> really notice.
>
> This patch is an attempt to enable boards to override the default of
> turning on the backlight for the pwm-backlight driver. I'm not sure if
> there was a specific reason to turn on the backlight by default when
> this driver was initially written, but the fact is that since it has
> pretty much always been like this we can't really go and change the
> default, otherwise a lot of people may end up with no backlight and no
> clue as to how to enable it. So the only reasonable thing we can do is
> to keep the old behaviour and give new boards a way to override it if
> they know that some other part of the stack will enable it at the right
> moment.
>
> .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 +
> drivers/video/backlight/pwm_bl.c | 8 ++++++++
> include/linux/pwm_backlight.h | 2 ++
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> index 764db86d441a..65e001a1733d 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> @@ -17,6 +17,7 @@ Optional properties:
> "pwms" property (see PWM binding[0])
> - enable-gpios: contains a single GPIO specifier for the GPIO which enables
> and disables the backlight (see GPIO binding[1])
> + - backlight-boot-off: keep the backlight disabled on boot
>
> [0]: Documentation/devicetree/bindings/pwm/pwm.txt
> [1]: Documentation/devicetree/bindings/gpio/gpio.txt
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index d7a3d13e72ec..62adfc9d37a7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -173,6 +173,8 @@ static int pwm_backlight_parse_dt(struct device *dev,
> data->max_brightness--;
> }
>
> + data->boot_off = of_property_read_bool(node, "backlight-boot-off");
> +
> return 0;
> }
>
> @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> }
>
> bl->props.brightness = data->dft_brightness;
> +
> + if (data->boot_off)
> + bl->props.power = FB_BLANK_POWERDOWN;
> + else
> + bl->props.power = FB_BLANK_UNBLANK;
> +
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
> diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
> index efdd9227a49c..1fc14989da4a 100644
> --- a/include/linux/pwm_backlight.h
> +++ b/include/linux/pwm_backlight.h
> @@ -15,6 +15,8 @@ struct platform_pwm_backlight_data {
> unsigned int *levels;
> /* TODO remove once all users are switched to gpiod_* API */
> int enable_gpio;
> + bool boot_off;
> +
> int (*init)(struct device *dev);
> int (*notify)(struct device *dev, int brightness);
> void (*notify_after)(struct device *dev, int brightness);
^ permalink raw reply
* [PATCH 4/4] ARM: dts: bcm2837-rpi-3-b: add GPIO expander
From: Peter Robinson @ 2018-01-04 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3993684b-5b99-6c38-6247-999f7564762b@raspberrypi.org>
>>> Stefan Wahren <stefan.wahren@i2se.com> hat am 2. Januar 2018 um 20:03
>>> geschrieben:
>>>
>>>
>>> Hi Baruch,
>>>
>>>> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19
>>>> geschrieben:
>>>
>>>
>>>> + expgpio: expgpio {
>>>> + compatible = "brcm,bcm2835-expgpio";
>>>> + gpio-controller;
>>>> + #gpio-cells = <2>;
>>>> + firmware = <&firmware>;
>>>
>>>
>>> Please add the gpio-line-names from Eric's patch [1].
>>>
>>> Thanks
>>> Stefan
>>>
>>> [1] - https://patchwork.kernel.org/patch/9339857/
>>>
>>
>> sorry i missed the fact that the same GPIO expander is on the CM3. So
>> please move the exgpio node to bcm2837.dtsi and only define the
>> gpio-line-names in this file.
>
>
> The GPIO expander is not a part of the BCM2837 SoC, and not all
> BCM2837-based Pis have a GPIO expander - see the Pi 2+.
There's two ways that's generally handled upstream, either just
duplicate across the two .dts files or to put it in a separate .dtsi
and include it in the relevant .dts files, see arch/arm/boot/dts/axp*
as relevant examples.
Peter
^ permalink raw reply
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Xiongfeng Wang @ 2018-01-04 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ac912cf-927d-5482-9ceb-b497a547fc2e@arm.com>
On 2018/1/4 1:32, Jeremy Linton wrote:
> Hi,
>
> On 01/03/2018 08:29 AM, Sudeep Holla wrote:
>>
>> On 02/01/18 02:29, Xiongfeng Wang wrote:
>>> Hi,
>>>
>>> On 2017/12/18 20:42, Morten Rasmussen wrote:
>>>> On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
>>>>>> [+Morten, Dietmar]
>>>>>>
>>>>>> $SUBJECT should be:
>>>>>>
>>>>>> arm64: topology: rename cluster_id
>>>>>
>>> [cut]
>>>>>
>>> I think we still need the information describing which cores are in one
>>> cluster. Many arm64 chips have the architecture core/cluster/socket. Cores
>>> in one cluster may share a same L2 cache. That information can be used to
>>> build the sched_domain. If we put cores in one cluster in one sched_domain,
>>> the performance will be better.(please see kernel/sched/topology.c:1197,
>>> cpu_coregroup_mask() uses 'core_sibling' to build a multi-core
>>> sched_domain).
>>
>> We get all the cache information from DT/ACPI PPTT(mainly topology) and now
>> even the geometry. So ideally, the sharing information must come from that.
>> Any other solution might end up in conflict if DT/PPTT and that mismatch.
>>
>>> So I think we still need variable to record which cores are in one
>>> sched_domain for future use.
>>
>> I tend to say no, at-least not as is.
>>
>
> Well, either way, with DynamiQ (and a55/a75) the cores have private L2's, which means that the cluster sharing is happening at what is then the L3 level. So, the code I had in earlier versions would have needed tweaks to deal with that anyway.
>
> IMHO, if we want to detect this kind of sharing for future scheduling domains, it should probably be done independent of PPTT/DT/MIPDR by picking out shared cache levels from struct cacheinfo *. Which makes that change unrelated to the basic population of cacheinfo and cpu_topology in this patchset.
>
I think we need to build scheduling domains not only on the cache-sharing information,
but also some other information, such as which cores use the same cache coherent interconnect
(I don't know the detail, I just guess)
I think PPTT is used to report the cores topology, which cores are more related to each other.
They may share the same cache, or use the same CCI, or are physically near to each other.
I think we should use this information to build MC(multi-cores) scheduling domains.
Or maybe we can just discard the MC scheduling domain and handle this scheduling-domain-building
task to the NUMA subsystem entirely, I don't know if it is proper.
Thanks,
Xiongfeng
>
> .
>
^ permalink raw reply
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Xiongfeng Wang @ 2018-01-04 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ac912cf-927d-5482-9ceb-b497a547fc2e@arm.com>
On 2018/1/4 1:32, Jeremy Linton wrote:
> Hi,
>
> On 01/03/2018 08:29 AM, Sudeep Holla wrote:
>>
>> On 02/01/18 02:29, Xiongfeng Wang wrote:
>>> Hi,
>>>
>>> On 2017/12/18 20:42, Morten Rasmussen wrote:
>>>> On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
>>>>>> [+Morten, Dietmar]
>>>>>>
>>>>>> $SUBJECT should be:
>>>>>>
>>>>>> arm64: topology: rename cluster_id
>>>>>
>>> [cut]
>>>>>
>>> I think we still need the information describing which cores are in one
>>> cluster. Many arm64 chips have the architecture core/cluster/socket. Cores
>>> in one cluster may share a same L2 cache. That information can be used to
>>> build the sched_domain. If we put cores in one cluster in one sched_domain,
>>> the performance will be better.(please see kernel/sched/topology.c:1197,
>>> cpu_coregroup_mask() uses 'core_sibling' to build a multi-core
>>> sched_domain).
>>
>> We get all the cache information from DT/ACPI PPTT(mainly topology) and now
>> even the geometry. So ideally, the sharing information must come from that.
>> Any other solution might end up in conflict if DT/PPTT and that mismatch.
Sorry, I didn't express myself clearly. There may be some misunderstanding above.
I mean that PPTT report the cores topology, such as a level of the topology tree maybe cores in one cluster,
another level maybe cores in one package.
We not only need variable in 'struct topology' to record which cores are in one package,
but also need variable to record which cores are in one cluster.
>>
>>> So I think we still need variable to record which cores are in one
>>> sched_domain for future use.
>>
>> I tend to say no, at-least not as is.
>>
>
> Well, either way, with DynamiQ (and a55/a75) the cores have private L2's, which means that the cluster sharing is happening at what is then the L3 level. So, the code I had in earlier versions would have needed tweaks to deal with that anyway.
>
> IMHO, if we want to detect this kind of sharing for future scheduling domains, it should probably be done independent of PPTT/DT/MIPDR by picking out shared cache levels from struct cacheinfo *. Which makes that change unrelated to the basic population of cacheinfo and cpu_topology in this patchset.
>
>
> .
>
^ permalink raw reply
* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Florian Fainelli @ 2018-01-04 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211175901.vbw7fpeijpqbp263@armageddon.cambridge.arm.com>
On 12/11/2017 09:59 AM, Catalin Marinas wrote:
> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote:
>> Patches are also pushed here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
>>
>> Feedback and testing welcome. At this point, I'd like to start thinking
>> about getting this merged for 4.16.
>
> For the record, the fixed up version was pushed by Will here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti
>
> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as
> above).
Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there
a plan to get the ARM64/KPTI patches backported towards stable trees as
well?
Thanks!
--
Florian
^ permalink raw reply
* [PATCH v2 0/7] ARM: dts: imx6q: engicam LVDS panel changes
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
Series add LVDS panel attributes on panel drivers instead of defining
them in dts nodes, and also added new icorem6 engicam boards
Jagan Teki (7):
drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
ARM: dts: imx6dl-icore: Add LVDS node
drm/panel: simple: Add support for KEO TX31D200VM0BAA
ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple
ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7
initial support
ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit
support
.../display/panel/ampire,am-800480aytzqw-00h.txt | 25 +++++++++
.../bindings/display/panel/koe,tx31d200vm0baa.txt | 25 +++++++++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-icore.dts | 28 ++++++++++
arch/arm/boot/dts/imx6q-icore-mipi.dts | 25 +++++++++
arch/arm/boot/dts/imx6q-icore-ofcap12.dts | 31 ++++++-----
arch/arm/boot/dts/imx6q-icore-ofcap7.dts | 65 ++++++++++++++++++++++
arch/arm/boot/dts/imx6q-icore.dts | 31 ++++++-----
arch/arm/boot/dts/imx6qdl-icore.dtsi | 25 ++++++++-
drivers/gpu/drm/panel/panel-simple.c | 54 ++++++++++++++++++
10 files changed, 282 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
create mode 100644 arch/arm/boot/dts/imx6q-icore-mipi.dts
create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
which can be supported by the simple panel driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Updated binding info about optional properties, node and example
.../display/panel/ampire,am-800480aytzqw-00h.txt | 25 ++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
new file mode 100644
index 0000000..abb5eee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
@@ -0,0 +1,25 @@
+Ampire AM-800480AYTZQW-00H 7.0" WVGA TFT LCD panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "ampire,am-800480aytzqw-00h"
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LVDS panel input.
+
+Example:
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8fd0b01..e262462 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -412,6 +412,30 @@ static const struct panel_desc ampire_am_480272h3tmqw_t01h = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct display_timing ampire_am_800480aytzqw_00h_timing = {
+ .pixelclock = { 27700000, 29200000, 39600000 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 12, 40, 212 },
+ .hback_porch = { 88, 88, 88 },
+ .hsync_len = { 1, 2, 40 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 1, 13, 88 },
+ .vback_porch = { 32, 32, 32 },
+ .vsync_len = { 1, 2, 3 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc ampire_am_800480aytzqw_00h = {
+ .timings = &ire_am_800480aytzqw_00h_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 33333,
.hdisplay = 800,
@@ -2054,6 +2078,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
+ .compatible = "ampire,am-800480aytzqw-00h",
+ .data = &ire_am_800480aytzqw_00h,
+ }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
}, {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/7] ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
Switch to use ampire,am-800480aytzqw-00h LVDS timings from
panel-simple instead hard coding the same in dts.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none
arch/arm/boot/dts/imx6q-icore.dts | 31 +++++++++++++++++--------------
arch/arm/boot/dts/imx6qdl-icore.dtsi | 2 +-
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-icore.dts b/arch/arm/boot/dts/imx6q-icore.dts
index 5613dd9..c8e464e 100644
--- a/arch/arm/boot/dts/imx6q-icore.dts
+++ b/arch/arm/boot/dts/imx6q-icore.dts
@@ -48,6 +48,17 @@
/ {
model = "Engicam i.CoreM6 Quad/Dual Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&can1 {
@@ -71,22 +82,14 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
+ reg = <0>;
status = "okay";
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <60000000>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <30>;
- hfront-porch = <30>;
- vback-porch = <5>;
- vfront-porch = <5>;
- hsync-len = <64>;
- vsync-len = <20>;
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index a1b469c..5fd9e00 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -49,7 +49,7 @@
reg = <0x10000000 0x80000000>;
};
- backlight {
+ backlight_lvds: backlight-lvds {
compatible = "pwm-backlight";
pwms = <&pwm3 0 100000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/7] ARM: dts: imx6dl-icore: Add LVDS node
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
Add ampire,am-800480aytzqw-00h LVDS support by using
timings from panel-simple.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none
arch/arm/boot/dts/imx6dl-icore.dts | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-icore.dts b/arch/arm/boot/dts/imx6dl-icore.dts
index 971f9fc..74bff84 100644
--- a/arch/arm/boot/dts/imx6dl-icore.dts
+++ b/arch/arm/boot/dts/imx6dl-icore.dts
@@ -48,6 +48,17 @@
/ {
model = "Engicam i.CoreM6 DualLite/Solo Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6dl";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&can1 {
@@ -66,3 +77,20 @@
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
};
};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ reg = <0>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
This adds support for the Kaohsiung Opto-Electronics.,
TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
supported by the simple panel driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Updated binding info about optional properties, node and example
.../bindings/display/panel/koe,tx31d200vm0baa.txt | 25 ++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
diff --git a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
new file mode 100644
index 0000000..6a036ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
@@ -0,0 +1,25 @@
+Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "koe,tx31d200vm0baa"
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LVDS panel input.
+
+Example:
+ panel {
+ compatible = "koe,tx31d200vm0baa";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e262462..ef3973d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1267,6 +1267,30 @@ static const struct panel_desc innolux_zj070na_01p = {
},
};
+static const struct display_timing koe_tx31d200vm0baa_timing = {
+ .pixelclock = { 39600000, 43200000, 48000000 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 16, 36, 56 },
+ .hback_porch = { 16, 36, 56 },
+ .hsync_len = { 8, 8, 8 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 6, 21, 33.5 },
+ .vback_porch = { 6, 21, 33.5 },
+ .vsync_len = { 8, 8, 8 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc koe_tx31d200vm0baa = {
+ .timings = &koe_tx31d200vm0baa_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 292,
+ .height = 109,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct display_timing kyo_tcg121xglp_timing = {
.pixelclock = { 52000000, 65000000, 71000000 },
.hactive = { 1024, 1024, 1024 },
@@ -2180,6 +2204,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
+ .compatible = "koe,tx31d200vm0baa",
+ .data = &koe_tx31d200vm0baa,
+ }, {
.compatible = "kyo,tcg121xglp",
.data = &kyo_tcg121xglp,
}, {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/7] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
Switch to use koe_tx31d200vm0baa LVDS timings from
panel-simple instead hard coding the same in dts.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none
arch/arm/boot/dts/imx6q-icore-ofcap12.dts | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap12.dts b/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
index 9e230f5..6e27c81 100644
--- a/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
@@ -48,28 +48,31 @@
/ {
model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 12 Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "koe,tx31d200vm0baa";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&ldb {
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
+ reg = <0>;
status = "okay";
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <46800000>;
- hactive = <1280>;
- vactive = <480>;
- hback-porch = <353>;
- hfront-porch = <47>;
- vback-porch = <39>;
- vfront-porch = <4>;
- hsync-len = <8>;
- vsync-len = <2>;
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop user
friendly graphic user interface.
ofcap 7 general features:
CPU NXP Freescale i.MX6Q rev1.5 at 792 MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC, 512MB
LVDS Display TFT 7" industrial, 800x480 resolution
Touchscreen EP0700M06 EDT Polytouch capacitive touch screen
Backlight LED backlight, brightness 300 Cd/m2
Power supply 15 to 30 Vdc
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Updated licence text - remove big notes, add SPDX and author
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore-ofcap7.dts | 65 ++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0bb8db3..11d0544 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -451,6 +451,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
+ imx6q-icore-ofcap7.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-mccmon6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap7.dts b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
new file mode 100644
index 0000000..6ff7a0a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Engicam S.r.l.
+ * Copyright (C) 2017 Amarula Solutions B.V.
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 7 Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ ep0700m06: touchscreen at 38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_edt_ft5x06>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <30 IRQ_TYPE_NONE>;
+ reset-gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ reg = <0>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_edt_ft5x06: edt-ft5x06grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30 0x1b0b0 /*interrupt*/
+ MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00 0x1b0b0 /*reset edt*/
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/7] ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support
From: Jagan Teki @ 2018-01-04 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-1-git-send-email-jagan@amarulasolutions.com>
i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
Android and video capture application.
notable features:
CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9 at 800MHz
Memory Up to 2 GB DDR3-1066
Video Interfaces Up to 1 Parallel Up to 2 LVDS HDMI 1.4
port 8 bit CSI INPUT MIPI-CSI INPUT
1 x 10/100 Ethernet interface, 2 x USB, 1 x PCIe, 1 x I2S etc
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- new patch
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore-mipi.dts | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-icore.dtsi | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore-mipi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 11d0544..9b6a5ef 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -449,6 +449,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-hummingboard-emmc-som-v15.dtb \
imx6q-hummingboard-som-v15.dtb \
imx6q-icore.dtb \
+ imx6q-icore-mipi.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
imx6q-icore-ofcap7.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-mipi.dts b/arch/arm/boot/dts/imx6q-icore-mipi.dts
new file mode 100644
index 0000000..acd3d33
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-mipi.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Engicam S.r.l.
+ * Copyright (C) 2017 Amarula Solutions B.V.
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual MIPI Starter Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&usdhc3 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 5fd9e00..d696447 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -265,6 +265,14 @@
status = "okay";
};
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ no-1-8-v;
+ non-removable;
+ status = "disabled";
+};
+
&iomuxc {
pinctrl_audmux: audmux {
fsl,pins = <
@@ -378,4 +386,19 @@
MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17070
>;
};
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ >;
+ };
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: vkilari at codeaurora.org @ 2018-01-04 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f89c8f07-bef6-c20b-cb2e-eaa2121689b3@arm.com>
Hi Jeremy
> -----Original Message-----
> From: linux-arm-kernel
[mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Jeremy Linton
> Sent: Wednesday, January 3, 2018 10:28 PM
> To: vkilari at codeaurora.org
> Cc: 'Mark Rutland' <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
> Jayachandran.Nair at cavium.com; 'Lorenzo Pieralisi'
> <lorenzo.pieralisi@arm.com>; austinwc at codeaurora.org; 'Linux PM' <linux-
> pm at vger.kernel.org>; jhugo at codeaurora.org; 'Catalin Marinas'
> <catalin.marinas@arm.com>; 'Sudeep Holla' <sudeep.holla@arm.com>; 'Will
> Deacon' <will.deacon@arm.com>; 'Linux Kernel Mailing List' <linux-
> kernel at vger.kernel.org>; wangxiongfeng2 at huawei.com; 'ACPI Devel Maling
> List' <linux-acpi@vger.kernel.org>; 'Viresh Kumar'
<viresh.kumar@linaro.org>;
> 'Rafael J. Wysocki' <rjw@rjwysocki.net>; 'Hanjun Guo'
> <hanjun.guo@linaro.org>; 'Greg Kroah-Hartman'
> <gregkh@linuxfoundation.org>; 'Rafael J. Wysocki' <rafael@kernel.org>; 'Al
> Stone' <ahs3@redhat.com>; linux-arm-kernel at lists.infradead.org; 'Len
Brown'
> <lenb@kernel.org>
> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
>
> Hi,
>
> On 01/03/2018 02:49 AM, vkilari at codeaurora.org wrote:
> > Hi Jeremy,
> >
> > Sorry, I don't have your previous patch emails to reply on right
> > patch context.
> > So commenting on top of this patch.
> >
> > AFAIU, the PPTT v5 patches still rely on CLIDR_EL1 register to know
> > the type of Caches enabled/available on the platform. With PPTT, it
> > should not rely on architecture registers. There can be platforms
> > which can report cache availability in PPTT but not in architecture
> > registers.
> >
> > The following code snippet shows usage of CLIDR_EL1
> >
> > In arch/arm64/kernel/cacheinfo.c
> >
> > static inline enum cache_type get_cache_type(int level) {
> > u64 clidr;
> >
> > if (level > MAX_CACHE_LEVEL)
> > return CACHE_TYPE_NOCACHE;
> > clidr = read_sysreg(clidr_el1);
> > return CLIDR_CTYPE(clidr, level); }
> >
> > static int __populate_cache_leaves(unsigned int cpu) {
> > unsigned int level, idx;
> > enum cache_type type;
> > struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> > struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> >
> > for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
> > idx < this_cpu_ci->num_leaves; idx++, level++) {
> > type = get_cache_type(level);
> > if (type == CACHE_TYPE_SEPARATE) {
> > ci_leaf_init(this_leaf++, CACHE_TYPE_DATA,
level);
> > ci_leaf_init(this_leaf++, CACHE_TYPE_INST,
level);
> > } else {
> > ci_leaf_init(this_leaf++, type, level);
> > }
> > }
> > return 0;
> > }
> >
> > In populate_cache_leaves() the cache type is read from CLIDR_EL1
register.
> > If CLIDR_EL1 reports CACHE_TYPE_NOCACHE for a particular level then
> > sysfs entry /sys/devices/system/cpu/cpu0/index<n>/type is not created
> > and hence userspace tools like lstopo will not report this cache
> > level.
>
>
> This sounds suspiciously like one of things tweaked between v4->v5. If you
look
> at update_cache_properties() in patch 2/9, you will see that we only
> update/find NOCACHE nodes and convert them to UNIFIED when all the
> attributes in the node are supplied.
>
> This means that if the node has an incomplete set of attributes we won't
update
> it. Can you verify that you have all those attributes set for nodes which
aren't
> being described by the hardware?
Thanks for pointing out.
Why do we need to check for set of attributes and decide it as UNIFIED
cache.?
We can get cache type from attributes bits[3:2] if cache type valid flag is
set
irrespective of other attributes. If cache type valid flag is not set then
we can assume
it as NOCACHE type as neither architecture register nor in PPTT has valid
cache type.
>
> Thanks,
>
>
> >
> > Regards
> > Vijay
> >
> >> -----Original Message-----
> >> From: linux-arm-kernel
> > [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> >> On Behalf Of Rafael J. Wysocki
> >> Sent: Thursday, December 14, 2017 4:40 AM
> >> To: Jeremy Linton <jeremy.linton@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
> >> Jayachandran.Nair at cavium.com; Lorenzo Pieralisi
> >> <lorenzo.pieralisi@arm.com>; Catalin Marinas
> >> <catalin.marinas@arm.com>; Rafael J. Wysocki <rafael@kernel.org>;
> >> jhugo at codeaurora.org; Will Deacon <will.deacon@arm.com>; Linux PM
> <linux-pm@vger.kernel.org>; Rafael J.
> >> Wysocki <rjw@rjwysocki.net>; Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> >> kernel at vger.kernel.org>; ACPI Devel Maling List
> > <linux-acpi@vger.kernel.org>;
> >> Viresh Kumar <viresh.kumar@linaro.org>; Hanjun Guo
> >> <hanjun.guo@linaro.org>; Al Stone <ahs3@redhat.com>; Sudeep Holla
> >> <sudeep.holla@arm.com>; austinwc at codeaurora.org;
> >> wangxiongfeng2 at huawei.com; linux-arm-kernel at lists.infradead.org; Len
> >> Brown <lenb@kernel.org>
> >> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
> >>
> >> On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton
> >> <jeremy.linton@arm.com>
> >> wrote:
> >>> Hi,
> >>>
> >>>
> >>> On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
> >>>>
> >>>> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
> >>>> <lorenzo.pieralisi@arm.com> wrote:
> >>>>>
> >>>>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> First, thanks for taking a look at this.
> >>>>>>
> >>>>>> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
> >>>>>>>
> >>>>>>> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> >>>>>>>>
> >>>>>>>> The PPTT can be used to determine the groupings of CPU's at
> >>>>>>>> given levels in the system. Lets add a few routines to the PPTT
> >>>>>>>> parsing code to return a unique id for each unique level in the
> >>>>>>>> processor hierarchy. This can then be matched to build
> >>>>>>>> thread/core/cluster/die/package/etc mappings for each
> >>>>>>>> processing element in the system.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>>>>>>
> >>>>>>>
> >>>>>>> Why can't this be folded into patch [2/9]?
> >>>>>>
> >>>>>>
> >>>>>> It can, and I will be happy squash it.
> >>>>>>
> >>>>>> It was requested that the topology portion of the parser be split
> >>>>>> out back in v3.
> >>>>>>
> >>>>>> https://www.spinics.net/lists/linux-acpi/msg78487.html
> >>>>>
> >>>>>
> >>>>> I asked to split cache/topology since I am not familiar with cache
> >>>>> code and Sudeep - who looks after the cache code - won't be able
> >>>>> to review this series in time for v4.16.
> >>>>
> >>>>
> >>>> OK, so why do we need it in 4.16?
> >>>
> >>>
> >>> I think its more case of as soon as possible. That is because there
> >>> are machines where the topology is completely incorrect due to
> >>> assumptions the kernel makes based on registers that aren't defined
> >>> for that purpose (say describing which cores are in a physical
> >>> socket, or LLC's attached to interconnects or memory controllers).
> >>>
> >>> This incorrect topology information is reported to things like the
> >>> kernel scheduler, which then makes poor scheduling decisions
> >>> resulting in sub-optimal system performance.
> >>>
> >>> This patchset (and ACPI 6.2) clears up a lot of those problems.
> >>
> >> As long as the ACPI tables are as expected that is, I suppose?
> >>
> >> Anyway, fair enough, but I don't want to rush it in.
> >>
> >> Thanks,
> >> Rafael
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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