[PATCH] ezchip: nps_enet: check if napi has been completed
After a new NAPI_STATE_MISSED state was added to NAPI we can get into
this state and in such case we have to reschedule NAPI as some work is
still pending and we have to process it. napi_complete_done() function
returns false if we have to reschedule something (e.g. in case we were
in MISSED state) as current polling have not been completed yet.
nps_enet driver hasn't been verifying the return value of
napi_complete_done() and has been forcibly enabling interrupts. That is
not correct as we should not enable interrupts before we have processed
all scheduled work. As a result we were getting trapped in interrupt
hanlder chain as we had never been able to disabale ethernet
interrupts again.
So this patch makes nps_enet_poll() func verify return value of
napi_complete_done() and enable interrupts only in case all scheduled
work has been completed.
Signed-off-by: Vlad Zakharov
---
drivers/net/ethernet/ezchip/nps_enet.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index 992ebe9..f819843 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -189,11 +189,9 @@ static int nps_enet_poll(struct napi_struct *napi, int
budget)
nps_enet_tx_handler(ndev);
work_done = nps_enet_rx_handler(ndev);
- if (work_done < budget) {
+ if ((work_done < budget) && napi_complete_done(napi, work_done)) {
u32 buf_int_enable_value = 0;
- napi_complete_done(napi, work_done);
-
/* set tx_done and rx_rdy bits */
buf_int_enable_value |= NPS_ENET_ENABLE << RX_RDY_SHIFT;
buf_int_enable_value |= NPS_ENET_ENABLE << TX_DONE_SHIFT;
--
2.7.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver
Hi Stephen, Michael, On Fri, 2017-03-03 at 15:50 -0800, Stephen Boyd wrote: > On 03/03, Vlad Zakharov wrote: > > > > Hi Michael, Stephen, > > > > On Tue, 2017-02-21 at 16:11 +0300, Vlad Zakharov wrote: > > > > > > AXS10X boards manages it's clocks using various PLLs. These PLL has same > > > dividers and corresponding control registers mapped to different > > > addresses. > > > So we add one common driver for such PLLs. > > > > > > Each PLL on AXS10X board consist of three dividers: IDIV, FBDIV and > > > ODIV. Output clock value is managed using these dividers. > > > > > > We add pre-defined tables with supported rate values and appropriate > > > configurations of IDIV, FBDIV and ODIV for each value. > > > > > > As of today we add support for PLLs that generate clock for the > > > following devices: > > > * ARC core on AXC CPU tiles. > > > * ARC PGU on ARC SDP Mainboard. > > > and more to come later. > > > > > > Acked-by: Rob Herring > > > Signed-off-by: Vlad Zakharov > > > Signed-off-by: Jose Abreu > > > Cc: Michael Turquette > > > Cc: Stephen Boyd > > > Cc: Mark Rutland > > > > Maybe you have any comments or remarks about this patch? And if you don't > > could you please apply it. > > > > I haven't reviewed it yet. The merge window is upon us right now > so I'll probably get to going through the queue this weekend/next > week. > Please treat this message as a polite reminder to review my patch. It is required for some subsystems on our boards, e.g. for ARC PGU. Thanks. -- Best regards, Vlad Zakharov ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
Hi Liviu, Rob,
On Fri, 2017-03-03 at 18:21 +, liviu.du...@arm.com wrote:
> On Fri, Mar 03, 2017 at 05:48:19PM +, Alexey Brodkin wrote:
> >
> > Hi Liviu,
> >
> > On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > >
> > > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > > >
> > > >
> > > > - /* find the encoder node and initialize it */
> > > > - encoder_node = of_parse_phandle(drm->dev->of_node,
> > > > "encoder-slave", 0);
> > > > - if (encoder_node) {
> > > > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > > > - of_node_put(encoder_node);
> > > > + /* There is only one output port inside each device, find it */
> > > > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > > > +
> > > > + if (port) {
> > > > + if (of_device_is_available(port))
> > > > + encoder = of_graph_get_remote_port_parent(port);
> > > > + of_node_put(port);
> > > > + }
> > >
> > > You must've been looking at some old version. Current version in -next
> > > uses
> > > of_graph_get_remote_node() to replace all those lines you have added (see
> > > Rob
> > > Herring's series to introduce of_graph_get_remote_node() function)
> >
> > Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to
> > date :)
> > Still I made a check of linux-next and don't see any changes in
> > "drivers/gpu/drm/arm" compared to Linus' tree.
> >
> > [1]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_torvalds_linux.git_commit_drivers_gpu_drm_arm-3Fid-3D
> > e4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4La2
> > T1SzSEiiP7hc_XsRahEc&s=uaswjVXcjYDrUosOkO_UpTMqJMWTT-LLPrg5JE6-t-8&e=
> > [2]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_next_linux-2Dnext.git_commit_drivers_gpu_drm_arm-3Fid
> > -3De4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4
> > La2T1SzSEiiP7hc_XsRahEc&s=hl9Y6s3K9LwLL1M2WnL3ODax_V-ZRh8k1iTiyctIqU4&e=
> >
> > Could you please clarify which exact tree did you mean?
>
> Sorry, I thought the series got pulled by one of the DRM trees, but it looks
> like
> I was wrong. I was carrying a private copy in my internal tree, waiting for
> the
> moment when it got pulled into drm-next or drm-misc-next.
>
> Rob, do you have an update on your series introducing
> of_graph_get_remote_node() ?
For some reason I cannot find any relevant commits in linux-next tree even
today.
Could you please point me to either any random git tree with mentioned above
change or
maybe just mailing list where this patch was sent?
I'd like to implement the same fix in ARCPGU and call it a day finally.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
Hi Vineet, Rob,
On 20-03-2017 14:02, Jose Abreu wrote:
> Hi Vineet, Alexey, Rob,
>
>
> On 02-03-2017 18:57, Alexey Brodkin wrote:
>> Hi Jose,
>>
>> On Wed, 2017-02-22 at 18:19 +, Jose Abreu wrote:
>>> This patch adds the necessary DT bindings to get HDMI audio
>>> output in ARC AXS10x SDP. The bindings for I2S controller were
>>> added as well as the bindings for simple audio card.
>>>
>>> Signed-off-by: Jose Abreu
>>> Cc: Carlos Palminha
>>> Cc: Alexey Brodkin
>>> Cc: Rob Herring
>>> Cc: Vineet Gupta
>>> Cc: devicet...@vger.kernel.org
>>> Cc: linux-snps-arc@lists.infradead.org
>>> Cc: linux-ker...@vger.kernel.org
>>> ---
>>> arch/arc/boot/dts/axs10x_mb.dtsi | 22 ++
>>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi
>>> b/arch/arc/boot/dts/axs10x_mb.dtsi
>>> index d6c1bbc..9d882b1 100644
>>> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
>>> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
>>> @@ -149,12 +149,13 @@
>>> interrupts = <14>;
>>> };
>>>
>>> - i2c@0x1e000 {
>>> - compatible = "snps,designware-i2c";
>>> + i2s: i2s@1e000 {
>>> + compatible = "snps,designware-i2s";
>>> reg = <0x1e000 0x100>;
>>> - clock-frequency = <40>;
>>> - clocks = <&i2cclk>;
>>> + clocks = <&i2sclk 0>;
>>> + clock-names = "i2sclk";
>>> interrupts = <15>;
>>> + #sound-dai-cells = <0>;
>>> };
>>>
>>> i2c@0x1f000 {
>>> @@ -174,6 +175,7 @@
>>> adi,input-colorspace = "rgb";
>>> adi,input-clock = "1x";
>>> adi,clock-delay = <0x03>;
>>> + #sound-dai-cells = <0>;
>>>
>>> ports {
>>> #address-cells = <1>;
>>> @@ -295,5 +297,17 @@
>>> };
>>> };
>>> };
>>> +
>>> + sound_playback {
>>> + compatible = "simple-audio-card";
>>> + simple-audio-card,name = "AXS10x HDMI Audio";
>>> + simple-audio-card,format = "i2s";
>>> + simple-audio-card,cpu {
>>> + sound-dai = <&i2s>;
>>> + };
>>> + simple-audio-card,codec {
>>> + sound-dai = <&adv7511>;
>>> + };
>>> + };
>>> };
>>> };
>> Just for the sake of history that's my mods to defconfig that allowed me
>> to play .pcm via HDMI from axs103 board:
>> >8---
>> diff --git a/arch/arc/configs/axs103_smp_defconfig
>> b/arch/arc/configs/axs103_smp_defconfig
>> index 30a3d4cf53d2..b11362a32e4e 100644
>> --- a/arch/arc/configs/axs103_smp_defconfig
>> +++ b/arch/arc/configs/axs103_smp_defconfig
>> @@ -67,25 +67,29 @@ CONFIG_MOUSE_PS2_TOUCHKIT=y
>> CONFIG_MOUSE_SERIAL=y
>> CONFIG_MOUSE_SYNAPTICS_USB=y
>> # CONFIG_LEGACY_PTYS is not set
>> -# CONFIG_DEVKMEM is not set
>> CONFIG_SERIAL_8250=y
>> CONFIG_SERIAL_8250_CONSOLE=y
>> CONFIG_SERIAL_8250_DW=y
>> CONFIG_SERIAL_OF_PLATFORM=y
>> # CONFIG_HW_RANDOM is not set
>> -CONFIG_I2C=y
>> CONFIG_I2C_CHARDEV=y
>> CONFIG_I2C_DESIGNWARE_PLATFORM=y
>> # CONFIG_HWMON is not set
>> -CONFIG_DRM=m
>> -CONFIG_DRM_I2C_ADV7511=m
>> -CONFIG_DRM_ARCPGU=m
>> -CONFIG_FB=y
>> +CONFIG_DRM=y
>> +CONFIG_DRM_I2C_ADV7511=y
>> +CONFIG_DRM_I2C_ADV7511_AUDIO=y
>> +CONFIG_DRM_ARCPGU=y
>> CONFIG_FRAMEBUFFER_CONSOLE=y
>> CONFIG_LOGO=y
>> # CONFIG_LOGO_LINUX_MONO is not set
>> # CONFIG_LOGO_LINUX_VGA16 is not set
>> # CONFIG_LOGO_LINUX_CLUT224 is not set
>> +CONFIG_SOUND=y
>> +CONFIG_SND=y
>> +CONFIG_SND_SOC=y
>> +CONFIG_SND_DESIGNWARE_I2S=y
>> +CONFIG_SND_DESIGNWARE_PCM=y
>> +CONFIG_SND_SIMPLE_CARD=y
>> CONFIG_USB_EHCI_HCD=y
>> CONFIG_USB_EHCI_HCD_PLATFORM=y
>> CONFIG_USB_OHCI_HCD=y
>> >8---
>>
>> Anyways...
>>
>> Acked-by: Alexey Brodkin
> Rob, can you please take a look at this patch and at 2/2?
>
> Alexey, do you still maintain your ack in these patches? (I'm
> asking because I remember you were having no video after patch
> 2/2 of this series). If so, Vineet, can you please pick this up
> and patch 2/2 also?
>
> Best regards,
> Jose Miguel Abreu
>
> ___
> linux-snps-arc mailing list
> linux-snps-arc@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=05dGD6sUxxlAGDQnPi7nAbNEBEAQb-u7BnZFDdL6TwI&s=NSYlH7VAuvW7bJx6m50UgCpZmyvijw__WBWmn39sh6Y&e=
>
Gentle ping :)
Best regards,
Jose Miguel Abreu
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
On Wed, Mar 29, 2017 at 01:34:00PM +, Alexey Brodkin wrote:
> Hi Liviu, Rob,
Hi Alexey,
>
> On Fri, 2017-03-03 at 18:21 +, liviu.du...@arm.com wrote:
> > On Fri, Mar 03, 2017 at 05:48:19PM +, Alexey Brodkin wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > > >
> > > > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > > > >
> > > > >
> > > > > - /* find the encoder node and initialize it */
> > > > > - encoder_node = of_parse_phandle(drm->dev->of_node,
> > > > > "encoder-slave", 0);
> > > > > - if (encoder_node) {
> > > > > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > > > > - of_node_put(encoder_node);
> > > > > + /* There is only one output port inside each device, find it */
> > > > > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > > > > +
> > > > > + if (port) {
> > > > > + if (of_device_is_available(port))
> > > > > + encoder = of_graph_get_remote_port_parent(port);
> > > > > + of_node_put(port);
> > > > > + }
> > > >
> > > > You must've been looking at some old version. Current version in -next
> > > > uses
> > > > of_graph_get_remote_node() to replace all those lines you have added
> > > > (see Rob
> > > > Herring's series to introduce of_graph_get_remote_node() function)
> > >
> > > Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to
> > > date :)
> > > Still I made a check of linux-next and don't see any changes in
> > > "drivers/gpu/drm/arm" compared to Linus' tree.
> > >
> > > [1]
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_torvalds_linux.git_commit_drivers_gpu_drm_arm-3Fid-3D
> > > e4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4La2
> > > T1SzSEiiP7hc_XsRahEc&s=uaswjVXcjYDrUosOkO_UpTMqJMWTT-LLPrg5JE6-t-8&e=
> > > [2]
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_next_linux-2Dnext.git_commit_drivers_gpu_drm_arm-3Fid
> > > -3De4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4
> > > La2T1SzSEiiP7hc_XsRahEc&s=hl9Y6s3K9LwLL1M2WnL3ODax_V-ZRh8k1iTiyctIqU4&e=
> > >
> > > Could you please clarify which exact tree did you mean?
> >
> > Sorry, I thought the series got pulled by one of the DRM trees, but it
> > looks like
> > I was wrong. I was carrying a private copy in my internal tree, waiting for
> > the
> > moment when it got pulled into drm-next or drm-misc-next.
> >
> > Rob, do you have an update on your series introducing
> > of_graph_get_remote_node() ?
>
> For some reason I cannot find any relevant commits in linux-next tree even
> today.
> Could you please point me to either any random git tree with mentioned above
> change or
> maybe just mailing list where this patch was sent?
Not sure why Rob hasn't added it to linux-next, but (according to Rob) this is
the latest version:
https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=of-graph-helpers
Best regards,
Liviu
>
> I'd like to implement the same fix in ARCPGU and call it a day finally.
>
> -Alexey
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ezchip: nps_enet: check if napi has been completed
On Wed, 2017-03-29 at 13:41 +0300, Vlad Zakharov wrote:
> After a new NAPI_STATE_MISSED state was added to NAPI we can get into
> this state and in such case we have to reschedule NAPI as some work is
> still pending and we have to process it. napi_complete_done() function
> returns false if we have to reschedule something (e.g. in case we were
> in MISSED state) as current polling have not been completed yet.
>
> nps_enet driver hasn't been verifying the return value of
> napi_complete_done() and has been forcibly enabling interrupts. That is
> not correct as we should not enable interrupts before we have processed
> all scheduled work. As a result we were getting trapped in interrupt
> hanlder chain as we had never been able to disabale ethernet
> interrupts again.
>
> So this patch makes nps_enet_poll() func verify return value of
> napi_complete_done() and enable interrupts only in case all scheduled
> work has been completed.
>
> Signed-off-by: Vlad Zakharov
> ---
> drivers/net/ethernet/ezchip/nps_enet.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
> b/drivers/net/ethernet/ezchip/nps_enet.c
> index 992ebe9..f819843 100644
> --- a/drivers/net/ethernet/ezchip/nps_enet.c
> +++ b/drivers/net/ethernet/ezchip/nps_enet.c
> @@ -189,11 +189,9 @@ static int nps_enet_poll(struct napi_struct *napi, int
> budget)
>
> nps_enet_tx_handler(ndev);
> work_done = nps_enet_rx_handler(ndev);
> - if (work_done < budget) {
> + if ((work_done < budget) && napi_complete_done(napi, work_done)) {
> u32 buf_int_enable_value = 0;
>
> - napi_complete_done(napi, work_done);
> -
> /* set tx_done and rx_rdy bits */
> buf_int_enable_value |= NPS_ENET_ENABLE << RX_RDY_SHIFT;
> buf_int_enable_value |= NPS_ENET_ENABLE << TX_DONE_SHIFT;
Seems fine, but looking at this driver, it looks it has some races,
trying to be a bit too smart.
nps_enet_irq_handler() really should be simpler, or the risk of missing
an interrupt might be high.
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index
992ebe973d25bfbccff7b5c42dc1801ea41fc9ea..03885ac0c0f845805eadb4659302b5c11bb250f6
100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -233,14 +233,11 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void
*dev_instance)
{
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
- u32 rx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
- u32 rx_ctrl_cr = (rx_ctrl_value & RX_CTL_CR_MASK) >> RX_CTL_CR_SHIFT;
- if (nps_enet_is_tx_pending(priv) || rx_ctrl_cr)
- if (likely(napi_schedule_prep(&priv->napi))) {
- nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
- __napi_schedule(&priv->napi);
- }
+ if (likely(napi_schedule_prep(&priv->napi))) {
+ nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
+ __napi_schedule(&priv->napi);
+ }
return IRQ_HANDLED;
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ezchip: nps_enet: check if napi has been completed
From: Vlad Zakharov Date: Wed, 29 Mar 2017 13:41:46 +0300 > After a new NAPI_STATE_MISSED state was added to NAPI we can get into > this state and in such case we have to reschedule NAPI as some work is > still pending and we have to process it. napi_complete_done() function > returns false if we have to reschedule something (e.g. in case we were > in MISSED state) as current polling have not been completed yet. > > nps_enet driver hasn't been verifying the return value of > napi_complete_done() and has been forcibly enabling interrupts. That is > not correct as we should not enable interrupts before we have processed > all scheduled work. As a result we were getting trapped in interrupt > hanlder chain as we had never been able to disabale ethernet > interrupts again. > > So this patch makes nps_enet_poll() func verify return value of > napi_complete_done() and enable interrupts only in case all scheduled > work has been completed. > > Signed-off-by: Vlad Zakharov Applied. Eric, if this is really required now, we have 148 broken drivers still. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ezchip: nps_enet: check if napi has been completed
On Wed, Mar 29, 2017 at 2:30 PM, David Miller wrote: Signed-off-by: Vlad Zakharov > > Applied. > > Eric, if this is really required now, we have 148 broken drivers still. Piece of cake :/ If we get more reports like that, we might implement a logic to prevent infinite loops. It is not clear to me what exactly happened to this driver, since testing napi_complete_done() was not mandatory. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arcv2: Make sure busy bit is set properly on SLC flushing
On 03/29/2017 07:15 AM, Alexey Brodkin wrote: > As reported in STAR 9001165532 if data cache gets disabled right before > L2 cache invalidation we may read wrong value of L2 cache "busy" bit. > So we won't wait before L2 cache gets properly flushed and so some > data might not reach DDR at all thus we'll use older values from DDR > next time they are accessed. > > For now we use a work-around with one extra read from SLC's control > register which guarantees next read will return real value of "busy" > bit. > > Signed-off-by: Alexey Brodkin Thx Alexey - pushed to for-curr ! > --- > arch/arc/mm/cache.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c > index d408fa21a07c..899f1d6b3560 100644 > --- a/arch/arc/mm/cache.c > +++ b/arch/arc/mm/cache.c > @@ -633,6 +633,9 @@ noinline static void slc_entire_op(const int op) > > write_aux_reg(ARC_REG_SLC_INVALIDATE, 1); > > + /* Make sure "busy" bit reports correct stataus, see STAR 9001165532 */ > + read_aux_reg(r); > + > /* Important to wait for flush to complete */ > while (read_aux_reg(r) & SLC_CTRL_BUSY); > } ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
