* Re: [RFC,v3 7/9] media: platform: Add Mediatek ISP P1 device driver
From: Tomasz Figa @ 2019-08-06 9:47 UTC (permalink / raw)
To: Jungo Lin
Cc: devicetree, Sean Cheng (鄭昇弘),
Frederic Chen (陳俊元),
Rynn Wu (吳育恩), srv_heupstream, Rob Herring,
Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil, ddavenport,
Sj Huang, moderated list:ARM/Mediatek SoC support,
Laurent Pinchart, Matthias Brugger, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1564125828.1212.600.camel@mtksdccf07>
Hi Jungo,
On Fri, Jul 26, 2019 at 4:24 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
>
> Hi, Tomasz:
>
> On Thu, 2019-07-25 at 18:23 +0900, Tomasz Figa wrote:
> > .Hi Jungo,
> >
> > On Sat, Jul 20, 2019 at 6:58 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > >
> > > Hi, Tomasz:
> > >
> > > On Wed, 2019-07-10 at 18:56 +0900, Tomasz Figa wrote:
> > > > Hi Jungo,
> > > >
> > > > On Tue, Jun 11, 2019 at 11:53:42AM +0800, Jungo Lin wrote:
[snip]
> > > > > +
> > > > > + err_status = irq_status & INT_ST_MASK_CAM_ERR;
> > > > > +
> > > > > + /* Sof, done order check */
> > > > > + if ((irq_status & SOF_INT_ST) && (irq_status & HW_PASS1_DON_ST)) {
> > > > > + dev_dbg(dev, "sof_done block cnt:%d\n", isp_dev->sof_count);
> > > > > +
> > > > > + /* Notify IRQ event and enqueue frame */
> > > > > + irq_handle_notify_event(isp_dev, irq_status, dma_status, 0);
> > > > > + isp_dev->current_frame = hw_frame_num;
> > > >
> > > > What exactly is hw_frame_num? Shouldn't we assign it before notifying the
> > > > event?
> > > >
> > >
> > > This is a another spare register for frame sequence number usage.
> > > It comes from struct p1_frame_param:frame_seq_no which is sent by
> > > SCP_ISP_FRAME IPI command. We will rename this to dequeue_frame_seq_no.
> > > Is it a better understanding?
> >
> > I'm sorry, unfortunately it's still not clear to me. Is it the
> > sequence number of the frame that was just processed and returned to
> > the kernel or the next frame that is going to be processed from now
> > on?
> >
>
> It is the next frame that is going to be proceed.
> We simplify the implementation of isp_irq_cam function. The hw_frame_num
> is renamed to dequeue_frame_seq_no and saved this value from HW at
> SOF_INT_ST. Since it is obtained in SOF_INI_ST event, it means it is
> next frame to be processed. If there is SW_PASS1_DON_ST, it means this
> frame is processed done. We use this value to de-queue the frame request
> and return buffers to VB2.
>
> The normal IRQ sequence is SOF_INT_ST => SW_PASS1_DON_ST &
> HW_PASS1_DON_ST.
>
> a. SW_PASS_DON_ST is designed for DMAs done event.
> If there is no available DMA buffers en-queued into HW, there is no
> SW_PADD_DON_ST.
>
> b. HW_PASS_DON_ST is designed to trigger CQ buffer load procedure.
> It is paired with SOF IRQ event, even if there is no available DMA
> buffers.
>
> static void isp_irq_handle_sof(struct mtk_isp_p1_device *p1_dev,
> unsigned int dequeue_frame_seq_no)
> {
> dma_addr_t base_addr = p1_dev->composer_iova;
> int composed_frame_seq_no =
> atomic_read(&p1_dev->composed_frame_seq_no);
> unsigned int addr_offset;
>
> /* Send V4L2_EVENT_FRAME_SYNC event */
> mtk_cam_dev_event_frame_sync(&p1_dev->cam_dev, dequeue_frame_seq_no);
>
> p1_dev->sof_count += 1;
> /* Save dequeue frame information */
> p1_dev->dequeue_frame_seq_no = dequeue_frame_seq_no;
>
> /* Update CQ base address if needed */
> if (composed_frame_seq_no <= dequeue_frame_seq_no) {
> dev_dbg(p1_dev->dev,
> "SOF_INT_ST, no update, cq_num:%d, frame_seq:%d",
> composed_frame_seq_no, dequeue_frame_seq_no);
> return;
> }
> addr_offset = MTK_ISP_CQ_ADDRESS_OFFSET *
> (dequeue_frame_seq_no % MTK_ISP_CQ_BUFFER_COUNT);
> writel(base_addr + addr_offset, p1_dev->regs + REG_CQ_THR0_BASEADDR);
> dev_dbg(p1_dev->dev,
> "SOF_INT_ST, update next, cq_num:%d, frame_seq:%d cq_addr:0x%x",
> composed_frame_seq_no, dequeue_frame_seq_no, addr_offset);
> }
>
> void mtk_cam_dev_dequeue_req_frame(struct mtk_cam_dev *cam,
> unsigned int frame_seq_no)
> {
> struct mtk_cam_dev_request *req, *req_prev;
> unsigned long flags;
>
> spin_lock_irqsave(&cam->running_job_lock, flags);
> list_for_each_entry_safe(req, req_prev, &cam->running_job_list, list) {
> dev_dbg(cam->dev, "frame_seq:%d, de-queue frame_seq:%d\n",
> req->frame_params.frame_seq_no, frame_seq_no);
>
> /* Match by the en-queued request number */
> if (req->frame_params.frame_seq_no == frame_seq_no) {
> atomic_dec(&cam->running_job_count);
> /* Pass to user space */
> mtk_cam_dev_job_done(cam, req, VB2_BUF_STATE_DONE);
> list_del(&req->list);
> break;
> } else if (req->frame_params.frame_seq_no < frame_seq_no) {
> atomic_dec(&cam->running_job_count);
> /* Pass to user space for frame drop */
> mtk_cam_dev_job_done(cam, req, VB2_BUF_STATE_ERROR);
> dev_warn(cam->dev, "frame_seq:%d drop\n",
> req->frame_params.frame_seq_no);
> list_del(&req->list);
> } else {
> break;
> }
> }
> spin_unlock_irqrestore(&cam->running_job_lock, flags);
>
> static irqreturn_t isp_irq_cam(int irq, void *data)
> {
> struct mtk_isp_p1_device *p1_dev = (struct mtk_isp_p1_device *)data;
> struct device *dev = p1_dev->dev;
> unsigned int dequeue_frame_seq_no;
> unsigned int irq_status, err_status, dma_status;
> unsigned long flags;
>
> spin_lock_irqsave(&p1_dev->spinlock_irq, flags);
> irq_status = readl(p1_dev->regs + REG_CTL_RAW_INT_STAT);
> err_status = irq_status & INT_ST_MASK_CAM_ERR;
> dma_status = readl(p1_dev->regs + REG_CTL_RAW_INT2_STAT);
> dequeue_frame_seq_no = readl(p1_dev->regs + REG_FRAME_SEQ_NUM);
> spin_unlock_irqrestore(&p1_dev->spinlock_irq, flags);
>
> /*
> * In normal case, the next SOF ISR should come after HW PASS1 DONE
> ISR.
> * If these two ISRs come together, print warning msg to hint.
> */
> if ((irq_status & SOF_INT_ST) && (irq_status & HW_PASS1_DON_ST))
> dev_warn(dev, "sof_done block cnt:%d\n", p1_dev->sof_count);
>
> /* De-queue frame */
> if (irq_status & SW_PASS1_DON_ST) {
> mtk_cam_dev_dequeue_req_frame(&p1_dev->cam_dev,
> dequeue_frame_seq_no);
> mtk_cam_dev_req_try_queue(&p1_dev->cam_dev);
> }
>
> /* Save frame info. & update CQ address for frame HW en-queue */
> if (irq_status & SOF_INT_ST)
> isp_irq_handle_sof(p1_dev, dequeue_frame_seq_no);
>
> /* Check ISP error status */
> if (err_status) {
> dev_err(dev, "int_err:0x%x 0x%x\n", irq_status, err_status);
> /* Show DMA errors in detail */
> if (err_status & DMA_ERR_ST)
> isp_irq_handle_dma_err(p1_dev);
> }
>
> dev_dbg(dev, "SOF:%d irq:0x%x, dma:0x%x, frame_num:%d",
> p1_dev->sof_count, irq_status, dma_status,
> dequeue_frame_seq_no);
>
> return IRQ_HANDLED;
> }
I think I understand this now and the code above also looks good to
me. Thanks a lot!
>
> > >
> > > Below is our frame request handling in current design.
> > >
> > > 1. Buffer preparation
> > > - Combined image buffers (IMGO/RRZO) + meta input buffer (Tuining) +
> > > other meta histogram buffers (LCSO/LMVO) into one request.
> > > - Accumulated one unique frame sequence number to each request and send
> > > this request to the SCP composer to compose CQ (Command queue) buffer
> > > via SCP_ISP_FRAME IPI command.
> > > - CQ buffer is frame registers set. If ISP registers should be updated
> > > per frame, these registers are configured in the CQ buffer, such as
> > > frame sequence number, DMA addresses and tuning ISP registers.
> > > - One frame request will be composed into one CQ buffer.Once CQ buffer
> > > is composed done and kernel driver will receive ISP_CMD_FRAME_ACK with
> > > its corresponding frame sequence number. Based on this, kernel driver
> > > knows which request is ready to be en-queued and save this with
> > > p1_dev->isp_ctx.composed_frame_id.
> >
> > Hmm, why do we need to save this in p1_dev->isp_ctx? Wouldn't we
> > already have a linked lists of requests that are composed and ready to
> > be enqueued? Also, the request itself would contain its frame ID
> > inside the driver request struct, right?
> >
>
> Below is current implementation for frame request en-queued.
> Before en-queued into HW by CQ, the request should be composed by SCP
> composer.
>
> a. mtk_cam_dev_req_try_queue()
> - Insert the request into p1_dev->running_job_list
> b. mtk_isp_req_enqueue()
> - Assign new next frame ID to this request.
> - Sending to SCP by workqueue
> - This request is ready to compose
> c. isp_tx_frame_worker()
> - Send request to SCP with sync. mode. by SCP_IPI_ISP_FRAME command
> - SCP composer will compose the buffer CQ for this request frame based
> on struct mtk_p1_frame_param which includes frame ID.
> - If scp_ipi_send() is returned, it means the request is composed done.
> Or
> d. isp_composer_handler()
> - If we received the ISP_CMD_FRAME_ACK for SCP_IPI_ISP_FRAME, we save
> the frame ID in p1_dev->composed_frame_seq_no which is sent in step C.
> - The request is composed done here.
> e. isp_irq_handle_sof()
> - In SOF timing, we will check there is any available composed CQ
> buffers by comparing composed & current de-queued frame ID.
>
> For p1_dev->running_job_list, we can't guarantee the requests are
> composed until the end of step c. For step e, we need to know how many
> available composed requests are ready to en-queued.
>
> Do you suggest we add another new link-list to save these requests in
> step c or we could update p1_dev->composed_frame_seq_no in step c and
> remove the implementation in step d[1]?
Okay, thanks to your explanation above I think I understood how the
hardware flow behaves and so I think we can indeed keep the
composed_frame_seq counter. Thanks!
>
> [1]. isp_composer_handler() is mandatory callback function for SCP
> sending API with sync mode design.
>
> static void isp_composer_handler(void *data, unsigned int len, void
> *priv)
> {
> struct mtk_isp_p1_device *p1_dev = (struct mtk_isp_p1_device *)priv;
> struct mtk_isp_scp_p1_cmd *ipi_msg;
>
> ipi_msg = (struct mtk_isp_scp_p1_cmd *)data;
>
> if (ipi_msg->cmd_id != ISP_CMD_ACK)
> return;
>
> if (ipi_msg->ack_info.cmd_id == ISP_CMD_FRAME_ACK) {
> atomic_set(&p1_dev->composed_frame_seq_no,
> ipi_msg->ack_info.frame_seq_no);
> dev_dbg(p1_dev->dev, "ack frame_num:%d\n",
> p1_dev->composed_frame_seq_no);
> }
> }
>
> > > - The maximum number of CQ buffers in SCP is 3.
> > >
> > > 2. Buffer en-queue flow
> > > - In order to configure correct CQ buffer setting before next SQF event,
> > > it is depended on by MTK ISP P1 HW CQ mechanism.
> > > - The basic concept of CQ mechanism is loaded ISP CQ buffer settings
> > > when HW_PASS1_DON_ST is received which means DMA output is done.
> > > - Btw, the pre-condition of this, need to tell ISP HW which CQ buffer
> > > address is used. Otherwise, it will loaded one dummy CQ buffer to
> > > bypass.
> > > - So we will check available CQ buffers by comparing composed frame
> > > sequence number & dequeued frame sequence from ISP HW in SOF event.
> > > - If there are available CQ buffers, update the CQ base address to the
> > > next CQ buffer address based on current de-enqueue frame sequence
> > > number. So MTK ISP P1 HW will load this CQ buffer into HW when
> > > HW_PASS1_DON_ST is triggered which is before the next SOF.
> > > - So in next SOF event, ISP HW starts to output DMA buffers with this
> > > request until request is done.
> > > - But, for the first request, it is loaded into HW manually when
> > > streaming is on for better performance.
> > >
> > > 3. Buffer de-queue flow
> > > - We will use frame sequence number to decide which request is ready to
> > > de-queue.
> > > - We will save some important register setting from ISP HW when SOF is
> > > received. This is because the ISP HW starts to output the data with the
> > > corresponding settings, especially frame sequence number setting.
> >
> > Could you explain a bit more about these important register settings?
> > When does the hardware update the values in the register to new ones?
> > At SOF?
> >
>
> Sorry about my words.
> In the current implementation, we just save frame ID.
>
Ah, okay, makes sense. No worries. :)
>
> > > - When receiving SW_PASS1_DON_ST IRQ event, it means the DMA output is
> > > done. So we could call isp_deque_request_frame with frame sequence
> > > number to de-queue frame to VB2
> >
> > What's the difference between HW_PASS1_DON_ST and SW_PASS1_DON_ST?
> >
>
> This is explained above.
>
> > > - For AAO/AFO buffers, it has similar design concept. Sometimes, if only
> > > AAO/AFO non-request buffers are en-queued without request buffers at the
> > > same time, there will be no SW P1 done event for AAO/AFO DMA done.
> > > Needs to depend on other IRQ events, such as AAO/AFO_DONE_EVENT.
> >
> > Do we have a case like this? Wouldn't we normally always want to
> > bundle AAO/AFO buffers with frame buffers?
> >
>
> For upstream driver, we will remove non-request design.
>
I think we also talked about a thing related to this in the thread for
another patch from this series. Basically on Chrome OS we want to use
the upstream driver, so corresponding userspace changes might be
needed as well.
> > > - Due to CQ buffer number limitation, if we receive SW_PASS1_DONT_ST,
> > > we may try to send another request to SCP for composing.
> >
> > Okay, so basically in SW_PASS1_DONT_ST the CQ completed reading the CQ
> > buffers, right?
> >
>
> We expected the the life cycle of CQ buffer is same as frame request.
> So SW_PASS1_DON_ST is good timing to re-queue the next request to
> compose.
> For the CQ operations, we will explain later.
>
> > >
> > > Hopefully, my explanation is helpful for better understanding our
> > > implementation. If you still have any questions, please let me know.
> > >
> >
> > Yes, it's more clear now, thanks. Still some more comments above, though.
> >
> > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > + } else {
> > > > > + if (irq_status & SOF_INT_ST) {
> > > > > + isp_dev->current_frame = hw_frame_num;
> > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > + }
> > > > > + irq_handle_notify_event(isp_dev, irq_status, dma_status, 1);
> > > > > + }
> > > >
> > > > The if and else blocks do almost the same things just in different order. Is
> > > > it really expected?
> > > >
> > >
> > > If we receive HW_PASS1_DON_ST & SOF_INT_ST IRQ events at the same time,
> > > the correct sequence should be handle HW_PASS1_DON_ST firstly to check
> > > any de-queued frame and update the next frame setting later.
> > > Normally, this is a corner case or system performance issue.
> >
> > So it sounds like HW_PASS1_DON_ST means that all data from current
> > frame has been written, right? If I understand your explanation above
> > correctly, that would mean following handling of each interrupt:
> >
> > HW_PASS1_DON_ST:
> > - CQ executes with next CQ buffer to prepare for next frame. <- how
> > is this handled? does the CQ hardware automatically receive this event
> > from the ISP hadware?
> > - return VB2 buffers,
> > - complete requests.
> >
> > SOF_INT_ST:
> > - send VSYNC event to userspace,
> > - program next CQ buffer to CQ,
> >
> > SW_PASS1_DON_ST:
> > - reclaim CQ buffer and enqueue next frame to composing if available
> >
>
> Sorry for our implementation of HW_PASS1_DON_ST.
> It is confusing.
> Below is the revised version based on your conclusion.
> So in our new implemmenation, we just handle SOF_INT_ST &
> SW_PASS1_DON_ST events. We just add one warning message for
> HW_PASS1_DON_ST
>
> HW_PASS1_DON_ST:
> - CQ executes with next CQ buffer to prepare for next frame.
>
> SOF_INT_ST:
> - send VSYNC event to userspace,
> - program next CQ buffer to CQ,
>
> SW_PASS1_DON_ST:
> - reclaim CQ buffer and enqueue next frame to composing if available
> - return VB2 buffers,
> - complete requests.
>
> For CQ HW operations, it is listed below:
>
> a. The CQ buffer has two kinds of information
> - Which ISP registers needs to be updated.
> - Where the corresponding ISP register data to be read.
> b. The CQ buffer loading procedure is triggered by HW_PASS1_DONT_ST IRQ
> event periodically.
> - Normally, if the ISP HW receives the completed frame and it will
> trigger W_PASS1_DONT_ST IRQ and perform CQ buffer loading immediately.
> - So the CQ buffer loading is performed by ISP HW automatically.
> c. The ISP HW will read CQ base address register(REG_CQ_THR0_BASEADDR)
> to decide which CQ buffer is loaded.
> - So we configure the next CQ base address in SOF.
> d. For CQ buffer loading, CQ will read the ISP registers from CQ buffer
> and update the ISP register values into HW.
> - SCP composer will compose one dummy CQ buffer and assign it to
> REG_CQ_THR0_BASEADDR of each CQ buffer.
> - Dummy CQ buffer has no updated ISP registers comparing with other
> CQ buffers.
> - With this design, if there is no updated new CQ buffer by driver
> which may be caused no en-queue frames from user space. The CQ HW will
> load dummy CQ buffer and do nothing.
Does the set of registers programmed by CQ include destination buffer
addresses to? If yes, we would end up overwriting previous frames if
no new buffers are provided.
> f. The CQ buffer loading is guaranteed by HW to finish before the next
> SOF.
>
Okay, thanks a lot for the explanation. This is much more clear now.
[snip]
> > > > > +static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > > + SET_SYSTEM_SLEEP_PM_OPS(mtk_isp_suspend, mtk_isp_resume)
> > > > > + SET_RUNTIME_PM_OPS(mtk_isp_suspend, mtk_isp_resume, NULL)
> > > >
> > > > For V4L2 drivers system and runtime PM ops would normally be completely
> > > > different. Runtime PM ops would be called when the hardware is idle already
> > > > or is about to become active. System PM ops would be called at system power
> > > > state change and the hardware might be both idle or active. Please also see
> > > > my comments to mtk_isp_suspend() and mtk_isp_resume() above.
> > > >
> > >
> > > Here is the new implementation. It should be clear to show the
> > > difference between system and runtime PM ops.
> > >
> > > static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > > pm_runtime_force_resume)
> > > SET_RUNTIME_PM_OPS(mtk_isp_runtime_suspend, mtk_isp_runtime_resume,
> > > NULL)
> > > };
> >
> > That's still not correct. In runtime suspend/resume ops we already are
> > not streaming anymore, because we call pm_runtime_get/put_*() when
> > starting and stopping streaming. In system suspend/resume ops we might
> > be streaming and that's when we need to stop the hardware and wait for
> > it to finish. Please implement these ops separately.
> >
> > Best regards,
> > Tomasz
>
>
> Ok, got your point.
> Below is the new implementation for your review.
>
> static int mtk_isp_pm_suspend(struct device *dev)
> {
> struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> u32 val;
> int ret;
>
> dev_dbg(dev, "- %s\n", __func__);
>
> /* Check ISP is streaming or not */
> if (!p1_dev->cam_dev.streaming)
> goto done;
We would normally check here for pm_runtime_suspended(). Although they
both should be equivalent. Still, there is no need to call
pm_runtime_force_suspend() if the latter is true, so we could just
return 0 instantly.
>
> /* Disable ISP's view finder and wait for TG idle */
> dev_dbg(dev, "Cam suspend, disable VF\n");
> val = readl(p1_dev->regs + REG_TG_VF_CON);
> writel(val & (~TG_VF_CON_VFDATA_EN), p1_dev->regs + REG_TG_VF_CON);
> ret = readl_poll_timeout_atomic(p1_dev->regs + REG_TG_INTER_ST, val,
> (val & TG_CS_MASK) == TG_IDLE_ST,
> USEC_PER_MSEC, MTK_ISP_STOP_HW_TIMEOUT);
> if (ret)
> dev_warn(dev, "can't stop HW:%d:0x%x\n", ret, val);
>
> /* Disable CMOS */
> val = readl(p1_dev->regs + REG_TG_SEN_MODE);
> writel(val & (~TG_SEN_MODE_CMOS_EN), p1_dev->regs + REG_TG_SEN_MODE);
>
> done:
> /* Force ISP HW to idle */
> ret = pm_runtime_force_suspend(dev);
> if (ret)
> return ret;
>
> return 0;
> }
>
> static int mtk_isp_pm_resume(struct device *dev)
> {
> struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> u32 val;
> int ret;
>
> dev_dbg(dev, "- %s\n", __func__);
>
> /* Force ISP HW to resume if needed */
> ret = pm_runtime_force_resume(dev);
> if (ret)
> return ret;
We should do this conditionally based on what pm_runtime_suspended()
returns. If it's non-zero then we can just return 0 instantly.
>
> if (!p1_dev->cam_dev.streaming)
> return 0;
>
> /* Enable CMOS */
> dev_dbg(dev, "Cam resume, enable CMOS/VF\n");
> val = readl(p1_dev->regs + REG_TG_SEN_MODE);
> writel(val | TG_SEN_MODE_CMOS_EN, p1_dev->regs + REG_TG_SEN_MODE);
>
> /* Enable VF */
> val = readl(p1_dev->regs + REG_TG_VF_CON);
> writel(val | TG_VF_CON_VFDATA_EN, p1_dev->regs + REG_TG_VF_CON);
>
> return 0;
> }
>
> static int mtk_isp_runtime_suspend(struct device *dev)
> {
> struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
>
> dev_dbg(dev, "- %s\n", __func__);
>
> if (pm_runtime_suspended(dev))
> return 0;
Sorry, I guess I wasn't clear in my reply. It's not possible to get
this callback called if the device is already runtime suspended.
>
> dev_dbg(dev, "%s:disable clock\n", __func__);
> clk_bulk_disable_unprepare(p1_dev->num_clks, p1_dev->clks);
>
> return 0;
> }
>
> static int mtk_isp_runtime_resume(struct device *dev)
> {
> struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> int ret;
>
> dev_dbg(dev, "- %s\n", __func__);
>
> if (pm_runtime_suspended(dev))
> return 0;
In this case the above call would always return non-zero, so the
behavior wouldn't be very good.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: imx-ocotp: Add i.MX8MN compatible
From: Srinivas Kandagatla @ 2019-08-06 9:39 UTC (permalink / raw)
To: Anson.Huang, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <20190711023714.16000-1-Anson.Huang@nxp.com>
On 11/07/2019 03:37, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add compatible for i.MX8MN and add i.MX8MM/i.MX8MN to the description.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied both the patches.
Thanks,
srini
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 96ffd06..904dadf 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -2,7 +2,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL,
> -i.MX7D/S, i.MX7ULP and i.MX8MQ SoCs.
> +i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM and i.MX8MN SoCs.
>
> Required properties:
> - compatible: should be one of
> @@ -16,6 +16,7 @@ Required properties:
> "fsl,imx7ulp-ocotp" (i.MX7ULP),
> "fsl,imx8mq-ocotp" (i.MX8MQ),
> "fsl,imx8mm-ocotp" (i.MX8MM),
> + "fsl,imx8mn-ocotp" (i.MX8MN),
> followed by "syscon".
> - #address-cells : Should be 1
> - #size-cells : Should be 1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Daniel Vetter @ 2019-08-06 9:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, linux-kernel, dri-devel, Sean Paul, Rob Clark,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Allison Randal
In-Reply-To: <20190806084821.GA17129@lst.de>
On Tue, Aug 06, 2019 at 10:48:21AM +0200, Christoph Hellwig wrote:
> This goes in the wrong direction. drm_cflush_* are a bad API we need to
> get rid of, not add use of it. The reason for that is two-fold:
>
> a) it doesn't address how cache maintaince actually works in most
> platforms. When talking about a cache we three fundamental operations:
>
> 1) write back - this writes the content of the cache back to the
> backing memory
> 2) invalidate - this remove the content of the cache
> 3) write back + invalidate - do both of the above
>
> b) which of the above operation you use when depends on a couple of
> factors of what you want to do with the range you do the cache
> maintainance operations
>
> Take a look at the comment in arch/arc/mm/dma.c around line 30 that
> explains how this applies to buffer ownership management. Note that
> "for device" applies to "for userspace" in the same way, just that
> userspace then also needs to follow this protocol. So the whole idea
> that random driver code calls random low-level cache maintainance
> operations (and use the non-specific term flush to make it all more
> confusing) is a bad idea. Fortunately enough we have really good
> arch helpers for all non-coherent architectures (this excludes the
> magic i915 won't be covered by that, but that is a separate issue
> to be addressed later, and the fact that while arm32 did grew them
> very recently and doesn't expose them for all configs, which is easily
> fixable if needed) with arch_sync_dma_for_device and
> arch_sync_dma_for_cpu. So what we need is to figure out where we
> have valid cases for buffer ownership transfer outside the DMA
> API, and build proper wrappers around the above function for that.
> My guess is it should probably be build to go with the iommu API
> as that is the only other way to map memory for DMA access, but
> if you have a better idea I'd be open to discussion.
I just read through all the arch_sync_dma_for_device/cpu functions and
none seem to use the struct *dev argument. Iirc you've said that's on the
way out?
That dev parameter is another holdup for the places where we do not yet
know what the new device will be (e.g. generic dma-buf exporters like
vgem). And sprinkling a fake dev or passing NULL is a bit silly.
Add a HAVE_ARCH_SYNC_DMA and the above refactor (assuming it's ok to roll
out everywhere) and we should indeed be able to use this. We still need to
have all the others for x86 and all that. Plus I guess we should roll out
the split into invalidate and flush.
The other bit is phys vs. virt addr confusion, but looks like standard if
phys_addr and you kmap underneath (except from drm_clflush_virt_range,
only used by i915).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: imx8mq: Unregister clks when of_clk_add_provider failed
From: Daniel Baluta @ 2019-08-06 9:17 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Fancy Fang, mturquette@baylibre.com,
festevam@gmail.com, sboyd@kernel.org, Jacky Bai, Jun Li,
agx@sigxcpu.org, Abel Vesa, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, Anson Huang,
linux-clk@vger.kernel.org, Peng Fan, kernel@pengutronix.de,
Leonard Crestez, s.hauer@pengutronix.de
Cc: dl-linux-imx
In-Reply-To: <20190806064614.20294-2-Anson.Huang@nxp.com>
On Tue, 2019-08-06 at 14:46 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> When of_clk_add_provider failed, all clks should be unregistered.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> drivers/clk/imx/clk-imx8mq.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-
> imx8mq.c
> index 04302f2..81a0249 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -562,10 +562,18 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
> clk_data.clk_num = ARRAY_SIZE(clks);
>
> err = of_clk_add_provider(np, of_clk_src_onecell_get,
> &clk_data);
> - WARN_ON(err);
> + if (err < 0) {
> + dev_err(dev, "failed to register clks for i.MX8MQ\n");
> + goto unregister_clks;
> + }
>
> imx_register_uart_clocks(uart_clks);
>
> + return 0;
> +
> +unregister_clks:
> + imx_unregister_clocks(clks, ARRAY_SIZE(clks));
> +
> return err;
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 05/11] arm64: mm: Introduce VA_BITS_MIN
From: Steve Capper @ 2019-08-06 9:11 UTC (permalink / raw)
To: Catalin Marinas
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, maz@kernel.org,
bhsharma@redhat.com, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190805172000.GL4175@arrakis.emea.arm.com>
On Mon, Aug 05, 2019 at 06:20:01PM +0100, Catalin Marinas wrote:
> On Mon, Jul 29, 2019 at 05:21:11PM +0100, Steve Capper wrote:
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index f7f23e47c28f..0206804b0868 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -797,6 +797,10 @@ config ARM64_VA_BITS
> > default 47 if ARM64_VA_BITS_47
> > default 48 if ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52
> >
> > +config ARM64_VA_BITS_MIN
> > + int
> > + default ARM64_VA_BITS
> > +
> > choice
> > prompt "Physical address space size"
> > default ARM64_PA_BITS_48
> [...]
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 8b0f1599b2d1..a8a91a573bff 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -52,6 +52,9 @@
> > #define PCI_IO_END (VMEMMAP_START - SZ_2M)
> > #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
> > #define FIXADDR_TOP (PCI_IO_START - SZ_2M)
> > +#define VA_BITS_MIN (CONFIG_ARM64_VA_BITS_MIN)
>
> Thinking about it, do we actually need a Kconfig option for VA_BITS_MIN?
> Can we not just generated it here based on VA_BITS as min(48, VA_BITS)?
>
Thanks Catalin,
I'll get rid of the Kconfig option.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] clk: imx8mm: Unregister clks when of_clk_add_provider failed
From: Daniel Baluta @ 2019-08-06 9:09 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Fancy Fang, mturquette@baylibre.com,
festevam@gmail.com, sboyd@kernel.org, Jacky Bai, Jun Li,
agx@sigxcpu.org, Abel Vesa, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, Anson Huang,
linux-clk@vger.kernel.org, Peng Fan, kernel@pengutronix.de,
Leonard Crestez, s.hauer@pengutronix.de
Cc: dl-linux-imx
In-Reply-To: <20190806064614.20294-1-Anson.Huang@nxp.com>
On Tue, 2019-08-06 at 14:46 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> When of_clk_add_provider failed, all clks should be unregistered.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Thanks Anson for the patch!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 03/11] arm64: kasan: Switch to using KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-06 9:05 UTC (permalink / raw)
To: Catalin Marinas
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, maz@kernel.org,
bhsharma@redhat.com, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190805163720.GF4175@arrakis.emea.arm.com>
On Mon, Aug 05, 2019 at 05:37:21PM +0100, Catalin Marinas wrote:
> On Mon, Jul 29, 2019 at 05:21:09PM +0100, Steve Capper wrote:
> > diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arm64/kasan-offsets.sh
> > new file mode 100644
> > index 000000000000..2b7a021db363
> > --- /dev/null
> > +++ b/Documentation/arm64/kasan-offsets.sh
> > @@ -0,0 +1,27 @@
> > +#!/bin/sh
> > +
> > +# Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW
> > +# start address at the mid-point of the kernel VA space
> > +
> > +print_kasan_offset () {
> > + printf "%02d\t" $1
> > + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
> > + + (1 << ($1 - 32 - $2)) \
> > + - (1 << (64 - 32 - $2)) ))
> > +}
> > +
> > +echo KASAN_SHADOW_SCALE_SHIFT = 3
> > +printf "VABITS\tKASAN_SHADOW_OFFSET\n"
> > +print_kasan_offset 48 3
> > +print_kasan_offset 47 3
> > +print_kasan_offset 42 3
> > +print_kasan_offset 39 3
> > +print_kasan_offset 36 3
> > +echo
> > +echo KASAN_SHADOW_SCALE_SHIFT = 4
> > +printf "VABITS\tKASAN_SHADOW_OFFSET\n"
> > +print_kasan_offset 48 4
> > +print_kasan_offset 47 4
> > +print_kasan_offset 42 4
> > +print_kasan_offset 39 4
> > +print_kasan_offset 36 4
>
> Even better if this generated the Kconfig entry directly ;). Anyway,
> it's fine as it is.
:-)
>
>
> > diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> > index 05edfe9b02e4..9e68e3d12956 100644
> > --- a/arch/arm64/mm/kasan_init.c
> > +++ b/arch/arm64/mm/kasan_init.c
> > @@ -154,8 +154,6 @@ static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
> > /* The early shadow maps everything to a single page of zeroes */
> > asmlinkage void __init kasan_early_init(void)
> > {
> > - BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
> > - KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
>
> Can we not still keep a BUILD_BUG_ON() for KASAN_SHADOW_OFFSET around,
> even if it does the same calculation as the script?
>
Yeah sure, I'll retain this. The only reason I removed it was because I
thought that it was redundant.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Don't write junk to sysregs on reset
From: Zenghui Yu @ 2019-08-06 8:52 UTC (permalink / raw)
To: Marc Zyngier, kvm, kvmarm, linux-arm-kernel
Cc: Andrew Jones, James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <7b36f1dd-e44f-af75-0e51-8f6e705e81f6@kernel.org>
On 2019/8/6 16:35, Marc Zyngier wrote:
> On 06/08/2019 07:29, Zenghui Yu wrote:
>> Hi Marc,
>>
>> On 2019/8/5 20:15, Marc Zyngier wrote:
>>> At the moment, the way we reset system registers is mildly insane:
>>> We write junk to them, call the reset functions, and then check that
>>> we have something else in them.
>>>
>>> The "fun" thing is that this can happen while the guest is running
>>> (PSCI, for example). If anything in KVM has to evaluate the state
>>> of a system register while junk is in there, bad thing may happen.
>>>
>>> Let's stop doing that. Instead, we track that we have called a
>>> reset function for that register, and assume that the reset
>>> function has done something. This requires fixing a couple of
>>> sysreg refinition in the trap table.
>>>
>>> In the end, the very need of this reset check is pretty dubious,
>>> as it doesn't check everything (a lot of the sysregs leave outside of
>>> the sys_regs[] array). It may well be axed in the near future.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>
>> (Regardless of whether this check is needed or not,) I tested this patch
>> with kvm-unit-tests:
>>
>> for i in {1..100}; do QEMU=/path/to/qemu-system-aarch64 accel=kvm
>> arch=arm64 ./run_tests.sh; done
>>
>> And all the tests passed!
>
> Great! Can I take this as a 'Tested-by:'?
Yes, please add:
Tested-by: Zenghui Yu <yuzenghui@huawei.com>
Zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] arm64: dts: lx2160a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Lx2160a platform, the i2c input clock is actually platform pll CLK / 16
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 4720a8e..408e0ec 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -485,7 +485,7 @@
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
scl-gpio = <&gpio2 15 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -497,7 +497,7 @@
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -508,7 +508,7 @@
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -519,7 +519,7 @@
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -530,7 +530,7 @@
reg = <0x0 0x2040000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
scl-gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -542,7 +542,7 @@
reg = <0x0 0x2050000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -553,7 +553,7 @@
reg = <0x0 0x2060000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -564,7 +564,7 @@
reg = <0x0 0x2070000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: ls1028a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Ls1028a platform, the i2c input clock is actually platform pll CLK / 4
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06..cca7bfdb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -171,7 +171,7 @@
#size-cells = <0>;
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -181,7 +181,7 @@
#size-cells = <0>;
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -191,7 +191,7 @@
#size-cells = <0>;
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -201,7 +201,7 @@
#size-cells = <0>;
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -211,7 +211,7 @@
#size-cells = <0>;
reg = <0x0 0x2040000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -221,7 +221,7 @@
#size-cells = <0>;
reg = <0x0 0x2050000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -231,7 +231,7 @@
#size-cells = <0>;
reg = <0x0 0x2060000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -241,7 +241,7 @@
#size-cells = <0>;
reg = <0x0 0x2070000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Chuanhua Han
Ls1088a platform, the i2c input clock is actually platform pll CLK / 8
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 20f5ebd..30b760e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -324,7 +324,7 @@
#size-cells = <0>;
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -334,7 +334,7 @@
#size-cells = <0>;
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -344,7 +344,7 @@
#size-cells = <0>;
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -354,7 +354,7 @@
#size-cells = <0>;
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: ls1012a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Ls1012a platform, the i2c input clock is actually platform pll CLK / 4
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index ec6257a..124a7e2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -323,7 +323,7 @@
#size-cells = <0>;
reg = <0x0 0x2180000 0x0 0x10000>;
interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 0>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -333,7 +333,7 @@
#size-cells = <0>;
reg = <0x0 0x2190000 0x0 0x10000>;
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 0>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-06 8:48 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, linux-kernel, dri-devel, Sean Paul,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Christoph Hellwig, Allison Randal
In-Reply-To: <20190805211451.20176-1-robdclark@gmail.com>
This goes in the wrong direction. drm_cflush_* are a bad API we need to
get rid of, not add use of it. The reason for that is two-fold:
a) it doesn't address how cache maintaince actually works in most
platforms. When talking about a cache we three fundamental operations:
1) write back - this writes the content of the cache back to the
backing memory
2) invalidate - this remove the content of the cache
3) write back + invalidate - do both of the above
b) which of the above operation you use when depends on a couple of
factors of what you want to do with the range you do the cache
maintainance operations
Take a look at the comment in arch/arc/mm/dma.c around line 30 that
explains how this applies to buffer ownership management. Note that
"for device" applies to "for userspace" in the same way, just that
userspace then also needs to follow this protocol. So the whole idea
that random driver code calls random low-level cache maintainance
operations (and use the non-specific term flush to make it all more
confusing) is a bad idea. Fortunately enough we have really good
arch helpers for all non-coherent architectures (this excludes the
magic i915 won't be covered by that, but that is a separate issue
to be addressed later, and the fact that while arm32 did grew them
very recently and doesn't expose them for all configs, which is easily
fixable if needed) with arch_sync_dma_for_device and
arch_sync_dma_for_cpu. So what we need is to figure out where we
have valid cases for buffer ownership transfer outside the DMA
API, and build proper wrappers around the above function for that.
My guess is it should probably be build to go with the iommu API
as that is the only other way to map memory for DMA access, but
if you have a better idea I'd be open to discussion.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] clk: meson: g12a: add support for DVFS
From: Jerome Brunet @ 2019-08-06 8:38 UTC (permalink / raw)
To: Neil Armstrong, sboyd
Cc: linux-kernel, linux-amlogic, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190731084019.8451-1-narmstrong@baylibre.com>
On Wed 31 Jul 2019 at 10:40, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Neil Armstrong (4):
> clk: core: introduce clk_hw_set_parent()
> clk: meson: add g12a cpu dynamic divider driver
> clk: meson: g12a: add notifiers to handle cpu clock change
> clk: meson: g12a: expose CPUB clock ID for G12B
>
> drivers/clk/clk.c | 6 +
> drivers/clk/meson/Kconfig | 5 +
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/clk-cpu-dyndiv.c | 73 ++++
> drivers/clk/meson/clk-cpu-dyndiv.h | 20 +
> drivers/clk/meson/g12a.c | 535 +++++++++++++++++++++++---
> drivers/clk/meson/g12a.h | 1 -
> include/dt-bindings/clock/g12a-clkc.h | 1 +
> include/linux/clk-provider.h | 1 +
> 9 files changed, 588 insertions(+), 55 deletions(-)
> create mode 100644 drivers/clk/meson/clk-cpu-dyndiv.c
> create mode 100644 drivers/clk/meson/clk-cpu-dyndiv.h
Patchset looks good to me.
Waiting for Stephen's ack on patch #1 to apply it.
>
> --
> 2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/13] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
From: Heiko Stuebner @ 2019-08-06 8:36 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, Sean Paul, Sam Ravnborg, amd-gfx
Cc: David Airlie, dri-devel, linux-kernel, kernel,
David (ChunMing) Zhou, linux-samsung-soc, Joonyoung Shim,
Krzysztof Kozlowski, linux-rockchip, Kukjin Kim, Harry Wentland,
Leo Li, linux-arm-msm, intel-gfx, Jani Nikula, Inki Dae,
linux-mediatek, linux-tegra, linux-arm-kernel, Seung-Woo Kim,
Sandy Huang, Kyungmin Park, Daniel Vetter, Alex Deucher,
freedreno, Christian König
In-Reply-To: <e3058e1973c9c7649a0818450188b5c3db442b3e.1564591626.git.andrzej.p@collabora.com>
Am Mittwoch, 31. Juli 2019, 18:58:13 CEST schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/13] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
From: Heiko Stuebner @ 2019-08-06 8:36 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, amd-gfx, linux-kernel, Sean Paul
Cc: David (ChunMing) Zhou, linux-samsung-soc, linux-tegra,
linux-rockchip, Leo Li, linux-arm-msm, intel-gfx, freedreno,
Sandy Huang, dri-devel, David Airlie, linux-mediatek,
Daniel Vetter, Alex Deucher, kernel, Harry Wentland,
Christian König, linux-arm-kernel
In-Reply-To: <52272b8ebf403361ff96e04bf14f5a7389116f73.1564591626.git.andrzej.p@collabora.com>
Am Mittwoch, 31. Juli 2019, 18:58:14 CEST schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Don't write junk to sysregs on reset
From: Marc Zyngier @ 2019-08-06 8:35 UTC (permalink / raw)
To: Zenghui Yu, kvm, kvmarm, linux-arm-kernel
Cc: Andrew Jones, James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <01b74492-c59f-dfd9-e439-752e6b1c53dc@huawei.com>
On 06/08/2019 07:29, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/8/5 20:15, Marc Zyngier wrote:
>> At the moment, the way we reset system registers is mildly insane:
>> We write junk to them, call the reset functions, and then check that
>> we have something else in them.
>>
>> The "fun" thing is that this can happen while the guest is running
>> (PSCI, for example). If anything in KVM has to evaluate the state
>> of a system register while junk is in there, bad thing may happen.
>>
>> Let's stop doing that. Instead, we track that we have called a
>> reset function for that register, and assume that the reset
>> function has done something. This requires fixing a couple of
>> sysreg refinition in the trap table.
>>
>> In the end, the very need of this reset check is pretty dubious,
>> as it doesn't check everything (a lot of the sysregs leave outside of
>> the sys_regs[] array). It may well be axed in the near future.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> (Regardless of whether this check is needed or not,) I tested this patch
> with kvm-unit-tests:
>
> for i in {1..100}; do QEMU=/path/to/qemu-system-aarch64 accel=kvm
> arch=arm64 ./run_tests.sh; done
>
> And all the tests passed!
Great! Can I take this as a 'Tested-by:'?
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] scsi: fas216: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-08-06 8:29 UTC (permalink / raw)
To: Russell King, James E.J. Bottomley, Martin K. Petersen
Cc: Gustavo A. R. Silva, linux-scsi, linux-arm-kernel, linux-kernel
Mark switch cases where we are expecting to fall through.
Fix the following warnings (Building: rpc_defconfig arm):
drivers/scsi/arm/fas216.c: In function ‘fas216_disconnect_intr’:
drivers/scsi/arm/fas216.c:913:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (fas216_get_last_msg(info, info->scsi.msgin_fifo) == ABORT) {
^
drivers/scsi/arm/fas216.c:919:2: note: here
default: /* huh? */
^~~~~~~
drivers/scsi/arm/fas216.c: In function ‘fas216_kick’:
drivers/scsi/arm/fas216.c:1959:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
fas216_allocate_tag(info, SCpnt);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/arm/fas216.c:1960:2: note: here
case TYPE_OTHER:
^~~~
drivers/scsi/arm/fas216.c: In function ‘fas216_busservice_intr’:
drivers/scsi/arm/fas216.c:1413:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
fas216_stoptransfer(info);
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/arm/fas216.c:1414:2: note: here
case STATE(STAT_STATUS, PHASE_SELSTEPS):/* Sel w/ steps -> Status */
^~~~
drivers/scsi/arm/fas216.c:1424:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
fas216_stoptransfer(info);
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/arm/fas216.c:1425:2: note: here
case STATE(STAT_MESGIN, PHASE_COMMAND): /* Command -> Message In */
^~~~
drivers/scsi/arm/fas216.c: In function ‘fas216_funcdone_intr’:
drivers/scsi/arm/fas216.c:1573:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if ((stat & STAT_BUSMASK) == STAT_MESGIN) {
^
drivers/scsi/arm/fas216.c:1579:2: note: here
default:
^~~~~~~
drivers/scsi/arm/fas216.c: In function ‘fas216_handlesync’:
drivers/scsi/arm/fas216.c:605:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
info->scsi.phase = PHASE_MSGOUT_EXPECT;
~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
drivers/scsi/arm/fas216.c:607:2: note: here
case async:
^~~~
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/scsi/arm/fas216.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index aea4fd73c862..6c68c2303638 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -603,6 +603,7 @@ static void fas216_handlesync(FAS216_Info *info, char *msg)
msgqueue_flush(&info->scsi.msgs);
msgqueue_addmsg(&info->scsi.msgs, 1, MESSAGE_REJECT);
info->scsi.phase = PHASE_MSGOUT_EXPECT;
+ /* fall through */
case async:
dev->period = info->ifcfg.asyncperiod / 4;
@@ -915,6 +916,7 @@ static void fas216_disconnect_intr(FAS216_Info *info)
fas216_done(info, DID_ABORT);
break;
}
+ /* else, fall through */
default: /* huh? */
printk(KERN_ERR "scsi%d.%c: unexpected disconnect in phase %s\n",
@@ -1411,6 +1413,8 @@ static void fas216_busservice_intr(FAS216_Info *info, unsigned int stat, unsigne
case STATE(STAT_STATUS, PHASE_DATAOUT): /* Data Out -> Status */
case STATE(STAT_STATUS, PHASE_DATAIN): /* Data In -> Status */
fas216_stoptransfer(info);
+ /* fall through */
+
case STATE(STAT_STATUS, PHASE_SELSTEPS):/* Sel w/ steps -> Status */
case STATE(STAT_STATUS, PHASE_MSGOUT): /* Message Out -> Status */
case STATE(STAT_STATUS, PHASE_COMMAND): /* Command -> Status */
@@ -1422,6 +1426,8 @@ static void fas216_busservice_intr(FAS216_Info *info, unsigned int stat, unsigne
case STATE(STAT_MESGIN, PHASE_DATAOUT): /* Data Out -> Message In */
case STATE(STAT_MESGIN, PHASE_DATAIN): /* Data In -> Message In */
fas216_stoptransfer(info);
+ /* fall through */
+
case STATE(STAT_MESGIN, PHASE_COMMAND): /* Command -> Message In */
case STATE(STAT_MESGIN, PHASE_SELSTEPS):/* Sel w/ steps -> Message In */
case STATE(STAT_MESGIN, PHASE_MSGOUT): /* Message Out -> Message In */
@@ -1575,6 +1581,7 @@ static void fas216_funcdone_intr(FAS216_Info *info, unsigned int stat, unsigned
fas216_message(info);
break;
}
+ /* else, fall through */
default:
fas216_log(info, 0, "internal phase %s for function done?"
@@ -1957,6 +1964,7 @@ static void fas216_kick(FAS216_Info *info)
switch (where_from) {
case TYPE_QUEUE:
fas216_allocate_tag(info, SCpnt);
+ /* fall through */
case TYPE_OTHER:
fas216_start_command(info, SCpnt);
break;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/4] clk: core: introduce clk_hw_set_parent()
From: Jerome Brunet @ 2019-08-06 8:28 UTC (permalink / raw)
To: Neil Armstrong, sboyd
Cc: Neil Armstrong, Martin Blumenstingl, linux-kernel, linux-amlogic,
linux-clk, linux-arm-kernel
In-Reply-To: <20190731084019.8451-2-narmstrong@baylibre.com>
On Wed 31 Jul 2019 at 10:40, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Introduce the clk_hw_set_parent() provider call to change parent of
> a clock by using the clk_hw pointers.
>
> This eases the clock reparenting from clock rate notifiers and
> implementing DVFS with simpler code avoiding the boilerplates
> functions as __clk_lookup(clk_hw_get_name()) then clk_set_parent().
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Looks ok to me but we will obviously need Stephen's ack to apply it
> ---
> drivers/clk/clk.c | 6 ++++++
> include/linux/clk-provider.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index c0990703ce54..c11b1781d24a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2487,6 +2487,12 @@ static int clk_core_set_parent_nolock(struct clk_core *core,
> return ret;
> }
>
> +int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *parent)
> +{
> + return clk_core_set_parent_nolock(hw->core, parent->core);
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_set_parent);
> +
> /**
> * clk_set_parent - switch the parent of a mux clk
> * @clk: the mux clk whose input we are switching
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 2ae7604783dd..dce5521a9bf6 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -817,6 +817,7 @@ unsigned int clk_hw_get_num_parents(const struct clk_hw *hw);
> struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw);
> struct clk_hw *clk_hw_get_parent_by_index(const struct clk_hw *hw,
> unsigned int index);
> +int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *new_parent);
> unsigned int __clk_get_enable_count(struct clk *clk);
> unsigned long clk_hw_get_rate(const struct clk_hw *hw);
> unsigned long __clk_get_flags(struct clk *clk);
> --
> 2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: meson: Link nvmem and secure-monitor nodes
From: Jerome Brunet @ 2019-08-06 8:26 UTC (permalink / raw)
To: Carlo Caione, srinivas.kandagatla, khilman, narmstrong, robh+dt,
tglx, linux-arm-kernel, linux-amlogic, devicetree
Cc: Carlo Caione
In-Reply-To: <20190731082339.20163-4-ccaione@baylibre.com>
On Wed 31 Jul 2019 at 09:23, Carlo Caione <ccaione@baylibre.com> wrote:
> The former is going to use the latter to retrieve the efuses data.
>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] nvmem: meson-efuse: bindings: Add secure-monitor phandle
From: Jerome Brunet @ 2019-08-06 8:25 UTC (permalink / raw)
To: Carlo Caione, srinivas.kandagatla, khilman, narmstrong, robh+dt,
tglx, linux-arm-kernel, linux-amlogic, devicetree
Cc: Carlo Caione
In-Reply-To: <20190731082339.20163-3-ccaione@baylibre.com>
On Wed 31 Jul 2019 at 09:23, Carlo Caione <ccaione@baylibre.com> wrote:
> Add a new property to link the nvmem driver to the secure-monitor. The
> nvmem driver needs to access the secure-monitor to be able to access the
> fuses.
>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Rework secure-monitor driver
From: Srinivas Kandagatla @ 2019-08-06 8:25 UTC (permalink / raw)
To: Kevin Hilman, Carlo Caione
Cc: devicetree, narmstrong, robh+dt, linux-amlogic, tglx,
linux-arm-kernel, jbrunet
In-Reply-To: <7hftmfguug.fsf@baylibre.com>
Hi Kevin,
On 05/08/2019 22:34, Kevin Hilman wrote:
> Srinivas,
>
> Carlo Caione <ccaione@baylibre.com> writes:
>
>> The secure-monitor driver is currently in really bad shape, not my
>> proudest piece of code (thanks Jerome for pointing that out ;). I tried
>> to rework it a bit to make it a bit more tolerable.
>>
>> I needed to change a bit the APIs and consequently adapt the only user
>> we have, that is the nvmem/efuses driver. To not break bisectability I
>> added one single commit to change both the drivers.
>
> With your ack on the nvmem bindings and nvmem part of patch 4/4, I can
> take the series take the rest of this series through my tree for Amlogic
> SoCs.
Sounds good for me!
I have Acked the driver changes, bindings need ack from DT guys.
Thanks,
srini
>
> Kevin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] firmware: meson_sm: Rework driver as a proper platform driver
From: Srinivas Kandagatla @ 2019-08-06 8:23 UTC (permalink / raw)
To: Carlo Caione, khilman, narmstrong, robh+dt, tglx, jbrunet,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <20190731082339.20163-5-ccaione@baylibre.com>
On 31/07/2019 09:23, Carlo Caione wrote:
> The secure monitor driver is currently a frankenstein driver which is
> registered as a platform driver but its functionality goes through a
> global struct accessed by the consumer drivers using exported helper
> functions.
>
> Try to tidy up the driver moving the firmware struct into the driver
> data and make the consumer drivers referencing the secure-monitor using
> a new property in the DT.
>
> Currently only the nvmem driver is using this API so we can fix it in
> the same commit.
>
> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> ---
> drivers/firmware/meson/meson_sm.c | 94 +++++++++++++++++--------
> drivers/nvmem/meson-efuse.c | 24 ++++++-
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] serial: sh-sci: Don't check for mctrl_gpio_init() returning -ENOSYS
From: Geert Uytterhoeven @ 2019-08-06 8:09 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
Greg Kroah-Hartman, shawnguo@kernel.org, s.hauer@pengutronix.de,
Jiri Slaby, linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, u.kleine-koenig@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-3-frieder.schrempf@kontron.de>
On Fri, Aug 2, 2019 at 12:04 PM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
> if CONFIG_GPIOLIB is disabled, we can safely remove this check.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/4] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Geert Uytterhoeven @ 2019-08-06 8:09 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
Greg Kroah-Hartman, shawnguo@kernel.org, s.hauer@pengutronix.de,
Jiri Slaby, linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, u.kleine-koenig@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-1-frieder.schrempf@kontron.de>
On Fri, Aug 2, 2019 at 12:04 PM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
> mctrl_gpio_init_noauto() will currently return an error pointer with
> -ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
> check for this condition to allow continue probing.
>
> To avoid the need for this check in each driver, we return NULL
> instead, as all the mctrl_gpio_*() functions are skipped anyway.
> We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox