On Fri, Dec 07, 2018 at 09:19:24AM +0100, Geert Uytterhoeven wrote:
> Hi David,
>
> Thanks for your answer!
>
> On Fri, Dec 7, 2018 at 2:44 AM David Gibson
> wrote:
> > On Thu, Dec 06, 2018 at 01:56:45PM +0100, Geert Uytterhoeven wrote:
> > > Some early revisions of SoCs may have hardware bugs
Hi Uwe, Laurent,
Thank you very much for your patches!
I tested patches and both codes work correctly.
> From: Laurent Pinchart, Sent: Monday, December 10, 2018 5:55 AM
>
> Hi Uwe,
>
> On Friday, 7 December 2018 23:49:32 EET Uwe Kleine-König wrote:
> > Hello,
> >
> > while looking at the driver
Hi Uwe,
> From: Uwe Kleine-König, Sent: Friday, December 7, 2018 7:46 PM
>
> Hello,
>
> On Fri, Dec 07, 2018 at 10:57:48AM +0100, Geert Uytterhoeven wrote:
> > > Is the documentation for this hardware publically available?
> >
> > Please check Section 59 of the "User's Manual: Hardware" at
> > h
Hi Uwem
Thank you for your review!
> From: Uwe Kleine-Konig, Sent: Friday, December 7, 2018 6:14 PM
>
> On Fri, Dec 07, 2018 at 05:29:33PM +0900, Yoshihiro Shimoda wrote:
> > +static void rcar_pwm_workaround_output_low(struct rcar_pwm_chip *rp)
> > +{
> > + /*
> > +* This PWM Timer cannot
Hi Shimoda-san,
Thank you for the patches.
On Friday, 7 December 2018 10:29:28 EET Yoshihiro Shimoda wrote:
> This patch adds support for PWM "atomic" API.
>
> This patch also adds a workaround to output "pseudo" low level.
> Otherwise, the PWM backlight driver doesn't work correctly, especially
On Mon, Oct 15, 2018 at 12:55:17PM +0200, Wolfram Sang wrote:
> Update the comment because we don't set the pointer to NULL anymore.
> Also use the correct pointer name 'dma_ops' instead of 'dma_map_ops'.
>
> Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in
> arm_iommu_detach_device(
Hi Uwe,
On Friday, 7 December 2018 23:49:32 EET Uwe Kleine-König wrote:
> Hello,
>
> while looking at the driver I noticed another patch opportunity: In
> rcar_pwm_get_clock_division() there is a loop:
>
> for (div = 0; div <= RCAR_PWM_MAX_DIVISION; div++) {
> max = (unsigned
DU channels are routed to DPAD outputs in an SoC-dependent way. The
routing can be fixed (e.g. DU3 to DPAD0 on H3) or configurable (e.g. DU0
or DU1 to DPAD0 on D3/E3). The hardware offers no option to disconnect
DPAD outputs, which are thus always driven by a DU channel.
On SoCs that have less DU
Hi Kieran,
On Friday, 7 December 2018 14:34:58 EET Kieran Bingham wrote:
> On 25/11/2018 14:40, Laurent Pinchart wrote:
> > The rcar_du_crtc outputs field stores a bitmask of the outputs driven by
> > the CRTC. This changes based on the configuration requested by
> > userspace, and is used for the
> I understand, but what is the use case behind it ? If the watchdog
I'll leave this discussion to Fabrizio...
> I'd rather clarify in the documentation that watchdog drivers are expected
> to ping the watchdog after resume, ie that restarting the watchdog after
> resume should be handled like s
On 12/9/18 8:36 AM, Wolfram Sang wrote:
Hi Guenter,
I can relate to the policy argument, though. Regardless of this patch, I
wonder if we can make it configurable from userspace. A draft:
#define WDIOF_RESUME_OPTS 0x0800
#define WDIOS_RESUME_KEEP 0x0008
#define WDIOS_RESUME_RESET
Hi Guenter,
> > I can relate to the policy argument, though. Regardless of this patch, I
> > wonder if we can make it configurable from userspace. A draft:
> >
> > #define WDIOF_RESUME_OPTS 0x0800
> >
> > #define WDIOS_RESUME_KEEP 0x0008
> > #define WDIOS_RESUME_RESET
On 12/07/2018 02:13 PM, Mason Yang wrote:
> This Renesas R-Car Gen3 RPC SPI driver is based on Boris's new
> spi-mem direct mapping read/write mode [1][2].
>
> v3 patch is according to Marek and Geert's comments including:
> 1) soc_device_mach() to set up RPC_PHYCNT_STRTIM.
> 2) get_unaligned()
>
13 matches
Mail list logo
