* [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: Daniel Kurtz @ 2016-11-18 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479361006.13083.7.camel@mtksdaap41>
Hi CK,
On Thu, Nov 17, 2016 at 1:36 PM, CK Hu <ck.hu@mediatek.com> wrote:
> Hi, Jitao:
>
>
> On Wed, 2016-11-16 at 11:20 +0800, Jitao Shi wrote:
>> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
>> Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
>> mode, those signals will cause h-time larger than normal and reduce FPS.
>> So need to multiply a coefficient to offset the extra signal's effect.
>> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
>> Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
>>
>> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
>
> It looks good to me.
> But this patch conflict with [1] which is one patch of MT2701 series. I
> want to apply MT2701 patches first, so please help to refine this patch
> based on MT2701 patches.
I don't think the MT2701 DSI patches are quite ready yet (I just
reviewed the one below).
Can we instead land Jitao's small targeted change first, and then
rebase the MT2701 series on top.
Thanks,
-Dan
>
> [1] https://patchwork.kernel.org/patch/9422821/
>
> Regards,
> CK
>
>> ---
>> Change since v4:
>> - tune the calc comment more clear.
>> - define the phy timings as constants.
>>
>> Chnage since v3:
>> - wrapp the commit msg.
>> - fix alignment of some lines.
>>
>> Change since v2:
>> - move phy timing back to dsi_phy_timconfig.
>>
>> Change since v1:
>> - phy_timing2 and phy_timing3 refer clock cycle time.
>> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
>> ---
>>
>
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: pankaj.dubey @ 2016-11-18 3:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3360559.T0zQaY0FJ3@wuerfel>
On Thursday 17 November 2016 10:33 PM, Arnd Bergmann wrote:
> On Thursday, November 17, 2016 9:50:27 AM CET pankaj.dubey wrote:
>>
>>>>> of_scu_enable() which _only_ looks up the SCU address in DT and enables
>>>>> it if it finds it, otherwise returning failure.
>>>>>
>>>>> a9_scu_enable() which tries to use the A9 provided SCU address and
>>>>> enables it if it finds it, otherwise returning failure.
>>>>>
>>
>> OK, In that case I can see need for following four helpers as:
>>
>> 1: of_scu_enable() which will __only__ lookup the SCU address in DT and
>> enables it if it finds, otherwise return -ENOMEM failure.
>> This helper APIs is required and sufficient for most of platforms such
>> as exynos, berlin, realview, socfpga, STi, ux500, vexpress, rockchip and
>> mvebu
>>
>> 2: a9_scu_enable(), which will __only__ use A9 provided SCU address and
>> enables it, if address mapped successfully, otherwise returning failure.
>> This helper APIs is required and sufficient for two ARM platforms as of
>> now tegra and hisi.
>>
>> 3: of_scu_get_base() which will lookup the SCU address in DT and if node
>> found maps address and returns ioremapped address to caller.
>> This helper APIs is required for three ARM plaforms rockchip, mvebu and
>> ux500, along with scu_enable() API to enable and find number_of_cores.
>>
>> 4: s9_scu_iomap_base() which will internally use s9_scu_get_base() and
>> do ioremap of scu address and returns ioremapped address to the caller
>> along with ownership (caller has responsibility to unmap it).
>> This helper APIs is required to simplify SCU enable and related code in
>> two ARM plaforms BCM ans ZX.
>>
>> For remaining two ARM platforms (IMX and ZYNQ), none of these helpers
>> are useful for the time-being, as they need SCU mapping very early of
>> boot, where we can't use iomap APIs. So I will drop patches related to
>> these platforms in v2 version.
>>
>> Please let me know if any concern in this approach.
>
> I think ideally we wouldn't even need to know the virtual address
> outside of smp_scu.c. If we can move all users of the address
> into that file directly, it could become a local variable and
> we change scu_power_mode() and scu_get_core_count() instead to
> not require the address argument.
>
If we change scu_get_core_count() without address argument, what about
those platforms which are calling this API very early boot (mostly in
smp_init_cpus), during this stage we can't use iomap. These platforms
are doing static mapping of SCU base, and passing virtual address.
Currently following are platforms which needs SCU virtual address at
very early stage mostly for calling scu_get_core_count(scu_address):
IMX, ZYNQ, SPEAr, and OMAP2.
I can think of handling of these platform's early need of SCU in the
following way:
Probably we need something like early_a9_scu_get_core_count() which can
be handled in this way in smp_scu.c file itself:
+static struct map_desc scu_map __initdata = {
+ .length = SZ_256,
+ .type = MT_DEVICE,
+};
+
+static void __iomem *early_scu_map_io(void)
+{
+ unsigned long base;
+ void __iomem *scu_base;
+
+ base = scu_a9_get_base();
+ scu_map.pfn = __phys_to_pfn(base);
+ scu_map.virtual = base;
+ iotable_init(&scu_map, 1);
+ scu_base = (void __iomem *)base;
+ return scu_base;
+}
+
+/*
+ * early_a9_scu_get_core_count - Get number of CPU cores at very early boot
+ * Only platforms which needs number_of_cores during early boot should
call this
+ */
+unsigned int __init early_a9_scu_get_core_count(void)
+{
+ void __iomem *scu_base;
+
+ scu_base = early_scu_map_io();
+ return scu_get_core_count(scu_base);
+}
+
Please let me know how about using above approach to simplify platform
specific code of early users of SCU address.
Also for rest platforms, which are not using scu base at very early
stage, but are using virtual address which is mapped either from SCU
device node or using s9_scu_get_base() to map to SCU virtual address. To
separate these two we discussed to separate scu_enable in two helper
APIs as of_scu_enable and s9_scu_enable. So if we change
scu_get_core_count which do not requires address argument, this also
needs to be separated in two as of_scu_get_core_count and
s9_scu_get_core_count.
Thanks,
Pankaj Dubey
> The only user I could find outside of that file is
>
> static int shmobile_smp_scu_psr_core_disabled(int cpu)
> {
> unsigned long mask = SCU_PM_POWEROFF << (cpu * 8);
>
> if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
> return 1;
>
> return 0;
> }
>
> which can be done in the same file as well.
>
>>>>> Then callers can decide which of these to call, and what error messages
>>>>> to print on their failures.
>>>>
>>>> Splitting the function in two is probably simpler overall, but
>>>> we may still have to look at all the callers: Any platform that
>>>> currently tries to map it on any CPU and doesn't warn about the
>>>> absence of the device node (or about scu_a9_has_base() == false)
>>>> should really continue not to warn about that.
>>>
>>> Did you miss the bit where none of of_scu_enable() or a9_scu_enable()
>>> should produce any warnings or errors to be printed. It's up to the
>>> caller to report the failure, otherwise doing this doesn't make sense:
>>>
>>> if (of_scu_enable() < 0 && a9_scu_enable() < 0)
>>> pr_err("Failed to map and enable the SCU\n");
>>>
>>> because if of_scu_enable() prints a warning/error, then it's patently
>>> misleading.
>>>
>
> That's why I said "otherwise we can leave the warning in the caller
> after checking the return code of the new APIs." for the case where
> we actually need it.
>
>> I will move out error message out of these helpers and let caller
>> (platform specific code) handle and print error if required.
>
> Ok.
>
> Arnd
>
>
>
^ permalink raw reply
* [PATCH next] arm64: remove "SMP: Total of %d processors activated." message
From: Kefeng Wang @ 2016-11-18 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117142213.GI22855@arm.com>
On 2016/11/17 22:22, Will Deacon wrote:
> On Thu, Nov 17, 2016 at 03:32:26PM +0800, Kefeng Wang wrote:
>> There is a common SMP boot message in generic code on all arches,
>> kill "SMP: Total of %d processors activated." in smp_cpus_done()
>> on arm64.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Boot message on qemu.
>> [ 0.375116] smp: Brought up 1 node, 8 CPUs
>> [ 0.383749] SMP: Total of 8 processors activated.
>>
>> arch/arm64/kernel/smp.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index cb87234..9db4a95 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -428,7 +428,6 @@ static void __init hyp_mode_check(void)
>>
>> void __init smp_cpus_done(unsigned int max_cpus)
>> {
>> - pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
>> setup_cpu_features();
>> hyp_mode_check();
>> apply_alternatives_all();
>
> Why? Are you proposing the same change to other architectures? Are you paid
> per patch?
The message provides no further information than the generic code, so kill it.
Or show BogoMIPS like arm32?
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index cb87234..6bb33cd 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -428,7 +428,17 @@ static void __init hyp_mode_check(void)
void __init smp_cpus_done(unsigned int max_cpus)
{
- pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
+ int cpu;
+ unsigned long bogosum = 0;
+
+ for_each_online_cpu(cpu)
+ bogosum += loops_per_jiffy;
+
+ pr_info("SMP: Total of %d processors activated "
+ "(%lu.%02lu BogoMIPS).\n",
+ num_online_cpus(),
+ bogosum / (500000/HZ),
+ (bogosum / (5000/HZ)) % 100);
setup_cpu_features();
hyp_mode_check();
apply_alternatives_all()
>
> Will
>
> .
>
^ permalink raw reply related
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Robert Nelson @ 2016-11-18 3:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e69a797c-bec3-2243-5c19-9d7633092369@ti.com>
On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm@ti.com> wrote:
> On 11/17/2016 08:44 PM, Robert Nelson wrote:
> again.. a short commit message at least please? :)
yeah, i'll fix all those. ;)
>
>> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
>> CC: Julien <jboulnois@gmail.com>
>> CC: Nishanth Menon <nm@ti.com>
>> CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> CC: Tony Lindgren <tony@atomide.com>
>> ---
>> arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>> b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>> index 6df7829..3bc47be 100644
>> --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>> +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>> @@ -97,6 +97,12 @@
>> #cooling-cells = <2>;
>> };
>>
>> + gpu-subsystem {
>
> A) do we want to make things clear that this is gpu subsystem for gc320?
> B) How about other platforms that could equally reuse?
so the 'gpu-subsystem' comes from etnaviv:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt?id=refs/tags/v4.9-rc5
For a generic name, it's currently only tied to the etnaviv driver:
gpu-subsystem {
compatible = "fsl,imx-gpu-subsystem";
cores = <&gpu_2d>, <&gpu_3d>;
};
it would make sense to make that more generic, so you could tie a 2d
vivante and a imgtec/sgx 3d core.. <sad laugh> but that would require
adding a imgtec/sgx driver/bindings to the kernel mainline... </sad
laugh>
>
>> + compatible = "ti,gc320-gpu-subsystem";
>> + cores = <&bb2d>;
>> + status = "okay";
>> + };
>> +
>> hdmi0: connector {
>> compatible = "hdmi-connector";
>> label = "hdmi";
>> @@ -190,6 +196,11 @@
>> >;
>> };
>> };
>> +
>> +&bb2d {
>> + status = "okay";
>> +};
>> +
>> &i2c1 {
>> status = "okay";
>> clock-frequency = <400000>;
>>
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Nishanth Menon @ 2016-11-18 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOCHtYiUz1cjYw9nNa4YZGtzNVgSgjEa=4Lqiktz07rszsSksw@mail.gmail.com>
On 11/17/2016 09:44 PM, Robert Nelson wrote:
> On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 11/17/2016 08:44 PM, Robert Nelson wrote:
>> again.. a short commit message at least please? :)
>
> yeah, i'll fix all those. ;)
>
>>
>>> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
>>> CC: Julien <jboulnois@gmail.com>
>>> CC: Nishanth Menon <nm@ti.com>
>>> CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> CC: Tony Lindgren <tony@atomide.com>
>>> ---
>>> arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>> b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>> index 6df7829..3bc47be 100644
>>> --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>> +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>> @@ -97,6 +97,12 @@
>>> #cooling-cells = <2>;
>>> };
>>>
>>> + gpu-subsystem {
>>
>> A) do we want to make things clear that this is gpu subsystem for gc320?
>> B) How about other platforms that could equally reuse?
>
> so the 'gpu-subsystem' comes from etnaviv:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt?id=refs/tags/v4.9-rc5
>
> For a generic name, it's currently only tied to the etnaviv driver:
>
I was only complaining about "gpu-subsystem {", not the compatible. it
is not the only gpu subsystem on the SoC. either "gpu-subsystem0 {" or
something like gpu-subsystem-gc320 might be helpful to clarify.
> gpu-subsystem {
> compatible = "fsl,imx-gpu-subsystem";
> cores = <&gpu_2d>, <&gpu_3d>;
> };
>
> it would make sense to make that more generic, so you could tie a 2d
> vivante and a imgtec/sgx 3d core.. <sad laugh> but that would require
> adding a imgtec/sgx driver/bindings to the kernel mainline... </sad
> laugh>
>
I should have clarified... I meant other dra7 devices to reuse the
same definitions. this definition is not by any means constrained to
EVM - it is a SoC definition, it should be moved to appropriate place
(convention for dra7 is to mark them as disabled by default in
SoC.dtsi to prevent proliferation of paper spin dtsi and just do
"status = okay" in board file to indicate presence in the variation
for the board).
Yes - I guess some day there might be a bunch of folks like etnaviv
who might make an community driver possible..
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Yao Yuan @ 2016-11-18 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0701MB213027FC738E6E377A593B60FEB10@AM4PR0701MB2130.eurprd07.prod.outlook.com>
On Thu, Nov 17, 2016 at 10:14:55AM +0000, Krzeminski, Marcin (Nokia - PL/Wroclaw) wrote:
> > On Thu, Nov 17, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > <B56489@freescale.com>
> > > > > > wrote:
> > > > > > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > > >
> > > > > > > With the physical sectors combination, S25FS-S family flash
> > > > > > > requires some special operations for read/write functions.
> > > > > > >
> > > > > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > > > ---
> > > > > > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > > > 1 file changed, 56 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb
> > > > > > > 100644
> > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > @@ -39,6 +39,10 @@
> > > > > > >
> > > > > > > #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > > > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
> > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > > > > > >
> > > > > > > struct flash_info {
> > > > > > > char *name;
> > > > > > > @@ -78,6 +82,7 @@ struct flash_info { };
> > > > > > >
> > > > > > > #define JEDEC_MFR(info) ((info)->id[0])
> > > > > > > +#define EXT_JEDEC(info) ((info)->id[5])
> > > > > > >
> > > > > > > static const struct flash_info *spi_nor_match_id(const char
> > > > > > > *name);
> > > > > > >
> > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > > > > */
> > > > > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024,
> > > > > > > 64,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024,
> > > > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > > > + 512, 0)},
> > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024,
> > > > > > > 512,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024,
> > > > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > > > +1042,50
> > > > > > @@ static const struct flash_info *spi_nor_read_id(struct
> > > > > > spi_nor
> > > > > > *nor)
> > > > > > > return ERR_PTR(-ENODEV); }
> > > > > > >
> > > > > > > +/*
> > > > > > > + * The S25FS-S family physical sectors may be configured as
> > > > > > > +a
> > > > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > > > + * at the top or bottom of the address space with all
> > > > > > > + * but one of the remaining sectors being uniform size.
> > > > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > > > + * must be used to erase any of the remaining
> > > > > > > + * sectors, including the portion of highest or lowest
> > > > > > > +address
> > > > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > > > + * The uniform sector erase command has no effect on
> > > > > > > +parameter
> > > > > > sectors.
> > > > > > > + */
> > > > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > > > > > + u8 cr3v = 0x0;
> > > > > > > + int ret = 0x0;
> > > > > > > +
> > > > > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > > > +
> > > > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > &cr3v, 1);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > > > + return 0;
> > > > > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > > > > > +
> > > > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > &cr3v, 1);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > > > + return -EPERM;
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > static int spi_nor_read(struct mtd_info *mtd, loff_t from,
> > > > > > > size_t
> > len,
> > > > > > > size_t *retlen, u_char *buf) { @@
> > > > > > > -1361,6
> > > > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > > > > +*name,
> > > > > > enum read_mode mode)
> > > > > > > spi_nor_wait_till_ready(nor);
> > > > > > > }
> > > > > > >
> > > > > > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > + }
> > > > > > > +
> > > > > > > if (!mtd->name)
> > > > > > > mtd->name = dev_name(dev);
> > > > > > > mtd->priv = nor;
> > > > > > > --
> > > > > > > 2.1.0.27.g96db324
> > > > > > >
> > > > > > >
> > > > > > Hi Brian, I will ack this change but still feel it's kind of hacking code.
> > > > > >
> > > > > > Acked-by: Han xu <han.xu@nxp.com>
> > > > >
> > > > > I am new on the list so I am not sure if this topic has been discussed.
> > > > > Generally our product functionality relay on those 4KiB sectors.
> > > > > I know that this hack is already in u-boot, but if you
> > > > > mainstream this you will force users of those 4KiB sectors to do hack the
> hack...
> > > > > I believe the proper solution here is to use erase regions
> > > > > functionality, I send and RFS about that some time ago.
> > > >
> > > > Do you mind to send me a link for reference?
> > > >
> > > Han,
> > >
> > > Sorry, It seem I have not posted erase region changes (only those
> > > regarding DUAL/QUAD I/O).
> > > Generally, in this flash you need to create 3 erase regions (because
> > > in FS-S family support only 4KiB erase on parameters sector - eg.
> > > 1.2.2.4 in
> > S25FS512S).
> > > In my case regions are:
> > > 1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21) 2. 32 - 256 - SE_CMD
> > (0xd8/0xdc) 3.
> > > Rest of the flash SE_CMD (0xd8/0xdc)
> > >
> > > To erase whole flash you can also use CHIP_ERASE_CMD (0x60/0xC7)
> > > command, you just need to add one more mtd partition that will cover
> > whole flash.
> > >
> >
> > Hi Krzeminski,
> >
> > Do you think is there any great advantages for enable 4KB?
> > Because for NXP(Freescale) QSPI controller, there is only support max
> > to 16 groups command.
> >
> > So It's hard to give 3 groups command just for erase (0x21,0xdc and 0xc7).
> > So we have to disable the 4kb erase and only use 256kbytes in this patch.
> >
> Yes, if you disable parameters sector in spi-nor framework you will disable it for
> all spi-nor clients not only for NXP QSPI controller. There are users (at least me)
> that relay on parameters sector functionality. This patch will brake it.
>
> Thanks,
Hi Krzeminski,
Get it.
So do you think how about that I add a flag in dts to select it?
The user want's disable 4kb, he can add the flag.
In spi-nor.c:
if (of_property_read_bool(np, "spi-nor, disable-4kb")) {
spansion_s25fs_disable_4kb_erase();
}
else
...
In dts:
&qspi {
num-cs = <2>;
bus-num = <0>;
status = "okay";
qflash0: s25fs512s at 0 {
compatible = "spansion, s25fs512s";
spi-nor, disable-4kb
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
reg = <0>;
};
I think it should be a better way.
How about your think?
Thanks.
^ permalink raw reply
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Robert Nelson @ 2016-11-18 4:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3eb346ad-1675-e613-93ef-bd2d07bf2ab8@ti.com>
On Thu, Nov 17, 2016 at 10:15 PM, Nishanth Menon <nm@ti.com> wrote:
> On 11/17/2016 09:44 PM, Robert Nelson wrote:
>>
>> On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm@ti.com> wrote:
>>>
>>> On 11/17/2016 08:44 PM, Robert Nelson wrote:
>>> again.. a short commit message at least please? :)
>>
>>
>> yeah, i'll fix all those. ;)
>>
>>>
>>>> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
>>>> CC: Julien <jboulnois@gmail.com>
>>>> CC: Nishanth Menon <nm@ti.com>
>>>> CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>>> CC: Tony Lindgren <tony@atomide.com>
>>>> ---
>>>> arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>>> b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>>> index 6df7829..3bc47be 100644
>>>> --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>>> +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
>>>> @@ -97,6 +97,12 @@
>>>> #cooling-cells = <2>;
>>>> };
>>>>
>>>> + gpu-subsystem {
>>>
>>>
>>> A) do we want to make things clear that this is gpu subsystem for gc320?
>>> B) How about other platforms that could equally reuse?
>>
>>
>> so the 'gpu-subsystem' comes from etnaviv:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt?id=refs/tags/v4.9-rc5
>>
>> For a generic name, it's currently only tied to the etnaviv driver:
>>
>
> I was only complaining about "gpu-subsystem {", not the compatible. it is
> not the only gpu subsystem on the SoC. either "gpu-subsystem0 {" or
> something like gpu-subsystem-gc320 might be helpful to clarify.
>
>> gpu-subsystem {
>> compatible = "fsl,imx-gpu-subsystem";
>> cores = <&gpu_2d>, <&gpu_3d>;
>> };
>>
>> it would make sense to make that more generic, so you could tie a 2d
>> vivante and a imgtec/sgx 3d core.. <sad laugh> but that would require
>> adding a imgtec/sgx driver/bindings to the kernel mainline... </sad
>> laugh>
>>
>
> I should have clarified... I meant other dra7 devices to reuse the same
> definitions. this definition is not by any means constrained to EVM - it is
> a SoC definition, it should be moved to appropriate place (convention for
> dra7 is to mark them as disabled by default in SoC.dtsi to prevent
> proliferation of paper spin dtsi and just do "status = okay" in board file
> to indicate presence in the variation for the board).
Oh yeah, defintely, we can move gpu-subsystem to the base dra7.dtsi,
as the whole dra.dtsi family has a gc320 and then the board device
tree can enable it via:
&bb2d {
status = "okay";
};
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Han Xu @ 2016-11-18 4:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB24077A46D3FC5147DC4C69D989B10@DB6PR0401MB2407.eurprd04.prod.outlook.com>
On Thu, Nov 17, 2016 at 3:14 AM, Yao Yuan <yao.yuan@nxp.com> wrote:
> On Thu, Nov 17, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia - PL/Wroclaw) wrote:
>> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
>> > > > wrote:
>> > > > > From: Yunhui Cui <yunhui.cui@nxp.com>
>> > > > >
>> > > > > With the physical sectors combination, S25FS-S family flash
>> > > > > requires some special operations for read/write functions.
>> > > > >
>> > > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
>> > > > > ---
>> > > > > drivers/mtd/spi-nor/spi-nor.c | 56
>> > > > > +++++++++++++++++++++++++++++++++++++++++++
>> > > > > 1 file changed, 56 insertions(+)
>> > > > >
>> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
>> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
>> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
>> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
>> > > > > @@ -39,6 +39,10 @@
>> > > > >
>> > > > > #define SPI_NOR_MAX_ID_LEN 6
>> > > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
>> > > > > +/* Added for S25FS-S family flash */
>> > > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
>> > > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
>> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
>> > > > >
>> > > > > struct flash_info {
>> > > > > char *name;
>> > > > > @@ -78,6 +82,7 @@ struct flash_info { };
>> > > > >
>> > > > > #define JEDEC_MFR(info) ((info)->id[0])
>> > > > > +#define EXT_JEDEC(info) ((info)->id[5])
>> > > > >
>> > > > > static const struct flash_info *spi_nor_match_id(const char
>> > > > > *name);
>> > > > >
>> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
>> > > > > */
>> > > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
>> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>> > > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
>> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>> > > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
>> > > > > + 512, 0)},
>> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
>> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
>> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>> > > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
>> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
>> > +1042,50
>> > > > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor
>> > > > *nor)
>> > > > > return ERR_PTR(-ENODEV); }
>> > > > >
>> > > > > +/*
>> > > > > + * The S25FS-S family physical sectors may be configured as a
>> > > > > + * hybrid combination of eight 4-kB parameter sectors
>> > > > > + * at the top or bottom of the address space with all
>> > > > > + * but one of the remaining sectors being uniform size.
>> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
>> > > > > + * be used to erase the 4-kB parameter sectors individually.
>> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
>> > > > > + * must be used to erase any of the remaining
>> > > > > + * sectors, including the portion of highest or lowest address
>> > > > > + * sector that is not overlaid by the parameter sectors.
>> > > > > + * The uniform sector erase command has no effect on parameter
>> > > > sectors.
>> > > > > + */
>> > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
>> > > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
>> > > > > + u8 cr3v = 0x0;
>> > > > > + int ret = 0x0;
>> > > > > +
>> > > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
>> > > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
>> > > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
>> > > > > +
>> > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
>> > > > > + if (ret)
>> > > > > + return ret;
>> > > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
>> > > > > + return 0;
>> > > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
>> > > > > + if (ret)
>> > > > > + return ret;
>> > > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
>> > > > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
>> > > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
>> > > > > +
>> > > > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
>> > > > > + if (ret)
>> > > > > + return ret;
>> > > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
>> > > > > + return -EPERM;
>> > > > > +
>> > > > > + return 0;
>> > > > > +}
>> > > > > +
>> > > > > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
>> > > > > size_t *retlen, u_char *buf) { @@
>> > > > > -1361,6
>> > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
>> > > > > +*name,
>> > > > enum read_mode mode)
>> > > > > spi_nor_wait_till_ready(nor);
>> > > > > }
>> > > > >
>> > > > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
>> > > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
>> > > > > + if (ret)
>> > > > > + return ret;
>> > > > > + }
>> > > > > +
>> > > > > if (!mtd->name)
>> > > > > mtd->name = dev_name(dev);
>> > > > > mtd->priv = nor;
>> > > > > --
>> > > > > 2.1.0.27.g96db324
>> > > > >
>> > > > >
>> > > > Hi Brian, I will ack this change but still feel it's kind of hacking code.
>> > > >
>> > > > Acked-by: Han xu <han.xu@nxp.com>
>> > >
>> > > I am new on the list so I am not sure if this topic has been discussed.
>> > > Generally our product functionality relay on those 4KiB sectors.
>> > > I know that this hack is already in u-boot, but if you mainstream
>> > > this you will force users of those 4KiB sectors to do hack the hack...
>> > > I believe the proper solution here is to use erase regions
>> > > functionality, I send and RFS about that some time ago.
>> >
>> > Do you mind to send me a link for reference?
>> >
>> Han,
>>
>> Sorry, It seem I have not posted erase region changes (only those regarding
>> DUAL/QUAD I/O).
>> Generally, in this flash you need to create 3 erase regions (because in FS-S
>> family support only 4KiB erase on parameters sector - eg. 1.2.2.4 in S25FS512S).
>> In my case regions are:
>> 1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21) 2. 32 - 256 - SE_CMD (0xd8/0xdc) 3.
>> Rest of the flash SE_CMD (0xd8/0xdc)
>>
>> To erase whole flash you can also use CHIP_ERASE_CMD (0x60/0xC7) command,
>> you just need to add one more mtd partition that will cover whole flash.
>>
>
> Hi Krzeminski,
>
> Do you think is there any great advantages for enable 4KB?
> Because for NXP(Freescale) QSPI controller, there is only support max to 16 groups command.
If it's really necessary to support all command groups, you can try
apply my dynamic lut patch first.
https://patchwork.ozlabs.org/patch/676791/
>
> So It's hard to give 3 groups command just for erase (0x21,0xdc and 0xc7).
> So we have to disable the 4kb erase and only use 256kbytes in this patch.
>
>
--
Sincerely,
Han XU
^ permalink raw reply
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Nishanth Menon @ 2016-11-18 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOCHtYh8QebrYA2ioaXgURdc47QY4x+EwZLBXLLGP1-k7eAMmw@mail.gmail.com>
On 11/17/2016 10:26 PM, Robert Nelson wrote:
[...]
> Oh yeah, defintely, we can move gpu-subsystem to the base dra7.dtsi,
> as the whole dra.dtsi family has a gc320 and then the board device
> tree can enable it via:
>
> &bb2d {
> status = "okay";
> };
Yep, thanks.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v9 02/10] drm/mediatek: add *driver_data for different hardware settings
From: Daniel Kurtz @ 2016-11-18 4:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478865346-19043-3-git-send-email-yt.shen@mediatek.com>
Hi YT,
I don't see a reason to handle device_data in such a generic way at
the generic mtk_ddp_comp layer.
The device data is very component specific, so just define different
structs for different comp types, ie:
struct mtk_disp_ovl_driver_data {
unsigned int reg_ovl_addr;
unsigned int fmt_rgb565;
unsigned int fmt_rgb888;
};
struct mtk_disp_rdma_driver_data {
unsigned int fifo_pseudo_size;
};
struct mtk_disp_color_driver_data {
unsigned int color_offset;
};
Then add typed pointers to the local structs that use them, for example:
struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_ovl_driver_data *data;
};
And fetch the device specific driver data directly in .probe, as you
are already doing:
static int mtk_disp_ovl_probe(struct platform_device *pdev) {
...
priv->data = of_device_get_match_data(dev);
...
}
More comments in-line...
On Fri, Nov 11, 2016 at 7:55 PM, YT Shen <yt.shen@mediatek.com> wrote:
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Nit: I think it would make sense to combine this patch with
drm/mediatek: rename macros, add chip prefix
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 27 ++++++++++++++++-----------
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 11 +++++++++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 11 +++++++----
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 27 +++++++++++++++++++++------
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 +++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 25 ++++++++++++++++++-------
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8 ++++++++
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 24 +++++++++++++++++++++++-
> 8 files changed, 115 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..1139834 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,13 +35,10 @@
> #define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> -#define DISP_REG_OVL_ADDR(n) (0x0f40 + 0x20 * (n))
Also, I would still use the "#define macros", for example
"DISP_REG_OVL_ADDR offsets, and use the named constant in the
driver_data:
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
(and in a later patch:
#define DISP_REG_OVL_ADDR_MT2701 0x0040
)
Also, I would still use the macro rather than open coding the "0x20 *
(n)", and just pass 'ovl' to the overlay macros that depend on
hardware type.
Something like the following:
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->ovl_addr + 0x20 * (n))
>
> #define OVL_RDMA_MEM_GMC 0x40402020
>
> #define OVL_CON_BYTE_SWAP BIT(24)
> -#define OVL_CON_CLRFMT_RGB565 (0 << 12)
> -#define OVL_CON_CLRFMT_RGB888 (1 << 12)
This seems like a really random and unnecessary hardware change.
Why chip designers, why!!?!?
For this one, it seems the polarity is either one way or the other, so
we can just use a bool to distinguish:
bool fmt_rgb565_is_0;
> +static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
> + .ovl = { DISP_REG_OVL_ADDR_MT8173, .fmt_rgb565_is_0 = true }
> +};
For use at runtime, the defines could become:
#define OVL_CON_CLRFMT_RGB565(ovl) ((ovl)->data->fmt_rgb565_is_0 ? 0
: OVL_CON_CLRFMT_RGB888)
#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ?
OVL_CON_CLRFMT_RGB888 : 0)
> #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> #define OVL_CON_AEN BIT(8)
> @@ -137,18 +134,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx)
> writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
> }
>
> -static unsigned int ovl_fmt_convert(unsigned int fmt)
> +static unsigned int ovl_fmt_convert(struct mtk_ddp_comp *comp, unsigned int fmt)
> {
> switch (fmt) {
> default:
> case DRM_FORMAT_RGB565:
> - return OVL_CON_CLRFMT_RGB565;
> + return comp->data->ovl.fmt_rgb565;
It will be nice to define a helper function for converting from the
generic 'mtk_ddp_comp' to the specific 'mtk_disp_ovl':
static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp) {
return container_of(comp, struct mtk_disp_ovl, ddp_comp);
}
Then these could become:
return OVL_CON_CLRFMT_RGB565(comp_to_ovl(comp));
Or maybe cleaner, do the conversion once at the top of the function:
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
And then just:
return OVL_CON_CLRFMT_RGB565(ovl);
> case DRM_FORMAT_BGR565:
> - return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
> + return comp->data->ovl.fmt_rgb565 | OVL_CON_BYTE_SWAP;
> case DRM_FORMAT_RGB888:
> - return OVL_CON_CLRFMT_RGB888;
> + return comp->data->ovl.fmt_rgb888;
> case DRM_FORMAT_BGR888:
> - return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
> + return comp->data->ovl.fmt_rgb888 | OVL_CON_BYTE_SWAP;
> case DRM_FORMAT_RGBX8888:
> case DRM_FORMAT_RGBA8888:
> return OVL_CON_CLRFMT_ARGB8888;
[snip]
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 1c366f8..935a8ef 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -16,6 +16,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/module.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/phy/phy.h>
>
> @@ -87,6 +88,9 @@
>
> #define MIPITX_DSI_PLL_CON2 0x58
>
> +#define MIPITX_DSI_PLL_TOP 0x64
> +#define RG_DSI_MPPLL_PRESERVE (0xff << 8)
> +
> #define MIPITX_DSI_PLL_PWR 0x68
> #define RG_DSI_MPPLL_SDM_PWR_ON BIT(0)
> #define RG_DSI_MPPLL_SDM_ISO_EN BIT(1)
> @@ -123,10 +127,15 @@
> #define SW_LNT2_HSTX_PRE_OE BIT(24)
> #define SW_LNT2_HSTX_OE BIT(25)
>
> +struct mtk_mipitx_data {
> + const u32 data;
Use a better name, like "mppll_preserve".
Ok, that's it for now.
Actually, the patch set in general looks pretty good.
-Dan
^ permalink raw reply
* [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-11-18 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omBpdRH5ZnvcApX_pevwSBHwUon77DhhjX0p9aQXuOy4DA@mail.gmail.com>
Hi, Daniel:
On Fri, 2016-11-18 at 11:22 +0800, Daniel Kurtz wrote:
> Hi CK,
>
> On Thu, Nov 17, 2016 at 1:36 PM, CK Hu <ck.hu@mediatek.com> wrote:
> > Hi, Jitao:
> >
> >
> > On Wed, 2016-11-16 at 11:20 +0800, Jitao Shi wrote:
> >> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
> >> Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
> >> mode, those signals will cause h-time larger than normal and reduce FPS.
> >> So need to multiply a coefficient to offset the extra signal's effect.
> >> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
> >> Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
> >>
> >> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> >
> > It looks good to me.
> > But this patch conflict with [1] which is one patch of MT2701 series. I
> > want to apply MT2701 patches first, so please help to refine this patch
> > based on MT2701 patches.
>
> I don't think the MT2701 DSI patches are quite ready yet (I just
> reviewed the one below).
> Can we instead land Jitao's small targeted change first, and then
> rebase the MT2701 series on top.
>
> Thanks,
> -Dan
MT2701 series looks still have some defect to be fixed.
Therefore, I would apply this patch first.
Thanks for your help.
Regards,
CK
> >
> > [1] https://patchwork.kernel.org/patch/9422821/
> >
> > Regards,
> > CK
> >
> >> ---
> >> Change since v4:
> >> - tune the calc comment more clear.
> >> - define the phy timings as constants.
> >>
> >> Chnage since v3:
> >> - wrapp the commit msg.
> >> - fix alignment of some lines.
> >>
> >> Change since v2:
> >> - move phy timing back to dsi_phy_timconfig.
> >>
> >> Change since v1:
> >> - phy_timing2 and phy_timing3 refer clock cycle time.
> >> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
> >> ---
> >>
> >
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Bharat Bhushan @ 2016-11-18 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-1-git-send-email-eric.auger@redhat.com>
Hi Eric,
Have you sent out QEMU side patches based on this new approach? In case I missed please point me the patches?
Thanks
-Bharat
> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Eric Auger
> Sent: Tuesday, November 15, 2016 6:39 PM
> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
> christoffer.dall at linaro.org; marc.zyngier at arm.com;
> robin.murphy at arm.com; alex.williamson at redhat.com;
> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
> Cc: drjones at redhat.com; kvm at vger.kernel.org; punit.agrawal at arm.com;
> linux-kernel at vger.kernel.org; iommu at lists.linux-foundation.org;
> pranav.sawargaonkar at gmail.com
> Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and
> IOVA reserved regions
>
> Following LPC discussions, we now report reserved regions through iommu-
> group sysfs reserved_regions attribute file.
>
> Reserved regions are populated through the IOMMU get_resv_region
> callback (former get_dm_regions), now implemented by amd-iommu, intel-
> iommu and arm-smmu.
>
> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
> IOMMU_RESV_NOMAP reserved region.
>
> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and 1MB
> large) and the PCI host bridge windows.
>
> The series integrates a not officially posted patch from Robin:
> "iommu/dma: Allow MSI-only cookies".
>
> This series currently does not address IRQ safety assessment.
>
> Best Regards
>
> Eric
>
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>
> History:
> RFC v2 -> v3:
> - switch to an iommu-group sysfs API
> - use new dummy allocator provided by Robin
> - dummy allocator initialized by vfio-iommu-type1 after enumerating
> the reserved regions
> - at the moment ARM MSI base address/size is left unchanged compared
> to v2
> - we currently report reserved regions and not usable IOVA regions as
> requested by Alex
>
> RFC v1 -> v2:
> - fix intel_add_reserved_regions
> - add mutex lock/unlock in vfio_iommu_type1
>
>
> Eric Auger (10):
> iommu/dma: Allow MSI-only cookies
> iommu: Rename iommu_dm_regions into iommu_resv_regions
> iommu: Add new reserved IOMMU attributes
> iommu: iommu_alloc_resv_region
> iommu: Do not map reserved regions
> iommu: iommu_get_group_resv_regions
> iommu: Implement reserved_regions iommu-group sysfs file
> iommu/vt-d: Implement reserved region get/put callbacks
> iommu/arm-smmu: Implement reserved region get/put callbacks
> vfio/type1: Get MSI cookie
>
> drivers/iommu/amd_iommu.c | 20 +++---
> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
> drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++++----
> ---
> drivers/iommu/intel-iommu.c | 50 ++++++++++----
> drivers/iommu/iommu.c | 141
> ++++++++++++++++++++++++++++++++++++----
> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
> include/linux/dma-iommu.h | 7 ++
> include/linux/iommu.h | 49 ++++++++++----
> 8 files changed, 391 insertions(+), 70 deletions(-)
>
> --
> 1.9.1
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH] kirkwood: fix spelling mistake
From: p.wassi at gmx.at @ 2016-11-18 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117210227.GL5574@lunn.ch>
Hi Andrew,
> You should also send the patch to the Marvell MVEBU
> maintainers.
how do I find Marvell mvebu maintainers?
The list in
https://www.kernel.org/doc/linux/MAINTAINERS
(line 1429) references mvebu/kirkwood and gave me the
mailing list's address. Should the other two maintainers
be addressed directly?
Best regards,
P. Wassi
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Jiancheng Xue @ 2016-11-18 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <114569cb-79ab-a46d-8582-6169f182a32c@hisilicon.com>
Hi Marty,
On 2016/11/17 11:03, Jiancheng Xue wrote:
> Hi Wei?
>
> On 2016/11/16 17:31, Wei Xu wrote:
>> Hi Pan,
>>
>> On 2016/11/16 8:56, wenpan wrote:
>>> Hi Marty?
>>> Does this confict with your patch? If not?I hope this could be merged first. Besides could you tell me the link to your related patch?
>>
>> This is the link: https://patchwork.kernel.org/patch/9334743/
>>
Could you give your comments on this patch?
If you have any objections to it, please let us know.
>
> Thank you for offering this.If I want to give some comments on Marty's patch,
> what should I do?
>
> For Marty's patch, I think there's no need to add specific config item ARCH_HIxxxx
> for every chipset. Some existing chipsets depend on ARCH_HISI directly like Hi3519
> and Hi3798CV200. If some options like ARM_GIC is removed from ARCH_HISI, this kind
> of chipsets will must choose other place to select it. I suggest we should keep selecting
> ARM_GIC under ARCH_HISI as Pan's patch do.
>
> The code may be like this:
>
> config ARCH_HISI
> bool "Hisilicon SoC Support"
> - depends on ARCH_MULTI_V7
> + depends on ARCH_MULTI_V5 || ARCH_MULTI_V6 || ARCH_MULTI_V7
> select ARM_AMBA
> - select ARM_GIC
> + select ARM_GIC if ARCH_MULTI_V7
> + select ARM_VIC if ARCH_MULTI_V5 || depends on ARCH_MULTI_V6
> select ARM_TIMER_SP804
> select POWER_RESET
> select POWER_RESET_HISI
> select POWER_SUPPLY
>
What's your opinion about this?
Best Regards,
Jiancheng
>>> On 2016/10/17 21:48, Arnd Bergmann wrote:
>>>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>>>
>>>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>>>
>>>>
>>>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>>>> patches for Hi3520, which I think is closely related to this one.
>>>> Please try to work together so the patches don't conflict. It should
>>>> be fairly straightforward since you are basically doing the same
>>>> change here.
>>>>
>
>
>
> .
>
^ permalink raw reply
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Krzysztof Kozlowski @ 2016-11-18 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3145378.USf2WOPoV2@wuerfel>
On Thu, Nov 17, 2016 at 01:35:45PM +0100, Arnd Bergmann wrote:
> On Monday, November 14, 2016 8:27:05 PM CET Krzysztof Kozlowski wrote:
> > @@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
> > config HZ_FIXED
> > int
> > default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
> > - ARCH_S5PV210 || ARCH_EXYNOS4
> > + ARCH_S5PV210
> > default 128 if SOC_AT91RM9200
> > default 0
>
> After further research, I've concluded that we should also drop the
> settings for ARCH_S5PV210 and ARCH_S3C24XX here.
>
> ARCH_S5PV210 behaves exactly like EXYNOS here, it has 32-bit timers
> so there won't be any overflow with 100Hz.
>
> For ARCH_S3C24XX, it the requirement was that HZ_100 could not
> be used with the old arch/arm/plat-samsung/time.c code that would
> overflow its 16-bit counter.
> However, the new drivers/clocksource/samsung_pwm_timer.c configures
> the clock divider to '50' instead of '6', so there is no longer
> a 16-bit overflow before the 100Hz tick, it now overflows every
> 3.7ms for the typical 12MHz clock.
I can send an updated version however testing would be nice... I know
Sylwester has a S3C6410 platform running, maybe S3C24xx as well.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] clk: sunxi-ng: sun6i-a31: Enable PLL-MIPI LDOs when ungating it
From: Chen-Yu Tsai @ 2016-11-18 7:15 UTC (permalink / raw)
To: linux-arm-kernel
The PLL-MIPI clock is somewhat special as it has its own LDOs which
need to be turned on for this PLL to actually work and output a clock
signal.
Add the 2 LDO enable bits to the gate bits. This fixes issues with
the TCON not sending vblank interrupts when the tcon and dot clock are
indirectly clocked from the PLL-MIPI clock.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
This can be queued for either 4.9 or 4.10.
The clock driver was introduced in 4.9,
but the users won't appear until 4.10.
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 4a82a49cff5e..fc75a335a7ce 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -143,7 +143,7 @@ static SUNXI_CCU_NKM_WITH_MUX_GATE_LOCK(pll_mipi_clk, "pll-mipi",
4, 2, /* K */
0, 4, /* M */
21, 0, /* mux */
- BIT(31), /* gate */
+ BIT(31) | BIT(23) | BIT(22), /* gate */
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
--
2.10.2
^ permalink raw reply related
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Krzysztof Kozlowski @ 2016-11-18 7:16 UTC (permalink / raw)
To: linux-arm-kernel
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz. Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is enabled.
This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx. Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").
Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's). I believe this choice
was rather an effect of coincidence instead of conscious choice.
Exynos uses its own MCT or arch timer and can work with all HZ values.
Older platforms use newer Samsung PWM timer driver which should handle
down to 100 Hz.
Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: Lee Jones <lee.jones@linaro.org>
[Dropping 200_HZ from S3C/S5P suggested by Arnd]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Kukjin Kim <kgene@kernel.org>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Tested on Exynos5422 and Exynos5800 (by Javier). It would be
appreciated if anyone could test it on S3C24xx or S5PV210.
Changes since v1:
1. Add Javier's tested-by.
2. Drop HZ_FIXED also from ARCH_S5PV210 and ARCH_S3C24XX after Arnd
suggestions and analysis.
---
arch/arm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..ced2e08a9d08 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1496,8 +1496,7 @@ source kernel/Kconfig.preempt
config HZ_FIXED
int
- default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
- ARCH_S5PV210 || ARCH_EXYNOS4
+ default 200 if ARCH_EBSA110
default 128 if SOC_AT91RM9200
default 0
--
2.7.4
^ permalink raw reply related
* [GIT PULL] pxa for v4.10
From: Olof Johansson @ 2016-11-18 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8d9wr6d.fsf@belgarion.home>
On Tue, Nov 08, 2016 at 11:19:22PM +0100, Robert Jarzmik wrote:
> Hello Arnd, Kevin, Olof,
>
> Please consider this pull request for pxa 4.10 cycle. This pull request strides
> off from my usual ones as its spans more than just mach-pxa.
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/rjarzmik/linux.git tags/pxa-for-4.10
>
> for you to fetch changes up to e413bd33ac44b6d0bebc0ef2ac19cbe7558a7303:
>
> ARM: pxa: fix pxa25x interrupt init (2016-11-05 21:48:18 +0100)
>
> ----------------------------------------------------------------
> This is the pxa changes for v4.10 cycle.
>
> This cycle is covering :
> - some clock fixes common with sa1100 architecture
> - the consequence of the pxa_camera conversion to v4l2
> - a small irq related fix for pxa25x device-tree only
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL] pxa-dt for v4.10
From: Olof Johansson @ 2016-11-18 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760nxwqs0.fsf@belgarion.home>
Hi,
On Tue, Nov 08, 2016 at 11:27:59PM +0100, Robert Jarzmik wrote:
> Hi Arnd, Kevin, and Olof,
>
> This is the pxa pull request for 4.10 device-tree, can you please consider
> pulling ?
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/rjarzmik/linux.git tags/pxa-dt-4.10
>
> for you to fetch changes up to f409d2f134d499354dca0613693f27d8efd75c74:
>
> ARM: dts: pxa: add pxa27x cpu operating points (2016-11-02 22:52:45 +0100)
>
> ----------------------------------------------------------------
> This device-tree pxa update brings :
> - pxa25x support
> - cpu operating points in preparation for cpufreq-dt
> - small fixes
>
> ----------------------------------------------------------------
> Robert Jarzmik (4):
> ARM: dts: add pxa25x .dtsi file
> ARM: dts: pxa: fix gpio0 and gpio1 interrupts
> ARM: dts: pxa: add pxa25x cpu operating points
> ARM: dts: pxa: add pxa27x cpu operating points
>
> Vijay Kumar (1):
> Fix no. of gpio cells in the pxa gpio binding doucmentation
This isn't the right patch subject. Please use standard prefix format
here (ARM: dts: pxa: ...).
Please respin this branch and post a fresh pull request. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Integrator DTS and defconfig changes
From: Olof Johansson @ 2016-11-18 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdara5D=kvGVYu-WRh_JYK6Z9NKmQ-eniXsauxdzx-QJbA@mail.gmail.com>
Hi Linus,
On Wed, Nov 09, 2016 at 09:10:35AM +0100, Linus Walleij wrote:
> Hi ARM SoC folks,
>
> this adds DT-based cpufreq to the Integrator family.
>
> The corresponding cpufreq changes are merged by Rafael to the
> cpufreq tree, and can go in orthogonally.
>
> However I have included the defconfig change turning on the feature
> here as it makes all kind of logic sense to have these three patches
> in succession: addin the DTS nodes and then turning on the DT
> cpufreq.
>
> If you insist, of course I can send the defconfig patch separately.
> I just think it makes more sense like this.
>
> Please pull it in so we get some rotation in linux-next for this!
Hmm.
I understand that it makes sense for your platform do turn on the option
at the same time as adding the DT entries, but there's nothing that should
require them to go in together (they just won't be used until both branches are
in).
We try to keep our categories of patches separate in the arm-soc tree;
keeping SoC changes, driver changes, DT changes and defconfig changes
is from a general code hygiene point of view beneficial and we encourage all
platform maintainers to follow those guidelines.
I also sympathize that it's extra annoying having to split just three
patches across two branches. So, if it's easier we can just cherry-pick
apart the patches here across the branches (your comment about next
coverage makes me suspect you have no direct downstream users of this
branch). If that's OK, let me know and I'll do that tomorrow.
Cheers,
-Olof
^ permalink raw reply
* [PATCH] ARM: integrator: drop EBI access use syscon
From: Olof Johansson @ 2016-11-18 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478679126-5460-1-git-send-email-linus.walleij@linaro.org>
On Wed, Nov 09, 2016 at 09:12:06AM +0100, Linus Walleij wrote:
> The EBI lookup is not longer in use: this has been moved to the
> NAND chip driver. The syscon node is better accessed indirectly
> using the regmap like the NAND chip driver does, so let's use
> the syscon to set the modem control signals RTS/CTS through the
> dedicated syscon register.
>
> We also migrate the decoder status "SC_DEC" register that
> enumerate the logic modules using syscon.
>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks: please apply this patch directly to the tree
> wherever it fits. I do not plan to send more Integrator patches
> this merge window.
Thanks, applied!
-Olof
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 2
From: Olof Johansson @ 2016-11-18 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <919f7b55-a2cd-fc20-a1cd-4d3f309fd60d@st.com>
On Thu, Nov 10, 2016 at 10:00:32AM +0100, Patrice Chotard wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider the second round of multi_v7_defconfig updates for v4.10 :
>
>
> The following changes since commit 620c52f4db4d47e1f33c64e641392fe575d5397f:
>
> ARM: multi_v7_defconfig: Remove stih41x phy Kconfig symbol. (2016-10-20 17:05:08 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git sti-defconfig-for-4.10-round2
>
> for you to fetch changes up to 57dae748959d0abae2b382ccee68621a82f827c8:
>
> ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
>
> ----------------------------------------------------------------
>
> Remove STiH415/416 specific IPs
>
> As STiH415/416 have been removed from kernel, remove IPs only
> found on these socs, remove ST_THERMAL_SYSCFG.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] STi DT update for v4.10 round 2
From: Olof Johansson @ 2016-11-18 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <828ebfb1-7ed0-8e6b-116d-9ef74d804db6@st.com>
On Thu, Nov 10, 2016 at 10:00:48AM +0100, Patrice Chotard wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this second round of STi dts update for v4.10 :
>
> The following changes since commit 97a0b97f9e8197429eee5f87ce14373f73dbd9d3:
>
> ARM: dts: stih410-clocks: Add PROC_STFE as a critical clock (2016-10-20 16:20:26 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-4.10-round2
>
> for you to fetch changes up to 64783ea7de0bff3de77cfdff1ed76428c288faac:
>
> ARM: dts: STiHxxx-b2120: change sound card name (2016-11-10 09:52:49 +0100)
>
> ----------------------------------------------------------------
> STi dts update:
>
> Change sound card name for B2120
> Enable sound card for B2260
> Remove stih415-clks.h
> Identify critical clocks for STiH407
> Fix typo in stih407-pinctrl.dtsi
>
> ----------------------------------------------------------------
> Arnaud Pouliquen (2):
> ARM: dts: STiH410-B2260: enable sound card
> ARM: dts: STiHxxx-b2120: change sound card name
>
> Geert Uytterhoeven (1):
> ARM: dts: STiH407: DT fix s/interrupts-names/interrupt-names/
>
> Patrice Chotard (1):
> ARM: dts: remove stih415-clks.h
>
> Peter Griffin (1):
> ARM: dts: stih407-clocks: Identify critical clocks
>
> arch/arm/boot/dts/stih407-clock.dtsi | 10 ++++++++++
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 2 +-
> arch/arm/boot/dts/stih410-b2260.dts | 22 ++++++++++++++++++++++
> arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +-
> include/dt-bindings/clock/stih415-clks.h | 16 ----------------
> 5 files changed, 34 insertions(+), 18 deletions(-)
> delete mode 100644 include/dt-bindings/clock/stih415-clks.h
>
>
>
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS updates for v4.10
From: Olof Johansson @ 2016-11-18 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111205915.22173-1-dinguyen@kernel.org>
On Fri, Nov 11, 2016 at 02:59:14PM -0600, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in part 2 of these DTS updates for v4.10.
>
> Thanks,
> Dinh
>
> The following changes since commit c96f5919e6b0d132aa9afe9f1adc872fc107d5bb:
>
> ARM: dts: socfpga: socrates: enable qspi (2016-10-18 22:18:14 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.10_part_2
>
> for you to fetch changes up to d837a80d19505d74ee5941eebf9dd53fed6f36a6:
>
> ARM: dts: socfpga: add nand controller nodes (2016-11-09 12:40:52 -0600)
>
> ----------------------------------------------------------------
> SoCFPGA DTS update for v4.10, part 2
> - Add specific compatible strings for variants of Cyclone5 boards
> - Add QSPI node on Arria10
> - Enable QSPI on Arria5 and Arria10 devkit, and Cyclone5 SoCKit
> - Add NAND controller node on Cyclone5
>
> ----------------------------------------------------------------
> Dinh Nguyen (6):
> ARM: dts: socfpga: add specific compatible strings for boards
> ARM: dts: socfpga: enable qspi on the Cyclone5 devkit
> ARM: dts: socfpga: Add QSPI node for the Arria10
> ARM: dts: socfpga: Enable QSPI in Arria10 devkit
> ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
> ARM: dts: socfpga: Enable QSPI on the Arria5 devkit
>
> Steffen Trumtrar (1):
> ARM: dts: socfpga: add nand controller nodes
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/socfpga.dtsi | 13 ++++++
> arch/arm/boot/dts/socfpga_arria10.dtsi | 14 +++++++
> arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts | 49 ++++++++++++++++++++++
> arch/arm/boot/dts/socfpga_arria5_socdk.dts | 33 +++++++++++++++
> arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 35 +++++++++++++++-
> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 23 +++++++++-
> arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
> 11 files changed, 170 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA defconfig updates for v4.10
From: Olof Johansson @ 2016-11-18 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111205915.22173-2-dinguyen@kernel.org>
On Fri, Nov 11, 2016 at 02:59:15PM -0600, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull these defconfig updates for v4.10.
>
> Thanks,
> Dinh
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.10
>
> for you to fetch changes up to cab004fa972f06b236ba6b592bbb0512d5c6c158:
>
> ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem (2016-11-09 08:11:31 -0600)
>
> ----------------------------------------------------------------
> SoCFPGA defconfig updates for v4.10
> - enable QSPI, HIGHMEM, FPGA bridge and device-tree overlays
> - enable AUTOFS4 and NFS file system support
>
> ----------------------------------------------------------------
> Alan Tull (1):
> ARM: socfpga: updates for socfpga_defconfig
>
> Dinh Nguyen (2):
> ARM: socfpga_defconfig: Enable HIGHMEM
> ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem
>
> Steffen Trumtrar (1):
> ARM: socfpga: defconfig: enable qspi
Merged, thanks.
-Olof
^ 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