From: Kuninori Morimoto
Now we can replace Codec to Component. Let's do it.
Signed-off-by: Kuninori Morimoto
---
sound/soc/intel/boards/kbl_da7219_max98357a.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a
Hi Mark
These are new added driver on mark/for-next branch,
but based on old "codec" framework.
We want to convert it to component. These patches are do it
Kuninori Morimoto (4):
ASoC: intel: kbl_da7219_max98357: replace codec to component
ASoC: amd: acp-da7219-max98357: replac
Hi Stephen
Thank you for your report.
It seems added new drivers are not based on new framework.
I will post fixup patch for these.
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_d
Hi Mark
> > Thank you for reporting.
> > It is my fault, this patch might cause other issue.
> > I'm asking to Mark to remove it from his branch.
>
> Dropped.
Thank you !
Best regards
---
Kuninori Morimoto
Hi Stephen
Thank you for reporting.
It is my fault, this patch might cause other issue.
I'm asking to Mark to remove it from his branch.
> After merging the sound-asoc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> /home/sfr/next/next/sound/soc/soc-core.c: In fu
moving things to use components rather than
> CODEC/platform/whatever driver types that was sent about the same time
> has just gone in - the driver will require the same conversions.
Thank you for pointing it.
I posted conversion patch for this driver.
Best regards
---
Kuninori Morimoto
initialized in
> this function [-Wmaybe-uninitialized]
>reg |= WM9081_DAC_MUTE;
>
> Introduced by commit
>
> 48c338764296 ("ASoC: wm9081: replace codec to component")
Thank you for your report.
I posted fixup patch for it.
Best regards
---
Kuninori Morimoto
Hi Laurent
> Hi Morimoto-san,
>
> Thank you for your patch.
>
> On Thursday, 1 February 2018 09:45:36 EET Kuninori Morimoto wrote:
> > From: Kuninori Morimoto
> >
> > panel-lvds.c is for LVDS Panel Driver,
> > not R-Car Display Unit CRTCs
> >
&
From: Kuninori Morimoto
panel-lvds.c is for LVDS Panel Driver,
not R-Car Display Unit CRTCs
Reported-by: Koji Matsuoka
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/panel/panel-lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel
>
> So to fix the regression, let's just do a partial revert adding back
> the read and write function pointers. Note that other non-regmap
> ASoC drivers may need similar patches.
>
> Fixes: 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read on twl4030")
>
ormation). However we should
> be screaming loudly about the fact that the I/O we tried to do fails,
> that clearly shouldn't be being ignored.
I'm sorry that my patch breaks your drivers.
It seems removing .read/.write callback was too much aggressive.
I hope your driver will be OK by using regmap.
In worst case, we can back .read/.write, but it will be component driver side.
Best regards
---
Kuninori Morimoto
ponent or dev.
But sometimes, in some drivers, it seems can be difficult.
Sorry for my noise.
Best regards
---
Kuninori Morimoto
nt().
It will set component->regmap if you called devm_regmap_init_i2c().
I think you can use snd_soc_component_read/write instead of regmap_read/write.
Then, we can remove max98373->regmap too ?
Ahh, you want to check Revision ID.
then, snd_soc_component_init_regmap() can help you ?
Best regards
---
Kuninori Morimoto
() too for DMA address.
> Do you have any suggestion to address this issue?
I have no idea at this point.
Missing part for TDM (Ex) Split mode is not only DMA pointer.
Why do you want to use it ?
If you want to do is only "use 2 DAIs for playback",
how about to use MIXer ? It is al
>
> /* audio_clkout0/1/2/3 */
> #clock-cells = <1>;
> @@ -549,6 +559,9 @@
> playback = <&ssi0 &src0 &dvc0>;
> capture = <&ssi1 &src1 &dvc1>;
> };
> + dai1 {
> + playback = <&ssi0>;
> + };
> };
> };
>
> playing with dai1 will have issue.
I guess so because you are using strange settings...
What do you want to do ?
Best regards
---
Kuninori Morimoto
t;dma[is_play]);
>
> return ret;
> }
Some cases, same SSI might be used on different dai links.
In my understanding, it happen if you uses MIXer.
But, are you using same SSI for both playback and capture ??
Best regards
---
Kuninori Morimoto
makes
user confuse. Thus, I kept original number.
I'm happy if compiler can adjust it automatically,
if not, I have no objection to modify it but we want to have such comment ?
Because above comment/explain mentions about "fvco", not "fout".
> If you agree with these small changes there's no need to resubmit the patch,
> I'll modify it when applying, and
>
> Reviewed-by: Laurent Pinchart
Thank you for your help
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be la
From: Kuninori Morimoto
It is difficult to understand its scale if number has many 0s.
This patch uses "* 1000" to avoid it in rcar_du_dpll_divider().
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- no change
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 in
Hi Laurent, David
These are v4 of DPLLCR patch for rcar-du.
Mainly fixuped 2000 -> 2kHz to unambiguous
Kuninori Morimoto (2):
drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider()
drm: rcar-du: calculate DPLLCR to be more small jitter
drivers/gpu/drm/rcar
Hi Geert
> >> > From: Kuninori Morimoto
> >> > In general, PLL has VCO (= Voltage controlled oscillator),
> >> > one of the very important electronic feature called as "jitter"
> >> > is related to this VCO.
> >> > In academi
Hi Geert
> > From: Kuninori Morimoto
> > In general, PLL has VCO (= Voltage controlled oscillator),
> > one of the very important electronic feature called as "jitter"
> > is related to this VCO.
> > In academic generalism, VCO should be maximum to be
From: Kuninori Morimoto
In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be la
From: Kuninori Morimoto
It is difficult to understand its scale if number has many 0s.
This patch uses "* 1000" to avoid it in rcar_du_dpll_divider().
Signed-off-by: Kuninori Morimoto
---
v2 -> v3
- new patch
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 in
Hi Laurent, David
These are v3 of DPLLCR patch for rcar-du.
[1/2] is added
Kuninori Morimoto (2):
drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider()
drm: rcar-du: calculate DPLLCR to be more small jitter
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 60
, to force unsigned integer types ?
> > Or possibly even better, 4096 * 1000 * 1000UL to make it more readable ?
>
> If it's just about making the number unsigned, and not about 64-bit
> arithmetic,
> a "U" suffix should be sufficient.
Thanks.
Will try
Best regards
---
Kuninori Morimoto
for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
>
> The output frequency on the line below can be calculated with
>
> output = fvco / 2 / (fdpll + 1)
>
> to avoid the multiplication by (n + 1) and division by (m + 1).
It is nice idea to avoid extra calculation.
I will use this idea, and add extrate comment to avoid confusion
Best regards
---
Kuninori Morimoto
sessary period_pos
>
> Changes for v2:
> * Updated commit message
>
> sound/soc/sh/rcar/ssi.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
for all patches
Acked-by: Kuninori Morimoto
e_per_period,
> without any check internally.
>
> I am ok to remove this explanation from commit message,
> what do you think?
This function is used from PIO mode only now, and "byte" is sizeof(u32)
(Its size was "byte_per_period" when DMA mode used).
This "Further more" case never happen.
Removing from commit message is better for reader, IMO.
Best regards
---
Kuninori Morimoto
DMA mode
> No, we are using rcar sound in DMA mode,
> our original patch resolves the issue in core.c for both PIO & DMA mode.
>
> but with your commit a97a06c ("ASoC: rsnd: cleanup pointer related code"),
> DMA mode no longer has the race condition issue,
> so I ported our fix patch to only address the issue in PIO mode
Thanks. Nice to know.
Best regards
---
Kuninori Morimoto
strange for me...
Best regards
---
Kuninori Morimoto
increments buffer pointer atomically to avoid this issue.
>
> Signed-off-by: Jiada Wang
> Reviewed-by: Takashi Sakamoto
> ---
You using playback with PIO mode ?
Because this function is no longer used on DMA mode
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be la
Hi
I noticed 1 typo, 1 bug on this patch.
I will post v2 patch
> From: Kuninori Morimoto
>
> In general, PLL has VCO (= Voltage controlled oscillator),
> one of the very important electronic feature called as "jitter"
> is related to this VCO.
> In academic gener
From: Kuninori Morimoto
In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be la
From: Kuninori Morimoto
Signed-off-by: Kuninori Morimoto
---
Hi Stephen
Thank you for reporting.
I think your issue will be solved by this patch
sound/soc/soc-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 9047046..345baa4 100644
dc132f0 ("ASoC: rsnd: add TDM Extend Mode support")
>
> Signed-off-by: Jiada Wang
> ---
Thanks
Acked-by: Kuninori Morimoto
> > >> What's a typical number of loops needed before DE is really cleared?
> > >
> > > It case by case, but I don't want to use while(1) loop
> >
> > I understand that, and I agree wholeheartedly with limiting the number
> > of cycles.
>
> So do I, but I'd still like to know what the typical values are :-)
It can buffering max 8 requests.
1 request needs max 2 cycle to transfer.
2 cycle x 8 request x [4ns/cycle] = 64[ns] = 640usec
1024usec is enough :)
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below
From: Kuninori Morimoto
DMAC reads data from source device, and buffered it until transferable
size for sink device. Because of this behavior, DMAC is including
buffered data .
Now, CHCR DE bit is controlling DMA transfer enable/disable.
If DE bit was cleared during data transferring, or
Hi Vinod
Cc Geert, Laurent
These are v3 of dmaengine fixup for Renesas SoC.
Main diffs are fixup typo
Kuninori Morimoto (2):
dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clearing
dmaengine: rcar-dmac: use TCRB instead of TCR for residue
drivers/dma/sh/rcar-dmac.c | 44
Hi Geert
Thank you for your review, and test.
But where is my brown paper bag for English spell ?
>
> Hi Morimoto-san,
>
> On Thu, Nov 16, 2017 at 5:34 AM, Kuninori Morimoto
> wrote:
> > From: Kuninori Morimoto
>
> Thanks for your patch!
>
> > SYS/RT/
gt; What's a typical number of loops needed before DE is really cleared?
It case by case, but I don't want to use while(1) loop
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below
From: Kuninori Morimoto
DMAC reads data from source device, and buffered it until transferable
size for shink device. Because of this behavoir, DMAC is including
buffered data .
Now, CHCR DE bit is controlling DMA transfer enable/disable.
If DE bit was cleared during data transferring, or
ransfer bufferred data if DE was cleared, and then,
DE was 1 until finished.
I tested this patch with CONFIG_SERIAL_SH_SCI_DMA, and serial works correctly.
Kuninori Morimoto (2):
dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clear
dmaengine: rcar-dmac: use TCRB instead of TCR for residue
--
1.9.1
ndings/sound/audio-graph-card.txt | 1 +
> sound/soc/generic/audio-graph-card.c | 47
> ++
> 2 files changed, 40 insertions(+), 8 deletions(-)
For all patches
Acked-by: Kuninori Morimoto
Best regards
---
Kuninori Morimoto
tor-x
> > > > (renesas_defconfig).
> > > > Reverting that commit fixes the issue for me.
> >
> > Okay since we are close to merge window I can drop this patch for now,
> > unless we identify the fix very quickly
>
> I have not seen a resolution to th
From: Kuninori Morimoto
We already have renesas_usbhs_get_info() macro.
Let's use it.
Signed-off-by: Kuninori Morimoto
---
Shimoda-san
can you please check this patch ?
drivers/usb/renesas_usbhs/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driver
ps the code should use the minimum of both registers instead?
TCR(= read) happen 1st, and TCRB (= write) happen next.
"TCRB always contains 0x20" means, DMA didn't transfer data for some reason ?
"use minimum" idea can't guarantee data transfering, same as previous topic I
guess.
Best regards
---
Kuninori Morimoto
r large serial console input situation?
I will ask this to HW guys.
Thanks
Best regards
---
Kuninori Morimoto
rsnd_runtime_is_ssi_tdm(io) ? 0x1 : 0x0);
>
> Thanks for your suggestion,
> I will do some test for this change,
> if it works fine, I will submit ver2 with it
Thanks
Best regards
---
Kuninori Morimoto
* see
+* rsnd_ssi_config_init()
+*/
+ rsnd_mod_write(mod, SSI_MODE,
+ rsnd_runtime_is_ssi_tdm(io) ? 0x1 : 0x0);
if (rsnd_ssi_use_busif(io)) {
rsnd_mod_write(mod, SSI_BUSIF_ADINR,
Best regards
---
Kuninori Morimoto
residue counter which indicates transferred
from sound device, but in reality the data was not yet put to memory
and recorder will record it.
Signed-off-by: Hiroyuki Yokoyama
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto
---
v2 -> v3
- Code is back to same as v1
x27;d be happier with v3 :-)
Oops, I didn't explain this.
This DMAC has buffer. thus it will take a while for TCR and TCRB to
become equal. I will add this to log in v3
Best regards
---
Kuninori Morimoto
;m happy to create v3 patch which includes detail reason
which is explained by Laurent if you want.
Best regards
---
Kuninori Morimoto
; and it needs abouve explanation.
If so, I think v1 is enough... ?
"transfer completed count is important for all case" is no doubt... ?
Best regards
---
Kuninori Morimoto
or all case.
In any case, "completed" information should be used.
But in MEM_TO_DEV case, I thought if is OK if data was read from MEM
(= the data will be send to DEV automatically, I didn't care about interruption)
But yes, your opinion is correct I think.
I think MEM_TO_MEM should use TCRB.
I think logic is same as your MEM_TO_DEV explanation ?
Anyway, in all case I can use TCRB in v3 patch,
and it needs abouve explanation.
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
SYS/RT/Audio DMAC have both TCR/TCRB.
Its difference is transfer counter value of read (= TCR)
or write (= TCRB). The relationship is like below.
TCR TCRB
[SOURCE] -> [DMAC] -> [DESTINATION]
Thus, for residue calculation, we want to read
TCR
accurate"))
> >> >
> >> > Signed-off-by: Hiroyuki Yokoyama
> >> > [Kuninori: added detail information in log]
> >> > Signed-off-by: Kuninori Morimoto
> > (snip)
> >> However, shouldn't the register to use depend on the DMA directi
; >
> > Thus, we want to read TCRB instead of TCR for residue.
> > Otherwise, Sound Capture has noise after PluseAudio support
> > (= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate"))
> >
> > Signed-off-by: Hiroyuki Yokoyama
> > [Kuninori: adde
From: Kuninori Morimoto
SYS/RT/Audio DMAC have both TCR/TCRB register.
Its difference is transfer counter value of read (= TCR)
or write (= TCRB). The relationship is like below.
TCR TCRB
[SOURCE] -> [DMAC] -> [DESTINATION]
Thus, we want to read TCRB instead of TCR for r
s.
> > > Each entry is a pair of strings, the
> > > first being the connection's sink,
> > > the second being the connection's
> > > source. Valid names for sources.
> > It can
From: Kuninori Morimoto
Anton Volkov noticed that engine->dev is NULL before
of_dma_controller_register() in probe.
Thus there might be a NULL pointer dereference in
rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
is equal to (&dmac->engine)->dev.
On sa
_dmac_isr_channel() IRQ handler registration.
>
> Let's not commit a quick hack but fix the problem correctly, we should ensure
> that all the initialization needed by IRQ handlers is performed before they
> get registered.
Yeah, indeed.
We need v2 patch
Best regards
---
Kuninori Morimoto
the second being the connection's
> source. Valid names for sources.
It can be "see simple-audio-card.txt" same as other properties.
Not a big deal though
Acked-by: Kuninori Morimoto
> diff --git a/sound/soc/generic/simple-scu-card.c
> b/sound/
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
- not tested
drivers/of/property.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 06
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
- Not tested
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/dr
tch initialize dmac->engine before it.
Reported-by: Anton Volkov
Signed-off-by: Kuninori Morimoto
---
> Anton, Laurent
I created this patch because noone posted it yesterday.
Anton, you can use this patch and replace Author to you if you want.
Thus, I used [RFC] on this patch
driver
v which
> is equal to (&dmac->engine)->dev. Is this possible from your point of
> view?
Very rare case, but not impossible (?).
I think these engine->xxx initialize should be done before
of_dma_controller_register();
engine.channels is initialized independently somehow...
Best regards
---
Kuninori Morimoto
Hi Hans
> > From: Kuninori Morimoto
> >
> > Now, we can use of_graph_get_remote_endpoint(). Let's use it.
>
> I'm not sure why this is resent. It's part of a pending pull request
> so I expect it to be merged this week.
Sorry, I didn't k
From: Kuninori Morimoto
This driver's Copyright is under Renesas Solutions Corp.
This patch updates the year, because this driver was moved
into synopsys folder in 2017.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- update year 2016 -> 2017
drivers/gpu/drm/bridge/synopsys/
Hi Archit
> >> On 08/07/2017 07:41 AM, Kuninori Morimoto wrote:
> >>>
> >>> From: Kuninori Morimoto
> >>>
> >>> This driver's Copyright is under Renesas Solutions Corp
> >>
> >> Can we update the year to 20
Hi Archit
Thank you for your feedback
> On 08/07/2017 07:41 AM, Kuninori Morimoto wrote:
> >
> > From: Kuninori Morimoto
> >
> > This driver's Copyright is under Renesas Solutions Corp
>
> Can we update the year to 2017 while we're at it?
The ori
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/ti-vpe/cal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/cal.c
b/drivers/media/platfo
From: Kuninori Morimoto
This driver's Copyright is under Renesas Solutions Corp
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-au
_graph_get_port_parent()")
> Fixes: 2692c1c63c29 ("ASoC: add audio-graph-card support")
> Fixes: 1689333f8311 ("ASoC: simple-card-utils: add
> asoc_simple_card_parse_graph_dai()")
> Cc: Mark Brown
> Cc: Takashi Iwai
> Cc: Kuninori Morimoto
> Cc: al
fig taken from
> https://git.linaro.org/people/john.stultz/android-dev.git
> branch dev/hikey-mainline-WIP
>
> Signed-off-by: Antonio Borneo
> ---
I got kernel boot error on my board (= Renesas R-Car Salvator-X) +
CONFIG_OF_DYNAMIC.
This patch solved this issue.
Tested-by: Kuninori
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Sylwester Nawrocki
Acked-by: Benoit Parrot
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()&q
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/gpu/drm/rcar-d
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Sylwester Nawrocki
Acked-by: Benoit Parrot
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()&q
From: Kuninori Morimoto
This driver's Copyright is under Renesas Solutions Corp
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-au
each ODD, EVEN timing.
Before this patch, for example 1080i@60Hz, print complete indication
happen in 30Hz.
After this patch, in interlace case, indication coming 60Hz
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/media/platform/ti-vpe/cal.c | 2 +-
1
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
1
linux/sound/soc/fsl/mpc5200_dma.c:305:18: warning: unused variable \
psc_dma’ [-Wunused-variable]
Signed-off-by: Kuninori Morimoto
---
sound/soc/fsl/mpc5200_dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 93885d9
From: Kuninori Morimoto
This driver's Copyright is under Renesas Solutions Corp
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-au
fixup unsigned expression compared with zero:
main_rate
From: Kuninori Morimoto
CC: Linux-ALSA , Simon ,
Date: Fri, 16 Jun 2017 00:02:59 +
> sound/soc/sh/rcar/ssi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/s
From: Kuninori Morimoto
ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new .get_dai_id callback
on
0613 for today.
Thanks.
I posted this fixup patch few hours ago
To: Mark Brown
Subject: [PATCH] ASoC: simple_card_utils: add EXPORT_SYMBOL_GPL() for
asoc_simple_card_clk_xxx()
CC: Linux-ALSA , Simon ,
Date: Wed, 14 Jun 2017 01:04:11 +
Best regards
---
Kuninori Morimoto
o exchange port@1 as ID=0 for ALSA SoC ?
If so, we already has .of_xlate_dai_id callback for this purpose.
Does below help your issue ?
commit 73b17f1a65c881fcf97109d77056006da2d40152
commit a180e8b988437b3e84a1b501ac4d073467602ca6
Samplle codes are
linux/sound/soc/codecs/hdmi-codec.c :: hdmi_of_xlate_dai_id
https://patchwork.kernel.org/patch/9732285/ (I posted, but not yet
applied)
Best regards
---
Kuninori Morimoto
stand what's going on with the graph code this seems to
> make sense to me. How do we want to go about handling the patch?
This is comment to me ? or DRM maintainer ?
If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me
Best regards
---
Kuninori Morimoto
From: Kuninori Morimoto
In descriptor mode, the descriptor running pointer is not maintained
by the interrupt handler, thus, driver finds the running descriptor
from the descriptor pointer field in the CHCRB register.
But, CHCRB::DPTR indicates *next* descriptor pointer, not current.
Thus, The
Hi Colin
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King
> ---
Grr... I want to have brown paper bag
Acked-by: Kuninori Morimoto
> sound/soc/generic/audio-graph-card.c | 2 +-
> 1 file changed, 1
From: Kuninori Morimoto
ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new .get_dai_id callback
on
From: Kuninori Morimoto
ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new .get_dai_id callback
on
From: Kuninori Morimoto
DesignWare HDMI driver (= dw-hdmi) is supporting HDMI sound, and its
probe function was calling sound binding function multiple times as
same HDMI device different port.
Because of this behavior, commit 9731f82d601 ("ASoC: hdmi-codec: enable
multi probe for ...&
201 - 300 of 887 matches
Mail list logo
