Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Brian Masney @ 2019-09-16 12:02 UTC (permalink / raw)
  To: Enric Balletbo i Serra
  Cc: mark.rutland, devicetree, jernej.skrabec, dri-devel, narmstrong,
	airlied, linux-arm-msm, linus.walleij, jonas, linux-kernel,
	robh+dt, bjorn.andersson, Andrzej Hajda, robdclark, agross,
	Laurent Pinchart, daniel, freedreno, sean, linux-arm-kernel
In-Reply-To: <3ec4f0bc-f3c5-aebf-8213-bc4f80915902@collabora.com>

On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
> Hi,
> 
> On 16/9/19 12:49, Laurent Pinchart wrote:
> > Hi Brian,
> > 
> > On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
> >> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> >>> On 15.08.2019 02:48, Brian Masney wrote:
> >>>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> >>>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> >>>> error. The downstream MSM kernel sources [1] shows that the proper value
> >>>> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> >>>> probing to succeed.
> >>>>
> >>>> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
> >>>>
> >>>> Signed-off-by: Brian Masney <masneyb@onstation.org>
> >>>> ---
> >>>>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> index 25e063bcecbc..bc511fc605c9 100644
> >>>> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> @@ -6,7 +6,7 @@
> >>>>  #ifndef __ANX78xx_H
> >>>>  #define __ANX78xx_H
> >>>>  
> >>>> -#define TX_P0				0x70
> >>>> +#define TX_P0				0x78
> >>>
> >>>
> >>> This bothers me little. There are no upstream users, grepping android
> >>> sources suggests that both values can be used [1][2]  (grep for "#define
> >>> TX_P0"), moreover there is code suggesting both values can be valid [3].
> >>>
> >>> Could you verify datasheet which i2c slave addresses are valid for this
> >>> chip, if both I guess this patch should be reworked.
> >>>
> >>>
> >>> [1]:
> >>> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
> >>>
> >>> [2]:
> >>> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
> >>>
> >>> [3]:
> >>> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
> >>
> >> This address is 0x78 on my Nexus 5. Given [3] above it looks like we
> >> need to support both addresses. What do you think about moving these
> >> addresses into device tree?
> > 
> > Assuming that the device supports different addresses (I can't validate
> > that as I don't have access to the datasheet), and different addresses
> > need to be used on different systems, then the address to be used needs
> > to be provided by the firmware (DT in this case). Two options are
> > possible, either specifying the address explicitly in the device's DT
> > node, or specifying free addresses (in the form of a white list or black
> > list) and allocating an address from that pool. The latter has been
> > discussed in a BoF at the Linux Plumbers Conference last week,
> > https://linuxplumbersconf.org/event/4/contributions/542/.
> > 
> >> The downstream and upstream kernel sources divide these addresses by two
> >> to get the i2c address. Here's the code in upstream:
> >>
> >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
> >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41
> >>
> >> I'm not sure why the actual i2c address isn't used in this code.
> > 
> 
> The ANX7802/12/14/16 has a slave I2C bus that provides the interface to access
> or control the chip from the AP. The I2C slave addresses used to control the
> ANX7802/12/14/16 are 70h, 72h, 7Ah, 7Eh and 80h. Every address allows you to
> access to different registers of the chip and AFAICS is not configurable.
> 
> I don't think these addresses should be configured via DT but for the driver itself.
> 
> My wild guess is that the ANX7808 has different addresses, but I don't have the
> datasheet of this version.

I'm able to communicate with the 7808 on my Nexus 5 using the 0x78
address. Given that the addresses appear to be fixed per model, maybe it
makes sense to drop the address #defines and add the addresses to the
data pointer in the driver's of_match_table like so:

static const struct of_device_id anx78xx_match_table[] = {
        { .compatible = "analogix,anx7808", .data = PTR_TO_7808_ADDRS },
        { .compatible = "analogix,anx7812", .data = PTR_TO_781X_ADDRS },
        { .compatible = "analogix,anx7814", .data = PTR_TO_781X_ADDRS },
        { .compatible = "analogix,anx7818", .data = PTR_TO_781X_ADDRS },
        { /* sentinel */ },
};

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 00/11] ARM: dts: qcom: msm8974: add support for external display
From: Andrzej Hajda @ 2019-09-16 12:02 UTC (permalink / raw)
  To: Brian Masney
  Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
	linux-kernel, linus.walleij, jonas, agross, dri-devel,
	bjorn.andersson, robdclark, robh+dt, Laurent.pinchart, daniel,
	linux-arm-msm, enric.balletbo, freedreno, sean, linux-arm-kernel
In-Reply-To: <20190916090150.GA349@onstation.org>

On 16.09.2019 11:01, Brian Masney wrote:
> Hi Andrzej,
>
> On Mon, Sep 16, 2019 at 10:13:58AM +0200, Andrzej Hajda wrote:
>> Hi Brian,
>>
>> On 15.08.2019 02:48, Brian Masney wrote:
>>> This patch series begins to add support for the external display over
>>> HDMI that is supported on msm8974 SoCs. I'm testing this series on the
>>> Nexus 5, and I'm able to communicate with the HDMI bridge via the
>>> analogix-anx78xx driver, however the external display is not working
>>> yet.
>>>
>>> When I plug in the HDMI cable, the monitor detects that a device is
>>> hooked up, but nothing is shown on the external monitor. The hot plug
>>> detect GPIO (hpd-gpios) on the analogix-anx78xx bridge and MSM HDMI
>>> drivers do not change state when the slimport adapter or HDMI cable is
>>> plugged in or removed. I wonder if a regulator is not enabled somewhere?
>>> I have a comment in patch 10 regarding 'hpd-gdsc-supply' that may
>>> potentially be an issue.
>>>
>>> I'm still digging in on this, however I'd appreciate any feedback if
>>> anyone has time. Most of these patches are ready now, so I marked the
>>> ones that aren't ready with 'PATCH RFC'.
>>>
>>> I'm using an Analogix Semiconductor SP6001 SlimPort Micro-USB to 4K HDMI
>>> Adapter to connect my phone to an external display via a standard HDMI
>>> cable. This works just fine with the downstream MSM kernel using
>>> Android.
>>
>> This patchset risks to be forgotten. To avoid it, at least partially, I
>> can merge patches 1-5, is it OK for you?
> That would be great if you could do that.


I have queued 1-4 to drm-misc-next. 5th patch requires some discussion.


Regards

Andrzej


>
> Thanks,
>
> Brian
>
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
From: Fabrice Gasnier @ 2019-09-16 11:47 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: lars, alexandre.torgue, linux-iio, pmeerw, linux-kernel,
	mcoquelin.stm32, knaack.h, linux-stm32, linux-arm-kernel
In-Reply-To: <20190915110524.2ec1b41d@archlinux>

On 9/15/19 12:05 PM, Jonathan Cameron wrote:
> On Fri, 13 Sep 2019 15:21:30 +0200
> Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> 
>> End of conversion may be handled by using IRQ or DMA. There may be a
>> race when two conversions complete at the same time on several ADCs.
>> EOC can be read as 'set' for several ADCs, with:
>> - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
>>   called in this case.
>> - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
>>   request instead. It's then automatically cleared by DMA read. But the
>>   handler gets called due to status bit is temporarily set (IRQ triggered
>>   by the other ADC).
>> So both EOC status bit in CSR and EOCIE control bit must be checked
>> before invoking the interrupt handler (e.g. call ISR only for
>> IRQ-enabled ADCs).
>>
>> Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
>>
>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> Fix looks fine to me, but I'm not keen on splitting out individual bits from
> register defines.  That's a long term readability nightmare.
> 
> See below,
> 
> Jonathan
> 
>> ---
>>  drivers/iio/adc/stm32-adc-core.c | 43 +++++++++++++++++++++++++++++++++++++---
>>  drivers/iio/adc/stm32-adc-core.h | 13 ++++++++++++
>>  drivers/iio/adc/stm32-adc.c      |  6 ------
>>  3 files changed, 53 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>> index 9b85fef..7297396 100644
>> --- a/drivers/iio/adc/stm32-adc-core.c
>> +++ b/drivers/iio/adc/stm32-adc-core.c
>> @@ -71,6 +71,8 @@
>>   * @eoc1:	adc1 end of conversion flag in @csr
>>   * @eoc2:	adc2 end of conversion flag in @csr
>>   * @eoc3:	adc3 end of conversion flag in @csr
>> + * @ier:	interrupt enable register offset for each adc
>> + * @eocie_msk:	end of conversion interrupt enable mask in @ier
>>   */
>>  struct stm32_adc_common_regs {
>>  	u32 csr;
>> @@ -78,6 +80,8 @@ struct stm32_adc_common_regs {
>>  	u32 eoc1_msk;
>>  	u32 eoc2_msk;
>>  	u32 eoc3_msk;
>> +	u32 ier;
>> +	u32 eocie_msk;
>>  };
>>  
>>  struct stm32_adc_priv;
>> @@ -303,6 +307,8 @@ static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
>>  	.eoc1_msk = STM32F4_EOC1,
>>  	.eoc2_msk = STM32F4_EOC2,
>>  	.eoc3_msk = STM32F4_EOC3,
>> +	.ier = STM32F4_ADC_CR1,
>> +	.eocie_msk = STM32F4_EOCIE,
>>  };
>>  
>>  /* STM32H7 common registers definitions */
>> @@ -311,8 +317,24 @@ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
>>  	.ccr = STM32H7_ADC_CCR,
>>  	.eoc1_msk = STM32H7_EOC_MST,
>>  	.eoc2_msk = STM32H7_EOC_SLV,
>> +	.ier = STM32H7_ADC_IER,
>> +	.eocie_msk = STM32H7_EOCIE,
>>  };
>>  
>> +static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = {
>> +	0, STM32_ADC_OFFSET, STM32_ADC_OFFSET * 2,
>> +};
>> +
>> +static unsigned int stm32_adc_eoc_enabled(struct stm32_adc_priv *priv,
>> +					  unsigned int adc)
>> +{
>> +	u32 ier, offset = stm32_adc_offset[adc];
>> +
>> +	ier = readl_relaxed(priv->common.base + offset + priv->cfg->regs->ier);
>> +
>> +	return ier & priv->cfg->regs->eocie_msk;
>> +}
>> +
>>  /* ADC common interrupt for all instances */
>>  static void stm32_adc_irq_handler(struct irq_desc *desc)
>>  {
>> @@ -323,13 +345,28 @@ static void stm32_adc_irq_handler(struct irq_desc *desc)
>>  	chained_irq_enter(chip, desc);
>>  	status = readl_relaxed(priv->common.base + priv->cfg->regs->csr);
>>  
>> -	if (status & priv->cfg->regs->eoc1_msk)
>> +	/*
>> +	 * End of conversion may be handled by using IRQ or DMA. There may be a
>> +	 * race here when two conversions complete at the same time on several
>> +	 * ADCs. EOC may be read 'set' for several ADCs, with:
>> +	 * - an ADC configured to use DMA (EOC triggers the DMA request, and
>> +	 *   is then automatically cleared by DR read in hardware)
>> +	 * - an ADC configured to use IRQs (EOCIE bit is set. The handler must
>> +	 *   be called in this case)
>> +	 * So both EOC status bit in CSR and EOCIE control bit must be checked
>> +	 * before invoking the interrupt handler (e.g. call ISR only for
>> +	 * IRQ-enabled ADCs).
>> +	 */
>> +	if (status & priv->cfg->regs->eoc1_msk &&
>> +	    stm32_adc_eoc_enabled(priv, 0))
>>  		generic_handle_irq(irq_find_mapping(priv->domain, 0));
>>  
>> -	if (status & priv->cfg->regs->eoc2_msk)
>> +	if (status & priv->cfg->regs->eoc2_msk &&
>> +	    stm32_adc_eoc_enabled(priv, 1))
>>  		generic_handle_irq(irq_find_mapping(priv->domain, 1));
>>  
>> -	if (status & priv->cfg->regs->eoc3_msk)
>> +	if (status & priv->cfg->regs->eoc3_msk &&
>> +	    stm32_adc_eoc_enabled(priv, 2))
>>  		generic_handle_irq(irq_find_mapping(priv->domain, 2));
>>  
>>  	chained_irq_exit(chip, desc);
>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>> index 8af507b..8dc936b 100644
>> --- a/drivers/iio/adc/stm32-adc-core.h
>> +++ b/drivers/iio/adc/stm32-adc-core.h
>> @@ -25,8 +25,21 @@
>>   * --------------------------------------------------------
>>   */
>>  #define STM32_ADC_MAX_ADCS		3
>> +#define STM32_ADC_OFFSET		0x100
>>  #define STM32_ADCX_COMN_OFFSET		0x300
>>  
>> +/* STM32F4 - registers for each ADC instance */
>> +#define STM32F4_ADC_CR1			0x04
>> +
>> +/* STM32F4_ADC_CR1 - bit fields */
>> +#define STM32F4_EOCIE			BIT(5)
>> +
>> +/* STM32H7 - registers for each instance */
>> +#define STM32H7_ADC_IER			0x04
>> +
>> +/* STM32H7_ADC_IER - bit fields */
>> +#define STM32H7_EOCIE			BIT(2)
>> +
>>  /**
>>   * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>>   * @base:		control registers base cpu addr
>> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
>> index 6a7dd08..3c9f456 100644
>> --- a/drivers/iio/adc/stm32-adc.c
>> +++ b/drivers/iio/adc/stm32-adc.c
>> @@ -30,7 +30,6 @@
>>  
>>  /* STM32F4 - Registers for each ADC instance */
>>  #define STM32F4_ADC_SR			0x00
>> -#define STM32F4_ADC_CR1			0x04
>>  #define STM32F4_ADC_CR2			0x08
>>  #define STM32F4_ADC_SMPR1		0x0C
>>  #define STM32F4_ADC_SMPR2		0x10
>> @@ -54,7 +53,6 @@
>>  #define STM32F4_RES_SHIFT		24
>>  #define STM32F4_RES_MASK		GENMASK(25, 24)
>>  #define STM32F4_SCAN			BIT(8)
>> -#define STM32F4_EOCIE			BIT(5)
> Hmm. This is breaking up the definitions of bits in a single register.
> That is rather nasty from a code readability point of view.  
> 
> I am as keen as the next person on only exposing definitions where
> we need to, but in this case we either need to provide an access path
> to it here, or we need to move the whole block to the header.

Hi Jonathan,

I think I'll add a precursor patch in v2 to move the whole block to the
header file. This way, the access path is easy (e.g. readl).
I'm only wondering about the Fixes tag... this will probably not be
straight forward to apply the fix on the maintenance releases ?
Or do I need to add it to the precursor patch as well ?

Thanks for reviewing,
Best regards,
Fabrice

> 
>>  
>>  /* STM32F4_ADC_CR2 - bit fields */
>>  #define STM32F4_SWSTART			BIT(30)
>> @@ -69,7 +67,6 @@
>>  
>>  /* STM32H7 - Registers for each ADC instance */
>>  #define STM32H7_ADC_ISR			0x00
>> -#define STM32H7_ADC_IER			0x04
>>  #define STM32H7_ADC_CR			0x08
>>  #define STM32H7_ADC_CFGR		0x0C
>>  #define STM32H7_ADC_SMPR1		0x14
>> @@ -89,9 +86,6 @@
>>  #define STM32H7_EOC			BIT(2)
>>  #define STM32H7_ADRDY			BIT(0)
>>  
>> -/* STM32H7_ADC_IER - bit fields */
>> -#define STM32H7_EOCIE			STM32H7_EOC
>> -
>>  /* STM32H7_ADC_CR - bit fields */
>>  #define STM32H7_ADCAL			BIT(31)
>>  #define STM32H7_ADCALDIF		BIT(30)
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 01/11] kselftest: arm64: add skeleton Makefile
From: Dave Martin @ 2019-09-16 11:41 UTC (permalink / raw)
  To: Amit Kachhap
  Cc: linux-arm-kernel@lists.infradead.org, andreyknvl@google.com,
	shuah@kernel.org, linux-kselftest@vger.kernel.org,
	Cristian Marussi
In-Reply-To: <0a284da1-ff63-dfe9-e479-6ad68865aea1@arm.com>

On Mon, Sep 09, 2019 at 12:42:06PM +0000, Amit Kachhap wrote:
> Hi,
> 
> On 9/5/19 11:27 PM, Cristian Marussi wrote:
> > Hi Amit
> >
> > On 03/09/2019 10:26, Amit Kachhap wrote:
> >>
> >> Hi Cristian,
> >>
> >> On 9/2/19 4:59 PM, Cristian Marussi wrote:
> >>> Add a new arm64-specific empty subsystem amongst TARGETS of KSFT build
> >>> framework; keep these new arm64 KSFT testcases separated into distinct
> >>> subdirs inside tools/testing/selftests/arm64/ depending on the specific
> >>> subsystem targeted.
> >>>
> >>> Add into toplevel arm64 KSFT Makefile a mechanism to guess the effective
> >>> location of Kernel headers as installed by KSFT framework.
> >>>
> >>> Merge with
> >>>
> >>> commit 9ce1263033cd ("selftests, arm64: add a selftest for passing
> >>>                  tagged pointers to kernel")
> >>>
> >>> while moving such KSFT tags tests inside their own subdirectory
> >>> (arm64/tags).
> >>>
> >>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >>> ---
> >>> v4 --> v5
> >>> - rebased on arm64/for-next/core
> >>> - merged this patch with KSFT arm64 tags patch, while moving the latter
> >>>     into its own subdir
> >>> - moved kernel header includes search mechanism from KSFT arm64
> >>>     SIGNAL Makefile
> >> This approach breaks the compilation of individual test cases which need
> >> to export includes individually.
> >>
> >> make -C tools/testing/selftests/arm64/signal
> >>
> >> ../../lib.mk:25: ../../../../scripts/subarch.include: No such file or
> >> directory
> >> Makefile:25: warning: overriding recipe for target 'clean'
> >> ../../lib.mk:123: warning: ignoring old recipe for target 'clean'
> >> make: *** No rule to make target '../../../../scripts/subarch.include'.
> >> Stop.
> >>
> >> However tags test works well,
> >> make -C tools/testing/selftests/arm64/tags
> >>
> >> aarch64-none-linux-gnu-gcc     tags_test.c  -o
> >> /home/amikac01/work/MTE_WORK/linux-server/linux/tools/testing/selftests/arm64/tags/tags_test
> >>
> >>
> >> Thanks,
> >> Amit Daniel
> >>
> >
> > So at the end I think I'll opt for the following in V6 regarding the issue of being able to build specific
> > KSFT arm64 subsystems while properly searching kernel headers (and keeping compatible with the KSFT
> > framework completely):
> >
> > - only arm64 toplevel KSFT Makefile searches for the kernel headers location for all and propagates down the info
> >
> > - you can also now optionally specify which arm64 subsystem to build (to avoid have to build, say, all of signal/
> >    if you are not interested into....a sort of standalone mode without all the burden of the old standalone mode)
> ok.
> >
> > So you can issue:
> >
> > $ make TARGETS=arm64 kselftest
> >
> > or similarly:
> >
> > $ make -C tools/testing/selftests TARGETS=arm64 \
> >                  INSTALL_PATH=<your-installation-path> install
> >
> > or select subsystems:
> >
> > $ make -C tools/testing/selftests TARGETS=arm64 SUBTARGETS="tags signal" \
> >                  INSTALL_PATH=<your-installation-path> install
> This option will be useful as it is better to compile just one subtarget
> in development phase.

Agreed, this seems a reasonable approach.

[...]

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 02/11] kselftest: arm64: add common utils and one testcase
From: Dave Martin @ 2019-09-16 11:40 UTC (permalink / raw)
  To: Cristian Marussi
  Cc: amit.kachhap, andreyknvl, shuah, linux-kselftest,
	linux-arm-kernel
In-Reply-To: <4d13461b-acf6-505f-aefc-05afdec278c7@arm.com>

On Fri, Sep 06, 2019 at 11:26:29AM +0100, Cristian Marussi wrote:
> Hi
> 
> On 04/09/2019 12:47, Dave Martin wrote:
> > ^Nit: "add one testcase" doesn't really describe what is being added here.
> > 
> 
> Yep I know...I was trying to stay under first commit line length limitations
> 
> > Maybe the following would work as the subject line:
> > 
> > --8<--
> > kselftest: arm64: mangle_pstate_invalid_compat_toggle and common utils
> > -->8--
> > 
> I'll grab it
> 
> 
> > The remainder of the commit message looks fine.
> > 
> > On Mon, Sep 02, 2019 at 12:29:23pm +0100, Cristian Marussi wrote:
> >> Add some arm64/signal specific boilerplate and utility code to help
> >> further testcases' development.
> >>
> >> Introduce also one simple testcase mangle_pstate_invalid_compat_toggle
> >> and some related helpers: it is a simple mangle testcase which messes
> >> with the ucontext_t from within the signal handler, trying to toggle
> >> PSTATE state bits to switch the system between 32bit/64bit execution
> >> state. Expects SIGSEGV on test PASS.
> >>
> >> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >> ---
> >> v4 --> v5
> >> - moved kernel headers include search to top level KSFT arm64 Makefile
> >> - removed warning about kernel headers not found
> >> - moved testcases/.gitignore up one level
> >> v3 --> v4
> >> - removed standalone mode
> >> - fixed arm64/signal/README
> >> - add file level comments: test layout / test description
> >> - reduced verbosity
> >> - removed spurious headers includes
> >> - reviewed ID_AA64MMFR[1,2]_EL1 macros
> >> - removed unused feats_ok
> >> - simplified CPU features gathering
> >> - reviewed included headers
> >> - fixed/refactored get_header() and validation routines
> >> - added test description
> >> ---
> > 
> > [...]
> > 
> >> diff --git a/tools/testing/selftests/arm64/signal/test_signals.c b/tools/testing/selftests/arm64/signal/test_signals.c
> >> new file mode 100644
> >> index 000000000000..f05c6dbf8659
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/arm64/signal/test_signals.c
> >> @@ -0,0 +1,29 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2019 ARM Limited
> >> + *
> >> + * Generic test wrapper for arm64 signal tests.
> >> + *
> >> + * Each test provides its own tde struct tddescr descriptor to link with
> > 
> > Typo?  tdescr
> > 
> Yes
> 
> > [...]
> > 
> >> diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.c b/tools/testing/selftests/arm64/signal/test_signals_utils.c
> >> new file mode 100644
> >> index 000000000000..e2a5f37e6ad3
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/arm64/signal/test_signals_utils.c
> >> @@ -0,0 +1,269 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/* Copyright (C) 2019 ARM Limited */
> >> +
> >> +#include <stdio.h>
> >> +#include <stdlib.h>
> >> +#include <signal.h>
> >> +#include <string.h>
> >> +#include <unistd.h>
> >> +#include <assert.h>
> >> +#include <sys/auxv.h>
> >> +#include <linux/auxvec.h>
> >> +#include <ucontext.h>
> >> +
> >> +#include "test_signals.h"
> >> +#include "test_signals_utils.h"
> >> +#include "testcases/testcases.h"
> >> +
> >> +extern struct tdescr *current;
> >> +
> >> +static char *feats_store[FMAX_END] = {
> > 
> > Nit: can we call this feat_names[]?ok
> > 
> > "store" makes me think of loads and stores...
> > 
> > Also, nit: can this be static const char *const []?
> > 
> > String literals are immutable anyway, and I guess we don't intend too
> > modify the pointers to the strings either...
> > 
> Yes of course.
> 
> >> +	" SSBS ",
> >> +	" PAN ",
> >> +	" UAO ",
> >> +};
> >> +
> >> +#define MAX_FEATS_SZ	128
> >> +static char feats_string[MAX_FEATS_SZ];
> >> +
> >> +static inline char *feats_to_string(unsigned long feats)
> >> +{
> >> +	size_t flen = MAX_FEATS_SZ - 1;
> >> +
> >> +	for (int i = 0; i < FMAX_END; i++) {
> >> +		if (feats & 1UL << i) {
> > 
> > Nit: maybe have () around (1UL << i), though I think it makes no
> > difference.
> 
> Yes it's better, I feared that, being not required, was frown upon.
> 
> > 
> >> +			size_t tlen = strlen(feats_store[i]);
> >> +
> >> +			assert(flen > tlen);
> >> +			flen -= tlen;
> >> +			strncat(feats_string, feats_store[i], flen);
> >> +		}
> >> +	}
> >> +
> >> +	return feats_string;
> >> +}
> >> +
> >> +static void unblock_signal(int signum)
> >> +{
> >> +	sigset_t sset;
> >> +
> >> +	sigemptyset(&sset);
> >> +	sigaddset(&sset, signum);
> >> +	sigprocmask(SIG_UNBLOCK, &sset, NULL);
> >> +}
> >> +
> >> +static void default_result(struct tdescr *td, bool force_exit)
> >> +{
> >> +	if (td->pass)
> >> +		fprintf(stderr, "==>> completed. PASS(1)\n");
> >> +	else
> >> +		fprintf(stdout, "==>> completed. FAIL(0)\n");
> >> +	if (force_exit)
> >> +		exit(td->pass ? EXIT_SUCCESS : EXIT_FAILURE);
> >> +}
> >> +
> >> +static inline bool are_feats_ok(struct tdescr *td)
> >> +{
> >> +	return (td->feats_required & td->feats_supported) == td->feats_required;
> >> +}
> >> +
> >> +static void default_handler(int signum, siginfo_t *si, void *uc)
> >> +{
> >> +	if (current->sig_trig && signum == current->sig_trig) {
> > 
> > (Thinking about it, signum is never 0 because there is no signal 0.
> > So we could write if (signum == current->sig_trig).  But I think your
> > code makes the intention clearer -- so no need to change it.)
> > 
> 
> Yes, in fact that's the reason I left it even if unneeded.

Ok, sounds fine.

> >> +		fprintf(stderr, "Handling SIG_TRIG\n");
> >> +		current->triggered = 1;
> >> +		/* ->run was asserted NON-NULL in test_setup() already */
> >> +		current->run(current, si, uc);
> >> +	} else if (signum == SIGILL && !current->initialized) {

[...]

> >> +static int test_init(struct tdescr *td)
> >> +{
> >> +	td->minsigstksz = getauxval(AT_MINSIGSTKSZ);
> >> +	if (!td->minsigstksz)
> >> +		td->minsigstksz = MINSIGSTKSZ;
> >> +	fprintf(stderr, "Detected MINSTKSIGSZ:%d\n", td->minsigstksz);
> >> +
> >> +	if (td->feats_required) {
> >> +		bool feats_ok = false;
> >> +
> >> +		td->feats_supported = 0;
> >> +		/*
> >> +		 * Checking for CPU required features using both the
> >> +		 * auxval and the arm64 MRS Emulation to read sysregs.
> >> +		 */
> >> +		if (getauxval(AT_HWCAP) & HWCAP_CPUID) {
> >> +			uint64_t val = 0;
> >> +
> >> +			/* Uses HWCAP to check capability */
> >> +			if (getauxval(AT_HWCAP) & HWCAP_SSBS)
> >> +				td->feats_supported |= FEAT_SSBS;
> > 
> > Should this be outside the HWCAP_CPUID check?
> 
> Right.
> 
> > 
> > It's only the get_regval(SYS_ID_foo) based checks that depend on
> > HWCAP_CPUID.
> > 
> >> +			/* Uses MRS emulation to check capability */
> >> +			get_regval(SYS_ID_AA64MMFR1_EL1, val);
> >> +			if (ID_AA64MMFR1_EL1_PAN_SUPPORTED(val))
> >> +				td->feats_supported |= FEAT_PAN;
> >> +			/* Uses MRS emulation to check capability */
> >> +			get_regval(SYS_ID_AA64MMFR2_EL1, val);
> >> +			if (ID_AA64MMFR2_EL1_UAO_SUPPORTED(val))
> >> +				td->feats_supported |= FEAT_UAO;
> >> +		} else {
> >> +			fprintf(stderr,
> >> +				"HWCAP_CPUID NOT available. Mark ALL feats UNSUPPORTED.\n");
> >> +		}
> >> +		feats_ok = are_feats_ok(td);
> >> +		fprintf(stderr,
> >> +			"Required Features: [%s] %ssupported\n",
> >> +			feats_ok ? feats_to_string(td->feats_supported) :
> >> +			feats_to_string(td->feats_required ^
> >> +					td->feats_supported),
> > 
> > Should this be something like:
> > td->feats_required & ~td->feats_supported ?
> > 
> > Otherwise we'll include features that are supported but not required,
> > when printing the features that are NOT supported.
> > 
> > Alternatively, we could just print out the required and supported sets
> > separately and leave it up to the user to obverse how they are
> > different.
> > 
> > (Watch out for calling feats_to_string() twice in the same printf() call
> > though.)
> > 
> Ok. Reported information was poor in fact.

[..]

> >> diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c
> >> new file mode 100644
> >> index 000000000000..72e3f482b177
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/arm64/signal/testcases/testcases.c
> >> @@ -0,0 +1,151 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/* Copyright (C) 2019 ARM Limited */
> >> +#include "testcases.h"
> >> +
> >> +struct _aarch64_ctx *get_header(struct _aarch64_ctx *head, uint32_t magic,
> >> +				size_t resv_sz, size_t *offset)
> >> +{
> >> +	size_t offs = 0;
> >> +	struct _aarch64_ctx *found = NULL;
> >> +
> >> +	if (!head)
> >> +		return found;
> >> +
> > 
> > I suggest you also check for resv_sz < HDR_SZ, since the while()
> > condition assumes that resv_sz - HDR_SZ doesn't underflow.
> > 
> > For now, I think resv_sz is already sizeof(__reserved) so this is never
> > true, but I suspect we will want to reuse this code eventually to looko
> > at the contents of extra_context.  Then, resv_sz would be the
> > extra_context size rather than a fixed constant.
> > 
> 
> Ok....in fact I think I removed recently such check...not sure why o_O
> I'll fix it.
> 
> 
> >> +	while (offs <= resv_sz - HDR_SZ &&
> >> +	       head->magic != magic && head->magic) {
> >> +		offs += head->size;
> >> +		head = GET_RESV_NEXT_HEAD(head);
> >> +	}
> >> +	if (head->magic == magic) {
> >> +		found = head;
> >> +		if (offset)
> >> +			*offset = offs;
> >> +	}
> > 
> > Although there appears to be some code duplication here, I guess you
> > need things this way to do the right thing if called with magic==0.
> > 
> > So I guess this is fine.
> >
> Yes that was exactly the point, and it seemed to me that removing further
> duplication would have made the code more complex and unreadable.
> 
> > Ultimately it would be good to have GET_RESV_NEXT_HEAD() work more
> > like an iterator, doing integrity bounds/alignment checks and updating
> > offs as it goes, but for now I think the code is sufficient.  We can
> > always beef it up later to catch more kinds of error from the kernel.
> > 
> Yes I remember you told me that on a previous iteration, but for now I left the
> GET_RESV_NEXT_HEAD() as it was without embedding the bounds checking logic
> because it is indirectly used also by the validation function that I use in
> the ASSERT_GOOD/BAD_CONTEXT() macros, so it should be able to handle
> artficially badly formed and corrupted frames without bailing out: it just walks
> and any kind of logic is handled outside...but maybe I'm overthinking
> (certainly I have not explained this reasons anywhere...I'll add a comment)

Sure, I think that's sufficient.

We could always improve this later, if needed.

[...]

> >> +bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
> >> +{
> >> +	bool terminated = false;
> >> +	size_t offs = 0;
> >> +	int flags = 0;
> >> +	struct extra_context *extra = NULL;
> >> +	struct _aarch64_ctx *head =
> >> +		(struct _aarch64_ctx *)uc->uc_mcontext.__reserved;
> >> +
> >> +	if (!err)
> >> +		return false;
> >> +	/* Walk till the end terminator verifying __reserved contents */
> >> +	while (head && !terminated && offs < resv_sz) {
> >> +		if ((uint64_t)head & 0x0fUL) {
> >> +			*err = "Misaligned HEAD";
> >> +			return false;
> >> +		}
> >> +
> >> +		switch (head->magic) {
> >> +		case 0:
> >> +			if (head->size)
> >> +				*err = "Bad size for terminator";
> >> +			else
> >> +				terminated = true;
> >> +			break;
> >> +		case FPSIMD_MAGIC:
> >> +			if (flags & FPSIMD_CTX)
> >> +				*err = "Multiple FPSIMD_MAGIC";
> >> +			else if (head->size !=
> >> +				 sizeof(struct fpsimd_context))
> >> +				*err = "Bad size for fpsimd_context";
> >> +			flags |= FPSIMD_CTX;
> >> +			break;
> >> +		case ESR_MAGIC:
> >> +			if (head->size != sizeof(struct esr_context))
> >> +				fprintf(stderr,
> >> +					"Bad size for esr_context is not an error...just ignore.\n");
> >> +			break;
> > 
> > Although it's not essential, I'd prefer that we enforce the correct
> > size here.  All records, including esr_context are intended to be
> > fixed-size.
> > 
> > In the kernel we check a bit more loosely -- this allows userspace to
> > delete a record using head->size += next_head->size.  This way no
> > memmove() is needed to shuffle subsequent records down.  I don't know
> > whether any userspace code makes use of this -- prior to SVE there were
> > no optional records except for esr_context, and sigreturn ignores that
> > in any case so deleting it is pointless.
> > 
> 
> > The kernel should never insert extra padding between records though,
> > so I think it makes sense to have strict size checks in this test.
> > 
> 
> Ok, I'll do. I kept it loose as it is in Kernel, because in some past tests
> (now removed) I used to play also with esr_context size to build easily an inflated
> fake sigframe (but good) and adding some badness on top of it.

OK, I guess that would be a problem if we want to use the same validity
checker for kernel-generated and user-generated signal frames.

I'm happy either way ... I'll take a look at v6 and comment.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Enric Balletbo i Serra @ 2019-09-16 11:32 UTC (permalink / raw)
  To: Laurent Pinchart, Brian Masney
  Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
	linux-kernel, linus.walleij, jonas, agross, dri-devel,
	bjorn.andersson, Andrzej Hajda, robdclark, robh+dt, daniel,
	linux-arm-msm, freedreno, sean, linux-arm-kernel
In-Reply-To: <20190916104907.GB4734@pendragon.ideasonboard.com>

Hi,

On 16/9/19 12:49, Laurent Pinchart wrote:
> Hi Brian,
> 
> On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
>> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
>>> On 15.08.2019 02:48, Brian Masney wrote:
>>>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
>>>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
>>>> error. The downstream MSM kernel sources [1] shows that the proper value
>>>> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
>>>> probing to succeed.
>>>>
>>>> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
>>>>
>>>> Signed-off-by: Brian Masney <masneyb@onstation.org>
>>>> ---
>>>>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>> index 25e063bcecbc..bc511fc605c9 100644
>>>> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>> @@ -6,7 +6,7 @@
>>>>  #ifndef __ANX78xx_H
>>>>  #define __ANX78xx_H
>>>>  
>>>> -#define TX_P0				0x70
>>>> +#define TX_P0				0x78
>>>
>>>
>>> This bothers me little. There are no upstream users, grepping android
>>> sources suggests that both values can be used [1][2]  (grep for "#define
>>> TX_P0"), moreover there is code suggesting both values can be valid [3].
>>>
>>> Could you verify datasheet which i2c slave addresses are valid for this
>>> chip, if both I guess this patch should be reworked.
>>>
>>>
>>> [1]:
>>> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
>>>
>>> [2]:
>>> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
>>>
>>> [3]:
>>> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
>>
>> This address is 0x78 on my Nexus 5. Given [3] above it looks like we
>> need to support both addresses. What do you think about moving these
>> addresses into device tree?
> 
> Assuming that the device supports different addresses (I can't validate
> that as I don't have access to the datasheet), and different addresses
> need to be used on different systems, then the address to be used needs
> to be provided by the firmware (DT in this case). Two options are
> possible, either specifying the address explicitly in the device's DT
> node, or specifying free addresses (in the form of a white list or black
> list) and allocating an address from that pool. The latter has been
> discussed in a BoF at the Linux Plumbers Conference last week,
> https://linuxplumbersconf.org/event/4/contributions/542/.
> 
>> The downstream and upstream kernel sources divide these addresses by two
>> to get the i2c address. Here's the code in upstream:
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41
>>
>> I'm not sure why the actual i2c address isn't used in this code.
> 

The ANX7802/12/14/16 has a slave I2C bus that provides the interface to access
or control the chip from the AP. The I2C slave addresses used to control the
ANX7802/12/14/16 are 70h, 72h, 7Ah, 7Eh and 80h. Every address allows you to
access to different registers of the chip and AFAICS is not configurable.

I don't think these addresses should be configured via DT but for the driver itself.

My wild guess is that the ANX7808 has different addresses, but I don't have the
datasheet of this version.

Best regards,
 Enric


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V3 00/15] arm64: dts: imx8: architecture improvement and adding imx8qm support
From: Oliver Graute @ 2019-09-16 11:22 UTC (permalink / raw)
  To: Aisheng Dong
  Cc: devicetree@vger.kernel.org, dongas86@gmail.com,
	catalin.marinas@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
	dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
	shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB42117BD6A60E4FEA1456954080B30@AM0PR04MB4211.eurprd04.prod.outlook.com>

On 13/09/19, Aisheng Dong wrote:
> > From: Oliver Graute <oliver.graute@gmail.com>
> > Sent: Friday, September 13, 2019 8:16 PM
> > 
> > On 12/09/19, Dong Aisheng wrote:
> > > IMX SCU based platforms (e.g. MX8QM/MX8QXP) are comprised of a
> > number
> > > of SS (Subsystems), those SS may be shared between different SoCs
> > > while most of them can be reused like Devices Resources, Clocks, Power
> > domains and etc.
> > >
> > > This patch series aims to improve the MX8 architecture to comply with
> > > the HW design to save a lot of duplicated codes and benefits us a
> > > better maintainability and scalability in the future.
> > >
> > > This patch series depends on another clk new binding series:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fcover%2F11046287%2F&amp;data=02%7C01%7Caishen
> > g.dong
> > > %40nxp.com%7C2dffe4b2a0734c5a031408d738447876%7C686ea1d3bc2b
> > 4c6fa92cd9
> > >
> > 9c5c301635%7C0%7C1%7C637039739035971290&amp;sdata=JsAy8vUkkCp
> > n5HYh79oC
> > > vekH3SJAICg7VQnLMP01O3c%3D&amp;reserved=0
> > 
> > Thx for your update of this patch series. I'am running into the issue that my
> > linux next-20190904 unfortunately is not booting with it on my imx8QM
> > board. Kernel is just stuck during boot see below.
> > 
> > I applied your v5 of your clock binding patches series and applied this series in
> > v3. Your former two patch series worked well with next-20190716.
> > 
> > The last messages from the kernel are:
> > 
> > [    1.019208] imx-scu scu: mbox_request_channel_byname() could not
> > locate channel named "gip3"
> > [    1.027316] imx-scu scu: failed to request mbox chan gip3, ret -22
> > [    1.033480] imx-scu scu: failed to enable general irq channel: -22
> > [    1.039646] imx-scu scu: NXP i.MX SCU Initialized
> > [    1.047414] a35_clk: failed to get clock rate -22
> > [    1.058682]  lcd0-pwm0: failed to power up resource 188 ret -22
> > [    1.064314] imx-scu-clk: probe of pwm_clk failed with error -22
> > [    1.070538]  lcd0: failed to power up resource 187 ret -22
> > [    1.075690] imx-scu-clk: probe of lcd_clk failed with error -22
> > [    1.085965] mipi_csi0_core_clk: failed to attached the power domain -2
> > [    1.092359] mipi_csi0_esc_clk: failed to attached the power domain -2
> > [    1.098777] mipi_csi0_i2c0_clk: failed to attached the power domain -2
> > [    1.105278] mipi_csi0_pwm0_clk: failed to attached the power domain -2
> > [    1.115744] imx8qm-pinctrl scu:pinctrl: initialized IMX pinctrl driver
> > [    1.123923] gpio-mxc 5d080000.gpio: IRQ index 1 not found
> > [    1.130276] gpio-mxc 5d090000.gpio: IRQ index 1 not found
> > 
> > I see similar messages also with your older working patches, only the last two
> > lines are new errors.
> > 
> 
> Those warnings are because we are still missing some domains added into the
> pd driver support, it does not block the booting.
> 
> But I did miss to send another power domain patch to avoid gate of console domain
> which may result in the console hang.

Thx. This patch indeed solved my problem. So now its booting with
next-20190904 and your patch series.

Best regards,

Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Laurent Pinchart @ 2019-09-16 10:49 UTC (permalink / raw)
  To: Brian Masney
  Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
	linux-kernel, linus.walleij, jonas, agross, dri-devel,
	bjorn.andersson, Andrzej Hajda, robdclark, robh+dt, daniel,
	linux-arm-msm, enric.balletbo, freedreno, sean, linux-arm-kernel
In-Reply-To: <20190916103614.GA1644@onstation.org>

Hi Brian,

On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> > On 15.08.2019 02:48, Brian Masney wrote:
> > > When attempting to configure this driver on a Nexus 5 phone (msm8974),
> > > setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> > > error. The downstream MSM kernel sources [1] shows that the proper value
> > > for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> > > probing to succeed.
> > >
> > > [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
> > >
> > > Signed-off-by: Brian Masney <masneyb@onstation.org>
> > > ---
> > >  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > > index 25e063bcecbc..bc511fc605c9 100644
> > > --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > > +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > > @@ -6,7 +6,7 @@
> > >  #ifndef __ANX78xx_H
> > >  #define __ANX78xx_H
> > >  
> > > -#define TX_P0				0x70
> > > +#define TX_P0				0x78
> > 
> > 
> > This bothers me little. There are no upstream users, grepping android
> > sources suggests that both values can be used [1][2]  (grep for "#define
> > TX_P0"), moreover there is code suggesting both values can be valid [3].
> > 
> > Could you verify datasheet which i2c slave addresses are valid for this
> > chip, if both I guess this patch should be reworked.
> > 
> > 
> > [1]:
> > https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
> > 
> > [2]:
> > https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
> > 
> > [3]:
> > https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
> 
> This address is 0x78 on my Nexus 5. Given [3] above it looks like we
> need to support both addresses. What do you think about moving these
> addresses into device tree?

Assuming that the device supports different addresses (I can't validate
that as I don't have access to the datasheet), and different addresses
need to be used on different systems, then the address to be used needs
to be provided by the firmware (DT in this case). Two options are
possible, either specifying the address explicitly in the device's DT
node, or specifying free addresses (in the form of a white list or black
list) and allocating an address from that pool. The latter has been
discussed in a BoF at the Linux Plumbers Conference last week,
https://linuxplumbersconf.org/event/4/contributions/542/.

> The downstream and upstream kernel sources divide these addresses by two
> to get the i2c address. Here's the code in upstream:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41
> 
> I'm not sure why the actual i2c address isn't used in this code.

-- 
Regards,

Laurent Pinchart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* RE: [1/3] soc: fsl: fix that flextimer cannot wakeup system in deep sleep on LS1021A
From: Biwen Li @ 2019-09-16 10:48 UTC (permalink / raw)
  To: Biwen Li, Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com
  Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190916102556.16655-1-biwen.li@nxp.com>

Hi all,
	the linux patch depended by RCPM driver,FlexTimer driver and FlexTimer dts, need apply these patches as follows:

	1. RCPM driver:

	https://patchwork.kernel.org/series/162731/mbox/ (https://patchwork.kernel.org/patch/11105279/)

	2. FlexTimer dts:

	https://lore.kernel.org/patchwork/series/405653/mbox/ (https://lore.kernel.org/patchwork/patch/1112493/)

	3. FlexTimer driver:

	https://patchwork.ozlabs.org/series/124718/mbox/ (https://patchwork.ozlabs.org/patch/1145999/)

	https://patchwork.ozlabs.org/series/126942/mbox/ (https://patchwork.ozlabs.org/patch/1152085/)

	4. Adjust drivers/soc/fsl/Makefile:

remove the line 'obj-y += ftm_alarm.o' in drivers/soc/fsl/Makefile to resolve a compilation error 
> Why:
>     - Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
>       Register RCPM_IPPDEXPCR1's default value is zero.
>       So the register value that reading from register
>       RCPM_IPPDEXPCR1 is always zero.
> 
> How:
>     - Save register RCPM_IPPDEXPCR1's value to
>       register SCFG_SPARECR8.(uboot's psci also
>       need reading value from the register SCFG_SPARECR8
>       to set register RCPM_IPPDEXPCR1)
> 
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
>  drivers/soc/fsl/rcpm.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> 82c0ad5e663e..2bf37d38efe5 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -13,6 +13,8 @@
>  #include <linux/slab.h>
>  #include <linux/suspend.h>
>  #include <linux/kernel.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> 
>  #define RCPM_WAKEUP_CELL_MAX_SIZE	7
> 
> @@ -63,6 +65,33 @@ static int rcpm_pm_prepare(struct device *dev)
>  					tmp |= value[i + 1];
>  					iowrite32be(tmp, rcpm->ippdexpcr_base + i * 4);
>  				}
> +				#ifdef CONFIG_SOC_LS1021A
> +				/* Workaround: There is a bug of register ippdexpcr1,
> +				 * cannot write it but can read it.Tt's default value is zero,
> +				 * then read it will always returns zero.
> +				 * So save ippdexpcr1's value to register SCFG_SPARECR8.
> +				 * And the value of ippdexpcr1 will be read from
> SCFG_SPARECR8.
> +				 */
> +				{
> +					struct regmap * rcpm_scfg_regmap = NULL;
> +					u32 reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
> +					u32 reg_value = 0;
> +
> +					rcpm_scfg_regmap =
> syscon_regmap_lookup_by_phandle(np, "fsl,rcpm-scfg");
> +					if (rcpm_scfg_regmap) {
> +						if (of_property_read_u32_array(dev->of_node,
> +						    "fsl,rcpm-scfg", reg_offset,
> rcpm->wakeup_cells + 1)) {
> +							rcpm_scfg_regmap = NULL;
> +							continue;
> +						}
> +						regmap_read(rcpm_scfg_regmap, reg_offset[i + 1],
> &reg_value);
> +						/* Write value to register SCFG_SPARECR8 */
> +						regmap_write(rcpm_scfg_regmap, reg_offset[i +
> 1], tmp | reg_value);
> +					}
> +				}
> +				#endif
> +
> +
>  			}
>  		}
>  	} while (ws = wakeup_source_get_next(ws));
> --
> 2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] iommu/arm-smmu: Axe a useless test in 'arm_smmu_master_alloc_smes()'
From: Robin Murphy @ 2019-09-16 10:46 UTC (permalink / raw)
  To: Christophe JAILLET, will, joro
  Cc: iommu, kernel-janitors, linux-kernel, linux-arm-kernel
In-Reply-To: <20190915193401.27426-1-christophe.jaillet@wanadoo.fr>

On 15/09/2019 20:34, Christophe JAILLET wrote:
> 'ommu_group_get_for_dev()' never returns NULL, so this test can be removed.

Nit: typo in the function name.

Otherwise, there definitely used to be some path where a NULL return 
could leak out, so I would have had that in mind at the time I wrote 
this, but apparently I never noticed that that had already been cleaned 
up by the time this got merged.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Thanks,
Robin.

> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
>   drivers/iommu/arm-smmu.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c3ef0cc8f764..6fae8cdbe985 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1038,8 +1038,6 @@ static int arm_smmu_master_alloc_smes(struct device *dev)
>   	}
>   
>   	group = iommu_group_get_for_dev(dev);
> -	if (!group)
> -		group = ERR_PTR(-ENOMEM);
>   	if (IS_ERR(group)) {
>   		ret = PTR_ERR(group);
>   		goto out_err;
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3] ARM: dts: imx6qdl-rex: add gpio expander pca9535
From: Gilles DOFFE @ 2019-09-16 10:43 UTC (permalink / raw)
  To: devicetree
  Cc: Mark Rutland, Fabio Estevam, Sascha Hauer, rennes, linux-kernel,
	Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
	jerome.oufella, Shawn Guo, linux-arm-kernel

The pca9535 gpio expander is present on the Rex baseboard, but missing
from the dtsi.
The pca9535 is on i2c2 bus which is common to the three SOM
variants (Basic/Pro/Ultra), thus it is activated by default.

Add also the new gpio controller and the associated interrupt line
MX6QDL_PAD_NANDF_CS3__GPIO6_IO16.

Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com>
---
 arch/arm/boot/dts/imx6qdl-rex.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi b/arch/arm/boot/dts/imx6qdl-rex.dtsi
index 97f1659144ea..8a748ca1b108 100644
--- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
@@ -132,6 +132,19 @@
 	pinctrl-0 = <&pinctrl_i2c2>;
 	status = "okay";
 
+	pca9535: gpio8@27 {
+		compatible = "nxp,pca9535";
+		reg = <0x27>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9535>;
+		interrupt-parent = <&gpio6>;
+		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
 	eeprom@57 {
 		compatible = "atmel,24c02";
 		reg = <0x57>;
@@ -237,6 +250,12 @@
 			>;
 		};
 
+		pinctrl_pca9535: pca9535 {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_CS3__GPIO6_IO16	0x17059
+		   >;
+		};
+
 		pinctrl_uart1: uart1grp {
 			fsl,pins = <
 				MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA	0x1b0b1
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* linux-next: manual merge of the arm64 tree with the compiler-attributes tree
From: Mark Brown @ 2019-09-16 10:42 UTC (permalink / raw)
  To: Rasmus Villemoes, Miguel Ojeda, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1383 bytes --]

Hi all,

Today's linux-next merge of the arm64 tree got a conflict in:

  init/Kconfig

between commit:

  eb111869301e15b7373 ("compiler-types.h: add asm_inline definition")

from the compiler-attributes tree and commit:

  2d122942484c20b ("Revert "init/Kconfig: Fix infinite Kconfig recursion on PPC"")

from the arm64 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc init/Kconfig
index 257e428c90472,d96127ebc44e0..cebadd0cfa50e
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -30,9 -30,9 +30,12 @@@ config CC_CAN_LIN
  config CC_HAS_ASM_GOTO
        def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
  
 +config CC_HAS_ASM_INLINE
 +      def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null)
 +
+ config TOOLS_SUPPORT_RELR
+       def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
+ 
  config CC_HAS_WARN_MAYBE_UNINITIALIZED
        def_bool $(cc-option,-Wmaybe-uninitialized)
        help

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Brian Masney @ 2019-09-16 10:40 UTC (permalink / raw)
  To: Enric Balletbo i Serra
  Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
	linux-kernel, linus.walleij, jonas, agross, dri-devel,
	bjorn.andersson, Andrzej Hajda, robdclark, robh+dt,
	Laurent.pinchart, daniel, linux-arm-msm, freedreno, sean,
	linux-arm-kernel
In-Reply-To: <98199a9b-f7e0-ef95-62d7-401273457692@collabora.com>

On Mon, Sep 16, 2019 at 12:36:19PM +0200, Enric Balletbo i Serra wrote:
> Hi Andrzej and Brian
> 
> On 16/9/19 12:02, Andrzej Hajda wrote:
> > On 15.08.2019 02:48, Brian Masney wrote:
> >> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> >> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> >> error. The downstream MSM kernel sources [1] shows that the proper value
> >> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> >> probing to succeed.
> >>
> >> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
> >>
> >> Signed-off-by: Brian Masney <masneyb@onstation.org>
> >> ---
> >>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >> index 25e063bcecbc..bc511fc605c9 100644
> >> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >> @@ -6,7 +6,7 @@
> >>  #ifndef __ANX78xx_H
> >>  #define __ANX78xx_H
> >>  
> >> -#define TX_P0				0x70
> >> +#define TX_P0				0x78
> > 
> > 
> > This bothers me little. There are no upstream users, grepping android
> > sources suggests that both values can be used [1][2]  (grep for "#define
> > TX_P0"), moreover there is code suggesting both values can be valid [3].
> > 
> > Could you verify datasheet which i2c slave addresses are valid for this
> > chip, if both I guess this patch should be reworked.
> > 
> 
> On my case the valid i2c slave address is 0x70 (from datasheet, very sorry I
> can't share it) and the bridge used is an ANX7814, it could be that ANX7808 or
> ANX7812 have different slave addresses?

I haven't been able to find any of the datasheets for these devices
online. Product briefs are online (such as 
https://www.analogix.com/en/system/files/ANX7808_product_brief.pdf), but
they don't provide this type of information.

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Enric Balletbo i Serra @ 2019-09-16 10:36 UTC (permalink / raw)
  To: Andrzej Hajda, Brian Masney, bjorn.andersson, robh+dt, agross,
	narmstrong, robdclark, sean
  Cc: mark.rutland, devicetree, jernej.skrabec, jonas, airlied,
	linux-arm-msm, linus.walleij, linux-kernel, dri-devel,
	Laurent.pinchart, daniel, freedreno, linux-arm-kernel
In-Reply-To: <dc10dd84-72e2-553e-669b-271b77b4a21a@samsung.com>

Hi Andrzej and Brian

On 16/9/19 12:02, Andrzej Hajda wrote:
> On 15.08.2019 02:48, Brian Masney wrote:
>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
>> error. The downstream MSM kernel sources [1] shows that the proper value
>> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
>> probing to succeed.
>>
>> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
>>
>> Signed-off-by: Brian Masney <masneyb@onstation.org>
>> ---
>>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>> index 25e063bcecbc..bc511fc605c9 100644
>> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
>> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>> @@ -6,7 +6,7 @@
>>  #ifndef __ANX78xx_H
>>  #define __ANX78xx_H
>>  
>> -#define TX_P0				0x70
>> +#define TX_P0				0x78
> 
> 
> This bothers me little. There are no upstream users, grepping android
> sources suggests that both values can be used [1][2]  (grep for "#define
> TX_P0"), moreover there is code suggesting both values can be valid [3].
> 
> Could you verify datasheet which i2c slave addresses are valid for this
> chip, if both I guess this patch should be reworked.
> 

On my case the valid i2c slave address is 0x70 (from datasheet, very sorry I
can't share it) and the bridge used is an ANX7814, it could be that ANX7808 or
ANX7812 have different slave addresses?

Regards,
 Enric

> 
> [1]:
> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
> 
> [2]:
> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
> 
> [3]:
> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
> 
> 
> Regards
> 
> Andrzej
> 
> 
>>  #define TX_P1				0x7a
>>  #define TX_P2				0x72
>>  
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [3/3] Documentation: dt: binding: fsl: Add 'fsl,rcpm-scfg' property
From: Biwen Li @ 2019-09-16 10:25 UTC (permalink / raw)
  To: leoyang.li, shawnguo, robh+dt, mark.rutland
  Cc: devicetree, linuxppc-dev, linux-kernel, linux-arm-kernel,
	Biwen Li
In-Reply-To: <20190916102556.16655-1-biwen.li@nxp.com>

The 'fsl,rcpm-scfg' property is used to fix a bug
that FlexTimer cannot wakeup system in deep sleep on LS1021A

Signed-off-by: Biwen Li <biwen.li@nxp.com>
---
 .../devicetree/bindings/soc/fsl/rcpm.txt          | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index 5a33619d881d..31e22f092b51 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -34,6 +34,12 @@ Chassis Version		Example Chips
 Optional properties:
  - little-endian : RCPM register block is Little Endian. Without it RCPM
    will be Big Endian (default case).
+ - fsl,rcpm-scfg : Must add the property for SoC LS1021A,
+   Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
+   #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
+   The first entry must be a link to the SCFG device node.
+   The non-first entry must be offset of registers of SCFG.
+   (Currently only support SoC LS1021A)
 
 Example:
 The RCPM node for T4240:
@@ -43,6 +49,15 @@ The RCPM node for T4240:
 		#fsl,rcpm-wakeup-cells = <2>;
 	};
 
+The RCPM node for LS1021A:
+	rcpm: rcpm@1ee2140 {
+		compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
+		reg = <0x0 0x1ee2140 0x0 0x8>;
+		#fsl,rcpm-wakeup-cells = <2>;
+		fsl,rcpm-scfg = <&scfg 0x0 0x51c>; /* SCFG_SPARECR8 */
+	};
+
+
 * Freescale RCPM Wakeup Source Device Tree Bindings
 -------------------------------------------
 Required fsl,rcpm-wakeup property should be added to a device node if the device
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [1/3] soc: fsl: fix that flextimer cannot wakeup system in deep sleep on LS1021A
From: Biwen Li @ 2019-09-16 10:25 UTC (permalink / raw)
  To: leoyang.li, shawnguo, robh+dt, mark.rutland
  Cc: devicetree, linuxppc-dev, linux-kernel, linux-arm-kernel,
	Biwen Li

Why:
    - Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
      Register RCPM_IPPDEXPCR1's default value is zero.
      So the register value that reading from register
      RCPM_IPPDEXPCR1 is always zero.

How:
    - Save register RCPM_IPPDEXPCR1's value to
      register SCFG_SPARECR8.(uboot's psci also
      need reading value from the register SCFG_SPARECR8
      to set register RCPM_IPPDEXPCR1)

Signed-off-by: Biwen Li <biwen.li@nxp.com>
---
 drivers/soc/fsl/rcpm.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 82c0ad5e663e..2bf37d38efe5 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,8 @@
 #include <linux/slab.h>
 #include <linux/suspend.h>
 #include <linux/kernel.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
 
 #define RCPM_WAKEUP_CELL_MAX_SIZE	7
 
@@ -63,6 +65,33 @@ static int rcpm_pm_prepare(struct device *dev)
 					tmp |= value[i + 1];
 					iowrite32be(tmp, rcpm->ippdexpcr_base + i * 4);
 				}
+				#ifdef CONFIG_SOC_LS1021A
+				/* Workaround: There is a bug of register ippdexpcr1,
+				 * cannot write it but can read it.Tt's default value is zero,
+				 * then read it will always returns zero.
+				 * So save ippdexpcr1's value to register SCFG_SPARECR8.
+				 * And the value of ippdexpcr1 will be read from SCFG_SPARECR8.
+				 */
+				{
+					struct regmap * rcpm_scfg_regmap = NULL;
+					u32 reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
+					u32 reg_value = 0;
+
+					rcpm_scfg_regmap = syscon_regmap_lookup_by_phandle(np, "fsl,rcpm-scfg");
+					if (rcpm_scfg_regmap) {
+						if (of_property_read_u32_array(dev->of_node,
+						    "fsl,rcpm-scfg", reg_offset, rcpm->wakeup_cells + 1)) {
+							rcpm_scfg_regmap = NULL;
+							continue;
+						}
+						regmap_read(rcpm_scfg_regmap, reg_offset[i + 1], &reg_value);
+						/* Write value to register SCFG_SPARECR8 */
+						regmap_write(rcpm_scfg_regmap, reg_offset[i + 1], tmp | reg_value);
+					}
+				}
+				#endif
+
+
 			}
 		}
 	} while (ws = wakeup_source_get_next(ws));
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [2/3] arm: dts: ls1021a: fix that FlexTimer cannot wakeup system in deep sleep
From: Biwen Li @ 2019-09-16 10:25 UTC (permalink / raw)
  To: leoyang.li, shawnguo, robh+dt, mark.rutland
  Cc: devicetree, linuxppc-dev, linux-kernel, linux-arm-kernel,
	Biwen Li
In-Reply-To: <20190916102556.16655-1-biwen.li@nxp.com>

The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.

Signed-off-by: Biwen Li <biwen.li@nxp.com>
---
 arch/arm/boot/dts/ls1021a.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index e3973b611c3a..377bb4717584 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -1000,12 +1000,13 @@
 			compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
 			reg = <0x0 0x1ee2140 0x0 0x8>;
 			#fsl,rcpm-wakeup-cells = <2>;
+			fsl,rcpm-scfg = <&scfg 0x0 0x51c>; /* SCFG_SPARECR8 */
 		};
 
 		ftm_alarm0: timer0@29d0000 {
 			compatible = "fsl,ls1021a-ftm-alarm";
 			reg = <0x0 0x29d0000 0x0 0x10000>;
-			fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
+			fsl,rcpm-wakeup = <&rcpm 0x0 0x30000000>; /* FlexTimer1 and OCRAM1 are not powerdown during LPM20(sleep) */
 			interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 			big-endian;
 		};
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Brian Masney @ 2019-09-16 10:36 UTC (permalink / raw)
  To: Andrzej Hajda
  Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
	linux-kernel, linus.walleij, jonas, agross, dri-devel,
	bjorn.andersson, robdclark, robh+dt, Laurent.pinchart, daniel,
	linux-arm-msm, enric.balletbo, freedreno, sean, linux-arm-kernel
In-Reply-To: <dc10dd84-72e2-553e-669b-271b77b4a21a@samsung.com>

On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> On 15.08.2019 02:48, Brian Masney wrote:
> > When attempting to configure this driver on a Nexus 5 phone (msm8974),
> > setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> > error. The downstream MSM kernel sources [1] shows that the proper value
> > for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> > probing to succeed.
> >
> > [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
> >
> > Signed-off-by: Brian Masney <masneyb@onstation.org>
> > ---
> >  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > index 25e063bcecbc..bc511fc605c9 100644
> > --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> > @@ -6,7 +6,7 @@
> >  #ifndef __ANX78xx_H
> >  #define __ANX78xx_H
> >  
> > -#define TX_P0				0x70
> > +#define TX_P0				0x78
> 
> 
> This bothers me little. There are no upstream users, grepping android
> sources suggests that both values can be used [1][2]  (grep for "#define
> TX_P0"), moreover there is code suggesting both values can be valid [3].
> 
> Could you verify datasheet which i2c slave addresses are valid for this
> chip, if both I guess this patch should be reworked.
> 
> 
> [1]:
> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
> 
> [2]:
> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
> 
> [3]:
> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73

This address is 0x78 on my Nexus 5. Given [3] above it looks like we
need to support both addresses. What do you think about moving these
addresses into device tree?

The downstream and upstream kernel sources divide these addresses by two
to get the i2c address. Here's the code in upstream:

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41

I'm not sure why the actual i2c address isn't used in this code.

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [EXT] Re: SCMI & Devfreq
From: Sudeep Holla @ 2019-09-16 10:15 UTC (permalink / raw)
  To: Sujeet Kumar Baranwal; +Cc: linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR18MB2438723658EF1F0586170CDDAF8C0@BYAPR18MB2438.namprd18.prod.outlook.com>

On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based
>>> platform ?
>
> DT based.
>

Good.

>>> Yes it needs some work and I do have some prototype, but with no users in
>>> the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic
>>> devfreq driver that I had seen >>on the list and my plan was to do
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is a need
> for a userspace dev governor controlling the frequency in different
> situation.

Okay, thanks for the info.

> Could you please share your patches and any instructions if needed.
>

It needs some polishing before I post them externally, they are still
hackish. I will do soonish.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Lukasz Luba @ 2019-09-16 10:07 UTC (permalink / raw)
  To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
	linux-arm-kernel
  Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
	cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
	myungjoo.ham, m.szyprowski
In-Reply-To: <20190916100704.26692-1-l.luba@partner.samsung.com>

Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
Introduce minor fixes in the old documentation.

Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
 Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
index 3b2485b84b3f..49afe794daaa 100644
--- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
+++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
@@ -1,7 +1,9 @@
 * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
 
 Required properties:
-- compatible : Should be  - "jedec,lpddr3"
+- compatible : should be one of the following:
+	Generic default - "jedec,lpddr3".
+	For Samsung 542x SoC - "samsung,K3QF2F20DB", "jedec,lpddr3".
 - density  : <u32> representing density in Mb (Mega bits)
 - io-width : <u32> representing bus width. Possible values are 8, 16, 32, 64
 - #address-cells: Must be set to 1
@@ -43,7 +45,7 @@ Child nodes:
 Example:
 
 samsung_K3QF2F20DB: lpddr3 {
-	compatible	= "Samsung,K3QF2F20DB", "jedec,lpddr3";
+	compatible	= "samsung,K3QF2F20DB", "jedec,lpddr3";
 	density		= <16384>;
 	io-width	= <32>;
 	#address-cells	= <1>;
@@ -73,7 +75,8 @@ samsung_K3QF2F20DB: lpddr3 {
 
 	timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 {
 		compatible	= "jedec,lpddr3-timings";
-		reg		= <800000000>; /* workaround: it shows max-freq */
+		/* workaround: 'reg' shows max-freq */
+		reg		= <800000000>;
 		min-freq	= <100000000>;
 		tRFC		= <65000>;
 		tRRD		= <6000>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 1/3] memory: Exynos5422: minor fixes in DMC
From: Lukasz Luba @ 2019-09-16 10:07 UTC (permalink / raw)
  To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
	linux-arm-kernel
  Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
	cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
	myungjoo.ham, m.szyprowski
In-Reply-To: <20190916100704.26692-1-l.luba@partner.samsung.com>

Small fixes for issues captured by static analyzes:
used kfree() insead of devm_kfree() and missing 'static' in the private
function.
Checks which show the issues:
- drivers/memory/samsung/exynos5422-dmc.c:272 exynos5_init_freq_table()
warn: passing devm_ allocated variable to kfree. 'dmc->opp'
- drivers/memory/samsung/exynos5422-dmc.c:736:1: warning: symbol
'exynos5_dmc_align_init_freq' was not declared.

Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
 drivers/memory/samsung/exynos5422-dmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
index 8c2ec29a7d57..a809fa997c03 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -269,7 +269,7 @@ static int exynos5_init_freq_table(struct exynos5_dmc *dmc,
 	return 0;
 
 err_free_tables:
-	kfree(dmc->opp);
+	devm_kfree(dmc->dev, dmc->opp);
 err_opp:
 	dev_pm_opp_of_remove_table(dmc->dev);
 
@@ -732,7 +732,7 @@ static struct devfreq_dev_profile exynos5_dmc_df_profile = {
  * statistics engine which supports only registered values. Thus, some alignment
  * must be made.
  */
-unsigned long
+static unsigned long
 exynos5_dmc_align_init_freq(struct exynos5_dmc *dmc,
 			    unsigned long bootloader_init_freq)
 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 0/3] Exynos5 DMC minor fixes
From: Lukasz Luba @ 2019-09-16 10:07 UTC (permalink / raw)
  To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
	linux-arm-kernel
  Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
	cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
	myungjoo.ham, m.szyprowski
In-Reply-To: <CGME20190916100716eucas1p213ef29ba8bd288dfc6b5f05138c9a558@eucas1p2.samsung.com>

Hi all,

This is a follow up patch set for the Exynos5 Dynamic Memory Controller
driver v13 [1]. The patches are based on Krzysztof's 'for-next' branch [2].
There are a few minor fixes captured during static analysis and a new
binding for 'samsung,K3QF2F20DB' LPDDR3 memory.

Regards,
Lukasz Luba

[1] https://lkml.org/lkml/2019/8/21/283
[2] https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/log/?h=for-next

Lukasz Luba (3):
  memory: Exynos5422: minor fixes in DMC
  ARM: dts: exynos: fix too long line in memory device
  dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories

 Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi    | 3 ++-
 drivers/memory/samsung/exynos5422-dmc.c          | 4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 2/3] ARM: dts: exynos: fix too long line in memory device
From: Lukasz Luba @ 2019-09-16 10:07 UTC (permalink / raw)
  To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
	linux-arm-kernel
  Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
	cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
	myungjoo.ham, m.szyprowski
In-Reply-To: <20190916100704.26692-1-l.luba@partner.samsung.com>

Small fix moving the comment to line above making sure the lines do not
exceed 80 characters.

Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index fe885ca969af..059fa32d1a8f 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -103,7 +103,8 @@
 
 		timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 {
 			compatible	= "jedec,lpddr3-timings";
-			reg		= <800000000>; /* workaround: it shows max-freq */
+			/* workaround: 'reg' shows max-freq */
+			reg		= <800000000>;
 			min-freq	= <100000000>;
 			tRFC		= <65000>;
 			tRRD		= <6000>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Andrzej Hajda @ 2019-09-16 10:02 UTC (permalink / raw)
  To: Brian Masney, bjorn.andersson, robh+dt, agross, narmstrong,
	robdclark, sean
  Cc: mark.rutland, devicetree, jernej.skrabec, jonas, airlied,
	linux-arm-msm, linus.walleij, linux-kernel, dri-devel,
	Laurent.pinchart, daniel, enric.balletbo, freedreno,
	linux-arm-kernel
In-Reply-To: <20190815004854.19860-6-masneyb@onstation.org>

On 15.08.2019 02:48, Brian Masney wrote:
> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> error. The downstream MSM kernel sources [1] shows that the proper value
> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> probing to succeed.
>
> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> ---
>  drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> index 25e063bcecbc..bc511fc605c9 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> @@ -6,7 +6,7 @@
>  #ifndef __ANX78xx_H
>  #define __ANX78xx_H
>  
> -#define TX_P0				0x70
> +#define TX_P0				0x78


This bothers me little. There are no upstream users, grepping android
sources suggests that both values can be used [1][2]  (grep for "#define
TX_P0"), moreover there is code suggesting both values can be valid [3].

Could you verify datasheet which i2c slave addresses are valid for this
chip, if both I guess this patch should be reworked.


[1]:
https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h

[2]:
https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h

[3]:
https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73


Regards

Andrzej


>  #define TX_P1				0x7a
>  #define TX_P2				0x72
>  



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH V3] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-09-16  9:51 UTC (permalink / raw)
  To: sstabellini@kernel.org, linux@armlinux.org.uk,
	catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com
  Cc: xen-devel@lists.xenproject.org, Peng Fan, dl-linux-imx,
	linux-arm-kernel@lists.infradead.org

From: Peng Fan <peng.fan@nxp.com>

arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").

So add a check if CONFIG_ZONE_DMA32 is enabled use __GFP_DMA32.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---

V3:
 Use IS_ENABLED(CONFIG_ZONE_DMA32) and drop xen_set_gfp_dma.

V2:
 Follow suggestion from Stefano,
 introduce static inline void xen_set_gfp_dma(gfp_t *flags) for arm32/arm64, and
 for arm64 using __GFP_DMA for the former and __GFP_DMA32 for the latter.


 arch/arm/xen/mm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 2b2c208408bb..38fa917c8585 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,10 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
 
 	for_each_memblock(memory, reg) {
 		if (reg->base < (phys_addr_t)0xffffffff) {
-			flags |= __GFP_DMA;
+			if (IS_ENABLED(CONFIG_ZONE_DMA32))
+				flags |= __GFP_DMA32;
+			else
+				flags |= __GFP_DMA;
 			break;
 		}
 	}
-- 
2.16.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox