Re: Can we re-use dw-hdmi-ahb-audio ?

Hi Mark > > dw-hdmi-audio.c : dw-hdmi audio common function set > > dw-hdmi-ahb-audio.c : dw-hdmi audio for ahb, using dw-hdmi-audio.c > > dw-hdmi-soc-audio.c : dw-hdmi audio for ASoC, using dw-hdmi-audio.c > > Something similar has been done for other things like the PXA drivers

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

Hi Wolfram, On Monday 18 Apr 2016 11:33:20 Wolfram Sang wrote: > > Whether we want a clock to influence its parent is policy, not hardware > > description. So IMHO it doesn't belong in DT. > > Yeah, I agree to that. > > > IMHO it's more worthwhile to convert r8a7740 to use the CPG/MSSR driver.

Re: [PATCH 0/4] ASoC: add graph base connection on simple-card

On Thu, Apr 14, 2016 at 05:45:41AM +, Kuninori Morimoto wrote: > Hi Mark > > Current simple-card is using "sound-dai" base connection on DT, > but V4L2 is using graph base connection. > For example HDMI case, we would like to use both connection. > To above confusable connection method, and

[PATCH v2 1/2] ARM: dts: r8a7793: Add SDHI controllers

Same as on r8a7791. Signed-off-by: Ulrich Hecht --- arch/arm/boot/dts/r8a7793.dtsi | 36 1 file changed, 36 insertions(+) diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi index 6843f46..aea9294

[PATCH v2 2/2] ARM: dts: gose: Enable SDHI controllers

Includes regulator and pin assignments. Signed-off-by: Ulrich Hecht --- arch/arm/boot/dts/r8a7793-gose.dts | 119 + 1 file changed, 119 insertions(+) diff --git a/arch/arm/boot/dts/r8a7793-gose.dts

[PATCH v2 0/2] ARM: dts: r8a7793/gose: enable SDHI

This enables SDHI on the Gose board, including pins and regulators. This revision includes the missing dma-names and power-domains entries spotted by Sergei and Simon. CU Uli Ulrich Hecht (2): ARM: dts: r8a7793: Add SDHI controllers ARM: dts: gose: Enable SDHI controllers

Re: [PATCH v5 03/11] soc: renesas: rcar-sysc: Add DT support for SYSC PM domains

On 18 April 2016 at 15:39, Geert Uytterhoeven wrote: > Hi Ulf, > > On Mon, Apr 18, 2016 at 2:59 PM, Geert Uytterhoeven > wrote: >> On Mon, Apr 18, 2016 at 2:21 PM, Ulf Hansson wrote: >>> [...] >>> + +static bool

Re: [PATCH v5 03/11] soc: renesas: rcar-sysc: Add DT support for SYSC PM domains

Hi Ulf, On Mon, Apr 18, 2016 at 2:21 PM, Ulf Hansson wrote: > [...] > >> + >> +static bool rcar_sysc_active_wakeup(struct device *dev) >> +{ >> + return true; > > I am interested to know why this is always returning true. Perhaps you > can elaborate a bit on that?

Re: [PATCH v5 03/11] soc: renesas: rcar-sysc: Add DT support for SYSC PM domains

[...] > + > +static bool rcar_sysc_active_wakeup(struct device *dev) > +{ > + return true; I am interested to know why this is always returning true. Perhaps you can elaborate a bit on that? > +} > + > +static int rcar_sysc_pd_power_off(struct generic_pm_domain *genpd) > +{ > +

Re: [PATCH v3 5/7] media: rcar-vin: add DV timings support

Hi Ulrich, This isn't right: this just overwrites the adv7180 input with an HDMI input. I assume the intention is to have support for both adv7180 and HDMI input and to use VIDIOC_S_INPUT to select between the two. This really needs some more work, I'm afraid. Regards, Hans On

Re: [PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver

Hi Niklas, Thanks for the patch. I've been testing this a bit more and there are a few things missing. On 04/12/2016 04:33 PM, Niklas Söderlund wrote: > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c > b/drivers/media/platform/rcar-vin/rcar-v4l2.c > new file mode 100644 > index

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Whether we want a clock to influence its parent is policy, not hardware > description. So IMHO it doesn't belong in DT. Yeah, I agree to that. > IMHO it's more worthwhile to convert r8a7740 to use the CPG/MSSR driver. > There it can be handled easily by adding a flag to the mssr_mod_clk

Re: [PATCH] ARM: shmobile: r8a7790: fix max-frequency for SDHI

On Sun, Apr 17, 2016 at 2:50 PM, Wolfram Sang wrote: > From: Wolfram Sang > > The wrong values come from an old datasheet. Fix them. > > Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven

Re: [PATCH 2/6] mmc: sh_mobile_sdhi: remove obsolete irq_by_name registration

On 6 April 2016 at 11:25, Wolfram Sang wrote: > From: Wolfram Sang > > There is no user left in the kernel, so this code can be removed. > (Legacy, non-DT sh_mobile boards have been removed a while ago.) The > diff looks more complicated than

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

Hi Wolfram, On Mon, Apr 18, 2016 at 10:09 AM, Wolfram Sang wrote: >> Hence I think it should be handled in the driver. > > I knew it ;) > > If we change the MSTP driver, we should do it in a generic way. MSTP > clocks which should/should not change the parent's clock rate can

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Hence I think it should be handled in the driver. I knew it ;) If we change the MSTP driver, we should do it in a generic way. MSTP clocks which should/should not change the parent's clock rate can be anywhere. My best bet so far would be encoding this in DT, because all the heuristics I

[PATCH 3/5] usb: renesas_usbhs: change function call orfer in usbhsf_dma_prepare_push()

Since usbhsf_dma_{un}map() will use the "fifo" data in the near future, this patch changes function call orfer in usbhsf_dma_prepare_push(). Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c | 12 ++-- 1 file changed, 6

[PATCH 5/5] usb: renesas_usbhs: use usb_gadget_{un}map_request_by_dev() for IPMMU

The previous code could use the first USB-DMAC with IPMMU if iommus property was set into this device node. However, in this case, it could not control the second USB-DMAC with IPMMU because a parameter of IPMMU (micro-TLB id) is different with each USB-DMAC. So, this patch uses the

[PATCH 4/5] usb: renesas_usbhs: change arguments of dma_map_ctrl()

Since usbhsg_dma_map_ctrl() needs DMA device structure in the near future, this patch changes arguments of dma_map_ctrl() to give such data. (This patch is only change the argument.) Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c |

[PATCH 2/5] usb: gadget: udc: core: add usb_gadget_{un}map_request_by_dev()

If the following environment, the first argument of DMA API should be set to a DMAC's device structure, not a udc controller's one. - A udc controller needs an external DMAC device (like a DMA Engine). - The external DMAC enables IOMMU. So, this patch add usb_gadget_{un}map_request_by_dev() API

[PATCH 1/5] usb: gadget: udc: core: Fix argument of dev_err() in usb_gadget_map_request()

The argument of dev_err() in usb_gadget_map_request() should be dev instead of >dev. Fixes: 7ace8fc ("usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU") Cc: # v4.3+ Signed-off-by: Yoshihiro Shimoda ---

[PATCH 0/5] usb: gadget: add new APIs of udc-core and modify renesas_usbhs for IPMMU

This patch set is based on the latest Felipe's usb.git / testing/next branch. (The commit id = 578bfe42fc37d588effe0d9fcd5e35e10d3d2e78) Changes from RFC: - rebase the latest commit of Felipe's usb.git. - revise commit log in patch 3 and 4. About the RFC patch set:

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

On Mon, 18 Apr 2016 02:43:21 + Kuninori Morimoto wrote: > But can I ask something ? > > > > > My concern is if audio side need to care/support "formal" graph style, > > > > I think all cpu/codec/card driver (and soc-core too ?) need to be > > > > updated,

Re: [PATCH v2 2/9] mmc: tmio, sh_mobile_sdhi: Add support for variable input clock frequency

On Sun, Apr 17, 2016 at 2:49 PM, Wolfram Sang wrote: > On Fri, Apr 15, 2016 at 10:41:57PM +0200, Wolfram Sang wrote: >> > > That seems like a bug in the clock driver. If it doesn't have >> > > independent dividers for each clock client then it shouldn't allow any >> > >

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

Hi Wolfram, On Mon, Apr 18, 2016 at 8:46 AM, Wolfram Sang wrote: >> Can you please give more detail about this r8a7740 issue? Just >> "r8a7740 flaw" does not make me understand. > > Ah, sorry. This RFC series was merely meant as a "right direction?" > series for Geert, thus

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Can you please give more detail about this r8a7740 issue? Just > "r8a7740 flaw" does not make me understand. Ah, sorry. This RFC series was merely meant as a "right direction?" series for Geert, thus the short CC list. The full series will have better documentation. The flaw is: On r8a7740,