dingly, but clk_set_rate()
>> used crtc_state->adjusted_mode->clock instead.
>> Fixes: 28ab7d35b6e0 ("drm/ingenic: Properly compute timings when using a
>> 3x8-bit panel")
>> Cc: sta...@vger.kernel.org # v5.10
Tested-by: H. Nikolaus Schaller # CI20/jz4780 (HDM
> Am 04.04.2021 um 12:01 schrieb Greg KH :
>
> On Sun, Apr 04, 2021 at 11:29:00AM +0200, H. Nikolaus Schaller wrote:
>> it seems as if the patch
>>
>> 9de47c37 ("usb: dwc3: gadget: Prevent EP queuing while stopping
>> transfers") in v5.11
it seems as if the patch
9de47c37 ("usb: dwc3: gadget: Prevent EP queuing while stopping
transfers") in v5.11.y
f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping
transfers") in v5.12-rc5
reproducible breaks dwc3 RNDIS gadget, at least on the Pyra Handheld
> Am 30.03.2021 um 19:27 schrieb Daniel Walker :
>
> On Fri, Mar 26, 2021 at 01:44:48PM +, Christophe Leroy wrote:
>> This code provides architectures with a way to build command line
>> based on what is built in the kernel and what is handed over by the
>> bootloader, based on selected
Without we get an "Specify missing connector_type" warning.
Fixes: ddb8e853dc85 ("drm/panel: panel-simple: validate panel description")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
so that we can suggest a patch.
BR and thanks,
Nikolaus
> Am 31.01.2021 um 11:54 schrieb H. Nikolaus Schaller :
>
> ping?
>
>> Am 12.01.2021 um 12:41 schrieb H. Nikolaus Schaller :
>>
>> Hi,
>> according to bindings/display/panel/panel-common.yaml
>>
Hi Paul,
> Am 02.02.2021 um 10:56 schrieb Paul Kocialkowski
> :
>
> Hi Nikolaus,
>
> On Tue 02 Feb 21, 10:18, H. Nikolaus Schaller wrote:
>> Hi,
>> since v5.11-rc6 my Pinephone display shows some moiré pattern.
>>
>> I did a bisect betw
Hi,
since v5.11-rc6 my Pinephone display shows some moiré pattern.
I did a bisect between v5.11-rc5 and v5.11-rc6 and it told me that
the commit mentioned in the subject is the reason.
Reverting it makes the display work again and re-reverting fail again.
IMHO it seems as if the display DMA of
ping?
> Am 12.01.2021 um 12:41 schrieb H. Nikolaus Schaller :
>
> Hi,
> according to bindings/display/panel/panel-common.yaml
> and by using "panel-simple" as compatible string we
> can define almost all properties of a DSI panel by a
> device tree entry.
>
&
Hi Paul,
> Am 24.01.2021 um 10:47 schrieb H. Nikolaus Schaller :
>
> Hi Paul,
>
>> Am 24.01.2021 um 10:43 schrieb Paul Cercueil :
>>
>> Hi Nikolaus,
>>
>> Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller a
>> écrit :
>>> Hi
Hi Paul,
> Am 24.01.2021 um 10:43 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller a
> écrit :
>> Hi Paul,
>> we observed the same issue on the jz4730 (which is almost identical
>> to the jz4740 wrt. LC
Hi Paul,
we observed the same issue on the jz4730 (which is almost identical
to the jz4740 wrt. LCDC) and our solution [1] was simpler.
It leaves the hwdesc f0 and f1 as they are and just takes f1 for really
programming the first DMA descriptor if there is no OSD.
We have tested on jz4730 and
> Am 20.01.2021 um 12:07 schrieb Paul Cercueil :
>
> - Add otg function and otg-vbus group.
>
> - Add lcd-8bit, lcd-16bit, lcd-18bit, lcd-generic and lcd-special
> groups. Change the lcd-24bit group so that it only selects the pins
> that aren't in the lcd-18bit and lcd-generic groups (which
Ah, there is a v2. Let's hope this gets merged/processed by robots correctly :)
> Am 13.01.2021 um 00:15 schrieb Andreas Kemnade :
>
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> Am 13.01.2021 um 00:15 schrieb Andreas Kemnade :
>
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> ---
> arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
seems to have a
Hi,
according to bindings/display/panel/panel-common.yaml
and by using "panel-simple" as compatible string we
can define almost all properties of a DSI panel by a
device tree entry.
Except the connector and bus format which can only be
set by adding the same information to the panel-simple
> Am 10.01.2021 um 12:35 schrieb Paul Cercueil :
>
> Hi Thomas,
>
> Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer
> a écrit :
>> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
>>> On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
>>> > Hi Thomas,
>>> >
Hi Adam,
> Am 09.01.2021 um 17:39 schrieb Adam Ford :
>
> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
>
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants,
Hi Adam and Tony,
> Am 30.12.2020 um 13:55 schrieb Adam Ford :
>
> On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote:
>>
>> At least for 4430, trying to use the single conversion mode eventually
>> hangs the thermal sensor. This can be quite easily seen with errors:
>>
>> thermal
: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO
descriptors")
CC: sta...@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b
card_detect_irq is not used anymore since v4.1.
Remove it.
H. Nikolaus Schaller (2):
mmc: jz4740: remove unused struct component card_detect_irq
mmc: omap: remove unused struct component card_detect_irq
drivers/mmc/host/jz4740_mmc.c | 1 -
include/linux/platform_data/mmc-omap.h | 3
I have not found any user for this struct component.
Signed-off-by: H. Nikolaus Schaller
---
drivers/mmc/host/jz4740_mmc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index a1f92fed2a55b7..b3c636edbb4610 100644
--- a/drivers
I have not found any user for this struct component.
Signed-off-by: H. Nikolaus Schaller
---
include/linux/platform_data/mmc-omap.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/platform_data/mmc-omap.h
b/include/linux/platform_data/mmc-omap.h
index
ck in sync with the data sheet and
spi subsystem code.
Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO
descriptors")
CC: sta...@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git
> Am 09.12.2020 um 22:28 schrieb Sven Van Asbroeck :
>
> On Wed, Dec 9, 2020 at 3:08 PM H. Nikolaus Schaller
> wrote:
>>
>> But I have tested with
>>
>>> spi->mode |= SPI_MODE_3;
>>
>> which should keep the mode intact. Right? Tha
Hi Andreas,
> Am 09.12.2020 um 21:01 schrieb Andreas Kemnade :
>
> On Wed, 9 Dec 2020 14:04:26 -0500
> Sven Van Asbroeck wrote:
>
>> On Wed, Dec 9, 2020 at 1:16 PM H. Nikolaus Schaller
>> wrote:
>>>
>>> This is also what made me wonder if that
> Am 09.12.2020 um 20:04 schrieb Sven Van Asbroeck :
>
> On Wed, Dec 9, 2020 at 1:16 PM H. Nikolaus Schaller
> wrote:
>>
>> This is also what made me wonder if that is really intended because then
>> the whole discussion about the cs-gpio-flags and inversion a
> Am 09.12.2020 um 18:36 schrieb Sven Van Asbroeck :
>
> On Wed, Dec 9, 2020 at 4:57 AM H. Nikolaus Schaller
> wrote:
>>
>> +
>> + device node | cs-gpio | CS pin state active | Note
>> + +===+=
Behavior of CS signal in combination of spi-cs-high and gpio descriptors
is not clearly defined and documented. So clarify the documentation
Cc: linus.wall...@linaro.org
Cc: linux-g...@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller
---
.../bindings/spi/spi-controller.yaml | 27
Hi Linus,
> Am 09.12.2020 um 09:38 schrieb Linus Walleij :
>
> On Sat, Dec 5, 2020 at 8:07 AM H. Nikolaus Schaller
> wrote:
>
>> I find it interesting that so far nobody wants to take responsibility
>> for a decision
> (...)
>
>
>>> What I can d
Hi Andreas,
> Am 09.12.2020 um 09:04 schrieb Andreas Kemnade :
>
> Hi,
>
> On Sat, 5 Dec 2020 08:04:25 +0100
> "H. Nikolaus Schaller" wrote:
>
>> Hi Linus,
>>
>>> Am 05.12.2020 um 01:25 schrieb Linus Walleij :
>>>
>&g
also be needed for OMAP44xx which has similar code
in omap4xxx_dt_clk_init, but I have not added this as I have no hardware
to test on.
Signed-off-by: David Shah
Signed-off-by: H. Nikolaus Schaller
---
drivers/clk/ti/clk-54xx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion
Hi Linus,
> Am 05.12.2020 um 01:25 schrieb Linus Walleij :
>
> On Fri, Dec 4, 2020 at 5:52 PM H. Nikolaus Schaller
> wrote:
>
>> But what I don't know is if I can omit spi-cs-high and have to keep
>> ACTIVE_HIGH (my revert patch) or also change to ACTIVE_
> Am 04.12.2020 um 20:19 schrieb Sven Van Asbroeck :
>
> On Fri, Dec 4, 2020 at 11:52 AM H. Nikolaus Schaller
> wrote:
>>
>>>> Anyways it is debatable if this is a bug at all. It is just a definition.
>>>
>>> I respectfully disagree
Hi Sven,
> Am 04.12.2020 um 14:46 schrieb Sven Van Asbroeck :
>
> On Fri, Dec 4, 2020 at 5:11 AM H. Nikolaus Schaller
> wrote:
>>
>> Anyways it is debatable if this is a bug at all. It is just a definition.
>
> I respectfully disagree. Prior to the fix, your
0, but is it really
the right thing?
Before submitting I would like to clarify the rules.
Especially since it is the same discussion as before:
https://lkml.org/lkml/2019/3/23/131
https://lkml.org/lkml/2019/3/24/2
> On Tue, Dec 1, 2020 at 12:13 PM H. Nikolaus Schaller
> wrote:
>>> A
> Am 01.12.2020 um 20:12 schrieb Andreas Kemnade :
>
> GTA04 uses that for controlling the td028ttec1 panel. So
> for easier testing/bisecting it is useful to have it
> enabled in the defconfig.
++
>
> Signed-off-by: Andreas Kemnade
> ---
> arch/arm/configs/omap2plus_defconfig | 1 +
> 1
Hi Sven,
> Am 01.12.2020 um 17:53 schrieb Sven Van Asbroeck :
>
> Hi Nikolaus,
>
> On Tue, Dec 1, 2020 at 11:43 AM H. Nikolaus Schaller
> wrote:
>>
>> You are right. It is active low.
>>
>
> In that case, we have a very simple solution, just remo
> Am 01.12.2020 um 17:44 schrieb Andreas Kemnade :
>
> On Tue, 1 Dec 2020 11:10:49 -0500
> Sven Van Asbroeck wrote:
>
>> Nikolaus,
>>
>> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
>> wrote:
>>>
>>> Let's work on a fix
> Am 01.12.2020 um 17:44 schrieb Andreas Kemnade :
>
> On Tue, 1 Dec 2020 11:10:49 -0500
> Sven Van Asbroeck wrote:
>
>> Nikolaus,
>>
>> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
>> wrote:
>>>
>>> Let's work on a fix
> Am 01.12.2020 um 16:52 schrieb Sven Van Asbroeck :
>
> Nikolaus,
>
> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
> wrote:
>>
>> Let's work on a fix for the fix now.
>
> I tested spi-gpio on my system, by converting a built-in or hardware
> Am 01.12.2020 um 17:20 schrieb Mark Brown :
>
> On Tue, Dec 01, 2020 at 03:20:12PM +0100, Linus Walleij wrote:
>
>> The reason why I shoot in the dark to convert all SPI
>> drivers to use GPIO descriptors instead of the global
>> GPIO numberspace is detailed in drivers/gpio/TODO
>> so I will
> Am 01.12.2020 um 17:10 schrieb Sven Van Asbroeck :
>
> Nikolaus,
>
> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
> wrote:
>>
>> Let's work on a fix for the fix now.
>>
>
> Are you quite sure the chip-select of the tpo,td028ttec1 panel
Hi Linus,
> Am 01.12.2020 um 15:20 schrieb Linus Walleij :
>
> Hi Nikolaus, Sven,
>
> the fault that the thing broke in the first place is all mine.
> Credit where credit is due!
>
> The reason why I shoot in the dark to convert all SPI
> drivers to use GPIO descriptors instead of the global
>
> Am 01.12.2020 um 13:16 schrieb Mark Brown :
>
> On Tue, Dec 01, 2020 at 09:59:43AM +0100, H. Nikolaus Schaller wrote:
>>> Am 30.11.2020 um 21:13 schrieb Sven Van Asbroeck :
>
>>> We knew that there was a chance that our fix would break something else.
>>
Hi Sven,
> Am 01.12.2020 um 13:41 schrieb Sven Van Asbroeck :
>
> On Tue, Dec 1, 2020 at 4:04 AM H. Nikolaus Schaller
> wrote:
>>
>> Then it should not have been applied to mainline but fully worked out and
>> tested.
Well I only complain because you wrote t
Hi Sven,
> Am 30.11.2020 um 21:13 schrieb Sven Van Asbroeck :
>
> Hi Nikolaus, thank you for reaching out !
>
> On Mon, Nov 30, 2020 at 2:06 PM H. Nikolaus Schaller
> wrote:
>>
>> But reverting your patch brings back the display. So it appears as if it
>>
Hi,
starting from v5.10-rc5 the SPI based panel of the GTA04 device is broken. It
uses
compatible = "spi-gpio"; [1] i.e. gpio descriptors very indirectly.
Bisect shows that it is commit
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
The commit description tells
> Am 08.11.2020 um 16:13 schrieb Zhou Yanjie :
>
>
> On 2020/11/8 下午10:35, H. Nikolaus Schaller wrote:
>>> Am 08.11.2020 um 13:46 schrieb Zhou Yanjie :
>>>
>>> Hello Nikolaus,
>>>
>>> On 2020/11/8 上午3:03, H. Nikolaus Schaller wro
> Am 08.11.2020 um 13:46 schrieb Zhou Yanjie :
>
> Hello Nikolaus,
>
> On 2020/11/8 上午3:03, H. Nikolaus Schaller wrote:
>>> Am 07.11.2020 um 12:52 schrieb 周琰杰 (Zhou Yanjie)
>>> :
>>>
>>> 1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG
> Am 07.11.2020 um 12:52 schrieb 周琰杰 (Zhou Yanjie) :
>
> 1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20.
> 2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752
> nodes for CU1000-Neo.
> 3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752
>
> Am 07.11.2020 um 12:52 schrieb 周琰杰 (Zhou Yanjie) :
>
> 1.Refresh defconfig of CI20 to support OTG and RNG.
> 2.Refresh defconfig of CU1000-Neo to support OTG/RNG/OST/SC16IS752.
> 3.Refresh defconfig of CU1830-Neo to support OTG/DTRNG/OST/SC16IS752.
>
> Tested-by: 周正 (Zhou Zheng)
>
Hi,
> Am 06.11.2020 um 09:58 schrieb Viresh Kumar :
>
> On 06-11-20, 09:44, H. Nikolaus Schaller wrote:
>>
>>> Am 06.11.2020 um 05:14 schrieb Viresh Kumar :
>>>
>>> On 06-11-20, 00:10, Andreas Kemnade wrote:
>>>> Hi,
>>>>
&g
> Am 06.11.2020 um 05:14 schrieb Viresh Kumar :
>
> On 06-11-20, 00:10, Andreas Kemnade wrote:
>> Hi,
>>
>> On the GTA04 (DM3730, devicetree omap3-gta04*) I get my console flooded
>> up with the following:
>> [ 24.517211] cpu cpu0: multiple regulators are not supported
>> [ 24.523040]
ping
> Am 03.10.2020 um 16:09 schrieb H. Nikolaus Schaller :
>
> * fix wrong pinmux offset preventing the user button from working
> * add uart connection for bluetooth wl1271 hci
>
> H. Nikolaus Schaller (2):
> ARM: dts: pandaboard: fix pinmux for gpio user button of Pand
* fix wrong pinmux offset preventing the user button from working
* add uart connection for bluetooth wl1271 hci
H. Nikolaus Schaller (2):
ARM: dts: pandaboard: fix pinmux for gpio user button of Pandaboard ES
ARM: dts: pandaboard es: add bluetooth uart for HCI
arch/arm/boot/dts/omap4-panda
The wl271 bluetooth uart is connected to uart2.
Setup a serdev uart child and separate bluetooth and uart2 pinmux
from wl12xx pinmux to better group the pins and muxes.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap4-panda-es.dts | 32
1 file changed
The pinmux control register offset passed to OMAP4_IOPAD is odd.
Fixes: ab9a13665e7c ("ARM: dts: pandaboard: add gpio user button")
Cc: sta...@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletio
>
> Tested-by: H. Nikolaus Schaller
> Tested-by: Paul Boddie
> Signed-off-by: 周琰杰 (Zhou Yanjie)
> ---
>
> Notes:
>v1->v2:
>No change.
>
>v2->v3:
>No change.
>
>v3->v4:
>Rebase on top of kernel 5.6-rc1.
>
>
Hi Pavel,
> Am 09.09.2020 um 00:56 schrieb Pavel Machek :
>
> Hi!
>
> It seems there is quite a lot of efforts porting kernel to various
> cellphones.
Yes, and it is sisyphos work to get it 100% into mainline... Most
projects I know about are at 99,5%.
>
> Librem 5 and PinePhone have their
Hi,
it seems as if your patch
34f379956e9d7 ("KVM: arm64: Fix symbol dependency in __hyp_call_panic_nvhe")
[ Upstream commit b38b298aa4397e2dc74a89b4dd3eac9e59b64c96 ]
fails to compile in v5.8.7 for me (using an aarch64 gcc 4.9 cross-toolchain to
try
to build a kernel for the PinePhone):
CC
Hi,
> Am 07.09.2020 um 16:22 schrieb Sasha Levin :
>
> On Mon, Sep 07, 2020 at 03:29:40PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> it seems as if your patch
>>
>> 34f379956e9d7 ("KVM: arm64: Fix symbol dependency in __hyp_
So IMHO this comment is misleading.
Otherwise,
Tested-by: H. Nikolaus Schaller
>
> Signed-off-by: David Shah
> ---
> arch/arm/boot/dts/omap5.dtsi | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/ar
Hi Tony,
> Am 29.07.2020 um 13:55 schrieb Tony Lindgren :
>
> * Tony Lindgren [200728 08:23]:
>> * H. Nikolaus Schaller [200727 20:51]:
>>> Hi Tony,
>>> after trying v5.8-rc7 the Pyra boot hangs after ca. 3 seconds
>>> (a little random what the
Hi Tony,
after trying v5.8-rc7 the Pyra boot hangs after ca. 3 seconds
(a little random what the last log line is).
I could bisect it to:
6cfcd5563b4fadbf49ba8fa481978e5e86d30322 is the first bad commit
commit 6cfcd5563b4fadbf49ba8fa481978e5e86d30322
Author: Tony Lindgren
Date: Mon Jul 13
Hi Alexandre,
> Am 06.07.2020 um 22:22 schrieb Alexandre GRIVEAUX :
>
> Le 06/07/2020 à 13:15, H. Nikolaus Schaller a écrit :
>> Hi Alexandre,
>>
>>> Am 05.07.2020 um 12:32 schrieb agrive...@deutnet.info:
>>>
>>> From: Alexandre GRIVEAUX
>&g
> Am 10.07.2020 um 12:27 schrieb Uwe Kleine-König
> :
>
> When commit 9017dc4fbd59 ("pwm: jz4740: Enhance precision in calculation
> of duty cycle") from v5.8-rc1 was backported to v5.4.x its dependency on
> commit ce1f9cece057 ("pwm: jz4740: Use clocks from TCU driver") was not
> noticed
> Am 10.07.2020 um 12:18 schrieb Uwe Kleine-König
> :
>
> On Fri, Jul 10, 2020 at 09:24:45AM +0200, H. Nikolaus Schaller wrote:
>> This reverts commit a6030d71e62d3e0e270bf3b7fb48d32a636732db.
>>
>> which was applied to v5.4.49. This ends in a compile issue:
&
ter include the required additional patches to define
the rate variable.
Fixes: a6030d71e62d ("pwm: jz4740: Enhance precision in calculation of duty
cycle")
Cc: sta...@vger.kernel.org # v5.4.49
Signed-off-by: H. Nikolaus Schaller
---
drivers/pwm/pwm-jz4740.c | 4 ++--
1 file changed,
Hi Alexandre,
> Am 05.07.2020 um 12:32 schrieb agrive...@deutnet.info:
>
> From: Alexandre GRIVEAUX
>
> Use brcm,bcm4329-fmac instead of brcm,bcm4330-fmac.
>
> Signed-off-by: Alexandre GRIVEAUX
> ---
> arch/mips/boot/dts/ingenic/ci20.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2
this code is run
on the build host.
Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line() helpers")
Co-developed-by: Masahiro Yamada
Signed-off-by: H. Nikolaus Schaller
---
scripts/mod/modpost.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff
> Am 28.06.2020 um 09:52 schrieb Masahiro Yamada :
>
> On Sun, Jun 28, 2020 at 3:17 PM H. Nikolaus Schaller
> wrote:
>>
>> Hi,
>>
>>> Am 28.06.2020 um 07:51 schrieb Masahiro Yamada :
>>>
>>> On Thu, Jun 25, 2020 at 5:47 PM H. Niko
Hi,
> Am 28.06.2020 um 07:51 schrieb Masahiro Yamada :
>
> On Thu, Jun 25, 2020 at 5:47 PM H. Nikolaus Schaller
> wrote:
>>
>> strsep() is neither standard C nor POSIX and used outside
>> the kernel code here. Using it here requires that the
>> build h
> Am 27.06.2020 um 15:55 schrieb Drew Fustini :
>
> These pins on the PocketBeagle P1 and P2 headers are connected to AM3358
> balls with gpio lines, and these pins are not used for any other
> peripherals by default. These GPIO lines are unclaimed and could be used
> by userspace program
). It does not
hurt kernel size or speed since this code is run on the build host.
Fixes: ac5100f5432967 ("modpost: add read_text_file() and get_line() helpers")
Signed-off-by: H. Nikolaus Schaller
---
scripts/mod/modpost.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff
ntime
autosuspend")
Cc: sta...@vger.kernel.org # v5.6+
Signed-off-by: H. Nikolaus Schaller
---
drivers/w1/masters/omap_hdq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index d363e2a89fdfc4..9f9ec108b18
If irq flags are not cleared for certain operations we
print an error message.
Since this should never occur in normal operation, this
patch is an optional safety-net and debugging tool.
Signed-off-by: H. Nikolaus Schaller
---
drivers/w1/masters/omap_hdq.c | 8
1 file changed, 8
Otherwise it will corrupt the console log during debugging.
Fixes: 7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.")
Cc: sta...@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller
---
drivers/w1/masters/omap_hdq.c | 10 +-
1 file changed, 5 insertions(+), 5
correctly, especially
hdq_write_byte(), hdq_read_byte(), omap_hdq_break().
Not tested is omap_w1_triplet().
Fixes: 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime
autosuspend")
Cc: sta...@vger.kernel.org # v5.6+
Signed-off-by: H. Nikolaus Schaller
---
drivers/w1/mas
This series fixes:
* some dev_dbg are missing an explicit \n
* wrong return value if battery is removed and no hdq response
* problems with resetting interrupt flags too early leading to timeouts and
wrong values
* print error if interrupt flags get mixed up
H. Nikolaus Schaller (4):
w1: omap
> Am 05.05.2020 um 17:53 schrieb Rob Herring :
>
> On Fri, Apr 24, 2020 at 10:34:04PM +0200, H. Nikolaus Schaller wrote:
>> The Imagination PVR/SGX GPU is part of several SoC from
>> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
>&g
Hi Tony,
> Am 03.05.2020 um 17:01 schrieb Tony Lindgren :
>
> * Paul Cercueil [200503 14:19]:
>> You have a new SoC with a SGX, and you only need to enable one clock to get
>> it to work. So you create a devicetree node which receives only one clock.
>>
>> Turns out, that the bootloader was
Hi Paul & Paul,
> Am 03.05.2020 um 18:41 schrieb H. Nikolaus Schaller :
>
> Hi Paul and Paul,
>
>> Am 03.05.2020 um 16:18 schrieb Paul Cercueil :
>>
>>
>>
>> Le dim. 3 mai 2020 à 15:31, H. Nikolaus Schaller a
>> écrit :
>>&g
resend from correct mail address
---
Hi Tony,
I am observing an issue with omap3-isp for a while. It seems
to have started with v5.6 but I have preferred to invest some
time into analysis of the problem instead of trying a bisect.
The problem is that there is a
[ 32.483703] WARNING: CPU: 0
Hi Tony,
> Am 29.04.2020 um 23:38 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [200429 21:35]:
>> I have reworked the way the spinlocks, setting and resetting
>> of the hdq_irqstatus bits are done and now it works right from
>> start of boot. Without any time
so that the driver can load by matching the device tree
if compiled as module.
Cc: sta...@vger.kernel.org # v5.3+
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 1 +
1 file
Hi Paul and Paul,
> Am 03.05.2020 um 16:18 schrieb Paul Cercueil :
>
>
>
> Le dim. 3 mai 2020 à 15:31, H. Nikolaus Schaller a écrit
> :
>> Hi Paul,
>>> Am 03.05.2020 um 14:52 schrieb Paul Cercueil :
>>>>> It's possible to forb
Hi Paul,
> Am 03.05.2020 um 14:52 schrieb Paul Cercueil :
>
>>> It's possible to forbid the presence of the 'clocks' property on some
>>> implementations, and require it on others.
>> To be precise we have to specify the exact number of clocks (between 0 and
>> 4) for every architecture.
>>
Hi Paul,
> Am 26.04.2020 um 15:11 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller a
> écrit :
>> The Imagination PVR/SGX GPU is part of several SoC from
>> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, I
Hi,
> Am 25.04.2020 um 12:37 schrieb H. Nikolaus Schaller :
>
>
>> Am 25.04.2020 um 12:29 schrieb H. Nikolaus Schaller :
>>
>> H
>> The things start to get "fixed" when the hdq_isr
>> jumps to 6 indicating
>>
>> OMAP_HDQ_INT_STAT
Hi Paul,
> Am 26.04.2020 um 14:50 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller a
> écrit :
>> Add SGX GPU node with interrupt. Tested on PandaBoard ES.
>> Since omap4420/30/60 and omap4470 come with dif
> Am 23.10.2019 um 00:19 schrieb Tony Lindgren :
>
> * Adam Ford [191022 19:01]:
>> On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren wrote:
>>>
>>> Hi,
>>>
>>> * Adam Ford [191007 15:06]:
The some in the OMAP3 family have a bandgap thermal sensor, but
omap2plus has it disabled.
> Am 22.10.2019 um 17:36 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191022 15:12]:
>> Hm. How should that work? Some SoC have the sgx544 as single
>> core and others as dual core. This imho does not fit into
>> the "img,sgx544-$revision" scheme
> Am 21.10.2019 um 19:13 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191018 20:28]:
>> Since v4.7 the dma initialization requires that there is a
>> device tree property for "rx" and "tx" channels which is
>> not provided by the pd
> Am 21.10.2019 um 16:30 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191019 18:43]:
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
>>
>&g
Just a meta-comment...
> Am 21.10.2019 um 12:15 schrieb Alexandre Belloni
> :
>
> Hi,
>
> The subject line is weird, how is it related to rc5t583?
>
> On 21/10/2019 07:41:04+0200, Andreas Kemnade wrote:
>> config RTC_DRV_S35390A
>> tristate "Seiko Instruments S-35390A"
>> select
wl1251 and wl1271 have different vendor id and device id.
So we need to handle both with sdio quirks.
Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller
Cc: # 4.11.0
---
drivers/mmc/core/quirks.h | 7 +++
1 file
and there was
no interface registration.
This patch defines separate constants to be used by sdio quirks
and drivers.
Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller
Cc: # 4.11.0
---
include/linux/mmc/sdio_ids.h | 2 ++
1 file
.
The new code checks for a DT child node compatible to wl1251
so it will not affect other MMC3 use cases.
Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting
DMA channel")
Signed-off-by: H. Nikolaus Schaller
Cc: # 4.7.0
---
drivers/mmc/host/omap_hs
The standard method for sdio devices connected to
an sdio interface is to define them as a child node
like we can see with wlcore.
Signed-off-by: H. Nikolaus Schaller
Acked-by: Kalle Valo
---
.../bindings/net/wireless/ti,wl1251.txt | 26 +++
1 file changed, 26 insertions
1 - 100 of 2084 matches
Mail list logo
