* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-18 9:01 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118095455.00bfe007-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
>
>> - soc {
>> + /* The following unit address is composed of the target
>> + * value (bit [40-47]), attributes value (bits [32-39],
>> + * and the address value in the window memory: [0-31].
>> + */
>> + soc@f00100000000 {
>
> Where is this value coming from? Why does the soc node needs to have a
It cames from the dts files.
> unit address? It doesn't have a 'reg' property if I remember
> correctly.
But it has a range property.
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Thomas Petazzoni @ 2016-11-18 8:59 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161117230830.31047-7-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
> - crypto_sram0: sa-sram0 {
> + /* The following unit addresses (for sa-sram) are composed of
> + * the target value (bit [40-47]), attributes value (bits
> + * [32-39], and the address value in the window memory: [0-31].
> + */
The "address value in the window memory" part doesn't make a lot of
sense. Maybe:
"The following unit addresses are composed of the window target ID
(bits 40-47), the window target attributes (bits 32-39) and the offset
inside the window."
Also, the comment formatting is not compliant with the coding style,
should be:
/*
* ...
* ...
*/
But do we really want this comment above each node? Couldn't we instead
add this explanation in the mvebu-mbus.txt DT binding?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 8:54 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161117230830.31047-10-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
> - soc {
> + /* The following unit address is composed of the target
> + * value (bit [40-47]), attributes value (bits [32-39],
> + * and the address value in the window memory: [0-31].
> + */
> + soc@f00100000000 {
Where is this value coming from? Why does the soc node needs to have a
unit address? It doesn't have a 'reg' property if I remember correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: kernel-TqfNSX0MhmxHKSADF0wUEw @ 2016-11-18 8:32 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Zhang Rui, Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Lee Jones, Eric Anholt, Russell King, Florian Fainelli,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161117151019.GA3115-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
> On 17.11.2016, at 16:10, Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hello Martin,
>
> On Thu, Nov 17, 2016 at 10:51:33AM +0100, Martin Sperl wrote:
>>
>>
>> On 17.11.2016 03:11, Eduardo Valentin wrote:
>>> Hey Martin,
>>>
>>> Very sorry for the late feedback. Not so sure if this one got queued
>>> already or not. Anyways, just minor questions as follows:
>>>
>>> On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org wrote:
>>>> From: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
>>>>
>>>> Add basic thermal driver for bcm2835 SOC.
>>>>
>>>> This driver currently relies on the firmware setting up the
>>>> tsense HW block and does not set it up itself.
>>>>
>>>> Signed-off-by: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
>>>> Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>>> Acked-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
>>>>
>> ...
>>>> +static int bcm2835_thermal_adc2temp(
>>>> + const struct bcm2835_thermal_info *info, u32 adc)
>>>> +{
>>>> + return info->offset + (adc * info->slope);
>>>
>>> Any specific reason we cannot use thermal_zone_params->slope and
>>> thermal_zone_params->offset?
>>
>> You could - the patch was just rebased to 4.9 and those slope and
>> offset just got merged during this cycle.
>>
>> Do we really need to modify it - the patch has been around since 4.6.
>>
>>>> +
>>>> +static int bcm2835_thermal_get_trip_temp(
>>>> + struct thermal_zone_device *tz, int trip, int *temp)
>>>> +{
>>>> + struct bcm2835_thermal_data *data = tz->devdata;
>>>> + u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
>>>> +
>>>> + /* get the THOLD bits */
>>>> + val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
>>>> + val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
>>>> +
>>>> + /* if it is zero then use the info value */
>>>> + if (val)
>>>
>>> Is this a read only register or is this driver supposed to program it?
>>> In which scenario it would be 0? Can this be added as comments?
>>
>> It is RW, but the Firmware typically sets up the thermal device with the
>> correct values already - this is just a fallback.
>
> OK, but how do you differentiate from a buggy firmware or misconfigured
> hardware? How do you know if the firmware is supposed to be loaded and
> ready? There is no firmware loading in this driver. Also, there is no
> dependency with a driver that loads firmware, or at least, I missed it.
>
The way that firmware works on the RPI is quite different from most others I guess.
in principle you got 2 different CPUs on the bcm2835:
* ARM, which runs the linux instance
* VideoCore 4, which runs the firmware (loading from SD initially) and
then booting the ARM.
So this Firmware on VC4 is the one that I am talking about.
Without the working firmware linux can not boot on arm.
As of now he firmware is also checking temperature of the SOC itself and
if it finds “critical” temperatures it will clock down ARM and the GPU.
Hope that this explains the “firmware” on bcm2835.
>>
>>>> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
>>>> + int *temp)
>>>> +{
>>>> + struct bcm2835_thermal_data *data = tz->devdata;
>>>> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
>>>> +
>>>> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
>>>
>>> What cases you would get the valid bit not set? Do you need to wait for
>>> the conversion to finish?
>>
>> I guess: if you have just enabled the HW-block (which the FW does much
>> in advance) and start to read the value immediately (before the first sample
>> period has finished), then this will not be valid.
>>
>
> Then again, how does this driver make sure the initialization procedure
> is correct, and that by the time it is using the hardware, the hardware
> is in a sane state?
>
> Back to the original question, does it mean the hardware is in
> some sort of continuous ADC conversion mode or reading the temperature
> requires specific steps to get the conversion done, and therefore you
> are checking the valid bit here?
As far as I understand the conversion is continuous (as soon as the HW is
configured). This case is there primarily to handle the situation where
we initialize the HW ourselves (see line 226 and below), and we immediately
want to read the ADC value before the first conversion is finished.
The above mentioned “configuration if not running” reflect the values that
the FW is currently setting. We should not change those values as long as the
Firmware is also reading the temperature on its own.
>
>> So do you need another version of the patchset that uses that new API?
>
> I think the API usage is change that can be done together with
> clarification for the above questions too: on hardware state,
> firmware loading, maybe a master driver dependency, and the ADC
> conversion sequence, which are not well clear to me on this driver. As long as
> this is clarified and documented in the code (can be simple comments so
> it is clear to whoever reads in the future), then I would be OK with
> this driver.
So how do you want this to get “documented” in the driver?
The setup and Firmware is a generic feature of the SOC, so if we would put
some clarifications in this driver, then we would need to put it in every
bcm283X driver (which seems unreasonable).
Thanks,
Martin--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute
From: Juri Lelli @ 2016-11-18 8:27 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
sudeep.holla-5wv7dgnIgG8, lorenzo.pieralisi-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
morten.rasmussen-5wv7dgnIgG8, dietmar.eggemann-5wv7dgnIgG8,
broonie-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20161103052842.GA16920@e106622-lin>
Hi Russell,
On 03/11/16 05:28, Juri Lelli wrote:
> Hi,
>
> apologies for the delay in replying, but I'm attending Linux Plumbers
> this week.
>
> On 30/10/16 20:45, Russell King - ARM Linux wrote:
> > On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote:
[...]
>
> I should have addressed your comments with the updated version below. If
> it looks good to you I'll superseed the old version with this new one.
>
The two updated patches are still listed as incoming in your system.
Do you think we will be able to queue them for 4.10? IMHO, it would be
good to have all pieces in together at once (Catalin and Sudeep already
queued their respective bits).
Thanks a lot.
Best,
- Juri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] hwmon: ltc2990: refactor value conversion
From: Tom Levens @ 2016-11-18 8:18 UTC (permalink / raw)
To: Guenter Roeck
Cc: Tom Levens, jdelvare, robh+dt, mark.rutland, linux-kernel,
linux-hwmon, devicetree
In-Reply-To: <1eff12d5-e0f9-aaa0-010d-1ddcccdd6ec9@roeck-us.net>
Hi Guenter,
On Thu, 17 Nov 2016, Guenter Roeck wrote:
> On 11/17/2016 08:23 AM, Tom Levens wrote:
>> Hi Guenter,
>>
>> Thanks for taking the time to review the patch.
>>
>> On Thu, 17 Nov 2016, Guenter Roeck wrote:
>>
>> > Hi Tom,
>> >
>> > On 11/17/2016 04:10 AM, Tom Levens wrote:
>> > > Conversion from raw values to signed integers has been refactored
>> > > using
>> > > the macros in bitops.h.
>> > >
>> > Please also mention that this fixes a bug in negative temperature
>> > conversions.
>>
>> Yes, of course, I will include the information in v3.
>>
>> >
>> > > Signed-off-by: Tom Levens <tom.levens@cern.ch>
>> > > ---
>> > > drivers/hwmon/ltc2990.c | 27 ++++++++++-----------------
>> > > 1 files changed, 10 insertions(+), 17 deletions(-)
>> > >
>> > > diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
>> > > index 8f8fe05..0ec4102 100644
>> > > --- a/drivers/hwmon/ltc2990.c
>> > > +++ b/drivers/hwmon/ltc2990.c
>> > > @@ -9,8 +9,12 @@
>> > > * This driver assumes the chip is wired as a dual current monitor,
>> > > and
>> > > * reports the voltage drop across two series resistors. It also
>> > > reports
>> > > * the chip's internal temperature and Vcc power supply voltage.
>> > > + *
>> > > + * Value conversion refactored
>> > > + * by Tom Levens <tom.levens@cern.ch>
>> >
>> > Kind of unusual to do that for minor changes like this. Imagine if
>> > everyone would do that.
>> > The commit log is what gives you credit.
>>
>> Good point, thanks for the hint. I will remove it from v3.
>>
>> > > */
>> > >
>> > > +#include <linux/bitops.h>
>> > > #include <linux/err.h>
>> > > #include <linux/hwmon.h>
>> > > #include <linux/hwmon-sysfs.h>
>> > > @@ -34,19 +38,10 @@
>> > > #define LTC2990_CONTROL_MODE_CURRENT 0x06
>> > > #define LTC2990_CONTROL_MODE_VOLTAGE 0x07
>> > >
>> > > -/* convert raw register value to sign-extended integer in 16-bit
>> > > range */
>> > > -static int ltc2990_voltage_to_int(int raw)
>> > > -{
>> > > - if (raw & BIT(14))
>> > > - return -(0x4000 - (raw & 0x3FFF)) << 2;
>> > > - else
>> > > - return (raw & 0x3FFF) << 2;
>> > > -}
>> > > -
>> > > /* Return the converted value from the given register in uV or mC */
>> > > -static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, int
>> > > *result)
>> > > +static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, s32
>> > > *result)
>> > > {
>> > > - int val;
>> > > + s32 val;
>> >
>> > Please just leave the variable type alone. it is also used for the
>> > return value
>> > from i2c_smbus_read_word_swapped(), which is an int, and changing it to
>> > s32 doesn't really make the code better.
>>
>> According to i2c.h the return type for i2c_smbus_read_word_swapped() is
>> s32, which is why I modified it here. But it could be changed back if you
>> think it is better to leave it as an int.
>>
> Ah, ok. Good to know. Please leave it anyway, reason being that there is no
> real
> reason to change it. Effectively those are just whitespace changes (unlike
> the rest,
> which is part bug fix, part cleanup).
>
>> > Can you send me a register map for the chip ? I would like to write a
>> > module test.
>>
>> Here is an example register dump:
>
> I meant the output of i2cdump (something like "i2cdump -y -f <bus>
> <i2c-address> w").
>
The register map wraps at 0x0F, so I only sent you the first 16 bytes. But
the fully expanded form is:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
10: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
20: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
30: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
40: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
50: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
60: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
70: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
80: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
90: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
a0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
b0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
c0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
d0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
e0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
f0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
Cheers,
> Thanks,
> Guenter
>
>>
>> 00 00 00 00
>> 01 90 07 d0
>> 2c cd 7d 80
>> 7c 29 20 00
>>
>> The expected values in this case are:
>>
>> in0_input 5000
>> in1_input 610
>> in2_input 3500
>> in3_input -195
>> in4_input -299
>> temp1_input 25000
>> temp2_input 125000
>> temp3_input -40000
>> curr1_input 38840
>> curr2_input -12428
>>
>> Testing with lltc,mode set to <5>, <6> and <7> should give you all
>> measurements.
>>
>> > Thanks,
>> > Guenter
>>
>> Cheers,
>>
>
>
^ permalink raw reply
* [PATCH] arm64: dts: exynos: add the mshc_2 node for supporting T-Flash
From: Jaehoon Chung @ 2016-11-18 7:12 UTC (permalink / raw)
To: linux-samsung-soc
Cc: linux-kernel, devicetree, kgene, krzk, cw00.choi, robh+dt,
mark.rutland, catalin.marinas, will.deacon, Jaehoon Chung
Add the mshc_2 node for supporting T-flash.
And it needs to add the "mshc*" aliases. Because dwmmc driver should be
assigned to "ctrl_id" after parsing to "mshc".
If there is no aliases for mshc, then it might be set to the wrong
capabilities.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 9ea3f32..75dab01 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -42,6 +42,8 @@
spi2 = &spi_2;
spi3 = &spi_3;
spi4 = &spi_4;
+ mshc0 = &mshc_0;
+ mshc2 = &mshc_2;
};
chosen {
@@ -661,6 +663,23 @@
assigned-clock-rates = <800000000>;
};
+&mshc_2 {
+ status = "okay";
+ num-slots = <1>;
+ cap-sd-highspeed;
+ disable-wp;
+ cd-gpios = <&gpa2 4 0>;
+ cd-inverted;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <0 4>;
+ samsung,dw-mshc-ddr-timing = <0 2>;
+ fifo-depth = <0x80>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
+ bus-width = <4>;
+};
+
&pinctrl_alive {
pinctrl-names = "default";
pinctrl-0 = <&initial_alive>;
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Jiancheng Xue @ 2016-11-18 6:42 UTC (permalink / raw)
To: Marty Plummer
Cc: Wei Xu, wenpan, Arnd Bergmann, mturquette, sboyd, robh+dt,
mark.rutland, linux, linux-clk, devicetree, linux-kernel,
linux-arm-kernel, howell.yang, jalen.hsu, lvkuanliang, suwenping,
raojun, kevin.lixu, qinxiaojun
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
* Re: [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: Daniel Kurtz
Cc: Mark Rutland, stonea168, dri-devel,
Yingjoe Chen (陳英洲), Ajay Kumar,
Vincent Palatin, cawa cheng, Russell King,
open list:OPEN FIRMWARE AND..., Jitao Shi, Pawel Moll,
Ian Campbell, Rob Herring,
moderated list:ARM/Mediatek SoC support, Andy Yan,
Matthias Brugger, Eddie Huang (黃智傑),
linux-arm-kernel@lists.infradead.org
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.
> >> ---
> >>
> >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [v3,2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Christopher Spinrath @ 2016-11-18 5:00 UTC (permalink / raw)
To: Jyri Sarha, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w, khilman-rdvid1DuHRBWk0Htik3J/w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, Spinrath, Christopher
In-Reply-To: <6eaa1b5d467cd354f7d5dc5ff8da1b9bf732ff11.1479388871.git.jsarha-l0cyMroinI0@public.gmane.org>
Hi Jyri,
On 11/17/2016 02:28 PM, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
s/ftp/tfp ?
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. However, because of missing DRM
> infrastructure support the connector is implemented within the bridge
> driver. Some tfp410 HW specific features may be added later if needed,
> because there is a set of registers behind i2c if it is connected.
>
> This implementation is tested against my new tilcdc bridge support
> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
> is also added.
>
> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
Thanks for working on this. I have tested the driver on my Utilite Pro
which is based on the imx6q SoC and has a tfp410 chip hooked up to its
parallel rgb24 interface. So you can add my
Tested-By: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
However, I have two more comments below.
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 40 +++
> drivers/gpu/drm/bridge/Kconfig | 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 287 +++++++++++++++++++++
> 4 files changed, 335 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> new file mode 100644
> index 0000000..6174b18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
There already is a binding documentation for the tfp410 in
Documentation/devicetree/bindings/display/ti/ti,tfp410.txt .
It is used by the omap drm driver. IMHO you should extend, move or
deprecate that one. Note that it describes an optional powerdown-gpios
property.
> @@ -0,0 +1,40 @@
> +TFP410 DVI bridge bindings
> +
> +Required properties:
> + - compatible: "ti,tfp410"
> +
> +Optional properties
> + - reg: I2C address. If and only if present the device node
> + should be placed into the i2c controller node where the
> + tfp410 i2c is connected to.
> +
> +Required subnodes:
> + - port@0: Video input port node to connect the bridge to a
> + display controller output [1].
> + - port@1: Video output port node to connect the bridge to a
> + connector input [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + hdmi-bridge {
> + compatible = "ti,tfp410";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + bridge_in: endpoint {
> + remote-endpoint = <&dc_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + bridge_out: endpoint {
> + remote-endpoint = <&hdmi_in>;
> + };
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index bd6acc8..a424e03 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
> ---help---
> Toshiba TC358767 eDP bridge chip driver.
>
> +config DRM_TI_TFP410
> + tristate "TI TFP410 DVI/HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + ---help---
> + Texas Instruments TFP410 DVI/HDMI Transmitter driver
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 97ed1a5..8b065d9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> new file mode 100644
> index 0000000..64f54e4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -0,0 +1,287 @@
> +/*
> + * Copyright (C) 2016 Texas Instruments
> + * Author: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_graph.h>
> +#include <linux/platform_device.h>
> +#include <linux/i2c.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +
> +struct tfp410 {
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> +
> + struct i2c_adapter *ddc;
> +
> + struct device *dev;
> +};
> +
> +static inline struct tfp410 *
> +drm_bridge_to_tfp410(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct tfp410, bridge);
> +}
> +
> +static inline struct tfp410 *
> +drm_connector_to_tfp410(struct drm_connector *connector)
> +{
> + return container_of(connector, struct tfp410, connector);
> +}
> +
> +static int tfp410_get_modes(struct drm_connector *connector)
> +{
> + struct tfp410 *dvi = drm_connector_to_tfp410(connector);
> + struct edid *edid;
> + int ret;
> +
> + if (!dvi->ddc)
> + goto fallback;
> +
> + edid = drm_get_edid(connector, dvi->ddc);
> + if (!edid) {
> + DRM_INFO("EDID read failed. Fallback to standard modes\n");
> + goto fallback;
> + }
> +
> + drm_mode_connector_update_edid_property(connector, edid);
> +
> + return drm_add_edid_modes(connector, edid);
> +fallback:
> + /* No EDID, fallback on the XGA standard modes */
> + ret = drm_add_modes_noedid(connector, 1920, 1200);
> +
> + /* And prefer a mode pretty much anything can handle */
> + drm_set_preferred_mode(connector, 1024, 768);
> +
> + return ret;
> +}
> +
> +static const struct drm_connector_helper_funcs tfp410_con_helper_funcs = {
> + .get_modes = tfp410_get_modes,
> +};
> +
> +static enum drm_connector_status
> +tfp410_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct tfp410 *dvi = drm_connector_to_tfp410(connector);
> +
> + if (dvi->ddc) {
> + if (drm_probe_ddc(dvi->ddc))
> + return connector_status_connected;
> + else
> + return connector_status_disconnected;
> + }
I wonder what happens if a display with none or defect ddc/edid is
attached? The dumb-vga-dac bridge driver reports
connector_status_unknown in the case drm_probe_ddc fails.
Cheers,
Christopher
> +
> + return connector_status_unknown;
> +}
> +
> +static const struct drm_connector_funcs tfp410_con_funcs = {
> + .dpms = drm_atomic_helper_connector_dpms,
> + .detect = tfp410_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int tfp410_attach(struct drm_bridge *bridge)
> +{
> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
> + int ret;
> +
> + if (!bridge->encoder) {
> + dev_err(dvi->dev, "Missing encoder\n");
> + return -ENODEV;
> + }
> +
> + drm_connector_helper_add(&dvi->connector,
> + &tfp410_con_helper_funcs);
> + ret = drm_connector_init(bridge->dev, &dvi->connector,
> + &tfp410_con_funcs, DRM_MODE_CONNECTOR_HDMIA);
> + if (ret) {
> + dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
> + return ret;
> + }
> +
> + drm_mode_connector_attach_encoder(&dvi->connector,
> + bridge->encoder);
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> + .attach = tfp410_attach,
> +};
> +
> +static int tfp410_get_connector_ddc(struct tfp410 *dvi)
> +{
> + struct device_node *ep = NULL, *connector_node = NULL;
> + struct device_node *ddc_phandle = NULL;
> + int ret = 0;
> +
> + /* port@1 is the connector node */
> + ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, -1);
> + if (!ep)
> + goto fail;
> +
> + connector_node = of_graph_get_remote_port_parent(ep);
> + if (!connector_node)
> + goto fail;
> +
> + ddc_phandle = of_parse_phandle(connector_node, "ddc-i2c-bus", 0);
> + if (!ddc_phandle)
> + goto fail;
> +
> + dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
> + if (dvi->ddc)
> + dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
> + else
> + ret = -EPROBE_DEFER;
> +
> +fail:
> + of_node_put(ep);
> + of_node_put(connector_node);
> + of_node_put(ddc_phandle);
> + return ret;
> +}
> +
> +static int tfp410_init(struct device *dev)
> +{
> + struct tfp410 *dvi;
> + int ret;
> +
> + if (!dev->of_node) {
> + dev_err(dev, "device-tree data is missing\n");
> + return -ENXIO;
> + }
> +
> + dvi = devm_kzalloc(dev, sizeof(*dvi), GFP_KERNEL);
> + if (!dvi)
> + return -ENOMEM;
> + dev_set_drvdata(dev, dvi);
> +
> + dvi->bridge.funcs = &tfp410_bridge_funcs;
> + dvi->bridge.of_node = dev->of_node;
> + dvi->dev = dev;
> +
> + ret = tfp410_get_connector_ddc(dvi);
> + if (ret)
> + goto fail;
> +
> + ret = drm_bridge_add(&dvi->bridge);
> + if (ret) {
> + dev_err(dev, "drm_bridge_add() failed: %d\n", ret);
> + goto fail;
> + }
> +
> + return 0;
> +fail:
> + i2c_put_adapter(dvi->ddc);
> + return ret;
> +}
> +
> +static int tfp410_fini(struct device *dev)
> +{
> + struct tfp410 *dvi = dev_get_drvdata(dev);
> +
> + drm_bridge_remove(&dvi->bridge);
> +
> + if (dvi->ddc)
> + i2c_put_adapter(dvi->ddc);
> +
> + return 0;
> +}
> +
> +static int tfp410_probe(struct platform_device *pdev)
> +{
> + return tfp410_init(&pdev->dev);
> +}
> +
> +static int tfp410_remove(struct platform_device *pdev)
> +{
> + return tfp410_fini(&pdev->dev);
> +}
> +
> +/* There is currently no i2c functionality. */
> +static int tfp410_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + int reg;
> +
> + if (!client->dev.of_node ||
> + of_property_read_u32(client->dev.of_node, "reg", ®)) {
> + dev_err(&client->dev,
> + "Can't get i2c reg property from device-tree\n");
> + return -ENXIO;
> + }
> +
> + return tfp410_init(&client->dev);
> +}
> +
> +static int tfp410_i2c_remove(struct i2c_client *client)
> +{
> + return tfp410_fini(&client->dev);
> +}
> +
> +static const struct of_device_id tfp410_match[] = {
> + { .compatible = "ti,tfp410" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, tfp410_match);
> +
> +struct platform_driver tfp410_platform_driver = {
> + .probe = tfp410_probe,
> + .remove = tfp410_remove,
> + .driver = {
> + .name = "tfp410-bridge",
> + .of_match_table = tfp410_match,
> + },
> +};
> +
> +static const struct i2c_device_id tfp410_i2c_ids[] = {
> + { "tfp410", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, tfp410_i2c_ids);
> +
> +static struct i2c_driver tfp410_i2c_driver = {
> + .driver = {
> + .name = "tfp410",
> + .of_match_table = of_match_ptr(tfp410_match),
> + },
> + .id_table = tfp410_i2c_ids,
> + .probe = tfp410_i2c_probe,
> + .remove = tfp410_i2c_remove,
> +};
> +
> +static int __init tfp410_module_init(void)
> +{
> + i2c_add_driver(&tfp410_i2c_driver);
> + platform_driver_register(&tfp410_platform_driver);
> +
> + return 0;
> +}
> +module_init(tfp410_module_init);
> +
> +static void __exit tfp410_module_exit(void)
> +{
> + i2c_del_driver(&tfp410_i2c_driver);
> + platform_driver_unregister(&tfp410_platform_driver);
> +}
> +module_exit(tfp410_module_exit);
> +
> +MODULE_AUTHOR("Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>");
> +MODULE_DESCRIPTION("TI TFP410 DVI bridge driver");
> +MODULE_LICENSE("GPL");
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Nishanth Menon @ 2016-11-18 4:34 UTC (permalink / raw)
To: Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Julien, Tomi Valkeinen, Lucas Stach, robh-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <CAOCHtYh8QebrYA2ioaXgURdc47QY4x+EwZLBXLLGP1-k7eAMmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Robert Nelson @ 2016-11-18 4:26 UTC (permalink / raw)
To: Nishanth Menon
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Julien, Tomi Valkeinen, Lucas Stach, robh-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <3eb346ad-1675-e613-93ef-bd2d07bf2ab8-l0cyMroinI0@public.gmane.org>
On Thu, Nov 17, 2016 at 10:15 PM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> wrote:
> On 11/17/2016 09:44 PM, Robert Nelson wrote:
>>
>> On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
>>>> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>>>> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>> 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/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Nishanth Menon @ 2016-11-18 4:15 UTC (permalink / raw)
To: Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Julien, Tomi Valkeinen, Lucas Stach, robh-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <CAOCHtYiUz1cjYw9nNa4YZGtzNVgSgjEa=4Lqiktz07rszsSksw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/17/2016 09:44 PM, Robert Nelson wrote:
> On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
>>> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>>> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 04/16] ARM: dts: Add xo to sdhc clock node on qcom platforms
From: Andy Gross @ 2016-11-18 3:56 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, sboyd, shawn.lin,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd,
david.griego, stummala, venkatg, rnayak, pramod.gurav, jeremymc
In-Reply-To: <1479343419-29326-1-git-send-email-riteshh@codeaurora.org>
On Thu, Nov 17, 2016 at 06:13:39AM +0530, Ritesh Harjani wrote:
> Add xo entry to sdhc clock node on all qcom platforms.
>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi | 16 ++++++++++------
> arch/arm/boot/dts/qcom-msm8974.dtsi | 16 ++++++++++------
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 ++++++----
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
> 4 files changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi b/arch/arm/boot/dts/qcom-apq8084.dtsi
> index 39eb7a4..f756cbb 100644
> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
> @@ -182,13 +182,13 @@
> };
>
> clocks {
> - xo_board {
> + xo_board: xo_board {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <19200000>;
> };
>
> - sleep_clk {
> + sleep_clk: sleep_clk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <32768>;
> @@ -416,8 +416,10 @@
> reg-names = "hc_mem", "core_mem";
> interrupts = <0 123 0>, <0 138 0>;
> interrupt-names = "hc_irq", "pwr_irq";
> - clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
> - clock-names = "core", "iface";
> + clocks = <&gcc GCC_SDCC1_APPS_CLK>,
> + <&gcc GCC_SDCC1_AHB_CLK>,
> + <&xo_board 0>;
With clock-cells = <0>, this should be <&xo_board>
Somehow this passes the dtc compiler. But it is still incorrect. Please fix
all instances of this to use the correct number of cells in the xo_board
references.
Andy
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Robert Nelson @ 2016-11-18 3:44 UTC (permalink / raw)
To: Nishanth Menon
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Julien, Tomi Valkeinen, Lucas Stach, robh-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <e69a797c-bec3-2243-5c19-9d7633092369-l0cyMroinI0@public.gmane.org>
On Thu, Nov 17, 2016 at 8:56 PM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
>> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> ---
>> 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/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: Daniel Kurtz @ 2016-11-18 3:22 UTC (permalink / raw)
To: CK Hu
Cc: Mark Rutland, stonea168, dri-devel,
Yingjoe Chen (陳英洲), Ajay Kumar,
Vincent Palatin, cawa cheng, Russell King,
open list:OPEN FIRMWARE AND..., Jitao Shi, Pawel Moll,
Ian Campbell, Rob Herring,
moderated list:ARM/Mediatek SoC support, Andy Yan,
Matthias Brugger, Eddie Huang (黃智傑),
linux-arm-kernel@lists.infradead.org
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.
>> ---
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 2/2] mtd: spi-nor: add rockchip serial flash controller driver
From: Shawn Lin @ 2016-11-18 2:59 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Marek Vasut, Cyrille Pitchen, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner,
Shawn Lin
In-Reply-To: <1479437945-27918-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add rockchip serial flash controller driver
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- fix typos
- add some comment for buffer and others operations
- rename SFC_MAX_CHIP_NUM to MAX_CHIPSELECT_NUM
- use u8 for cs
- return -EINVAL for default case of get_if_type
- use readl_poll_*() to check timeout cases
- simplify and clarify some condition checks
- rework the bitshifts to simplify the code
- define SFC_CMD_DUMMY(x)
- fix ummap for dma read path and finish all the
cache maintenance.
- rename to rockchip_sfc_chip_priv and embed struct spi_nor
in it.
- add MODULE_AUTHOR
- add runtime PM and general PM support.
- Thanks for Marek's comments. Link:
http://lists.infradead.org/pipermail/linux-mtd/2016-November/070321.html
MAINTAINERS | 8 +
drivers/mtd/spi-nor/Kconfig | 7 +
drivers/mtd/spi-nor/Makefile | 1 +
drivers/mtd/spi-nor/rockchip-sfc.c | 971 +++++++++++++++++++++++++++++++++++++
4 files changed, 987 insertions(+)
create mode 100644 drivers/mtd/spi-nor/rockchip-sfc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..eb7e06d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10266,6 +10266,14 @@ L: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
S: Odd Fixes
F: drivers/tty/serial/rp2.*
+ROCKCHIP SERIAL FLASH CONTROLLER DRIVER
+M: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
+L: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
+L: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
+S: Maintained
+F: Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
+F: drivers/mtd/spi-nor/rockchip-sfc.c
+
ROSE NETWORK LAYER
M: Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
L: linux-hams-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 4a682ee..bf783a8 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -76,4 +76,11 @@ config SPI_NXP_SPIFI
Flash. Enable this option if you have a device with a SPIFI
controller and want to access the Flash as a mtd device.
+config SPI_ROCKCHIP_SFC
+ tristate "Rockchip Serial Flash Controller(SFC)"
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
+ depends on HAS_IOMEM && HAS_DMA
+ help
+ This enables support for rockchip serial flash controller.
+
endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 121695e..364d4c6 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_MTD_MT81xx_NOR) += mtk-quadspi.o
obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o
+obj-$(CONFIG_SPI_ROCKCHIP_SFC) += rockchip-sfc.o
diff --git a/drivers/mtd/spi-nor/rockchip-sfc.c b/drivers/mtd/spi-nor/rockchip-sfc.c
new file mode 100644
index 0000000..061f2c4
--- /dev/null
+++ b/drivers/mtd/spi-nor/rockchip-sfc.c
@@ -0,0 +1,971 @@
+/*
+ * Rockchip Serial Flash Controller Driver
+ *
+ * Copyright (c) 2016, Rockchip Inc.
+ * Author: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/dma-mapping.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/spi-nor.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+
+/* System control */
+#define SFC_CTRL 0x0
+#define SFC_CTRL_COMMON_BITS_1 0x0
+#define SFC_CTRL_COMMON_BITS_2 0x1
+#define SFC_CTRL_COMMON_BITS_4 0x2
+#define SFC_CTRL_DATA_BITS_SHIFT 12
+#define SFC_CTRL_DATA_BITS_MASK 0x3
+#define SFC_CTRL_ADDR_BITS_SHIFT 10
+#define SFC_CTRL_ADDR_BITS_MASK 0x3
+#define SFC_CTRL_CMD_BITS_SHIFT 8
+#define SFC_CTRL_CMD_BITS_MASK 0x3
+#define SFC_CTRL_PHASE_SEL_NEGETIVE BIT(1)
+
+/* Interrupt mask */
+#define SFC_IMR 0x4
+#define SFC_IMR_RX_FULL BIT(0)
+#define SFC_IMR_RX_UFLOW BIT(1)
+#define SFC_IMR_TX_OFLOW BIT(2)
+#define SFC_IMR_TX_EMPTY BIT(3)
+#define SFC_IMR_TRAN_FINISH BIT(4)
+#define SFC_IMR_BUS_ERR BIT(5)
+#define SFC_IMR_NSPI_ERR BIT(6)
+#define SFC_IMR_DMA BIT(7)
+/* Interrupt clear */
+#define SFC_ICLR 0x8
+#define SFC_ICLR_RX_FULL BIT(0)
+#define SFC_ICLR_RX_UFLOW BIT(1)
+#define SFC_ICLR_TX_OFLOW BIT(2)
+#define SFC_ICLR_TX_EMPTY BIT(3)
+#define SFC_ICLR_TRAN_FINISH BIT(4)
+#define SFC_ICLR_BUS_ERR BIT(5)
+#define SFC_ICLR_NSPI_ERR BIT(6)
+#define SFC_ICLR_DMA BIT(7)
+/* FIFO threshold level */
+#define SFC_FTLR 0xc
+#define SFC_FTLR_TX_SHIFT 0
+#define SFC_FTLR_TX_MASK 0x1f
+#define SFC_FTLR_RX_SHIFT 8
+#define SFC_FTLR_RX_MASK 0x1f
+/* Reset FSM and FIFO */
+#define SFC_RCVR 0x10
+#define SFC_RCVR_RESET BIT(0)
+/* Enhanced mode */
+#define SFC_AX 0x14
+/* Address Bit number */
+#define SFC_ABIT 0x18
+/* Interrupt status */
+#define SFC_ISR 0x1c
+#define SFC_ISR_COMMON_ACTIVE 0x1
+#define SFC_ISR_COMMON_MASK 0x1
+#define SFC_ISR_RX_FULL_SHIFT 0
+#define SFC_ISR_RX_UFLOW_SHIFT 1
+#define SFC_ISR_TX_OFLOW_SHIFT 2
+#define SFC_ISR_TX_EMPTY_SHIFT 3
+#define SFC_ISR_TX_FINISH_SHIFT 4
+#define SFC_ISR_BUS_ERR_SHIFT 5
+#define SFC_ISR_NSPI_ERR_SHIFT 6
+#define SFC_ISR_DMA_SHIFT 7
+/* FIFO status */
+#define SFC_FSR 0x20
+#define SFC_FSR_TX_IS_FULL BIT(0)
+#define SFC_FSR_TX_IS_EMPTY BIT(1)
+#define SFC_FSR_RX_IS_EMPTY BIT(2)
+#define SFC_FSR_RX_IS_FULL BIT(3)
+#define SFC_FSR_TX_WATER_LVL_SHIFT 8
+#define SFC_FSR_TX_WATER_LVL_MASK 0x1f
+#define SFC_FSR_RX_WATER_LVL_SHIFT 16
+#define SFC_FSR_RX_WATER_LVL_MASK 0x1f
+/* FSM status */
+#define SFC_SR 0x24
+#define SFC_SR_IS_IDLE 0x0
+#define SFC_SR_IS_BUSY 0x1
+/* Raw interrupt status */
+#define SFC_RISR 0x28
+#define SFC_RISR_RX_FULL BIT(0)
+#define SFC_RISR_RX_UNDERFLOW BIT(1)
+#define SFC_RISR_TX_OVERFLOW BIT(2)
+#define SFC_RISR_TX_EMPTY BIT(3)
+#define SFC_RISR_TRAN_FINISH BIT(4)
+#define SFC_RISR_BUS_ERR BIT(5)
+#define SFC_RISR_NSPI_ERR BIT(6)
+#define SFC_RISR_DMA BIT(7)
+/* Master trigger */
+#define SFC_DMA_TRIGGER 0x80
+/* Src or Dst addr for master */
+#define SFC_DMA_ADDR 0x84
+/* Command */
+#define SFC_CMD 0x100
+#define SFC_CMD_IDX_SHIFT 0
+#define SFC_CMD_IDX_MASK 0xff
+#define SFC_CMD_DUMMY_SHIFT 8
+#define SFC_CMD_DUMMY_MASK 0xf
+#define SFC_CMD_DIR_RD 0
+#define SFC_CMD_DIR_WR 1
+#define SFC_CMD_DIR_SHIFT 12
+#define SFC_CMD_DIR_MASK 0x1
+#define SFC_CMD_ADDR_ZERO (0x0 << 14)
+#define SFC_CMD_ADDR_24BITS (0x1 << 14)
+#define SFC_CMD_ADDR_32BITS (0x2 << 14)
+#define SFC_CMD_ADDR_FRS (0x3 << 14)
+#define SFC_CMD_TRAN_BYTES_SHIFT 16
+#define SFC_CMD_TRAN_BYTES_MASK 0x3fff
+#define SFC_CMD_CS_SHIFT 30
+#define SFC_CMD_CS_MASK 0x3
+/* Address */
+#define SFC_ADDR 0x104
+/* Data */
+#define SFC_DATA 0x108
+
+#define SFC_MAX_CHIPSELECT_NUM 4
+#define SFC_MAX_IDLE_RETRY 10000
+#define SFC_WAIT_IDLE_TIMEOUT 1000000
+#define SFC_DMA_MAX_LEN 0x4000
+#define SFC_DMA_MAX_MASK (SFC_DMA_MAX_LEN - 1)
+#define SFC_CMD_DUMMY(x) \
+ (((x) & SFC_CMD_DUMMY_MASK) << SFC_CMD_DUMMY_SHIFT)
+
+enum rockchip_sfc_iftype {
+ IF_TYPE_STD,
+ IF_TYPE_DUAL,
+ IF_TYPE_QUAD,
+};
+
+struct rockchip_sfc;
+struct rockchip_sfc_chip_priv {
+ u8 cs;
+ u32 clk_rate;
+ struct spi_nor nor;
+ struct rockchip_sfc *sfc;
+};
+
+struct rockchip_sfc {
+ struct device *dev;
+ struct mutex lock;
+ void __iomem *regbase;
+ struct clk *hclk;
+ struct clk *clk;
+ /* virtual mapped addr for dma_buffer */
+ void *buffer;
+ dma_addr_t dma_buffer;
+ struct completion cp;
+ struct rockchip_sfc_chip_priv flash[SFC_MAX_CHIPSELECT_NUM];
+ u32 num_chip;
+ bool use_dma;
+ /* use negative edge of hclk to latch data */
+ bool negative_edge;
+};
+
+static int get_if_type(enum read_mode flash_read)
+{
+ enum rockchip_sfc_iftype if_type;
+
+ switch (flash_read) {
+ case SPI_NOR_DUAL:
+ if_type = IF_TYPE_DUAL;
+ break;
+ case SPI_NOR_QUAD:
+ if_type = IF_TYPE_QUAD;
+ break;
+ case SPI_NOR_NORMAL:
+ case SPI_NOR_FAST:
+ if_type = IF_TYPE_STD;
+ break;
+ default:
+ pr_err("unsupported SPI read mode\n");
+ return -EINVAL;
+ }
+
+ return if_type;
+}
+
+static int rockchip_sfc_reset(struct rockchip_sfc *sfc)
+{
+ int err;
+ u32 status;
+
+ writel_relaxed(SFC_RCVR_RESET, sfc->regbase + SFC_RCVR);
+
+ err = readl_poll_timeout(sfc->regbase + SFC_RCVR, status,
+ !(status & SFC_RCVR_RESET), 20,
+ jiffies_to_usecs(HZ));
+ if (err)
+ dev_err(sfc->dev, "SFC reset never finished\n");
+
+ /* Still need to clear the masked interrupt from RISR */
+ writel_relaxed(SFC_ICLR_RX_FULL | SFC_ICLR_RX_UFLOW |
+ SFC_ICLR_TX_OFLOW | SFC_ICLR_TX_EMPTY |
+ SFC_ICLR_TRAN_FINISH | SFC_ICLR_BUS_ERR |
+ SFC_ICLR_NSPI_ERR | SFC_ICLR_DMA,
+ sfc->regbase + SFC_ICLR);
+ return err;
+}
+
+static int rockchip_sfc_init(struct rockchip_sfc *sfc)
+{
+ int err;
+
+ err = rockchip_sfc_reset(sfc);
+ if (err)
+ return err;
+
+ /* Mask all eight interrupts */
+ writel_relaxed(0xff, sfc->regbase + SFC_IMR);
+
+ /*
+ * Phase configure for sfc to latch data by using
+ * ahb clock, and this configuration should be Soc
+ * specific.
+ */
+ if (sfc->negative_edge)
+ writel_relaxed(SFC_CTRL_PHASE_SEL_NEGETIVE,
+ sfc->regbase + SFC_CTRL);
+ else
+ writel_relaxed(0, sfc->regbase + SFC_CTRL);
+
+ return 0;
+}
+
+static int rockchip_sfc_prep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ int ret;
+
+ mutex_lock(&sfc->lock);
+ pm_runtime_get_sync(sfc->dev);
+
+ ret = clk_set_rate(sfc->clk, priv->clk_rate);
+ if (ret)
+ goto out;
+
+ ret = clk_prepare_enable(sfc->clk);
+ if (ret)
+ goto out;
+
+ return 0;
+
+out:
+ mutex_unlock(&sfc->lock);
+ return ret;
+}
+
+static void rockchip_sfc_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+
+ clk_disable_unprepare(sfc->clk);
+ mutex_unlock(&sfc->lock);
+ pm_runtime_mark_last_busy(sfc->dev);
+ pm_runtime_put_autosuspend(sfc->dev);
+}
+
+static int rockchip_sfc_wait_op_finish(struct rockchip_sfc *sfc)
+{
+ int err;
+ u32 status;
+
+ /*
+ * Note: tx and rx share the same fifo, so the rx's water level
+ * is the same as rx's, which means this function could be reused
+ * for checking the read operations as well.
+ */
+ err = readl_poll_timeout(sfc->regbase + SFC_FSR, status,
+ status & SFC_FSR_TX_IS_EMPTY,
+ 20, jiffies_to_usecs(2 * HZ));
+ if (err)
+ dev_err(sfc->dev, "SFC tx never empty\n");
+
+ return err;
+}
+
+static int rockchip_sfc_op_reg(struct spi_nor *nor,
+ u8 opcode, int len, u8 optype)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ u32 reg;
+ bool tx_no_empty, rx_no_empty, is_busy;
+
+ reg = readl_relaxed(sfc->regbase + SFC_FSR);
+ tx_no_empty = !(reg & SFC_FSR_TX_IS_EMPTY);
+ rx_no_empty = !(reg & SFC_FSR_RX_IS_EMPTY);
+
+ is_busy = readl_relaxed(sfc->regbase + SFC_SR);
+
+ if (tx_no_empty || rx_no_empty || is_busy)
+ rockchip_sfc_reset(sfc);
+
+ reg = (opcode & SFC_CMD_IDX_MASK) << SFC_CMD_IDX_SHIFT;
+ reg |= (len & SFC_CMD_TRAN_BYTES_MASK) << SFC_CMD_TRAN_BYTES_SHIFT;
+ reg |= (priv->cs & SFC_CMD_CS_MASK) << SFC_CMD_CS_SHIFT;
+ reg |= (optype & SFC_CMD_DIR_MASK) << SFC_CMD_DIR_SHIFT;
+
+ writel_relaxed(reg, sfc->regbase + SFC_CMD);
+
+ return rockchip_sfc_wait_op_finish(sfc);
+}
+
+static int rockchip_sfc_read_reg(struct spi_nor *nor, u8 opcode,
+ u8 *buf, int len)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ int ret;
+ u32 tmp, i;
+
+ ret = rockchip_sfc_op_reg(nor, opcode, len, SFC_CMD_DIR_RD);
+ if (ret)
+ return ret;
+
+ while (len > 0) {
+ tmp = readl_relaxed(sfc->regbase + SFC_DATA);
+ for (i = 0; i < ((len > 4) ? 4 : len); i++)
+ *buf++ = (u8)((tmp >> (i * 8)) & 0xff);
+
+ len = len - 4;
+ }
+
+ return 0;
+}
+
+static int rockchip_sfc_write_reg(struct spi_nor *nor, u8 opcode,
+ u8 *buf, int len)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ u32 dwords, i;
+
+ /* Align bytes to dwords */
+ dwords = (len + 3) >> 2;
+
+ for (i = 0; i < dwords; i++)
+ writel_relaxed(*(buf + 4 * i), sfc->regbase + SFC_DATA);
+
+ return rockchip_sfc_op_reg(nor, opcode, len, SFC_CMD_DIR_WR);
+}
+
+static inline void rockchip_sfc_setup_transfer(struct spi_nor *nor,
+ loff_t from_to,
+ size_t len, u8 op_type)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ u32 reg;
+ u8 if_type = 0;
+
+ if (op_type == SFC_CMD_DIR_WR)
+ reg = (nor->program_opcode & SFC_CMD_IDX_MASK) <<
+ SFC_CMD_IDX_SHIFT;
+ else
+ reg = (nor->read_opcode & SFC_CMD_IDX_MASK) <<
+ SFC_CMD_IDX_SHIFT;
+
+ reg |= op_type << SFC_CMD_DIR_SHIFT;
+ reg |= (nor->addr_width == 4) ?
+ SFC_CMD_ADDR_32BITS : SFC_CMD_ADDR_24BITS;
+
+ if_type = get_if_type(nor->flash_read);
+ writel_relaxed((if_type << SFC_CTRL_DATA_BITS_SHIFT) |
+ (if_type << SFC_CTRL_ADDR_BITS_SHIFT) |
+ (if_type << SFC_CTRL_CMD_BITS_SHIFT) |
+ (sfc->negative_edge ? SFC_CTRL_PHASE_SEL_NEGETIVE : 0),
+ sfc->regbase + SFC_CTRL);
+
+ reg |= (priv->cs & SFC_CMD_CS_MASK) << SFC_CMD_CS_SHIFT;
+ reg |= (len & SFC_CMD_TRAN_BYTES_MASK) << SFC_CMD_TRAN_BYTES_SHIFT;
+
+ if (op_type == SFC_CMD_DIR_RD)
+ reg |= SFC_CMD_DUMMY(nor->read_dummy);
+
+ /* Should minus one as 0x0 means 1 bit flash address */
+ writel_relaxed(nor->addr_width * 8 - 1, sfc->regbase + SFC_ABIT);
+ writel_relaxed(reg, sfc->regbase + SFC_CMD);
+ writel_relaxed(from_to, sfc->regbase + SFC_ADDR);
+}
+
+static int rockchip_sfc_dma_transfer(struct spi_nor *nor, loff_t from_to,
+ dma_addr_t dma_buf, size_t len, u8 op_type)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ u32 reg;
+ int err = 0;
+
+ init_completion(&sfc->cp);
+
+ writel_relaxed(SFC_ICLR_RX_FULL | SFC_ICLR_RX_UFLOW |
+ SFC_ICLR_TX_OFLOW | SFC_ICLR_TX_EMPTY |
+ SFC_ICLR_TRAN_FINISH | SFC_ICLR_BUS_ERR |
+ SFC_ICLR_NSPI_ERR | SFC_ICLR_DMA,
+ sfc->regbase + SFC_ICLR);
+
+ /* Enable transfer complete interrupt */
+ reg = readl_relaxed(sfc->regbase + SFC_IMR);
+ reg &= ~SFC_IMR_TRAN_FINISH;
+ writel_relaxed(reg, sfc->regbase + SFC_IMR);
+
+ rockchip_sfc_setup_transfer(nor, from_to, len, op_type);
+ writel_relaxed(dma_buf, sfc->regbase + SFC_DMA_ADDR);
+
+ /*
+ * Start dma but note that the sfc->dma_buffer is derived from
+ * dmam_alloc_coherent so we don't actually need any sync operations
+ * for coherent dma memory.
+ */
+ writel_relaxed(0x1, sfc->regbase + SFC_DMA_TRIGGER);
+
+ /* Wait for the interrupt. */
+ if (!wait_for_completion_timeout(&sfc->cp, msecs_to_jiffies(2000))) {
+ dev_err(sfc->dev, "DMA wait for transfer finish timeout\n");
+ err = -ETIMEDOUT;
+ }
+
+ /* Disable transfer finish interrupt */
+ reg = readl_relaxed(sfc->regbase + SFC_IMR);
+ reg |= SFC_IMR_TRAN_FINISH;
+ writel_relaxed(reg, sfc->regbase + SFC_IMR);
+
+ if (err)
+ return err;
+
+ return rockchip_sfc_wait_op_finish(sfc);
+}
+
+static inline int rockchip_sfc_pio_write(struct rockchip_sfc *sfc, u_char *buf,
+ size_t len)
+{
+ u32 dwords, tx_wl, count, i;
+ unsigned long timeout;
+ int ret = 0;
+ u32 *tbuf = (u32 *)buf;
+
+ /*
+ * Align bytes to dwords, although we will write some extra
+ * bytes to fifo but the transfer bytes number in SFC_CMD
+ * register will make sure we just send out the expected
+ * byte numbers and the extra bytes will be clean before
+ * setting up the next transfer. We should always round up
+ * to align to DWORD as the ahb for Rockchip Socs won't
+ * support non-aligned-to-DWORD transfer.
+ */
+ dwords = (len + 3) >> 2;
+
+ while (dwords) {
+ tx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
+ SFC_FSR_TX_WATER_LVL_SHIFT) &
+ SFC_FSR_TX_WATER_LVL_MASK;
+
+ if (tx_wl > 0) {
+ count = min_t(u32, dwords, tx_wl);
+ for (i = 0; i < count; i++) {
+ writel_relaxed(*tbuf++,
+ sfc->regbase + SFC_DATA);
+ dwords--;
+ }
+
+ if (dwords == 0)
+ break;
+ timeout = 0;
+ } else {
+ mdelay(1);
+ if (timeout++ > SFC_MAX_IDLE_RETRY) {
+ ret = -ETIMEDOUT;
+ break;
+ }
+ }
+ }
+
+ if (ret)
+ return ret;
+ else
+ return rockchip_sfc_wait_op_finish(sfc);
+}
+
+static inline int rockchip_sfc_pio_read(struct rockchip_sfc *sfc, u_char *buf,
+ size_t len)
+{
+ u32 dwords, rx_wl, count, i, tmp;
+ unsigned long timeout;
+ int ret = 0;
+ u32 *tbuf = (u32 *)buf;
+ u_char *tbuf2;
+
+ /*
+ * Align bytes to dwords, and get the remained bytes.
+ * We should always round down to DWORD as the ahb for
+ * Rockchip Socs won't support non-aligned-to-DWORD transfer.
+ * So please don't use any APIs that will finally use non-aligned
+ * read, for instance, memcpy_fromio or ioread32_rep etc.
+ */
+ dwords = len >> 2;
+ len = len & 0x3;
+
+ while (dwords) {
+ rx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
+ SFC_FSR_RX_WATER_LVL_SHIFT) &
+ SFC_FSR_RX_WATER_LVL_MASK;
+
+ if (rx_wl > 0) {
+ count = min_t(u32, dwords, rx_wl);
+ for (i = 0; i < count; i++) {
+ *tbuf++ = readl_relaxed(sfc->regbase +
+ SFC_DATA);
+ dwords--;
+ }
+
+ if (dwords == 0)
+ break;
+ timeout = 0;
+ } else {
+ mdelay(1);
+ if (timeout++ > SFC_MAX_IDLE_RETRY) {
+ ret = -ETIMEDOUT;
+ break;
+ }
+ }
+ }
+
+ if (ret)
+ return ret;
+
+ /* Read the remained bytes */
+ timeout = 0;
+ tbuf2 = (u_char *)tbuf;
+ while (len) {
+ rx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
+ SFC_FSR_RX_WATER_LVL_SHIFT) &
+ SFC_FSR_RX_WATER_LVL_MASK;
+ if (rx_wl > 0) {
+ tmp = readl_relaxed(sfc->regbase + SFC_DATA);
+ for (i = 0; i < len; i++)
+ tbuf2[i] = (u8)((tmp >> (i * 8)) & 0xff);
+ goto done;
+ } else {
+ mdelay(1);
+ if (timeout++ > SFC_MAX_IDLE_RETRY) {
+ ret = -ETIMEDOUT;
+ break;
+ }
+ }
+ }
+done:
+ if (ret)
+ return ret;
+ else
+ return rockchip_sfc_wait_op_finish(sfc);
+}
+
+static int rockchip_sfc_pio_transfer(struct spi_nor *nor, loff_t from_to,
+ size_t len, u_char *buf, u8 op_type)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+
+ rockchip_sfc_setup_transfer(nor, from_to, len, op_type);
+
+ if (op_type == SFC_CMD_DIR_WR)
+ return rockchip_sfc_pio_write(sfc, buf, len);
+ else
+ return rockchip_sfc_pio_read(sfc, buf, len);
+}
+
+static ssize_t rockchip_sfc_read(struct spi_nor *nor, loff_t from, size_t len,
+ u_char *read_buf)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ size_t offset;
+ int ret;
+ dma_addr_t dma_addr = 0;
+
+ if (!sfc->use_dma)
+ goto no_dma;
+
+ for (offset = 0; offset < len; offset += SFC_DMA_MAX_LEN) {
+ size_t trans = min_t(size_t, SFC_DMA_MAX_LEN, len - offset);
+
+ dma_addr = dma_map_single(NULL, (void *)read_buf,
+ trans, DMA_FROM_DEVICE);
+ if (dma_mapping_error(sfc->dev, dma_addr))
+ dma_addr = 0;
+
+ /* Fail to map dma, use pre-allocated area instead */
+ ret = rockchip_sfc_dma_transfer(nor, from + offset,
+ dma_addr ? dma_addr :
+ sfc->dma_buffer,
+ trans, SFC_CMD_DIR_RD);
+
+ if (dma_addr) {
+ /* Invalidate the read data from dma_addr */
+ dma_sync_single_for_cpu(sfc->dev, dma_addr,
+ trans, DMA_FROM_DEVICE);
+ dma_unmap_single(NULL, dma_addr,
+ trans, DMA_FROM_DEVICE);
+ }
+
+ if (ret) {
+ dev_warn(nor->dev, "DMA read timeout\n");
+ return ret;
+ }
+ if (!dma_addr)
+ memcpy(read_buf + offset, sfc->buffer, trans);
+ }
+
+ return len;
+
+no_dma:
+ ret = rockchip_sfc_pio_transfer(nor, from, len,
+ read_buf, SFC_CMD_DIR_RD);
+ if (ret) {
+ dev_warn(nor->dev, "PIO read timeout\n");
+ return ret;
+ }
+ return len;
+}
+
+static ssize_t rockchip_sfc_write(struct spi_nor *nor, loff_t to,
+ size_t len, const u_char *write_buf)
+{
+ struct rockchip_sfc_chip_priv *priv = nor->priv;
+ struct rockchip_sfc *sfc = priv->sfc;
+ size_t offset;
+ int ret;
+ dma_addr_t dma_addr = 0;
+
+ if (!sfc->use_dma)
+ goto no_dma;
+
+ for (offset = 0; offset < len; offset += SFC_DMA_MAX_LEN) {
+ size_t trans = min_t(size_t, SFC_DMA_MAX_LEN, len - offset);
+
+ dma_addr = dma_map_single(NULL, (void *)write_buf,
+ trans, DMA_TO_DEVICE);
+ if (dma_mapping_error(sfc->dev, dma_addr)) {
+ dma_addr = 0;
+ memcpy(sfc->buffer, write_buf + offset, trans);
+ } else {
+ /* Flush the write data to dma memory */
+ dma_sync_single_for_device(sfc->dev, dma_addr,
+ trans, DMA_TO_DEVICE);
+ }
+
+ /* Fail to map dma, use pre-allocated area instead */
+ ret = rockchip_sfc_dma_transfer(nor, to + offset,
+ dma_addr ? dma_addr :
+ sfc->dma_buffer,
+ trans, SFC_CMD_DIR_WR);
+ if (dma_addr)
+ dma_unmap_single(NULL, dma_addr,
+ trans, DMA_TO_DEVICE);
+ if (ret) {
+ dev_warn(nor->dev, "DMA write timeout\n");
+ return ret;
+ }
+ }
+
+ return len;
+no_dma:
+ ret = rockchip_sfc_pio_transfer(nor, to, len,
+ (u_char *)write_buf, SFC_CMD_DIR_WR);
+ if (ret) {
+ dev_warn(nor->dev, "PIO write timeout\n");
+ return ret;
+ }
+ return len;
+}
+
+/**
+ * Get spi flash device information and register it as a mtd device.
+ */
+static int rockchip_sfc_register(struct device_node *np,
+ struct rockchip_sfc *sfc)
+{
+ struct device *dev = sfc->dev;
+ struct mtd_info *mtd;
+ int ret;
+
+ sfc->flash[sfc->num_chip].nor.dev = dev;
+ spi_nor_set_flash_node(&(sfc->flash[sfc->num_chip].nor), np);
+
+ ret = of_property_read_u8(np, "reg", &sfc->flash[sfc->num_chip].cs);
+ if (ret) {
+ dev_err(dev, "No reg property for %s\n",
+ np->full_name);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "spi-max-frequency",
+ &sfc->flash[sfc->num_chip].clk_rate);
+ if (ret) {
+ dev_err(dev, "No spi-max-frequency property for %s\n",
+ np->full_name);
+ return ret;
+ }
+
+ sfc->flash[sfc->num_chip].sfc = sfc;
+ sfc->flash[sfc->num_chip].nor.priv = &(sfc->flash[sfc->num_chip]);
+
+ sfc->flash[sfc->num_chip].nor.prepare = rockchip_sfc_prep;
+ sfc->flash[sfc->num_chip].nor.unprepare = rockchip_sfc_unprep;
+ sfc->flash[sfc->num_chip].nor.read_reg = rockchip_sfc_read_reg;
+ sfc->flash[sfc->num_chip].nor.write_reg = rockchip_sfc_write_reg;
+ sfc->flash[sfc->num_chip].nor.read = rockchip_sfc_read;
+ sfc->flash[sfc->num_chip].nor.write = rockchip_sfc_write;
+ sfc->flash[sfc->num_chip].nor.erase = NULL;
+ ret = spi_nor_scan(&(sfc->flash[sfc->num_chip].nor),
+ NULL, SPI_NOR_QUAD);
+ if (ret)
+ return ret;
+
+ mtd = &(sfc->flash[sfc->num_chip].nor.mtd);
+ mtd->name = np->name;
+ ret = mtd_device_register(mtd, NULL, 0);
+ if (ret)
+ return ret;
+
+ sfc->num_chip++;
+ return 0;
+}
+
+static void rockchip_sfc_unregister_all(struct rockchip_sfc *sfc)
+{
+ int i;
+
+ for (i = 0; i < sfc->num_chip; i++)
+ mtd_device_unregister(&(sfc->flash[sfc->num_chip].nor.mtd));
+}
+
+static int rockchip_sfc_register_all(struct rockchip_sfc *sfc)
+{
+ struct device *dev = sfc->dev;
+ struct device_node *np;
+ int ret;
+
+ for_each_available_child_of_node(dev->of_node, np) {
+ ret = rockchip_sfc_register(np, sfc);
+ if (ret)
+ goto fail;
+
+ if (sfc->num_chip == SFC_MAX_CHIPSELECT_NUM) {
+ dev_warn(dev, "Exceeds the max cs limitation\n");
+ break;
+ }
+ }
+
+ return 0;
+
+fail:
+ dev_err(dev, "Failed to register all chips\n");
+ /* Unregister all the _registered_ nor flash */
+ rockchip_sfc_unregister_all(sfc);
+ return ret;
+}
+
+static irqreturn_t rockchip_sfc_irq_handler(int irq, void *dev_id)
+{
+ struct rockchip_sfc *sfc = dev_id;
+ u32 reg;
+
+ reg = readl_relaxed(sfc->regbase + SFC_RISR);
+ dev_dbg(sfc->dev, "Get irq: 0x%x\n", reg);
+
+ /* Clear interrupt */
+ writel_relaxed(reg, sfc->regbase + SFC_ICLR);
+
+ if (reg & SFC_RISR_TRAN_FINISH)
+ complete(&sfc->cp);
+
+ return IRQ_HANDLED;
+}
+
+static int rockchip_sfc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct rockchip_sfc *sfc;
+ int ret;
+
+ sfc = devm_kzalloc(dev, sizeof(*sfc), GFP_KERNEL);
+ if (!sfc)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, sfc);
+ sfc->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sfc->regbase = devm_ioremap_resource(dev, res);
+ if (IS_ERR(sfc->regbase))
+ return PTR_ERR(sfc->regbase);
+
+ sfc->clk = devm_clk_get(&pdev->dev, "sfc");
+ if (IS_ERR(sfc->clk)) {
+ dev_err(&pdev->dev, "Failed to get sfc interface clk\n");
+ return PTR_ERR(sfc->clk);
+ }
+
+ sfc->hclk = devm_clk_get(&pdev->dev, "hsfc");
+ if (IS_ERR(sfc->hclk)) {
+ dev_err(&pdev->dev, "Failed to get sfc ahp clk\n");
+ return PTR_ERR(sfc->hclk);
+ }
+
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_warn(dev, "Unable to set dma mask\n");
+ return ret;
+ }
+
+ sfc->buffer = dmam_alloc_coherent(dev, SFC_DMA_MAX_LEN,
+ &sfc->dma_buffer, GFP_KERNEL);
+ if (!sfc->buffer)
+ return -ENOMEM;
+
+ mutex_init(&sfc->lock);
+
+ ret = clk_prepare_enable(sfc->hclk);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to enable hclk\n");
+ goto err_hclk;
+ }
+
+ ret = clk_prepare_enable(sfc->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to enable clk\n");
+ goto err_clk;
+ }
+
+ sfc->use_dma = !of_property_read_bool(sfc->dev->of_node,
+ "rockchip,sfc-no-dma");
+
+ sfc->negative_edge = of_device_is_compatible(sfc->dev->of_node,
+ "rockchip,rk1108-sfc");
+ /* Find the irq */
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0) {
+ dev_err(dev, "Failed to get the irq\n");
+ goto err_irq;
+ }
+
+ ret = devm_request_irq(dev, ret, rockchip_sfc_irq_handler,
+ 0, pdev->name, sfc);
+ if (ret) {
+ dev_err(dev, "Failed to request irq\n");
+ goto err_irq;
+ }
+
+ sfc->num_chip = 0;
+ ret = rockchip_sfc_init(sfc);
+ if (ret)
+ goto err_irq;
+#if 1
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+ pm_runtime_use_autosuspend(&pdev->dev);
+#endif
+ ret = rockchip_sfc_register_all(sfc);
+ if (ret)
+ goto err_register;
+
+ clk_disable_unprepare(sfc->clk);
+ pm_runtime_put_autosuspend(&pdev->dev);
+ return 0;
+
+err_register:
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+err_irq:
+ clk_disable_unprepare(sfc->clk);
+err_clk:
+ clk_disable_unprepare(sfc->hclk);
+err_hclk:
+ mutex_destroy(&sfc->lock);
+ return ret;
+}
+
+static int rockchip_sfc_remove(struct platform_device *pdev)
+{
+ struct rockchip_sfc *sfc = platform_get_drvdata(pdev);
+
+ pm_runtime_get_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+
+ rockchip_sfc_unregister_all(sfc);
+ mutex_destroy(&sfc->lock);
+ clk_disable_unprepare(sfc->clk);
+ clk_disable_unprepare(sfc->hclk);
+ return 0;
+}
+
+#ifdef CONFIG_PM
+int rockchip_sfc_runtime_suspend(struct device *dev)
+{
+ struct rockchip_sfc *sfc = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(sfc->hclk);
+ return 0;
+}
+
+int rockchip_sfc_runtime_resume(struct device *dev)
+{
+ struct rockchip_sfc *sfc = dev_get_drvdata(dev);
+
+ clk_prepare_enable(sfc->hclk);
+ return 0;
+}
+#endif /* CONFIG_PM */
+
+static const struct of_device_id rockchip_sfc_dt_ids[] = {
+ { .compatible = "rockchip,sfc"},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rockchip_sfc_dt_ids);
+
+static const struct dev_pm_ops rockchip_sfc_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(rockchip_sfc_runtime_suspend,
+ rockchip_sfc_runtime_resume, NULL)
+};
+
+static struct platform_driver rockchip_sfc_driver = {
+ .driver = {
+ .name = "rockchip-sfc",
+ .of_match_table = rockchip_sfc_dt_ids,
+ .pm = &rockchip_sfc_dev_pm_ops,
+ },
+ .probe = rockchip_sfc_probe,
+ .remove = rockchip_sfc_remove,
+};
+module_platform_driver(rockchip_sfc_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Rockchip Serial Flash Controller Driver");
+MODULE_AUTHOR("Shawn Lin");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/2] mtd: spi-nor: Bindings for Rockchip serial flash controller
From: Shawn Lin @ 2016-11-18 2:59 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Marek Vasut, Cyrille Pitchen, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner,
Shawn Lin
In-Reply-To: <1479437945-27918-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add binding document for the Rockchip serial flash controller.
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v2: None
.../devicetree/bindings/mtd/rockchip-sfc.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt b/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
new file mode 100644
index 0000000..28430ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
@@ -0,0 +1,31 @@
+Rockchip Serial Flash Controller
+
+Required properties:
+- compatible : Should be
+ "rockchip,rk1108-sfc", "rockchip,sfc" for ROCKCHIP RK1108.
+- address-cells : Should be 1.
+- size-cells : Should be 0.
+- clocks: Must contain two entries for each entry in clock-names.
+- clock-names: Shall be "sfc" for the transfer-clock, and "hsfc" for
+ the peripheral clock.
+- interrupts : Should contain the interrupt for the device.
+- reg: Physical base address of the controller and length of memory mapped.
+
+Optional properties:
+- rockchip,sfc-no-dma: Indicate the controller doesn't support dma transfer.
+
+Example:
+nor_flash: sfc@301c0000 {
+ compatible = "rockchip,rk1108-sfc", "rockchip,sfc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
+ clock-names = "sfc", "hsfc";
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x301c0000 0x1000>;
+ spi-nor@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <12000000>;
+ reg = <0>;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] Add rockchip serial flash controller support
From: Shawn Lin @ 2016-11-18 2:59 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Marek Vasut, Cyrille Pitchen, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner,
Shawn Lin
This pathset is gonna support serial flash controller
, namely SFC, found on Rockchip RK1108 platform.
Feature:
(1) Support x1, x2, x4 data bits mode
(2) Support up to 4 chip select
(3) Support two independent clock domain: AHB clock and SPI clock
(4) Support DMA master up to 16KB/transfer
Test environment:
This patchset is testing on RK1108 evb boards with Winboud flash
(w25q256) and working find with PIO or DMA mode.
How-to:
Any rockchip guys who are interested in testing it could refer to
the following steps:
(1) enable CONFIG_MTD_M25P80
(2) enable CONFIG_SPI_ROCKCHIP_SFC
(3) enable CONFIG_MTD_CMDLINE_PARTS
(4) enable CONFIG_SQUASHFS
(4) CONFIG_CMDLINE="root=/dev/mtdblock2
mtdparts=spi-nor:256k@0(loader)ro,8m(kernel)ro,7m(rootfs),-(freedisk)"
Of course, you should check the partition layout if you modify it. Also
you could pass it from your loader to the kernel's cmdline.
(5) Add dts support:
nor_flash: sfc@301c0000 {
compatible = "rockchip,rk1108-sfc", "rockchip,sfc";
#address-cells = <1>;
#size-cells = <0>;
clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
clock-names = "sfc", "hsfc";
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
reg = <0x301c0000 0x1000>;
/* If you want to use PIO mode, activate this */
#rockchip,sfc-no-dma;
spi-nor@0 {
compatible = "jedec,spi-nor";
spi-max-frequency = <12000000>;
reg = <0>;
}
};
please make sure your DT's mdtid matchs what you assgin to the
mdtparts(cmdline), namely they are both *spi-nor* here.
With enabling DBG for cmdlinepart.c, you could get following log and
boot kernel and rootfs successfully.
[ 0.481420] rockchip-sfc 301c0000.sfc: w25q256 (32768 Kbytes)
[ 0.481962] DEBUG-CMDLINE-PART: parsing
<256k@0(loader)ro,8m(kernel)ro,7m(rootfs)ro,-(freedisk)>
[ 0.482897] DEBUG-CMDLINE-PART: partition 3: name
<freedisk>, offset ffffffffffffffff, size ffffffffffffffff, mask flags 0
[ 0.484021] DEBUG-CMDLINE-PART: partition 2: name
<rootfs>, offset ffffffffffffffff, size 700000, mask flags 400
[ 0.485066] DEBUG-CMDLINE-PART: partition 1: name
<kernel>, offset ffffffffffffffff, size 800000, mask flags 400
[ 0.486108] DEBUG-CMDLINE-PART: partition 0: name
<loader>, offset 0, size 40000, mask flags 400
[ 0.487152] DEBUG-CMDLINE-PART: mtdid=<spi-nor> num_parts=<4>
[ 0.487827] 4 cmdlinepart partitions found on MTD device spi-nor
[ 0.488370] Creating 4 MTD partitions on "spi-nor":
[ 0.488826] 0x000000000000-0x000000040000 : "loader"
[ 0.492340] 0x000000040000-0x000000840000 : "kernel"
[ 0.495679] 0x000000840000-0x000000f40000 : "rootfs"
[ 0.499241] 0x000000f40000-0x000002000000 : "freedisk"
[root@arm-linux]#
[root@arm-linux]#mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs
(rw,relatime,size=26124k,nr_inodes=6531,mode=755)
proc on /proc type proc (rw,relatime)
none on /tmp type ramfs (rw,relatime)
none on /var type ramfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debug on /sys/kernel/debug type debugfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
Changes in v2:
- fix typos
- add some comment for buffer and others operations
- rename SFC_MAX_CHIP_NUM to MAX_CHIPSELECT_NUM
- use u8 for cs
- return -EINVAL for default case of get_if_type
- use readl_poll_*() to check timeout cases
- simplify and clarify some condition checks
- rework the bitshifts to simplify the code
- define SFC_CMD_DUMMY(x)
- fix ummap for dma read path and finish all the
cache maintenance.
- rename to rockchip_sfc_chip_priv and embed struct spi_nor
in it.
- add MODULE_AUTHOR
- add runtime PM and general PM support.
- Thanks for Marek's comments. Link:
http://lists.infradead.org/pipermail/linux-mtd/2016-November/070321.html
Shawn Lin (2):
mtd: spi-nor: Bindings for Rockchip serial flash controller
mtd: spi-nor: add rockchip serial flash controller driver
.../devicetree/bindings/mtd/rockchip-sfc.txt | 31 +
MAINTAINERS | 8 +
drivers/mtd/spi-nor/Kconfig | 7 +
drivers/mtd/spi-nor/Makefile | 1 +
drivers/mtd/spi-nor/rockchip-sfc.c | 971 +++++++++++++++++++++
5 files changed, 1018 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
create mode 100644 drivers/mtd/spi-nor/rockchip-sfc.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Nishanth Menon @ 2016-11-18 2:56 UTC (permalink / raw)
To: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Julien,
Tomi Valkeinen
In-Reply-To: <20161118024436.13447-6-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/17/2016 08:44 PM, Robert Nelson wrote:
again.. a short commit message at least please? :)
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> 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?
> + 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,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 3/6] Documentation: dt: add bindings for ti bb2d
From: Nishanth Menon @ 2016-11-18 2:54 UTC (permalink / raw)
To: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gowtham Tammana, Tomi Valkeinen
In-Reply-To: <20161118024436.13447-3-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/17/2016 08:44 PM, Robert Nelson wrote:
> From: Gowtham Tammana <g-tammana-l0cyMroinI0@public.gmane.org>
>
> Add documentation for device tree bindings description for
> 2D GPU blitter module present in Texas Instruments family of SoCs.
>
> Signed-off-by: Gowtham Tammana <g-tammana-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> ---
Might want to point at the source of the patch -> just for the record,
this came from TI vendor kernel..
> Documentation/devicetree/bindings/gpu/ti-bb2d.txt | 27 +++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/ti-bb2d.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/ti-bb2d.txt b/Documentation/devicetree/bindings/gpu/ti-bb2d.txt
> new file mode 100644
> index 0000000..af47488
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/ti-bb2d.txt
> @@ -0,0 +1,27 @@
> +* Texas Instruments BB2D blitter module
> +
> +This binding describes the 2D BitBlit (BB2D) graphics accelerator
> +subsystem based on the GC320 core from Vivante Corporation available
> +in Texas Instruments SoCs.
> +
> +Required properties:
> + - compatible: value should take the following format:
> + "ti,<soc>-bb2d", "vivante,<gpuversion>"
> + accepted values:
> + (a) "ti,dra7-bb2d", "vivante,gc320" for TI DRA7xx / AM57x
> +
> + - reg : base address and length of BB2D IP registers
> + - interrupts : BB2D interrupt line number
> + - ti,hwmods : name of the hwmod associated with BB2D module
> + - clocks : handle to BB2D functional clock
> + - clock-names : fclk
> +
> +Example for DRA7x SoC:
> + bb2d: bb2d@59000000 {
> + compatible = "ti,dra7-bb2d", "vivante,gc320";
> + reg = <0x59000000 0x0700>;
> + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
> + ti,hwmods = "bb2d";
> + clocks = <&dpll_core_h24x2_ck>;
> + clock-names = "fclk";
> + };
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 1/6] drm/etnaviv: add binding for the gc320 found in ti socs
From: Nishanth Menon @ 2016-11-18 2:53 UTC (permalink / raw)
To: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Julien,
Christian Gmeiner, Russell King, Lucas Stach, Tomi Valkeinen
In-Reply-To: <20161118024436.13447-1-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/17/2016 08:44 PM, Robert Nelson wrote:
Could we write at least a oneline commit message? :)
Might want to state that since the TI gpu systems are a mixed bunch
and certain SoCs may have more than 1 GPU integrated, we indicate
clearly the rev here?
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> CC: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> index ed5e0a7..9fa259d 100644
> --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> @@ -8,6 +8,7 @@ Required properties:
> - compatible: Should be one of
> "fsl,imx-gpu-subsystem"
> "marvell,dove-gpu-subsystem"
> + "ti,gc320-gpu-subsystem"
> - cores: Should contain a list of phandles pointing to Vivante GPU devices
>
> example:
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a6799b0..ce51270 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
> static const struct of_device_id dt_match[] = {
> { .compatible = "fsl,imx-gpu-subsystem" },
> { .compatible = "marvell,dove-gpu-subsystem" },
> + { .compatible = "ti,gc320-gpu-subsystem" },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 2/6] drm/etnaviv: allow building etnaviv on omap devices
From: Nishanth Menon @ 2016-11-18 2:52 UTC (permalink / raw)
To: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Christian Gmeiner, Russell King, Lucas Stach
In-Reply-To: <20161118024436.13447-2-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/17/2016 08:44 PM, Robert Nelson wrote:
Could we write at least a oneline commit message? :)
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> CC: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 2cde7a5..b776f41 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> - depends on ARCH_MXC || ARCH_DOVE
> + depends on ARCH_MXC || ARCH_DOVE || ARCH_OMAP2PLUS
> select SHMEM
> select TMPFS
> select IOMMU_API
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 1/6] drm/etnaviv: add binding for the gc320 found in ti socs
From: Robert Nelson @ 2016-11-18 2:51 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Robert Nelson, Julien, Christian Gmeiner, Russell King,
Lucas Stach, Nishanth Menon, Tomi Valkeinen
In-Reply-To: <20161118024436.13447-1-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sorry, messed up the cover-header, patches 3 & 4 in this series where
cherry picked form ti's v4.4.x tree:
http://git.ti.com/cgit/cgit.cgi/ti-linux-kernel/ti-linux-kernel.git/commit/arch/arm/boot/dts/dra7.dtsi?h=ti-linux-4.4.y&id=8067f5a5619ce45657d3729ab3adb9e5b1294f0d
http://git.ti.com/cgit/cgit.cgi/ti-linux-kernel/ti-linux-kernel.git/commit/Documentation/devicetree/bindings/gpu/ti-bb2d.txt?h=ti-linux-4.4.y&id=ddadad0828f8e5ad7e89b11dd243249228ff2997
"ti,gc320-gpu-subsystem" seems like the best middle ground option, the
gc320 is found on one omap4770, omap5, dra7..
"ti,omap-gpu-subsystem" might clash with the naming for the sgx544 3D
core found on these devices, then some day, ti could use
"ti,sgx<num>-gpu-subsystem"
For BeagleBoard.org & BeagleBoard-x15 users we have this working in
the updated images.
For people looking to build the packages, i have it up here:
https://gist.github.com/RobertCNelson/fc6d07157b0fcc13b9c28c5832fdc74b
Regards,
On Thu, Nov 17, 2016 at 8:44 PM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> CC: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> index ed5e0a7..9fa259d 100644
> --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> @@ -8,6 +8,7 @@ Required properties:
> - compatible: Should be one of
> "fsl,imx-gpu-subsystem"
> "marvell,dove-gpu-subsystem"
> + "ti,gc320-gpu-subsystem"
> - cores: Should contain a list of phandles pointing to Vivante GPU devices
>
> example:
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a6799b0..ce51270 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
> static const struct of_device_id dt_match[] = {
> { .compatible = "fsl,imx-gpu-subsystem" },
> { .compatible = "marvell,dove-gpu-subsystem" },
> + { .compatible = "ti,gc320-gpu-subsystem" },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
> --
> 2.10.2
>
--
Robert Nelson
https://rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Robert Nelson @ 2016-11-18 2:44 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Robert Nelson,
Julien, Nishanth Menon, Tomi Valkeinen
In-Reply-To: <20161118024436.13447-1-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
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 {
+ 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>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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